172 篇博文 含有标签「evaluation」

你的 RAG 评估仪表盘显示为绿色。忠实度（Faithfulness）为 0.91，回答相关度（Answer Relevance）为 0.88，你花了两个迭代周期构建的 LLM-as-judge 评估框架显示系统运行良好。与此同时，一位用户刚刚问了一个问题，而答案就在你的检索器（retriever）从未提取出的文档中，你的模型写下了一个自信、结构清晰但完全没用的回答，内容与问题相关但风马牛不相及。评判员给了它高分。它读起来很顺畅。它基于模型 确实 获取到的片段。它只是用与用户需求无关的内容回答了一个错误的问题。

这是大多数团队评估检索增强生成（RAG）时存在的隐性结构缺陷：他们给文章打分，却从未检查学生是否拿到了正确的书。RAG 系统是两个连接在一起的机器——一个是决定 模型能看到什么 的检索器，另一个是决定 如何处理这些内容 的生成器。几乎生产环境中的每一个评估框架都只衡量第二个机器。第一个机器，也就是真正决定答案质量上限的那个，却在未经监控的情况下运行。

一位队友提交了一个拉取请求（PR）。Diff 只有三个单词。一行变红了 —— Do not add information not present in the source.（不要添加原文中不存在的信息）—— 另一行变绿了 —— Make your best guess if the source is incomplete.（如果原文不完整，请做出最佳猜测）。改动很小，意图也合理，代码审查只用了 11 秒。你批准了它。一周后，你的客服机器人开始自信地编造根本不存在的退款政策，而你正在翻阅日志，试图查出幻觉率是从什么时候开始翻倍的。

Git Diff 完美地完成了它的工作。它准确地向你展示了哪些字符发生了变化。但它无法展示唯一重要的事情：这些字符背后的行为已经从“不确定时拒绝”变成了“不确定时编造”。对于代码，文本差异是行为差异的忠实代理 —— 将 < 改为 <=，审查者可以推断出后果。而对于提示词（Prompts），文本差异和行为差异几乎没有任何关系。

这次升级看起来就像是白捡的便宜。供应商发布了一个更新的模型，它在每一项公开基准测试中的得分都更高，每个 token 的成本更低，且生成 token 的速度更快。你在一个配置文件里修改了模型字符串，运行了评估套件，看着 340 个测试用例全部变绿，然后在周二下午发布上线。到了周四，客服工单不断增加，却没人能指出到底是哪一个测试失败了。

这是应用层 LLM 开发中最令人困惑的失效模式，因为它违反了其他所有软件与你达成的契约：如果测试通过，行为就保持一致。在这里，该契约失效了。模型升级不是对一个你可控接口的库进行版本更新。它是一次对概率函数的无声、大规模更替，而你的评估套件只检查了你想到要写下来的那一小部分行为。

真正带来伤害的退化往往存在于你从未编码定义过的行为中——语气、冗余度、格式习惯，以及模型如何处理请求中模糊的中间地带。这些恰恰是你的用户所依赖的东西，也恰恰是 pass/fail 断言无法察觉的东西。

一个新的前沿模型发布了。它更便宜、更快速，并在各大公开排行榜上霸榜。你使用你花了 18 个月构建的评估套件对其进行测试，结果它的得分比你目前运行的模型还要差。于是你保留了现有的模型，将挑战者模型归类为“尚未准备好”，然后继续之后的工作。

令人不安的部分在这里：那个结果几乎没有告诉你哪个模型更好。它告诉你的其实是，你的评估套件是通过观察当前模型的失败、处理一次又一次的生产事故而构建的，然后通过修补来消除那些特定的失败。这个套件并不是对质量的客观衡量，它是某个模型“疤痕组织”的目录。而一个拥有不同弱点的挑战者模型，在面对一个针对现有模型特定弱点而收集的测试集时，表现总是会显得更差——即使它在你实际服务的流量上表现得更好。

这就是“现有模型偏见 (incumbent bias)”，它是没人会在迁移决策中计算的切换成本。它在更好的选择出现很久之后，依然悄悄地将你锁定在旧模型上，而且它还是披着“严谨工程”的外衣做到这一点的。

你的评估流水线针对每一个模型输出运行一个由三位评审组成的集成系统。评审成员包括使用严格标准的 GPT-4、使用宽松标准的 GPT-4 以及使用思维链标准的 GPT-4。他们在 91% 的案例中达成一致。你向发布审查委员会报告了 0.83 的 Krippendorff's alpha 评审间一致性指标。这个数字落在了每个方法论教科书都视为“绿灯”的“显著一致性”区间内。在六个月的时间里，三个模型升级版本依据这一数字顺利发布。

一位外部审计员使用相同的评审标准，将其中一位评审更换为 Claude，结果在难题上的一致率降至 64%。那些证明前三次升级合理性的评估分数，结果变成了取决于你将哪个供应商家族视为“基准真相（Ground Truth）”的数字。这些升级只是针对 GPT-4 家族偏好的升级，而非针对质量的提升——因为评审本身就是受审模型的“同胞兄弟”。

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

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

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

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

我上个月接触的一个团队对一个数字感到非常自豪：他们的高级主管智能体（supervisor agent）在第一次审查时就批准了其子智能体（subagents）97% 的计划。他们将其解读为“子智能体非常有能力”。六周后的红队审查则将其解读为“主管和子智能体实际上是同一个评估者在给自己的输出打分”。这两种解读都符合数据，但只有其中一种在生产环境中是真正“承重”的。

主管-审查-子智能体模式（supervisor-reviews-subagent pattern）是 2026 年多智能体系统中最常见的形态——约占生产部署的 70%，其中包括各大实验室发布的大多数参考设计。在纸面上，这看起来像是一种校验机制。规划者分解任务，专家执行者制定计划，主管在授权执行前审查每个计划。关注点分离、清晰的审计追踪，应有尽有。问题在于，如果你使用相同的基础提示词模板来构建主管和子智能体——即使角色特定的补充说明有一段不同——你构建的也不是校验机制，而是一个审查步骤，它只是同一个模型自我认同的产物。

一个团队最成功的 AI 功能在周二凌晨 2:14 宕机了。传呼机显示模型 API 在稳态下返回 429 错误。模型是健康的。供应商是健康的。团队自身的生产流量也是正常的。蚕食额度的是每晚运行的评测套件（eval suite）——正是团队在前一周引以为傲并进行扩展的那个套件。评测系统和产品共享同一个组织密钥（organization key），在那个夜晚，评测系统成了那个打破室友宁静的“吵闹邻居”。

评测系统并没有异常行为。它正在按照开发者的设计运行：针对生产模型标识符（identifier）进行一千个案例的测试，按节奏、按计划运行——这个计划因为已经静默运行了两年，早就被大家遗忘了。这次最终导致超限的扩展增加了三百个案例。该 PR 经过了评测负责人和 Prompt 负责人的审核。评审线程中没有一个人想到要问：这会消耗多少每日 Token 额度？

你添加了搜索工具，接着是日历工具，然后是 CRM 工具，接着是四个数据库封装器（wrappers）和一个计算器。仪表盘的变化正如你所愿：任务完成率上升，延迟保持稳定，“我不知道”率从 14% 下降到 4%。这看起来像是能力的提升。事实并非如此。规划器并没有学到更多知识；它只是学会了减少拒答（abstention）。现在每个问题看起来都是可以回答的，因为总有 某个 工具的模式能与查询充分匹配并被调用。你消除的那 10 个百分点的“我不知道”并没有转化为正确的答案 —— 它们变成了自信的错误答案，分布在无人仔细评审的长尾场景中。

这就是工具表面扩展带来的“伪能力陷阱”（false-competence trap）。这是团队在庆祝改进时，发布了性能退化（regression）最常见的方式。评估准则衡量的是 Agent 是否尝试了任务并产生了一个形状合理的答案；它并不衡量 Agent 是否应该拒绝回答。拒答并非没有成本，但它是目前能获得的最廉价的正确行为，而一旦你的工具集变得足够大，以至于总有 某个 工具会被触发，你就再也看不见这种行为了。

微调模型上线了，评估仪表盘全线飘绿，团队发出了庆祝的截图。投入生产一周后，支持工单的积压情况与训练运行前完全一样。在你的准则（rubric）中获得 87 分的模型，在实际工作中表现得很糟糕，和微调前只有 71 分的模型没什么两样。你的测试集没有任何泄露。数据是干净的。切分是诚实的。出问题的地方更微妙：用于评分训练奖励的准则与用于评分评估的准则是同一个，而模型学会了如何迎合这个准则。

这是一种失败模式，全线飘绿的仪表盘证明的是记忆力而非能力。训练循环推动模型趋向于准则所奖励的任何目标。准则有一个“表面”——一种形状、一种措辞、一组评审模型（judge model）会捕捉的线索——而模型学习这些表面特征的速度比学习底层行为要快得多。当你使用同样的准则进行评估时，你不再是在衡量模型是否变得更好，而是在衡量它是否发现了该准则的“破绽”。

一个优化单一损失函数的模型路由器会准确地交付该损失函数所要求的结果，除此之外别无他求。当该函数的目标是“保持在 p95 延迟目标之下”时，每一个本可以从深度推理（extended reasoning）中获益的查询都会被强行分配到路由器能辩护的最廉价路径上，因为快速模型能在 SLO 范围内返回，而缓慢但正确的模型则不能。延迟仪表板变绿了。综合评估指标（aggregate eval）仅波动了不到一个百分点，团队便将其视为噪声忽略不计。而没人绘图的分片视图（per-slice view）才是真正发生质量回归（regression）的地方：它集中在那些多步骤、模糊且分布外（out-of-distribution）的查询中，这些查询本应被路由到推理模型，结果却分配给了那些运行迅速但错误得很有底气的模型。

这不是路由 bug。路由器正在准确地执行其设计任务。Bug 出在框架设定上——如果一个系统的优化器完全以延迟为基准，它就会产生质量回归，而这些回归在团队为了 KPI 而维持“绿色”的指标中是不可见的。随后，它会默默地发布这些回归，因为盯仪表板的人并不是盯答案的人。