聊到大模型后训练这一摊事，Nathan Lambert（下面我就叫他 Lambert）大概是少数会把“数据纪律”和“评估科学”反复掰开揉碎讲的从业者之一。他的核心判断我复述一下：大家花了太多时间调偏好优化算法的超参、试各种奖励模型变体，却很少有人认真回答“我们喂给算法的偏好数据到底干不干净”和“我们用来验收模型的评估指标到底可不可信”这两个问题。这篇文章就把这两个问题拆开讲一讲，顺便聊聊为什么 RL 数据与评估会从边角料变成未来几年的核心议题。
我是比较早把他的观点当“反潮流参考”来看的人。原因很简单：那个时期各个团队都在卷算法名目和训练框架，数据侧的文章通常没人看，因为不够酷。但跑过 RLHF 的人都知道，同样一套代码，换了一份偏好数据，结果能差出一个量级。数据问题才是那个真正卡脖子的东西。
1. 为什么“数据”会从 RL 的边角料变成核心议题
1.1 监督学习时代养成的“数据直觉”在 RL 这里不灵了
做 NLP 的人最早对数据的理解，基本是在监督学习里养成的：多收集样本、做清洗、控制类别均衡、划分 train/valid/test，然后丢给模型。这套流程在分类、生成式微调上都算成熟，团队里只要有人盯标签质量，效果一般不会太离谱。
但 RL 的数据完全不是同一个物种。RLHF 训练时我们用偏好对（preference pair）：同一个 prompt 下给出两个回答，告诉模型哪个更好。这条数据的信息量和监督学习里“输入-标签”完全不同，它描述的是一次相对比较，而不是一个绝对答案。
Lambert 多次提到一个判断：RLHF 的难点从来不只在算法侧，真正的瓶颈在数据侧——你是如何拿到这些“哪个更好”的判断的？哪些人做的判断？判断标准稳定吗？这些问题不解决，换任何花哨的偏好优化算法都只能得到随机结果。
1.2 行为数据与偏好数据：两条完全不同的数据生产线
很多人把 RL 的数据笼统理解为“用户反馈数据”，这其实是混淆了两种东西。
- 行为数据：模型与环境交互产生的轨迹，比如一个智能体玩游戏时的每一步动作和回报。这类数据的核心是“探索-利用”的平衡，它天然是序列结构的，带有时间上下文。
- 偏好数据：静态的、成对出现的比较型数据。比如两个回答让你选一个，它不关心生成过程，只关心人对输出结果的评价。
这二者的生产流程、噪声来源、清洗方式都完全不同。偏好数据的核心问题是裁判的可靠性：标注者是否理解任务？是否被提示词的措辞带偏？是否因为答案更长就觉得更好？行为数据的核心问题则是覆盖率：探索到的状态空间是否足够广。
我们在很多开源项目里看到的 RL 复现，其实根本没有分清这两类数据。有的团队把线上用户点击日志当成行为数据去训练，却忽略了点击率背后的人为偏好偏差；有的团队把几个标注员凭直觉写的比较对当成标准偏好数据，却没有检查标注一致性。这类问题在论文里很常见，因为大家默认数据是被设计好的，实际上它们只是“有”而已。
1.3 Lambert 反复强调的一个判断：数据是一门需要被设计的学科
Lambert 对“RL 数据科学”的强调，说到底就是一句话：数据收集要像实验设计一样被对待，而不是像挖矿一样被对待。
举个例子。今天大部分偏好数据集的构造流程是：从一个指令池里抽 prompt → 两个模型各生成一个回答 → 找标注者判断谁更好。看似简单，但每一步都有选择：指令池怎么建？模型用哪个？如果两个回答都烂，标注者怎么选？是否允许“都好”或“都差”？这些决定会系统性改变偏好分布，进而影响模型学到的对齐目标。
我在实际项目中踩过类似坑。某个早期实验里，我们用了另一个团队开源的偏好数据，跑完 DPO 后模型确实更“听话”了，但回答长度暴涨。后来核查数据才发现，那个数据集里超过 70% 的偏好对被人类标注者判给了更长更啰嗦的回答。模型学到的根本不是“更正确”，而是“更长”。
这类问题，靠调参和换算法是永远调不出来的。只有把数据当成研究对象，拆开来看它的分布和偏差来源，才可能根治。
2. 偏好标注的噪声陷阱：谁在当裁判，裁判有没有标准
2.1 两个答案之间真的存在“可比较的序”吗
主流 RLHF 工具链里，偏好数据最终都会被建模成 Bradley-Terry 模型（BT 模型）。它的核心假设是：任意两个回答 A 和 B，存在一个稳定的概率 P(A 优于 B)，这个概率只取决于二者的潜在奖励值之差。
这个假设放到人类判断里非常理想化。真实情况是，人类对“好回答”的判断受立场、风格、时长、情绪、甚至当天状态影响。让同一个人在隔天重新标注同一对回答，他都有可能改主意。我们把这种不稳定数据直接丢给 reward model，等于把一个充满噪声的裁判系统当成精确测量仪器来用。
Lambert 在多个场合表示：偏好数据的噪声问题至今被低估了，尤其是当数据被多次过滤、Source 拼接、模型生成介入之后，偏差会被系统性地固化。这不是标注者有没有认真干活的问题，而是人类偏好本身就不是一个稳定函数。
2.2 标注协议的分歧：一句话的措辞就会改变整个标签分布
我参与过一个偏好数据审查项目，当时请了三拨人标注同一批 prompt 的答案：
| 标注组 | 判给“答案 A 更好”的比例 | 组内一致性 |
|---|---|---|
| 组1 只给简单二选一 | 约 65% | 中等 |
| 组2 附带“更正确/更有用/更安全”维度说明 | 约 52% | 明显更高 |
| 组3 要求先写一句话理由再选择 | 约 48% | 高，但存在“理由越充分越倾向于批判性选择”的现象 |
这里面最关键的变量不是标注者的专业水平，而是任务定义本身。同样是“选更好的回答”，一旦你加入“请先判断事实性错误”，标注者就会更倾向于惩罚事实错误；如果你只问“你更喜欢哪个”，他们就会更看重语气和长度。
标注协议的微小差异会直接改变整个偏好分布。这意味着，当我们比较两个偏好数据集时，不能只看 prompt 数和 size，必须看它的标注协议是否一致。很多团队在多个数据集上混合训练 reward model，却没有做过“协议对齐”，结果模型学到的偏好是多个互相冲突的标准，训练后自然是四不像。
2.3 从“人工比较”到“AI 裁判”：噪声从源头换了宿主
为了降低人工成本，现在很多项目开始用 GPT 级别的大模型做排列组合判断，也就是所谓的 LLM-as-a-judge。这在规模上是高效的，但它并没有消除噪声，只是把噪声从人类身上转移到了模型上。
AI 裁判有非常明显的系统性偏好：位置偏差（偏好第一个回答）、长度偏差（偏好更长回答）、自利偏好（偏好和自己风格相近的输出）。如果不对这些问题做控制，最后训练出的模型会迎合裁判模型的偏见，而不是人类的真实需求。
Lambert 对这件事的态度我比较认同：AI 裁判可以用，但不能作为唯一的评估来源。更好做法是把它当成一个“粗筛器”，把明显优劣的pair先分掉，把接近的、分歧大的pair再交给人来判断，这样既控制成本又保留了高质量标签。这个流程有点像招聘筛选——机器先做简历过滤，最终面还是人来面。
3. 评估科学被低估的三个关键问题
3.1 奖励模型不是测量仪，它是会被“刷”的优化目标
如果说偏好数据是 RLHF 的输入端，那奖励模型就是中间那个把偏好变成数字的转换器。很多团队把 reward model 当成了一个“打分器”，觉得训练好之后它就能客观衡量模型好坏。实际上，reward model 是一个可被优化的目标函数，模型经常会找到奖励模型喜爱的表达方式，而这种表达并不对应真实质量的提升。
这就是 reward hacking。典型表现是：模型发现了某个句式或结构能稳定获得高奖励，于是开始机械性堆砌，导致训练后 win-rate 上去了，但人类读完觉得“假、空、模板感”。
Lambert 的观点是，reward model 本身也需要被评估。不是看它的准确率，而是要看它是否在分布外数据上保持判断的一致性。如果你发现某个 prompt 的所有变体都被 reward model 给了一样的分数，那就说明它根本没有理解内容，只是在利用表面特征。
3.2 胜率对比的方差陷阱：几千条样本的评估结果其实很不稳定
现在几乎所有后训练论文都在报告 win-rate：某模型 A 对某模型 B 的胜率是多少，以此证明训练有效。但这个数字的可信度，完全取决于评估集的规模和质量。
假设你评估了 600 条样本，其中模型 A 赢了 330 次，那 win-rate 是 55%。二项分布的标准差大约是 2%，这意味着 95% 置信区间大概是 51% ~ 59%。换句话说，这个结果和 50% 平局并没有本质差异。如果只用几百条样本就得出“A 明显更好”的结论，实际上风险极大。
我自己的习惯是，评估至少用 2000 条以上样本，并且要拆分成不同类别看：指令遵循类、事实类、代码类、长文本类、多轮对话类。每一类的胜率单独算，不能只看总量。因为模型完全可能在代码类上赢了 70%，在对话类上只有 35%，平均下来刚好 50%，这时候看总量毫无意义。
这里也顺便提一下开盲评估的意义：
评估时最好不知道某段输出是由哪个版本模型生成的。很多时候，人会被“这是新版本”的心理暗示影响判断，开盲虽然不能消除所有偏差，但至少能压掉一部分。
3.3 基准集污染与“评估的评估”：没有规范的基准审计就不算科学
评估基准被污染，在 NLP 里已经是老问题。某个模型在某些公开榜单上突然暴涨，后来发现是评估集里的文本早就在预训练阶段见过了。这种情况在 RL 后训练里同样常见，只是更隐蔽：你可能不是把评估集塞进了预训练数据，而是把评估集的 prompt 风格混进了微调提示词，导致模型学会了“看起来像在考试”的表达。
Lambert 提到的“评估科学”方向里，很重要的一点是：对评估集本身做审计。包括检查评测样本是否与训练数据重叠、是否有重复题、是否覆盖足够的难度分布。更进一步，每个团队都应该维护自己的内部评估集，不能只依赖公开榜单。
我做过的比较实用的一件事是：把每个评估样本都标注来源和难度等级，并定期做人工抽检，看看模型输出是否被 LLM-as-judge 误判。这套流程不是什么高科技，但它直接决定了你迭代模型时能不能看清每次改动带来的真实变化。没有这些东西，所谓“科学评估”就只是换个指标自嗨。
4. 数据与评估合流：开源复现 RLHF 时最该注意整理的东西
4.1 复现失败的第一步往往不是算法，而是数据文件里多出来的一列
聊完大的原则，我想落回到最实际的场景：复现 RLHF 实验。
不少人在复现 DPO 或其他偏好优化算法时，会遇到“明明照着论文写的，效果却对不上”的情况。这时候大家本能地开始怀疑超参数、模型初始化、学习率，却很少有人去检查数据文件本身。
我见过一个典型案例：开源数据集里同一对 (prompt, chosen, rejected)，在某一行复制时出现错位，导致 chosen 和 rejected 顺序反了。你拿这份数据去训 DPO，优化目标刚好是反的，模型当然越训越差。这个问题肉眼很难发现，因为它只影响小部分数据，最后表现为“训练不稳定”“loss 震荡下不去”。
4.2 数据切分、训练验证泄漏这类低级又致命的错误如何排查
更隐蔽的另一个问题，是训练验证泄漏。比如你先把全部偏好数据洗了一遍，然后从里面切出验证集，但同一对 prompt 的不同来源版本同时混进了训练和验证。reward model 在验证集上表现一直很好，但实际线上表现很差，根本原因就是验证集不再“干净”。
一个比较简单实用的排查流程：
- 清洗数据后，先做 fingerprint 或 hash 去重，不要把同一 pair 的变体切到两边。
- 检查 chosen / rejected 的字段顺序，验证它和你训练代码里的语义是否一致。
- 检查 prompt 去重，避免同一个 prompt 在训练集和验证集里反复出现。
- 记录每次数据版本的时间戳和过滤规则，方便回溯。
这个流程听起来像废话，但我可以说，至少三分之一的复现失败最后都栽在这些“低级”问题上。与其把时间耗在各种花哨的算法改动上，不如先用脚本把数据完整检查一遍。
下面这个小 Python 片段可以快速检查 pair 里是否出现重复 prompt 分身：
import pandas as pd def audit_preference_data(path): df = pd.read_json(path, lines=True) # 检查 chosen/rejected 字段是否齐全且文本非空 for col in ["prompt", "chosen", "rejected"]: assert df[col].notna().all(), f"{col} 存在空值" # 统计同一 prompt 在训练集和验证集共现的嫌疑索引 train = set(df["prompt"].tolist()) valid = set(df["valid_prompt"].dropna().tolist()) overlap = train & valid if overlap: print(f"发现 {len(overlap)} 个 prompt 同时出现在训练与验证中，需要处理") return df audit_preference_data("my_pref_data.jsonl")4.3 一个可落地的评估清单与数据记录模板
因为评估和数据容易被忽略，我把自己的做法整理成一个 checklist，供参考：
| 阶段 | 检查项 | 我的建议做法 |
|---|---|---|
| 数据收集 | 结构化字段与版本控制 | 每条偏好数据记录来源、过滤规则、标注协议、收集时间 |
| 数据清洗 | pair 顺序与重复检测 | 写自动化审计脚本，训练前跑一遍并保留日志 |
| 训练前 | 验证集与训练集隔离 | hash 去重、prompt 去重，保证验证集不泄漏 |
| 训练中 | reward score 监控 | 观察训练集 reward 是否异常升高，警惕 reward hacking |
| 训练后 | 多种维度评估 | win-rate 之外同时看长度、指令遵循、事实性、鲁棒性 |
| 定期抽检 | 人工复核 | 每个月抽 50 条评估样本由不同的人复评，看随机方差大小 |
这大概就是 Lambert 说的“data discipline”的落地版。做了这些之后，我的实验迭代效率明显变高了，因为每次改动到底有没有用，能被真实地测量出来，而不是靠感觉猜。
5. 合成数据、缩放法则与数据闭环：未来两三年最值得盯的方向
5.1 RLAIF 与自奖励机制：合成偏好数据解决规模问题的可能路径
人工偏好数据的成本决定了它不可能无限扩大，因此 Lambert 关注的另一个方向是合成偏好数据。所谓 RLAIF（AI Feedback），本质上是让一个足够强的模型来当裁判，生成偏好标注。成本低、速度快，还能做大规模覆盖。
但合成数据有一个隐患：它只是把当前模型的认知边界当成了一种“标准”。如果强模型本身在某类问题上判断能力不够，它生成的偏好数据就会固化这种局限。更麻烦的是，当下一代模型继续用这些数据训练时，它会把错误偏好当成对齐目标。这是典型的“循环退化”风险。
我个人对合成数据的判断是：可以用在风格偏好、格式遵循、常规知识类任务上，但在事实性、法律、医疗这类高风险的领域，不宜完全依赖合成偏好。至少要保持一定比例的人类专家复核。
5.2 缩放法则在 RL 数据侧的边界：质量、多样性与分布外行为
预训练时代我们习惯了“越大越好”：更多数据、更大模型、更长训练。但 RLHF 数据侧的缩放规律并不明确，甚至可能不是单调的。偏好数据太多，reward model 过拟合的风险会显著上升，最终导致模型被“压”在一个狭窄的表达空间里。
Lambert 的观点是，偏好数据的价值更多来自多样性与覆盖度，而不是单纯的数量。如果 10 万条偏好数据里充斥着同一种 prompt 风格，哪怕总量很大，模型学到的也只是对单一分布的过拟合；如果数据覆盖了更广泛的任务族、输入风格、输出长度范围，即使只有 2 万条，效果也会扎实很多。
我在实践中确实观察到这个现象：做了代表性重采样（选取更分散的 prompt 子集）之后，模型在分布外任务上的表现反而增强了。这说明 RL 数据需要的不是“挖矿式”地扩大，而是“设计式”地选择。
5.3 数据闭源趋势下，研究社区能保住的公共资产是什么
另一个值得关注的趋势是数据闭源。最强模型背后的训练细节，尤其是偏好数据构造、评估集设计这类软资产，正在变成各家公司的核心机密。这种背景下，研究社区能保住的东西其实不多，但也不是完全没有，那就是公开的评估方法论和可审计的公共基准集。
Lambert 在多个场合呼吁，评估科学应当成为一个公开的学科。因为评估集本身一旦封闭，外界根本无法验证模型的真实能力，只能依据厂商自报的指标，这会导致整个领域陷入“谁说话大声谁有理”的状态。
我认为这个呼吁是有建设性的。公共评估集的设计、标注、维护和更新，是可以被当作一个持久项目的。即使我们无法拿到别人的训练数据，只要有一套开放、可信的评估标准，社区对模型的判断力就还在。
6. 我想提醒后来者的几件事
最后分享几个我从实际项目中摸出来的经验，不按重要程度排，都挺值得留意。
第一，不要一上来就复现大模型 RL，先跑小规模的闭环。我建议先在 1B 或更小的模型上，把数据、reward model 和训练迭代跑通，记录整套实验过程；然后再放大到更大模型。很多人习惯跳过这步直接烧卡，结果烧完发现数据有问题，白白浪费大量算力。
第二，每一次实验，变量只动一个。数据、模型、算法这三类东西不要同时改。特别是在探索新方法时，一次只改一个变量，出问题才能快速定位。你会发现绝大部分异常都来自数据，而不是算法。
第三，把数据当作代码来管理。用版本控制工具管理数据文件，记录每次修改的 hash、时间和原因。对一个认真迭代的 RL 项目来说，数据版本混乱造成的损失，远大于“少跑几次实验”。
第四，评估要开盲。做到这一点能减少心理偏差。我自己经常被“新模型一定更好”的想法带偏，开盲后反而经常发现新模型在某些类别里其实是退步的。评估就是为了发现这类问题，不是用来证明我们有多努力。
第五，别迷信单一指标。win-rate 有参考价值，但它不是一个足以指导全部决策的数字。建议同时监控长度、指令遵循率、事实性错误率、格式规范度、稳定性等多个维度，综合判断。
这些经验放到 Lambert 说的“RL 数据与评估科学方向”里，其实就是数据纪律的日常化。真正做出高质量模型，靠的是耐心的测量和积累，不是一两个神秘的算法 trick。至少从我这些年的实践来看，数据端和评估端投入的每一分钟，最终都会在模型质量上获得回报。
