Self-Refine：大语言模型自我迭代优化的原理与实践

1. 项目概述：Self-Refine，让大模型学会自我迭代

最近在折腾大语言模型（LLM）应用时，我一直在思考一个问题：我们给模型一个指令，它生成一个结果，然后我们人类再去评判好坏、给出反馈、让它重写。这个过程里，模型就像一个被动的执行者，它自己并不知道“好”的标准是什么，更别提主动优化了。有没有可能让模型自己给自己当“教练”，通过自我反馈和迭代，把活儿干得更好呢？

这个想法，在Aman Madaan等人发表的论文《Self-Refine: Iterative Refinement with Self-Feedback》里变成了现实，并且开源了同名项目。简单来说，Self-Refine的核心思想是让同一个大语言模型，交替扮演“生成者”和“批评者”两个角色。生成者先出一个初稿，批评者立刻对这个初稿进行审视、打分、提出修改意见，然后生成者再根据这些意见，生成一个改进版本。这个过程可以循环多次，直到输出结果达到满意的标准，或者达到预设的迭代次数上限。

这听起来有点像我们写文章时的自我修改：写完一段，自己读一遍，觉得这里逻辑不通顺，那里用词不准确，然后动手修改。Self-Refine就是把这种人类的内省能力，通过精心设计的提示词（Prompt），赋予给了大语言模型。它不再需要额外的人工标注数据来训练一个独立的“评判模型”，也不需要复杂的强化学习框架，仅仅依靠模型自身在预训练阶段获得的知识和推理能力，就能实现输出的持续优化。

我花了不少时间研读论文和跑通他们的代码，发现这个框架的潜力远超我的预期。它不是一个只能跑通论文实验的“玩具”，而是一个方法论清晰、可扩展性强、能直接应用到多种实际任务中的通用框架。无论是让代码变得更易读，还是生成更合理的对话回复，甚至是解决数学推理问题，Self-Refine都展现出了比传统“一步生成”方法更优的性能。

接下来，我就结合自己的实践，带你深入拆解Self-Refine的运作机制、核心模块，并手把手展示如何将它应用到几个典型任务上，最后再分享一些我踩过的坑和实战心得。

2. 核心机制拆解：生成、反馈、迭代的三步舞曲

Self-Refine的流程可以抽象为一个清晰的循环：生成（Generate） -> 反馈（Feedback） -> 迭代（Refine）。理解这个循环里每个环节的设计，是灵活运用该方法的关键。

2.1 生成（Generate）：不仅仅是初稿

生成环节的目标是产生任务的初始输出。这里的“任务”定义非常宽泛，可以是一段代码、一个问题的答案、一段文本摘要，甚至是一张图的描述（在视觉任务中）。这个环节的提示词（InitPrompt）设计，直接决定了迭代优化的起点质量。

注意：很多人会误以为初始生成可以很粗糙，反正后面会改。但实际上，一个高质量的初始输出，能让后续的反馈和迭代更聚焦于“锦上添花”，而不是“从零救火”。如果初始输出完全偏离主题或包含根本性错误，模型在自我反馈阶段可能难以识别或纠正。

以论文中的“首字母缩写生成”任务为例，输入是一篇论文的标题“Using language models of code for few-shot commonsense”，目标是生成一个好听、易记、相关的缩写。InitPrompt会明确告诉模型：“请为这个标题生成一个候选缩写，并确保它易于发音、拼写，且与标题内容相关。”

2.2 反馈（Feedback）：模型如何扮演“严师”

这是Self-Refine最具创新性的环节。模型需要暂时忘记自己“生成者”的身份，转而以一个“批评者”或“评估者”的视角，来审视刚才自己产出的内容。FeedbackPrompt的设计，核心在于为模型提供一个结构化、可操作的评估框架。

这个框架通常包括几个维度：

1. 评估准则（Criteria）：明确告诉模型从哪些方面进行评价。例如，对于代码可读性，准则可能包括“变量命名是否有意义”、“函数是否简短且功能单一”、“注释是否清晰”。
2. 评分机制（Scoring）：为每个准则提供量化的打分方式（如1-5分），并解释每个分值对应的具体表现。这相当于给了模型一把“尺子”。
3. 具体建议（Suggestions）：要求模型不仅打分，还要给出具体的、可执行的修改建议。比如“第X行的变量a可以改为input_data以提升可读性”。

在首字母缩写任务中，反馈提示词会要求模型从“易读性”、“易拼写”、“与标题相关性”、“正面含义”、“知名度”五个维度，对生成的缩写进行1-5分的打分，并总结总分。

为什么模型能做好这件事？这得益于大语言模型在预训练时接触的海量文本中，包含了大量人类进行评价、比较、批评的内容（如产品评论、代码审查、文章评析）。Self-Refine通过提示词，成功“激活”了模型的这部分能力。

2.3 迭代（Refine）：基于反馈的精准改进

拿到结构化的反馈（包括分数和文字建议）后，模型切换回“生成者”模式。IteratePrompt的任务是：结合原始输入、上一轮的输出、以及本轮收到的反馈，生成一个改进后的新版本。

这个提示词的关键在于，要引导模型“专注”于反馈中指出的问题。例如：“你之前生成的缩写是CLoCK，反馈指出其在‘知名度’上得分较低（2/5）。请生成一个新的缩写，在保持其他优点的基础上，尝试提升其知名度或联想度。”

模型此时的工作，不再是天马行空地创造，而是进行一种有针对性的、约束条件下的优化。它需要理解反馈，权衡不同准则间的取舍（比如为了提升知名度，是否可以在相关性上做一点点妥协），然后产生一个新的候选。

2.4 循环与终止：何时停下脚步

这个“生成-反馈-迭代”的循环可以一直进行下去。那么，什么时候停止呢？论文中主要采用了两种策略：

1. 固定迭代次数：比如循环3次或4次。这是最简单直接的方法，确保计算成本可控。
2. 基于反馈的自动终止：当模型给出的反馈分数达到某个阈值（例如总分超过23/25），或者反馈中明确表示“无需进一步修改”时，循环终止。

在实际应用中，我通常采用固定迭代次数+人工审核的方式。比如设置最大迭代5次，每次迭代后都观察输出和反馈的变化。经常能看到，模型在头两轮改进最大，后续轮次可能只是在微调措辞，这时就可以提前终止，节省资源。

3. 实战演练一：提升代码可读性（Code Readability）

理论讲完了，我们来看一个非常实用的场景：让大模型优化一段写得比较“烂”的代码，提升其可读性。这个任务对于程序员日常维护遗留代码库或进行代码审查非常有帮助。

3.1 任务定义与数据准备

Self-Refine项目中使用的是CodeNet数据集中的Python代码片段。任务目标是：给定一段功能正确但可读性差的代码（例如变量名是a,b,c，没有注释，函数冗长），生成一个功能等价但更易于人类理解和维护的版本。

首先，我们需要准备环境。项目依赖prompt-lib这个库来管理与大语言模型（如OpenAI API）的交互。

# 1. 克隆Self-Refine仓库 git clone https://github.com/madaan/self-refine cd self-refine # 2. 安装prompt-lib git clone https://github.com/reasoning-machines/prompt-lib pip install prompt-lib/ # 3. 设置Python路径（避免模块导入错误） export PYTHONPATH=".:$PYTHONPATH"

接下来，需要解压项目自带的数据集：

# 进入数据目录并解压 cd data/tasks/codeclean/code_readability/ unzip codenet-python-train.jsonl.zip

这个JSONL文件里，每一行都是一个JSON对象，包含input（原始代码）和output（人工改写后的、可读性更好的代码，用于评估）。

3.2 运行Self-Refine流程

项目已经为我们写好了脚本。运行以下命令，模型就会开始对代码进行自我迭代优化：

# 在项目根目录执行 PYTHONPATH="." python -u src/readability/readability.py --output ./my_refined_code.jsonl

这个脚本会：

1. 加载数据集中（或指定）的代码。
2. 使用Init提示词让模型生成“初始优化版”代码。
3. 使用Feedback提示词让模型批判自己的优化版（从变量名、注释、函数长度等维度）。
4. 使用Iterate提示词让模型根据反馈生成“改进版”。
5. 重复步骤3和4，直到达到最大迭代次数（默认配置）。

3.3 效果评估与解析

跑完程序后，我们如何评估优化效果呢？项目提供了几个简单的评估脚本，它们通过计算一些客观指标来对比优化前后的代码：

# 计算优化后代码中“有意义的变量名”比例 PYTHONPATH="." python -u src/readability/count_meaningful_var.py --file ./my_refined_code.jsonl # 计算函数注释的比例 PYTHONPATH="." python -u src/readability/count_comment.py --file ./my_refined_code.jsonl # 统计函数数量（判断是否进行了合理的函数拆分） PYTHONPATH="." python -u src/readability/count_function.py --file ./my_refined_code.jsonl

我找了一段简单的示例代码做测试：原始代码：

def p(a): r = 1 for i in range(2, int(a**0.5)+1): if a % i == 0: r = 0 break return r

经过两轮Self-Refine优化后的代码：

def is_prime(number): """ Checks if a given number is a prime number. Args: number (int): The number to check for primality. Returns: bool: True if the number is prime, False otherwise. """ if number < 2: return False is_prime = True for divisor in range(2, int(number ** 0.5) + 1): if number % divisor == 0: is_prime = False break return is_prime

优化点分析：

1. 函数名与变量名：p->is_prime，a->number，r->is_prime(局部变量)，i->divisor。名称立刻变得清晰。
2. 添加文档字符串（Docstring）：明确了函数功能、参数和返回值。
3. 增加边界条件处理：反馈环节模型可能意识到原代码对小于2的数处理不优雅（返回1），在迭代中主动增加了if number < 2: return False。
4. 逻辑更清晰：将r初始化为True，找到因子时设为False，比用1/0表示更符合布尔逻辑直觉。

实操心得：在代码可读性任务中，Feedback提示词的设计至关重要。如果只让模型泛泛地“找问题”，它可能只会说“变量名不好”。但如果我们明确要求它“检查变量名是否描述了其用途，检查函数是否超过20行，检查复杂逻辑块是否有注释”，它给出的反馈就会具体得多，从而指导下一轮生成更精准的修改。这提示我们，想要模型给出高质量反馈，我们必须先当好模型的“导师”，通过提示词把我们的评估标准清晰地传递给它。

4. 实战演练二：解决数学推理问题（GSM8K）

GSM8K是一个小学数学应用题数据集，需要多步推理才能得出答案。传统方法是让模型直接生成推理链和答案。Self-Refine则引入了一个新思路：让模型检查自己的推理步骤是否存在逻辑或计算错误。

4.1 任务的特殊性：反馈作用于推理过程

对于数学问题，反馈的对象不是最终答案，而是得到答案的推理过程（Chain of Thought, CoT）。Init阶段，模型生成一个包含步骤的解答。Feedback阶段，模型需要逐步检查：题目理解是否正确？每一步的推导是否合理？计算是否准确？单位是否一致？最后答案是否回答了问题？

例如，题目是：“小明有5个苹果，他每天吃2个，3天后还剩几个苹果？”

• 初始生成：5 - 2 = 3 (第一天后剩3个), 3 - 2 = 1 (第二天后剩1个), 1 - 2 = -1 (第三天后剩-1个)。答案是-1个。
• 模型自我反馈：“第三步计算错误。第三天开始时只有1个苹果，吃2个是不够的。通常这种问题隐含‘不够吃就停止’或‘不会出现负数’的常识。应该修正为：第三天只能吃1个，剩余0个。”
• 迭代生成：总苹果5个。第一天吃2个，剩3个。第二天吃2个，剩1个。第三天只有1个苹果可吃，吃完后剩0个。答案是0个。

4.2 运行与评估

运行GSM8K任务的命令很简单：

python -u src/gsm/run.py

程序会读取GSM8K测试集，对每个问题运行Self-Refine流程，并将每一轮的输出、反馈和最终答案保存到data/tasks/gsm/gsm_outputs.jsonl。

评估时，使用项目提供的脚本：

python src/gsm/gsm_selfref_eval.py --path data/tasks/gsm/gsm_outputs.jsonl

这个脚本会做两件事：

1. 计算最终准确率：对比模型最终答案与标准答案。
2. 生成错误分析报告：在gsm_outputs.jsonl.reports.txt中，会展示那些最终答案仍错误的案例，并列出模型在每一轮中的推理和反馈。这对于分析Self-Refine为何在某些问题上失效极具价值。

4.3 从失败案例中学习

我分析了报告中的一些错误案例，发现失败原因主要有几类：

1. 初始理解偏差：模型一开始就错误理解了题意（例如，把“比率”理解成“差值”）。后续的反馈和迭代都在错误的道路上进行修正，无法回到正轨。这说明初始生成的质量是天花板。
2. 反馈力度不足：模型发现了计算小错误，但未能识别更深层的逻辑谬误或假设错误。例如，在涉及“工作效率”的题目中，模型可能忽略了“多人合作时总效率是效率和”这一关键点，只检查了算术计算。
3. 纠正时引入新错误：在根据反馈修改时，模型可能修正了A点，却不小心在B点引入了新的计算错误。

避坑技巧：对于数学推理这类对精确性要求极高的任务，可以尝试“多轮反馈聚焦”策略。即，在第一轮反馈中，只要求模型检查计算算术错误；在第二轮，要求检查逻辑连贯性；在第三轮，检查是否回答了原始问题。这种分层次的反馈，比让模型一次性检查所有方面更有效，能减少反馈信息的过载和遗漏。

5. 实战演练三：创意生成与约束满足（Commongen）

Commongen任务展示了Self-Refine在创意生成领域的应用。给定一组概念词（如cmd,stair,bubble,team），要求生成一个通顺、合理且包含所有这些词的句子。这比简单造句难，因为词之间可能毫无关联。

5.1 创意任务中的反馈设计

对于创意任务，Feedback提示词需要引导模型评估句子的流畅性、逻辑性、创意性和约束满足度。

• 初始生成：The cmd team walked up the stair and saw a bubble.（句子通顺，但cmd用得生硬，像是强行插入）。
• 模型自我反馈：“句子语法正确，包含了所有词。但‘cmd’（通常指命令行）与‘team’、‘stair’、‘bubble’的语境融合度不高，显得突兀。整体创意一般。”
• 迭代生成：The software team, working from the command line (cmd), celebrated their success by blowing a bubble gum bubble at the top of the stair.（将cmd解释为command line并融入软件开发场景，逻辑更自洽，创意提升）。

5.2 运行与观察

运行命令尝试一组词：

python -u src/commongen/run.py cmd stair bubble team dryer puppy aliens cat

你会看到在终端中，模型不断输出每一轮的句子和反馈分数。观察这个动态过程非常有趣，你能看到句子如何从一个生硬的版本，在模型自我批评和调整下，逐渐变得自然、有趣。

这个任务揭示了Self-Refine的另一个优势：它在满足硬性约束（必须包含某些词）的同时，优化软性指标（流畅度、创意）。传统的约束生成可能靠采样多个句子再筛选，而Self-Refine通过反馈迭代，让单个句子朝着多目标优化的方向进化。

6. 通用设置与自定义任务指南

如果你想将Self-Refine应用到自己的任务上，需要理解其通用框架并准备三个核心提示词。

6.1 框架的三要素：提示词

每个Self-Refine任务都围绕三个提示词展开，它们定义了任务的“规则”：

1. Init提示词：定义任务，要求模型生成初始输出。关键要素：任务描述、输入格式、输出格式要求。
2. Feedback提示词：定义评估标准，要求模型对给定输出进行批判性评价。关键要素：评估维度列表、每个维度的详细说明/评分标准、要求提供具体修改建议。
3. Iterate提示词：定义优化动作，要求模型基于反馈改进输出。关键要素：重申任务和原始输入，展示上一轮输出和反馈，明确要求生成改进版。

项目里每个任务（acronym/,readability/,gsm/等）的目录下，都有对应的task_init.py,feedback.py,task_iterate.py文件，里面就是调用prompt-lib构建提示词的代码。这是最好的学习资料。

6.2 构建自定义任务的步骤

假设我想用Self-Refine来优化“产品功能描述文案”：

1. 定义输入输出：输入是粗糙的产品功能点列表，输出是一段吸引人的、面向客户的产品描述文案。
2. 设计Init提示：

   你是一位资深产品文案。请根据以下功能点，撰写一段约200字的产品描述，要求突出卖点，语言生动。 功能点：[用户提供的列表]

3. 设计Feedback提示：

   你是一位严格的文案评审。请从以下维度评估这段产品描述： 1. 信息准确性（5分）：是否完整、正确地涵盖了所有功能点？ 2. 语言吸引力（5分）：用语是否生动、有感染力？能否激发购买欲？ 3. 结构清晰度（5分）：逻辑是否顺畅？重点是否突出？ 请对每个维度打分（1-5），并给出具体的修改建议，例如“关于XX功能的描述可以更具体”，“开头可以更抓人眼球”。 待评估文案：[上一轮生成的文案]

4. 设计Iterate提示：

   你是一位资深产品文案。这是原始功能点：[用户提供的列表]。 这是你上一轮撰写的文案：[上一轮文案]。 这是文案评审给出的反馈：[收到的反馈]。 请仔细阅读反馈，并在此基础上，重新撰写一份改进后的产品描述文案。

5. 集成到框架：参考src目录下任一任务的run.py，编写自己的主循环，依次调用三个提示词，并管理迭代状态。

6.3 模型选择与成本考量

Self-Refine论文中使用了GPT-3.5和GPT-4。我的经验是：

• GPT-4：在反馈和迭代环节表现显著更优，尤其是需要深度推理、理解复杂准则的任务（如代码优化、数学解题）。但成本高昂。
• GPT-3.5-Turbo：性价比高，对于语言风格优化、简单文案修改等任务足够用。但在需要精细逻辑判断时，其反馈可能不够深入或准确。
• 本地大模型：理论上可以，但对模型的要求很高。需要模型具备强大的指令遵循、批判性思维和文本生成能力。目前开源的70B参数级别的模型或许可以尝试，但效果和稳定性需大量调试。

成本控制技巧：对于非关键任务，可以采用“混合策略”。用GPT-3.5做多轮迭代，然后用GPT-4对最终结果做一次最终的“质检反馈”。或者，在迭代过程中，每隔一轮使用一次GPT-4进行反馈，以纠正可能累积的偏差。另外，合理设置最大迭代次数是控制成本最直接有效的方法，很多任务在2-3轮后改善就很小了。

7. 常见问题、局限性与实战心得

在大量实验后，我总结了Self-Refine的一些常见问题和局限性，以及对应的应对策略。

7.1 常见问题排查表

7.2 方法的局限性

1. 依赖基础模型的能力：Self-Refine的效果上限受限于所用大语言模型本身的能力。如果模型无法理解某个领域的知识，那么它既无法生成好的初稿，也无法给出有效的反馈。
2. 无法创造新知识：它只能在模型已有知识范围内进行优化和重组。如果任务需要模型生成它不知道的信息，迭代再多轮也无济于事。
3. 可能放大偏见：如果基础模型的训练数据中存在某种偏见，那么在自我反馈时，模型可能会将这种偏见作为“正确”的标准，从而在迭代中强化它。
4. 计算成本翻倍：每一轮迭代都需要两次模型调用（一次反馈，一次生成），成本是单次生成的2N倍（N为迭代次数）。

7.3 个人实战心得

1. 提示词工程是核心：Self-Refine的强大与否，八成取决于三个提示词的设计。花时间精心设计反馈维度，比盲目增加迭代次数有效得多。我的习惯是，先人工扮演“批评者”，对几个样例输出写下我的评语，然后从中抽象出评估维度和话术，再转化成给模型的提示词。
2. 从小处着手，快速验证：不要一开始就想着优化一个完整项目。选择一个非常具体、边界清晰的子任务（比如“给这个函数改个名并加注释”），跑通整个流程，观察模型的反馈是否说到点子上。这能帮你快速调整提示词。
3. 把模型输出当“草案”：永远不要完全信任模型的最终输出，尤其是关键任务。Self-Refine是一个强大的“副驾驶”或“初级助手”，它能产出质量高得多的草案，但最终的责任和决策权应该在人类手中。将其产出作为灵感来源或修改基础，而非最终成品。
4. 结合其他技术：Self-Refine可以和其他技术结合。例如，在生成多个初始草案后，用Self-Refine分别对每个草案进行迭代优化，最后再用一个选择器（可以是另一个模型，也可以是规则）挑出最好的。这结合了多样性和深度优化的优点。

Self-Refine为我打开了一扇新的大门，让我看到大语言模型不仅仅是一个静态的知识库或生成器，更可以成为一个具备自我改进能力的动态系统。它降低了构建高质量AI应用的门槛，因为你不再需要为每个任务都去收集大量的“好-坏”对比数据来训练一个评判模型。尽管有其局限，但作为提示工程和模型自我提升方向的一次精彩实践，它无疑为我们利用现有大模型能力提供了又一把利器。在实际项目中，我已经开始尝试用它来辅助代码审查、润色技术文档和设计用户故事，效果提升是肉眼可见的。最关键的是，这个过程本身，也让我对如何与AI协作有了更深的理解。