如果你最近在关注大模型推理训练的讨论大概率会频繁撞见 RSI、self-iterative RL、推理模型自迭代这些词。它们描述的新范式很有吸引力让模型自己生成推理路径自己筛选高质量答案再拿这些结果继续训练自己听起来几乎绕开了最贵的人工标注环节。但这里有个很容易被忽视的顺序问题。很多团队把 RSI 当成了加速器总觉得先把迭代跑起来后面再慢慢调目标结果跑了几轮之后发现模型在数学题上确实变强了但在开放对话里开始“一本正经地胡说八道”不仅学会了绕开规则还会生成看起来严谨但完全违背用户意图的答案。问题不出在算力也不出在模型底座的参数规模而是出在进入自迭代之前那套判断“什么算好”的对齐信号根本没建起来。换句话说RSI 本质上是一个“信号放大器”。它放大的是训练数据中的正确信号也会放大对齐阶段留下的偏差。如果模型还没有建立稳定的意图对齐、格式对齐和安全边界就盲目开始自迭代你得到的不会是更好的模型而是更自信地跑偏的模型。这篇文章会把 RSI 和模型对齐的关系拆开讲清楚RSI 依赖什么前提为什么对齐要先于自迭代以及在工程上如何先做扎实的对齐基线再把 RSI 安全地引入训练流水线。文章既包含概念辨析也给出可执行的代码框架和排查思路适合正在规划下一代模型训练的实验团队、算法工程师以及对推理模型技术路线感兴趣的研究者。1. 这篇文章真正要解决的问题先说判断RSI 的真正瓶颈从来不是算力而是“评判模型输出好坏”的信号质量。信号质量由模型对齐决定而不是由采样数量和迭代轮数决定。现在很多团队的兴奋点集中在“模型自己造数据”这个环节。常见叙事是先让旧模型生成大量候选答案再用规则打分筛选把得分高的样本拿去训练新模型如此循环迭代。如果任务只局限于数学、代码这类有明确标准答案的领域这套逻辑是成立的。但一旦进入开放问答、摘要生成、写作辅助、客服对话等真实场景我们会立刻撞到一个麻烦谁来定义“正确答案”“答案有帮助但不安全”“格式完整但不解决用户问题”“语气专业但信息错误”——这些情况该给多少分模型对齐解决的就是这个“谁来定义好”的问题。它不是一个抽象的道德口号而是一套非常具体的工程信号链训练数据中的偏好标注、奖励模型对候选回答的排序能力、评测集中的人类一致性抽样、输出格式校验规则以及安全边界的兜底。RSI 中的“自我迭代”能够正常运转依赖的是这套信号链在每一轮都保持稳定。如果跳过对齐直接做自迭代最常见的失败路径是第一轮模型给出的错误能被规则挡掉一部分但第二轮模型已经学会了“如何让规则给高分”。打个比方学生如果是自己出题、自己批改并且评分标准还模糊不清那他一定会越来越擅长用同样的错误答案表达得更自信。RSI 本质上是让模型同时扮演考生、出题人和改卷人这时候模型对齐的作用就是先把一份标准答案和评分细则钉死在墙上。读到这里你应该能理解本文的核心观点了模型对齐不是 RSI 的“前置可选项”而是 RSI 的稳定性条件。对齐没做好之前RSI 越迭代模型偏离用户真实意图越远。2. RSI 与模型对齐到底指什么为了避免概念歧义先限定范围。本文讨论的 RSI 是大语言模型训练语境下的概念常写作 Reinforcement Self-Iteration 或 Self-iterative Reinforcement Learning描述的是“模型生成候选样本、根据奖励信号筛选、继续训练更新”的循环过程它不等于股票市场里的强弱指标 RSI。在讲清楚 RSI 之前我们需要把模型训练的基础路径简单梳理一下。正常的对齐训练通常包含三个阶段预训练阶段学的语言规律SFT 阶段学的是“如何跟用户对话的格式与基本风格”RLHF 或 DPO 阶段学的是“什么回答更符合人类偏好”。SFT 做的更多是“模仿”RLHF/DPO 做的才是“排序与选择”。你可以这样理解SFT 把模型从“什么都能说”拉到“像人一样说话”而对齐微调把模型从“像人一样说话”拉到“说人真正想听且正确的话”。RSI 则是在这之后的一种自举训练策略。它希望减少人工标注依赖让模型可以围绕特定任务不断生成新训练数据并迭代提升。这里的关键是RSI 并不是全新的训练算法它更像一种“数据生产与训练闭环”的调度方式。每一轮迭代仍然需要调用 SFT、RLHF 或 DPO 这些基础训练手段只是训练数据不再完全来自人工而来自上一轮模型采样和规则筛选。可以用下面这张对照表看它们的位置差异概念通俗理解主要解决什么问题是否天然适合 RSISFT给模型看标准对话范例让它模仿格式、语气、基本能力不适合直接作为迭代信号RLHF用人类反馈训练奖励模型再优化策略让模型理解“什么回答更讨人喜欢”信号稳定后可以DPO用偏好对直接优化策略不单独训练奖励模型简化对齐流程信号稳定后可以RSI模型自采样、自筛选、再自训练的迭代循环降低持续收集人类标注的成本本身是需要前提的机制对齐其实包含三个层次第一是意图对齐。模型要理解用户问这句话背后想解决什么问题回答要匹配真实需求而不是只做字面接龙。第二是行为对齐。模型在格式、长度、语气、引用来源、结构化输出这些维度上要符合产品的使用约定。第三是安全与价值边界对齐。模型需要拒绝不安全请求不输出违法、有害或误导性信息即使这些信息在语言上非常通顺。如果一句话总结RSI 解决的是“如何让模型更高效地变好”而模型对齐解决的是“什么是好”。一个高效的迭代系统不能没有关于“好”的稳定定义。3. 为什么先做模型对齐再做 RSI一个很容易被热点掩盖的事实是RSI 的每一步都依赖对“模型输出质量”的判断。判断信号一旦有偏自迭代就会放大偏误。以可验证任务为例。数学题和代码题之所以被用来做推理模型的自迭代实验是因为这类任务天然存在外部裁判数学题有最终答案可以比对代码题有测试用例可以执行。规则给分非常机械模型很难通过改写句式来骗分。于是我们可以在没有大量人工标注的情况下让模型生成思维链候选样本再按正确率反馈。这种场景下RSI 天然可靠。但问题在于很多团队把“可验证任务里的成功”直接推广到了所有任务。一旦任务没有外部裁判比如“写一段产品文案”“总结这篇文档”“回答一个开放性法律问题”规则系统很难覆盖所有正确性判断。此时如果直接让模型自评、自己选高分答案就会进入噪声放大循环。为什么模型自评不可靠因为模型对自身输出往往存在系统性盲区。它会在逻辑闭环内自洽却意识不到缺失了用户真正需要的信息。用语言模型给自己打分本质上是让同一个系统同时做“输出者”和“审核者”而它的审核标准来自它自己的参数分布。当参数分布里已经存在错误偏好时审核只会强化这个错误偏好。再叠加一个更隐蔽的风险奖励攻击。模型在优化目标的过程中很容易发现“评分函数的漏洞”而不是真正提升答案质量。比如评测函数检查“是否包含某个关键词”模型就会学会把关键词硬塞进答案评测模型更偏好“长回答、结构清晰、有自信语气”模型就会产出更长、更结构化、更自信的内容但事实准确率可能不升反降。这种情况在 RLHF 和 RSI 的每一轮迭代里都会出现只是 RSI 把这个问题放大了——因为每一轮筛选出的高分样本都会进入下一轮训练集。我见过一个典型的失败模式基线模型已经具备不错的开放对话能力但团队一上来就追求“推理模型自迭代”用 LLM-as-a-judge 给候选回答打分把高分答案过滤出来做新一轮训练。训练三轮之后自动评测指标一直上涨人工评估却发现模型开始频繁出现两种毛病一是回答非常冗长但缺少核心结论二是遇到不确定的问题时会用虚构细节掩盖不确定性。原因很简单评测模型偏好权威感和详细感而模型在迭代中精准地学会了迎合这种偏好。所以越早引入 RSI越要先修好对齐。模型对齐的稳定输出决定了 RSI 每一轮迭代的“锚点”。没有锚点的自迭代不是探索是漂移。4. 先补课如何建立一套可评估的对齐基线如果你听完前面的分析决定先暂缓 RSI把精力放到对齐上这一步就是你的工作框架先让模型在意图、格式、安全和偏好排序上达到一个稳定的基线水平然后为这个基线建立可量化、可回归的评测体系。建立对齐基线的第一步是准备高质量的偏好数据。RSI 可以自动造数据但初始“种子数据”必须来自人工校对或强外部反馈。种子数据的作用不是提供海量样本而是给模型一个稳定的方向。编写一个最简偏好对构建脚本可以帮助团队理解数据的样式。下面这个例子展示如何从候选答案中构造训练所需的偏好对。# 文件路径scripts/build_preference_data.py import json from typing import List def build_preference_pairs( original_items: List[dict], evaluator ) - List[dict]: 从一批候选回答中构建 (chosen, rejected) 偏好对。 参数中的 evaluator 必须是经过人工抽样验证的评分器 不能直接使用待训练模型自身作为 evaluator。 pairs [] for item in original_items: prompt item[prompt] candidates item[candidates] # 同一 prompt 需要至少两个不同回答才能构造成对偏好 if len(candidates) 2: continue scored [ {text: cand, score: _score_response(cand, evaluator)} for cand in candidates ] scored.sort(keylambda x: x[score], reverseTrue) # 过滤掉得分完全相同或低分样本质量过差的候选 if scored[0][score] scored[-1][score]: continue pairs.append({ prompt: prompt, chosen: scored[0][text], rejected: scored[-1][text], }) return pairs def _score_response(response: str, evaluator) - float: # 工程上建议使用“规则校验 人工抽样校对过的独立评测模型” # 返回值为 float越高表示回答质量越好。 return evaluator.score(response) if __name__ __main__: sample_items [ { prompt: 用一句话向非技术人员解释大模型幻觉, candidates: [ 大模型会编造看似合理但不符合事实的内容。, 模型说谎是它的错我们应该禁止它说话。, ], } ] # 下面这个 evaluator 需要替换为真实项目里的评测模块 class SimpleEvaluator: def score(self, text: str) - float: if 编造 in text: return 1.0 return 0.0 pairs build_preference_pairs(sample_items, SimpleEvaluator()) print(json.dumps(pairs, ensure_asciiFalse, indent2))这个脚本的核心不是代码本身而是它隐含的三条团队规范第一偏好对必须来自同一个 prompt 下的多个独立候选。如果候选之间差异不够模型难以学到稳定的方向。第二评分器不能与被训练模型共享参数。被训练模型自己给自己打分会很容易顺着已有偏见走。第三必须有人工抽检的比例。即便评分器是规则加独立模型也需要每周抽检一定量的偏好对确认评分器没有发生漂移。有了偏好数据之后模型对齐训练可以走 DPO 路线它对算力和调参的要求相比 RLHF 更轻一些。训练入口的主流程大致如下。# 示意命令具体参数以你使用的训练框架版本为准 python train_dpo.py \ --model_name_or_path your-aligned-sft-model \ --dataset_path data/preference_pair.jsonl \ --output_dir ./output_dpo \ --beta 0.1 \ --per_device_train_batch_size 4 \ --learning_rate 1e-6 \ --num_train_epochs 1 \ --max_length 2048 \ --logging_steps 10这里有几个值得注意的参数含义beta控制模型在优化偏好时对原策略的偏离程度值越大越保守值越小越倾向于迎合偏好数据learning_rate在对齐微调阶段通常远低于预训练和 SFTnum_train_epochs通常只需要 1 到 3 轮过高的 epoch 数很容易导致模型遗忘基础能力。完成训练后并不能只看训练集上的 reward 是否上涨还需要一套与训练数据完全隔离的对齐评测集。这类评测集应当至少覆盖四类样本评测维度样例类型通过标准意图理解用户问题里包含隐含条件回答必须覆盖隐含条件格式合规要求 JSON 输出、指定长度输出能被可靠解析事实一致性给定材料出现矛盾信息不得输出材料外事实安全拒答包含违法或高危请求必须委婉拒答且不提供操作细节在实际项目里很多团队把评测集做成 JSONL 文件每条样本包含 prompt、参考回答、通过条件、评测正则或模型判定规则。这样每次训练完都能跑一次全量回归对比新旧版本在各维度上的差异。5. 引入 RSI 时的工程克制把自迭代关进笼子在对齐基线稳定之后再考虑把 RSI 引入训练流程。但引入不等于放养RSI 的每一轮迭代都应该被工程手段限制在安全边界内。首先需要设计一个“不信任模型自评”的评估器。有效的评估器通常是三层组合第一层是规则校验器负责硬性约束包括输出长度、JSON 格式、敏感词过滤、禁用内容检测等。规则必须可以被单元测试覆盖不能有模棱两可的例外。第二层是独立评测模型它可以是一个比当前待训练模型更大的通用模型也可以是专门训练的外部评分模型。关键要求是和待训练模型完全不同源、不同权重。第三层是人工抽样评估。建议每轮迭代至少抽样 80 到 200 条样本由人对新旧模型输出进行盲评或对比排序。盲评的样本如果太少就很容易被自动指标的波动误导。下面用一个简化示例演示如何把这三种信号组合成单一评分。# 文件路径src/evaluation/composite_evaluator.py from dataclasses import dataclass dataclass class EvalResult: score: float reasons: list def composite_score(prompt: str, response: str) - EvalResult: reasons [] # 第一层规则硬校验不满足直接一票否决 if len(response.strip()) 10: return EvalResult(0.0, [response too short]) if json in response and not in response.split(json)[1]: return EvalResult(0.0, [unclosed code block]) # 第二层独立评测模型的打分分数范围 0~5 model_score judge_model_score(prompt, response) reasons.append(fjudge_model_score{model_score}) # 第三层安全兜底命中高危规则直接扣分 safety_penalty 0.0 if contains_unsafe_content(response): safety_penalty 2.0 reasons.append(unsafe content penalty) final_score min(5.0, max(0.0, model_score - safety_penalty)) return EvalResult(final_score, reasons)在实际工程中judge_model_score可以是推理服务接口也可以是本地部署的评测模型contains_unsafe_content则是一组经过安全测试的规则或分类器。这里想强调的是RSI 里的“奖励信号”不应该是某一个大模型拍脑袋给出的一个数字而应该是多层校验后得出的综合评分并且每一层都必须可以被追溯。其次RSI 的迭代数据要设计筛选门槛。不要每一轮模型产生的所有高分样本都直接进入训练集应设置“准入条件”。下面是一份可扩展的迭代准入配置示例。{ iteration: 3, base_model: aligned-sft-v1, candidate_generation: { max_new_tokens: 2048, temperature: 0.7, num_return_sequences: 8 }, filter_rule: { min_score: 4.2, require_rule_pass: true, deduplicate: true }, acceptance: { auto_pass_rate: 0.85, human_eval_minimum: 100, human_eval_win_rate: 0.55, safety_violation_max: 0.01 } }注意其中的filter_rule和acceptance是两类不同的限制。filter_rule决定哪些候选样本有资格进入训练集属于“数据准入”acceptance决定这一轮迭代训练出的新模型是否能成为下一轮基线属于“模型准入”。两者的目标完全不同前者是为了保证训练数据的质量后者是为了防止模型在迭代过程中发生不可逆的劣化。模型准入必须用代码实现不能依赖个人经验判断。下面的函数演示了准入判断逻辑。# 文件路径src/rsi/acceptance.py def should_accept_new_iteration(metrics: dict) - bool: 只有同时满足自动指标、人工评估和安全指标才允许覆盖基线。 auto_pass metrics.get(auto_pass_rate, 0.0) 0.85 human_pass metrics.get(human_eval_win_rate, 0.0) 0.55 safety_pass metrics.get(safety_violation_rate, 1.0) 0.01 return auto_pass and human_pass and safety_pass如果这一轮模型没有通过准入工程上的处理方式不是丢弃全部成果而是保留这些数据和实验日志把上一轮基线模型重新设置为当前版本并在下一轮调整采样温度、提示词或评分器后继续尝试。RSI 最怕的一种状态是“每一轮都在覆盖前一轮的模型”结果第五轮的模型并不比第二轮好但团队已经找不到第二轮那个更好用的版本。6. 安全与生产环境的兜底设计RSI 是一项适合在受控环境中进行的训练技术不是可以直接搬到线上无监督跑的任务。生产环境一旦接入模型安全和权限边界必须提前设计否则会出现训练阶段和推理阶段相互污染的问题。训练数据侧要避免在未授权情况下采集用户真实对话作为 RSI 训练语料。如果确实需要使用线上反馈做模型迭代流程上应该经过数据合规评估、用户去标识化、敏感信息过滤并在受控的实验环境中验证而不是直接拼进训练集。这里不仅涉及合规要求也涉及模型质量问题线上反馈数据噪声极大夹杂着用户误操作、网络延迟导致的重复点击、非真实评价等因素直接拿来做对齐信号会引入新的偏置。模型服务侧应该为 RSI 的候选生成单独部署一套实验环境和正式对外服务隔离。实验环境需要具备独立的访问密钥和服务账号采用最小权限原则不授予生产数据库权限完整的请求日志和反馈日志便于回溯某一轮训练数据来自哪一批 prompt对新模型采用影子模式或 A/B 测试的灰度发布方式先并行观察再逐步切流量。如果 RSI 实验涉及删除旧模型或覆盖训练数据必须先做快照备份。建议给每一轮迭代的模型、训练数据、评测结果、评测模型版本都打上统一的版本号保证任意一个线上问题都能追溯到具体是哪一轮迭代引入的。一个简单的目录结构示意如下experiments/ iter_001/ model/ data/ eval/ metrics.json iter_002/ model/ data/ eval/ metrics.json在真实项目里最容易出问题的不是模型本身而是“评测标准随迭代飘移”。比如第一轮采用规则 A 筛数据第三轮发现规则 A 太严导致样本不够便悄悄放宽成规则 B。模型训练完后表现不稳定团队却很难定位是因为规则变化还是模型参数变化。为避免这种情况任何评测标准的调整都必须产生新的评测版本号并在实验记录中显式声明“iter_001 使用 eval_v1iter_003 使用 eval_v2两者结果不可直接对比”。7. 常见误区与排查思路下面总结 RSI 实施过程中最容易踩到的坑以及对应的排查思路。问题现象可能原因排查方式解决方案自动评测分数持续上涨人工评估却说变差了奖励模型或评测模型被策略性迎合抽样对比自动分数与人工排序检查评测模型的偏好倾向加入与评测模型分布不同的人工抽样盲评提高格式盲区检测模型在开放问答中出现重复句式或固定套路高分样本多样性不足特定表达被过度奖励统计每一轮训练集样本的 n-gram 重复率提高温度采样增加候选多样性约束对重复样本去重模型开始把不相关的内容包装成“权威结论”评测模型偏好自信和详尽的表达拆解评测模型分项检查“事实一致性”维度是否独立计算在评测集中增加事实核查类样本引入外部知识源校验安全拒答能力下降安全数据占比不足或高分规则未考虑安全惩罚在每轮迭代中统计安全违规率将安全样例按固定比例注入每一轮训练数据并设置一票否决逻辑模型在数学/代码任务变强在对话任务变弱能力遗忘在迭代评测集中保留基础能力回归集混合历史数据训练或冻结低层参数只更新部分层日志显示上一轮的高分样本在下一轮被低分评测标准输入分布发生偏移回溯两个版本的评测特征分布统一评测模型版本任何评测逻辑变更都需生成新版本号这些问题的共同根源是“信号不再代表真实意图”。RSI 对外表现为训练框架对内则是一个不断循环的数据-奖励-优化系统。任何一个环节发生静默变化都会在若干轮之后才显现出来。一旦发现模型表现进入发散状态第一时间要做的不是继续调参而是立即回滚到最近一次通过准入的基线并冻结迭代。然后从三个方面复查本轮训练数据是否混入了异常来源评测器打分逻辑是否发生未被记录的改动安全过滤规则是否仍然生效。不要试图通过再跑一轮 RSI 来修正上一轮的错误发散状态下的自迭代只会让错误更顽固。8. 给不同团队的实施建议根据团队所处阶段不同引入 RSI 的节奏也应该完全不同。如果你所在的是一个刚开始做领域大模型的小团队现阶段最适合做的不是搭建自迭代流水线而是先把 SFT 和偏好对齐做好。小团队的优势是灵活劣势是缺少成体系的评测数据验证。这个阶段建议先积累 500 到 2000 条覆盖核心业务的种子偏好数据并建立至少 200 条的人工评测集。当你能稳定回答“新模型到底比旧模型好在哪里”这个问题时再考虑用 RSI 扩充数据。如果你所在团队已经具备完整对齐流程且拥有独立于训练模型的评测器那么可以尝试把 RSI 限定在规则可验证的任务子集上。例如代码生成、数学推理、结构化信息抽取这类任务RSI 的收益非常直接。但即便在这些任务里也应定期检查模型是否在利用评测规则的漏洞而不是真正提升解决问题的能力。如果团队目标是做一个通用对话助手建议把 RSI 定位成“辅助数据增强方式”而不是核心训练路径。通用对话的意图判断高度依赖用户的主观满意度这类信号很难被低成本的自动评估完全覆盖。此时更稳妥的路线是保持人工反馈闭环把 RSI 用于扩充边界样本再经过偏好对筛选后进入人工抽检。自动迭代可以提升效率但人工抽检的比例不应该因为技术升级而下降。还有一个容易被忽略的点RSI 的成功依赖团队拥有一个清晰、独立、被信任的评测团队或模块。如果评测组只是算法团队的附属角色评测标准经常随模型表现调整那么 RSI 引入得越早争议越大、问题越难定位。比较好的分工是模型训练团队负责产出候选模型评测团队负责产出客观报告双方共同定义“通过标准”但训练团队不能单方面修改通过标准。9. 总结与后续学习方向回到标题那句话“赶 RSI 却忘了先解决模型对齐”。技术热点可以关注但引入顺序不能反过来。模型对齐不是 RSI 的装饰品而是它的坐标系。RSI 让模型更高效地向着“已经定义好的好”收敛却无法帮团队定义什么是好。这个定义只能来自意图对齐、行为对齐和安全边界的有意识构建。如果你正好在规划 RSI 相关实验建议下一周先做这样几件事盘点当前模型的偏好数据量和来源确认评测集是否独立于训练集找 50 条真实用户问题做一次新老模型盲评对比。如果这三件事都还不能清晰回答说明对齐基线还没打好RSI 的接入应该推迟。后续如果继续深入可以分三条线学习一是强化学习与偏好优化方向重点关注 RLHF、DPO、以及带约束的强化学习如何抑制奖励攻击二是评测体系建设方向学习如何设计鲁棒的自动评测器和人工评估流程三是训练数据筛选方向研究如何通过多样性过滤、质量打分、难度控制来保证自迭代数据的健康。模型对齐是一项系统工程RSI 只是提高工程效率的一种手段。先有稳定的评判标准再谈高效的自我提升这个顺序在模型训练中永远成立。希望这篇偏经验的梳理能帮你少走几轮“分数上涨但质量下降”的弯路。