跳到主要内容

Reflection与Self-Critique

1. 定义与边界​

Reflection 是 Agent 对自身输出、计划或执行轨迹进行评估，并基于反馈修正后续行为的机制。Self-Critique 是模型自我批评输出质量的一类方法。

相关研究包括：

  • Reflexion：使用语言反馈作为强化信号，让 Agent 在后续尝试中改进。
  • Self-Refine：让模型生成、反馈、修订，迭代改善输出。

工程上不要把 Reflection 理解成“模型自己检查就一定更可靠”。它只是反馈机制之一，必须与外部验证、评测器、工具结果和人类在环结合。

2. 为什么重要​

Reflection 适合处理：

  • 输出质量可评估但初稿容易不完整的任务。
  • 代码、写作、计划等可迭代改进的任务。
  • 工具失败后需要重新规划的任务。
  • 需要将失败经验写入短期记忆或下次尝试的任务。

不适合：

  • 没有客观反馈信号的高风险判断。
  • 模型缺少必要事实却反复自评。
  • 成本和延迟敏感的一步任务。
  • 需要合规批准的动作。

3. 核心机制​

Reflection 的反馈来源分三类：

来源优点风险
模型自评成本低、易集成可能自信地强化错误
外部评测器更可控、可复现评测器本身需要维护
人类反馈高价值、可解释成本高、延迟高

反馈对象​

Reflection 可以作用在不同对象上，混用会导致评测困难。

对象典型问题反馈形式
输出答案不完整、引用不足、格式不合规rubric、引用检查、人工批注
计划步骤顺序错、漏验证planner critique、检查点
工具调用调错工具、参数错trace evaluator、工具单测
状态忘记约束、错误写入记忆state validator、记忆写入审批
安全违反策略、泄漏敏感信息guardrail result、红队样本

4. 架构模式​

Generate-Critique-Revise​

适合文档、计划、摘要、代码修复建议。

Execute-Reflect-Retry​

工具调用失败、测试失败或环境反馈不满足时，Agent 反思原因并重新选择行动。

Memory Reflection​

将失败原因总结为短期记忆，供同一任务后续步骤使用。长期写入必须谨慎，避免污染记忆。

Evaluator-Optimizer​

Anthropic 将 evaluator-optimizer 作为一种 workflow 模式：一个模型生成，另一个模型或评测器提供反馈，循环优化。它适合有明确评价标准的任务。

5. 工程实现​

def generate_with_reflection(task, max_rounds=3):
    draft = model.generate(task)

    for round_id in range(max_rounds):
        critique = evaluator.grade(
            task=task,
            output=draft,
            rubric=[
                "是否满足任务目标",
                "是否有事实依据",
                "是否违反安全或业务规则",
                "是否缺少必要步骤"
            ]
        )

        if critique.passed:
            return draft

        draft = model.revise(
            task=task,
            previous_output=draft,
            critique=critique.actionable_feedback
        )

    return require_human_review(draft, critique)

执行轨迹反思示例：

{
  "failed_step": 5,
  "symptom": "create_ticket returned POLICY_CONFLICT",
  "reflection": "此前没有读取最新退款政策，导致创建了错误类型工单",
  "next_constraint": "必须先调用 read_refund_policy，再决定工单类型",
  "memory_scope": "current_run_only"
}

Rubric 配置示例：

reflection_rubric:
  task_type: customer_policy_response
  checks:
    - id: evidence
      question: 是否引用了订单状态和政策来源
      fail_action: revise
    - id: forbidden_action
      question: 是否建议或执行了直接打款
      fail_action: escalate
    - id: clarity
      question: 给客服的一句话建议是否可执行
      fail_action: revise
  max_rounds: 2
  require_external_evidence: true

6. 生产实践​

场景推荐做法
代码任务用测试、lint、类型检查作为外部反馈
文档任务用 rubric + 引用检查 + 人工抽样
客服任务用政策规则和工单状态校验
长任务定期总结已完成、阻塞和下一步
高风险任务自评只能辅助，必须审批或规则验证

7. 常见反模式​

反模式表现后果修正
无证据自查事实让同一模型判断自己是否胡编错误被强化自评必须引用工具、测试或来源
无限反思一直 revise 直到“看起来更好”成本和延迟失控设置 max_rounds 和收益阈值
失败写入长期记忆一次错误经验影响所有任务记忆污染默认 run scope，长期写入需审批
无 rubric只说“请改进”反馈不可复现使用任务化检查项
反思后自动高风险修正自评通过就执行退款/删除安全事故高风险动作重新走策略和 HITL
反思替代评测没有离线 eval，只看模型批评无法量化收益A/B 比较无反思、自评、外部评测器

8. 评测方法​

指标说明
Revision Gain反思后任务得分提升
Critique Precision批评是否指出真实问题
Critique Actionability反馈是否可执行
False Acceptance Rate有问题输出被评为通过的比例
Over-Refinement Cost反思带来的 token、延迟和轮数
Regression Rate修改后是否破坏已正确部分

评测时要对比无 Reflection、Self-Critique、外部评测器、人类反馈几种方案的收益成本。

一个实用验收口径：

问题上线门槛
反思是否真的提升质量Revision Gain 在代表性任务集上显著为正
反思是否会放过错误False Acceptance Rate 低于业务红线
反思是否太贵平均轮数、延迟和成本低于预算
反思是否破坏正确内容Regression Rate 可接受并可回放
反思是否安全高风险 fail_action 不允许自动执行

9. 安全与治理​

Reflection 可能带来新的风险：

  • 模型在反思中生成看似合理但未经验证的解释。
  • 自评器被 prompt injection 影响。
  • 反思摘要泄漏敏感数据。
  • 长期记忆写入错误结论。

控制手段：

  • 反思内容按 run scope 默认短期保存。
  • 长期记忆写入需要规则或人工确认。
  • 自评必须引用外部观察、测试或规则。
  • 高风险修正必须重新过权限和审批。
  • 反思日志脱敏。

10. 权威资料​