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

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）里列出了一堆团队，而每个团队都以为别人会负责。

构建一个 LLM 功能需要几天时间。在生产环境中对其进行调试则需要数周。这种不对称性——即“调试税”（debug tax）——是 2026 年 AI 工程的核心成本结构，大多数团队直到深陷其中时才意识到这一点。

2025 年的一项 METR 研究发现，使用 LLM 辅助编码工具的资深开发人员实际上效率降低了 19%，尽管他们感知到的速度提升了 20%。这种感知效率与实际效率之间的差距是更广泛问题的一个缩影：AI 系统之所以让人感觉构建速度很快，是因为最困难的部分——在生产环境中调试概率性行为——还没有开始。

调试税并非能力问题。它是构建在概率推理之上的系统的结构性属性。传统软件的失败表现为堆栈跟踪（stack traces）、错误代码和确定的重现路径。基于 LLM 的系统则表现为似是而非但错误的答案、间歇性的质量下降，以及无法重现的故障，因为相同的输入在连续运行中会产生不同的输出。调试这些系统需要根本不同的方法论、工具和心智模型。

你的 AI 智能体完成了任务。日志中没有错误。延迟看起来很正常。输出是格式良好的 JSON，语法完美的散文，或者是执行起来毫无怨言的有效 SQL 查询。仪表盘上的每一个指标都是绿色的。

而用户盯着结果，叹了口气，然后从头开始。

这就是语义失效模式 —— 这类生产环境中的 AI 失败表现为：系统运行正常，模型自信地响应，输出按时交付，但智能体并没有做用户真正需要的事情。传统的错误监控对这些失败完全视而不见，因为并没有报错。HTTP 状态码是 200。模型没有拒绝。输出符合 Schema。从每一项技术指标来看，系统都成功了。

Wait, I should double-check the truncate tag and headers.

大多数构建 LLM 应用的团队都会陷入两种失败模式之一。第一种是完全不建立评估（Evals），凭感觉发布功能。第二种是在还没搞清楚到底要衡量什么之前，就构建了复杂的评估基础设施。这两种都是代价高昂的错误。

表现优秀的团队有一个共同点：他们从观察数据开始，而不是从构建系统开始。错误分析优先于自动化评估。在信任任何自动评判器之前，先用人工判断为指标奠定基础。他们不把评估看作是一个需要跨越的里程碑，而是一个随着产品共同演进的持续准则。

这就是 Evals 在实践中的真实样貌——那些至关重要的决策、浪费精力的模式，以及在你被“坑”过之前都不明显的权衡。

大多数团队构建 LLM 评估器（evaluators）的顺序都是错误的。他们先写标准，然后再看数据。这种倒置是评估失准的根本原因，而且在交付首个 AI 产品的团队中几乎普遍存在。这些标准在纸面上听起来很合理 —— “回复应当准确、有帮助且简洁” —— 但当你将它们应用于真实模型输出时，你会发现评分标准（rubric）与你真正关心的内容并不匹配。你最终得到的评估器评分的是你并未衡量的内容，却漏掉了真正重要的失败情况。

解决方法不是制定更好的评分标准。而是一个不同的工作流：先看数据，再定义标准，然后在信任其进行无人值守运行之前，根据人类判断验证你的评估器。