Eval 异味目录：让你的 LLM 评估套件比没有评估还糟糕的反模式

我去年合作过的一个团队拥有一套包含 847 个测试用例的评估套件，仪表盘一片绿色，发布节奏从外部看非常有纪律。然而，他们的旗舰摘要功能开始为大约二十分之一的客户支持线程生成言之凿凿的错误摘要。该能力的评估得分在连续六个月里一直保持在 94%。当我们对这套套件进行审计时，发现问题并不在于评估在撒谎。问题在于这些评估已经悄然腐化，测量了错误的东西，惩罚了正确的模型行为，并与它们正在评估的模型共享盲点。这套套件并不是像传统测试那样以一种响亮的方式崩溃，而是像温度计一样坏掉了——无论你把它放在哪里，它都显示室温。

测试异味（Test smells）在传统软件领域已经被研究了二十年。Van Deursen 的目录、xUnit 模式分类以及更近期的工作都记录了那些看起来正常的测试如何能积极地损害代码库——通过编码错误的规范、使重构变得昂贵、以及制造让真正的 bug 隐藏得更深的虚假信心。LLM 评估是一个非常新的领域，以至于同类的文献几乎不存在，但同样的动态已经发生在我交流过的每个 AI 团队中。不同之处在于，LLM 评估异味具有传统测试所不具备的机制：训练数据重叠、随机输出、评委模型反馈循环、能力漂移。你不能只是简单地移植旧的分类体系，你需要一个新的。

接下来是我一直在积累的目录——我见过的五种将评估套件变成负担的“异味”，以及每种异味的重构模式。目标不是抛弃你的评估，而是恢复它们的信号，就像测试重构可以恢复生产代码中的信号一样。

异味 1：训练-评估数据泄漏 (Training-Eval Data Leakage)

这种异味表现为：你的评估得分高得可疑，但与用户实际体验到的功能不相关。具体来说，在你的模型可能看过的任务上得分很高，而在它可能没看过的任务上得分很低。

这是被记录最多的 LLM 评估失败案例，它至少有三个团队容易混淆的机制。首先是经典的基准测试污染：模型在包含测试集的语料库上进行了训练，因此评估测量的是记忆力而非能力。其次是微妙的操作性泄漏：你的评估集是使用你正在评估的同一个模型生成的（例如由 GPT-4 生成的“黄金数据集”，然后你用它来测试 GPT-4 变体），分布会悄悄地编码评估者的偏好。第三是 LLM 作为评委（LLM-as-judge）设置中的偏好泄漏，其中评委模型是在被评判模型产生的数据（或与其密切相关的数据）上进行微调的，因此评委系统性地高估了某些风格。

最近的研究表明，即使是缓解策略也可能无法实现其初衷。通过代码重构来掩饰基准测试、合成扰动、改写——在所有设置下，没有一种方法能既有效又忠实于原始评估意图。实际的教训不是污染无法修复，而是任何超过六个月的评估集，特别是从类网页资源中整理或由前沿模型生成的，都应该被视为已污染，直到证明并非如此。

重构方法：按出处拆分你的评估套件。为每个案例标记其来源——生产环境合成、手写、公开基准测试、模型生成。按每个存储桶（bucket）跟踪分数，而不是汇总分数。当不同桶之间的差距很大时（公开基准测试比新鲜的生产衍生案例高出 15 分以上），你就获得了一个可以采取行动的污染信号，而不是一个谜团。添加一个源自过去 30 天生产数据的“新鲜案例”队列，并将其回归的权重设置得比旧的公开桶更高。随着时间的推移，将公开基准测试案例完全从准入（gating）套件中移除，仅保留作为历史参考。

异味 2：脆弱的精确匹配断言 (Brittle Exact-Match Assertions)

这种异味表现为：你的测试结果是红色的，但输出是正确的。“答案是 42” 无法通过预期的 “42” 验证。JSON 键顺序的交换破坏了断言。一个开始将数字包裹在单位中的模型（例如 “42 ms” 而不是 “42”）摧毁了你的通过率，而且没人能分清这种回归是真的还是假的。

这直接移植自传统测试异味文献，其中“断言轮盘赌”（Assertion Roulette）和“脆弱测试”（Fragile Test）已被分类多年。在 LLM 评估中，它呈现出一种特别有害的形式，因为自然语言没有规范的表面形式。模型生成成千上万种有效的改写之一，而你的断言只接受一种。每次模型升级都会洗牌措辞的分布，而你的评估套件会因为模型漂移到另一种有效的形式而惩罚它。

精确匹配仍然有其地位。格式至上的结构化输出（SQL 查询、函数调用、机器可读的枚举）应该使用精确或近乎精确的相等性进行检查——这不是异味，这是正确的工具。这里的异味是将精确匹配应用于你实际上关心语义等价的自由形式输出。

重构方法：将自由形式的断言提升到语义层。对于简短的事实性回答，使用提取并归一化断言（解析数字、去除单位、进行比较）。对于较长的输出，优先选择基于属性的检查（“答案包含正确的实体”、“答案不违背来源”、“答案不超过两句话”），而不是全字符串相等。对于真正的开放式文本，使用具有明确标准的量表评分评委评估（rubric-graded judge evaluation），而不是 BLEU 风格的词汇重叠。当你确实需要根据参考文本进行断言时，使用具有质量控制阈值的语义相似度，而不是精确匹配——并固定用于比较的嵌入模型，以便阈值在不同运行中保持意义。

坏味道 3：评测腐化 (Eval Rot)

现象：你的评测套件通过了，但用户却在抱怨，这两组信号不再重叠。生产环境出现的失败方式是你的套件从未设计去检测的，因为你的套件是针对两代前的模型失败模式设计的。

在传统测试中，这有时被称为“测试腐化”或“测试相关性衰减”，但 LLM 评测腐化的速度更快、更无情。模型能力每几个月就会发生变化。产品界面在扩张。用户行为在适应模型的怪癖，这改变了输入分布。一个在 2024 年初围绕 GPT-4 的拒绝模式编写的评测套件，很大程度上是在测量一个已经不存在的产物——更糟糕的是，它在因为新模型没有重现旧行为而惩罚它们。该套件测量的不是质量，而是与旧模型特有习性的向后兼容性。

这里有一个特定的子坏味道，我称之为“能力锚定”（capability pinning）：编写断言是为了要求特定的推理路径（“响应必须提到中间步骤 X”），而不是正确的结果。当一个能力更强的模型通过不同的路径得出正确答案时，测试就会失败，而一名急于求成的工程师会通过提示词（prompting）将模型“修复”回旧路径。能力锚定会将你的评测套件变成一种回归强制机制，积极地抵制模型的改进。

加载中…