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

一个团队从前沿模型升级到了其更快的后继版本。评估套件（eval suite）全绿。最终答案一致。工具调用的 Schema 完全相同。结构化输出通过了与以往一样的 JSON Schema 验证。他们发布了。不到一天，支持票据就堆积如山：“助手感觉太匆忙了”，“它不再真正思考了”，“感觉不对劲”。产品经理调取了遥测数据，发现任务完成率没有变化。工程团队反复检查了评估和 Schema，没发现任何问题。投诉是真实的，但团队定义的契约——就如团队所定义的那样——依然完好无损。

改变的是流的纹理（texture）。旧模型在调用工具前会停顿 800 毫秒，发出一句“让我查一下……”的前导词，并以每秒约 35 个 Token 的速度输出，在子句边界处有自然的节奏。新模型以每秒 90 个 Token 的速度输出，从不停顿，且完全跳过了前导词。这些都没有出现在任何文档记录的契约中。但所有这些都是不可或缺的“承重”部分。

这就是海勒姆定律（Hyrum's Law），而流式传输（streaming）让它的表面积变得巨大。系统的任何可观察行为都会被某人所依赖——而流式 AI 界面暴露的可观察行为远比团队意识到的要多。

在过去的二十年里，制约理论（Theory of Constraints）在软件交付中的答案始终如一：瓶颈在于编写代码。我们围绕这一假设构建了一切——结对编程、IDE 自动补全、更快的 CI、更小的微服务，所有这些都是为了让更多的代码通过固定宽度的审阅管道。接着，编程 Agent 出现了，管道的生产端拓宽了 5–10 倍，而审阅管道的宽度却纹丝不动。一位过去每周提交 3 个 PR 的资深工程师，现在正监督着一群在一个下午就能提交 30 个 PR 的智能体。团队的交付速度不再取决于编写代码的速度，而是取决于人类阅读代码的速度。

这并非未来的问题。据测量，在某些样本中，PR 审阅时间的中位数同比增长了 441%，并且在未经任何审阅的情况下就被合并的 PR 增加了 31%——这并非出于政策规定，而是因为审阅者已经放弃了跟上进度。Stripe 每周交付超过一千个由 Agent 生成的 PR。在一项基准测试中，特性分支（feature-branch）的吞吐量同比增长了 59%，而主分支（main-branch）的吞吐量却下降了 7%——代码正在被编写，但没有被发布，因为它们卡在了审阅环节。

一个在你的评估集（eval set）上得分 92%，但在真实生产流量中得分 60% 的提示词（prompt），并不是一个有 bug 的提示词。它是一个评估集在结构上无法发现 bug 的提示词。这种差距并非噪声，而是针对那些与提示词设计意图共享语域（register）、长度分布、语言和礼貌程度的示例进行优化的结果——而这些示例正是由编写评估案例的同一个意图所创作的。

真实用户不会配合你的设计意图。他们会发送三个词的片段、十二个段落的文章、作为问题粘贴的代码块、省略冠词的非正式语域、添加敬语的正式语域，以及你的 few-shot 示例从未涉及的语言查询。这些都不是攻击性的，这只是输入分布（input distribution）。如果你的评估集是由编写提示词的同一个人策划的，那么它几乎肯定与这种分布毫无相似之处。

缩小这一差距的学科不是“更多评估”，而是一种不同类型的评估——一个压力矩阵（stress matrix），它刻意改变你策划的集合中保持不变的维度，并对退化曲线（degradation curves）进行评分，而不是单一的准确率数字。称之为提示词卧推（prompt bench press）：你不是在测试提示词能否完成工作，而是在测试随着输入变得更难，它是如何失败的。

周五下午，一封客户成功（customer-success）邮件发了过来：“德国用户的模型效果变差了。”团队打开评估仪表板，评分没变，p95 延迟也很正常。配置中的模型名称还是三周前发布的那一个。一切都没变。但其实有些东西变了。上个迭代中，美国的端点悄悄上线了新一代模型，而欧洲的端点由于供应商还没完成地区性的分阶段发布，仍在使用旧版本。而位于两者之前的负载均衡器，则在团队的所有仪表板上掩盖了这一差异。

这就是所谓的区域性模型发布博弈。你的“单一模型”抽象并不是单一的。当供应商跨大洲分阶段发布时，它就开始分化了——而在大多数年份、对大多数供应商而言，这种情况在大多数时间里都在发生。当这种情况发生时，客户端 SDK 中的版本字符串并不会改变。你的追踪（traces）看起来一模一样。你与供应商签订的合同也没有做出其他承诺。而你赖以捕捉行为回归的评估套件，几乎肯定运行在某个地区的 CI 机器上，并访问地理位置最近的端点。

打开任何上线超过一年的 AI 功能的生产环境配置，你会发现一个考古挖掘现场。temperature: 0.7 是因为有人想让演示看起来不那么机械。top_p: 0.85 是因为一个客户抱怨输出太普通。frequency_penalty: 0.4 是因为 2024 年有那么糟糕的一周，一个现在已经退役的模型一直在重复自己。这些决定都没有记录。它们都没有针对当前的基座模型进行重新测试。它们在每一次请求、每一次评估、每一次 A/B 测试中运行，塑造着自原始工单关闭以来再也没有人会有意识选择的行为。

这就是采样漂移（Sampling Drift）。它是由于权宜之计而进行的采样器微调的缓慢积累，这些微调最初的理由已经消失，而其效果却在不断叠加。你配置中的数值并不是经过“调优”的——它们是过去事故的化石记录，被缩放到了你当前的流量规模。

它之所以不可见，是结构性原因造成的。你运行的每一次评估都是针对当前的采样配置进行评分的，所以头条数据看起来总是没问题。当 Temperature 值比基座模型落后两个版本时，不会触发报警。也没有日历邀请会提醒你“在本季度重新网格化采样参数”。这种衰减是无声的，直到有人运行了一个干净的实验，发现一个质量提升、Token 减少，或者两者兼而有之的机会，就摆在眼前，且不需要任何工程成本。

当同一个模型负责编写需求、实现代码并编写用于验证正确性的断言时，“所有测试通过”不再是功能正常工作的证据，而仅仅证明了模型是内部一致的。这是两回事，而这种区别正是编写测试的初衷。

我们通常对测试套件的理解是，它们提供了“第二意见”。作者带着一种对需求的心理模型编写代码，而测试编写者则带着略有不同的心理模型编写断言。这两个模型不一致的地方，往往就是 Bug 潜伏之处。这种说法的前提是测试编写者与代码作者拥有不同的认知视角。如果去掉了视角的差异，测试套件就不再携带关于正确性的任何独立信息——它只携带关于一致性的信息。

一名 PM 用英文写了一份功能规范 (feature spec)。一名工程师将其翻译成带有惯用 LLM 模式的系统提示词 (system prompt) —— 思维链 (CoT) 脚手架、输出格式强制，以及一些涵盖规范中从未提到的失败模式的避险条款。一位评估 (eval) 作者打开同一份规范，冷读一遍，并根据自己的理解编写 JSON 测试用例。三周后，这三个产物各不相同，没人能说清楚一个回归到底是提示词的 bug、规范与实现的差异，还是从第一天就写错的评估。

这就是规范翻译税 (specification translation tax)。传统软件也有这种问题 —— PRD 与代码之间、代码与测试之间的差距 —— 但编译器和类型系统缩小了这种差距。AI 功能没有这种兜底保障。提示词是系统实际阅读的文档。评估是没人签署的合同。规范是没人执行的意图描述。每一项都是将同一意图翻译成不同的媒介，如果没有双向的一致性，行为就会通过那个最容易编辑的产物泄露进来。

研究跨语言话次转换（turn-taking）的语言学家们得出的结论惊人地一致：日常对话中说话者之间的间隙大约为 200 到 300 毫秒。任何更长的停顿都会被解读为犹豫、疏远或顺从；任何更短的停顿则会被视为打断。这个窗口是如此狭窄，以至于人类显然在对方说完之前就开始构思回复了 —— 倾听和计划是并行发生的，而非顺序进行。

错过这个窗口的语音智能体并不仅仅是让人觉得有点慢，而是让人觉得“不对劲”。在聊天产品中没人会注意到的 700 毫秒延迟，在语音交互中会让智能体显得迟钝、心不在焉，或者导致用户因失去耐心而打断它。1.5 秒的间隙足以让用户开始重复他们说过的话。满足这一时间预算并非简单的打磨工作 —— 它迫使开发者做出文本智能体从未面临过的架构选择，而这些选择重塑了整个技术栈的构建方式。

一个拥有八年经验的后端工程师加入了你的团队。在一般的代码库中，到第三周他们就能开始交付功能了。但在 AI 层面，他们仍然在私信里问问题，而且你能预测出他们在问哪两位资深工程师。入职三个月后，他们终于被信任可以修改系统提示词（system prompt）了 —— 这并不是因为提示词有多难，而是因为没有人能告诉他们，哪些评估（evals）能捕捉到退化（regression），而哪些会直接放行错误的输出。

这在通常意义上并不是招聘问题或文档问题。AI 代码库带有一种隐藏的领域知识税（domain-knowledge tax），这种税不会出现在代码审查中，不会出现在 README 中，静态分析器也无法察觉。这笔税体现在入职时间、对同一批人的重复提问，以及最终团队悄悄分化为“能动它的人”和“其他所有人”。

打开任何采用固定订阅制的 AI 产品的单用户成本仪表盘。其形状总是一样的：一条长长的、几乎无法产生显著影响的扁平尾部，以及顶部一个细长的尖峰—— 5% 的账户消耗了 80% 的推理预算。这个尖峰对处于两端的两类用户都是隐藏的。重度用户不知道自己在补贴其他人——他们以为价格就是那个价格。轻量用户不知道他们可以要求更多——他们以为限制就是那个限制。

仪表盘始终保留在工程团队内部，因为产品经理担心暴露它会吓跑用户。但事实恰恰相反。隐藏成本的团队最终会推出无声的限流、隐藏的模型降级以及导致用户认为“这产品坏了”的答案截断。而那些将成本作为刻意的 UI 界面（而非后台管理页）展示出来的团队，则能将同样的成本上限从流失驱动因素转变为商业化杠杆。

这就是 AI 钱包。它不是一个账单页面，而是一个产品原语（product primitive）。

我见过的企业级 LLM 最有效的对抗性提示（adversarial prompt）并非来自红队、安全研究员或提示词工程师。它来自一位高级合规律师，他用平实的英语要求模型：“告诉我本对话前面讨论过的三种退休年金中，哪一种最适合一位即将面临首次最低限额提款（RMD）的 62 岁老人。”模型给出了一个自信、周全且格式精美的建议。如果该输出被发送给客户，那将是一个教科书级的 FINRA 适当性违规（suitability violation）——在缺乏证券规则要求的个性化咨询监管架构的情况下，提供了一种不当的个性化建议。

这位合规律师在短短 4 秒钟内就发现了这种失效模式。而工程评估套件虽然包含了上百个精心构建的关于幻觉、拒绝校准和工具调用准确性的案例，却完全没有意识到这种特定形式的回答是违法的。不是质量低。不是幻觉。而是违法。当时公司的流程是让她在 Google 文档中阅读输出样本并撰写备忘录，而不是将测试用例签入回归套件。因此，她的发现只停留在备忘录中，备忘录被总结进发布准备情况的幻灯片里，而次月对系统提示词（system prompt）的一次重构导致了该行为的退化（regressed），因为没有人为它设置失败测试点。

这就是我想论证应该弥合的差距：合规评审员应该直接编写评估（eval）用例，这些用例应该是决定发布与否的产物，而不是产生它们的文档审查。

一名用户向你的购物智能体询问“150 美元以下、足弓支撑良好的跑鞋”。智能体尽职地返回了 12 个选项，但它们表现为单个聊天气泡中一长串超出视口的子弹点文本。用户滚动屏幕，找不着看到哪了，然后输入“只显示 Asics”——此时，你的智能体重新运行了整个搜索，而不是过滤它已经拥有的结果集。三轮对话后，用户正在通过一次一个提示词来发明一种查询语言，而你的产品感觉就像一个披着聊天气泡外壳的命令行。

这是我不断看到团队在交付时陷入的失败模式。他们在用户实际上想要的分面搜索（faceted-search）产品之上构建了一个聊天产品。模型没问题。检索也没问题。问题出在 UI 上，它的形态不适合这项任务。

我能给出的最简短的结论是：聊天是一种输入模态，而不是输出模态。智能体的职责是将用户意图转化为结构化查询。一旦结果集超过三项，正确的做法是渲染 UI，而不是继续说话。