778 篇博文 含有标签「llm」

我见过的每一个发布过“小规模”输出 Schema 变更的 AI 团队，都经历过同样的一周。有人在系统提示词（system prompt）中重命名了一个字段——比如将 summary 改为 tldr，或者工具目录中增加了一个必填的 confidence 参数——结果下一次 CI 运行就在 800 个与该变更毫无关系的 Eval 用例中亮起了红灯。提示词的 diff 只有 15 行。而 Eval 的 diff 却变成了一个为期四天的迁移项目，且无人规划、无人负责，也从未包含在预算之内。

这就是 Eval 迁移税（Eval Migration Tax）。这是任何路线图都没有考虑到的维护成本，它以发布延迟的形式支付，而这些延迟往往被归咎于“不稳定的测试”（flaky tests），而非真正导致它们的架构选择。大多数团队在意识到这一模式之前已经支付了数年的代价，因为每一个单独的事件看起来都像是普通的日常损耗。只有当你统计一个季度内用于迁移 Eval 的工程小时数，并发现它们超过了用于改进 Eval 本应衡量的模型行为的时间时，这种复利效应才会显现。

大多数 AI 功能发布时只有两种状态：正常工作和彻底挂掉。模型调用成功，功能就有响应；模型调用失败，用户就会看到错误。这相当于在构建 Web 服务时没有负载均衡、没有缓存，且只有一个数据库副本——在出事之前，它在技术上是可行的。

不同之处在于，工程师在 20 世纪 90 年代就学会了数据库弹性模式，并将其深刻内化。 AI 功能的弹性仍处于通过一次次生产事故进行艰难探索的阶段。一家支付处理器在一次时长 4 小时的 AI 停机中损失了 230 万美元。一家物流公司在其路由模型宕机时，错过了 30,000 个包裹的交付窗口。这两起失败都有一个共同的根本原因：当主模型不可用时，没有可以回退的方案。

你的 AI 功能上线时带有一个质量门禁：每个回复都会经过一个 GPT-4 提示词，根据帮助性、准确性和语气进行评分。绿色分值不会触发报警。仪表盘显示通过率为 97%。与此同时，你的支持工单翻了一倍。

问题出在结构上。你使用了与生成输出相同类型的系统来验证这些输出。当生成器产生一个听起来很合理的虚假事实（幻觉）时，基于相同互联网文本分布训练的评判模型会认为这个幻觉是可信的并予以通过。两个模型共享相同的盲点。你的质量门禁衡量的是置信度，而非正确性。

大多数生产环境中的 Agent 故障看起来像是模型错误。Agent 在会话开始时能正确响应系统提示词——维持正确的语气，遵守工具约束，遵循定义的工作流程。然后，在第 30 或 40 轮左右，情况悄然发生变化。Agent 开始在本应直接的地方含糊其辞，调用了它被告知应避免的工具，甚至推翻了它在 15 轮前做出的决定。系统提示词没有改变，但 Agent 的行为已经变了。

这就是人格漂移：由于 Transformer 对越来越深埋的上下文的注意方式，Agent 实际行为与其原始系统指令之间产生的渐进式偏差。研究对此进行了精确量化——经过 8–12 轮对话后，人格自一致性指标下降超过 30%。单轮 Agent 的任务准确率约为 90%；在运行相同任务的多轮 Agent 中则降至约 65%。这 25 个百分点的差距并非一个可以通过调整提示词来解决的模型质量问题，而是注意力机制在长序列上工作方式的架构特性。而大多数团队只有在上线某个功能、该功能悄无声息地降级数小时后才被用户发现时，才意识到这个问题。

一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。

大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。

确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。

它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。

一个用户问你的助手，“这季度我们的退款政策有什么变化？”系统返回了一个当前退款政策的、格式良好的自信总结。用户点点头，关闭聊天，并根据一个与他们提出的问题完全无关的信息采取行动。你的评测套件（eval suite）没有捕捉到这一点。你的忠实度指标（faithfulness metric）没有标记它。检索看起来很完美——它返回了高度相关的分块（chunks）。合成看起来也很完美——它引用了它使用的每个分块。唯一的问题是，问题是关于 变化 的，而你的索引没有变化的概念。

这是向量相似度检索无法通过调优修复的失败模式。同一文档的两个版本具有几乎相同的嵌入（embeddings）——这就是好的嵌入所 做 的，它们将语义等效的文本折叠到同一个邻域中。因此，当你问“什么改了”时，检索器返回其中一个版本，LLM 总结该版本，而答案在沉默中成为了“什么都没变”的幻觉。用户无法察觉。你的评测集可能也无法察觉，因为你的评测集是围绕“什么是 X”的问题构建的，而不是“现在 X 有什么不同”。

某个团队此刻正看着他们的 LLM 月支出以 10 倍速度增长，而 p99 延迟徘徊在四秒左右。工程师们增加了更多重试。重试触发了速率限制。速率限制触发了回退。回退也是 LLM 调用。没有人停下来问：这个功能真的需要实时响应吗？

大多数 AI 产品团队都为"幸福路径"设计架构——用户发消息，模型响应，用户看到结果。同步调用模式是 API SDK 在第一个代码示例中演示的内容，因此它就这样上线了。但生产 LLM 工作负载中有相当大一部分与用户坐在键盘前等待毫无关系。它们是文档增强任务、内容分类流水线、向量嵌入生成、夜间摘要生成和后台质量评分。对于这些工作负载，实时推理是错误的工具——而坚持使用它所付出的代价是真实的金钱、级联故障，以及你要花费数月才能理清的运营复杂性。

当你团队中的初级工程师第一次输入 --update-snapshots 并推送到 main 分支时，你的测试套件就不再是测试套件了，它变成了一份记录稿。虽然 Diff 依然显示为红绿颜色，CI 徽章依然会变为通过，但信号已经悄然反转：测试套件不再告诉你代码是否正确，而是告诉你是否有人费心看过输出。对于确定性的代码，这种风险尚在可接受范围内，因为大多数 Diff 确实是符合预期的。但当网络调用的另一端是一个随机模型时，同样的流程会让每一个 PR 变成一场硬币投掷，让每一位评审者变成一个橡皮图章。

快照测试曾是确定性世界里的一个美妙构想。你记录下上周二 render(<Button />) 的生成结果，断言本周二它会生成相同的字符串。从定义上讲，任何 Diff 都是值得人工核查的行为变更。这种模式在 Jest、Vitest、Pytest、整个 React 生态系统以及一代又一代的 UI 快照扩展中得以幸存，是因为底层契约依然成立：相同的输入加上相同的代码等于相同的输出。但这个契约对 LLM 调用并不奏效。相同的输入、相同的代码加上相同的提示词（Prompt），却会产生不同的字符串——而且这种差异并非 Bug，而是产品按设计正常运行的结果。

查看你的网关重试配置。三次尝试。带有抖动的指数退避。在 5xx 错误和超时时重试。最大延迟限制在几秒钟。这看起来很合理，而且是某人两年前从微服务运行手册中复制过来的。但这正是你的 P99 是 P50 两倍、在服务商发生故障期间 Token 费用激增，以及相当一部分用户在默默流失前盯着 30 秒加载圈的最主要原因。

专为 50 毫秒 RPC 设计的重试策略在面对 8 秒的 LLM 调用时注定会失效。失败的形式不同，每次尝试的成本不同，用户感知到的时间维度也不同。默认设置并不安全，只是让人感到熟悉。大多数团队通过同样的方式发现这一点：在一次事后回顾中，网关日志显示响应成功，而客户的截图却显示 UI 已经卡死。

你的 Agent 代码库中最危险的文件是你一直当作 API 文档来编写的那个。工具注册表（Tool Registry）——即告诉模型存在哪些函数以及它们接受哪些参数的 JSON 或 Pydantic schema —— 不再仅仅是一个 docstring。它是你的授权层（authorization layer）。如果你像大多数团队那样设计它，你就是把万能钥匙交给了大模型（LLM），并称之为优秀的工程设计。

考虑一个典型的工具初步尝试：query_database(sql: string)。初衷是合理的 —— 让模型根据用户的问题制定正确的 SQL。现实情况是，模型现在成了一个不受信任的客户端，拥有连接字符串所指向的任何数据库的无限 DDL 和 DML 权限。系统提示词说“仅在 orders 表上运行 SELECT” 只是一个建议，而不是控制手段。当一个受到提示注入（prompt-injected）的工具结果 —— 比如邮件正文、网页或 PDF —— 告诉模型运行 DROP TABLE users 时，你的授权模型就变成了对模型指令遵循能力的纪律要求。那不是授权。那是祈祷。

看看大多数智能体框架提供的循环原语：continue、return、retry 以及一个硬性终止运行的步数预算。注意缺失了什么。这里有一条表示“工作成功”的路径，一条表示“模型想继续”的路径，还有一条表示“我们耗尽了资金或耐心，于是强行终止循环”的路径。唯独没有一条头等路径来表达“我正在执行的计划是错误的，我想将其丢弃并开始一个全新的计划”。放弃原语（abandon primitive）——即一种让规划器显式、结构化地宣布当前轨迹无望的方式——是智能体循环语法中缺失的动词。它的缺失导致了一类通常被误诊为“模型需要更多推理”的失败。

一个在注定失败的分支上执行了三步的规划器，会不断优化同一个错误的计划，因为循环唯一的出口是成功、重试上一步或耗尽预算。这些路径都不包含“放弃该策略并尝试另一个”。因此，智能体执行了循环所允许的操作：它就地修改计划、再调用一个工具、再请求一次澄清，并在步数预算耗尽前不断收敛到一个非解决方案。当最终撞墙时，用户看到的是一条礼貌的失败消息，而不是问题的答案。这些浪费的步骤所带来的成本是真实的——生产数据表明，智能体系统 5-10% 的 Token 支出都花在了无法产生任何可用结果的重试上，而这一数字主要由长期的“注定失败分支”占据，而非孤立的工具错误。