639 篇博文 含有标签「llm」

每个上线 LLM 功能的团队都会经历相同的演变曲线。一开始，你硬编码一个 OpenAI API 调用。然后加上重试逻辑。然后有人问你花了多少钱。然后某个周五下午供应商宕机了，于是你开始构建网关。

这并非偶然。推理网关是一种自然涌现的架构模式——应用与 LLM 提供商之间的中间件层，将限流、故障转移、成本追踪、提示词日志和路由整合到一个统一的关卡中。它是 AI 时代的负载均衡器，如果你在生产环境中运行模型，你要么已经有了一个，要么正在不知不觉中构建一个。

你的 RAG 管道在回答单一事实问题时表现出色。问它"我们的退款政策是什么？"它每次都能准确回答。但如果问"哪些企业版客户在合同续签后 30 天内提交了关于计费 API 的工单？"它就无能为力了。答案确实存在于你的数据中——分散在三种不同的文档类型中，通过余弦相似度无法捕捉的关系连接在一起。

这就是多跳推理问题，也是越来越多的生产级 RAG 团队在向量检索管道上嫁接知识图谱的原因。不是因为图谱又流行了，而是因为他们遇到了一个具体的准确率天花板——无论怎么调整分块大小或重新排序都无法突破。

每个人都在讨论如何避免 LLM 供应商锁定。建议通常归结为"使用抽象层"——仿佛把 openai.chat.completions.create 换成 litellm.completion 就能解决问题。但事实并非如此。API 调用是最简单的部分。真正的锁定是隐形的：它存在于你的提示词、评估数据、工具调用假设，以及你不知不觉围绕特定行为设计的系统中。

供应商可移植性不是非黑即白的。它是一个连续谱系，大多数团队比他们认为的离可移植端更远。好消息是，实现真正可移植性的模式已经很成熟——只是比引入一个封装库需要更多的纪律性。

每隔几个月，团队里就会有人转发一篇关于 Llama 或 Qwen 在某个基准测试上"媲美 GPT-4"的博客文章，然后不可避免地提出这个问题："既然我们可以自己运行，为什么还要为 API 调用付费？"在草稿纸上算一算，这个数字看起来很有吸引力。但现实是，大多数尝试自托管的团队最终花费反而更多——不是因为模型不好，而是他们低估了模型之外的所有成本。

话虽如此，在某些特定场景下，自托管开源权重模型确实是明确正确的选择。关键在于认清你实际所处的场景，而不是你希望自己所处的场景。

当今生产环境中最有效的 AI 智能体看起来与框架演示完全不同。它们不是拥有十七种节点类型的有向无环图，也不是通过消息总线协调的多智能体集群。它们是一个提示词、一个工具列表和一个 while 循环——它们比框架重型的对手交付更快、故障更少、维护成本更低。

这不是为了标新立异。这是一个又一个团队在花费数周时间进行框架迁移、抽象调试和 DSL 考古之后得出的结论。这种模式如此一致，值得给它一个名字：后框架时代。

你的 A/B 测试框架是为按钮和横幅颜色而生的。它假设当你向用户展示变体 B 时，变体 B 每次的行为都相同。这个假设是如此根本，以至于没有人费心去明说它。然而对于 AI 功能而言，这个假设完全是错的。

当处理本身是非确定性的——当同一个提示每次请求都会产生不同的输出时——你试图测量的方差被你无意中制造的方差所掩盖。大多数团队都是经历了惨痛教训才意识到这一点：本应在一周内达到显著性的实验跑了一个月；周二看起来显著的结果到周四又逆转了；而"获胜"的变体在推广到 100% 流量后却毫无提升。

这不是一个小小的统计干扰问题，而是实验平台的工作方式与 LLM 驱动功能的实际行为之间的结构性错配。

AI 功能发布中存在一个重复出现的模式：演示（demo）惊艳全场，功能正式上线，两周内发生了一些灾难性的事情。不是宕机——那些很容易捕捉。而是一些更微妙的事情：模型自信地生成错误信息，成本飙升到预期三倍，或者在真实负载下延迟激增导致功能无法使用。团队手忙脚乱，功能被悄悄禁用，大家一致同意“下次做得更好”。

问题不在于演示做得不好。问题在于演示成了唯一被重视的测试。

大多数线上故障的失败，并非因为缺乏工具，而是因为值班工程师在最需要的时刻无法快速获得足够的上下文。凌晨三点，工程师被一墙的触发告警惊醒，先花 20 分钟拼凑出到底哪里出了问题，再花 20 分钟判断该用哪份运维手册，等到真正开始执行修复时，故障已经持续了将近一个小时。而实际的修复动作可能只需要 5 分钟。

AI 能够将这个上下文收集窗口从 40 分钟压缩到 2 分钟以内。这才是真正摆在桌面上的价值。但"LLM 帮助值班工程师"并不是一个单一的产品决策，而是一系列决策的叠加，每一层都有其独特的失效模式，而某些失效模式的后果，远比客服聊天机器人幻觉严重得多。

你的 AI 产品在评估套件中获得了 82% 的分数。你向 40 个国家发布了产品。三个月后，法国和德国用户报告的质量与英语用户相似。印地语和阿拉伯语用户则悄悄停止了使用该功能。你的综合满意度评分几乎没有波动 —— 因为英语用户主导了指标池。悬崖一直都在。你只是没有测量它。

这是大多数发布多语言 AI 产品的团队都会遇到的典型情况。质量差距并非微乎其微。像 QwQ-32B 这样的最先进模型，在英语推理基准测试中分数为 70.7%，但在斯瓦希里语中则下降到 32.8% —— 这是 2025 年测试的最佳模型在性能上的 54% 相对崩溃。而且这还是 最佳 模型。这种差距并不会随着模型变大而消失。它在高资源语言中会缩小，但在其他语言中依然很大。

大多数提示工程的努力都集中在让指令更清晰上：更精准的动词、更好的格式、更明确的约束。这确实有效——在某种程度上。但生产级 AI 系统的瓶颈往往不是指令清晰度，而是模型明明拥有相关知识和能力，却根本没有将其激活。

这就是提示工程与能力激发的本质区别。提示工程优化的是你如何提问，能力激发优化的是模型在回答时从自身权重中调取了什么。这一区别至关重要，因为两者的失败方式截然不同：提示工程失败时，你得到的是格式混乱或答非所问的回复；激发失败时，你得到的是格式完美、措辞自信，却错过了模型明明具备的洞察力的回复。

大多数团队在优化 LLM 提示词时，其实在解决一个错误的问题。他们花好几周打磨指令的措辞——调整用词、重排约束条件、改变语气——而真正的瓶颈却在于：模型其实已经知道如何完成这个任务，只是你的提示词从未触发正确的能力路径。

这就是提示工程与能力激发之间的本质区别。提示工程解决的是"如何表达你想要什么"，而能力激发解决的是"如何唤醒模型已有的能力"。这一区分至关重要，因为两者的修复方式截然不同——误判问题所在，会让你在错误的方向上白白迭代数月。

大多数将"差分隐私"视为合规复选框的团队实际上并没有得到保护。他们在流水线的某个环节添加了噪声——也许是在微调时添加到梯度上，也许是在检索时添加到查询嵌入上——然后得出结论认为问题已经解决。合规文档写着"已启用 DP"，工程团队继续前进。

他们没有做的是：定义 epsilon 预算、核算系统将服务的每一次查询所消耗的预算，或者验证其隐私损失是否受到有效约束。在实践中，"我们添加了噪声"与"我们拥有有意义的隐私保证"之间的差距，正是大多数现实世界 AI 隐私事件发生的地方。

本文就是关于这个差距的：差分隐私对 LLM 实际承诺了什么，这些承诺在哪里失效，以及团队做出的工程决策——通常是隐性的——如何决定他们的 DP 部署是真正的保护还是表面文章。