LLM Critics Help Catch LLM Bugs
#reward-model
#reasoning
搞 (question, answer) -> critique 训了 rm，拿 rm 训 ppo 写 critique（但这不是重点）
重点在于说明了 llm 找 bug 比人强，
类似 CoT?
这也是我之前思考的问题：考虑以下两个 critique，一个描述准确但漏了大错，一个漏了大错但描述准确，如何评价 critic 好坏？看上去二者各有优劣，但实际中训出性能肯定有差异，因为二者对应的数据分布就不同
OpenAI 给出了四条判断 critique 好坏的指标
- 全面性（comprehensiveness）：评审是否全面，即没有遗漏任何明显和严重的问题。
- 特定错误捕捉（critique-bug inclusion, CBI）：评审是否捕捉到了事先指定的特定错误。
- 是否包含虚构错误或吹毛求疵：评审是否包含任何虚构的错误或吹毛求疵的小问题。
- 总体主观有用性评分：综合考虑上述因素，以及评审的风格和总体实用性，给出一个主观的有用性评分。
其中前两条很好避免，只要我让模型尽可能多说，那遗漏的点就会很少。但是言多必失，模型说多了之后就会胡言乱语。
实验方法
数据集构造
OpenAI 先从 ChatGPT 数据里面找到一些代码片段，然后人为制造 bug，最后拿这些 bug 让标注师们操作。
结果分析
CriticGPT答的比人好
即使 OpenAI 选了五年以上 python 经验的专家，结果仍然不好。他们认为原因有三点，
- 看的太匆忙
- 缺少具体领域知识，比如让一个搞 ai 的去看通信相关的库
- 任务本身就很难
