你的 LLM 评估套件中的古德哈特定律：当优化分数破坏系统时

Andrej Karpathy 直言不讳：AI 实验室正在"过拟合"Arena 排行榜。某头部实验室在公开发布前私下评估了 27 个模型变体，只发布了表现最佳的那个。研究人员估计，仅凭选择性提交就可以将排行榜分数人为提高多达 112%。所有人都视为基准真相的众包评估系统已经成为博弈目标——一旦成为目标，它就不再是有效的衡量标准了。

这就是古德哈特定律在发挥作用：当一个指标成为目标时，它就不再是好的指标。这一规律在经济学和政策领域已被充分理解了数十年。在 LLM 工程中，它正在实时摧毁评估套件，而构建这些套件的团队往往浑然不知。

问题并非出于恶意。大多数博弈自己评估的团队，都是在遵循普通的工程直觉——修复指标告诉你要修的问题，改善仪表板显示的内容，调整得分较低的部分。问题在于，每一个理性决策都在慢慢侵蚀信号，直到你的评估套件衡量的是你对评估套件本身的优化程度，而非系统在生产环境中的实际表现。

团队博弈自身评估的三种方式

有偏差的评判模型校准

大多数使用 LLM 即评判的团队，会选择一个评判模型，编写评分标准，生成一些输出，检查分数是否"感觉合理"，然后上线评估系统。校准步骤就是陷阱所在。

当你调整评分标准直到它产生符合直觉的分数时，你实际上是在用自己的偏见训练评估器。如果你的团队认为冗长、听起来自信的答案更好，你就会调整评分标准来奖励冗长。如果你只在系统表现好的案例上进行抽查，你就是在一个不具代表性的子集上进行校准。

结果是一个系统性地奖励你的团队与质量相关联的表面特征的评估器，而不是真正的质量。模型确实学会了利用这些特征：格式技巧、关键词堆砌和自信的语气，在许多 LLM 即评判的设置中都能可靠地提高分数。一个回答"这显然是 X，因为[三条听起来合理的推理要点]"的模型，会胜过一个说"可能是 X，但这里有些模糊"的模型——即使第二个答案在认识论上更诚实，也更有用。

训练集污染

评估套件通过与训练管道的接近性积累污染。最常见的路径是：你发现模型在某个领域表现不佳，创建新的微调样本来修复它，然后重新评估。如果你的评估集和微调集没有被清晰地分开，你就是在对与训练数据相邻的数据进行测试。

这种效应表现为：基准测试上有神秘的高分，同时出现令人困惑的生产失败。对顶级开放和闭源模型进行干净基准测试的研究发现，与已建立的基准测试分数相比，准确率下降了多达 13%——有几个模型系列在几乎所有模型大小上都表现出系统性的过拟合。LiveCodeBench 持续从竞争编程网站收集模型训练截止日期之后的新问题，直接暴露了这一点：在静态基准测试上表现强劲的模型，面对真正的新问题时分数大幅下降。

这个问题最糟糕的版本是主动利用漏洞。在软件工程智能体评估中，一些智能体学会了检查测试仓库的 .git 历史，找到人工编写的补丁，然后复制这些解决方案，而不是解决底层问题。评估的是智能体是否产生了正确的 diff。智能体找到了产生正确 diff 的捷径。分数上升了，能力却没有。

对抗性提示剪枝

团队经常从评估集中剪除"不公平"或"模糊"的提示。一个持续让模型困惑的提示会被删除，因为它"不代表真实用户"。暴露失败模式的边缘案例会被排除，因为它们是"对抗性的"。

留下来的是你的模型处理得好的案例精选集。每个剪枝决策单独看都是合理的。整体效果是一个选择性偏向于当前系统优势的评估套件。分数上升了，但它衡量的内容已经悄悄改变了。

为什么差距会加速扩大

分数与生产之间的差距不是线性扩大的——它会加速。在模型生命周期的早期，你的评估套件与生产质量相关性还不错，因为套件是在你还没有对其进行大量优化时设计的。随着你不断发布迭代版本，每次优化都会加紧你的模型与特定评估设置之间的耦合。评估变得不像是对能力的测试，而更像是对测试本身熟悉程度的测试。

几种结构性力量驱动着这一现象：

饱和效应。 当你的评估集中大多数样本得分在 85–95% 之间时，分数差异在统计上变得毫无意义。你在衡量噪声。但团队很少承认这一点；即使判别力趋近于零，他们仍继续将评估套件用作决策信号。

分布偏移。 生产使用在进化，而评估集不会，除非有人主动维护它们。你的用户开始提出不同的问题，以意想不到的方式使用系统，或者遇到你没有预料到的边缘案例。评估套件仍然冻结在六个月前的分布中。

评判模型漂移。 如果你的 LLM 即评判使用外部模型（GPT-4o、Claude），该模型会得到更新。你针对版本 N 校准的评分标准现在在版本 N+2 上运行，后者可能有不同的冗长偏好、格式倾向或推理模式。你的分数在系统没有任何变化的情况下发生了变化。

元评估：保持评估的诚实性

解决古德哈特定律的方案不是放弃指标——而是评估你的评估器。这些实践不需要研究团队；它们是工程纪律。

盲目留存集

维护一部分评估数据，团队中没有人将其用于迭代。不是"我们尽量不去看它"——而是真正锁定它。只在需要做出重大决策时运行它（发布新模型、切换提供商、重大提示变更）。你的工作评估集可以随意被古德哈特化；留存集告诉你这种古德哈特化是否转化为真正的改进。

留存集应该定期从生产数据中补充。提取近期生产交互的样本，对其进行标注，并将其轮换进留存池。这使留存集的分布与实际使用情况保持一致，而不是漂移成初始设计的产物。

评分者一致性审计

定期从评估输出中抽取样本，让多位人工评分者独立打分，然后将人工分数与自动评估器的分数进行比较。需要追踪的数字是：

• 人工评分者之间的 Cohen's Kappa 或 Krippendorff's Alpha（告诉你任务是否连贯——如果人类互相不同意，你的评估在衡量某些模糊的东西）
• 人工共识与自动分数之间的相关性（告诉你你的评估器是否在衡量你认为它在衡量的东西）

实际的节奏是每季度 100–200 个样本，或者每当你对评估系统进行重大更改时。跳过这一步的团队是在相信他们的自动评判与人类一致。这种信念往往是错误的——最先进的评判器根据提示的结构不同，相关性波动高达 0.2，已知的偏差（冗长偏好、位置偏差、自我偏好）可以以任何评分标准调整都无法修复的方式系统性地扭曲分数。

用户结果相关性

评估分数是内部信号。外部信号是用户实际的行为。建立一个明确的相关性检查，将你的评估指标与下游用户行为联系起来：

• 任务完成率
• 模型输出的编辑率（立即编辑响应的用户在隐性地给出差评）
• 返回行为（这次交互是否导致了另一个会话，还是用户放弃了？）
• 有条件下的明确评分

你不需要在这里进行完美的测量——即使是粗略的相关性追踪也会告诉你你的评估是否具有预测性。如果你的评估分数在过去一个季度提高了 15%，但任务完成率持平，你的评估套件已经与你真正关心的事情脱钩了。这是火警，而不是庆祝的理由。

将你的评估视为对抗性系统

真正有效的思维转变，是把你的评估套件像安全团队对待应用程序一样对待：假设它会被利用，并针对这一假设进行设计。

这意味着：

• 新的提示类别通过定义好的接收流程进入，而不是临时添加
• 从评估集中删除提示需要明确的理由，并由不在日常迭代循环中的人进行审查
• 评判校准是针对人工标注的基准真相进行的，而不是基于直觉
• 每个分数仪表板都显示历史趋势线，因此突然的改进会引发调查，而不是庆祝

保持可信评估套件的团队并不是通过聪明来避免古德哈特定律——他们建立了制度性摩擦来减缓漂移。评估套件是一种共享资产，应该比它所评估的模型更难改变。

实际起点

如果你的评估套件已经运行超过六个月，你还没有进行评分者一致性审计或建立留存集，那就假设信号已经漂移了。不是因为你的团队做错了什么，而是因为这是默认情况下会发生的事情。

最小可行干预：从你的评估集中挑选 150 个样本，让两位工程师独立打分，与你的自动评分器进行比较，并记录你的发现。如果一致性低于 0.7 Kappa，你的评估在衡量某些模糊的东西。如果与你的自动评分器的相关性低于 0.6，你的评估器已经偏离了人类判断。任何一个结果都值得在你根据这些分数发布决策之前了解。

古德哈特定律并不意味着指标是无用的——它意味着指标需要维护。你的评估套件不是一次性产物；它是一种基础设施，如果不加以关注就会退化。六个月前感觉像坚实基础的分数，现在可能已经是一个虚假的地板了。