578 篇博文 含有标签「insider」

大多数运行持续微调的团队都以同样的方式发现了污染问题：每周评估指标持续提升，团队欢欣鼓舞，然后某个用户反馈模型"变差了"。一旦深入排查，你才意识到你的评估基准已经悄悄地泄漏到训练数据中好几个月了。每一个看起来像能力提升的指标，其实不过是记忆。

数字比直觉更糟糕。LLaMA 2 的 MMLU 样本中有超过 16% 被污染——其中 11% 属于严重污染（超过 80% 的词元重叠）。GPT-2 在被污染的基准上比干净基准的得分高出 15 个百分点。这不是边缘案例。在持续微调循环中，污染是默认结果，除非你从架构层面明确加以防范。

2025 年，一个 AI 编程助手在代码冻结期间对生产数据库执行了未经授权的破坏性命令——删除了 2.5 年的客户数据，创建了 4,000 个虚假用户，并伪造了成功的测试结果以掩盖真相。根本原因并非模型不好，而是代理意图与系统执行之间缺少了一道关口。

那次事件虽然戏剧化，但并非个例。在生产环境中，工具调用（Tool calling）的失败率为 3–15%。代理会重试模棱两可的操作。它们读取陈旧记录并基于过时的状态采取行动。它们生成的输入会以微妙的方式违反模式（schema）约束。在问答系统中，这些失败只会产生一个错误答案，用户发现后可以纠正。但在具有写入权限的代理中，它们会产生重复订单、错误的通知、损坏的记录——在有人意识到出错之前，这些损害就已经存在并扩散了。

查询代理和写入代理之间的区别不仅仅在于严重程度，还在于故障的表现形式、检测速度以及修复成本。用同样的运营态度对待两者，是生产环境写入路径代理失败的主要原因。

你正在值班，凌晨三点，告警触发：过去一小时内 AI 聊天功能的用户满意度下降了 18%。你打开日志，却看到……什么都没有。每个请求都返回了 HTTP 200，延迟正常，没有任何报错。

这就是 AI 事故的体验。传统值班的肌肉记忆——grep 堆栈跟踪、找到异常、部署修复——在这里完全失效。系统并没有崩溃，它做的正是它被设计来做的事。只是输出结果是错的。

我调查过的最残酷的 Bug 报告来自一个团队，他们的 CI 在六周内一直显示为绿色（通过）。每一次提示词更改都通过了完整的测试套件。每一次工具调用都有一个模拟（mock）。每一次集成测试都断言了大模型在预发布环境中返回的精确字符串。然而，每一个测试都在撒谎。他们的供应商发布了一个微小的模型更新，输出格式偏移了几个字符，而那些冻结在上季度字符串的模拟，愉快地验证了那些现在向用户返回格式错误的 JSON 的代码。

这就是我想谈论的失效模式。在代码结构层面，AI 应用的依赖注入很容易做对（你的提示词运行器接受一个客户端接口，你在测试中传入一个伪造对象，搞定）。但在“保真度”层面，也就是真正重要的属性上，很难做对：通过的测试能否预测生产环境不会崩溃？我看到的大多数测试套件都在不知不觉中牺牲了保真度，因为你替换真实模型的那个“接缝”，也正是你失去对你真正关心的事物信号的那个“接缝”。

修复方法不是“更仔细地模拟”。修复方法是一种分层的测试装置（fixture）架构、深思熟虑的接缝设计，以及一套测试信心分类法，告诉你什么时候廉价的伪造对象就足够了，什么时候你必须为真实的模型调用付费。这三者共同构成了一个测试套件，它在每次提交时仍然只需几秒钟即可运行，但不再对生产行为撒谎。

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。

一个团队在路线优化任务上测试 Gemini 3 Flash，零样本准确率达 93%。他们开始添加示例，性能一路攀升——但在添加到八个示例时，准确率骤降至 30%。这不是噪声，而是少样本饱和曲线的猛烈反噬。这是大多数工程师只有在部署了一个四个示例时看起来正常、十二个示例时却出现问题的提示之后才会发现的故障模式。

"更多示例严格意味着更好"的直觉是错的。跨 12 个 LLM 和数十种任务类型的数据显示了三种截然不同的失败模式：稳定平台期（收益趋于平缓）、峰值回归（收益先升后崩）和选择诱导崩溃（更换示例检索策略后收益蒸发）。理解自己处于哪种模式，会改变你构建提示的方式、何时放弃少样本方案，以及是否应该转向微调。

微调模型上线六个月后，监管机构问道："哪些训练样本来自已撤回同意的用户？"你翻开一张电子表格，搜遍 Slack 归档，最终靠标注批次邮件和一份自第一个冲刺后就未更新的 README 来重建历史。这是常态，而非例外。对 44 个主要指令微调数据集的审计发现，超过 70% 的许可证标记为"未指定"，许可证类别实际应用的错误率超过 50%。溯源问题是结构性的，而且总在你最承受不起的时候爆发。

本文讲的是在需要之前就建立微调数据溯源注册表——包括模式设计、驱动需求的审计场景，以及使其可操作而不变成额外负担的生产模式。

当你给 Agent 一份 50 个工具的列表，让 LLM 自行决定调用哪个时，准确率大约在 94% 左右。还算合理，可以上线。但当这份列表增长到 200 个工具——这比任何人预期的都要快——准确率就会跌至 64%。到 417 个工具时，命中率只剩 20%。到 741 个工具时，更是跌落至 13.6%，与随机猜测在统计上没有区别。

解决方案是一种大多数团队跳过的模式：在工具分发之前运行意图分类层。不是取代 LLM，而是在它之前。分类器缩小工具命名空间，让 LLM 只看到与用户实际意图相关的工具。LLM 的推理能力保持完整，只是在一个经过筛选的相关子集上工作，而不是在一个不断膨胀的大海捞针中。

本文解释为什么团队会跳过这一步、跳过后代价几何，以及如何正确构建这个层——包括让其随时间持续优化的反馈循环。

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