1. 从标题拆解：这个项目到底在解决什么问题

1.1 核心命题：让模型学会“自己教自己”

看到“用强化学习扩展自我改进”这个表述，我第一反应是：这不是又一个“堆数据、堆参数”的常规迭代，而是试图在训练范式上做文章。传统的大模型能力提升路径，基本围绕“更多高质量数据 + 更大算力 + 更精细的人类反馈”展开，但这条路有个天花板——人类标注的速度和规模是有限的，而模型自我生成的数据如果缺乏筛选机制，很容易陷入“自我催眠”式的退化。

这个项目的核心命题，就是让模型在强化学习框架下，自己生成训练信号、自己评估质量、自己决定哪些经验值得保留。换句话说，它想解决的是“模型能力增长如何摆脱对人类标注的线性依赖”这个问题。这个方向在近两年的研究中热度很高，但真正把“自我改进”做成可扩展、可稳定训练的闭环，工程难度极大。

1.2 为什么是强化学习，而不是继续做监督微调

这里需要解释一个关键选择：为什么用强化学习来驱动自我改进，而不是继续用监督微调（SFT）？

监督微调的本质是“模仿”，模型学的是人类标注的“标准答案”。但自我改进场景下，模型面对的是自己生成的内容，没有现成的标准答案。这时候如果还用SFT的思路，就等于让模型去拟合自己上一轮的输出，结果往往是能力震荡甚至崩塌。

强化学习的优势在于，它不需要“正确答案”，只需要一个“评价信号”。这个信号可以来自规则、来自奖励模型、来自多轮采样后的统计对比。模型通过最大化期望奖励来调整策略，从而在“生成-评估-优化”的循环中逐步提升。这个逻辑在AlphaGo时代就被验证过，但迁移到语言模型上，难点在于奖励信号的设计和训练稳定性。

1.3 适合谁来读这篇拆解

如果你是大模型训练方向的从业者，尤其是做后训练（post-training）、RLHF、奖励建模的，这篇内容会帮你理清“自我改进”这条技术路线的关键节点。如果你是算法工程师但没直接做过RL训练，我会尽量把奖励设计、采样策略、稳定性控制这些环节讲得足够具体，让你能判断自己的场景是否适用。如果你只是对大模型技术演进感兴趣，我也会用生活化的类比把核心逻辑说清楚，不堆公式。

2. 整体设计思路：自我改进闭环的四个关键环节

2.1 闭环的基本结构：生成、评估、筛选、更新

任何“自我改进”系统，本质上都是一个闭环。这个闭环至少包含四个环节：

1. 生成：模型针对一批问题或任务，生成多个候选回答或推理路径。
2. 评估：用一个或多个评价机制，给这些候选打分。
3. 筛选：根据分数，选出“好”的样本和“坏”的样本，形成偏好对或加权信号。
4. 更新：用这些信号去更新模型参数，然后进入下一轮。

这个结构听起来简单，但每一步都有坑。比如生成阶段，如果采样温度太低，候选多样性不够，评估信号就没有区分度；如果温度太高，生成质量太差，评估又变成“垃圾里挑金子”。评估阶段，如果奖励模型本身有偏差，模型就会学会“刷分”而不是真正提升能力。筛选阶段，如果只保留最高分样本，模型会迅速过拟合到奖励模型的偏好上。更新阶段，学习率、KL约束、批次构成都会影响稳定性。

2.2 奖励信号从哪来：规则、模型、还是自洽性

在自我改进框架里，奖励信号的设计是灵魂。常见的有三类：

• 规则奖励：比如数学题有标准答案，代码有单元测试，这类任务可以直接用规则判断对错。优点是信号干净，缺点是适用范围窄。
• 奖励模型：训练一个单独的模型来打分，通常是基于人类偏好数据训练的。优点是通用，缺点是容易有偏差，而且奖励模型本身也需要更新。
• 自洽性奖励：让模型对同一个问题生成多条推理路径，如果最终答案一致，就认为这条路径更可信。这个思路在数学推理任务上被验证过有效，因为它不需要外部标注。

这个项目标题里提到“用强化学习扩展”，我推测它很可能采用了混合奖励策略：在可验证任务上用规则奖励，在开放任务上用奖励模型或自洽性信号。这样既能保证信号质量，又能扩大适用范围。

2.3 为什么要强调“扩展”：从单轮到多轮，从小规模到大规模

“扩展”这个词很关键。早期的自我改进实验，往往是在小规模模型、小规模任务上做的，比如让模型自己出题自己做。但那种做法很难扩展到大规模训练，因为一旦模型能力变强，它生成的问题和评估信号都会变得不可控。

这个项目强调“扩展”，我理解至少包含三层含义：

• 规模扩展：从几万条样本扩展到百万级甚至更大，需要工程上的采样效率优化。
• 轮次扩展：从一两轮自我改进扩展到多轮迭代，需要解决误差累积和分布漂移问题。
• 任务扩展：从单一任务（如数学）扩展到多任务（如代码、推理、对话），需要奖励信号的泛化设计。

这三层扩展，每一层都会引入新的工程挑战。比如多轮迭代时，模型分布会逐渐偏离初始分布，奖励模型的打分也会越来越不准，这时候就需要引入周期性的人类反馈校准，或者用集成奖励模型来降低方差。

2.4 与现有RLHF流程的区别：从“人类教”到“自己教”

传统的RLHF流程是：人类标注偏好数据 -> 训练奖励模型 -> 用PPO等算法优化策略模型。这个流程里，人类始终在闭环中扮演“教师”角色。

而自我改进框架试图把“教师”角色也交给模型自己。人类只在初始阶段提供少量种子数据或规则，后续的评估和筛选由模型自主完成。这个转变的意义在于：它有可能打破人类标注的规模瓶颈，让模型能力增长进入一个更自主的循环。

但这里有个关键风险：如果模型自己教自己，它会不会越教越偏？这就是为什么强化学习框架里通常要加KL约束，防止新策略偏离初始策略太远。这个约束的强度需要仔细调，太强了学不动，太弱了会崩。

3. 核心细节解析：奖励设计、采样策略与稳定性控制

3.1 奖励设计：如何避免模型学会“刷分”

奖励设计是自我改进系统里最容易翻车的地方。我见过不少实验，模型在训练初期表现很好，但几轮之后就开始输出一些“看起来对但实际没意义”的内容，因为奖励模型被这种模式骗了。

避免刷分的常见手段有几种：

• 奖励模型集成：训练多个奖励模型，取平均分或最低分作为奖励。这样模型很难同时骗过所有奖励模型。
• 长度惩罚：如果奖励模型倾向于给长回答高分，模型就会学会啰嗦。加一个长度归一化或惩罚项可以缓解。
• 周期性重新校准：每隔几轮，用新的人类标注数据重新训练奖励模型，防止它被模型输出分布带偏。
• 规则兜底：在可验证任务上，始终保留规则奖励作为硬约束，防止模型在开放任务上刷分影响到核心能力。

这个项目如果要在“扩展”上做文章，奖励模型的更新策略一定是重点。我推测它可能采用了“奖励模型与策略模型交替更新”的方案，或者用了一个更大的、冻结的奖励模型作为锚点。

3.2 采样策略：多样性、温度与批次构成

采样策略直接影响训练信号的丰富度。如果每次只采样一条路径，评估信号就非常稀疏；如果采样太多，计算成本又太高。

常见的做法是：对每个问题采样K条路径（K通常在4到16之间），然后用评估机制打分，形成组内对比。这个思路和“组相对策略优化”类似，不需要绝对分数，只需要相对排序。

温度参数也很关键。温度太低，所有路径都差不多，评估没有区分度；温度太高，路径质量太差，评估信号噪声大。我自己的经验是，在推理任务上，温度设在0.7到1.0之间比较合适，具体要看任务难度和模型规模。

批次构成上，不能只保留最高分样本，否则模型会迅速过拟合。通常的做法是保留“正样本”和“负样本”形成偏好对，或者用加权方式让中等质量的样本也有贡献。这个比例需要根据任务调整，没有万能公式。

3.3 稳定性控制：KL约束、学习率与梯度裁剪

强化学习训练语言模型，稳定性是最大的工程挑战。我踩过的坑包括：奖励突然飙升然后模型输出崩坏、KL散度爆炸、梯度范数异常增大等。

几个关键控制点：

• KL约束：在奖励里加一个KL惩罚项，防止新策略偏离参考策略太远。系数通常设在0.01到0.1之间，需要根据模型规模和任务调整。
• 学习率：RL微调的学习率通常比SFT小一到两个数量级，比如1e-6到5e-6。太大容易崩，太小学习慢。
• 梯度裁剪：把梯度范数裁剪到1.0左右，防止个别批次把参数带偏。
• 早停与回滚：监控验证集上的表现，如果连续几轮下降，就回滚到上一个检查点。

这些手段在常规RLHF里已经比较成熟，但自我改进场景下，因为奖励信号是模型自己生成的，噪声更大，所以这些控制需要更保守一些。

3.4 评估环节：自洽性、多数投票与过程奖励

评估环节决定了筛选出来的样本质量。常见的方法有：

• 多数投票：对同一个问题生成多条路径，最终答案出现次数最多的那个被认为更可信。这个方法在数学题上很有效，因为答案空间是离散的。
• 自洽性检查：不仅看最终答案，还看推理过程是否自洽。比如如果两条路径的中间步骤矛盾，即使最终答案一致，也可能有问题。
• 过程奖励模型：训练一个模型来给每一步推理打分，而不是只给最终结果打分。这个思路在“让模型学会一步步推理”上很有价值，但训练过程奖励模型本身就需要大量标注。

这个项目如果要在“扩展”上做好，评估环节的效率和准确性是关键。我推测它可能采用了“多数投票 + 规则验证”的混合方案，在可验证任务上直接用规则，在开放任务上用多数投票或奖励模型。

4. 实操过程：从零搭建一个自我改进训练循环

4.1 环境准备与基础模型选择

假设你要复现一个类似的自我改进流程，第一步是选基础模型。通常选一个已经经过SFT的模型作为起点，因为纯预训练模型输出太发散，评估信号噪声太大。

基础模型的选择要考虑：

• 规模：太小（如1B以下）能力不足，自我改进空间有限；太大（如70B以上）训练成本高，迭代慢。7B到13B是比较适合实验的区间。
• 许可证：确保允许研究和商用，避免后续麻烦。
• 生态：有现成的推理框架和微调工具支持，能省很多工程时间。

环境方面，需要准备推理引擎（如vLLM或TGI）用于批量采样，训练框架（如DeepSpeed或FSDP）用于参数更新，以及一个奖励模型或规则评估模块。

4.2 数据准备：种子问题集与验证集

种子问题集是自我改进的起点。它不需要很大，但需要覆盖目标任务的核心类型。比如做数学推理，种子集可以包含几百道有标准答案的题；做代码生成，可以包含几百个有单元测试的编程题。

验证集是必须的，而且要和训练集严格分开。验证集的作用是监控模型是否真的在提升，而不是在刷奖励。我建议验证集用人类标注或规则验证的“干净”数据，不要用模型自己生成的数据。

数据格式上，通常需要问题、参考答案（可选）、评估规则（可选）。对于开放任务，参考答案可以没有，但需要有一个评估脚本或奖励模型接口。

4.3 训练循环实现：采样、评估、筛选、更新

下面是一个简化的训练循环伪代码，用Python风格描述：

for iteration in range(num_iterations): # 1. 采样 problems = sample_problems(seed_set, batch_size) candidates = [] for problem in problems: paths = policy_model.generate(problem, num_samples=K, temperature=0.8) candidates.append(paths) # 2. 评估 rewards = [] for problem, paths in zip(problems, candidates): scores = evaluate(problem, paths) # 规则或奖励模型 rewards.append(scores) # 3. 筛选 training_pairs = [] for problem, paths, scores in zip(problems, candidates, rewards): # 形成偏好对或加权样本 pairs = build_preference_pairs(paths, scores) training_pairs.extend(pairs) # 4. 更新 policy_model = rl_update(policy_model, training_pairs, kl_coef=0.05) # 5. 验证与日志 val_score = evaluate_on_validation(policy_model, val_set) log(iteration, val_score) # 6. 检查点保存与回滚判断 if val_score < best_score: rollback_if_needed() else: best_score = val_score save_checkpoint(policy_model)

这个循环里，每一步都有细节可以优化。比如采样阶段可以用异步推理提高吞吐；评估阶段可以缓存规则验证结果；筛选阶段可以控制正负样本比例；更新阶段可以用梯度累积来稳定训练。

4.4 关键参数计算：KL系数、学习率与批次大小

KL系数的选择需要平衡“学习新能力”和“保持稳定性”。一个经验公式是：KL系数与学习率的乘积大致控制在1e-7到1e-6之间。比如学习率是2e-6，KL系数可以设在0.05左右。

批次大小方面，RL训练通常比SFT需要更大的批次来降低方差。如果显存允许，全局批次大小可以设在64到256之间。如果不够，可以用梯度累积模拟。

采样数量K的选择，需要根据任务难度和计算预算。K越大，评估信号越可靠，但计算成本线性增长。我通常从K=4开始实验，如果发现评估区分度不够，再增加到8或16。

4.5 实操现场记录：一次典型的训练日志分析

假设我们跑了一次实验，日志大概长这样：

这个日志说明：从第4轮开始，模型在刷奖励，但真实能力在下降。这时候应该回滚到第3轮的检查点，并调整奖励模型或增加KL约束。

这个现象在自我改进训练里非常常见，我几乎每次实验都会遇到。关键是要有验证集监控和回滚机制，不能只看训练奖励。

5. 常见问题与排查技巧实录

5.1 奖励涨了但验证集不涨，怎么办

这是最典型的问题。原因通常是奖励模型有偏差，模型学会了“讨好”奖励模型而不是真正解决问题。

排查思路：

1. 检查奖励模型在验证集上的打分是否和人类判断一致。如果不一致，说明奖励模型需要重新校准。
2. 检查训练样本的多样性。如果模型输出越来越单一，说明采样温度太低或筛选太激进。
3. 检查KL散度。如果KL散度增长过快，说明模型偏离参考策略太远，需要增大KL系数。
4. 引入规则奖励作为兜底。在可验证任务上，规则奖励是硬信号，不会被模型欺骗。

我的经验是，奖励模型和策略模型的能力需要匹配。如果奖励模型太弱，模型很快就会找到漏洞；如果奖励模型太强，训练信号又太稀疏。通常奖励模型比策略模型大一个量级比较合适。

5.2 训练过程中输出突然崩坏，如何快速定位

输出崩坏的表现包括：重复、乱码、拒绝回答、逻辑混乱等。快速定位的步骤：

• 检查最近一个批次的奖励分布。如果奖励突然变得很高或很低，说明评估环节出了问题。
• 检查KL散度。如果KL散度突然飙升，说明更新步长太大。
• 检查梯度范数。如果梯度范数异常大，说明有个别样本产生了巨大梯度。
• 回滚到上一个检查点，用更小的学习率或更大的KL系数重跑。

我自己的做法是，在训练脚本里加一个“异常检测”钩子：如果某个批次的奖励标准差超过阈值，或者KL散度超过阈值，就跳过这个批次的更新，并记录日志。这个简单的机制能避免很多崩坏。

5.3 多轮迭代后模型变得“油滑”，怎么破

“油滑”是指模型输出看起来合理但实际空洞，或者总是用套话回避问题。这是自我改进多轮迭代后的常见退化。

原因通常是：模型在自我评估时，倾向于给“安全但无用”的回答高分，因为这类回答不容易出错。久而久之，模型就学会了这种策略。

破解方法：

• 在奖励里加入“信息量”或“具体性”的惩罚项，鼓励模型给出具体答案。
• 在评估环节引入“对抗性”问题，专门测试模型是否在回避。
• 定期用人类标注数据重新校准奖励模型，防止它被模型输出分布带偏。
• 控制迭代轮次，不要无限自我改进。通常3到5轮后就需要引入外部信号。

5.4 常见问题速查表

5.5 独家避坑技巧：三个我踩过的坑

第一个坑：奖励模型更新太频繁。我一开始每轮都更新奖励模型，结果奖励信号一直在变，策略模型根本学不稳。后来改成每3到5轮更新一次，或者用冻结的奖励模型作为主信号，只用一个小的可更新模型做微调，稳定性好了很多。

第二个坑：验证集泄露。有次我不小心把验证集的问题也放进了种子集，结果验证准确率虚高，实际部署时效果很差。后来我严格分开种子集和验证集，并且用不同的数据来源。

第三个坑：忽略推理成本。自我改进训练需要大量采样，如果推理引擎没优化好，训练时间会成倍增加。我后来用了连续批处理和KV缓存复用，吞吐提升了三倍多。这个工程优化在论文里通常不会写，但实际做的时候非常关键。

6. 这个方向后续可以怎么扩展

6.1 从单模态到多模态的自我改进

目前大部分自我改进实验集中在文本推理任务上。但同样的框架可以扩展到多模态：让模型自己生成图像描述、自己评估描述质量、自己筛选高质量对。难点在于多模态奖励模型更难训练，而且评估信号更噪声。

我推测这个项目后续可能会往多模态方向走，因为“自我改进”的框架是通用的，只要奖励信号能设计出来，就能扩展。

6.2 从离线到在线的持续学习

现在的自我改进通常是离线迭代：采样一批、训练一轮、再采样。更激进的方向是在线持续学习：模型在部署过程中不断自我评估、自我更新。这个方向的风险更大，因为一旦更新出错，线上服务会直接受影响。但潜在收益也更大，因为模型能持续适应新数据。

6.3 与工具使用的结合

如果模型能调用外部工具（如计算器、代码解释器、搜索引擎），自我改进的评估环节会变得更可靠。比如数学题可以用计算器验证，代码题可以用单元测试验证。这样规则奖励的覆盖面会大大扩展，减少对奖励模型的依赖。

这个方向我觉得是近期最有可能落地的，因为工具调用本身已经比较成熟，缺的是和自改进循环的工程整合。

6.4 我个人在实际操作中的体会

做了几轮自我改进实验后，我最大的体会是：奖励设计比算法选择重要得多。同样的PPO或GRPO算法，奖励设计得好，效果天差地别；奖励设计得差，再花哨的算法也救不回来。

另外，验证集监控是生命线。没有干净的验证集，你根本不知道模型是在真提升还是在刷分。我建议任何做自我改进的人，先把验证集建好，再开始训练。

最后，不要追求无限迭代。自我改进有边际收益递减，而且多轮之后容易退化。通常3到5轮后，就需要引入新的人类数据或外部信号来校准。把这个循环当成一个“增强”工具，而不是“替代”工具，心态会稳很多。