可靠性已更新 2026-06-21 · 版本 1.0
反思
反思让模型批判自己的输出，然后以该批判作为反馈进行修改。这是一种轻量级的、单模型的方法，用于在推理、编码和写作任务中发现错误并提高质量，代价是需要额外的调用。
证据: 行业观察置信度: 高来源: 行业观察来源: 论文
定义
反思是一种模式，其中模型根据明确的标准审查和批判自己的输出，然后对其进行修改，以额外的推理换取更高的质量。
问题
模型往往会产生有缺陷的初步答案，如果提示它们审查自己的工作，它们本可以改进这些答案，但单次生成让它们没有机会这样做。
适用场景
当自我审查步骤能够显著改善输出，且您希望使用一种比双模型评估器循环更简单的替代方案时，可以使用反思——这在推理和编码任务中很常见。
解决方案
在生成答案后，提示同一个模型根据目标（以及任何工具反馈，如测试结果或错误）对其进行批判，然后根据该批判生成修改后的答案。重复此过程，限制迭代次数。
当反思基于真实信号（执行错误、测试输出、检索到的事实）而非纯粹的自我评估时，效果最好，因为纯粹的自我评估可能会过度自信。
组件
初始生成自我批判步骤依据信号（错误/测试/事实）修改迭代预算
优势
- 使用单个模型即可提高质量——无需第二个系统。
- 当基于工具或测试反馈时非常有效。
- 易于添加到现有的调用中。
风险
- 自我批判可能会过度自信，或者遗漏自身的错误。
- 额外的调用会增加延迟和成本。
- 如果没有依据，收益会很有限。
不适用场景
- 当您有客观的外部检查时——使用评估器-优化器。
- 当单次运行已达到标准时。
- 当延迟预算非常紧张时。
技术
LangGraphAgent frameworksLLM-as-judge
示例
- 一个编码智能体读取测试失败信息并修复自己的补丁。
- 一个推理任务，模型在回答前重新检查其步骤。
- 模型在定稿前审查草稿是否存在漏洞。
生产实践证据
- 上下文
- 输出质量比延迟或成本更重要的任务（如起草、代码生成、分析），且在审查时可以检测到错误。
- 场景
- 在生成第一个答案后，模型（或单独的批判器）根据具体标准对其进行评估，并生成修改后的版本；该循环限制在一次或两次运行内。
- 技术
- 一个“先批判后修改”的提示词链，对于高风险工作，最好有外部信号（测试、工具、单独的评估器）的支持。
- 负载
- 每次反思运行至少会使调用次数翻倍，因此它被选择性地应用于那些值得付出此开销的输出。
- 结果
- 观察到的模式：在模型确实能够检测到自身错误的情况下，反思可以提升质量，但它可能会对正确的答案进行过度修改，并且至少会使成本翻倍。在信任它之前，先根据评估集衡量质量提升，并在高风险情况下优先选择外部信号。
KPI
- 反思带来的质量提升
- 衡量有反思步骤与没有反思步骤时输出质量的改进；如果无法衡量，则该步骤不值得其成本。
- 自我纠正率
- 模型在审查中捕获并修复的真实错误的比例——这与表面上的修改不同。
- 增加的延迟与成本
- 反思至少会使调用次数翻倍；跟踪该开销与它所换取的质量之间的关系。
- 过度修改率
- 反思因自我怀疑而降低原本优秀的答案质量的频率。
已观测到的失效模式
- 自我评估盲区：模型通常无法发现自己的错误，因此反思会遗漏这些错误。
- 过度修改：模型将正确的答案“修复”成更差的答案。
- 成本和延迟翻倍（或更多），而质量提升微乎其微或根本没有。
- 盲目自信：模型在输出并不正确时，却断言其现在是正确的。
经验教训
- 衡量提升幅度；只有在反思能明显提高质量的情况下，它才值得使用。
- 在高风险情况下，优先选择外部信号（测试、工具、单独的评估器），而非纯粹的自我批判。
- 将反思限制在一次或两次运行内——收益递减很快，且成本会成倍增加。
- 为反思步骤提供具体的标准，而不是模糊的“改进这个”。
常见问题
- 反思还是评估器-优化器？
- 反思使用一个模型进行自我批判（更简单）；评估器-优化器使用单独的评估器（更敏锐、偏见更少）。根据自我评估对您的任务有多可靠来做出选择。
- 反思总是有效吗？
- 当基于测试结果或错误等真实反馈时，它的帮助最大。纯粹的自我评估可能会过度自信，且收效甚微。
- 需要多少轮反思？
- 保持次数受限——通常是一到两轮。收益递减和成本上升使得长循环很少值得。