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的设计核心在于为模型提供一个结构化、可操作的评估框架。这个框架通常包括几个维度评估准则Criteria明确告诉模型从哪些方面进行评价。例如对于代码可读性准则可能包括“变量命名是否有意义”、“函数是否简短且功能单一”、“注释是否清晰”。评分机制Scoring为每个准则提供量化的打分方式如1-5分并解释每个分值对应的具体表现。这相当于给了模型一把“尺子”。具体建议Suggestions要求模型不仅打分还要给出具体的、可执行的修改建议。比如“第X行的变量a可以改为input_data以提升可读性”。在首字母缩写任务中反馈提示词会要求模型从“易读性”、“易拼写”、“与标题相关性”、“正面含义”、“知名度”五个维度对生成的缩写进行1-5分的打分并总结总分。为什么模型能做好这件事这得益于大语言模型在预训练时接触的海量文本中包含了大量人类进行评价、比较、批评的内容如产品评论、代码审查、文章评析。Self-Refine通过提示词成功“激活”了模型的这部分能力。2.3 迭代Refine基于反馈的精准改进拿到结构化的反馈包括分数和文字建议后模型切换回“生成者”模式。IteratePrompt的任务是结合原始输入、上一轮的输出、以及本轮收到的反馈生成一个改进后的新版本。这个提示词的关键在于要引导模型“专注”于反馈中指出的问题。例如“你之前生成的缩写是CLoCK反馈指出其在‘知名度’上得分较低2/5。请生成一个新的缩写在保持其他优点的基础上尝试提升其知名度或联想度。”模型此时的工作不再是天马行空地创造而是进行一种有针对性的、约束条件下的优化。它需要理解反馈权衡不同准则间的取舍比如为了提升知名度是否可以在相关性上做一点点妥协然后产生一个新的候选。2.4 循环与终止何时停下脚步这个“生成-反馈-迭代”的循环可以一直进行下去。那么什么时候停止呢论文中主要采用了两种策略固定迭代次数比如循环3次或4次。这是最简单直接的方法确保计算成本可控。基于反馈的自动终止当模型给出的反馈分数达到某个阈值例如总分超过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这个脚本会加载数据集中或指定的代码。使用Init提示词让模型生成“初始优化版”代码。使用Feedback提示词让模型批判自己的优化版从变量名、注释、函数长度等维度。使用Iterate提示词让模型根据反馈生成“改进版”。重复步骤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优化点分析函数名与变量名p-is_primea-numberr-is_prime(局部变量)i-divisor。名称立刻变得清晰。添加文档字符串Docstring明确了函数功能、参数和返回值。增加边界条件处理反馈环节模型可能意识到原代码对小于2的数处理不优雅返回1在迭代中主动增加了if number 2: return False。逻辑更清晰将r初始化为True找到因子时设为False比用1/0表示更符合布尔逻辑直觉。实操心得在代码可读性任务中Feedback提示词的设计至关重要。如果只让模型泛泛地“找问题”它可能只会说“变量名不好”。但如果我们明确要求它“检查变量名是否描述了其用途检查函数是否超过20行检查复杂逻辑块是否有注释”它给出的反馈就会具体得多从而指导下一轮生成更精准的修改。这提示我们想要模型给出高质量反馈我们必须先当好模型的“导师”通过提示词把我们的评估标准清晰地传递给它。4. 实战演练二解决数学推理问题GSM8KGSM8K是一个小学数学应用题数据集需要多步推理才能得出答案。传统方法是让模型直接生成推理链和答案。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这个脚本会做两件事计算最终准确率对比模型最终答案与标准答案。生成错误分析报告在gsm_outputs.jsonl.reports.txt中会展示那些最终答案仍错误的案例并列出模型在每一轮中的推理和反馈。这对于分析Self-Refine为何在某些问题上失效极具价值。4.3 从失败案例中学习我分析了报告中的一些错误案例发现失败原因主要有几类初始理解偏差模型一开始就错误理解了题意例如把“比率”理解成“差值”。后续的反馈和迭代都在错误的道路上进行修正无法回到正轨。这说明初始生成的质量是天花板。反馈力度不足模型发现了计算小错误但未能识别更深层的逻辑谬误或假设错误。例如在涉及“工作效率”的题目中模型可能忽略了“多人合作时总效率是效率和”这一关键点只检查了算术计算。纠正时引入新错误在根据反馈修改时模型可能修正了A点却不小心在B点引入了新的计算错误。避坑技巧对于数学推理这类对精确性要求极高的任务可以尝试“多轮反馈聚焦”策略。即在第一轮反馈中只要求模型检查计算算术错误在第二轮要求检查逻辑连贯性在第三轮检查是否回答了原始问题。这种分层次的反馈比让模型一次性检查所有方面更有效能减少反馈信息的过载和遗漏。5. 实战演练三创意生成与约束满足CommongenCommongen任务展示了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任务都围绕三个提示词展开它们定义了任务的“规则”Init提示词定义任务要求模型生成初始输出。关键要素任务描述、输入格式、输出格式要求。Feedback提示词定义评估标准要求模型对给定输出进行批判性评价。关键要素评估维度列表、每个维度的详细说明/评分标准、要求提供具体修改建议。Iterate提示词定义优化动作要求模型基于反馈改进输出。关键要素重申任务和原始输入展示上一轮输出和反馈明确要求生成改进版。项目里每个任务acronym/,readability/,gsm/等的目录下都有对应的task_init.py,feedback.py,task_iterate.py文件里面就是调用prompt-lib构建提示词的代码。这是最好的学习资料。6.2 构建自定义任务的步骤假设我想用Self-Refine来优化“产品功能描述文案”定义输入输出输入是粗糙的产品功能点列表输出是一段吸引人的、面向客户的产品描述文案。设计Init提示你是一位资深产品文案。请根据以下功能点撰写一段约200字的产品描述要求突出卖点语言生动。 功能点[用户提供的列表]设计Feedback提示你是一位严格的文案评审。请从以下维度评估这段产品描述 1. 信息准确性5分是否完整、正确地涵盖了所有功能点 2. 语言吸引力5分用语是否生动、有感染力能否激发购买欲 3. 结构清晰度5分逻辑是否顺畅重点是否突出 请对每个维度打分1-5并给出具体的修改建议例如“关于XX功能的描述可以更具体”“开头可以更抓人眼球”。 待评估文案[上一轮生成的文案]设计Iterate提示你是一位资深产品文案。这是原始功能点[用户提供的列表]。 这是你上一轮撰写的文案[上一轮文案]。 这是文案评审给出的反馈[收到的反馈]。 请仔细阅读反馈并在此基础上重新撰写一份改进后的产品描述文案。集成到框架参考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 常见问题排查表问题现象可能原因排查与解决思路迭代后质量无改善甚至下降1. 反馈提示词过于模糊。2. 迭代提示词未能有效利用反馈。3. 模型能力不足。1. 检查反馈提示词确保评估准则具体、可衡量用“变量名是否描述性”代替“代码是否好”。2. 在迭代提示词中明确要求“针对反馈中的第X点建议进行修改”。3. 尝试更换更强的基础模型如从GPT-3.5切换到GPT-4。模型陷入局部修改逃避核心问题反馈未能指出根本性错误或迭代时只在表面修改。1. 在反馈提示词中加入“请指出最根本的1-2个问题”。2. 采用“重启”策略如果连续两轮反馈相似且迭代无效清空历史用原始输入和累积的反馈要点重新生成一个全新版本。迭代过程不稳定输出波动大生成温度Temperature参数过高。在反馈和迭代阶段将温度调低如0.2以增加输出的确定性和一致性。初始生成阶段可以保持较高温度如0.7以获取多样性。任务本身不适合任务输出没有明确的“更好”标准或标准极度主观。Self-Refine依赖模型内在的“质量”概念。对于艺术创作等高度主观任务效果可能不佳。可尝试将主观标准分解为多个相对客观的子维度如“色彩搭配的和谐度”、“构图的平衡感”。API调用错误或超时网络问题、API密钥错误、速率限制。1. 检查prompt-lib的配置API key, base URL。2. 在代码中增加重试机制和指数退避策略。3. 监控API使用量和费用。7.2 方法的局限性依赖基础模型的能力Self-Refine的效果上限受限于所用大语言模型本身的能力。如果模型无法理解某个领域的知识那么它既无法生成好的初稿也无法给出有效的反馈。无法创造新知识它只能在模型已有知识范围内进行优化和重组。如果任务需要模型生成它不知道的信息迭代再多轮也无济于事。可能放大偏见如果基础模型的训练数据中存在某种偏见那么在自我反馈时模型可能会将这种偏见作为“正确”的标准从而在迭代中强化它。计算成本翻倍每一轮迭代都需要两次模型调用一次反馈一次生成成本是单次生成的2N倍N为迭代次数。7.3 个人实战心得提示词工程是核心Self-Refine的强大与否八成取决于三个提示词的设计。花时间精心设计反馈维度比盲目增加迭代次数有效得多。我的习惯是先人工扮演“批评者”对几个样例输出写下我的评语然后从中抽象出评估维度和话术再转化成给模型的提示词。从小处着手快速验证不要一开始就想着优化一个完整项目。选择一个非常具体、边界清晰的子任务比如“给这个函数改个名并加注释”跑通整个流程观察模型的反馈是否说到点子上。这能帮你快速调整提示词。把模型输出当“草案”永远不要完全信任模型的最终输出尤其是关键任务。Self-Refine是一个强大的“副驾驶”或“初级助手”它能产出质量高得多的草案但最终的责任和决策权应该在人类手中。将其产出作为灵感来源或修改基础而非最终成品。结合其他技术Self-Refine可以和其他技术结合。例如在生成多个初始草案后用Self-Refine分别对每个草案进行迭代优化最后再用一个选择器可以是另一个模型也可以是规则挑出最好的。这结合了多样性和深度优化的优点。Self-Refine为我打开了一扇新的大门让我看到大语言模型不仅仅是一个静态的知识库或生成器更可以成为一个具备自我改进能力的动态系统。它降低了构建高质量AI应用的门槛因为你不再需要为每个任务都去收集大量的“好-坏”对比数据来训练一个评判模型。尽管有其局限但作为提示工程和模型自我提升方向的一次精彩实践它无疑为我们利用现有大模型能力提供了又一把利器。在实际项目中我已经开始尝试用它来辅助代码审查、润色技术文档和设计用户故事效果提升是肉眼可见的。最关键的是这个过程本身也让我对如何与AI协作有了更深的理解。