影子评估：当私有切片取代了你的评估汇总

想要发现你的 AI 团队缺乏评测纪律，最快的方法就是分别在 Slack 私聊中询问三名工程师：“你上次的提示词（prompt）修改提升了质量吗？”——然后看着他们三个人都回答“是”，但给出的却是三个不同的数字，针对的是三个不同的切片（slice），在三台不同的笔记本电脑上运行，而且团队中没有其他人能复现这些结果。从教科书式的定义来看，这不单纯是评测问题。教科书会说你没有评测。而现实情况更糟：你有 太多 的评测，每个评测都是私有的，每个都能衡量一些真实的东西，但没有一个能汇总成组织可以据此制定计划的单一指标。

这就是“影子评测（shadow eval）”反模式，大多数 AI 团队在承认这一点之前，这种状态持续的时间比他们愿意承认的要长。它看起来效率很高——每个工程师都有一个 notebook，每个 PR 都附带一张通过率的截图，每次站会都会提到“在长尾切片上取得了胜利”——而且它能在季度评审中幸存下来，因为“我们做评测”的门槛太低了，只要运行任何内容都算。但组织得不到任何信号。领导层无法判断上个月的三次提示词修改是推动了产品进步还是原地踏步，因为三名工程师是根据三个私有切片进行衡量的，而且在切换文件的那一刻就停止了对之前基准（baseline）的追踪。

这种模式的出现并不是因为有人偷懒。它的出现是因为局部激励远快于全局激励。一名正在调试西班牙语客服查询回归问题的工程师，不想为了验证五十个本地案例而花一个小时等待完整的评测套件运行一千个案例，因为他们可以在三分钟内完成本地迭代。这五十个案例是 正确 的——它们是解决当前 bug 所需的关键案例。问题在于，没有其他人见过这些案例，针对这些案例的分数永远不会出现在排行榜上，当工程师发布修复程序时，组织没有任何关于这五十个案例曾经存在的记录，更不用说新提示词在这些案例上的表现如何了。

典型症状

当以下情况全部属实时，你就是在运行影子评测。PR 描述中引用了评测数字，但产生这些数字的评测只是作者 ~/scratch/ 目录下的一个脚本。“官方”评测套件——如果存在的话——每周由一个人运行一次，而且其仪表板自上次值班轮换以来就没刷新过。工程师们引用在私下取得的进展——“没错，上个冲刺我在金融服务切片上获得了 3 个百分点的提升”——但没有其他工程师能复现这个数字，因为切片本身只是存在于作者笔记本电脑上的 CSV 文件，直到在一次清理中被意外 rm -rf 掉了。

一个更微妙的症状是：当生产环境出现回归时，事后分析无法确定哪个评测应该捕获到它，因为没有人知道官方套件的覆盖范围。团队一直在针对从未提升到共享基础设施的私有案例进行迭代，因此回归套件已经滞后于团队对“产品需要处理什么”的实际心理模型。心理模型存在于七个私有的 notebook 中。而回归套件已经过时六个月了。

经济成本是真实的，但那是次要的。真正的成本是认知上的。组织一直是在根据关于评测的故事而不是评测本身做决策，而故事与评测套件之间的差距在每个冲刺中都在扩大。

为什么局部激励会胜出

一个运行良好的共享评测框架是很慢的。它包含工程师在处理当前 bug 时并不关心的案例，它将算力浪费在工程师不需要信号的评测运行上，并且它产生的数字将相关切片混合到全局平均值中，从而掩盖了工程师试图衡量的变化。工程师那包含五十个案例的私有 notebook 要快二十倍，并且在实际问题上能产生更清晰的信号。从单纯的迭代耗时来看，对于工程师的 当前任务，私有 notebook 是理性的选择。

这就是核心陷阱。私有评测在局部是帕累托最优的——对于工程师正在调试的精确故障模式有更好的信噪比——但在全局则是最差的——对组织的其他人不可见，没有提升到共享基准中，在工程师切换上下文的瞬间就会丢失。如果团队不主动承担将私有切片提升到共享基础设施的成本，最终会陷入一个充满局部正确决策的坟场，而没有全局图景。

版本控制中的类比是每个人主目录下未受监管的脚本。代码库中的类比是永远不会合并的死分支。数据工程中的类比是运行业务的 Excel 表格。它们描述的都是同一种失败模式：真实的工作正在进行，真实的价值正在产生，但没有一项能累积到共享的基座上，组织正在缓慢地为这种偏离付出代价。

弥合差距的纪律

弥合影子评测差距首先不是一个工具问题——而是一个契约问题。这个契约是：每一个影响合并决策的评测结果，都必须能由另一名工程师在另一台机器上，仅使用仓库中的内容即可复现。这句话几乎涵盖了所有工作。如果你认真对待它，就会推导出以下几点：

带有排行榜的共享框架。 一个运行规范套件的过程，针对注册的 模型+提示词+配置 元组进行运行，并将结果写入每个人都能看到的地方。像 promptfoo、Braintrust、lm-evaluation-harness 模式以及各种自研变体都趋向于这种形式——一个指定数据集、提示词模板、评测员（judge）和评分细则的 YAML 或配置文件，并进行版本锁定，以便相同的配置加上相同的提交哈希值能产生相同的数字。数字不是目标，可复现性才是。排行榜让全局状态一目了然：本周谁在哪个方向上推动了哪个切片。

强制性的 PR 关联评测运行。 当工程师开启一个涉及提示词、工具定义、模型标识符或任何可能影响质量的 PR 时，CI 会针对提议的更改运行共享评测套件，并发布相对于当前基准的差异（diff）。这个差异就是一个合并门槛（merge gate）。合并门槛不能被某人笔记本电脑上的截图所反驳，因为截图是不可复现的。这是真正约束行为的政策杠杆——工程师们不再将私有评测作为他们的 主要 信号，因为这个门槛会不断捕获他们私有切片漏掉的东西。

每个人都能复现的“受保护”切片。 评测套件不是一个庞然大物。它是由少数几个命名的切片组成的——长尾西班牙语查询、多轮拒绝案例、新功能回归集、金融服务评分细则——每个切片都由指定的人员负责，每个切片都是从曾经的私有 notebook 提升而来的，每个切片都经过版本化处理且可见。当工程师在实际环境中发现新的故障模式时，提升路径 才是关键：该案例被添加到受保护的切片中，切片负责人对其进行审核，排行榜现在反映了新的事实真相，团队的其他成员在一天之内就开始针对它进行迭代。没有提升路径，每个私有案例永远都只是私有案例。

每个案例的溯源元数据。 受保护切片中的每个案例都带有一个简短的注释：它防范哪种故障模式，是哪个事件或 PR 添加了它，谁负责它。这听起来很官僚，直到评测套件拥有了一万个案例，而有人想知道某个特定的回归是否允许发生。有了溯源信息，你可以在三十秒内回答这个问题。没有它，你只能针对 Git blame 和旧的 Slack 频道开展为期六周的考古项目。

无效的折中方案

修复影子评估 (shadow evals) 最常见的尝试之所以失败，是因为半途而废。团队会采用共享的评估框架 (eval harness)，建立排行榜，但却不在 PR 中对其进行把关 (gate)。工程师们仍然保留着私人的 notebook，因为私人的 notebook 依然更快，共享框架仍然是可选的，而唯一的改变只是现在多了一个无人维护、让团队感到愧疚的仪表盘。六个月后，仪表盘的最后一次更新还停留在发布周，团队依然在运行影子评估——他们只是多了一个不用的工具。

约束行为的是准入门槛 (gate)，而不是工具。没有门槛的工具是对使用者的一种负担，也是对不使用者的一种借口。如果你不愿意根据共享评估结果来阻止合并，那么你实际上并没有在运行它；你只是在为其配备人员。

一个相关的折中方案：在 PR 中仅根据单一的共享评估分数进行把关，而不是根据细分切片 (per-slice breakdown) 的结果。这会奖励那些损害某个切片但提高了全局平均分的回归 (regressions)，而这种权衡正是工程师应该明确做出的，并由该切片负责人签字，而不是靠数学计算默默完成。PR 的评论应该显示每个切片的差异 (diff)，并且如果任何切片出现退化，都需要负责人签字确认，而不仅仅是打印一个综合评分。

六个月后的理想状态

一个真正弥合了影子评估差距的团队，在三个可观察的方面表现得与众不同。

首先，当你询问工程师为什么要进行特定的提示词 (prompt) 更改时，他们会引用排行榜的 URL 和发生变动的切片。他们不会截取 notebook 的图。你在接下来的十分钟内就可以在自己的电脑上复现这个结果。

其次，当出现回归时，复盘 (postmortem) 能精确地识别出评估差距：“这种失败模式没有被任何核准的切片覆盖；我们正在将其添加到 multi-turn-refusal 切片中，并且该切片的负责人已经签字。”团队将评估覆盖率视为一等公民级别的技术债，其重要性与服务工程团队中缺失的单元测试相同。

第三，排行榜非常无聊。大多数时候，它的波动只有零点几分。这种“无聊”就是信号——这意味着团队不再依赖戏剧性的私人突破，而是开始发布具有复利效应的、渐进式的共享进展。无聊的排行榜正是健康的 AI 工程组织的样子。而在 Slack 中截图展示的戏剧性私人突破，则是从内部看一个不健康组织的表现，这正是团队长期陷入陷阱的原因。

从私人 notebook 到共享汇总 (rollup) 的转变不是工具升级，而是团队内部对于“什么才是证据”这一认知的改变。除非私人 notebook 的评估数据变得不可接受——礼貌但坚定地——否则工程师会继续运行它们，因为局部激励总是会比全局激励更快。这种约束力来自于合并准入门槛、核准的切片、指定的负责人以及任何人都可以重新运行的排行榜 URL。工具是简单的部分。契约才是困难的部分，而契约才是真正弥合差距的关键。