递归自我改进Recursive Self-ImprovementRSI大概是AI圈里被吹得最玄、也最容易被误读的概念之一。它的核心想象很诱人如果AI能够改进自己改进AI的能力那么人类需要亲手制造的可能就只有最后一台AI剩下的迭代交给系统自身滚动完成。听起来像科幻但真正动手做研究或工程时你会发现自己能改自己这句话几乎毫无操作意义。模型根据反馈改写一下提示词算不算自我改进训练一个奖励模型去调另一个模型算不算还是说必须达到某种智能指数级增长才算数最近读到一篇标题很挑衅的论文——《The Last AI Built by Humans: Toward Genuine Recursive Self-Improvement》它没有停留在哲学讨论上而是试图给什么才算是真正的递归自我改进一个可检验的定义和一套协议。这篇文章我想把它的核心要点拆开来讲同时结合我自己在模型迭代和数据验证上踩过的坑聊聊这套框架到底能在多大程度上落地。这类内容适合谁看如果你在关注AGI路径、模型对齐、自动数据增强或者你正在做用大模型改进大模型这类自举式的项目那这篇论文的思考方式会对你有直接的参考价值。它不是一篇给你现成代码的工程教程而是一个能够帮你分辨伪自我改进与可验证自我改进的思维框架。1. 为什么这篇论文坚持要重新定义RSI——传统思路走不通的地方1.1 两种主流直觉思路能力叠加与自我反思先说说大多数人对RSI的第一直觉。第一种想法是让模型学会编程然后给自己写更好的训练算法、更好的架构。这个思路看起来最直接但它有个致命前提模型必须在编程和算法设计上强到足以改进自身这本来就是超级智能的门槛了。说得直白点这属于你已经是AGI了才凑得齐启动条件的悖论不具备递归启动的可操作性。第二种想法是让模型反复评估自己的输出并修正。这个思路更容易在当下复现比如让LLM生成训练数据来微调自己或者让模型对自己的回答做多轮批判式修订。但它有一个非常隐蔽的陷阱模型自我评价的分数并不等于真实能力提升。我实测过一个典型例子——让一个7B模型自己生成一批更详细、更有逻辑的SFT数据然后微调它自己结果在某一类与训练数据同分布的评测上分数确实涨了但换一个分布略有偏移的数据集性能立刻回落。你很难说清楚这个过程中模型到底是变强了还是仅仅是过拟合到了自己生成的数据分布上。1.2 论文的核心转向从能力增强转向可验证的进步信号论文提出的关键转向是判断RSI是否成立重点不该放在模型是否变得更聪明这种模糊感受上而应该放在改进过程是否通过了可验证性检验上。换句话说真正值得关心的问题不是系统强不强而是系统的进步信号能不能被外部审计。这个转向非常像现实世界的公司审计逻辑。一家公司说自己今年利润翻倍这不算数得让第三方审计确认营收凭证、库存流水和回款记录利润数字才能被采信。论文对递归自我改进的态度也是如此一个AI系统说自己经过自我改进后变强了必须拿得出让人信服的验证链——留出的测试集、可重复的评估协议、置信区间以及对验证集未被污染的证据。凡是拿不出可验证信号的自我改进论文倾向于把它视为候补选手而不是合法RSI。1.3 伪RSI的三个典型形态我根据自己的工程经验把论文讨论中隐含的伪RSI归纳成三种常见形态方便你对照基准污染型改进过程中使用的训练数据与测试数据有重叠。比如模型生成的增强数据里混入了评测集原文或者评测集本身已经在预训练语料中出现过。这种情况下的分数上涨不是进步是记忆泄漏。自我表扬型评估完全依赖模型自己的判断。比如让模型给自己的回答打分再把这个分数当作改进依据。模型很容易学会生成更符合自己偏好的内容而不是生成更正确的内容。提示词魔术型研究者反复用同一组prompt微调、改写、拼接直到输出看起来更有条理然后在少量样例上做人工对比得出模型更聪明了的结论。这类改进往往在放大一个很小的验证集上的噪声换一批样本立刻失效。这三种情况在论文的框架里都不满足合法递归自我改进的条件因为它们没有提供一个可被独立验证的进步信号。2. SCE训练协议递归的每一步不是变强而是被验证地变强2.1 上游模型与下游模型把改进过程拆成可审计的角色论文提出了一套名为SCESuccessive Conceptual Elaboration连续概念阐述的训练协议思路。这个词听起来抽象但把角色拆开看其实很清晰。SCE的核心是把一次递归改进拆成三个角色上游模型负责提出改进方案。它可以建议修改训练数据、重新组织任务的表述方式、提出新的评估指标、甚至生成训练代码片段。下游模型负责执行上游方案并进行训练。它是实际承受改进后果的一方。验证器可以是人类也可以是自动程序负责检查下游模型是否真的变好了。这三个角色形成一个循环上游提出方案下游执行并更新验证器确认改进有效。树的结构则是一个递归链上一轮验证通过的下游模型成为下一轮的上游模型继续提出下一个改进方案。很多人第一次接触这个框架时觉得这不过就是个人类在环里的自动调参但我觉得SCE的精髓在于角色分离。你不再关心AI是否自己给自己写代码这种笼统问题而是可以精确地回答是哪个模型、基于什么信号、通过什么验证、完成了哪项具体改进一旦每一步都能回答这些问题递归过程就从黑箱变成了可审计的链条。2.2 一条合法递归链的运转流程按我的理解SCE中一条合法的递归链应该是这样运转的基线模型A在任务T上取得指标m0。模型A作为上游被要求提出一个改进方案p方案的具体形式可以是一组新的训练数据、一个不同的目标函数写法、或者重新表述任务的方式。方案p被应用到新模型B的训练流程中B是下游模型。在预先设定好的固定验证集V上评估B的指标m1。只有m1在统计意义上显著优于m0例如置信区间不重叠时B才被接受为新的基线模型。重复以上过程直到某个终止条件被触发。这个过程里有一个容易被忽略的细节SCE的命名中Conceptual Elaboration意味着每次改进不限于调超参数更鼓励模型重新表述任务本身。比如一个模型面对判断两个数学问题是否等价的任务它可能提出把问题重写成先分别化简再比较规范形的形式。这种重新表述一旦被下游模型验证有效就被保留下来成为后续改进的共享表征。知识的积累不是参数层面的微小调整而是任务理解层面的每一次深化。2.3 为什么可验证比强更关键如果你只有变强这个目标你永远无法判断什么时候该停止、什么时候该回滚、以及两个不同的改进路线是否可以合并。而可验证提供的是一个外部锚点。每一次递归迭代都产生一条可以被审计的记录用了什么数据、改了什么设置、在什么验证集上提升了多少。我在实际项目里对这个点的感触特别深。有一段时间我在做模型的自动数据增强每次迭代都能让内部评测分数上涨但产品上线后用户反馈却越来越诡异。后来复盘才发现模型学会了在内部评测分布上过度拟合真正用户场景中更换了提问方式后表现肉眼可见地退化。如果我当时在每一轮迭代上都设置一个不可妥协的外部验证集这个坑完全可以避免。论文把可验证放在RSI定义的核心就是在用形式化的语言提醒没有验证信号的自我改进大概率是在原地跑步甚至有可能是在往错误方向飞奔。3. 合法性测试用三个可操作的问题判断一次递归改进是否算数3.1 三种可验证进步类型论文讨论中反复出现verifiable progress这个概念我理解它的意思是合法的递归自我改进必须对应某种可验证的进步。进一步拆开可以分成三种类型类型判断对象验证方式典型示例可验证的任务改进模型在特定任务上的表现在固定留出测试集上指标显著提升数学推理准确率从60%提升到70%可验证的模型改进模型本身的能力边界展示出一个此前不具备且可验证的新能力从前无法完成形式化验证现在可以对程序输出给出可检查的验证步骤可验证的数据改进数据或数据生成管线的质量新数据能持续带来下游任务提升且不污染评估集自动筛选出的错误样本人工抽查确认后加入训练集使通用指标稳定上升三种进步类型里最容易产生误判的是第二种。很多团队声称模型的推理能力提升了但本质上只是现有任务上的分数提高了。论文强调真正的模型改进应该是一种可持续泛化的能力变化而不是某个benchmark上的数字变化。区别在哪里数字变化可能来自记忆、风格偏好调整或对评估集的分布拟合而能力变化应当能迁移到新的、未被训练过的任务上。3.2 谷仓问题两个模型都在进步但它们的进步合并不了论文里有一个让我印象很深的概念叫silo problem我把它理解成谷仓问题。情景是这样的两个模型分别在自己的领域里进行递归自我改进各自积累了独立的提示词体系、数据风格和评价标准。绕了一圈之后你发现它们各自都提升了但你想把两条改进路线合并到同一个系统里时崩溃了——因为两个系统对任务的定义、对好结果的定义、甚至使用的术语体系都不一致了。这个问题的根源在于验证信号总是相对于某个特定框架存在的。模型A的更好的证明风格在模型B的评价体系里可能毫无意义。现实中这种例子比比皆是一个团队专注prompt engineering另一个团队专注数据质量两边各自迭代三个月然后在这两个改进能不能叠加的问题上吵了起来。论文指出解决谷仓问题的方向是引入更高层级的评估维度也就是后面要说的全视野评估用领域级共享基准去校准不同系统的进步方向。3.3 防伪造进步信号必须不可用嘴炮伪造合法性测试的另一层深意是防伪造unforgeability。一个可验证的进步信号不能是那种看起来有道理但经不起深入检查的东西。举个例子解析数学证明的形式化严格性是天然的防伪造信号因为每一步推导都可以被自动化工具重新检查。文本更有说服力则是高伪造风险的信号——大模型非常擅长生成听起来流畅、结构工整、但实际上经不起推敲的内容。正因如此论文倾向于把那些依赖人类主观感受、又无法转换成自动化检查的进步证据排除在合法性测试之外或者至少加以严格限制。我自己的经验是任何由模型自己声称的改善都必须附上一个人类或程序可以重新独立运行的检查流程。如果这个流程不存在那这个进步在合法性测试里就只能算待定。这不是不信任模型而是审计的第一原则不能既当运动员又当裁判。4. 想动手验证这套框架从最小递归改进循环开始4.1 一个最小化的递归循环实现思路论文没有给出可以直接跑起来的代码这一点要明确。但它的概念框架其实非常适合改造成一个最小实验容器。我基于自己的理解写过一个非常简化的验证循环结构如下def recursive_improve_loop( baseline_model, task, fixed_validation_set, max_rounds10, significance_threshold0.05 ): best_model baseline_model best_score evaluate(baseline_model, task, fixed_validation_set) for round_idx in range(max_rounds): # 1. 上游提议让当前模型提出改进方案 proposal best_model.propose_improvement(task) # 2. 下游训练用提议方案训出一个候选模型 candidate_model train_with_proposal(best_model, proposal) # 3. 固定验证集上评估 candidate_score evaluate(candidate_model, task, fixed_validation_set) # 4. 统计检验只有显著提升才接受 ci_low, ci_high bootstrap_confidence_interval( candidate_score, fixed_validation_set ) if ci_low best_score significance_threshold: best_model candidate_model best_score candidate_score log_improvement(round_idx, proposal, ci_low, ci_high) else: log_rejection(round_idx, proposal, candidate_score) return best_model这段代码当然简陋但它捕捉了论文框架的骨架上游提议、下游执行、固定验证集检验、统计显著性门槛。我强烈建议任何想复现类似思路的人都自己动手实现一遍这个循环因为你会发现真正的难点根本不在代码而在工程环境验证集怎么隔离训练过程怎么保持可复现模型分布漂移怎么归因。4.2 信号选择内生信号、外生信号与全视野评估在论文对验证信号的讨论中我体会到三个层次的区分也对应着三种不同强度的验证方式内生信号任务自身的评估分数。比如数学题的准确率、代码运行通过率。它的优点是容易获取缺点是容易被单一分布绑架。外生信号跨任务的泛化表现。比如一个在数学推理上做了自我改进的模型在代码逻辑、法律条文理解等无关任务上的表现是否也提升了。外生信号是检验能力是否真正泛化的重要手段。全视野评估field-level evaluation在整个数据生态上的综合评估。它的作用相当于审计中的全盘复查而不只是抽查某几笔账。面对谷仓问题时全视野评估是让不同系统的进步回到同一把尺子的办法。一个常见的误区是只盯内生信号做递归优化。我在早期做模型自训练的时候就犯过这个错误盯着单任务准确率一路递归调最后模型在目标任务上非常好在邻近任务上却明显退步。论文把外生信号和全视野评估纳入讨论本质上是要求你做能力增长的体检而不是只看某一项指标的好看数字。4.3 工程落地的几个实际坑如果你打算在自己项目里尝试这个框架有几个坑我先帮你排一下验证集污染递归改进中最容易翻车的就是数据污染。上游模型生成的数据中可能包含与验证集高度重合的内容尤其是在验证集样本本来就存在于网络语料中时。我的建议是对每一批生成数据做一次embedding层面的去重把所有与验证集相似度超过阈值的样本直接丢弃。置信区间计算小模型或小数据量下单次评估结果方差很大。只比较均值几乎一定会做出错误判断。我用bootstrap抽样估计置信区间只有在置信区间完全不重叠时才接受一次改进。代价是速度慢了一些但换来的判断可靠性值得。单次只改一个变量递归改进思路很诱人但如果你同时改数据、改目标函数、改评估方式一旦出现变化你根本没法归因。我在实验中坚持每一轮只允许上游模型提交一个维度的改动这让每一轮改进的记录都像一张干干净净的实验报告。5. 开放问题为什么最后一代AI可能迟迟不来5.1 花言巧语模型的威胁验证者被说服而不是被证实论文讨论里有一个让我后背发凉的概念就是花言巧语模型smooth-talker model。它指的是那些非常擅长生成看起来合理、读起来流畅、但经不起严格验证内容的模型。如果递归链条里的验证环节依赖人类审阅者的时间和注意力那么攻击面就出现了一个花言巧语的上游模型可以生成海量看似正确的报告、证明、数据分析人类验证者可能只有有限的精力去抽查于是大量未经验证的进步被放进了链条。这其实是可验证性框架最脆弱的地方。你建立的审计流程再严谨如果审计员可以被无穷无尽的看似有效的提交淹没审计质量就会下降。论文对这个问题的态度是必须尽可能把验证环节自动化用形式化工具、可执行测试、可重复实验去替代人类的主观审阅。越是往后递归人类越应该在协议层把关而不是在内容层逐字检查。5.2 不可验证能力的缺口创造力、审美与抽象权衡另一个开放问题是有些被人类视作关键的能力在目前的框架下几乎找不到可信的验证信号。论文自己也承认像科学品味、审美判断、长期目标权衡这类高度抽象的能力很难被塞进固定验证集统计显著提升的框架里。这个问题不能靠发明一个打分器来糊弄。如果你硬要把不可验证目标转换成可量化指标比如把回答有创意定义成与参考答案的编辑距离小那这种验证信号本身就是伪造的。SCE框架能够覆盖的是一大类具备清晰正确标准的任务而对那些无法形式化验证的能力它目前只能保持克制。这也是我认为这篇论文最诚实的地方——它没有宣称自己解决了所有自我改进的问题而是划出了一条线可验证的进步可以递归不可验证的进步需要人类协议介入。5.3 人类协议要审查的不是输出而是链条本身论文最后给人留下的思考是人类在递归自我改进中的角色不应该是在每一环输出上做质检员而应该是在关键节点上审查是否继续递归。就像审计师不会重算公司每一笔账而是审流程、审内控人类面对AI递归改进时真正要决定的是是否继续这条递归链是否需要更换验证器是否需要重新定义任务是否需要中止迭代这些决定没法自动化因为它们的背后是价值判断——什么方向的进步是值得追求的什么风险是不可接受的。这也是为什么论文强调人类协议human protocol的存在。递归自我改进如果有一天真的实现它最需要的可能不是更强的验证器而是一套能够在适当时刻说不的制度性流程。写在最后读这篇论文给我带来的最大变化是面对自我改进这个说法时不再轻易被demo打动。现在看到任何号称模型自己改自己的项目我都会先问三个问题改进信号可验证吗验证集够干净吗改进能复制到分布外吗这三个问题帮我省掉了很多无效的兴奋和无效的加班。最后再分享一个小实践给所有递归式的实验建立审计日志。不要只记录最终指标要把每一轮的输入数据版本、验证集版本、模型权重版本、提议内容、置信区间、决策结果全部记录在案。这个方法听起来麻烦但它才是复现和研究递归自我改进的基石。否则当模型真的开始自己改进自己时你连它上一轮改了什么都不知道那才是真正让人头皮发麻的时刻。