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

一个用户询问你的助手某项配置更改是否可以安全发布。模型流式返回了：“是的，你可以安全地部署。” 300 毫秒后，它继续写道：“——但在 us-east 区域除外，那里的旧连接池仍在排空。”但用户已经读完了前半部分，感受到了绿灯带来的放松，并点击了部署。这句修正说明到达时，人已经走开了。

这里没有人犯错。模型是正确的。用户阅读了屏幕上的内容。渲染器忠实地显示了每个到达的 Token。然而结果却是一次糟糕的部署，因为流式传输将模型的“中间状态”变成了用户视为“最终结果”的东西。

你的团队启用模式约束解码（schema-constrained decoding）的那一天感觉像是一个里程碑。解析错误停止了。JSONDecodeError 警报消失了。从文本中抓取字段的脆弱正则表达式也被删除了。有人在站会上说“模型现在返回有效的 JSON 了”，结构化输出的任务单随之关闭。

那句话正是麻烦的开始。“模型现在返回有效的 JSON 了”是正确性工作的开始，而不是结束。JSON 模式和约束解码保证了响应的形状（shape）——即 quantity 是一个整数，status 是三个枚举值之一，对象包含你要求的键。它们完全无法保证 quantity 是否是正确的数字，status 是否反映了真实发生的情况，或者 sku 字段是否指向了目录中存在的商品。

让一个编程智能体 (AI agent) “为这个模块添加测试”，你会得到测试。它们格式整齐，遵循你的项目规范，而且能够通过。覆盖率会上升。这个 PR 看起来非常尽职。然而，这些测试中很大一部分根本无法捕捉到你可能引入的任何 Bug。

这并不是一个关于模型太蠢的故事。智能体完全按照要求完成了任务。问题在于，“添加测试”和“添加能约束行为的测试”是不同的请求，而其中只有一个是能被一眼验证的。无论是真正的断言还是同义反复（tautology），绿色的对勾看起来都一模一样。

结果就是，测试套件的代码行数在增加，但效能却在萎缩。你最终得到了更多的文件、更多的 CI 耗时、更多的维护成本——而交付回归缺陷的概率却与开始前几乎无异。

你的评测套件通过了。240 个案例全是绿色，和上周一样。你发布了代码。两天后，支持工单激增。当你阅读对话记录时，你发现了一种你的套件完全没有立场的失败模式——不是某个案例从通过变成了失败，而是用户开始问一些你的套件从未想到过要去问的问题。

这就是评测（evals）的无声失败。我们将“全绿”视作对现状的肯定：“系统运行正常”。实际上，它只是对过去的一种陈述——即编写这些评测案例的那一刻。六个月前编写的评测编码了当时的三样东西：产品的范围、模型的失败模式，以及真实用户表达请求的方式。而这三者都在变化。功能增加了新的界面，模型升级了两次。随着用户了解产品的功能，输入分布也发生了漂移。套件没有随之移动，因此全绿的运行结果越来越只是在证明一个不再存在的世界。

没有人注意到，因为没有东西崩溃。过时的评测不会报错。它会继续自信地通过，但衡量的关键内容却越来越少。

当安全团队审查一个新的工具集成时，他们会阅读代码。他们会检查函数的功能、它触及的内容、它需要的权限范围（scopes），以及它是否记录了敏感秘密。但他们几乎从不阅读那句决定模型是否调用该工具的句子——工具描述。那句话不仅仅是文档。它是模型视为权威的指令，而在大多数智能体堆栈中，没有人会去审计它。

工具描述是写给模型看的。模型利用它来决定工具何时相关、应该传递哪些参数，以及如何解释返回的结果。这使得描述成为了进入模型行为的一个控制通道。而当一个工具来自第三方注册表、一个你不运行的模型上下文协议（MCP）服务端，或者一个同事上周安装的插件时，这个控制通道的作者就是你从未同意信任的人。

这就是差距所在。输入净化（Input sanitization）检查用户输入的内容。代码审计（Code review）检查函数执行的内容。工具描述介于两者之间——它是表现得像输入的配置——它从这两个防护网中漏掉了。

当你输入“启动另一个智能体来并行处理”的那一刻，你就已经成为了一名分布式系统工程师。你可能没有注意到。框架让它变成了一行代码的改动，演示运行良好，延迟也降低了。但在底层，你刚刚引入了两个在没有协调的情况下读写共享状态的进程 —— 而困扰了数据库领域五十年的每一个竞态条件 (race condition)、更新丢失 (lost update) 和脏读 (dirty read)，现在都潜伏在你的智能体堆栈中，伺机而动。

这种情况之所以棘手，是因为故障看起来不像并发 Bug，而像是某个智能体出错了。输出在语法上是有效的，流水线显示绿色，没有抛出异常 —— 然而，客户被收取了两次费用，或者文件丢失了一半预期的内容，又或者一个智能体自信地根据另一个智能体已经覆盖的数字采取了行动。你去调试那个“愚蠢的智能体”，发现它的提示词 (prompt) 没有任何问题，因为提示词根本就不是问题的症结所在。

向量索引感觉就像一个数据库。你向其中写入文档，查询它，它返回结果。但它并不是数据库——它是存储在其他地方的数据的“派生、非规范化副本”。你的事实来源是 wiki、工单系统、CRM 或 PDF 文件夹。嵌入 (embeddings) 是这些事实的投影，冻结在你运行摄取任务 (ingestion job) 的那一刻。

这使得你的向量索引变成了一个缓存。就像所有缓存一样，它会失效。不同之处在于，大多数团队是有意识地构建缓存层，带有 TTL 和失效钩子 (invalidation hook)，而几乎没有人会有意识地将向量索引作为缓存来构建。他们将其构建为“知识库”，然后在它提供三周前就已经过时的知识时感到惊讶。

财务团队指出，本季度的 LLM 账单上涨了 18%。一名工程师调出使用情况仪表板，发现 70% 的流量现在流向了经济型模型（budget model）而非前沿模型（frontier model），他感到有些困惑：路由更改本应是为了削减开支。每 token 价格确实如电子表格预测的那样下降了。但账单还是上涨了。

这不是计费错误。这是成本优化在悄无声息中发生逆转的最常见方式。证明降级合理的电子表格衡量的是一件事——token——而生产系统支付的是完全不同的另一件事：完成的任务。较弱的模型不仅仅是产生更便宜的 token。它还会改变其周围每个组件的行为，而这些二阶效应最终都会反映在同一张发票上。

这个陷阱非常诱人，因为一阶数学逻辑确实是正确的。经济型模型的每 token 价格可能比前沿模型便宜 10 到 30 倍，且对于大部分流量，它返回的答案在质量上是难以区分的。错误不在于路由决策。错误在于在错误的边界衡量路由决策。

每一家在生产环境中上线 AI 功能的公司，都有那么一两个无法承受其离职损失的工程师，而大多数公司直到收到辞职邮件时，才意识到这些工程师是谁。

那个关键人物很少是办公室里嗓门最大的。他们是那个记得在第二季度的问题升级后，通过三行系统提示词（system-prompt）修改修好了客服摘要语气的人；是那个在模型供应商悄悄更改默认采样（sampling）的那周，在评估套件（eval suite）中添加了六个案例的人；也是那个在上次有人“清理”评分细则（rubric）时，发现评判标准校准（judge calibration）发生偏移的人。这些内容都没有被记录在继任者能找到的地方。它只存在于一个人的脑子里，而这个人的脑子大约每两周就会收到一次猎头发来的加薪 25% 的消息。

在每个 AI 功能的演进过程中，审阅者总会提出一个听起来很合理的问题：“我们能不能让模型告诉我们它的置信度（confidence），这样我们就可以把低置信度的回答路由给人工或备选方案？”这听起来像是一份免费保险。你在输出 schema 中添加一个 confidence 字段，模型尽职尽责地填好它，现在你就有了一个可以调节的旋钮。发布吧。

那个旋钮并不是免费的，更糟糕的是，它通常没有连接到任何实际逻辑上。置信度数字只是模型乐于生成的一个 token 序列，模型并没有义务让它具有实际意义。团队支付真实的 token 和延迟来获取它，却从不检查它是否与正确性相关，然后根据它路由生产环境的流量，就好像 “0.9” 真的代表 90% 的可靠性评估一样。它就像一个用螺栓固定在仪表盘上的压力表，但玻璃后面其实什么也没连。

这篇文章讨论了两个没人定价的成本：生成置信度字段本身的单次请求税，以及信任一个未校准的数字来做路由决策所带来的更巨大的成本。

AI 功能的上线决策会议（go/no-go meeting）表面上是一个数据驱动的仪式。工程团队会带来一系列评估数字——评测专家分数变化（judge score deltas）、切片准确率（slice accuracies）、相对于基线的回归百分比（regression-against-baseline percentages）——然后由与会者做出决定。这看起来非常严谨。但通常并非如此。

一句话概括这种失败模式：有能力解读评估切片权重的人没有决策权，而有决策权的人看不懂切片。产品经理（PM）主导发布决策。工程师掌握数字背后的含义。在这两者之间存在着翻译鸿沟，谁在会议上表现得最自信，谁就能填补这个鸿沟。

问题的征兆在于，“87% 准确率就发布”和“87% 准确率不发布”都可以基于同一份评分卡找到依据，这取决于你更看重哪个切片。当同一份数据集支持截然相反的结论，且决定性因素是辞令上的自信而非证据时，你拥有的就不是一个数据驱动的流程，而是一场以电子表格为背景的辩论。

你构建过的每个分布式系统都依赖于一个隐形的假设：超时后的重试是安全的。操作是幂等的，因此如果客户端放弃等待并重新发送，最坏的情况也只是重复工作，并最终收敛到相同的状态。两个 PUT 请求落地同一行。两个 DELETE 请求留下同样的空缺。重试只是伪装成第二次尝试的“无操作”（no-op）。

LLM 调用打破了这一假设，而且是悄无声息地打破。重试并不会重新获取相同的答案 —— 它会采样一个新的答案。当客户端因为响应在传输中丢失而在网络层超时，但提供商实际上已经完成了生成时，重试会产生第二个、不同的答案。现在，对于一个逻辑请求，存在两个不同的输出，而你的技术栈中没有任何部分知道哪一个是权威的。

这并非罕见的极端情况。在模型背后运行超时机制的从业者报告称，即使底层调用最终成功，仍有 5–10% 的请求会触发完整的超时加重试循环。其中的每一次重试都是一次抛硬币，而你的系统从未被设计成去裁定这种结果。