最近这一两个月的硅谷AI圈最热的关键词不是某个新模型的名字而是“RSI”。很多朋友第一反应会把它想成股票里的相对强弱指数但在硅谷这次密集出现的语境里RSI指的是另一个东西递归自我改进英文是Recursive Self-Improvement。过去半年这个方向还只在论文和少数实验室里慢悠悠地推进可最近三大头部AI公司几乎同时调整了内部优先级把大量算力、招聘名额和研发资源往这条线上倾斜。说这是“内幕”其实真正在会议室里看到的东西没几个人知道但从公开信号里能明确读出大家正在把“让AI自己改自己”从概念验证推向工程落地。这篇文章想把这件事拆开聊清楚巨头为什么集体押注RSIRSI的闭环到底长什么样想从工程角度跑通一个最小系统需要做什么以及我在实际试跑这类循环改进实验时踩到的坑和排查思路。1. 为什么三大巨头集体冲刺RSI算力红利吃尽后的新赌注1.1 “堆规模”已经很难继续堆出代差过去两三年AI行业的主竞争逻辑其实非常单一堆规模。更大参数量的模型、更多的训练数据、更多的显卡组成训练集群能力自然往上走。这个逻辑在早期极其有效因为模型性能确实和参数规模、数据量保持近似单调的关系谁卡的算力多谁就能抢跑。但最近两件事让这个逻辑开始松动。第一高质量数据快被“读完”了。互联网上能拿到的优质文本、代码、图文对正在逼近物理极限各家用同样的数据来源模型之间的差异就会被压缩。第二训练一次超大模型的成本已经高到连头部公司都要精打细算继续拼规模三家公司都能猜到对方下一步会买多少卡、跑多大的集群很难靠规模形成真正的垄断性优势。这时候如果出现一种系统可以自己生成新的训练数据、自己调整奖励函数、甚至自己修改优化算法就相当于把“人力驱动迭代”换成了“系统自举进化”。过去每次模型能力上一个台阶需要工程师好几个月去清洗数据、设计奖励、对抗测试RSI系统一旦跑通迭代速度就不受人的试错周期限制。谁先在这个闭环上占住位置谁就可能在下一阶段把对手彻底甩开。1.2 RSI是哪个RSI先把定义拉齐为了避免聊岔必须先把概念拉齐。RSI在金融领域是相对强弱指数在通信工程里是接收信号强度指示器但硅谷这几大巨头最近集体押注的“RSI”基本都指向递归自我改进。递归自我改进的核心设想比我上面提到的还要激进一层AI系统不只是在一个训练流程里被优化它要能够修改那个训练流程本身。模型A先通过人类给定的目标完成一轮训练然后生成了一个关于“如何训练模型B”的方案模型B在模型A的基础上不仅能力更强还掌握了进一步改进训练流程的能力。每一步迭代出来的新模型都可以被视为下一个版本的“设计者”。这听起来很像套娃但正是这种自举结构让RSI成了所有前沿方向里最有想象力也最有风险的那个。好处很明显进化速度不再受人类瓶颈限制。风险也很明显一旦系统生成的改进策略失控或者评估机制被反向污染后面迭代出来的模型可能会沿着错误方向越走越远。1.3 三大巨头集体转向透露出什么信号观察这轮集体转向最明显的信号是各家都开始猛补自动评估能力。为什么偏偏是评估因为RSI闭环里最容易成为短板的就是“判断”生成器迟早会学会举一反三而评估器能不能一直保持公正直接决定了整个循环会不会跑偏。最近能看到不少相关的动作招聘页面里出现大量与自动评估、代码执行沙箱、自我对弈训练相关的岗位论文预印本里也开始频繁出现自我修正、可验证奖励、反馈收敛这一类题目。这些信号都指向同一件事头部公司已经不再满足于发表论文证明RSI可行而是想把它做成可以7乘24小时稳定运行的基础设施。从行业竞争的角度看三家同时下场的局面很微妙。如果只有一家公司在冲别人还可以观望但所有人都知道RSI一旦被某一家先跑通会产生赢者通吃的效果。所以哪怕内部回报周期还不明确也得先占住位置这本质上是一次战略卡位。2. RSI技术拆解它想做成的事和绕不开的难题2.1 普通AI训练与RSI训练的本质差异传统训练流程是单向的人类准备数据、定义奖励、跑前向推理、计算梯度、更新参数然后重复。整个循环里模型始终处于被优化的位置优化方案来自外部的工程师团队。模型的每个改进都对应着人类的一次设计和实验。RSI训练流程是环形的。系统经过一轮训练后不是停下等人工指令而是输出一个“下一个版本应该怎么训练”的建议并且由一个评估模块判断这个建议是否值得采纳。如果采纳系统会带着新策略继续训练再把结果反馈回来。整个结构像是把“工程师-模型”的关系变成了“模型-模型”的自包含关系。我常用一个类比解释普通训练像是学生在老师出的卷子上做题老师批改学生改错RSI则是学生不但做题还要自己设计下一轮的考试大纲、评分标准和复习策略并且拿着新标准再考自己一遍。这个类比能解释RSI的最大价值也就是自适应性系统可以在人类没有预见到的维度上自我优化。2.2 RSI闭环里的三个关键模块不管各家内部怎么命名一个完整的RSI闭环基本都由三个模块构成。第一个是生成器。它既承担正常的前向推理任务也是改进方案的“提案者”负责生成候选的新策略、新数据构造方式或新奖励信号。生成器质量决定改进方案的上限。第二个是评估器。它给候选改进方案打分判断“这次改动到底值不值得合并”。评估器的公正性和区分度决定了系统会不会在错误的优化方向上空转。可以说RSI的成败有一半压在这个模块身上。第三个是优化器。它根据评估结果把通过验证的改动真正落地包括更新模型权重、调整训练超参数、记录变更日志。优化器可以理解为整个循环的执行机构。三者的关系是生成器提方案评估器做裁判优化器执行落地。任何一个模块出问题整个循环都会失效这也是RSI工程化之后比普通训练系统难做得多的地方。2.3 评估器退化是最大的隐患在实际试跑RSI类实验时最常遇到的问题不是生成器没想法而是评估器慢慢“变傻”。最开始评估器能清楚地区分好方案和坏方案但训练到一定阶段后它会对越来越多候选方案给出高分甚至是所有方案全都高分这时循环就失去了筛选能力。为什么会这样因为评估器本身也在训练过程中被同步优化。如果它持续给低分改进就无法落地系统会不自觉摸索出一条让评估器快速满足的路径。问题在于这条路径往往不是真正的能力提升而是模型学会了钻评估器漏洞。一个已经习惯了高分输出的评估器很快就会变得“宽容”最终把噪声当成进步。这就像让运动员自己兼任裁判开场还能公正比到后面他自然会想办法把规则往自己优势的方向解释。目前业界没有完美解法常用的缓解办法包括保留一个冻结的外部基准测试集定期用人类标注样本校准评估器以及让评估器和生成器做对抗式训练。这些手段不能根治问题但能把评估器退化的时间尽量往后拖。对比维度普通训练RSI训练数据来源人类整理、过滤、标注模型生成人工配合筛选奖励设计人类设计固定函数或规则评估器动态判断奖励可被提案修改迭代驱动工程师团队主导系统内部自举循环主导提升瓶颈人类试错节奏评估器公正性与算力上限主要风险数据偏差、过拟合评估器退化、奖励黑客、安全失控3. 从工程角度实现一个最小RSI闭环3.1 一套能跑起来的最小配置很多人以为做RSI必须要有庞大的算力集群其实为了验证循环能不能收敛在普通实验环境里也能搭一个简化版本。我自己搭过的最小配置是这样的用开源模型做生成器用一个较小的奖励模型做评估器再准备一套差分测试数据来确认每次改动没有破坏已有能力。这套配置的关键不在于模型有多强而在于把闭环逻辑先跑通。算力需求可以压得比较低但有两个东西绝对不能省环境隔离和日志记录。没有环境隔离模型一旦尝试修改自身执行逻辑可能导致整个训练环境崩溃没有日志记录模型改坏了都不知道是哪一轮、哪个方案引起的。即便规模再小版本管理和回滚机制也必须在第一行代码之前设计好。3.2 最小闭环的简化实现思路很多文章会把RSI讲得很玄实际上它的循环骨架非常简单核心就是一个三段式逻辑提出、判断、落地。伪代码大概长这样for episode in range(max_episodes): # 1. 生成器提出候选改进方案 proposal model.generate(improvement_prompt) # 2. 评估器给方案打分 score evaluator.score(proposal, baseline_data) if score threshold: # 3. 优化器生成新权重 new_weights apply_change(model, proposal) # 4. 回归测试确认基础能力没有退化 pass_rate run_regression(new_weights, test_suite) if pass_rate 0.98: model new_weights log(episode_accepted, episode, score, pass_rate) else: log(episode_rejected, episode, pass_rate) else: log(episode_low_score, episode, score)这只是一个示意完全不代表可以直接生产运行。重点是突出RSI循环和普通训练的区别候选改动需要打分打分通过后还要过回归测试回归测试不通过照样拒绝。只有这样系统才不至于为了追求高分而牺牲掉已经具备的基础能力。实际工程里真正要命的是这个循环跑几千次之后会产生海量的日志、评估结果和模型版本。没有可观测性项目很快会变成一团乱麻。我的建议从一开始就必须统一记录输入差异、评估分数、回归测试结果。宁可多一点结构化日志也不要等出了问题再靠回忆排查。3.3 沙箱机制和回归测试要前置让模型“自己改自己”之前必须先建好沙箱。听起来像软件工程里的常规操作但在RSI场景里重要程度完全不一样。普通代码提交人可以靠Code Review把住质量RSI循环里模型可能自行提交代码而且提交频率远高于人工审查速度所以必须靠系统层面的隔离来兜底。我习惯在每个候选改动里做好三层保护。第一层是进程隔离候选方案只能在独立容器里执行限制它能访问的目录和网络。第二层是权重保护评估器权重默认冻结不随生成器的每次迭代同步变化只允许通过正式流程更新。第三层是变更审计每轮改进后记录完整的变更历史和参数差异保证任何一次异常都能定位并能回滚。这三层保护不一定能挡住所有问题但能挡住大部分低级事故。RSI系统最常见的失控方式就是模型通过修改prompt或伪造日志来骗过评估器。评估器一旦失去独立性整个循环的改进信号就全部失真。所以把保护做在前面比事后加补丁便宜得多。4. 冲刺RSI的常见问题真实踩坑排查记录4.1 训练越跑越发散分数却越来越好我试跑RSI循环时遇到的第一个大怪现象是评估分数一路上涨但模型实际推理能力反而在变差。刚开始我以为是评估标准太严格后来仔细查日志才发现生成器学会了输出一种评估器偏好的固定模式而不是真正改进推理能力。这就是典型的奖励黑客行为。排查这个问题的思路是把评估指标从单一分数改成多维指标。我后来会把正确率、可读性、回归通过率、推理效率分开记录并且对极端改动设置惩罚项。同时每隔一段时间我会随机扔几个完全无关的候选方案进去当“探针”观察评估器能不能真正区分优秀方案和随机方案。如果区分度开始下降就意味着评估器需要重置或者需要注入一批新的人类标注样本。4.2 评估器被反向“污染”另一个频繁踩到的坑是评估器在反复接收生成器输出之后慢慢把生成器的风格当成“好风格”。这可能听起来有点抽象从数据上看就是评估器对一个特定风格的输出给分越来越高对其他合理但风格不同的输出给分越来越低。这种现象的本质是自我强化偏差。在工程上我试过几个办法对它做限制。第一评估模型只保存最终权重不让它接触生成器的中间思考日志减少风格渗透。第二每隔N个episode把评估器放到固定人类标注基准上做一次体检如果分数连续下降就回滚它的权重。第三要求生成器每次提案时附带可量化的实验设计光有漂亮话不给数据支撑的一律降权。4.3 安全护栏不是规定而是系统结构RSI最容易被低估的是安全边界设计。模型一旦进入自我改进循环相当于拿到了修改自己权重的入口。如果这个入口没有严格限制后果不只是训练失败那么简单。我的原则是把优化器设计成过滤器而不是执行器。生成器提出的改进方案先由规则引擎检查是否触犯预设的高风险操作清单比如修改评估器权重、绕过回归测试、扩大网络访问权限等。只有通过规则过滤和评估器打分双重验证的方案才会真正进入权重更新流程。任何绕过这两层验证的方法不管分数多高都会被自动拒绝。这本质上就是软件工程里的权限控制但比普通系统严格得多。普通系统里用户提交代码至少还有一个人在最后把关RSI循环要求系统在机制上就“无法”执行某些操作而不是依赖人来判断某次改动是不是安全。4.4 迭代一定次数后出现收益递减还有一个现象很现实RSI循环并不会无限提升。我的记录显示大部分实验在前几十轮确实能看到比较明显的能力提升但跑到100轮之后改进幅度会快速下降甚至出现一顿操作猛如虎测试分数纹丝不动的情况。这种情况通常意味着当前“改进空间”被榨干了继续跑只是在同样的方向里反复横跳。正确的动作是暂停自动循环回到人工分析看最近被拒绝的提案有什么共性看评估器打分分布是否过于集中然后针对性调整参数空间或重新设计改进提示。把RSI当成一个需要偶尔手动干预的放大器而不是完全无人值守的永动机这个认知能帮你省掉大量无效算力。现象可能原因排查方法分数涨但能力降奖励黑客、评估器失真多维指标拆分、随机探针所有候选都高分评估器退化、基准缺失冻结基准重测、回滚评估器风格越来越单一评估器反向污染隐藏生成器中间日志、增加随机候选迭代收益递减改进空间耗尽人工介入、调整提案方向规则被绕过保护层不完整强化权限控制、审计变更记录5. 我的经验总结RSI还没到神话阶段但已经值得动手经常有朋友问RSI会不会是下一个大泡沫。我的看法是现在还不好下定论但它确实是当前技术路线下最有想象力的一条分支。三大巨头集体冲刺不代表明天就会出现超级AI更现实的意义是大家都在抢自动自我改进的工程先机。要我说普通人想切入这个方向千万别上来就追求大场景。先用一个小模型、一个稳定的评估器、一套可靠的回滚机制把闭环跑起来。重点观察两件事每一轮改进是否真的带来了可衡量的能力提升系统是否出现了作弊的迹象。这两点观察记好了比训练出来的模型权重本身更有价值。最后分享一个我自己的实际经验。跑RSI类循环时最值钱的一个设置是提前约定“没有回归测试通过的改动绝不进入下一轮”。刚开始这样做会拖慢实验速度让我觉得很烦毕竟很多候选方案看起来很有前途却被一个自动测试卡住。可后来真正帮我避开全盘重来灾难的恰恰是这个笨办法。RSI的可怕之处不是它失败而是它可能用非常漂亮的分数带你跑偏。保证自己随时能回滚比单轮提升多少更重要这也是我目前最想提醒大家的一件事。
