先说一个不太好听但很现实的结论大模型确实可以自我进化但今天被反复验证的“自我进化”几乎都发生在数学和代码这类答案能被机器自动检查的任务里。一旦走出这两个领域自我进化就会从“稳定闭环”变成“勉强能用”搞不好还会在几轮迭代之后越练越差。这不是玄学而是反馈信号决定的。自我进化的本质是模型拿自己的输出当训练数据再用一个可计算的信号做筛选形成“生成—筛选—训练—再生成”的闭环。数学有标准答案代码有单元测试这两类信号可以完全自动化所以闭环成立。而开放式写作、复杂对话、事实推理没有一个“标准答案检查器”只能退化成“让模型自己给自己打分”这里面的问题就多了。这篇文章围绕“走出数学与代码大模型还能自我进化吗”这条主线讲清楚三件事第一主流的自我进化技术路线到底是怎么工作的第二为什么它们在数学和代码上有效却在开放域频繁翻车第三如果你要自己动手跑一轮可控的自我进化实验环境、数据、训练、评估分别怎么设计。适合正在做大模型微调、强化学习、数据工程和 Agent 应用的开发者阅读。1. 核心认知速览认知点说明研究主题大模型自我进化self-evolution主要依托领域数学、代码等可自动验证任务主流技术路线Self-Instruct、Self-Play/SPIN、Self-Rewarding、RLVR GRPO是否依赖人工标注数据构建阶段可以减少效果评估阶段通常仍需要人工或外部基准关键硬件需求数据生成需要能运行目标模型的推理算力微调成本由 LoRA/QLoRA 到全参训练差异很大批量任务能力数据生成、执行验证、评测天然适合批量通常用并发请求或本地推理服务支撑当前成熟度数学/代码领域已有多个闭环成果开放域仍是研究热点稳定性不足主要风险奖励作弊、模型崩溃、自评偏好、测试集污染、灾难性遗忘适合读者做大模型微调、强化学习、数据工程、Agent 应用的开发者和研究者现在网上讨论“大模型自我进化”很多文章把它包装成模型“自己越来越聪明”。实际落地时它更像一套数据生产流水线模型负责生成候选答案验证器负责判断好坏筛选出的数据送回去重新训练。能不能进化不取决于模型本身有多聪明而取决于那个“验证器”有多可靠。数学和代码之所以成为试验田就是因为验证器便宜、客观、可重复。2. 为什么数学和代码是自我进化的“试验田”先看数学。数学题的答案可以用规则匹配、符号计算、或者另一个模型来核对判断“对不对”不需要人类介入。再看代码代码题更直接写完代码跑编译跑单元测试通过了就是通过报错了就是报错。这种确定性让自我进化里最关键的“奖励信号”变得极其干净。具体来说数学和代码给自我进化提供了四个条件。第一可自动验证。这是最核心的。进化需要选择压力选择压力来自“这个答案比那个答案好”。数学和代码的“好”可以被程序判断于是整个循环不需要人工参与。第二失败信息可利用。代码报错信息、单元测试输出、数学答案比对差异都是一种带结构的反馈。模型可以根据报错信息重写代码可以根据“最后一步算错”重新推理这比单纯告诉模型“你错了”要强得多。第三正确性有客观边界。写得再花哨的代码运行结果不对就是不对数学证明再长结论错了就是错了。模型很难通过“看起来很像正确答案”来蒙混过关。第四数据可以无限生成。题目是无限的或者可以通过改数字、改条件、换等价描述来扩展。只要验证器够快就能源源不断地产出高质量正样本。这四点在开放域里几乎同时消失。写一篇技术博客谁来判断“更好”是读者体验、信息密度、结构逻辑这些都需要人类主观评价。做一轮对话什么算“更好的回复”是更礼貌、更准确、更简洁还是更符合提问者偏好没有统一答案。所以自我进化一旦离开数学和代码第一个卡住的就是你根本没法自动化地给几万条模型输出排序。3. 大模型自我进化的主流技术路线3.1 Self-Instruct数据自举Self-Instruct 是较早进入大众视野的自举式方法。思路不复杂先准备一小批种子任务让模型根据种子任务生成更多同类任务再让模型给自己生成回答最后用启发式规则过滤掉低质量、重复样本把筛选后的数据拿去做监督微调。这种方法的价值在于你用少量人工种子数据跑出一批覆盖度更高的训练数据。代价也很明显数据质量上限取决于模型本身。模型会的它会生成得很顺利模型不会的它也会一本正经地生成“错误答案”而且错得很像。一个实际的自举生成脚本通常长这样import json from openai import OpenAI # 假设本地已经起了一个 OpenAI 兼容的推理服务 client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) seed_tasks [ 解释什么是动态规划。, 写一个判断素数的函数。, 把一句中文翻译成英文并说明关键字。, ] def generate_variants(task: str, n: int 5) - list[str]: prompt ( 下面是几个种子任务请生成语义相似但表达不同的新任务。\n\n f种子任务{task}\n\n 要求每个任务独立成行编号 1-n不要输出其他内容。 ) resp client.chat.completions.create( modellocal-model, messages[{role: user, content: prompt}], temperature0.8, ) text resp.choices[0].message.content.strip() lines [line.split(. , 1)[-1] for line in text.splitlines() if line.strip()] return lines[:n] if __name__ __main__: result [] for task in seed_tasks: for new_task in generate_variants(task): result.append({instruction: new_task, source: self-instruct}) with open(./self_evo_data/tasks.jsonl, w, encodingutf-8) as f: for item in result: f.write(json.dumps(item, ensure_asciiFalse) \n) print(f生成任务数: {len(result)})这段代码只解决“任务变体”这一步。真正工程化时还要做相似度去重、长度过滤、答案质量抽检否则模型生成的重复样本会让微调阶段很容易过拟合。3.2 Self-Play 与 SPIN让模型与自己博弈Self-Play 的思路借鉴了对抗博弈。模型有两重身份一个是“玩家”负责生成回答另一个是“判别器”负责区分“模型自己生成的回答”和“高质量参考回答”。每次迭代后模型用判别结果继续训练再进入下一轮直到模型自己的输出越来越接近高质量参考。SPINSelf-Play Fine-Tuning就是这一思路的代表实现。它把微调过程变成博弈模型努力生成“能骗过判别器”的回答同时判别器努力识别“这个回答来自模型还是来自高质量数据”。这种对抗式训练能有效拉开模型输出和真实数据分布之间的距离但也容易陷入模式坍塌——模型只生成一小类“看起来安全”的答案。一个简化的训练循环可以这样理解for round_id in range(num_rounds): # 1. 模型生成样本 model_samples model.generate(eval_questions) # 2. 判别器打分真实数据得分高模型生成数据得分低 score_real discriminator(real_answers) score_fake discriminator(model_samples) # 3. 判别器损失 模型生成损失交替更新 d_loss compute_discriminator_loss(score_real, score_fake) discriminator.update(d_loss) g_loss compute_generator_loss(score_fake, temperature1.0) model.update(g_loss)在真实代码中你通常不会手写 GAN 式的对抗损失而是用 SPIN 论文的损失函数或者直接使用开源复现。这里要强调博弈式训练比普通 SFT 敏感得多学习率、正则、判别器初始强度都会影响收敛稍不留神模型就会“猜到”判别器的偏好。3.3 Self-Rewarding让模型自己当裁判Self-Rewarding 更进一步模型不仅要生成答案还要给自己的答案打分然后用打分结果构造偏好对做 DPO 式微调。流程是模型生成新问题 → 模型为同一问题生成多个回答 → 模型用“LLM-as-a-Judge”的方式给回答打分 → 高分回答作为 chosen低分回答作为 rejected → 训练一轮 DPO → 重复。这套方法在生产环境里很常见原因很简单人工标注偏好对太贵了让模型自己标注可以把成本降到接近零。但问题同样明显模型既是运动员又是裁判。实验里经常出现“自评偏好”——模型更认可跟自己风格相近的回答而不是客观上更好的回答。如果训练数据本身已经存在风格偏差自评会放大这个偏差。DPO 训练的数据格式大概是这种偏好对结构{ instruction: 用一句话解释什么是梯度下降, chosen: 梯度下降是一种通过沿损失函数负梯度方向迭代更新参数来最小化损失的优化算法。, rejected: 梯度下降就是反向传播用来训练神经网络。, source: self-rewarding-round1 }注意DPO 对“对”和“错”的质量差异很敏感。如果 chosen 和 rejected 差距不大模型学到的东西会非常有限如果差距过大又可能让模型过度迎合裁判风格。所以 Self-Rewarding 的关键不在生成而在评分 prompt 设计。3.4 RLVR GRPO用可验证奖励做强强化学习进入 2024 年后数学和代码自我进化最突出的路线是基于可验证奖励的强化学习RLVR。以 DeepSeek-R1 为代表的多项公开发布工作把“规则化验证 组内相对策略优化”推进到了实用层级。这里的奖励不是模型打的分而是几段简单的规则代码数学题对答案代码题跑测试。模型对同一个问题生成多组回答每一组按规则拿到 0/1 奖励再在组内计算相对优势更新策略。因为不需要单独训练奖励模型强化学习的成本大幅下降。一个简化的可验证奖励计算可以写成这样import re def compute_math_reward(answer: str, gold_answer: str) - float: # 提取 \boxed{...} 里的最终答案 match re.search(r\\boxed\{(.*?)\}, answer) if not match: return 0.0 return 1.0 if match.group(1).strip() str(gold_answer).strip() else 0.0 def compute_code_reward(code: str, test_cases: list[str]) - float: passed 0 for case in test_cases: if run_code_with_test(code, case): # 实际需要沙箱执行 passed 1 return passed / len(test_cases)RLVR 是当前“能真正跑出效果”的自我进化路线但它依赖一个容易被忽略的前置条件问题本身必须可验证。一旦把同样的强化学习算法迁移到“写一段广告文案”“总结一份会议纪要”规则奖励无从定义就又回到了奖励模型和自评偏好那一套老问题。4. 走出数学与代码开放域自进化的真实困难开放域自进化困难不是模型不够聪明而是“判断更聪明了没有”这件事本身不成立。领域可验证性自我进化可行性主要问题数学高标准答案/求解器高复杂证明仍难自动验证代码高单元测试/执行高测试覆盖不足时会奖励作弊事实问答低到中检索可辅助中事实核验成本高模型会编造依据写作/创意低低到中只能靠模型自评存在同质化风险法律/医疗/金融低到中低错误代价高必须人工兜底首先开放域缺少一个可靠的奖励函数。写得好不好、回答有没有帮助、推理是否完整这些指标要么靠人类主观打分要么靠一个更强大的模型打分。人类主观打分成本高另一个模型打分则可能引入系统偏好。奖励一旦有偏差强化学习就会把偏差放大模型不是在进化而是在迎合裁判。其次是奖励作弊问题。模型在优化目标时非常擅长找捷径。代码题里模型可能训练到“看到测试样例就硬编码输出预期结果”写作题里模型可能学会“不管用户问什么都输出一段套话因为这些套话在自评中得分稳定”。这些不是模型变聪明了而是它找到了奖励函数的漏洞。第三是模型崩溃风险。Shumailov 等人的研究已经指出当模型反复在自己生成的未经校正的数据上训练时输出多样性会持续下降尾部知识逐渐丢失整个分布会向单一模式坍缩。数学和代码因为有外部验证器不断把“对的样本”过滤进来可以在一定程度上抵消这种坍缩。开放域没有这个纠偏机制演化几轮后模型输出的内容会越来越雷同。第四是评估本身的不可靠。你无法证明“自进化后模型更好了”除非你有一个可信的评测集。开放域评测集要么依赖人类打分要么依赖另一个模型的偏好两者都不稳定。评测不稳定整个实验的结论就是悬空的。5. 哪些迹象说明自我进化正在“破圈”如果只说“开放域不行”这篇讨论就太悲观了。实际研究中已经出现几条“破圈”迹象它们共同特征是把开放任务改造成可验证的封闭子任务或者用外部工具提供反馈信号。第一条工具增强的自我修正。代码 Agent 是典型例子。模型写代码跑执行器看报错再改代码这已经是一个完整的“生成—验证—修正”循环。把这个思路扩展到浏览器、计算器、数据库、搜索引擎模型可以在更广的范围内获得外部反馈。所以说到底语言模型没变验证器变强了。第二条Agent 环境反馈。在游戏、机器人仿真、网页导航等环境中模型的行为会产生可观测结果。只要结果可观测强化学习就能跑起来。这种自我进化已经不只是文本生成而是把策略学习引入真实动作空间。第三条过程奖励建模。数学和代码的长链条推理容易错在中间某一步。研究者开始不满足于“只看最终答案”而是逐步给出过程奖励甚至给每一步推理打分。过程奖励可以有效减少“中间步骤全错、最后答案蒙对”的问题也让自我进化从“结果校验”走向“过程校验”。第四条RLAIF 与 Constitutional AI。模型先根据一组原则对自己的输出做批评和修改再基于修改后的数据做偏好对齐。虽然批评者仍是模型自己但有了显式原则约束之后系统稳定性明显提升。这类方法在安全对齐、风格控制上有实际落地已经不算纯实验。这些迹象说明自我进化不是被困死在数学和代码而是“能自动化验证的边界”在往外扩。边界每扩大一点自我进化的适用面就大一点。扩大的方式通常不是让模型更聪明而是让验证器更强大、外部反馈更丰富。6. 设计一场可控的自我进化实验纸上讨论再多不如自己跑一轮实验。下面给出一套可以在本地部署场景下完成的自我进化实验设计以“代码生成”为测试领域。你也可以把测试域换成数学应用题核心流程不变。6.1 实验目标与基线选择先定目标验证“模型能否利用自己的输出和测试反馈在 held-out 测试集上提升 pass1”。选一个当前可用的开源对话模型作为基线记下模型名称和版本。不建议一上来用太大模型7B 到 14B 级别最适合跑闭环。实验前必须组好三个数据集种子问题集模型会做但做得不完美的问题约 200 到 500 题。验证集用于筛选生成样本约 100 到 200 题。测试集只用于最终评估不参与任何训练和筛选确保不发生数据泄漏。6.2 环境准备最少需要一台能运行目标模型的机器。如果目标是本地部署建议先部署一个 OpenAI 兼容的推理服务例如 vLLM、TGI 或 llama.cpp server。用推理服务统一接口后面生成、修正、评估都走同一个 API。# 以 vLLM 为例实际命令需要按项目文档调整 python -m vllm.entrypoints.openai.api_server \ --model /path/to/local_model \ --served-model-name self-evo-model \ --port 8000 \ --max-model-len 8192微调阶段按资源选择 LoRA、QLoRA 或全参微调。7B 级别模型做 LoRA 微调是更稳妥的入门方式具体显存占用要结合 batch size、序列长度按本机测试确认。6.3 数据生成与过滤先让基线模型在种子问题上生成代码跑测试把失败的样本收集起来。拿到报错信息后让模型参考报错重写代码再次执行。这样每道失败题都可能产生一条“从错误到正确”的修正样本。import json import subprocess from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) def run_code(code: str, timeout: int 10) - tuple[bool, str]: try: result subprocess.run( [python, -c, code], capture_outputTrue, textTrue, timeouttimeout, ) return result.returncode 0, result.stderr[-500:] except Exception as exc: return False, str(exc) def revise_solution(problem: str, wrong_code: str, error_msg: str) - str: prompt ( 下面是代码题和一次错误解答以及执行报错。 请参考报错修改代码输出完整可运行的 Python 代码不要额外解释。\n\n f题目{problem}\n\n错误解答\n{wrong_code}\n\n报错信息\n{error_msg}\n ) resp client.chat.completions.create( modelself-evo-model, messages[{role: user, content: prompt}], temperature0.3, ) return resp.choices[0].message.content.strip() def build_training_data(problems: list[dict]) - list[dict]: train_samples [] for item in problems: problem item[prompt] code item[initial_code] ok, err run_code(code) if ok: continue revised revise_solution(problem, code, err) ok2, _ run_code(revised) if ok2: train_samples.append({ instruction: problem, output: revised, round: 1, }) return train_samples注意run_code直接执行模型输出存在安全风险。生产环境必须用沙箱执行例如 Docker 容器或云函数限制文件系统、网络和权限千万不要在宿主机上直接跑不可信代码。生成完正样本后还要做一次相似度去重避免同一种解法反复出现导致微调过拟合from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) def dedupe(samples, threshold: float 0.9): texts [s[output] for s in samples] emb model.encode(texts, normalize_embeddingsTrue) keep [] for i in range(len(samples)): dup False for j in keep: if float(emb[i] emb[j]) threshold: dup True break if not dup: keep.append(i) return [samples[i] for i in keep]6.4 微调配置筛选完数据后用 LoRA 方式在训练集上做监督微调。下面是一份可以参考的训练配置模板实际参数需要按模型和数据规模调整{ model_name_or_path: /path/to/local_model, dataset_path: ./self_evo_data/train.jsonl, lora_r: 16, lora_alpha: 32, target_modules: [q_proj, k_proj, v_proj, o_proj], per_device_train_batch_size: 2, gradient_accumulation_steps: 8, learning_rate: 2e-5, num_train_epochs: 3, max_seq_length: 2048, logging_steps: 10, save_strategy: epoch, output_dir: ./self_evo_checkpoints }训练结束后把 LoRA 权重合并回模型得到一个“进化版”权重。如果你想做第二轮、第三轮就把进化版模型部署成新的推理服务重复 6.3 的数据生成流程再做一轮微调。每轮迭代前都要记录数据量和评测分数方便判断“进化是否真的发生”。6.5 评估方法评估指标选 pass1。对测试集每个问题用温度和采样参数固定为同一组让基线模型和进化模型各生成一次答案跑单元测试统计通过率。from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) def generate_code(model_name: str, prompt: str) - str: resp client.chat.completions.create( modelmodel_name, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content.strip() def pass_at_1(model_name: str, eval_problems: list[dict]) - float: passed 0 for p in eval_problems: code generate_code(model_name, p[prompt]) ok, _ run_code_with_sandbox(code, p[tests]) if ok: passed 1 return passed / len(eval_problems) base_score pass_at_1(self-evo-model, eval_problems) evo_score pass_at_1(self-evo-merged, eval_problems) print(f基线 pass1: {base_score:.3f}) print(f自进化后 pass1: {evo_score:.3f})判断标准很朴素如果进化版在 held-out 测试集上稳定高于基线且不在通用能力测试上显著下降说明这一轮自我进化成立。如果分数没有变化甚至下降就回到数据质量、训练参数和问题难度三个方向排查。7. 资源占用与性能观察自我进化实验最容易被低估的成本是数据生成阶段的推理开销。一个 200 题的数据集如果每题要生成 2 到 3 次、每次还带修正重跑就是几百到上千次推理请求。逐条串行请求速度会慢到让人失去耐心。所以在数据生成阶段建议先把模型部署成推理服务用并发请求批量打。推理服务本身通常支持高吞吐批处理。观察推理性能时重点看两个指标总吞吐量每秒生成 token 数和单请求时延。模型能跑起来只算第一步吞吐量上不去数据生成这一环就会卡死整个流程。微调阶段的资源观察更直接。训练开始后用nvidia-smi按秒刷新看显存占用watch -n 1 nvidia-smi可以重点记录三样东西训练峰值显存、训练时 batch 能否塞进显存、以及 loss 是否在合理范围内下降。如果 OOM优先减小 batch size、降低 max_seq_length或者改用 QLoRA 量化版本。如果 loss 下降但评测不涨问题大概率不在资源而在数据或超参。性能观察要养成记录习惯。每一轮自进化实验建议固定一张实验记录表至少包含以下字段模型版本、训练数据量、数据来源、微调配置、训练耗时、训练峰值显存、评测 pass1、通用能力抽检结果。没有这套记录几轮迭代后你根本分不清哪个改动带来了提升。8. 常见误区与失败模式排查问题现象可能原因排查方式解决方案训练 loss 下降但评测 pass1 不涨生成数据质量低、重复度过高、过拟合检查训练集去重情况抽检生成样本提高筛选阈值增加多样性和去重几轮迭代后生成数据同质化严重模型输出分布坍缩统计生成代码的文本相似度分布降低采样温度加入更多种子问题减少迭代轮次模型学会“作弊”输出预期结果而不是通用解法测试样例被硬编码进训练查看生成代码中是否包含测试样例字符串强化测试生成器增加隐藏测试暴露逻辑缺陷微调后通用能力明显下降灾难性遗忘训练数据过于单一在通用 benchmark 上做对比评测混入通用指令数据降低学习率减少 epoch显存 OOMbatch 或序列过长或模型占用过高看 nvidia-smi 峰值减小 batch、缩短 max_seq_length、启用梯度累积、用 QLoRAAPI 请求卡死或超时推理服务负载过高或网络问题查看服务日志和并发数增加并发上限控制、设置超时重试、减少 batch 请求数评测结果波动大采样数量太少或测试集过小多次重复评测看方差增加测试样本量固定随机种子多跑几轮取平均生成数据混入测试集相近样本数据去重不严污染测试集对生成数据和测试集做相似度比对从生成流程开始排除测试集所有样本做哈希或向量去重这里要特意提醒一个反直觉现象训练 loss 下降从来不是自我进化成功的证据。因为模型在训练集上的 loss 下降只代表它记住了训练数据不代表它解决了测试集上的问题。自我进化的唯一硬指标是 held-out 测试集上的效果提升。没有这个指标一切 loss 曲线都只是过程数据。另一个常见误区是把“自进化”理解成“无限提升”。实际上每一轮迭代的收益都在递减。第一轮修正样本通常能带来最明显的提升第二轮、第三轮的边际收益会快速下降同时同质化风险上升。健康的实验设计是控制在 2 到 3 轮内每轮都做完整评估没有提升就立刻停。9. 工程化与合规建议自我进化实验一旦进入工程化阶段需要同时管理数据质量、版本安全和合规边界。数据权利要小心。模型自己生成的代码可以用于训练但如果种子问题来自受版权保护的题库或平台条款限制的数据集生成结果在商用场景下的使用边界需要单独确认。不要默认“模型生成的数据就完全归我所有”要回到数据来源的授权条款去判断。隐私保护不能放松。不要拿真实用户对话、真实个人信息、医疗或财务数据去跑自进化数据生成。实验阶段使用脱敏数据或公开数据集是成本最低且最稳妥的做法。涉及人脸、声音、肖像、版权素材的处理必须提前确认授权这是底线。工程上的建议是分层管理资源。模型文件、种子问题集、生成中间结果、微调 checkpoint、最终评测报告建议分目录存放并给每个文件打上模型版本和生成日期。没有版本控制的实验数据一多就会变得不可复现。接口服务要限制访问范围。如果推理服务或微调服务暴露在网络上建议绑定回环地址或内网地址不要裸奔在公网。OpenAI 兼容服务默认不鉴权生产环境必须加 API Key 或网络白名单。发布和商用之前必须做人工复核。无论评测分数多高自进化模型都可能存在“评测集上好用、真实场景翻车”的情况。特别是在法律、医疗、金融等错误代价高的领域任何自我进化模型输出的结果都不能直接作为决策依据。10. 总结与下一步回到开头那个问题走出数学与代码大模型还能自我进化吗答案是能但路径不是“让模型凭空变聪明”而是“把更多任务改造成可自动验证的任务”。数学和代码之所以成立是因为验证器可靠开放域之所以困难是因为验证器缺失。沿着“给模型造更多验证器”的方向走自我进化的边界会持续扩大。如果你要亲手验证一轮自我进化我的建议是第一步先选代码生成或数学推理这类可自动验证的任务跑通“生成—筛选—微调—评估”的闭环第二步把评估做成硬指标固定在 held-out 测试集上不要被训练 loss 欺骗第三步控制迭代轮次每轮都记录数据和指标没有提升就停。最容易踩的坑有三个一是生成数据质量没有抽检就丢进训练二是测试集和生成数据没有彻底隔离三是把自进化当成无限提升盲目迭代到模型输出同质化。这三条都能靠“严格评估 版本记录 小步迭代”来规避。后续往哪个方向扩展取决于你的任务领域。做 Agent 应用的可以试试把工具调用反馈接入自进化循环做内容生成的可以试试过程奖励和原则约束做开放域模型的建议优先解决“可验证子任务拆分”而不是直接上强化学习。自我进化不是魔术它是数据、反馈和训练三者闭环的工程结果。