990 篇博文 含有标签「insider」

你的评测套件得分 91%，但用户反映系统感觉不可靠。事后复盘发现了问题所在：你同时用 GPT-4o 来生成响应和评分。这个模型在评判自己的镜像，而它喜欢自己所看到的。

这就是裁判模型独立性问题。它比大多数团队意识到的更为普遍，产生的评分虚高幅度足以影响决策，而且修复方法既不复杂也不昂贵。但你必须知道从哪里找起。

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样，这个参数要么没设置，要么设成了模型的最大值，或者是半年前随便选的一个像 4096 这样的整数，之后就再也没动过。它是 API 请求中一个显眼的预算旋钮，却在默默地为你从未使用过的冗余买单。

在中等商业模型上，输出 token 的成本大约是输入 token 的四倍，而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的：你在 max_tokens 中留下的每一分未使用的余量，都是你可能需要支付的成本；而且由于解码是顺序进行的，你生成的每一个 token 都会线性地增加你的 P50 延迟。然而，大多数生产系统都将此参数视为安全阀——设置得高高的，然后忘掉它，继续开发。

2026 年 1 月，OpenAI 仅提前两周通知便将若干 GPT 模型从 ChatGPT 中退役——而就在此前不久，其 CEO 刚刚在公开场合承诺在此次退役后会"提前充分通知"。对于那些已将工作流构建在这些模型之上的团队而言，这份公告无异于周五下午收到的一条页面报警。那一次 API 未受波及，但下一次未必如此。

你当前调用的每一个模型都有弃用日期。部分日期已列在供应商的文档页面上，另一些尚未宣布。操作层面的问题不是你的生产模型是否会被退役，而是你能否在问题发生前及时收到通知并从容应对，还是在用户开始遭遇故障后手忙脚乱地迁移。

大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。

这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。

模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。

告警在凌晨 2:47 响起。面向客户的聊天助手正为一半的付费用户返回 429 错误。工程师们在仪表板中忙乱寻找，试图找到那天下午发布的 Bug。他们一无所获 —— 代码没问题。真正的罪魁祸首是另一个团队在当晚启动的批量摘要任务，它共享了同一个供应商 API 密钥，耗尽了该账户接下来四小时的每分钟 Token 预算。没有人拥有这个共享密钥，也没有人负责这个限制。

这就是“喧闹邻居”（noisy-neighbor）问题。与经典的 API 配额事故不同，它在 LLM 系统中表现出一种独特的残酷性。一个达到速率上限的 REST 端点会迅速失败并进行重试；而 LLM 的“每分钟 Token”（TPM）桶是根据请求内容非对称消耗的。因此，一个生成 8K Token 的功能可能会使一个进行低成本 200 Token 分类调用的功能陷入饥饿，而这一切在请求计数图表中甚至都不会显现。流量在你所测量的维度上并不“喧闹”。

大多数团队发现这一点的方式正如上文提到的团队：一个无关团队的任务与付费用户的会话发生冲突，而两者唯一的共同点只是环境变量中的一个字符串。

你的组织有一份隐私政策。它用合理的措辞描述了用户数据的谨慎处理、保留限制以及对 GDPR 和 HIPAA 的合规。但它几乎肯定没有说明：在任何策略控制生效之前，用户的姓名、电子邮件地址或病史是否以明文形式传输给了托管的 LLM API。

这个缺口——你能指出的隐私政策与你实际能证明的隐私保证之间的距离——正是大多数生产 LLM 系统悄然失守的地方。研究显示，提交给 ChatGPT 和 Copilot 等工具的提示词中，约有 8.5% 包含敏感信息，包括 PII、凭据和内部文件引用。在企业环境中，用户将邮件、客户数据和支持工单粘贴到 AI 辅助工作流程中，这一比例几乎肯定更高。

问题不在于开发者粗心大意。而在于 LLM 提示层从未被设计为数据处理边界。它从上游系统——用户输入、RAG 检索、智能体上下文——继承内容，却不执行治理整个技术栈其他部分的数据分类规则。

有一家公司每位用户每月收费 50 英镑。其 AI 功能消耗了 30 英镑的 API 费用。这意味着在支付任何一笔退款或处理任何一个流失席位之前，剩下的 20 英镑还要覆盖主机、支持和利润。他们打造了用户喜爱的产品，发展到数千名订阅者，却在不知不觉中构建了一个客户越多、亏损越多的商业模式。

这并非关于坏主意的警示故事，而是关于定价架构的警示故事——这套架构从一个下一个用户边际成本几乎为零的世界照搬而来。当你的产品需要调用语言模型时，那个世界已不再完全适用。

传统 SaaS 毛利率为 70–90%。以 AI 为核心的公司报告的数字是 50–60%——差距主要由一行成本解释：推理。当 Token 占据销售成本的 20–40% 时，标准 SaaS 打法就会失效。

几乎所有关于构建 AI Agent 的教程都以同样的方式开场：用户输入消息，Agent 进行推理，Agent 返回响应。这个模型对聊天机器人和副驾驶（Copilot）来说运行良好，却无法描述各组织正在大规模部署的大多数生产 AI 工作。

在企业环境中默默发挥最大价值的 Agent，并不等待消息。它们在数据库行发生变更时唤醒，在队列深度超过阈值时唤醒，在凌晨 3 点的定时任务触发时唤醒，或在监控检测到指标漂移超出范围时唤醒。它们在没有用户在场的情况下行动。一旦失败，没有人会察觉，直到损失已经累积到难以挽回。

构建这类主动型 Agent 需要一套与构建被动式助手截然不同的设计语汇。适用于对话型 AI 的会话（Session）思维模型，在 Agent 循环运行、在后台重试、没有人类兜底的场景下会彻底失效。

向生产环境中的 RAG 系统提一个你的语料库无法回答的问题，看看会发生什么。它很少会说“我没有那方面的信息”。相反，它会检索出五个排名最高的片段——由于没有更好的匹配项，这五个片段其实是五个最不糟糕的无关内容——然后将它们交给模型，并配上类似“请使用以下上下文回答用户的问题”的提示词。模型在被训练为要乐于助人的同时，手中握着与主题有几分相似的文本，于是产生了一个自信的回答。这个答案的错误在架构上是不可见的：检索成功了，生成也成功了，每个片段都在检索到的文档中有据可查，但用户却被误导了。

这就是检索空洞问题。它不是任何单一层级的 bug。它是一个流水线的涌现行为，该流水线将 “top-k” 视为一种契约，却从不询问 top-k 的质量如何。ICLR 2025 上发表的一项关于“充分上下文”（sufficient context）的研究量化了这一影响：当 Gemma 获得充分的上下文时，其在事实性问答上的幻觉率约为 10%。当它收到的上下文不足时——即检索到的文档实际上并不包含答案——该比率会飙升至 66%。向描述不足的查询中添加检索到的文档会让模型错得更自信，而不是更少。

大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。

这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。

重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。

大多数团队引入护栏的方式，和引入日志一样随意：直接挂上去，以为代价很小，然后继续往下走。但代价并不小。一次内容审核检查要花 10–50ms，再加上 PII 检测，又是 20–80ms；再叠上输出 schema 校验和毒性分类器，在第一个 token 到达用户之前，串行开销就已累积到 200–400ms。加上 500ms 的模型响应，你那个"快速"的 AI 功能现在给人的感觉就是迟钝。

把锅甩给 LLM 是错的。护栏才是瓶颈。解决方案不是去掉安全措施，而是停止把安全检查当成一堆无差别的任务，改用架构思维来对待它。

大多数决定微调模型的团队在写下第一行训练代码之前，都会花上几周时间争论该使用哪种方法。这种争论很少触及核心问题。真正的问题不是 “SFT 还是 DPO？”，而是 “我试图缩小什么样的差距？”

有监督微调（SFT）、人类反馈强化学习（RLHF）和直接偏好优化（DPO）并不是解决同一个问题的竞争性方案。每种方法针对的是不同的失败模式。在 SFT 足以解决问题时选择 RLHF 会浪费数月时间。而当问题实际上是偏好不匹配时选择 SFT，则会产生一个表达流利但在生产环境中暴露问题之前很难察觉到错误模型。

这篇文章提供了一个决策框架。它将每种方法映射到其解决的具体问题上，解释了哪些信号预示着哪种方法将占主导地位，并提供了一套诊断方法论，帮助你在开始训练之前识别出实际存在的差距。