28 篇博文 含有标签「llm-evaluation」

产品团队在每个 AI 建议旁边都附带了一个置信度徽章。≥85% 为绿色，60–84% 为黄色，低于此数值为红色。六周后，他们运行了一次 A/B 测试，发现在任何阈值下用户行为都没有变化。置信度为 0.92 的误报被接受的比例与置信度为 0.61 的误报完全相同。团队的直觉是调整校准——拟合一个温度缩放层（temperature scaling layer），重新生成徽章，再次运行 A/B 测试。数据变了，但行为没变。

问题不在于模型没有校准好，尽管它几乎肯定没校准好。问题在于校准后的概率是错误的输出。用户可以据此行动的信号不是模型“有多确定”，而是“模型具体没检查什么”。一个 0.87 的徽章无法告诉用户任何可以验证的信息。“我对地址相当有信心，但我还没有核对单元号”则准确地告诉了他们该看哪里。

每个 LLM 团队最终都会收到主管发来的同一封邮件：“Anthropic 发布了新的 Sonnet。用我们的流量跑一下测试，周五前告诉我是否应该切换。”团队打开生产环境的追踪（trace）存储，调取上个月的请求，并针对新模型排队运行——但在运行三小时后，有人发现工具调用环节的差异评分看起来非常离谱。答案是：没有人以原始形式捕捉工具的响应。追踪记录忠实地记录了模型的“回复”，并存储了每个工具返回内容的一行摘要。回放这些请求并不能回放旧模型实际看到的内容；它回放的是一段被严重压缩的投射。迁移评估并不是在衡量新模型，而是在衡量新模型如何与一个不同的现实对话。

这就是我想讨论的失败模式。大多数生产环境的 LLM 日志都是“以输出为导向”的：它们能很好地回答“模型说了什么？”，但只能模糊地回答“模型看到了什么？”。这种不对称性在你需要针对新模型回放历史数据之前是隐形的——到那时，它就成了整个问题的关键，因为日志记录与实际发送内容之间的差距，正是真实评估与虚假评估之间的差距。

称之为反事实日志（counterfactual logging）：今天就捕捉那些你明天询问“如果用另一个模型处理这个完全相同的请求，它会做什么？”时所需的输入。标准不是“我们记录了请求”，而是“我们可以针对不同的模型重新执行该请求，并确信结果是有意义的”。

这是周二的早晨，也就是 Prompt 更改上线到一半流量后的那一周。你打开四个仪表板。LLM 评审员（LLM judge）评分的留存黄金集显示 +8%。每周对生产流量进行抽样的真人评估小组显示无变化。下游转化率的 A/B 测试显示 -2%。点赞率（thumbs-up rate）持平。四个信号，四个结论，而十五分钟后就有一个站会，会上有人会问你到底是发布这个 Prompt 还是回滚。

你很容易倾向于选择那个能证实你原本意图的数字——团队也会这样做，因为会议上没有人拥有一套关于哪个信号获胜的书面规则。这种不一致并非测量错误。这是一个在没有层级体系的情况下强行把四个评估器凑在一起的系统的必然产物。缺乏这种体系的代价是，每个发布周都会变成一场关于该信任谁的数据的辩论。

如果代码审查流水线中的作者和审阅者都是在重叠语料库上训练的语言模型，那么它就不是一个质量关卡，而是一个信心放大器。作者编写的代码在 Transformer 看来是合理的，审阅者以同样的合理性视角阅读代码，双方最终达成“看起来没问题”的共识，于是代码变更带着一个绿色的勾合并了，而这对于变更是否真正正确毫无意义。最近的行业数据清楚地展示了这种不对称性：在同等规模下，与 AI 共同编写的 PR 产生的严重问题（critical issues）比人类编写的高出约 40%，重大问题（major issues）高出约 70%，其中逻辑和正确性错误占了差距的大部分。而为了捕捉这些错误而发布的审阅代理（reviewer agents），从构造上来说，恰恰是最不具备发现这些错误能力的。

那些从 AI 代码审阅中获得真实信号的团队已经不再将“审阅”视为“生成”的某种变体，而是开始将审阅设计为一种本质上不同的认知任务。生成式提示词（Generation prompting）要求模型产生连贯的内容。而审阅式提示词（Review prompting）则必须要求模型发现缺失的东西——去关注 Diff 中的负空间而不是正空间——这种反向思维比一行系统提示词所暗示的要难诱发得多。

架构图上写着“三个前沿模型集成、辩论与对齐、多数投票”。追踪记录显示，所有三个智能体在第一轮就达成了一致，并又花了两个回合礼貌地互相转述。评估结果显示比单次调用高出 0.4 分。账单显示成本是 4.2 倍。在这其中的某个环节，有人判定这个委员会运作良好。

多智能体辩论被宣传为一种获取分歧驱动推理的方法：三个大脑相互争论，以获得比其中任何一个单独达到的更好的答案。但这取决于智能体是否真的存在分歧。在重叠的网络语料库上训练、针对重叠的偏好数据集进行指令微调、并针对重叠的安全分类法进行对齐的前沿 LLM，其共享的先验知识远比架构图所承认的要多。在经过一轮“让我们达成一致”之后，你观察到的并不是三种观点向真理汇聚——而是来自同一个分布的三个样本向它们原本就相距不远的众数汇聚。

这种模式在最近的文献中有一个名字：当一个集成的投票分歧率趋于零且与问题难度无关时，你就遇到了辩论多样性崩塌（debate diversity collapse）。委员会仍在投票。但投票已不再携带任何信息。

Agent 对客户说：“收到——我已经提交了你的退款请求。你应该会在 5–7 个工作日内看到它。”客户关闭了聊天。但退款从未被提交。没有工单，没有 API 调用，退款表中也没有记录。有的只是一段礼貌且自信的英语，以及随后成功的会话终止。

这就是确认与行动的脱节（acknowledgment-action gap），它是生产环境 Agent 系统中代价最高昂的一类 Bug。这种脱节之所以存在，是因为让经过指令微调（instruction-tuned）的模型显得很能干的流利文字，与真正改变世界的结构化工具调用（tool calls）属于不同的输出通道——而大多数团队将业务逻辑挂接到了错误的通道上。

每个发布 Agent 的人最终都会以惨痛的方式意识到这一点。模型生成了一份读起来像承诺的精美确认函，下游系统将其解读为承诺，几周后一份支持工单寄来，询问退款去了哪里。令人尴尬的不是模型撒了谎，而是系统被设计成去信任它所说的话。

你最信任的基准测试极有可能正是在对你撒谎。公开评估是一个闭环：你发布测试，有人抓取它，下一代模型在抓取的数据上进行训练，于是你信任的衡量标准的分数在没人触碰底层能力的情况下提高了 10 分。测量体系保持不动，而它所测量的对象却在下方发生了偏移，“模型在这个基准测试上表现更好”与“模型在这个任务上表现更好”之间的差距每个季度都在拉大。当这种分歧明显到足以引发争论时，该评估已经发布了六次排行榜更新和三个产品路线图，而这些都假设那个数字是有意义的。

这并非一种假设性的失败模式。非公开的预 RLHF 版 GPT-4 基础模型已被证明能够逐字重现 BIG-Bench 的 canary GUID，Claude 3.5 Sonnet 也是如此，这都表明原本应该被隔离的任务数据最终进入了训练。大约 40% 的 HumanEval 样本被确定为已污染，从 GSM8K 中移除污染子集后，测得的准确率下降了约 13 分。SWE-bench Verified 目前显示有记录的数据泄漏率为 10.6%，OpenAI 在 2025 年末其内部审计发现每个主要的前沿模型都能为某些任务逐字复现金标准补丁（gold patches）后，公开停止了对其的报告。我们用来比较模型的数字正越来越多地变成关于记忆力的数字，而不是能力的数字。

评估套件显示绿色（通过）。仪表盘显示绿色。一周后，支持团队淹没在同样的投诉中：“助手一直拒绝预订会议。”你打开评估工具（eval harness），重放失败的追踪记录，结果它运行正常。非常完美。每一次都成功。Bug 不在你的评估中，也不在你的模型中。Bug 在于：你的评估所测量的 Agent 和你的客户正在交谈的 Agent 已经不再是同一个系统了，而目前还没有人意识到这一点。

评估与生产环境偏移（Eval-prod drift）是指评估工具加载到 Agent 中的内容与推理栈在请求时实际组装的内容之间，发生的缓慢且难以归因的发散。提示词（Prompts）、固定的模型版本（model pins）、工具架构（tool schemas）、护栏配置（guardrail configs）和功能标志（feature flags）分别通过不同的部署路径流入 Agent —— 代码合并、配置推送、提示词注册中心的回调、实验平台、运行时上线 —— 几乎没有团队拥有一个能够协调这些内容的单一事实来源。因此，评估工具最终测量的是存在于某人 PR 分支中的 Agent 版本，而生产环境运行的则是昨日热修复、上周的功能标志变体，以及工具团队在没告知任何人的情况下推送的任何内容的集合。

这不是一种理论上的失效模式。它是任何运行超过三个月、且配置分布在多个代码库中的 Agent 系统的默认状态。

一个在提示词未发生任何更改的情况下，测试结果由绿转红的回归测试套件，通常源于以下三种情况之一：测试框架损坏、检索库不稳定，或者评估模型（Judge）在周末学习了“新口味”。第三种情况最常见，也最难调试，因为你的代码仓库里没有任何提交记录与之相关。评分模型在静默状态下完成了质量更新，你与上个月仪表盘对比的所有分数，现在都已经是在用另一种“货币”计价了。

这是 LLM-as-judge 令人不安的地方：你有两个处于变动中的模型，而不仅仅是一个。待测模型（Candidate Model）是你发布的产物；评估模型（Judge Model）则是告诉你待测模型表现如何的工具。当两者独立演进时，分数的变化量（Score Deltas）不再具有以往的含义，你家产品经理每天早上刷新的仪表盘正在悄悄地撒谎。

智能体（Agent）打印了一个五步计划。第三步是“从发票服务中获取用户的账单历史”。追踪链路（Trace）显示，第三步实际上调用了订单服务，关联了一个过时的客户表，并产生了一个看起来正确的数字。输出通过了评估（Eval）。六个月后，财务部门发现仪表盘与事实源（Source-of-truth）悄然出现了 4% 的偏差，复盘时才发现了这次回归（Regression）。

没有人写出 Bug。规划器（Planner）写下了一份执行器（Executor）从未签署的契约。

这就是“计划与执行”架构在其优雅的架构之下所掩盖的失败模式。这种模式被推销为一种赋予智能体长程连贯性的方式：由一个强大的模型起草计划，较弱的模型执行步骤，计划起到脚手架的作用。在实践中，计划只是一种“营销产物”——在 t=0 时发出的一个看起来合理的预告，随后在 t>0 时发生的每一件趣事都会迅速令其失效。追踪链路显示了计划，追踪链路也显示了行动。但几乎没有人去衡量两者之间的距离。

大多数团队在发布 LLM 功能后，会花费数周时间争论该功能是否真的好用。由于构建标注数据集感觉像是一个独立的项目，评估问题往往被推迟。当你有了标准答案（ground truth）时，你也积累了两个月无法诊断的沉默回归。这本末倒置了。如果你知道该采用哪些技术以及每种技术的局限性，你可以在第一周——在完成任何标注之前——就获得有意义的质量信号。

这篇文章是无标注评估的实战指南：涵盖了有效的无引用方法、所需条件，以及如果不小心就会误导你的特定失败模式。

当加拿大航空（Air Canada）的客服聊天机器人向客户承诺为近期遭遇丧亲之痛的旅客提供折扣票价时，它所描述的政策其实并不存在。法院后来依然裁定加拿大航空必须兑现这一“幻觉”产生的退款。当一家雪佛兰经销店的聊天机器人经协商以 1 美元的价格卖出一辆 2024 款 Tahoe 时，没有任何机制能阻止它。在这两个案例中，最直接的问题是模型质量。而真正的问题——在运营层面上至关重要的问题——则更简单：到底应该由谁来发现这些问题？

在大多数组织中，答案是：没有具体的人。AI 质量处于机器学习工程（ML engineering）、产品管理、数据团队和运营的交汇点。每个职能部门都只看到局部，没有人声称拥有完整的责任权。其结果是一个“真空地带”，本应被发现的问题被漏掉了；而当某些环节出现故障时，事后分析报告（postmortem）里列出了一堆团队，而每个团队都以为别人会负责。