484 篇博文 含有标签「llm」

大多数团队通过在系统提示词中加入一句话来处理弃权（abstention）问题：“如果你不确定，就说你不知道。”模型偶尔会遵守，但经常不遵守，而且这种失败模式是不对称的。一个自信的错误答案会以全速发布——它直接落入用户手中，在 Slack 讨论串中被引用，在下游摘要中被采纳。而一个诚实的弃权则会触发客户成功（CS）升级，因为用户期望智能体处理请求，而现在必须有人解释为什么它没有处理。六个月后，团队已经了解到哪种失败的发布成本更低，而那个名义上控制弃权的系统提示词修改，已经被悄悄地调整为倾向于顺从，而非诚实。

解决这个问题的准则不是寻找更好的措辞。而是要认识到，弃权是一个路由决策，而不是一种提示词模式。它理应拥有一个一等公民级别的输出通道、自己的 SLO、自己的评估套件，以及在系统拓扑中的独立位置——位于提示词之外，可以被测试、维护和扩展。

账单在 3 月份寄达。仅追踪（traces）一项就花费了 8.1 万美元，而 11 月时这一数字仅为 1.2 万美元。团队在 10 月份启用了全量 Agent 追踪，理由是可见性越高越好。到了第一季度，可观测性成本的增速已经超过了推理成本——而当生产环境真正出现性能回归（regression）时，包含故障的追踪记录却被淹没在两千万个无人问津的成功 span 中。

错误并不在于决定进行埋点。错误在于将请求追踪（request-tracing）的心智模型引入了一个行为完全不像传统请求的工作负载中。

一个典型的 Web 请求会生成一个包含少量子节点的 span 树：处理器、数据库调用、缓存查找、下游服务。而一个 Agent 请求生成的树包含 5 个 LLM 调用、3 个工具调用、2 个向量查找、中间草稿（scratchpads），以及一个重新审视其中 3 个步骤的规划器。同样适用于 API 网关的采样策略——头部采样（head-sample）1%，保持其余部分的代表性——在 Agent 场景下会产生一个追踪存储库，其中中位数追踪是拥有 200 个 span 的怪物，长尾效应才是唯一关键的部分，而你发现故障的频率与你花钱的频率完全无关。

浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。

这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。

一位平台工程师修改了公司“品牌风格”序言中的开场白——这是用于统一所有面向客户的助手语气的一行代码。这项改动通过 feature flag 发布。到了周二，搜索团队的相关性退化指标激增，支持机器人的评估通过率下降了四个百分点，入职引导 Agent 的重试率翻了一倍。这些团队中没有一个动过自己的代码。他们都没有收到任何预警。平台工程师对这一切一无所知，因为没人收到过类似的警报：“你的修改刚刚搞坏了三个下游功能。”

这就是定义 AI 团队成立第二年后的典型失效模式。第一年，每个团队都在各自的角落闭门造车。第二年，这些角落开始共享产物——这里一个提示词片段，那里一个种子评估集，或者一个被当作协议复用的工具 Schema。当这种共享变得隐性时，AI 功能之间的依赖图就变得不可见了。你现在拥有的是一个没人能叫出其边缘名称的分布式系统。

解决这一问题的方法论（discipline）并不是一个新平台，而是绘制这张图。

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 Opus，看看能不能解决。”四十分钟后，评估通过率回升了，团队关闭了工单，而该路径上的推理账单悄然翻了三倍。六周后，同样形式的回归出现在另一个路径上，并采用了同样的修复方法。你的团队刚刚训练出了一种巴甫洛夫反射：质量回归 → 增加算力。更大的模型是你的技术栈中最昂贵的调试工具，而你现在却首先想到它。

问题不在于更大的模型没有帮助。它们确实有——有时甚至很大。问题在于，更大的模型是一种绝对占优的“掩盖”策略。当提示词指令冲突、检索返回了过时的块、工具描述被误读，或者评估集没有覆盖失效的分布时，更强大的模型会绕过这些故障而不修复其中的任何一个。下一次回归仍具有相同的根本原因，账单已经复加，而底层系统变得更加脆弱，而非更加稳健，因为升级带来的缓冲空间让所有人都不再去探究底层逻辑。

在 1 月下旬的一个周一早上，仪表盘发出了第一次回归预警。支持助手的质量得分一夜之间下降了 3 分。周末没有发布 Prompt 变更。没有更换模型。评估套件——团队在 6 个月前构建的一个包含 800 行数据的精选黄金集 (gold set)——也没有任何变化。有人开了一个故障单 (incident)。

经过两天的二分定位 (bisecting) 之后，得到的答案平淡无奇且是结构性的。那是美国国税局 (IRS) 开启当年税务申报后的第一个工作周一。一半的入站查询已从“我的薪水到账了吗”变成了“我该如何申报来自支付 App 的 1099-K 表单”。在夏季采样的评估集对 1099-K 毫无头绪。模型并没有变差。是客户变了。评估标准是针对一个已经不存在的客户群进行校准的。

这种模式在每一个拥有季节性用户的产品中每季度都会重复出现——报税季的金融科技、季度末的销售工具、开学季的教育产品、退货季的电子商务、订票季的旅游产品、投保季的医疗保健。将“评估集视为固定资产”是一种舒适的抽象，但在一个无人更新的日程表上，这种做法是错误的。

黄金评估集的通过率为 94%。模型在本季度已经升级了两次，提示词修改了 11 次，工具库增加了 4 个，仪表盘依然是一片绿色。然而，一名销售工程师转发了一份对话记录，显示智能体（Agent）自信地将客户引导至一个两个月前就已停用的工作流；与此同时，支持团队负责人悄悄开启了一个讨论组，询问为什么在评估流水线显示没有回归的情况下，满意度评分已经连续下滑了六周。黄金集并没有撒谎。它只是在用上个季度的产品标准来衡量这个季度的流量，而除此之外没人要求它做别的事。

这是评估系统最难察觉的一种失效模式，因为本该检测质量回归的工具本身就是误报的源头。通过率是针对集合中的项目计算的；集合中的项目是根据某个时间点的使用快照精心筛选的；用户的使用方式已经演进，但通过率依然保持“干净”。团队信任绿色的仪表盘，发布了另一个模型升级，几个月后才发现生产环境的分布与评估集所衡量的东西已经南辕北辙，而这种状态持续的时间超出了所有人的想象。

解决方法并不是提高黄金集的更新频率。更新频率是一个错误的调节旋钮；正确的旋钮是拥有第二个针对不同时间窗口校准的工具，以便在用户发现问题之前，通过两者之间的分歧来暴露漂移。这第二个工具就是影子评估（Shadow Eval）—— 一个从当前生产流量中持续重建的并行评估集，它与黄金集并行运行，其明确的任务就是与黄金集唱反调。

一名开发者在 9:00 打开 IDE 的 Copilot，在早会前问了三个问题，然后一直开会到 11:30。聊天面板仍然打开着，对话依然可以滚动查看。模型在两个半小时内没有生成一个 token。然而，这个无人问津的会话整个上午都在悄悄地产生费用。KV 缓存被占用。提示词缓存（Prompt cache）通过定期 ping 保持活跃。对话状态保存在热存储（hot store）中。追踪流水线每跳动一次心跳就写入一行记录。模型提供商预留了并发槽位。乘以一万个席位，这笔账单是真实存在的。

这就是“闲置智能体税”（idle agent tax）。它是你推理预算的一部分，用于支付用户并未使用的容量。由于大多数工程仪表盘是为无状态 API 构建的，因此它在仪表盘上是不可见的。一个请求进来，一个响应出去，容器关闭。搞定。智能体产品在两年前就打破了这一模型，而大多数团队尚未根据这一变化重新调整其架构的成本模型。

我上个季度合作的一个团队在周二凌晨 2:14 向生产环境推送了一个回归错误。值班警报触发了，因为其摘要代理（summarization agent）下游的 JSON 解析器以“尾随逗号错误”拒绝了二十分之一的响应。模型没变。提示词（prompt）没变。评估套件在前一天晚上的通过率为 96.4%，稳稳高于 95% 的准入门槛。改变的只是 package.json 中的一行：模型提供商的 SDK 从 4.6.2 升级到了 4.6.3。补丁更新（Patch bump）。由依赖机器人自动合并。发布说明里写着“内部清理”。

所谓的“内部清理”是一个收紧的 JSON 模式解析器，它删除了一个宽容的后备路径，而这个路径此前一直在默默修复模型工具调用输出中反复出现的尾随逗号怪癖。模型的行为没有改变。但 SDK 对该行为的解释改变了。团队的评估套件从未发现这个回归，因为评估套件运行的 SDK 版本与依赖机器人刚刚推送的版本不同。

这就是 LLM SDK 升级税，它是当今生产环境 AI 中最隐蔽、代价最昂贵的故障模式之一。SDK 不是被动的传输工具。它是你提示词行为的积极参与者，而那些在没有评估的情况下升级 SDK 的团队，实际上是在进行一场伪装的模型发布。

打开任何交付 LLM 功能超过一年的团队的提示词库，你都会发现同样的情况：每个提示词都有三个略有不同的版本。一个是喜欢 Sonnet 及其指令遵循能力的工程师调优的。一个是由于延迟预算而切换到 Haiku 的工程师重写的。还有一个属于那个只在 Opus 上运行且从未迁移过的原型。每个版本都有略微不同的系统消息、不同的工具目录描述方式、不同的格式引导 —— 而且没有人追踪它们是如何产生漂移的。

""

这不是卫生问题。而是一种在每次模型升级时都会累积的协作税，它正在悄悄破坏你的评估套件与线上流量之间的关系。词库本应是共享资源。而在实践中，每个功能交付时都使用了作者最后测试的版本，评估套件运行的是评估作者偏好的版本，而路由层则根据成本而不是根据哪个变体实际通过了线上评估来选择。

那些没有察觉到的团队，已经在付出代价了。

成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。

没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。

账单在月初寄到，金额是你电子表格预测的三倍。没有人推送过系统提示词（system prompt）的更改。仪表盘显示请求量持平。p95 延迟看起来很正常。每个正确任务消耗的 token 比例（token-per-correct-task ratio）也没有变化。然而，你却欠了推理供应商额外的四万美元，而可观测性技术栈中唯一暗示了原因的信号，是一个大多数团队从未设置过报警的指标：缓存命中率（cache hit rate）。它在计费周期的第二周，也就是某个周二的太平洋时间上午 9:47，从 71% 掉到了 18%。而那个时刻，正是你最大的租户的客户成功团队为两百名新用户启动了一场协调一致的入驻活动。

欢迎来到提示词缓存抖动（prompt cache thrashing）—— 这种多租户故障模式本该在十年前就被 SaaS 策略手册消除，如今却通过推理供应商的共享前缀缓存（shared prefix cache）从后门溜了回来。供应商的缓存是在你组织的流量中共享的。无论你是否愿意，你的租户都在共享这个缓存，而一个租户的前缀形态在夜间发生改变，就可能逐出（evict）所有其他租户的单位经济效益（unit economics）所依赖的前缀。对于那些没做任何改变的租户来说，账单也会激增。财务部呼叫工程部，工程部指着显示一切正常的仪表盘，因为仪表盘并没有测量出那个已经损坏的环节。