Self-Refine: Iterative Refinement with Self-Feedback

LLM 的第一次回答往往是一个能用的草稿，仍可能遗漏约束、解释不够清楚或代码效率低。逐次让人指出问题成本高，训练专用 Refiner 又需要数据。Self-Refine 研究同一个固定 Model 能否在推理时生成有针对性的 Feedback，再据此修改当前输出。

人写程序时常先得到正确但低效的实现，再从复杂度或边界条件检查它。Model 的生成和诊断能力也可能不完全同步。由此可以先把评价目标写清楚，让它只找具体问题，再让下一次调用只负责修复这些问题。独立的 Feedback 阶段是否有增益，要和等预算的重复生成比较。

同一 model 生成初稿与检查初稿时面对的任务不同：先找可改之处，再据此修订，可能调用一次生成未充分使用的能力。Self-Refine 将这种分工实现为 prompt 循环，改善对象是当前输出，为研究 self-feedback 的效果提供了清晰而轻量的起点。

原文展示了求 1 到 N 之和的代码优化案例。初稿使用循环逐个累加；Feedback 指出存在 Closed-form Expression；Refinement 改为 N(N+1)/2。代入 N=5 得到 15，是对原文案例的教学演算。Pipeline 的输入是任务与初稿，处理中保留反馈和修订历史，输出是最终程序；固定 Model 和外层循环并未因此更新。

算法本身没有必须掌握的新数学定理。把 y_t 看作第 t 版答案，f_t 是对它的反馈，R 是固定 Model 的修订调用，即可写出迭代。循环只是描述信息流，没有规定某个真实质量函数必须每步上升。代码案例中的求和公式可由首尾配对理解：每对和为 N+1，共 N/2 对，因此总和为 N(N+1)/2。

f_t = Feedback(x, y_t)
y_(t+1) = Refine(x, y_t, f_t, history)
1 + 2 + … + N = N(N+1)/2

最实用的模式是将一个宽泛请求拆成可检查的维度，例如代码复杂度、任务约束或措辞。最容易误读的地方是把当前答案变好等同于系统学会了新能力；这篇研究主要提供 Task-local Refinement 证据。

最脆弱的假设是 Feedback 比初稿更可靠。若 Model 对问题本身有系统性误解，反馈可能只是更自信地重复误解，并把原本正确的部分改错。

变化发生在当前回答中；这不是 model weights 或 self-improvement 算法的持续演化。