AI / Technology

大模型批评者帮助找出大模型的错误

原论文 PaperBridge 编辑团队2026/7/20

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

核心结论

记住这三点

它帮助人评估答案，不是直接替人改答案。 论文研究的是“可扩展监督”：当模型的答案越来越难审，人能否借助另一个模型看得更准。[§1；§4]
专门训练确实带来增益。 在含有自然发生错误的代码上，评审者有 63% 的时候更偏好模型批评而不是人工批评；CriticGPT 也优于直接提示 ChatGPT 写批评。[摘要；§3.1]
更会找错不等于更可信。 模型会误报和挑小毛病。论文最有价值的结论不是“AI 胜过人”，而是人和批评模型组合后，可以保留较广的覆盖，同时比模型单独工作少一些误报。[摘要；§3.3–3.4]

问题

人为什么会漏掉模型的错？

RLHF 依赖人比较模型回答，但更强的模型会犯更隐蔽、更专业的错。论文中的人工评审者自报 Python 经验中位数为 5 年，每个样本的检查时间中位数约 50 分钟；即使如此，他们仍可能因为评论较短、缺少特定库知识，或错误本身太难而漏检。[§2.1.3；§3.1]

过去的方法离真实代码还有多远？

早期“可扩展监督”实验已研究辩论等方法，但主要场景是未读过的短篇科幻故事上的选择题。CriticGPT 把问题推进到真实助手任务产生的代码回答：评审者要定位具体错误，而不只是选一个答案。[§1；§4]

方法

训练数据为什么要故意“埋雷”？

人的排序怎样变成 CriticGPT？

对同一个“问题 + 带错回答”，模型先生成多份批评。人工从完整性、是否指出已知错误、是否误报或挑小毛病、整体帮助程度等方面打分；研究者用排序训练奖励模型，再用 PPO 优化批评策略。CriticGPT 与论文中的 ChatGPT 对照从同一检查点初始化，但 CriticGPT 专门学习批评任务。[§2.1.1；§2.2.3–2.2.4]

推理时怎样控制“少误报”和“多找错”？

证据与局限

哪些结果最能支持论文结论？

观察	论文结果	能说明什么	来源
自然发生的代码错误	模型批评相对人工批评获偏好率 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 尚不足以改变网络安全攻防格局。[摘要；§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]

主要来源。 arXiv 主页面；论文 PDF。