1. 从“RSI”这个词说起它到底指什么先把话说在前头RSI 这三个字母在不同圈子里指向完全不同的东西。做交易的朋友第一反应是相对强弱指标做工程的朋友可能想到的是信号完整性但最近一段时间在技术社区里被反复讨论的 RSI指的是Recursive Self-Improvement递归自我改进。简单讲就是一个系统能够修改自己、提升自己然后用提升后的版本再去修改自己形成一轮又一轮的迭代。这个概念之所以重新热起来是因为围绕它出现了几个很具体的词Headroom-Closed Index、Data-RSI、Harness-RSI。这几个词不是空泛的哲学讨论而是试图把“自我改进”这件事拆成可以量化、可以动手写的面。我花了不少时间把这几条线索捋了一遍越捋越觉得有意思的地方不在于“系统能不能自己变强”而在于我们到底该往哪个方向写、写什么、怎么判断写对了。这篇文章适合两类人看一类是对递归自我改进这个概念好奇、想知道它到底落地在哪些具体环节上的读者另一类是真的想动手做点实验、但不知道从哪下手的人。我会把三个可写面、五条定律以及那个几乎没人认真做过的对照实验一条一条拆开讲。不堆术语尽量说人话把我自己踩过的坑和想明白的地方都放进去。2. 三个可写面递归自我改进到底能改哪里2.1 为什么是“三个面”而不是一个很多人一听到自我改进脑子里浮现的画面是“系统改自己的代码”。这个画面不能说错但它太窄了。真正拆开来看一个系统能对自己动手的地方至少有三个层面而且这三个层面的可写性、风险、见效速度完全不一样。把它们混在一起谈就会陷入“到底能不能自我改进”这种没有答案的争论里。我倾向于把这三个面分别叫做数据面、工具面、结构面。对应到热词里Data-RSI 说的是数据面Harness-RSI 说的是工具面或者说“套具面”而 Headroom-Closed Index 更像是在衡量结构面还剩多少空间。这三个面不是并列关系而是有先后、有依赖的。搞清楚它们的顺序比单独研究任何一个都重要。提示不要一上来就想着改结构。结构面是最难写、最难验证、也最容易把前面成果全部推翻的一层。先从数据和工具入手是更稳的路径。2.2 数据面Data-RSI 改的是“喂进去的东西”数据面是最容易被低估的一个面。很多人觉得数据就是数据改数据不算自我改进。但你仔细想一个系统如果能够自己筛选、自己生成、自己标注训练或推理时用的数据那它其实已经在改变自己的输入分布了而输入分布一变输出行为就会跟着变。Data-RSI 的核心动作可以拆成三步筛选、生成、回灌。筛选是从已有数据里挑出对当前目标最有价值的部分生成是让系统自己造出新的样本回灌是把这些新样本重新送进流程里。这三步里筛选最安全生成风险中等回灌最容易出问题因为一旦回灌的数据有偏整个系统会沿着偏的方向越走越远。我实测下来数据面最实用的一个技巧是给生成的数据打上来源标记。也就是说系统自己造出来的每一条数据都要能追溯到它是哪一轮、基于什么条件生成的。这样做的好处是当你发现某一轮之后效果突然变差可以快速定位是不是某批生成数据的问题。没有这个标记排查起来基本靠猜。2.3 工具面Harness-RSI 改的是“怎么用工具”Harness 这个词直译是“马具、套具”放在这里指的是系统调用外部能力的那一层封装。Harness-RSI 说的就是系统能够修改自己使用工具的方式。这一层比数据面更接近“行为”因为它改的不是输入而是系统跟外界交互的接口和策略。举个具体的例子。假设一个系统需要调用搜索、计算、读写文件这几类能力。工具面能改的东西包括调用顺序、参数怎么填、失败之后怎么重试、多个工具的结果怎么合并。这些看起来都是工程细节但它们对最终效果的影响非常大。我见过太多情况模型本身没问题就是工具调用策略太粗糙导致结果一塌糊涂。工具面之所以叫“可写面”是因为这些策略通常是以配置或者轻量代码的形式存在的改起来成本低、见效快。但它也有个陷阱过度拟合到某几个任务上。你针对一类任务把工具调用策略调得很顺换一类任务可能立刻崩掉。所以工具面的改动一定要配一套跨任务的验证集不能只看单点效果。2.4 结构面Headroom-Closed Index 在衡量什么结构面是最深的一层改的是系统自身的组织方式比如模块怎么划分、信息怎么流动、决策怎么分层。这一层最难动因为牵一发动全身。Headroom-Closed Index 这个指标我的理解是它在衡量结构面还剩多少可改空间。Headroom 是“余量、空间”的意思Closed 是“关闭”。合起来这个指数越高说明结构上可动的余地越小已经接近一个封闭状态指数越低说明还有比较大的调整空间。这个思路其实很聪明因为结构改进不像数据改进那样可以无限做它是有天花板的。当结构已经高度优化再改就是负收益。我自己在梳理这个指数的时候用了一个很土的办法把系统里所有“可以替换但暂时没替换”的组件列出来数一数有多少个再评估每个替换的预期收益和风险。这个列表的长度和平均收益大致就能反映 Headroom 的状态。列表越来越短、收益越来越低就说明结构面在往 Closed 走。这个方法不精确但胜在直观适合快速判断当前该不该动结构。3. 五条定律从经验里提炼出来的硬约束3.1 定律一改进速度受限于验证速度这是我体会最深的一条。很多人以为自我改进的瓶颈在于“能不能改”其实真正的瓶颈在于“改完能不能快速知道改对了没有”。一个系统如果每改一次要花很久才能验证那它的迭代速度就被验证卡死了改得再快也没用。这条定律的实践含义是在动手改任何东西之前先把验证通道建好。验证通道包括自动化测试、对比基准、回归检查。我见过太多项目改进逻辑写得飞快结果验证全靠人肉看最后积累了一堆不知道好坏的改动整个系统变成一团乱麻。验证速度上不去改进速度就是假的。3.2 定律二可写面之间存在依赖顺序数据面、工具面、结构面不是随便挑一个就能改的。它们之间有依赖数据面的改动会影响工具面的效果评估工具面的改动会暴露结构面的瓶颈结构面的改动又会反过来要求数据面重新适配。这个顺序如果搞反了就会反复返工。我的建议是按数据、工具、结构的顺序推进每一层稳定之后再动下一层。这不是说结构面不能碰而是说在没有把数据和工具理顺之前碰结构大概率是在给自己挖坑。结构改动一旦发生前面所有的验证基准可能都要重做成本极高。3.3 定律三每一层都有收益递减这条定律跟 Headroom-Closed Index 是呼应的。任何一层的改进前期收益大后期收益小最后趋近于零。数据面可能改几十轮就到瓶颈工具面可能改十几轮结构面可能改几轮就到头。认识到这一点就不会在某一层上死磕。实际操作里判断是否到瓶颈有个简单信号连续几轮改动的效果提升都低于噪声水平。这时候就该考虑换一层而不是继续在同一层上加码。很多人舍不得换是因为前面投入太多但沉没成本不该影响判断。3.4 定律四自我改进会放大原有偏差一个系统如果本身有偏差自我改进不会自动修正它反而会放大它。因为改进的方向是由系统自己判断的而判断标准里就带着原有的偏差。这一点在数据面上尤其明显系统自己生成的数据会倾向于它已经擅长的方向久而久之能力分布会越来越窄。对抗这条定律的办法是引入外部锚点。外部锚点可以是人工标注的固定测试集可以是来自不同来源的对照数据也可以是一套不随系统变化的硬指标。没有外部锚点自我改进就是在一个封闭回路里打转越转越偏。3.5 定律五改进的收益必须能被人理解这条听起来有点虚但非常实际。如果一个系统的自我改进过程完全不可解释那么即使效果变好了也没人敢继续用它因为不知道什么时候会出问题。可理解性不是锦上添花而是自我改进能否持续的前提。我的做法是强制记录每一轮改动的动机、动作和结果。动机是为什么改动作是具体改了什么结果是改完之后指标怎么变。这三样东西记下来哪怕当时看不懂事后回看也能拼出脉络。不记录的话几轮之后连自己改过什么都忘了。4. 那个没人做的对照实验为什么它重要4.1 对照实验缺的是什么聊到自我改进几乎所有人都在展示“改完之后变好了”。但很少有人做这样一个对照同样的系统在不做自我改进的情况下用同样的资源、同样的时间效果会怎样。这个对照看起来简单实际上极少有人认真做。缺这个对照的后果是我们无法区分“效果提升”到底来自自我改进还是来自单纯的时间投入、资源投入、或者随机波动。没有对照所有的改进声明都是悬空的。我自己在早期做实验时就吃过这个亏以为某个改动很关键后来做了对照才发现不做那个改动、只是多跑几轮效果也差不多。4.2 对照实验该怎么设计设计这个对照实验核心是控制变量。实验组做自我改进对照组不做但两组在初始状态、资源预算、运行时间、评估方式上必须完全一致。评估方式尤其重要必须用同一套外部锚点不能用系统自己生成的指标。具体操作上我建议至少跑三组一组完全不做改进一组只做数据面改进一组做数据面加工具面改进。这样不仅能看出自我改进有没有用还能看出哪一层的贡献最大。跑的时候要注意每组的随机种子要固定否则波动会掩盖真实差异。4.3 为什么大家不愿意做原因很现实对照实验不出彩。做自我改进的实验可以展示一条上升曲线很好看做对照实验往往得到的是一条平线或者差异很小写出来不吸引人。但从严谨性角度对照实验的价值远高于展示曲线。另一个原因是成本。对照实验意味着要额外跑一遍甚至几遍资源翻倍。在资源紧张的时候大家自然倾向于把资源投在“看起来有进展”的那一组上。但我觉得如果连对照都不做那些进展本身就不值得信。4.4 我建议的最小可行对照方案如果你资源有限做不了完整对照至少做一个最小可行版本选一个固定的任务集跑一次不做任何改进的基线记录指标然后跑一次做改进的版本记录指标。两次之间除了改进本身其他条件尽量保持一致。这个方案成本不高但能给你一个最基本的参照。我实测下来这个最小对照经常能揭示一些反直觉的结果。比如有一次我以为工具面改进贡献最大对照跑完发现数据面的贡献其实更稳定工具面的提升只在特定任务上出现。没有对照这个结论根本得不到。5. 把三个面、五条定律和对照实验串起来5.1 一个可落地的推进节奏把前面这些东西串起来我自己的推进节奏是这样的先建验证通道确保每次改动都能快速评估然后从数据面开始做筛选和生成配好来源标记数据面到瓶颈后转工具面调调用策略配跨任务验证集工具面稳定后再评估结构面用 Headroom-Closed Index 判断还有多少空间。整个过程里对照实验贯穿始终每一层改动都留一个不做改动的参照。这个节奏不是死的但顺序背后的逻辑是稳的先保证能验证再保证改得动最后才考虑改得深。跳过任何一步后面都会加倍还回来。5.2 常见误区速查误区表现正确做法一上来就改结构结构改完验证基准全废先数据、再工具、后结构不做对照效果提升无法归因至少跑一个最小对照只看单点效果换任务就崩配跨任务验证集不记录改动几轮后自己都忘了强制记录动机、动作、结果死磕一层收益早已递减还在加码连续低收益就换层5.3 我踩过的几个坑第一个坑是验证通道建得太晚。早期我急着改数据改了几轮之后才发现没有稳定的评估方式前面的改动全都没法比较只能重来。从那以后我养成了先建验证再动手的习惯。第二个坑是低估了偏差放大。有一轮系统自己生成的数据看起来质量不错回灌之后短期指标确实涨了但过了几轮发现能力分布明显变窄很多原本能处理的任务开始出错。后来加了外部锚点才慢慢拉回来。第三个坑是对照实验跑得太少。有段时间我连续做了好几轮改进每轮都感觉有提升但一直没做对照。后来补做对照才发现其中两轮的提升完全在噪声范围内等于白做。这个教训让我明白感觉有提升和真的有提升是两回事。6. 关于 Headroom-Closed Index 的一点补充6.1 它不是一个精确数字我得强调一下Headroom-Closed Index 不是一个能精确算出来的数字它更像一个判断框架。你用它来问自己当前这一层还有多少可改的地方改完之后预期收益还有多大。这个判断是定性的但足够指导决策。我自己的用法是把它分成三档开阔、收窄、接近封闭。开阔的时候大胆改收窄的时候谨慎改接近封闭的时候就别改了把精力放到别的层或者别的系统上。这个分档很粗但比拍脑袋强。6.2 什么时候该停判断该停的信号有几个连续几轮改动收益低于噪声、改动带来的风险开始超过收益、验证成本高到不划算、外部锚点显示能力分布开始收窄。这几个信号出现任何一个都该停下来重新评估而不是继续往前冲。停下来不是失败是止损。自我改进这件事最怕的不是改不动而是明明改不动了还在硬改把原本稳定的系统改坏。知道什么时候停比知道怎么改更重要。7. 最后分享几个实操上的小技巧第一个技巧是给每一轮改动编号并写一句话摘要。编号方便追溯一句话摘要方便快速回忆。我现在的记录格式是“第 N 轮改了 X预期 Y实测 Z”简单但够用。第二个技巧是对照实验的基线要定期重跑。系统在变基线也会变一次跑完的基线不能一直用。我一般每隔几轮就重跑一次基线确保参照系是新鲜的。第三个技巧是外部锚点要选得“笨”一点。太聪明的锚点容易跟系统一起漂移反而是那些简单、固定、不随系统变化的指标更可靠。宁可锚点粗糙也不要锚点跟着系统走。第四个技巧是别在资源紧张的时候做结构改动。结构改动需要充足的验证资源兜底资源不够的时候做结构改动等于在没有安全网的情况下走钢丝。等资源宽裕了再动结构稳得多。这几个技巧都不复杂但都是我在实际推进里一点点攒下来的。递归自我改进这件事听起来很玄拆开来看其实就是数据、工具、结构三个面加上验证、顺序、递减、偏差、可理解这五条约束再配一个大家都不太愿意做的对照实验。把这几样东西理顺比追任何新概念都实在。