842 篇博文 含有标签「ai-engineering」

一个团队负责摘要生成器。另一个团队负责摄取这些摘要的搜索排序器。第三个团队负责一个路由，根据排序器的置信度分数在不同的智能体人格之间进行选择。这些团队都没有共同的值班轮换，也没有人参加同一个站会，他们之间唯一的契约就是“上一个功能的输出是下一个功能的输入”。周二，摘要团队收紧了一个提示词，以修复销售演示中反馈的幻觉问题。六小时后，搜索排序器的质量骤降。到周三早上，路由开始将任务交给错误的智能体人格。复盘报告会将原因记录为“提示词变更”，但实际原因是团队的 AI 功能已经悄然组成了一个没人绘制过的有向图。

这是最常见的 AI 故障形式，它不会触发你为 AI 故障构建的任何警报。模型没有宕机。被修改功能的评估套件显示为绿色。Token 成本曲线很平稳。真正断裂的是两个功能之间的接口，你的依赖工具将其视为纯文本，因为在 API 边界它确实只是纯文本——并且将其视为惰性的，因为纯文本不携带版本、Schema 或弃用策略。

上个季度评分 92% 的评估集（eval set）现在评分达到了 94%，团队称之为进步。事实并非如此。该评估集中的标签是根据标注员脑海中早已模糊的准则（rubric）编写的。模型评分所针对的产品已经发生了变化。标准已经发生了变化。标注员自身的校准（calibration）也发生了变化。表面上 2% 的提升，实则是静态产物与动态产品之间无声的差距，且只要团队不更新，这种差距每周都会扩大。

标注漂移（Annotation drift）是成熟 LLM 评估方案中一种隐蔽的失效模式。它不会表现为回归（regression）——回归是简单的情况，因为数值会下降，从而触发人员调查。它表现为一个持续显示绿色的数字，而其原本衡量的内容在底层已经腐烂。已经建立了评估集、编写了准则并招募了标注员的团队面临的风险最大，因为他们信任自己构建的系统，从而停止了对基础的审计。

这是一个尴尬的事实，大多数 AI 团队在发现时往往已经晚了半年：一个精心设计的评估（eval）用例所耗费的工程精力通常比它要测试的功能本身还要多。修改一次提示词（prompt）只需要一个下午。而让你确信这次修改没有破坏原有功能的评估用例，则需要领域专家进行为期两天的标注，一个与裁判提示词（judge prompt）的校准循环，以及一场关于“正确”在当前用户界面下究竟意味着什么的讨论。功能可以在一个 Sprint 内交付，而让你能够安全交付后续十个功能的评估体系则需要一个季度才能成熟。

这种不对称性并非缺陷。它是评估工作的结构性形态。标注、边缘情况的策划、裁判校准和评分标准设计都是前置的固定成本，它们不随你交付功能的多少而扩展，而是随你想要验证的不同行为（behaviors）数量而扩展。与此同时，功能开发端不断产生看似廉价的边际输出：“又一次提示词迭代”、“为智能体增加了一个工具”、“更换模型”。每一个改动看起来都很微小。但每一个改动都在无声无息地增加评估集必须覆盖的范围。

演示进行得非常完美。全场鼓掌。两周后，同样的功能出现在公司内部使用的 Slack 中，到了周三，一位高级工程师发布了截图，配文是“有人测试过这个吗？”到了周五，频道变得寂静无声 —— 并不是因为 Bug 被修复了，而是因为那些本来会指出问题的人已经放弃了，回到了旧的工作流。发布计划仍在日程表上。没有人取消它。没有人拥有取消它的政治资本。

这就是从演示到内部试用（dogfooding）之间的鸿沟。MIT NANDA 计划去年对其进行了衡量，比例高达 95% —— 即在企业级生成式 AI 试点项目中，有 95% 未能产生可衡量的损益（P&L）影响，而几乎所有这些项目都有一个令人心动的演示。模型本身不是问题。演示与内部使用第一周之间的差距才是问题，每个发布过 AI 功能的团队都曾目睹过类似情形的上演。

迁移工单只有一行：“将 Embedding 模型从 v3-small 升级到 v3-large。”新模型在公开基准测试（Benchmark）中胜出 12%。流水线代码改动只有六行 Python。团队预计需要两天的开发时间，加上一个周末就能跑完的重嵌入（Re-embedding）任务。两个月后，查重功能的误报率比更换前翻了一倍，“相关项目”栏目悄然变成了废话生成器，语义缓存的命中率更是断崖式下跌，因为在旧空间运行良好的 0.95 阈值在现在几乎匹配不到任何内容。

没人动过这些功能。没人提交过 Bug。这个在迁移计划中被归类为“基础设施”的模型切换，悄无声息地改写了每一个使用相似度得分的业务规则。

一名高管发了一封只有一行字的邮件：“好消息——我们在下个冲刺周增加视觉能力。”产品经理将其解读为一星期的工作量：更换模型、开放图像参数、发布。评估（Eval）团队读了同样的邮件，脑子里已经开始起草一份尚未获批的四周计划。到了周五，这种认知脱节在站会上表现为一句含糊的“我们需要做一些评估工作”，然后大家一致同意以后再解决。

这种在“我们添加了视觉能力”与“我们可以安全发布视觉能力”之间的鸿沟，就是评估补填税（Eval Backfill Tax）。每当新的模型能力落地时——多模态输入、工具使用、更长上下文、推理轨迹、电脑使用——这项工作就会悄无声息地落在评估团队身上。因为历史测试案例是在一个模型不会以这些新方式失败的体系下构建的。测试套件依然显示绿色，头条基准测试分数在上升，但生产环境的发布却暴露出了没人写过测试的失效模式。

我最近合作的一个团队失去了一位资深机器学习工程师。两周后，每个 PR 的评估套件（eval suite）依然全绿——847 个案例全部通过，裁判一致性（judge agreement）达到 92%。六周后，一位客户发现了一个回归问题，而这个问题本该被“支持质量”桶里的第一个评估案例捕获。当团队进行调试时，没人能解释为什么要写那个案例，它本该捕获哪种失败模式，或者为什么裁判提示词（judge prompt）是按 1–4 分评分而不是二元评分。那个案例依然通过了，但它并没有测试任何有人能说清楚的东西。

这就是评估的公交车系数（eval bus factor）：一种无声的失败模式。在这里，决定 AI 功能“正确”含义的人，也是策划测试用例、校准裁判模型并吸收了大脑中每一个隐含标注权衡的人。当他们离职时，评估套件虽然依然保持绿灯，但却不再能产生可靠的发布/拒绝信号——因为没有其他人能扩展它、调试不稳定的裁判，或评估新的失败模式是否属于测试集。

一个健康的评估集（eval set）本应是成熟的标志。但在任何一个周一，它也可能意味着排队等待的 1,000 个失败案例，而人工审核员只有 8 小时，且每个案例的处理效率大约是 50 个。这笔账很残酷：大约每 20 个失败案例中只有一个会被阅读。剩下的 19 个只能等待。至于哪 19 个在等，哪一个能被选中，完全取决于文件加载的顺序。

大多数团队将其称为“审核失败案例”。但它更像是一场按字母顺序加权的抽奖。一个影响 2% 生产流量且位于文件顶部的失败案例会得到关注。而一个影响 40% 生产流量但位于文件底部的失败案例，即便能被看上一眼，也要等到周五下午。团队在周二发布了针对小问题的修复方案，并在周四写了一份回顾（retro），纳闷为什么仪表盘上的指标毫无变化。

每个人都在看的成本仪表盘是一个周滚动平均值，而那个平均值正在对你说谎。并不是说数字本身是错误的——它是计费事件流的忠实算术平均值——而是它隐藏了底层的成本曲线形态。周五晚上到周一早上之间的 token 消耗方式，与周二上午 10 点到周四下午 4 点之间截然不同。周六凌晨 3 点活跃的群体与周二上午 11 点活跃的群体并非同一拨人，这些群体的单用户经济效益（per-user economics）差异巨大，但没人记录这一点，因为仪表盘通过平均值将其抹平了。

大多数团队第一次发现这一点，是在周末自动化脚本烧光预算的时候。一个 LangChain 智能体在周五晚上陷入了无限对话循环，运行了大半周才被人发现，导致产生了一张五位数的账单，周一早上不得不向财务部门解释。事后回顾将其视为一次性事件——糟糕的重试逻辑、缺失的预算上限、没有触发值班报警。但是，那个隐藏了失控循环的仪表盘，同时也隐藏了同一现象的稳态版本：每周都会出现的非工作时间流量基准，其单位经济效益在结构上比工作时间基准更差，而周平均值让这一切变得不可见。

一位工程负责人（Head of Engineering）在周一早晨打开了研发速率仪表盘。每周合并的 PR 数量：持平。完成的故事点：持平。改动的代码行数：低得可疑。图表显示，AI 团队在这个季度表现平平。而在两个楼层之外，那支团队在三周内重写了七次系统提示词（System Prompt），更换了一个让工具调用准确率翻倍的工具描述，增加了六个新的 few-shot 示例，并不断调整重排序（Rerank）指令，直到产品感觉像是一个完全不同的应用。所有这些工作都没有出现在 PR 图表中。但对用户来说，这些改变无处不在。

AI 团队所做的改动与工程仪表盘所测量的指标之间的不对称，已成为 2026 年最具影响力的误判。在重度依赖 AI 的产品中，行为的改变正日益与代码的改动解耦，而支配了软件组织十五年的指标——PR 吞吐量、提交量、涉及的代码行数——衡量的都是代码的改动。一个团队可能每周都在重塑线上响应的分布，但在领导层信任的每一张图表上，他们看起来却无所事事。

一个自托管 LLM 团队将生产模型从 fp16 量化为 int4。内存占用降低了 4 倍，吞吐量几乎翻倍，GPU 账单大幅缩减，团队重新运行了曾用于 fp16 发布把关的同一套评估组件。MMLU-Pro 保留了基准测试的 98.1%。综合质量看起来不错。他们发布了。

六周后，一名支持工程师注意到数学辅导功能悄悄变差了。合规团队标记了在对抗性提示下违反政策的补全次数有所增加。结构化输出的重试率从 1.4% 攀升至 6.8%。这些都没有出现在评估仪表盘上，因为评估仪表盘是为了验证另一个模型而构建的——那个虽然共享相同权重文件，但每个激活值背后都有四倍比特位的模型。

这就是量化漂移（quantization slippage）。成本分析只计算了内存和延迟方面的收益，却没有计算这次替换在无形中要求的评估重新锚定。而针对 fp16 分布进行校准的评估套件，现在正用错误的准则对错误的模型进行评分。

当 AI 功能表现异常时，大多数工程师做的第一件事就是再次点击“运行（run）”。这种思路认为，模型是具有随机性的，所以这次运行可能只是运气不好。当第二次尝试产生看起来合理的结果时，工单就被关闭了。团队继续前进。而真正的 Bug——过期的工具响应、检索缺失、仅在包含特定 token 的输入时才触发的系统提示词冲突——仍然完好无损地留在生产环境中，等待下一个用户触发它。

这就是“重跑反模式（rerun antipattern）”，它是 AI 团队从聊天机器人时代继承下来的最昂贵的调试习惯。它看起来很严谨，因为模型确实是非确定性的。它看起来像是一种方差探测。但几乎没有人在重新运行之前写下假设，没有人预先决定多少次运行才算证据，也没有人考虑 token 的成本。正在发生的事情更接近于“老虎机式调试”：你不断拉动杠杆，直到红灯停止闪烁，然后你走开，并确信机器没问题。