可靠性已更新 2026-06-21 · 版本 1.0
评估器-优化器
一个 LLM 生成响应，而第二个 LLM 根据标准对其进行评估并返回反馈；生成器进行修改，循环重复，直到评估通过。它以增加额外调用为代价，提高了具有明确评估标准的任务的质量。
证据: 行业观察置信度: 高来源: 行业观察来源: 论文
问题
单次输出可能会遗漏要求，并且在使用之前没有内置机制来检查和改进它。
适用场景
当您可以制定明确的评估标准，并且迭代优化能显著改善结果时（例如翻译质量、必须通过测试的代码或根据评分标准进行写作），请使用评估器-优化器。
解决方案
生成器产生一个候选结果；评估器（独立的 LLM 调用或确定性检查）根据明确的标准对其进行评分并返回可操作的反馈。生成器进行修改，循环往复，直到满足标准或达到预算上限。
将生成与评估分离，类似于人类作者如何从编辑中受益：批评者发现作者遗漏的问题，而明确的标准使循环保持收敛。
组件
生成器评估器（LLM 裁判或规则检查）明确的标准修改循环停止条件 / 预算
优势
- 在具有明确标准的任务上获得更高的质量。
- 捕获单次运行可能会漏过的错误。
- 反馈明确且具有可操作性。
风险
- 额外的调用会增加延迟和成本。
- 能力较弱的评估器会给出误导性的反馈。
- 在没有预算限制的情况下，循环可能无法收敛。
不适用场景
- 当无法明确定义标准时。
- 当单次运行的结果已经足够好时。
- 当延迟或成本预算非常紧张时。
技术
LangGraphLLM-as-judgeOpenAI Agents SDKEvaluation suites
示例
- 生成代码、运行测试并进行修改，直到测试通过。
- 起草翻译并对照原文进行润色。
- 根据评分标准进行写作，并由评审人员强制执行每项标准。
KPI
- 采纳率
- 评估器在首轮通过中接受的候选输出比例 —— 比例过高意味着门槛太低，过低则意味着生成器或评分标准存在偏差。
- 达到接受所需的迭代次数
- 接受前平均经历的“评估→修改”循环次数；次数上升标志着生成器较弱或标准模糊。
- 每个被接受输出的成本与延迟
- 所有循环迭代中的总 token 数和实际消耗时间（Wall-clock time），而不仅仅是最终调用 —— 循环会使这两者成倍增加。
- 评估器与人工的一致性
- 评估器的判定在抽样集合中与人工评审员一致的频率；该循环的效果完全取决于评估器的质量。
已观测到的失效模式
- 奖励黑客行为（Reward hacking）：生成器学会了迎合评估器的措辞，而不是实现真正的目标。
- 评估器较弱或校准不当：它接受了糟糕的输出或拒绝了优秀的输出，导致循环增加了成本却未能提升质量。
- 当没有候选方案能够达标时，会出现无限循环或振荡循环——如果没有迭代上限，成本将是无底洞。
- 标准漂移：模糊或不断变化的评估细则导致采纳结果具有不确定性，且难以审计。
经验教训
- 限制迭代次数并定义回退方案（返回迄今为止的最佳结果，或进行升级上报），以确保循环始终能够终止。
- 使准入标准明确且稳定；评估器的效果完全取决于其评估细则。
- 在将评估器作为准入关卡予以信任之前，先对照人工判断对其进行验证。
- 仅在质量提升能够证明成倍增加的成本是合理的情况下才使用该循环——不要用于廉价、低风险的输出。
常见问题
- 这与自我反思（reflection）有什么不同？
- 自我反思是由同一个模型进行自我批判。评估器-优化器（Evaluator-optimizer）则分离了角色：由一个独立的评估器来评判生成器，这通常能提供更敏锐、更少偏见的反馈。
- 评估器可以是确定性的吗？
- 可以。对于代码，测试运行器（test runner）是理想的评估器；对于结构化输出，Schema 检查非常有效。对于微妙复杂的标准，可以使用模型作为裁判。
- 需要迭代多少次？
- 设定一个预算（例如 2-3 次），并在标准通过时停止。无限制的循环会浪费成本，且可能无法收敛。