AI / Technology
大模型批评者帮助找出大模型的错误
CriticGPT 辅助人工复核的基本流程
图 1｜流程示意。箭头表示信息处理顺序，不表示把决定权交给模型。
CriticGPT 的关键变化很简单：检查代码时，人不必从空白开始。一个专门训练的 GPT-4 系列模型先读“问题 + 回答”，再指出回答中可能有错的片段和理由；人仍负责核实并下最终结论。[摘要；§2]
从真实任务到 CriticGPT 的训练闭环
图 2｜训练闭环示意。“记录已知错误”是供人工比较批评时使用的参照，不是暗中塞给批评模型的答案。虚线回路表示后续埋雷会针对当前模型变得更难。
研究者从真实 ChatGPT 任务和回答出发，请人工在代码里插入隐蔽错误，并立即写下这个错误的解释。插错者还能看到当前批评模型；他们尽量设计出让它三次采样中至少漏掉一次的错误。这样，每个训练样本都有一个已知目标，也会随着批评模型变强而变难。[§2.2.1；图 3]
FSBS 从多份候选批评中选择结果
图 3｜FSBS 机制示意。底部两端是取舍方向，不代表任何一端天然最好。
长批评通常能覆盖更多真实问题，也更容易夹带误报。FSBS 会为每个输入搜索 28 个候选批评，用奖励分数和“希望包含多少个高亮问题”的偏好共同选出结果。论文测试了对应批评长度第 10、25、50、75 百分位的四档设置；默认的 CriticGPT 指 RL + 中位档 FSBS，平均给出 4 个高亮问题。[§2.3]
人工、模型与人机组合的定性比较
图 4｜定性示意，不是按论文数值绘制的柱状图；图标数量只帮助理解方向，不能读取为精确比例。
人工单独审查最少误报，却容易漏掉问题；模型能列出更多问题，也会带来更多幻觉和吹毛求疵。人机组合找到的问题数量与 CriticGPT 大致相当，同时比模型单独工作更少误报。论文把这理解为组合越过了纯模型的“覆盖—误报”边界。[摘要；§3.3–3.4；图 6–8]
CriticGPT 已测试范围与尚未覆盖的复杂场景
图 5｜中间是论文主要验证的短代码、局部错误；外围是论文明确列出的未覆盖场景。示例代码仅作视觉占位，不代表论文样本或实验结果。
这项研究没有证明 CriticGPT 能审查完整软件仓库。实验代码通常较短，不支持多文件和仓库导航，也没有测试分散在多处、难以定位的复杂错误。它同样没有直接跑完“有批评辅助 vs. 无辅助”的两套 RLHF 训练闭环，因此“更好的批评最终会训练出更好的模型”仍是合理假设，不是已验证结果。[§5]
研究附录
官方来源标题： LLM Critics Help Catch LLM Bugs
作者： Nat McAleese、Rai (Michael Pokorny)、Juan Felipe Cerón Uribe、Evgenia Nitishinskaya、Maja Trębacz、Jan Leike
来源： arXiv:2407.00215 · 2024-06-28
核心结论
CriticGPT 的关键变化很简单：检查代码时，人不必从空白开始。一个专门训练的 GPT-4 系列模型先读“问题 + 回答”，再指出回答中可能有错的片段和理由；人仍负责核实并下最终结论。[摘要；§2]
记住这三点
- 它帮助人评估答案，不是直接替人改答案。 论文研究的是“可扩展监督”：当模型的答案越来越难审，人能否借助另一个模型看得更准。[§1；§4]
- 专门训练确实带来增益。 在含有自然发生错误的代码上，评审者有 63% 的时候更偏好模型批评而不是人工批评；CriticGPT 也优于直接提示 ChatGPT 写批评。[摘要；§3.1]
- 更会找错不等于更可信。 模型会误报和挑小毛病。论文最有价值的结论不是“AI 胜过人”，而是人和批评模型组合后，可以保留较广的覆盖，同时比模型单独工作少一些误报。[摘要；§3.3–3.4]
问题
人为什么会漏掉模型的错？
RLHF 依赖人比较模型回答，但更强的模型会犯更隐蔽、更专业的错。论文中的人工评审者自报 Python 经验中位数为 5 年，每个样本的检查时间中位数约 50 分钟；即使如此，他们仍可能因为评论较短、缺少特定库知识，或错误本身太难而漏检。[§2.1.3；§3.1]
过去的方法离真实代码还有多远？
早期“可扩展监督”实验已研究辩论等方法，但主要场景是未读过的短篇科幻故事上的选择题。CriticGPT 把问题推进到真实助手任务产生的代码回答：评审者要定位具体错误，而不只是选一个答案。[§1；§4]
方法
训练数据为什么要故意“埋雷”？
研究者从真实 ChatGPT 任务和回答出发，请人工在代码里插入隐蔽错误，并立即写下这个错误的解释。插错者还能看到当前批评模型；他们尽量设计出让它三次采样中至少漏掉一次的错误。这样，每个训练样本都有一个已知目标，也会随着批评模型变强而变难。[§2.2.1；图 3]
人的排序怎样变成 CriticGPT？
对同一个“问题 + 带错回答”，模型先生成多份批评。人工从完整性、是否指出已知错误、是否误报或挑小毛病、整体帮助程度等方面打分；研究者用排序训练奖励模型，再用 PPO 优化批评策略。CriticGPT 与论文中的 ChatGPT 对照从同一检查点初始化，但 CriticGPT 专门学习批评任务。[§2.1.1；§2.2.3–2.2.4]
推理时怎样控制“少误报”和“多找错”？
长批评通常能覆盖更多真实问题，也更容易夹带误报。FSBS 会为每个输入搜索 28 个候选批评，用奖励分数和“希望包含多少个高亮问题”的偏好共同选出结果。论文测试了对应批评长度第 10、25、50、75 百分位的四档设置；默认的 CriticGPT 指 RL + 中位档 FSBS，平均给出 4 个高亮问题。[§2.3]
证据与局限
哪些结果最能支持论文结论？
| 观察 | 论文结果 | 能说明什么 | 来源 |
|---|---|---|---|
| 自然发生的代码错误 | 模型批评相对人工批评获偏好率 63% | 批评模型在更贴近日常 RLHF 的错误上有实际帮助 | 摘要 |
| 人是否因 CriticGPT 而进步 | 有辅助的评审在 60% 的比较中胜过无辅助评审 | 模型建议能改善人的最终审查，而不只是模型自己的分数 | OpenAI 论文配套说明；论文 §3.3–3.4 的人机组合实验 |
| “无瑕疵”训练数据复查 | CriticGPT 提醒后，24% 的回答被判定存在足以明显降分的问题；无批评的独立复查为 6% | 批评模型能发现首轮人工漏掉的问题，也能扩展到大量非代码任务 | §3.6 |
| 专项训练与单纯扩大模型 | 朴素外推估计，要追上 RL-only CriticGPT 的漏错表现需约 30× 预训练算力 | 针对性数据和训练可能比单纯堆算力更高效 | §3.2；图 5 |
这里的 30 倍是按模型规模曲线做的朴素外推，不是实际训练了一个 30 倍系统。24% 与 6% 也不是完全相同的复查流程，适合说明信号很强，不适合当作严格的因果差值。[§3.2；§3.6]
人、模型、人机组合各自擅长什么？
人工单独审查最少误报，却容易漏掉问题；模型能列出更多问题，也会带来更多幻觉和吹毛求疵。人机组合找到的问题数量与 CriticGPT 大致相当，同时比模型单独工作更少误报。论文把这理解为组合越过了纯模型的“覆盖—误报”边界。[摘要；§3.3–3.4；图 6–8]
哪些结论现在还不能下？
这项研究没有证明 CriticGPT 能审查完整软件仓库。实验代码通常较短，不支持多文件和仓库导航，也没有测试分散在多处、难以定位的复杂错误。它同样没有直接跑完“有批评辅助 vs. 无辅助”的两套 RLHF 训练闭环，因此“更好的批评最终会训练出更好的模型”仍是合理假设，不是已验证结果。[§5]
批评模型的误报绝对比例仍然偏高，还可能把人带向原本不会犯的标注错误。人工插入的错误也比自然发生的错误更难、更严重，二者分布并不相同。强大的找错能力还具有双重用途，不过作者判断当时的 CriticGPT 尚不足以改变网络安全攻防格局。[摘要；§2.1；§5；附录图 10]
实际意义
产品里最值得借鉴的不是“再问一次”
真正可复用的是一套受控复核流程：保留原问题和回答，让批评器把意见绑定到具体片段；把“漏掉严重问题”“编造问题”“无关小毛病”分开评价；最后让人验证，而不是自动接受批评。若业务对漏错和误报的成本不同，还应单独调节批评覆盖度。[§2.1；§2.3]
上线前应该问哪四个问题？
- 真实业务错误是否和训练时的“人工埋雷”足够接近？
- 批评器误报后，人会识别出来，还是会被它带偏？
- 长上下文、多文件和跨步骤错误是否另有评测？
- 最终指标是“批评看起来更好”，还是下游标注与模型真的变好？
研究脉络与可核查记录
这项工作直接沿用“模型批评帮助人工评估”的路线，并把它从早期实验推进到真实助手代码与 RLHF 数据。它也采用了成熟的偏好学习与 PPO 训练框架；新增之处主要是对抗式人工埋雷数据、专门的批评训练，以及推理时的 FSBS 取舍控制。[§1–2；§4；参考文献 26、27、31]
证据台账。 核心数字均按论文原口径记录：63%（摘要，自然发生错误上模型批评相对人工批评的偏好）；28 个候选与四个长度档位（§2.3，FSBS 搜索）；约 30×（§3.2，朴素外推而非实测）；24% 与 6%（§3.6，两种不同复查设置）。论文没有公开模型规模、训练算力绝对值，也没有给出完整 RLHF 下游改进实验，因此本文不补猜这些信息。
术语小抄。 “批评”是指向回答具体片段并说明潜在问题的文字；“完整性”指有没有漏掉清楚且严重的问题；“幻觉错误”指批评声称存在、实际并不存在的问题；FSBS 是推理时生成、评分并筛选多份候选批评的搜索方法。[§2.1；§2.3]
关于这篇论文的三个关键问题
大模型批评者帮助找出大模型的错误 解决了什么问题？
RLHF 依赖人比较模型回答，但更强的模型会犯更隐蔽、更专业的错。论文中的人工评审者自报 Python 经验中位数为 5 年，每个样本的检查时间中位数约 50 分钟；即使如此，他们仍可能因为评论较短、缺少特定库知识，或错误本身太难而漏检。[§2.1.3；§3.1]
大模型批评者帮助找出大模型的错误 的核心结论有哪些证据？
这里的 30 倍是按模型规模曲线做的朴素外推，不是实际训练了一个 30 倍系统。24% 与 6% 也不是完全相同的复查流程，适合说明信号很强，不适合当作严格的因果差值。[§3.2；§3.6]
阅读 大模型批评者帮助找出大模型的错误 时最需要注意什么局限？
人工单独审查最少误报，却容易漏掉问题；模型能列出更多问题，也会带来更多幻觉和吹毛求疵。人机组合找到的问题数量与 CriticGPT 大致相当，同时比模型单独工作更少误报。论文把这理解为组合越过了纯模型的“覆盖—误报”边界。[摘要；§3.3–3.4；图 6–8]