← 返回闯关手册
谁来验证「验证者」？（论文中文导读）
全称《Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences》。这篇 HCI 论文是「Judge 需要校准」这一理念的学术源头之一，正好为你收藏中《Grader》篇的校准实践提供理论依据。
一、要解决的问题
人工评估繁琐、代码评估能力有限，LLM 越来越多地被用来辅助评估 LLM 输出。但 LLM 生成的评估器（无论是 prompt 还是代码）继承了被评估模型的所有问题，因此评估器本身还需要人来验证——这就是「谁来验证验证者」的递归问题。论文提出一种「混合主动」（mixed-initiative）方法：让 LLM 生成的评估函数与人类需求对齐。
二、EvalGen 系统：边打分、边生成、边对齐
论文实现了名为 EvalGen 的界面，工作流程是：
- 系统辅助用户生成评估标准（criteria）并实现为断言（Python 函数或 LLM 评分 prompt）；
- 在生成候选实现的同时，请人类对一小部分 LLM 输出打分；
- 用这些人工打分来选择与人类判断更对齐的评估实现。
效果：缺陷召回率 0.73，优于全自动基线方法 SPADE 的 0.49，且所需断言更少。
三、核心发现：标准漂移（Criteria Drift）
论文最重要的概念贡献：用户需要标准才能给输出打分，但给输出打分的过程又帮助用户定义标准——评估标准不是能事先完全写死的（a priori），而是依赖于你实际观察到的模型输出。有些标准只有在看到具体输出后才浮现。
这对实践的含义非常直接：
- 不要指望第一天就写出完美的 Rubric——先看至少 20 个样本再定标准；
- 评估循环需要一个内层迭代环：边打分、边改标准、边实现断言；
- 这也解释了为什么 Hamel Husain 强调「先开放编码、再写评估器」，以及为什么「为想象的错误写评估」往往失败；
- 对「自动提示优化」类工具保持警惕：它们只能在预定义指标上爬山，无法发现新失败模式。
四、用户研究的其他发现
- 整体上用户支持 EvalGen 这种人机协同方式；
- 对齐是一个主观且迭代的过程，不是一次性设置；
- LLM 评估器比代码断言更难取信——因为代码可以被人直接查看和编辑，而 prompt 的行为更难预测。
五、与你收藏其他文章的关系
| 本文概念 | 对应实践文章 |
|---|
| 验证者需要被验证 | 《Grader》：Judge 上线前先做 Eval，用人工金标校准 |
| 标准漂移 | Hamel FAQ：反对评估驱动开发，先做错误分析 |
| 人机混合主动 | 《Grader》三层架构：程序 → Judge → 人工仲裁 |