【强化学习与大模型后训练】19｜后训练评测：对齐、推理、安全与回归

后训练的目标不是让训练奖励变高，而是让模型在真实使用和可复现评测中变好。

这句话听起来简单，却是 RLHF、DPO、GRPO、RLVR 最常见的工程分水岭。

如果评测只覆盖偏好胜率，模型可能牺牲事实性和安全性。

如果评测只覆盖数学正确率，模型可能变得不善于对话。

如果评测只看目标任务，模型可能在非目标能力上付出对齐税。

如果评测本身有长度偏置、位置偏置或污染，训练就会围绕错误代理优化。

本文讨论后训练模型该如何评测：偏好与对齐、LLM-as-judge、推理基准、污染风险、安全评测、能力回归，以及把 eval 纳入训练闭环时需要警惕什么。

一、后训练评测要回答四个问题

1.1 模型是否更符合偏好

偏好评测关注回答是否更有用、更清楚、更符合指令。

典型形式是 pairwise comparison。

给定同一个 prompt，让模型 A 和模型 B 生成回答，再由人类或 judge 判断哪一个更好。

结果通常报告 win-rate、tie-rate、loss-rate。

这种评测最接近 RLHF 的初始目标。

它也最容易受 judge 偏差影响。

1.2 模型是否更会推理

推理评测关注可验证正确性。

典型基准包括 GSM8K、MATH、代码题、逻辑题和工具调用任务。

这类评测的优点是目标更清楚。

答案可以用 exact match、数值匹配、单元测试或程序验证器判断。

缺点是容易受数据污染、提示格式和采样策略影响。

1.3 模型是否更安全

安全评测关注有害请求、越狱、隐私、偏见、违法指导、恶意代码等风险。

后训练常会同时优化 helpfulness 与 harmlessness。

如果 helpfulness 权重过强，模型可能在危险请求上过度配合。

如果 safety 权重过强，模型可能在正常请求上过度拒答。

安全评测必须同时看“该拒答时拒答”和“不该拒答时不拒答”。

1.4 模型是否在其他能力上回退

后训练经常针对某个目标分布优化。

例如更会聊天、更会数学、更会工具调用或更安全。

但模型原有能力可能下降。

这就是能力回归或对齐税。

因此评测不能只看目标任务。

必须保留一组非目标能力回归集。

二、偏好评测：pairwise win-rate 的价值与边界

2.1 pairwise 为什么常用

开放式回答很难给绝对分。

同一个回答可能在准确性、完整性、风格、安全性之间权衡。

Pairwise 比较把问题简化为“两个回答哪个更好”。

这与偏好模型训练数据的形式一致。

它也方便做 A/B 比较和 checkpoint 选择。

2.2 win-rate 的口径

一个基本 pairwise 评测包含：

• prompt 集。
• baseline 模型。
• candidate 模型。
• generation config。
• judge 规则。
• tie 处理方式。
• 统计置信区间。

缺少任意一项，win-rate 都很难复现。

例如 tie 计 0.5 还是忽略，会影响最终数字。

不同温度和 max tokens 也会改变胜率。

2.3 baseline 的选择

与 SFT 模型比较，可以衡量 RL 是否带来收益。

与上一 checkpoint 比较，可以用于早停。

与强开源模型比较，可以评估外部竞争力。

与产品线上版本比较，可以支持发布决策。

不要把所有 baseline 混在一个总表里。

不同 baseline 回答不同问题。

2.4 分任务 win-rate

总 win-rate 容易掩盖任务差异。

应该按任务类型切片。

例如：

• 信息问答。
• 写作改写。
• 数学推理。
• 代码生成。
• 安全边界。
• 多轮对话。
• 工具使用。
• 长上下文。

如果写作提升 10%，数学下降 10%，总胜率可能没有变化。

但产品含义完全不同。

2.5 人类评测与自动评测

人类评测更接近真实偏好。

但它成本高、速度慢、标注一致性有限。

自动 judge 便宜、快、可频繁运行。

但自动 judge 会继承模型偏差。

实际系统通常用自动评测做高频筛选，用人类评测做关键 checkpoint 校准。

三、LLM-as-judge：强工具，不是客观真理

3.1 MT-Bench 与 Chatbot Arena 的启发

Zheng 等人在 2023 年提出 MT-Bench 和 Chatbot Arena，系统研究了用强 LLM 作为 judge 评估聊天模型的做法。

这类方法让开放式对话评测可规模化。

它的核心优势是覆盖面广、成本低、速度快。

它的核心风险是 judge 偏差。

3.2 位置偏置

位置偏置指 judge 更倾向选择先出现或后出现的回答。

如果 A/B 顺序固定，模型可能因为位置而赢。

解决方法是交换顺序评测两次，或随机化位置并记录顺序。

当两次顺序给出不同结论时，可以记为 tie 或人工复核。

3.3 长度偏置

长度偏置指 judge 更倾向选择更长、更详细的回答。

RL 训练很容易利用这种偏差。

模型学会写更长回答，judge win-rate 上升，但人类可能觉得啰嗦。

Dubois 等人在 Length-Controlled AlpacaEval 中专门研究并缓解了这一问题。

后训练评测中，长度控制不是装饰，而是防止奖励黑客的重要机制。

3.4 风格偏置

Judge 可能偏爱某种语气、格式或自信表达。

例如更喜欢列表、更喜欢免责声明、更喜欢“让我们一步步思考”。

如果训练 reward 或评测 judge 都偏爱这种风格，模型会快速模板化。

这会让 win-rate 虚高。

人工抽样检查能发现这类问题。

3.5 自评偏置与模型家族偏置

如果 judge 与被评测模型来自同一模型家族，可能更偏爱相似风格。

如果 judge 见过某些模板，也可能高估这些模板。

因此关键评测最好使用多个 judge 或人类校准。

不要把单一 judge 的分数当作绝对真理。

3.6 Judge prompt 是评测协议

LLM-as-judge 的 prompt 本身就是评测协议。

它必须版本化。

它应该明确评价维度、tie 规则、安全优先级、长度处理和输出格式。

修改 judge prompt 等于修改评测基准。

结果不能直接与旧版本比较。

3.7 一个简化的 judge 输出格式

{
  "winner": "A",
  "confidence": "medium",
  "criteria": {
    "instruction_following": "A",
    "factuality": "tie",
    "clarity": "A",
    "safety": "tie"
  },
  "rationale": "A answers the request more directly without adding unsupported claims."
}

结构化输出方便统计。

但 rationale 仍然可能包含 judge 幻觉。

关键决策不要只看 rationale。

四、AlpacaEval 与长度控制

4.1 AlpacaEval 的定位

AlpacaEval 用自动 judge 比较模型回答与参考模型回答。

它适合快速衡量 instruction-following 和通用助手风格。

它不是数学、代码或安全的全面评测。

把 AlpacaEval 分数当成总能力分，是误用。

4.2 长度控制版本的意义

Dubois 等人的 Length-Controlled AlpacaEval 试图减少模型通过回答更长获得更高胜率的问题。

它提醒我们：后训练评测中的“胜率”不是自然物理量，而是评测协议产物。

当协议偏向长回答，模型就会学会变长。

当协议控制长度，模型必须更依赖内容质量获胜。

4.3 训练与评测的耦合

如果训练 reward 使用类似 judge，评测也使用同类 judge，就会形成闭环过优化。

这种闭环很高效，也很危险。

高效在于它能快速提升自动指标。

危险在于它可能只提升 judge 偏爱的表面特征。

因此要保留与训练 reward 独立的评测集和 judge。

4.4 报告长度相关指标

任何偏好评测都应报告：

• candidate 平均长度。
• baseline 平均长度。
• 长度分桶胜率。
• 长度控制前后分数。
• 截断率。
• EOS 率。

如果 win-rate 提升主要来自长度变长，应谨慎解释。

五、推理评测：GSM8K、MATH 与可验证任务

5.1 GSM8K

Cobbe 等人在 2021 年提出 GSM8K，用于小学数学文字题推理。

它的优点是题目自然语言化，答案可验证，适合观察 chain-of-thought 或直接解题能力。

它的局限是覆盖范围有限，而且公开时间长，污染风险需要关注。

5.2 MATH

Hendrycks 等人在 2021 年提出 MATH，覆盖更难的竞赛数学题。

它比 GSM8K 更挑战符号推理、多步推导和领域知识。

后训练如果声称提升推理能力，MATH 类基准常被纳入评测。

但提示模板、答案抽取和采样次数会显著影响结果。

5.3 代码与单元测试

代码评测常用单元测试或隐藏测试判断正确性。

它比 judge 偏好更客观。

但也会受测试覆盖率影响。

模型可能通过硬编码、格式投机或利用公开题库污染获得高分。

因此代码评测要关注去重、隐藏测试和执行安全。

5.4 pass@k 与采样策略

推理和代码任务常报告 pass@1 或 pass@k。

pass@1 衡量单次回答质量。

pass@k 衡量多次采样中是否能产生正确解。

RLVR 训练常通过多样采样获得学习信号。

评测时必须明确 k、temperature、top-p 和答案选择规则。

否则不同论文或实验结果不可比。

5.5 过程与最终答案

数学模型可能最终答案对，但推理过程错。

也可能过程合理，最终抽取错。

如果产品需要可解释推理，评测不能只看最终答案。

如果只需要自动求解，最终答案更重要。

评测目标要与使用场景一致。

5.6 污染问题

公开基准进入训练语料后，评测会高估能力。

污染可能来自预训练语料、SFT 数据、偏好数据、合成数据或 RL prompt 池。

处理方法包括：

• 去重和近重复检测。
• 使用时间切分后的新题。
• 保留私有 holdout。
• 对可疑题目做人工审查。
• 报告数据构造流程。

污染不能完全消除，但可以降低和透明化。

六、安全评测：拒答不是唯一目标

6.1 安全评测的两类错误

安全模型有两类错误。

第一类是假阴性：危险请求没有拒答。

第二类是假阳性：正常请求被错误拒答。

只优化拒答率会制造过度保守模型。

只优化 helpfulness 会制造风险模型。

安全评测必须同时报告两类错误。

6.2 越狱与鲁棒性

越狱评测检查模型在诱导、角色扮演、编码、翻译、分步请求、多轮上下文下是否泄漏有害内容。

后训练模型可能在标准安全 prompt 上表现好，却在组合攻击下失败。

因此安全评测要包含多轮和变体。

还要记录模型是否给出替代安全建议，而不是只输出模板拒答。

6.3 安全与能力的边界

有些请求表面敏感，但有合法用途。

例如网络安全教育、化学安全、医疗科普、法律信息。

模型需要区分高层解释、风险提醒和可操作危害步骤。

评测集应该覆盖边界案例。

否则模型会学成“看到关键词就拒答”。

6.4 安全 judge 的偏差

LLM-as-judge 也可用于安全评测。

但 judge 可能过度保守或过度宽松。

安全评测最好结合规则、专家标注和模型 judge。

对于高风险领域，自动评测只能做筛选，不能替代审查。

6.5 训练 reward 与安全 eval 分离

如果安全 reward 与安全 eval 完全同源，模型可能过拟合规则。

例如学会避开关键词，而不是理解风险。

应保留独立红队集和新型攻击集。

发布前还要做人工红队或专家审查。

七、能力回归与对齐税

7.1 什么是对齐税

对齐税指模型在变得更符合某些偏好或安全目标时，其他能力下降。

它不是必然发生，但在后训练中常见。

原因可能是 KL 约束不足、数据分布偏窄、奖励偏好单一或训练步长过大。

7.2 回归集应该覆盖什么

回归评测至少覆盖：

• 通用问答。
• 数学推理。
• 代码生成。
• 写作与总结。
• 多语言。
• 长上下文。
• 工具调用。
• 安全边界。
• 拒答校准。
• 指令遵循。

目标任务之外的能力越重要，越应该单独看。

7.3 checkpoint selection

最大奖励 checkpoint 未必是最好 checkpoint。

最佳发布点通常是多指标折中。

例如：偏好胜率提升，KL 未超过目标，安全不退化，数学不退化，长度未异常上升。

这类选择需要 dashboard，而不是单个 scalar。

7.4 早停策略

可以设置硬门槛。

例如 KL 超阈值停止。

安全假阴性超过阈值停止。

回归集下降超过阈值停止。

也可以设置软策略，在多个 checkpoint 中选择 Pareto 前沿。

关键是规则在实验前写清楚。

八、eval-as-part-of-the-loop：奖励就是评测代理

8.1 训练奖励与评测指标的关系

RL 中的 reward 可以看作某种评测代理。

如果 reward 与真实目标一致，训练会推动模型变好。

如果 reward 只是表面代理，训练会放大奖励漏洞。

这就是 Goodhart 定律在后训练中的体现。

8.2 把 eval 纳入循环的好处

周期 eval 可以用于早停、超参选择、prompt 采样重加权和 reward 修正。

它让训练不再盲目追逐 reward。

例如当 reward 上升但 length-controlled win-rate 不升时，可以触发人工审查。

当数学正确率下降时，可以减少写作类 prompt 权重或加强 KL。

8.3 把 eval 纳入循环的风险

如果过度按 eval 调参，eval 也会被过拟合。

多次查看私有测试集会泄漏信息到开发过程。

因此要区分 dev eval、validation eval 和最终 holdout。

开发期间高频使用 dev eval。

关键发布前只少量使用 holdout。

8.4 可验证环境的趋势

RLVR 把 reward 从偏好模型转向可验证结果。

这让 reward 更接近 eval。

数学答案、代码测试、游戏胜负、工具任务成功率都可以成为训练信号。

但可验证不等于完整。

可验证环境仍然可能奖励投机解、格式投机或测试集漏洞。

九、实用评测流水线

9.1 固定输入与固定配置

评测必须固定 prompt、模板、系统提示、解码参数和答案抽取规则。

任何改变都要版本化。

如果训练中途改了 chat template，旧评测不能直接比较。

如果 max tokens 改了，长度与正确率都会变化。

9.2 多层评测频率

可以分三层频率。

高频小评测：每若干 iteration 跑少量固定 prompt，检测趋势。

中频标准评测：每个 checkpoint 跑主要偏好、推理、安全、回归集。

低频人工评测：只对候选发布版本做深入审查。

这样能兼顾成本与风险。

9.3 统计置信

小样本 win-rate 波动很大。

应报告置信区间或 bootstrap 估计。

不要因为 0.5% 的自动胜率差异就宣布模型显著更好。

对于高成本人评，样本设计和一致性检查同样重要。

9.4 失败样本库

每次评测都应该保留失败样本。

失败样本要能回放：prompt、模型回答、baseline 回答、judge 输出、版本、采样配置。

失败样本库是下一轮数据构造和 reward 修正的重要来源。

9.5 lm-eval-harness

EleutherAI 的 lm-eval-harness 是常用的语言模型评测工具。

它提供统一任务接口、prompt 模板和结果聚合方式。

对于标准 NLP/推理任务，它能减少重复工程。

但开放式偏好评测、安全红队和产品特定任务通常仍需自定义 harness。

9.6 报告模板

一个后训练 checkpoint 的评测报告至少包含：

• 模型版本与训练数据版本。
• baseline 版本。
• 解码参数。
• 偏好 win-rate 与长度控制结果。
• 推理任务正确率。
• 安全假阴性与假阳性。
• 回归集变化。
• 代表性失败案例。
• 与训练 reward/KL/length 曲线的对应关系。

十、评测污染与数据治理

10.1 污染不是只发生在预训练

后训练阶段也会污染评测。

SFT 数据可能包含 benchmark 解答。

偏好数据可能来自 benchmark prompt。

合成数据可能由模型看过的题目生成。

RL prompt 池可能混入 eval 题。

10.2 去重粒度

完全字符串去重不够。

题目可以改写、翻译、换数字或换格式。

需要近重复检测、embedding 检索、n-gram 相似度和人工抽查结合。

对于数学和代码题，还要检查结构相似。

10.3 版本化数据

每个 eval 集应该有版本号。

每个训练数据源也应该有版本号。

当发现污染时，能追溯哪些实验受影响。

没有版本化，污染只能靠猜。

10.4 私有 holdout

私有 holdout 的价值在于减少开发过拟合。

它不应频繁用于日常调参。

也不应把失败样本直接加入训练后继续报告同一 holdout。

一旦 holdout 被用于数据构造，它就不再是 holdout。

十一、与训练稳定性的连接

11.1 训练指标预警，评测指标定案

18｜训练稳定性 讨论了 KL、熵、长度、ratio 等训练信号。

这些指标能快速发现异常。

但它们不能替代评测。

KL 稳定不等于模型更好。

Reward 上升不等于人类更喜欢。

Entropy 合理不等于安全。

11.2 评测也会反哺训练

评测发现长度偏置，就要回到 reward 和采样设置。

评测发现数学回归，就要调整 prompt 混合或 KL。

评测发现安全假阳性，就要检查 safety reward 是否过强。

评测发现 judge 偏差，就要修改自动评测协议。

这就是后训练闭环。

11.3 不要把 leaderboard 当产品目标

公开 leaderboard 有价值。

它提供外部可比性。

但产品模型还要满足特定用户、延迟、成本、安全、风格和合规要求。

后训练评测应该同时包含公开基准和内部场景。

十二、小结：评测是奖励函数的现实校验

后训练评测不是训练结束后的报表。

它是奖励函数是否可信的现实校验。

偏好评测告诉我们模型是否更符合开放式人类偏好。

LLM-as-judge 让评测可规模化，但必须处理位置偏置、长度偏置和风格偏置。

推理基准提供可验证正确性，但要警惕污染和提示协议差异。

安全评测必须同时衡量危险请求放行和正常请求误拒。

能力回归评测防止模型在目标能力上前进、在其他能力上后退。

把 eval 纳入训练闭环可以更早发现问题，但也会带来 eval 过拟合。

一个可信的后训练结果，应该能回答：赢了谁、在哪些任务赢、代价是什么、评测是否独立、失败样本长什么样。

参考资料

论文与技术报告

• Lianmin Zheng et al., 2023, “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”, NeurIPS Datasets and Benchmarks.
• Yann Dubois et al., 2024, “Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators”.
• Karl Cobbe et al., 2021, “Training Verifiers to Solve Math Word Problems”, arXiv.
• Dan Hendrycks et al., 2021, “Measuring Mathematical Problem Solving With the MATH Dataset”, NeurIPS.
• Nathan Lambert et al., 2024, “Tülu 3: Pushing Frontiers in Open Language Model Post-Training”.
• Percy Liang et al., 2022, “Holistic Evaluation of Language Models”, Transactions on Machine Learning Research.

← 上一篇：18｜训练稳定性　|　下一篇：20｜前沿与展望 →