LLM自进化这个话题最近半年在圈子里被反复聊起每次组会都有人问“能不能让模型自己生成数据再自己训自己”。说白了这就是一个增强回路大模型自己出题、自己作答、自己打分再把筛选后的数据喂回去微调让下一次迭代更强。它的价值不是替代人工标注而是把那些人工成本过高、又必须反复积累的环节自动化让模型在已经学会的能力基础上持续爬坡。这篇文章我会把自进化的几条主流技术路线拆开讲清楚然后给出一条我能跑通的最小流水线实录最后说说我在数据塌缩、自评偏差上踩过的坑希望对正在做 LLM 微调或 Agent 落地的朋友有参考价值。1. LLM自进化到底在解决什么问题1.1 从数据瓶颈说起做对话模型、垂直领域助手的人都有体会模型效果的上限很大程度上被训练数据卡着。公开的高质量指令数据就那么些英文的多、中文的少通用场景多、专业场景少。想自己标注一批数据招人、写标注规范、做质检一套下来成本极高还未必能覆盖长尾场景。自进化的核心动机就在这里与其等人来写数据不如让模型利用已有能力去“产出”训练素材。这背后的前提是现阶段的 LLM 在生成、判断、反思上已经具备相当强的能力。它虽然不能保证每个回答都正确但它能生成大量候选也能大致判断哪些回答更好——这两件事组合起来就构成了一条可以自动转起来的数据生产流水线。要注意的是“让 AI 自己训练自己”并不是指模型直接修改自己的权重那是当前架构做不到的。实际的做法是模型产出数据 → 用某种机制筛选 → 用筛选后的数据做监督微调SFT或偏好优化DPO/RLHF→ 得到新模型 → 继续迭代。自进化是一个训练流程层面的工程方案不是一个神秘的算法。1.2 自进化的基本框架不管技术路线怎么变自进化流水线大致都长这样种子集一小撮高质量种子指令或问题作为起点可能只有几十到几千条。生成用当前模型或辅助模型对种子集进行扩写、改写、多轮生成扩大数据规模。筛选通过规则、外部工具、模型自评分等方式过滤低质量样本。训练:在筛选后的数据上做 SFT 或 DPO得到新一轮模型。评估用固定评测集检查是否真的变强了决定是否继续迭代。这个框架本身不复杂真正的难点在每个环节的质量控制。生成环节怎么保证多样性筛选环节怎么防止模型“自卖自夸”训练环节怎么避免灾难性遗忘这些都是实操里绕不开的坎后面我会一个个展开。2. 三大主流技术路线拆解2.1 自指令与合成数据让模型当出题人先说最经典的一条线代表工作是斯坦福 2022 年的 Self-Instruct。它的思路很直接:先准备一小批种子指令比如 175 条人工写的任务描述让模型模仿这些指令的风格生成新的指令然后让模型为新指令生成回答最后用规则过滤掉过于相似的样本合并成新数据集去微调模型。这个方案最容易被低估的点是“指令生成”的难度。你如果直接跟模型说“再给我生成 100 条问题”它往往会退化成同义改写表面上一堆变体实际信息量很低。Self-Instruct 原文里做了不少细节设计比如限制关键词重叠度、用 ROUGE 相似度去重就是为了逼模型产出真正多样的任务。后来的合成数据工作基本都在这个框架上加料。比如在指令里要求模型替换领域、变换复杂度、指定输出格式或者用一个强模型比如大参数的闭源模型做教师生成数据后再交给小模型去学。我自己的经验是自指令生成的数据质量方差很大必须配合严格筛选否则模型很快会学到“话多但空洞”的毛病。2.2 自评估与自反馈让模型当裁判第二条线是让模型参与质量评估代表方向是 Constitutional AI 和 RLAIFReinforcement Learning from AI Feedback)。Constitutional AI 的做法是给模型一组行为准则让它基于这些准则对自己的输出进行批评和修订用修订后的回答构造偏好对再训练一个奖励模型最后做强化学习。这条线在实操里非常依赖“评估提示词”的设计。你让模型打分它很容易犯两个毛病:一是所有分数都往高处给缺乏区分度二是容易被长回答带跑觉得字数多就是质量高。解决这些问题没有银弹常用的手段包括要求模型先输出评审理由再给出分数、强制使用 1~5 分或 1~10 分的离散标尺、对长度做回归修正、引入多个独立打分取平均。自评估的另一个衍生方向是自我反思Self-Refine/Reflexion。模型回答一个问题后先自己审视哪里错了把反思结果写下来再带着反思去重新回答。这不需要重新训练只是在推理阶段加了一步迭代但对数学题、代码调试这类任务提升明显。如果再把反思后的正样本收集起来做微调就变成了 STaRSelf-Taught Reasoner那套逻辑模型自己尝试解答只保留回答正确的推理过程拿去微调循环往复。2.3 自我博弈与迭代偏好优化第三条线更像是强化学习的思路让模型和自己的不同版本竞争或合作不断拉高上限。Self-Play Fine-Tuning 是让模型针对同一指令生成两个回答然后自己判断哪个更好把偏好对拿去做 DPO。Meta 的 Self-Rewarding Language Models 更进一步模型同时具备生成和评估能力每次迭代都用模型自己构造的偏好对训练让模型的判断力也跟着提升。迭代 DPO 是我在实际项目里用得最多的一种形态。流程大概是用当前模型对一批指令生成两个回答 → 用奖励模型或规则打分 → 构建好/坏偏好对 → 做一轮 DPO → 得到新模型 → 重复。每一次迭代模型生成数据的分布都在移动所以每一轮都要重新生成数据不能拿旧数据反复用。这条线最大的坑是“自我欺骗”模型打分偏好很容易被某个表面特征抓住比如带很多 bullet point 就高分于是训练完的模型学会了堆格式、堆术语真实能力并没有提升。所以我通常会把自评分和规则评分混合使用至少留一部分硬性检查关键词是否出现、格式是否合法、长度是否达标、是否能被验证器确认不要让模型一个人说了算。3. 实操记录搭建一条最小可用的自进化流水线3.1 环境与模型选型先说结论如果你只是想跑通流程验证想法不需要一张 A100。7B 级别的开源模型配合 LoRA一张 24GB 显存的消费级卡就能做微调数据生成阶段用 vLLM 加速推理8GB 显存也能勉强跑小模型。我自己这次演示用的是一张 409024GB微调用的 Qwen2.5-7B-Instruct推理用 vLLM训练用 LLaMA-Factory 的 DPO 组件。选模型时有几个经验第一基座模型本身能力不能太弱自进化的天花板由“生成质量判断质量”共同决定模型如果连基本的格式化输出都做不好后面全是垃圾进垃圾出第二优先选指令微调过的模型因为自评估、自我反思这些操作对遵循指令的能力要求很高第三如果预算允许教师模型和学生模型分开用一个更强的模型做评分器能明显缓解自评偏差。依赖环境其实就三块推理服务vLLM、微调框架LLaMA-Factory 或 TRL、评测工具lm-evaluation-harness 或自己写脚本。我当时是直接用 conda 建了一个 Python 3.10 的环境装好 torch 2.3 CUDA 12.1然后 pip 装 vllm 和 LLaMA-Factory整体没遇到什么环境地狱比早期折腾 TF 舒服太多。3.2 第一轮种子集生成我做的任务是一个垂直领域的技术问答场景目标是让模型在“数据库性能优化”这类问题上回答得更专业。种子集我用了两批一批是从已有日志和知识库抽出的 500 条真实用户问题一批是人工写的 50 条高质量问题模板。然后写提示词让 Qwen2.5-7B 基于种子问题扩写要求“保持领域不变、难度覆盖从入门到资深、输出格式为问答对”。这里有个关键参数生成温度。我第一次跑的时候温度设成 0.3结果 2000 条数据里有一大半是近义改写多样性很差。后来调到 0.9多样性上来了但噪声也明显变多。最终我采用的是分桶策略基础问题用低温度0.4生成保证可用性复杂推理类问题用高温度0.9生成保证多样性两边数据量按 7:3 混合。生成完成后必须做一轮机器清洗我用的规则有长度过滤回答少于 50 字或超过 2000 字的去掉、去重对问题做 SimHash 去重、格式校验必须包含“问题”“回答”两个字段、安全词过滤。这一轮从 3000 条原始生成里筛出了约 1800 条进入下一步。3.3 迭代优化反馈、筛选、微调闭环数据准备好之后就是标准的迭代循环。我拆成四个步骤来跑第一步用当前模型为每条指令生成两个独立回答温度 0.7seed 不同。注意一定要用两个不同随机种子多次采样否则两次回答高度相似后面构造偏好对时区分度太低。第二步评分。我混合了三种信号规则分数是否包含关键实体、是否存在重复表述、长度是否合理 Qwen2.5-72B 教师模型的 1~5 分打分 人工抽检的 100 条做校准基准。三种信号加权合成最终分数权重的确定方式比较粗糙——我先跑了一轮看哪个权重的排序结果和人工抽检一致性高再固定下来。第三步构造训练数据。SFT 数据取分数前 30% 的回答DPO 数据取同一指令下高分回答和低分回答配成对要求两段回答长度差不能超过 1.5 倍避免模型只学“长对”这种捷径。第四步训练。SFT 用 LoRArank32alpha64学习率 2e-4DPO 用同样的 LoRA 配置beta 默认 0.1。每轮迭代训练 3 个 epoch同时用保留的 500 条评测题做自动评估如果 BLEU/相似度分数掉了就回滚上一轮权重。这样一个循环跑下来大约花 6~8 个小时数据生成 2 小时 评分 1 小时 训练 2 小时 评估 1 小时。我跑了三轮第二轮的收益最明显第三轮提升就很小了再往下开始出现退化迹象。这个“三轮之后收益递减”的现象不是偶然模型在自身输出分布上反复拟合边际收益必然下降这时候应该停止而不是硬着头皮继续刷。4. 常见问题与避坑实录4.1 数据塌缩模型越训越窄数据塌缩模型坍缩是自进化最隐蔽的杀手。现象是模型在评测集上分数挺好看但实际对话时明显变“油滑”了什么话题都能接但回答都很空知识面反而变窄了。原因是反复用模型自己的输出训练会把数据分布推向模型已经擅长的区域长尾知识逐渐消失。这就好比一个学生反复做自己会做的题成绩单好看但遇到没见过的题型立刻露馅。我的对策有三个每轮迭代必须混入至少 30% 的原始人工数据或外部高质量数据防止分布偏移生成时故意引入高温度样本保持分布宽度设定一个多样性监控指标比如回答的 embedding 聚类的平均距离如果连续两轮多样性显著下降立即停止迭代。4.2 自评偏差与提示词敏感模型给自己打分这件事远没有论文里那么可靠。我试过让同一个模型用不同提示词打分相关系数只有 0.6 左右如果提示词里加了“请严格打分”分数分布会整体下移但排序几乎没有变化——也就是说模型学会了调整分数的尺度但没有学会真正区分好坏。几类典型的自评偏差宽松偏差给分普遍偏高集中在 4~5 分失去区分度。长度偏差回答越长分数越高跟内容质量无关。位置偏差两个回答做对比时排在前面的更容易被选中。术语偏好看起来专业术语多的回答得分高实际可能是胡编。缓解手段对长度做显式分箱校正对比评估时交换两个回答的顺序、跑两次再汇总在提示词里让模型先引用回答中的具体证据再给分引入第二模型交叉验证。记住自评永远只是弱信号真正的质检底线是靠规则和人工抽检兜住的。4.3 过拟合与灾难性遗忘微调阶段最常见的问题是灾难性遗忘——模型在新语料上增强了但把原有的通用能力丢了。症状包括模型不再会说“我不知道”遇到不懂的问题硬编格式遵循能力反而变差对某些常识问题答非所问。我做过的有效缓解措施是LoRA 参数牢牢控制在低 rank不超过 64训练数据里保留 20% 的通用对话数据每轮迭代训练完都会跑一遍通用基准比如 C-Eval 的子集或 MMLU 子集如果通用能力明显下降就减少训练步数或降低学习率。还有一个容易被忽略的细节DPO 的 beta 参数不要调得太高beta 过大模型会太激进地往偏好方向挤遗忘会更严重。另外一个评估层面的坑别只盯着单一指标。我第一轮迭代的时候数学类评测分数涨了 12%当时很开心后来发现是因为评测集被污染了——评测题目本身可能出现在模型的预训练数据里。后来我换成动态抽题的方式每轮从题库里按不同 seed 抽题才让指标可信起来。5. 工具链与生态速览5.1 主流框架与组件自进化并不是某一家公司的专属技术现在开源生态里能拼出一整套工具链。我做了一个简单的分工梳理环节推荐工具说明推理与数据生成vLLM、SGLang支持高吞吐批量推理适合批量生成训练数据SGLang 在多轮生成上更灵活数据合成与筛选Distilabel、Argilla、Data-JuicerDistilabel 专门做 LLM 数据的生成-评分-过滤流程自带很多预置任务微调LLaMA-Factory、TRL、AxolotlLLaMA-Factory 上手快支持 SFT/DPO/PPOTRL 更贴近底层灵活度更高评估lm-evaluation-harness、AlpacaEval、MT-Bench标准评测集一把梭AlpacaEval 适合衡量指令跟随能力实验追踪WB、MLflow记录每次迭代的数据分布、训练参数和评测结果回溯排查时非常关键Distilabel 是我最近用得比较顺手的组件它把“生成→评分→过滤→打包”这些步骤声明式地串起来支持自定义评分器。如果你不想折腾 YAML直接用 Python 脚本也能实现同样的逻辑流程感反而更清晰。5.2 按场景选型建议不同场景下自进化的侧重点完全不一样我总结了几类常见情况第一类垂直领域问答助手。这是最容易见效的场景因为有领域知识做天然筛选器。建议用“教师模型评分 规则校验”双通道教师模型选闭源强模型或大参数开源模型学生模型用 7B~14B 级别。迭代两到三轮足够了。第二类代码生成助手。这个场景最大的优势是有编译器/测试用例做硬信号自进化可以非常激进。正确的回答会被测试用例验证天然形成高质量偏好对。我身边做代码助手的团队基本都在用类似 STaR 的路线让模型自己写代码、跑测试、保留通过的样本效果比人工标注好很多。第三类Agent 工具调用场景。这里的自进化更多是行为层面的让 Agent 自己尝试完成任务成功与失败的轨迹构成偏好数据。难点是轨迹评估很复杂成功不代表动作最优我建议结合过程奖励每个工具调用是否合理和结果奖励任务是否完成一起打分。第四类通用对话模型。坦白讲纯靠自进化做通用模型效果提升很有限因为通用领域的“好回答”标准太主观自评信号太弱。这一块更适合用 Self-Instruct 做数据扩张而不是做迭代式自进化。6. 一点实际操作体会最后说点不太好写进论文里的东西。自进化这个方向上最大的难点从来不是技术实现而是对“数据质量”的判断力。我刚跑通第一版流水线的时候觉得自己发现了新大陆——迭代了两轮模型在自测集上哗哗涨分。后来把同样的问题拿给几个朋友做盲测他们给出的评价却是“回答变官方了不好用了”。那一刻我才意识到评测集的分数和真实用户体验之间还隔着很长一段距离。所以如果你也想在这个方向尝试我建议从一个小切口开始选一个信号非常明确的任务类型比如代码题、数学题、有标准答案的知识问答先把流水线跑通再去碰主观评价类的任务。前期把精力花在评分器上它的质量直接决定自进化的上限。另外每一轮迭代的数据、模型权重、评测结果都要完整存档因为自进化的失误往往是累积性的没有记录出了问题你根本不知道是哪一轮引入的。这套方法还有很多可以继续探索的空间比如把外部工具引入反馈回路、让多模型互相评测、结合检索增强补充新鲜知识。技术路线会变但“用模型自己的输出去训练模型”这个基本思路未来几年应该会越来越普及。希望对正在尝试的朋友有帮助。