自反思 Self-Reflection

Self-Reflection / Reflexion

LLM 在生成答案后或生成过程中,主动触发另一次(或多次)自我审视调用,对已生成内容进行评分、纠错、补全、优化,用额外计算量换取更高答案质量。

详细解释

LLM Self-Reflection(自反思 / 自审 / Reflexion 范式) 一句话定义:不要把 LLM 吐出的第一个版本当最终答案,让它自己当自己的阅卷老师——先出初稿,然后换一个 System Prompt(「你是一个严格的评审,请从准确性、完整性、逻辑三个角度给上文打 1-5 分并列出修改点」)再调用一次,根据修改意见再出二稿,必要时循环,直到达到及格分。人类写稿都要改 3 遍,凭什么觉得 LLM 一次就能写对?在代码生成、数学推理、长文写作等高错误率任务上,加一次自反思通常能把最终正确率提 10 至 20 个百分点,成本只翻一倍不到(二稿通常比初稿短)。

2023 年 6 月诺亚方舟实验室提出的 Reflexion 是这个方向的开山论文:核心思路就是「语言反馈 + 记忆池」—— Agent 每次做完一个任务,先自己写一段「这次哪里做得不好、下次怎么改」的文字反思,存到记忆里,下次做同类任务时先把记忆里的反思塞进上下文,相当于人类积累的错题本。实测在 HumanEval 代码生成上,GPT-4 一次通过率 67%,加 Reflexion 三轮迭代后冲到 91%,提升非常显著。

唯元智创 的 LLM 网关内置了「自反思开关」,不需要改业务代码:在请求参数里加 enable_reflection: truereflection_rounds: 2,网关自动帮你在业务无感知的情况下把同一次请求跑 N 轮(生成 → 评审 → 修正),最后只返回终稿给你;并且评审环节默认走 GPT-4o-mini,比业务调用的强模型便宜,所以总成本上升通常控制在 40% 至 70%。

自反思的三种主流范式(按适用场景选)

范式流程适合任务成本倍数正确率提升
① 外部评审式(External Critic)——最常用生成节点(模型A,温度高)输出初稿 → 评审节点(模型B,温度0)按 rubric 打 1-5 分 + 写修改意见 → 分数≥门槛就过,否则把修改意见 + 初稿一起喂回生成节点重写,最多 N 轮文案写作、报告生成、代码 Code Review、法律合同审阅×1.5 至 ×2.5+10% 至 +20%
② 自一致性投票式(Self-Consistency Ensemble)同一个问题用 5 个不同 seed / 温度独立生成 5 个答案 → 让 LLM 自己选「哪个答案最可能对」或者对数学题直接取多数投票,不需要额外写评审 rubric数学推理、多选题、有唯一标准答案的客观题×5 至 ×10(较贵)+5% 至 +15%(越难的题提升越多)
③ 过程式逐步反思(Step-level Critique)生成时不是一口气写完,而是每写一个步骤就暂停 → 反思「这一步对不对,有没有和前面矛盾」 → 不对就撤回这步重写,对了才写下一步超长逻辑链推理、复杂代码生成(先写伪代码再反思再写真代码)×3 至 ×6+15% 至 +30%(复杂任务提升大但慢)

自反思工程化的四个必加护栏(防止死循环和自欺欺人)

护栏 1:最大轮次硬上限 + 分数收敛检测。千万不要写「分数达到 4/5 才停」这种无限循环——评审模型心情一不好连续给 3 分,循环 20 次 token 账单直接炸。硬上限一般是 3 轮(初稿算第 0 轮,最多反思两次);加一个收敛检测:连续两轮分数没有变化(比如都是 3.2 分),说明改不动了,直接停。

护栏 2:生成模型和评审模型必须隔离,最好是不同模型。如果「自己写的稿子自己打分」,LLM 非常容易自欺欺人——给自己打 5 分或者只提无关痛痒的小毛病(「句子可以更通顺」这种废话),等于白加。标准做法:生成用强模型高温(GPT-4o / Claude Opus,温度 0.8-1.2,追求创造力),评审用中等模型低温(GPT-4o-mini / Claude Haiku,温度 0,追求稳定严格),评审模型看不到初稿的 System Prompt,完全以最终读者视角盲审。

护栏 3:评审 Rubric 必须是结构化、可量化的 3-5 条硬规则,禁止开放题。错误的评审 Prompt 是「请评价这段回答好不好」——评审模型会输出一堆没用的主观话。正确的评审 Prompt 必须长这样:「请按以下 4 条逐项打分,每条 1-5 分,最后给总分,分不够必须列出具体修改点(写清第几段第几句、改成什么):(1) 事实准确性:是否和召回文档一致,有没有幻觉;(2) 完整性:是否覆盖了用户问题的 3 个诉求点;(3) 格式合规:是否按要求输出 JSON,字段是否齐全;(4) 语气:是否符合客服中性专业语气,不出现推卸责任的话」。没有量化规则的评审等于没评审。

护栏 4:反思失败必须有兜底出口。连续 3 轮反思后分数仍然不达标(比如还是达不到 4/5),不是返回最后一稿就算了——必须触发降级逻辑:(a) 把最后三稿 + 所有评审意见打包给人工介入(工单系统自动派单);或者 (b) 切换到更强的模型(比如原本用 GPT-4o-mini,失败升级到 GPT-4o)跑最后一轮;或者 (c) 对用户主动说「这个问题我需要再确认一下,请稍等 5 分钟 / 留下联系方式稍后回复」,而不是硬给一个明知不对的答案。

常见问题

自反思是不是就是温度=0 多跑几次?有什么本质区别?
有本质区别:温度=0 多次跑叫「重复采样」,每次生成都是无记忆的独立事件;而自反思叫「有反馈的迭代修正」,每一轮生成都能看到上一轮的具体错误在哪里、应该怎么改,是带着反馈信号往前走的。举一个具体例子说明差距:写一个 100 行的 Python 函数,跑单测报错 IndexError 第 56 行。温度=0 重跑 3 次,可能每次都在同一个地方犯同一个 IndexError(因为确定性采样,只要提示不改输出几乎一模一样),根本修不好;自反思的流程是「初稿跑单测失败 → 把错误栈 traceback 喂给评审节点 → 评审节点说「第 56 行 list 越界是因为没判断当输入为空数组时的边界情况,你需要加一行 if len(arr)==0: return []」→ 生成节点带着这条具体修改意见重写 → 错误就修好了」。两者在代码生成、数学推理这类「有明确错误反馈信号」的任务上差距可以到 30 个百分点以上。
高并发场景加自反思,延迟翻倍用户受不了怎么办?
不要对所有请求一视同仁加自反思,要做「分级别触发」——只有高风险和高价值的请求才走反思链路,低风险请求直接返回初稿。工程上成熟的分层策略:(1)把所有请求按风险等级和价值打分,比如「涉及退款/医疗/法律建议」=高风险,「VIP 用户」=高价值,「问公司地址」=低风险低价值;(2)只有总分达到阈值(高风险或高价值)的请求才触发自反思(通常占总请求的 10% 至 20%),剩下 80% 低风险请求直接返回初稿;(3)再加一个「初稿置信度」信号——生成模型输出 logprobs,如果低置信度 token 占比超过阈值,说明模型自己都不确定说的对不对,这种不管风险级别都触发反思。按这个分层之后,自反思对全局平均延迟的影响从 100% 翻倍降到 10% 至 20%,绝大多数用户感知不到,只有少数关键请求拿到了反思后的高质量答案。并且自反思那 20% 的请求可以用「乐观流式返回 + 后台静默修正」:先把初稿流式吐给用户看,后台异步跑反思,如果反思后答案有显著不同,前端弹一个「刚刚为您更新了更准确的答案」并替换显示,用户体验和延迟都兼顾了。
评审模型本身也会评审错怎么办?会不会把本来对的答案改错?
评审模型也会犯错,这是客观事实,但工程上完全可以把「评审错误导致答案变差」的概率压到 1% 以下。四道防线:(1)「只改评审指出的具体位置,其他部分不动」——修正环节的 Prompt 必须明确写「只能修改评审明确指出的第 X 条、第 Y 句,其余所有内容必须一字不改复制」,防止模型借着反思的机会把本来对的段落也瞎改一通;(2)「双评审交叉验证」——对于高风险请求,用两个不同模型各自独立评审,只有两个评审都标记为错的点才允许修改,一个说对一个说错的点不动;(3)「反思前后对比校验」——修正完之后,再用一个极小的分类器判断「修正后的答案是否比初稿在 Rubric 上真的更好了」,如果分数没涨反而跌了,直接回滚返回初稿,不用修正版;(4)「保留修改痕迹」——在返回答案给业务的同时,把「初稿 + 每轮评审意见 + 修改点 diff」一起塞进响应的 meta 字段里,人工介入时一眼就能看到是不是评审改错了,并且这些 case 会定期回流去优化评审 Prompt 的 Rubric。上线前请务必做 500 条人工标注的 A/B 测试:确认「反思组答案正确率 - 对照组」统计显著为正且 ≥3%,才允许全量。