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

这是一个尴尬的事实，大多数 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 的成本。正在发生的事情更接近于“老虎机式调试”：你不断拉动杠杆，直到红灯停止闪烁，然后你走开，并确信机器没问题。

控制面板上的对话情况看起来很健康。每次调用的平均 token 数合理，p50 输入长度舒适地处于缓存前缀（cached prefix）之内，供应商的发票按照财务部门批准的速度增长。然后，有人导出了一个包含 200 轮对话的单次编程会话，该用户的单项支出就超过了团队其余成员每日流量的总和。控制面板没有撒谎 —— 它只是在算平均值。账单来自于长尾（long tail），而长尾并不会随着轮次增加而线性增长。

每一个多轮对话的 AI 功能最终都会遇到这种“惊喜”。每次调用的 token 数是一个错误的衡量单位，因为 30 轮对话的成本不是单次调用的 30 倍 —— 而是 50 倍到 200 倍之间，这取决于历史记录的结构方式、提示词缓存（prompt cache）的衰减情况，以及一旦输入超过 200K token 后请求所处的计费层级。根据单次调用数据为功能定价的团队，实际上是在为他们从未建模过的长尾风险承保。

六个月的绿色 CI 掩盖了一个事实：大约 40% 的评估集（eval set）已不再代表用户在产品中的实际行为。测试套件仍在运行，裁判（judge）仍在打分，仪表盘依然闪烁着绿光。但这些案例是针对查询分布、语料库、工具界面和监管文本编写的，而这些内容早已发生了变化——现在的绿色运行意味着“昨天的产品在昨天的现实中依然有效”，而这并不是你付费让 CI 回答的问题。

这就是“快照评估退化”（snapshot eval decay），它是 AI 评估中最缓慢、最昂贵的失败模式。说它缓慢，是因为套件从未失败——陈旧性表现为无法区分模型优劣，而不是构建变红。说它昂贵，是因为当有人意识到评估通过的模型切换导致了生产环境回归时，团队已经建立了一年之久的“评估通过即发布”的肌肉记忆，而这一记忆是建立在一个早已悄然失效的资产之上的。