720 篇博文 含有标签「llm」

一个 RAG 智能体用一段简洁的文字和一条引用回答了客户的监管问题。验证层获取了该 URL，看到返回码为 200 OK，勾选通过并发布。六个月后，合规性审计调取了对话记录，点击同一个链接，却发现页面现在的内容与智能体引用的完全相反。URL 没问题，对话记录中的引用也没问题，但两者不再匹配。客户的合规官询问智能体是否捏造了引用，而团队无法证明它没有捏造，因为证明该 URL 过去内容的唯一证据就是智能体自己声称它说过什么。

这不是通常意义上的幻觉。模型检索到了真实内容，忠实地提取了真实的句子，并给出了一个至今仍可解析的真实 URL。世界上任何链接检查工具都会认为这个引用是有效的。然而，审计依然失败了，因为验证层衡量的是错误的属性。可访问性（Reachability）并不等同于忠实度（Fidelity）。URL 只是指向受他人编辑控制的可变文档的指针，一旦文档发生变化，每一份引用它的对话记录都会变成一个随时可能爆发的“幻觉报告”。

用户提交了一个问题。你的模型生成了一个答案，这个答案以一种非常具体的方式“自信地出错”：格式完美，推理结构严密，并且出现了一个特定的限定词——这个限定词完全不适用于这个问题——它出现的位置，恰好是你系统提示词（system prompt）中示例三出现类似限定词的地方。这既不是幻觉，也不是提示词注入。模型只是精确地执行了示例教它的操作，尽管这些示例原本并非为了涵盖这个问题。

这就是 Few-Shot 提示主动诱发的故障模式，而大多数评估套件（eval suites）在结构上对此是视而不见的。你的示例并不是“优秀范式”的中立演示。它们是判例法（case law）。模型通过表面 token 选择最匹配的项，并将该先例——包括其限制条件——应用到眼前的任何案例中。

JSON Schema 验证的是输出的形状（shape）。它并不验证该形状内数值的含义。在长达 9 个月的时间里，你的 AI 流水线产生的每一条输出都顺利通过了校验，监控显示 Schema 合规率为 100%，你的团队也理所当然地认为符合 Schema 的响应在契约层面就是正确的。接着，一次模型升级发布了，每一条输出依然能通过校验，但你的 Slack 告警频道却在一夜之间从每天 50 条消息飙升到了 800 条。

Schema 没有出问题，出问题的是其内部数值的分布。这就是大多数 AI 团队在生产环境中发现的鸿沟：JSON 契约是一个类型系统（type system），而非行为系统（behavior system），而下游消费者一直依赖于某种契约从未被要求强制执行的数值分布。

在事故复盘报告中，最昂贵的代码行反而是没人写出的那一行：一个字段缺失的 200 OK。原本应该将难题上报（Escalate）给更强模型的路由，在整整六周的时间里上报的流量为零。成本看板在欢庆，质量看板却在下滑——但仅限于那组被现有评估集低估的难题切片。直到客户投诉系统以前能正确处理的特定问题时，一切看起来都还像是场胜利。

起因是协议栈上层的一个响应结构变化。供应商的中级方案取消了逐 Token 的 logprobs，这在发行说明中被称作“特定层级的特性对等调整”。客户端收到的仍是有效的 JSON，HTTP 状态码依然是 200，响应中的模型标识符与请求中的模型标识符也完全匹配。唯一的变化是，路由用来做上报决策的字段消失了，而一年前在一次事故中添加的防御性默认设置，悄然变成了每个请求的生产环境默认行为。

你的事故时间线显示没有部署。你的代码没有变。你的流量组合没有变。你的提示词也没有变。然而，你的 p99 输出长度在一周内翻了一番，下游渲染层开始截断响应，而且在流量没有请求更长答案的情况下，你的输出 Token 账单增长了 38%。这种变化是真实的，回归是可以衡量的，但你的版本控制系统中没有记录——因为发生变动的值是你的代码从未发送过的。

供应商提高了一个隐式默认值。发布说明将其归类为“改进的长内容表现”。有问题的参数是 max_tokens，你的应用程序从第一天起就忽略了它，因为文档中记录的默认值很慷慨，而且你的输出很少接近这个值。默认值从 4096 移动到 8192，以适应供应商新模型中更长的推理过程。无论你是否想要，你的应用程序都获得了新的默认值，因为缺少参数本身就是一种配置选择——而供应商拥有更改其背后值的权利。

这种故障模式下，供应商侧的“无操作”（no-op）发布会作为行为变化、成本变化和用户体验（UX）变化同时在你的系统中传播，而你团队唯一的诊断信号是月底寄来的账单。

你的采购团队在上个季度续约了推理合同，并带着一丝自得地注意到，引用“HumanEval pass@1 达到 84%”的质量条款已被供应商最新的模型卡（model card）轻松超越，现在报告的数值是 87%。提高了三个百分点。条款已达成。合作关系很稳健。与此同时，你推理团队自己的回归测试集——那个真正运行你产品所依赖的任务的测试集——显示自模型更新发布以来，在留出法评估案例上出现了 2% 的下降。这两个数字都是真实的，但合同里只写了其中一个。

这就是当营销产物在法律文件中承重时的情况。模型卡上的基准测试数字只是测量结果的标题；而产生该数字的方法论则是附录中的一个注脚，合同审查链上的任何人都不会去读它。当供应商更改方法论时——从贪婪解码（greedy decode）切换到三选一采样（best-of-three sampling），添加结构化输出系统消息，或者更换提示词模板以匹配模型新的聊天微调——数字的变动与你的实际流量毫无关系，而与数字的计算方式息息相关。你的合同条款引用了该数字，而对方则掌控着产生该数字的协议。你签署了一个对方可以在不违约的情况下修改其含义的条款。

客户支持团队升级了一个问题：“你的助手以前能正确处理退款资格问题。但上周开始出错了。”值班工程师调取了对话记录，在开发账号中使用相同的模型标识符回放了完全相同的提示词（prompt），得到了正确的回答，于是以“无法复现”为由关闭了工单。两周后，另一名客户提出了同样的投诉。工程师再次在同一个开发账号中进行回放，结果依然正确。团队开始归咎于没人做过的提示词更改。

请求中的模型标识符从未改变。响应字段中的字符串与请求字段中的字符串匹配。评估套件在六周内一直保持绿色。生产流量使用的模型权重与评估套件使用的模型权重是两套不同的集合，而且在该账号的整个生命周期中一直如此——直到过去这六周，它们变成了同一套权重，而团队注意到这一点仅仅是因为客户先发现了。

用户联系支持：“助手让我注销服务来更新地址，这太疯狂了。”你的团队开启了故障处理程序，询问对话 ID，将其放入追踪（tracing）UI，结果得到了一句礼貌的 “未发现此 trace 的 spans”。24 小时的保留窗口在一小时前刚刚关闭。尾部采样器（tail sampler）判定这次对话是常规成功，因为响应是一个语法正确的 JSON 对象，返回状态码 200，耗时 1.4 秒。根据你的采集器所能理解的所有信号，什么都没发生。

模型返回的一句话毁掉了一段客户关系，而你的可观测性流水线却将其归类为无事发生。这不是采样器的 bug。采样器完全按照你的配置执行。问题在于，你编写的策略是为“请求-响应”的世界设计的，在那个世界里，“成功”与“值得保留”几乎是同一回事，而你未经修改就将其移植到了一个并非如此的系统中。

我最近接触的一个产品团队针对回复人格设定（简洁、详尽、对话式）进行了一项为期三周的 A/B 测试，覆盖了所有用户群组。系统提示词描述了这三种设定，并要求模型选择最匹配用户的那一种。当他们打开数据集编写分析报告时，一个数字让他们愣住了：“详尽”组占据了 91% 的流量。另外两组的比例小到几乎可以忽略不计。

他们的实验平台没有标记任何异常。没有触发任何警报。流水线完全按照他们的指令运行。三周所谓的“多人格测试”产生了一个只能告诉他们关于“详尽”信息的数据集。另外两组样本太少，根本无法进行任何统计推断。

房间里的第一直觉是提示词需要改进——更好的指令、更清晰的人格区分、为对话式场景提供更刻意的示例。如果是在十年前基于规则的路由器中，这个诊断是正确的。但对于模型来说，它是错误的。提示词不是变量，路由器才是。

一个仅针对入站流量运行的 PII 脱敏器就像是安装在管道错误一端的单向阀。它在用户提交的姓名、电子邮件和账号进入日志之前拦截它们。但它对模型的输出无能为力 —— 而现在，模型正是在输出端积极地组合可能包含这些相同标识符的文本，这些内容可能源自 RAG 检索、工具返回、对话历史或用户从另一个租户数据中粘贴的内容。我观察过每一个上线了输入端脱敏器的团队，他们的待办事项中都有一个标记为“输出端对齐”的后续任务。大多数这类任务永远不会关闭，因为在长达六个月的时间里，没有任何事故暴露出这个缺口。六个月后，该任务经过多次重新排序，看起来更像是一个功能需求，而不是缺失的一半安全控制手段。

失败模式是恒定的：输入端脱敏被视为标准的控制手段，因为它的工程问题更简单，审计故事也更容易讲。你编写了一套正则表达式，运行了一个标注好的基准测试，证明了在固定语料库上的精确率和召回率，在特性开关后上线了它，安全评审也将其接受为 PII 边界。输出端则完全没有这些优势。模型的响应是生成性的，表面积是无限的，而且测试方法论 —— “在无限多的上下文中它不应该说什么” —— 在结构上比“我们应该从已知输入中剥离什么”要困难得多。因此，上线入口端的团队将出口端视为未来的工作，而这个未来永远不会到来，直到有客户举报另一个客户的电子邮件出现在他们的对话记录中。

评测集（eval set）是一个文件。但它也暗含了对 AI 功能用途的理论定义。这两者并非一回事，混淆它们的团队建立了一个质量网关，而其校准完全依赖于单个人的工作记忆。当那个人离职时，文件留下了，但那套理论也随之而去了。

这是你在组织架构图中看不到的失败模式。你规划了一个提示工程（prompt engineering）角色。你雇佣了一个优秀的人才。他们发布了 v1 版本的提示词，审视了简陋的基准测试，并将其重写为内容丰富的东西——一个失败模式分类法、每个类别的权重，以及一套能够消除边缘情况歧义的标注指南（rubric）。评测集变成了“该模型是否好到足以发布”的契约。六个季度后，你发现这份契约除了编写它的那个人之外，其他人都看不懂。

你的平台团队出于成本考虑采用了供应商的 "auto" 模型标识符。上线后的第一个仪表盘数据非常有说服力：在每周 eval（评估）中没有出现可衡量的质量下降，支出却减少了 34%。三个月后，在你最短、流量最高的功能点上，客户满意度已经连续两个季度下滑。一项由产品主导的调查最终将这种回归追踪到了一个工程团队无人触及的模型标识符上。代码里写的是 "auto"。而供应商一直在重新定义 "auto" 这一路整过程中的含义。

教训并不是自动路由不好。教训是，"auto" 是一个移动的目标，其分布随供应商的经济效益而漂移，而你的 eval 的代表性是供应商优化与你的产品质量之间唯一的屏障。如果 eval 与流量不匹配，那么你所庆祝的折扣，其实是从一个无人审查的质量斜坡中支付的。