团队改了提示词，一次生成两百份回答。让人逐份阅读很慢，只看关键词又分不清解释是否完整，于是常有人提议再请一个大模型来打分。这种办法通常叫 LLM-as-a-Judge，也可以叫 LLM 评审。
我查了 MT-Bench 的原始论文、G-Eval 论文和 OpenAI 当前的 grader 接口。LLM 评审主要有三种做法。它可以把两份答案放在一起选较好的一份，可以给单份答案打分，也可以拿参考答案一起判断。三种做法解决的问题不同，不能只换一段评分提示词就当成同一把尺子。
先把能确定的部分交给规则
OpenAI 的 grader 接口同时提供字符串检查、文本相似度、Python 规则和模型评分。这一组设计很有启发。订单号格式、JSON 字段、引用数量这类要求能由程序判断，就让程序判断。语气是否清楚、摘要是否覆盖重点这类开放问题，再交给模型。
模型评审的好处是快，也能解释为何给出某个分数。MT-Bench 研究中，较强模型对一批开放回答的判断与人类偏好达到八成以上的一致率。这个结果证明它适合扩大评测规模，却只代表论文中的问题、模型和判定设置。换成企业合同、中文客服或专业医疗内容，一致率需要重新测。
G-Eval 把评测标准、分步判断和表单式评分组合起来，在摘要任务上得到更接近人工判断的结果。它也报告了一个令人警惕的现象，模型评审可能更偏爱由大模型生成的文字。评审模型和被评模型来自相近系列时，团队尤其要保留人工对照。
裁判自己也会偏
MT-Bench 论文记录了位置偏差。两份相近答案交换前后顺序，评审的选择可能跟着翻转。它还会偏爱更长的回答。研究人员把原有要点重复改写，凑成更长的列表，一些评审会把重复当成内容丰富。论文也观察到部分模型更偏爱自己所属系列的输出。
处理这些偏差需要具体动作。做两两比较时交换左右位置，各评一次，结果冲突就交给人工。评分标准要写出“重复不加分”和长度上限。数学、代码或事实题尽量提供可验证的参考答案。论文中的参考引导办法曾明显降低推理题上的评审失败，代价是提示和调用更复杂。
正式使用前，先抽出一小批由业务人员判好的答案。让模型评审同一批内容，按维度比较一致与不一致的地方。客服场景可以拆成事实正确、是否解决问题和表达是否合适，别只留一个总分。每次更换评审模型、评分提示或被评任务，都重跑这批校准样本。
我的建议是让 LLM 评审承担初筛和趋势比较。质量门槛能由程序确认的部分继续用确定性规则，高风险与分歧样本留给人。这样会多保留一套小型人工集，却能知道裁判何时开始跑偏，比收下一列漂亮分数稳得多。