当你的评测结果不一致时：在数据互相矛盾时的一套信号优先级体系

这是周二的早晨，也就是 Prompt 更改上线到一半流量后的那一周。你打开四个仪表板。LLM 评审员（LLM judge）评分的留存黄金集显示 +8%。每周对生产流量进行抽样的真人评估小组显示无变化。下游转化率的 A/B 测试显示 -2%。点赞率（thumbs-up rate）持平。四个信号，四个结论，而十五分钟后就有一个站会，会上有人会问你到底是发布这个 Prompt 还是回滚。

你很容易倾向于选择那个能证实你原本意图的数字——团队也会这样做，因为会议上没有人拥有一套关于哪个信号获胜的书面规则。这种不一致并非测量错误。这是一个在没有层级体系的情况下强行把四个评估器凑在一起的系统的必然产物。缺乏这种体系的代价是，每个发布周都会变成一场关于该信任谁的数据的辩论。

这种情况并不罕见。这是任何具有多个评估维度的 LLM 产品的常态。这些信号的设计初衷就是不一致的——它们在不同的节奏下，针对不同的人群，回答不同的问题。将它们视为可以互换的，正是导致僵局的原因。解决方法不是更好的评估方式，而是一个明确的信号优先级体系（signal hierarchy），在下一次发生分歧之前就写下来，并规定每个信号在什么情况下可以推翻其他信号。

为什么四个信号指向四个方向

每一个评估器都针对不同的基准真相（ground truth）回答不同的问题。一旦你知道每个评估器实际测量的是什么，这种不一致就是信息，而不是噪音。

LLM 评审员黄金集（LLM-judge golden set） 测量的是你的 Prompt 更改是否在团队手工策划的固定输入分布上提高了性能。它成本低、速度快，且在每个 PR（拉取请求）上都会运行。它也倾向于团队已知如何编写的案例，并由一个校准精度与你的产品独立漂移的模型进行评分。这里 +8% 的提升意味着“评审员认为今天的版本处理测试用例的效果比昨天的版本处理昨天的效果更好”。这是一个真实的信号，只是它所代表的意义比人们理解的要窄。

真人评估小组（human-rater panel） 测量的是经过培训的人员根据评分标准对每周生产流量样本进行评分时，是否看到了差异。人类评估速度慢、成本高且差异大，但他们是其他所有指标的校准锚点。当人类说“没有变化”而评审员说“+8%”时，最可能的解释是评审员的评估标准在你不知不觉中发生了偏移（模型升级、Prompt 格式更改、新的 few-shot 示例），而人类并不认为外部环境随之发生了改变。

转化率 A/B 测试 测量的是 Prompt 更改是否在真实会话中影响了真实用户的下游业务指标。它是唯一能证明所交付价值的信号。它也是噪音最大的：转化率有几十个上游原因，测试的样本量通常不足以支撑其效应量（effect size），且指标的响应会有几天的延迟。第一周看到的 -2% 读数更像是掷硬币的结果，而不是最终定论，但团队通常将其视为基准真相，因为这是领导层唯一会看的数字。

点赞率（thumbs-up rate） 测量的是那些选择提供明确反馈的用户是否对回复给出了正面评价。关于它有三点需要了解：只有 1–5% 的会话会收到评价；分布偏向于投诉（负面反馈偏差）；反馈的不对称性意味着点赞率主要衡量的是你是否失败得很惨，而不是你是否取得了更大的成功。持平的点赞率可能意味着“没有变化”，也可能意味着“在严重偏差样本的噪声底线内波动”。它很少是驱动“发布/不发布”决策的信号。

优先级体系：在什么条件下哪个信号获胜

信号优先级体系并不是“将四个指标从最好到最差排序”。它是一个记录在案的地图，说明了在什么条件下哪个信号获胜，并对何时允许某个信号推翻其他信号制定了明确的规则。在实践中行之有效的映射大致如下：

• 评审员（Judge） 用于快速迭代。它是内部循环。用它来决定哪些 Prompt 变体值得运行更昂贵的评估。永远不要用它来推翻相反方向的人类或 A/B 测试信号——评审员可能会失准，评审员显示 +8% 而人类评估小组持平，这是评审员发生漂移（judge drift）而非性能提升的最典型特征。
• 人类（Humans） 用于校准。真人评估小组是你对于好的输出长什么样的基准真相。通过它，你可以检测到评审员是否发生了漂移、评分标准是否过时或任务是否发生了转变。它不是关于用户想要什么的基准真相——人类是在真实会话所不具备的受控上下文中进行评分的。
• A/B 测试 用于确定影响的基准真相。A/B 测试是唯一能证明更改确实影响了与用户价值挂钩的指标的信号。当样本量充足、样本组与更改匹配、指标已预先注册且运行时间符合指标响应周期时，它可以推翻评审员和真人评估小组的结论。当缺失上述任何一项时，A/B 测试充其量只是一个方向性信号，而非基准真相。
• 遥测数据（Telemetry）（点赞、延迟、错误率）用于监控。生产环境的遥测数据比任何其他信号都能更快地反映出偏移、滥用、成本激增和彻底的故障。它是烟雾报警器，而不是裁决书。持平的点赞率可能意味着成功，也可能意味着失败；但点赞率下降 30% 意味着必须立即停止发布。

由此得出的规则是：如果 A/B 测试结果为负且样本量充足，即使评审员信号为正也不发布。如果真人评估小组表示质量有所提高，且指标变动可以由已知干扰因素（季节性、流量结构变化、另一团队负责的界面的上游更改）解释，那么负面的 A/B 测试结果也不一定需要回滚。持平的点赞率本身永远不能决定发布或回滚任何内容。

把这些写下来。没有写下这些规则的团队每周都会重新争论，而拥有最多政治资本的团队成员将会获胜——这并不等同于获胜的是正确答案。

校准锚点：在发布受损前检测评测模型漂移

评测模型（judge）是成本最低的信号，也是你最依赖的信号。它也是最容易悄无声息发生漂移的信号。当评测模型向上漂移——即评分变得更宽松时——每个 prompt 变体看起来都像是一种改进，团队每周都在发布“改进”，而只有人工评审小组才会注意到实际的质量标准一直停滞不前甚至有所下降。

防御手段是评估集的一个冻结校准分片 (frozen calibration slice)。该分片先由人工评分一次，然后在每次模型升级、框架升级或评测模型 prompt 更改时，由评测模型重新评分。评测模型在这个冻结分片上的得分不允许作为你优化的变量。它是证明评测模型仍在测量上季度所测量内容的变量。如果在人工评分保持不变的情况下，评测模型在冻结分片上的得分发生了变动，说明评测模型已经发生了漂移。在重新锚定之前，所有依赖它的比较指标都已被污染。

几个实用的模式可以使这一机制生效：

• 保持评估集的一个分片冻结至少两个季度。不要向其中添加内容，不要针对它进行调优，也不要让它随评测模型的迭代而变化。
• 每当你更换评测模型、评测模型 prompt、评分标准（rubric）或 few-shot 示例时，都要用评测模型对冻结分片重新评分。将这一增量（delta）作为一级指标，记录在你的核心评估分数旁边。
• 定期（每月是一个不错的节奏）对线上流量中的评测模型判定结果进行 5–10% 的采样，并由人工重新评分。跟踪人工与评测模型的一致性随时间的变化。下降趋势意味着评测模型失效了、任务发生了转移或评分标准已过时——这三种情况都需要人工干预，而不是仅仅“发布下一个 prompt”。

这种规范带来的负担很小。跳过这一步的团队往往会花费一个季度的时间去追逐一个虚幻的回归，而结果却发现只是因为供应商升级了底层模型，导致评测模型评分变得更加严苛。

A/B 测试设计是前提，而非事后补充

A/B 测试与评测模型结果“不一致”最常见的原因是：A/B 测试是在评测模型说 prompt 看起来不错之后才建立的，其设计经不起数据的检验。测试运行在一个 prompt 更改预期不会产生影响的样本组上。选择某个指标是因为它容易查询，而不是因为它对变化敏感。从未计算过最小可检测效应（MDE），因此对于你可能看到的实际提升来说，测试的效能不足。获胜条件是在结果出来之后才决定的。

预注册（Pre-registered）的 A/B 测试设计能将 A/B 测试转化为可对齐的信号，而不是辩论的道具。三个最低要求：

1. 在测试运行前，预先注册指标、样本组和最小可检测效应。将这些写在文档中并分享，一旦结果开始产生，就不允许团队更改它们。样本组应与 prompt 更改所针对的人群相匹配——如果更改仅影响 5% 的意图分片，却针对全量流量运行 A/B 测试，会将效果稀释到无法察觉。
2. 针对你实际预期的效应量级来保证测试效能，而不是针对你希望能发现的效应量级。评测模型集中 +8% 的提升很少能转化为下游业务指标上接近的涨幅；如果你的测试效能只能检测到 5% 的转化率提升，那么对于产生真实但更小提升的更改，测试结果将显示为持平或充满噪音。效能不足的测试不是“不确定”——它们是淹没信号的巨大噪音。
3. 将运行时长与指标的响应时间相匹配。需要多天延迟才能完成的转化指标不能在三天内读取结果。因为团队缺乏耐心而在第三天叫停 A/B 测试，就像在只有 2% 的选区报票时就宣布选举结果一样。

一旦设计规范到位，A/B 测试与评测模型的不一致就变成了诊断性的，而非令人困惑的。评测模型说“+8%”而效能充足的 A/B 测试说“−2%”，这告诉你了一些具体的事情：prompt 的更改改进了评测模型评分的表面（可能是你团队策划的案例），但损害了 A/B 测试敏感的表面（可能是你的黄金集代表性不足的长尾意图）。这是一个有用的发现。这也是团队可以采取行动的发现，而不是争论该相信谁的数据。

组织失效模式：没有人负责指标对齐

更深层次的失败并不在于信号不一致，而在于没有一个角色负责解决这种不一致。负责 prompt 的团队引用评测模型。负责产品的团队引用 A/B 测试。负责留存的团队引用遥测数据。负责质量的团队引用人工评审。每个人都是诚实的。每个人都在选择能印证自己先验偏好的信号。会议以一种谁都不满意且没有任何产出的妥协告终。

指标对齐必须由一个拥有最终决定权的明确角色负责——通常是 AI 平台负责人或“评估主管”职能——并辅以一套当信号矛盾时的书面升级路径。信号层级结构是该角色执行的契约。该角色的工作不是每周重新审议这个层级结构，而是始终如一地应用它，并标记出层级结构不适用且需要修订的情况。如果没有这个角色，层级结构就会变成一份无人阅读的文档。

以下模式可以减少沟通中的摩擦：

• 层级结构在任何分歧发生之前由所有四个负责团队批准。发生分歧的那一周是谈判哪个信号获胜的最糟糕时机。
• 层级结构无法解决的分歧应上升为结构化的复盘，而不是 Slack 上的争论。产出应该是层级结构的修订，而不是一次性的决定。
• 信号层级结构本身每季度审查一次。世界在变——新的模型类别、新的评估方法、新的产品界面——上季度正确的层级结构本季度可能就不再适用。

将评估系统视为一项受维护的属性

实践者们在摸爬滚打中学到的教训是：多信号评估系统并非模型或提示词固有的属性。它是评估基础设施的一项受维护属性，需要你像对待任何其他生产系统一样投入严谨性：明确的契约、书面化的层级结构、校准锚点、漂移检测、明确责任人的升级路径，以及定期的审查节奏。

缺乏明确信号层级的团队在每个发布周都会反复争论应该信任哪个数字，这种代价在反映到指标之前，会先反映在日程表上：资深工程师忙于争论而非交付，提示词的改动在评审中搁置数日，只因无人敢拍板，A/B 测试在得出统计显著性之前就因耐心耗尽而被迫中止。解决方案枯燥乏味——一份文档、一份冻结切片、一项预注册测试、一个具名的负责人——但这正是“能指导决策的评估系统”与“只会产生足够多的数字来支持室内既定决策的评估系统”之间的本质区别。

在下一次分歧发生前，把层级结构写下来。下一次分歧已经排在日程表上了；你只是还不知道具体的日期而已。