168 篇博文 含有标签「evaluation」

你的评估流水线针对每一个模型输出运行一个由三位评审组成的集成系统。评审成员包括使用严格标准的 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 而维持“绿色”的指标中是不可见的。随后，它会默默地发布这些回归，因为盯仪表板的人并不是盯答案的人。

你的英文系统提示词（system prompt）花了六周的时间进行调优。一位资深工程师先后四次重写了约束列表，评估套件终于在留存任务集（held-out task set）上跑出了 94% 的通过率，发布检查清单也为生产环境亮了绿灯。随后，国际化（i18n）团队接手，将其放入处理按钮标签和工具提示的相同翻译流水线中，并在下个迭代周期交付了日语、德语、印地语和阿拉伯语版本。针对非英语市场的发布仪表盘显示了相同的任务量、相同的用户转化漏斗，而且——直到六个月后收到东京客户的一张工单——始终保持着代表正常的绿色状态。

东京客户投诉称，智能体忽略了英文提示词中明确禁止的一项指令。你重新阅读了日语提示词，发现从语义上看，两者的意思完全相同。你针对英文变体重新运行了英文评估套件，通过了。但日语变体没有评估套件。从来都没有。

检索日志很干净。针对你手动标注的查询集，Recall@10 在几个月内都没有出现退化。答案质量仪表盘显示忠实度（faithfulness）保持在 90% 以上。然后，一位客户向你的支持代理粘贴了一个问题，金标准文本（gold passage）就在组合提示词的 12 个位置中的第 7 位，而模型的回答却好像从未检索到它一样。

检索团队会告诉你该分块（chunk）确实在那里。提示词团队会告诉你提示词是正确的。两者在技术上都是对的。模型关注了前一千个标记（tokens），关注了最后一千个标记，却略过了答案所在的中间地带。你的流水线正面临着一种位置注意力偏置（positional attention bias），没有哪个团队对此负责，没有哪个仪表盘在追踪它，也没有哪个基准测试能捕捉到它。

你的去重步骤报告显示语料库缩减了 28%，训练运行提前六小时结束。评估数值持平甚至略有提升。没人去查看被删除内容的 diff。三周后，客服开始因为一类模型曾经能处理、现在却完全搞砸的退款反转工单进行告警。有 11 条训练数据涉及该特定模式。其中 9 条消失了——它们被合并为一个单一的代表样本，保留了最简洁、最干净的措辞，却丢弃了那些模型实际从中学习如何缓和情绪的、语带敌意的复杂变体。你的去重流水线造成了这一切，而你的评估并没有捕捉到它，因为在构建评估集时，这些例子已经从用于采样评估集的训练集中消失了。

这是关于去重作为一个流水线步骤让我感到困扰的失效模式：它表现为数据清洗，实际上却是分布编辑。删除样板文件的完全重复是清洗。通过相似度阈值删除近重复项则是一种包装成清洗的采样决策。阈值决定了训练分布中哪些切片能存活下来，而最容易丢失的切片正是你起初样本最少的那些——根据定义，这些样本通常是你为了覆盖率而非样本数量而保留的。

离线评估的结果非常明确。在向量搜索的前 50 个结果之上叠加一个交叉编码器（cross-encoder）后，nDCG@5 提升了 4 个点。团队在周二上线了该功能。到了周四，p99 检索延迟已超过 SLO（服务水平目标）700 毫秒，客户成功团队也开始转发空结果页面的截图，而这些页面在旧的流水线下本应是有内容的。真正关键的指标——用户感知的回答质量——下降了。重排序器（reranker）实际上是一个被团队冠以“改进”之名的性能退化，而评估标准则是将这种退化隐藏在众目睽睽之下的幕后黑手。

这是生产环境检索中最常见的失效模式之一，且很少被准确描述为：一个评估缺陷（evaluation bug）。重排序器完成了它的宣传任务：以更细的粒度对前 50 个结果进行了重新排序。问题在于，用于证明其合理性的指标——在无限预算下针对完整重排序列表计算的离线 nDCG——描述的是一个生产系统并不存在的理想世界。在生产环境中，最终输出的答案并非评分最高的重排序列表，而是系统在请求截止时间前所能返回的任何内容。一旦你以此方式重新定义指标，重排序器的贡献就不再是 4 个点的提升，而是一条曲线。