107 篇博文 含有标签「evaluation」

你的团队第一次意识到 Agent 可以调用 revoke_api_key 是在某个早晨，一位好心的用户输入了：“这个 Token 感觉太旧了，能帮我轮换一下吗？” 这个工具是在六个月前作为认证团队 MCP 服务批量导入的一部分注册的。它通过了 Schema 验证，出现在目录枚举中，然后就一直闲置在那里。没有任何评测（Eval）调用过它，也没有任何生产环境追踪（Trace）触及过它。直到某条提示词（Prompt）、某个规划器（Planner）决策，事件频道（Incident Channel）才发现该工具竟然存在。

这就是隐藏在每一个拥有复杂工具目录的 Agent 中的失效模式。四十个注册函数和一个可以组合它们的规划器，产生了一个你从未观察到的计划可达图的长尾。假设“我们测试了常用路径”掩盖了一个事实：危险的分支几乎从定义上来说就是你从未见过的那一个。

你的 AI 技术栈中最危险的数据存储是那个无人设计的存储。这一切始于一次冲刺期间的 Slack 消息：“真实用户是捕捉真实 Bug 的唯一途径 —— 让我们把一定比例的生产流量接入评估流水线，以便我们可以每晚进行回放。”六名工程师给这条消息点了赞。九个月后，该存储桶包含了 430 万条追踪（traces），当失败率上升时，评估任务会呼叫值班人员，而失败案例会被逐字发送到一个有 40 人阅读的 Slack 频道。这些追踪包含电子邮件地址、公司内部名称、部分信用卡卡号、员工电话号码，以及用户解释其愤怒原因的客户支持对话记录。

没有人梳理过数据流。没有 DPIA（数据保护影响评估）涵盖它。上季度的隐私审查查看了模型供应商的 API；但它没有查看你的评估任务。然后，一份数据主体删除请求送达，团队发现“删除该用户的所有数据”这句话已经无法对应到他们实际能做的任何事情。

单轮评估擅长一件事：在用户输入一次后便离开的任务中对模型进行排名。但对于你实际发布时会遇到的故障模式，它们毫无用处。比如在第三轮对话时就忘记用户目标的 Agent；在礼貌的重复询问下（“你确定吗？能再检查一下吗？”）就屈服并推翻正确答案的 Agent；或者在第四轮对话时还在问第二轮已经问过的澄清问题的 Agent，因为它读不懂自己的历史记录。这些问题都不会出现在对话仅进行一次交互就结束的基准测试中。

你可以进行真实用户评估，但每次发布都需要耗费数百小时的人工审查，而且问题往往在发布三周后才浮出水面。或者，你可以构建由 LLM 驱动的合成用户——具有人物角色 (Persona)、目标、耐心和放弃阈值的机器人——每晚针对待选 Agent 运行数千次对话。这是 τ-bench、AgentChangeBench 以及 2025–2026 年大多数生产级对话评估方案背后的方法。这种方法行之有效，直到它失效为止，而它失效的方式往往能让你更深刻地了解你的评估流水线，而不是合成用户本身。

在几乎每一个智能体（agent）项目评审中，都有一个会让谈话戛然而止的时刻。有人画了一张小图表：y 轴是端到端任务成功率，x 轴是工具使用的步骤数。曲线急剧下降。全场陷入沉默，因为屋子里的每个人之前都在争论提示词（prompt）、模型和检索策略——而这张图表在告诉大家，所有的这些争论，都抵不过一个简单的事实：这条链条上的环节太多了。

这一数学原理是可靠性工程中最古老的结论之一，如今被移植到了一个自以为是的新领域。如果流水线中的每一步都以概率 p 独立成功，那么 n 个串联步骤的成功概率就是 p 的 n 次方。代入一些在进度报告中听起来还不错的数字：单步可靠性 95%，十个步骤，端到端成功率就只有 60%。二十步降至 36%。三十步则降至 21%。那个“95% 的时间都能正常工作”的智能体，实际上在三分之一的真实用户请求中都会失败，因为真实的用户请求绝非只有单个步骤。

每个 AI 产品团队都会有一种特定的会议，通常发生在周四。有人共享屏幕，在 notebook 里输入一个 prompt，然后运行三四个例子。房间里的人反应热烈。大家惊叹“哇”。有人截图发到 Slack。决策就这样做出了——上线、更换模型、调整 temperature。没有人记录失败率，因为根本没人去衡量它。

这就是演示循环（demo loop），它带有一种几乎没有团队意识到的结构性偏见：它筛选的不是最佳输出，而是最“易读”的输出。几周或几个月下来，你的 prompt 不断演进，最终生成的是那些能“在会议中镇住场面”的答案——自信、流利、格式整齐、切中主题。至于它们是否正确，则是另一个变量，而你的流程并没有衡量这个变量。

其结果就是我所说的“有魅力的失败”（charismatic failure）：输出结果在某些方面是错误的，但由于选择压力，你的演示循环已经被训练得会自动忽略这些错误。

你的 Agent 通过了 92% 的评估测试集。你发布了它。在上线一小时的真实流量中，发生了一些从未在任何追踪（trace）中出现过的事情：Agent 在频率限制（rate-limit）重试风暴中停滞不前，一个客户在工具响应中看到了另一个客户的草稿邮件，你的模型供应商连接池处于 100% 的占用率，而 CPU 却处于闲置状态。这些失败没有一个源自模型。它们存在于你测试的方式与生产环境运行方式之间的鸿沟中。

这个鸿沟表现为同一种形式。你的评估工具（eval harness）在一个固定数据集上一次循环一个 Agent。而你的生产环境则在共享基础设施上同时运行许多 Agent。顺序评估隐藏了每一个前提条件为“两个事物接触同一个资源”的 Bug。在你将对抗性并发（adversarial concurrency）构建到评估工具本身之前，这些 Bug 只会以紧急运维（on-call）报警的形式出现。

你的智能体在评估测试集上达到了 94% 的准确率。然而你的轮值告警却响个不停。房间里没人撒谎，这两个数字都是真实的。实际情况是，测试框架（harness）在测试提示词（prompt），而生产环境在测试智能体（agent），这是两个完全不同的产物，只是恰好共享了权重。

Mock 工具的评估通常是产生这种差距的原因。你用预设的 JSON 存根（stub）了 search_orders、charge_card 和 send_email，给模型输入一个用户回合，并对最终响应进行断言。这种运行方式成本低、具有确定性且可复现——这些都是 CI 系统喜欢的特性。但它对工具选择、延迟、速率限制（rate limits）、部分失败和重试行为保持沉默，也就是说，它忽略了那些在事故回顾中占主导地位的失败因素。

用户将一份冗长且复杂的错误报告粘贴到你的 AI 助手。它看起来像是一个经典的空指针问题，其措辞和代码布局与数以千计的 Stack Overflow 帖子如出一辙。模型自信地做出了响应，引用了常用的修复方案，听起来非常权威。用户向它表示感谢。然而，错误依然存在。这份报告实际上关于的是竞态条件 (race condition)；空指针的表述只是用户描述症状时的偶然方式。

这是在生产环境 LLM 系统中捕捉难度最高的一类 Bug。模型没有拒绝回答，没有推诿。它没有幻觉出一个虚假的 API。它只是极其流畅地解决了错误的问题，而下游的所有环节——包括用户、你的评估流水线、你的护栏 (guardrails)——都看到了一个看似合理且切中要害的回答，然后继续下一步。我将此称为模式匹配失败 (pattern-matching failures)：模型锁定了查询的表面特征，并针对与实际提出的问题相邻的问题给出了一个自信的答案。

向用户展示一个带有 AI 答案的界面，且每句话末尾都附有链接，还没等他们读完任何一个引用的段落，他们的信任度就已经飙升。这正是企业级 RAG 的全部营销卖点：“有据可查”、“有源可循”、“可验证”。这也是 AI 工程领域中交付最多、但测试最少的说法。最近的基准测试发现，50% 到 90% 的 LLM 回复并未得到其引用来源的完全支持，有时甚至与来源相矛盾。在对抗性评估集中，最先进模型生成的引用中有高达 57% 是不忠实的：模型根本没有真正使用它指向的文档。这些引用是事后补上去的，目的是为了让模型已经决定给出的答案显得合理。

这不是检索层面的 Bug。即便你拥有完美的检索系统，仍然会得到虚假的引用，因为这种失效是架构性的。生成器先写出文字，然后再缝补链接。这些链接看起来像证据，实则只是装饰。

一个用户询问你的助手，“我该如何杀死一个挂起的 Python 进程？”结果收到了一个关于暴力的礼貌拒绝。另一个用户问，“谁获得了 2003 年诺贝尔物理学奖？”结果得到了一个自信编造的名字。这两个回答都来自同一个模型，都通过了你的安全审核，并且到周一都会出现在你的支持收件箱里。令人沮丧的是，这并不是两个独立的故障，也不是两个独立的修复方案。它们是同一个失败：你的模型被训练成识别拒绝模板，而不是识别它实际上不应该回答的内容。

整个行业花了三年时间让模型拒绝违反政策的请求。但几乎没有花时间教它们拒绝那些无法可靠回答的问题。结果是拒绝能力的方向出现了偏差：在表面模式（如 “kill”、“exploit”、“bypass”）上得到了大量强化，但在认知状态（如 “我不知道那是谁”）上几乎没有训练。当你只优化一个方向时，你得到的模型会对错误的问题说“不”，同时对错误的问题说“是”，而且通常发生在同一次对话中。

你的模型在评测集上得分92%，但说法语的用户却不断抱怨它在胡说八道。这两件事可以同时为真——而它们之间的差距，是多语言AI系统在构建和评测方式上的结构性问题。

LLM在非英语语言中的幻觉率比英语高出15–35%。在斯瓦希里语或约鲁巴语等低资源语言中，针对同样的事实类问题，性能差距可扩大至38个百分点。然而，大多数团队在推出多语言AI功能时，只使用英语评测套件，汇报掩盖问题的聚合基准分数，直到巴黎或孟买的用户开始提交工单才发现问题。

跨语言幻觉问题本质上不是模型质量问题，而是一种测量与架构失误——团队将多语言AI视为"英语AI加上翻译模块"而一再延续这一失误。

大多数团队将他们的黄金评估集（golden eval set）视为宪法——持久、权威且变动成本极高。他们花数周时间挑选案例，请领域专家进行标注，并将其接入 CI。然后，他们就转去忙别的事了。

六个月后，评估套件显示通过率为 87%，但用户却在抱怨输出结果支离破碎。评估指标并没有倒退——它们只是腐化了。该数据集测量的仍然是 10 月份重要的数据。它只是不再测量现在重要的数据。

这就是黄金数据集腐化问题（golden dataset decay problem），它比大多数团队愿意承认的更为普遍。