📰 概要

LLM-as-a-judge是强化微调（RFT）的核心组件，但评判架构怎么设计，其实有很多细节。

AWS于2026年4月29日发布指南，详细拆解了LLM-as-a-judge奖励函数的设计要点。

核心结论：布尔评分（pass/fail）比细粒度量表（1-10分）更可靠，能减少评判波动。

---

🔍 解读

评判模式有两种：Rubric-based（基于评分标准的评分）和Preference-based（基于偏好的对比）。

布尔评分要求定义清晰的pass/fail标准，每个维度有具体的、可观察的判断依据。比让模型打1-10分更稳定——打分制容易出现评委之间分歧大、同一评委前后不一致的问题。

偏好评分则需要写出清晰的Prompt，解释"为什么一个回答比另一个更好"，配合具体例子。适合难以量化标准的场景。

---

💎 深挖

为什么布尔评分更可靠

AWS的测试结论是：布尔评分比1-10量表更可靠，减少评判波动。在基于评分标准的评判中，定义清晰的pass/fail边界，比让LLM生成一个连续分数更容易获得稳定结果。

分数制的潜在问题：评委LLM的评判标准可能随上下文变化，同一个答案这次给8分下次给6分。布尔制把这个问题变成了二元判断，降低了不确定性。

不要单独依赖LLM评判

这是AWS指南中最实用的建议：不要单独依赖LLM评判。

要把LLM评判和快速确定性奖励组件结合使用。确定性组件先行一步，在昂贵的LLM评判之前，先过滤掉明显错误的结果。

原因：生产级RFT系统每次训练步需要处理数千次奖励评估。如果每次都调用LLM，成本和延迟都会成为瓶颈。

评判Prompt的设计原则

评判Prompt是对齐质量的基础。设计时需要：

产生结构化的、可解析的输出。明确评分维度。奖励函数需要和你的生产评估指标保持一致——对齐目标要正确，否则模型会在错误的方向上优化。

实际案例：法律合同审查

AWS还分享了一个法律行业的实际案例。任务：AI生成法律合同的风险评估意见，并对照内部规范、历史合同和适用法规进行核查。

奖励Lambda函数需要满足特定命名规范（包含"SageMaker"），配置在Amazon Bedrock上调用。这是AWS生产环境的推荐架构。

什么情况不建议用

如果你的对齐任务已经有成熟的标准评估集和明确的自动化指标，LLM-as-a-judge的价值不大。现有的MMLU、HumanEval等基准测试可能更直接。

如果你的训练规模很小（几百个样本以内），LLM评判的成本可能超过收益。直接人工标注可能更划算。

如果评判LLM和被训练的模型能力接近或更弱，评判质量会打折扣。选一个推理能力足够强的评判模型。