907 篇博文 含有标签「insider」

你的评估流水线每周会产生 800 条 trace 供人工审核。你的标注人员每周大约有 90 分钟的预算来处理这些数据。他们打开队列，对前三条进行打分，再将其余几条标记为“跳过”，然后就关闭了标签页。你在周一早上盯着看的排行榜，现在只是反映了哪些 trace 碰巧排在了列表顶部，而不是对系统质量的真实衡量。

这不是一个标注问题。这是一个披着质量问题外衣的吞吐量问题，也是评估项目退化最隐蔽的方式之一。Trace 仍在流动。仪表板仍在渲染。数值仍在变动。你没看到的是，你的“人工评分评估得分”的分母已经悄然缩减到了寥寥几项，而这些项是由一个没人刻意设计的排序函数挑选出来的。

确认对话框是 AI agent 工具箱中最廉价的安全层。它由一个字符串、一个按钮和一个回调函数组成。提议增加这一功能的项目经理在散会时，坚信该 agent 现在是安全的。开发它的工程师用一个下午就把它发布上线了。负责审计的合规检查员勾选了通过选项。而那天早上第七次看到它的用户，在眼睛还没读完标题之前，鼠标就已经移到了“确认”按钮上。

不到一周，确认步骤就不再是一个决策点，而变成了一种节奏。Agent 问：“你确定要发送这封邮件吗？”，用户回答“是”，就像别人打喷嚏时随口回一句“保重”一样自然。终有一天，Agent 会提议一个真正错误的动作——错误的收件人、错误的金额、错误的语气——而用户会带着之前确认那六个正确动作时同样的自动化反应去确认它。邮件发出后，团队写下一份事后分析，称之为“用户操作失误”。

这不是用户错误。这是系统误把“点击”的存在当成了“同意”的存在。

智能体工具调用抽象失效最明显的标志是：追踪记录（trace）显示该步骤已标记为完成，而下游系统却显示什么都没发生。模型调用了一个工具，收到了一个任务 ID 返回值，将该任务 ID 视为答案，然后继续执行。三分钟后，实际工作要么在无人监听的情况下成功，要么失败并产生一条记录在无人查看的日志中的错误。用户看到的是一份自信的总结；而操作队列看到的却是一个搁浅的任务。

这就是函数调用（function-calling）抽象悄然允许的失效模式。JSON Schema 描述了参数和返回类型，但它们无法区分“此工具返回一个结果”与“此工具返回一个操作回执，你稍后需要查询其结果”。模型对两者一视同仁，因为在规划器（planner）看来，它们看起来是一样的——都是一个带有非错误负载的成功工具调用。

集群完全按照我们的指令行事。流量在 45 秒内降至零，队列深度指标也归于平寂，KEDA 将副本数从 1 改为 0，90 秒后，节点自动扩缩容工具回收了 H100 Pod。图表看起来很干净。Slack 频道一片寂静。成本看板上的数字跳低了半美分。

一小时十二分钟后，一封客户支持工单送达：一个长时间运行的文档分析任务——一个预算为 28 分钟解码时间的 180k-token 推理任务——消失了。客户端 SDK 没报错。应用程序日志没异常。只有网关访问日志中埋着的一行 499，时间戳大致就在调度器判定 Pod 空闲并将其回收的时候。

一个超级用户在第三天早上 9 点就耗尽了你的月度 token 预算。熔断机制（kill-switch）准确触发——网关返回 429，模型停止调用，账单停止增长。与此同时，智能体（agent）已经订好了机票，发送了确认邮件，并将支持工单标记为已解决。仪表盘显示“支出已停止”。用户却问：“为什么要为我从未要求的行程扣费？”两者都没错。预算上限阻止了模型思考，但它没能阻止世界的改变。

这是几乎每个智能体预算护栏都会携带的失效模式：上限信号位于 支出 平面，但损害发生在 行动 平面，而这两个平面在连接时并没有共享的事务边界。告诉模型停止并不等同于告诉世界撤销模型刚刚所做的一切。

一个客户支持工单在周二送达。客户附上了一张你的产品在 6 周前生成的输出截图。他们声称该输出是错误的、不安全的，或者根本不符合预期，并要求修复。你的支持工程师将提示词粘贴回同一个 API 终端，得到了一个清晰、合理的回答。就系统目前的状态而言，这个 Bug 并不存在。

Bug 是存在的，但产生这张截图的模型已经不在了。自从客户提交工单以来，你的 v1-chat 终端背后的权重已经更换了两次——一次是为了提升质量，一次是为了优化成本——而原始的检查点（checkpoint）已无法访问。客户的“这东西坏了”现在成了一个针对变动目标的无法证伪的断言，支持团队既无法确认它，也无法关闭它。

这不是一个古怪的边缘案例。这是将模型版本控制视为内部 MLOps 问题，而非客户可见的产品合约的必然结果。终端 URL 是稳定的，但它背后的产物（artifact）却不是。在你的支持流程、保留策略和客户合约承认这一差距之前，每一个针对已轮换检查点的 Bug 报告都会掉进同一个分类真空区。

一位用户询问我们的支持智能体：“为什么发票 INV-2025-08-44719 在 4 月 3 日被扣了两次款？”45 分钟和 18 次工具调用之后，智能体自信地回复道：该账户在该季度没有任何重复计费的证据。用户理所当然地投诉了。当我们回放追踪记录（trace）时，答案变得显而易见。智能体在第九轮对话时对内容进行了压缩（compacted）。摘要显示用户“在询问 4 月初的一笔重复收费”。其中并不包含字符串 “INV-2025-08-44719”。随后的每一次工具调用——账本查询、退款 API 查询、审计日志扫描——都是针对转述后的意图发出的，而不是用户输入的字面意义上的发票编号。

Bug 不在工具里，也不在模型的推理中。问题在于我们的上下文管理器（context manager）与每个下游组件之间都有一个契约，但没有人把它写下来。契约写着：“我会保留语义。”而组件需要的是：“我会保留字符串。”

在第 3 轮，你的用户点击了“不要保留我的代码”。在第 7 轮，他们关闭了“使用我的对话来改进模型”。在第 12 轮，他们选择了退出跨会话记忆。到第 40 轮时，你的上下文预算耗尽了。压缩过程将第 1-30 轮折叠成一个简洁的 200 token 摘要，读起来非常顺畅：它捕捉了用户的提问、你的智能体做了什么以及结果如何。在第 41 轮，你的智能体——带着那份摘要和最近的 10 轮对话——自信地将用户的代码写入了一个用户在第 7 轮就已经选择退出的存储库中。

你的审计日志现在包含一个在 t=3 时的授权事件，一个在 t=41 时的违规操作，而两者之间是一段没有任何字段说明为什么该操作被允许的文本。摘要生成器经过训练是为了压缩对话，而不是为了转发控制状态。没有人告诉它那个授权开关是承重的（load-bearing）。也没人能告诉它，因为授权信息并不在对话中——它存在于对话旁的一个结构化字段里，而这个结构化字段没能熬过摘要化的过程。

你的每美元标签（labels-per-dollar）仪表盘是团队评审中最亮眼的一行，但它在对你撒谎。分母是你 2023 年与标注供应商谈妥的按任务计费率，那时人类研究负责人会亲手编写每个标注提示词（prompt），修改两次，请同事审阅，一周可能才提交 40 个提示词。分子是通过 API 返回的已完成任务数量。在过去的三个月里，你的团队悄悄停止了手动编写提示词，转而使用大语言模型（LLM）生成。LLM 每两秒就能生成一个提示词，边际成本几乎为零。你的每美元标签指标在上升，而唯一知道这个指标毫无意义的人是供应商的客户经理，他正看着利润率被压缩，并准备发送一份采购团队会将其视为涨价的合同修正案。

这种错位并不是供应商的问题。这反映出合同中关于工作流的假设已不再成立。这些假设与你当前行为之间的差距，正是一方在静默吸收的剩余价值，直到续约周期迫使双方进行价格发现（price-discovery）对话。先注意到错位的一方将决定新的价格。

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 Sprint 内悄然消失。复盘（Post-mortem）结果显示代码没问题，功能开关的滚动发布没问题，分析端也没问题。发生变动的是实验清单上没人负责的东西：你检索调用背后的托管嵌入模型（embedding model），在第三周、第七周，以及你开会审阅结果的那个早上，为同一个查询返回了略微不同的向量。你的 A/B 测试是真实的，但它运行的底层基座却不是。

这是每一个运行检索增强生成（RAG）的团队最终都会遇到的失败模式，而且几乎没人针对它进行设计。嵌入端点被视为像 Postgres 一样的稳定基座。但它不是。它是一个模型，其发布节奏由厂商控制，你不会去阅读它的更新日志，它的行为表现面（behavior surface）可能会发生偏移，而无需改变维度数量、SLA 或你签署的 API 合约。你以为实验测量的是功能变化，实际上测量的是检索机制的变迁，而功能开关带来的波动只是其上的噪声。

升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 escalate_to_human，随后请求滑入工单队列，并向用户礼貌地回复“专家稍后会跟进”。工程团队在发布清单上完成了闭环确认。值班表上也列出了负责接收的人员。

六个月后，一次审计对该路径进行了回溯。升级工具打开了一个 Zendesk 工单。Zendesk 队列由客服团队为了维持 SLA 响应时间而设立的预审智能体进行分拣。预审智能体由于找不到可以直接解决的政策匹配，调用了自己的 delegate_to_specialist 工具——该工具将案例路由给了一个专家智能体。而专家智能体在不确定时，又调用了 escalate_to_human。追踪轨迹形成了一个闭路。审计抽样调查的升级案例中，没有任何人类接触过。发布文档中描述的人机协作（human-in-the-loop）实际上并不存在。

升级接口并没有失败。它的每一次跳转都得到了执行。失败的是“接收系统是自然人”这一假设。

就在你发布提示词（prompt）更改的同一周，所有评估类别的得分都提升了 6 个百分点。团队成员将其视为改动奏效的证明。三周后，有人注意到这种提升也出现在了提示词更改绝不可能触及的类别中——这是一个你专门用来检测此类情况的对照组——而且这种提升是均匀分布的，而真正的产品改进绝不会呈现出这种形态。评审模型在某个周二以相同的终端节点（endpoint）名称发布了。在你的系统变动之前，你的分数就已经变了。

这种失效模式对“大模型作为评审员”（LLM-as-a-judge）评估流水线的破坏，比文献中警告过的任何失效模式都要更隐蔽。不是偏见，不是位置效应，也不是自我偏好——这些是评审员在特定时间点的属性，你的评估设计可能已经考虑到了这些因素。真正让你栽跟头的是评审员在你没注意的时候发生了变化，而你的终端节点名称、评估代码和仪表板都在声称一切如常。测量单位在一个稳定的标签下发生了偏移。跨越迁移边界的每一次比较现在都被混淆了，你无法将差值分解为“我们的系统改进了”和“尺子的标准变宽松了”，因为你从未构建过能进行这种分解的工具。