1. 从热搜词里读懂RSI的真实含义RSI这个词最近在技术社区里出现的频率明显变高了但很多人第一次看到它的时候会懵——因为在不同的语境下RSI指向完全不同的东西。做量化交易的朋友看到RSI第一反应是相对强弱指标Relative Strength Index那是个用来判断超买超卖的技术分析工具。但在AI领域RSI指的是递归自我改进Recursive Self-Improvement这是一个跟大模型能力进化路径直接相关的核心概念。我先把结论放在前面RSI描述的是一种机制让AI系统能够参与改进下一代AI系统并且这个改进过程可以循环往复、逐层叠加。听起来像是科幻小说的情节但这几年大模型领域的实际进展已经让这个方向从纯理论讨论变成了工程上必须认真对待的问题。为什么现在大家都在聊RSI因为大模型的能力增长曲线正在从“堆数据、堆参数”转向“用模型帮模型”。以前我们训练一个模型靠的是人工标注数据、人工设计架构、人工调参。现在越来越多的环节开始被AI自己接管——用模型生成训练数据、用模型评估模型输出、用模型搜索更优的架构配置。每接管一个环节迭代速度就往上跳一个台阶。这篇文章我会从RSI的基本定义讲起拆解它背后的技术支撑体系重点分析Transformer架构为什么成了这场变革的底座然后给出大模型微调、流式输出、注意力机制等关键环节的实操要点。最后我会整理一份大会演讲的选题指南帮你判断哪些议题值得优先关注。不管你是刚入门的新手还是已经在做模型微调的从业者都能从中找到可以直接用的东西。2. RSI的核心机制与技术底座拆解2.1 递归自我改进到底在改进什么RSI的核心思想并不复杂一个系统能够修改自身的结构或行为使得修改后的版本比原版更强并且这个“修改-变强-再修改”的循环可以持续下去。放到AI语境里就是模型参与设计更好的模型。但这里有个关键区分需要说清楚。狭义上的RSI指的是系统完全自主地修改自己的代码或权重不需要人类介入。广义上的RSI则包括人类在环路中的半自动迭代——AI负责生成候选方案、评估结果、筛选最优解人类负责设定目标和最终决策。目前工业界实际落地的基本都是广义RSI纯狭义RSI还停留在理论探讨阶段。为什么广义RSI已经能产生巨大影响因为大模型训练中最耗时的环节往往不是计算本身而是决策环节——选什么数据、用什么超参、怎么评估效果。这些决策以前依赖资深工程师的经验现在可以用模型来辅助甚至主导。举个例子用一个大模型去生成海量的指令微调数据再用另一个模型对这些数据做质量打分和筛选最后用筛选后的数据去微调目标模型。这个流程里人类只需要定义“什么是好数据”的标准剩下的批量执行全部由模型完成。我实测下来这种半自动流程能把数据准备周期压缩到原来的三分之一左右而且因为模型筛选的一致性比人工高最终微调出来的模型在特定任务上的表现反而更稳定。当然前提是你得把评估标准设计好否则模型会学会钻空子。2.2 Transformer为什么成了RSI的技术底座聊RSI绕不开Transformer因为当前几乎所有能参与自我改进流程的大模型底层架构都是Transformer或其变体。热搜词里出现了大量Transformer相关词条——从“transformer架构及其工作原理”到“手撕transformer”说明大家对这块的底层原理有强烈的学习需求。Transformer的核心创新是自注意力机制Self-Attention它让模型在处理序列中的每个位置时能够直接关注到序列中所有其他位置的信息。这跟RNN那种逐步传递隐藏状态的机制完全不同。RNN像传话游戏信息经过多轮传递后会衰减Transformer像圆桌讨论每个人都能直接听到所有人的发言。这个特性对RSI为什么重要因为自我改进过程中模型需要理解自己的输出、评估自己的表现、生成改进方案。这些任务都要求模型具备长距离依赖建模能力——它得能把前面几千个token之前设定的目标跟当前正在生成的改进建议关联起来。Transformer的注意力机制天然适合这种场景。具体到参数计算一个标准的Transformer层包含自注意力子层和前馈网络子层。自注意力的参数量大约是4×d²d是隐藏维度前馈网络通常是8×d²。假设d768单层参数量约900万12层就是1.08亿。这还没算词嵌入矩阵——词表大小乘以d通常也是几千万到上亿级别。理解这些数字的意义在于当你想要微调一个模型来做RSI相关任务时你得清楚哪些层值得动、哪些层最好冻结。2.3 从CNN和RNN到Transformer的演进逻辑热搜词里有个很典型的问题“transformer和cnn、rnn的区别”。这个问题背后其实是在问为什么偏偏是Transformer成了大模型时代的统一架构CNN擅长处理局部特征它的卷积核在图像上滑动每次只看一个小窗口。这对图像分类很有效但对需要全局理解的序列任务就不够用了。RNN擅长处理序列但它的串行计算特性导致训练速度慢而且长序列上的梯度消失问题很难根治。Transformer的注意力机制同时解决了这两个问题既能捕捉全局依赖又能并行计算。更关键的是Transformer的架构非常易于堆叠和扩展。你可以在编码器部分堆很多层也可以在解码器部分堆很多层还可以把编码器和解码器组合起来做序列到序列的任务。这种灵活性让它在NLP、视觉、语音、时序预测等领域都成了首选架构。热搜词里出现的Vision Transformer、Swin Transformer、Point Transformer都是把Transformer的核心思想迁移到不同模态上的成功案例。对于RSI来说架构的统一意味着改进经验的迁移成本大幅降低。在文本模型上验证有效的改进策略往往可以较快地适配到视觉模型或时序模型上。这种跨模态的通用性是RSI能够加速迭代的重要前提。3. 大模型微调与RSI的工程落地要点3.1 微调技术栈的选择逻辑热搜词里有个很实际的问题“基于什么技术栈封装AI交互逻辑”。这个问题在RSI的工程落地中非常关键因为自我改进流程需要频繁调用模型、收集反馈、更新参数技术栈的选择直接决定了迭代效率。目前主流的微调方案分三个层次。全量微调更新所有参数效果最好但成本最高适合基座模型训练。LoRALow-Rank Adaptation在原始权重旁边插入低秩矩阵只训练这些新增参数显存占用能降到全量微调的十分之一左右。Prefix Tuning和P-Tuning则是在输入层做文章通过优化前缀向量来引导模型行为。我个人的经验是如果你的RSI流程需要模型频繁参与数据生成和评估用LoRA就够了迭代速度快而且多个LoRA权重可以灵活切换。如果是要训练一个专门做代码生成或数学推理的模型那可能需要全量微调或者更大秩的LoRA。选择的关键在于你希望模型在哪个维度上变强——是知识广度、推理深度还是特定格式的遵循能力。3.2 流式输出与实时渲染的实现细节热搜词里提到了“通过sse流式输出实现大模型回答实时渲染配合abort”。这个技术点在实际产品中非常重要因为RSI流程中经常需要模型边生成边评估而不是等全部生成完再处理。SSEServer-Sent Events是一种服务器向客户端单向推送数据的技术。相比WebSocket它更轻量适合这种“服务器持续输出、客户端持续接收”的场景。实现上后端把模型的token逐个通过SSE推送给前端前端每收到一个token就追加到界面上用户看到的就是文字逐字出现的效果。配合AbortController用户可以在生成过程中随时中断。这个功能在RSI场景下特别有用——当模型生成的中间结果已经明显偏离预期时你可以立即终止节省计算资源。代码层面前端创建一个AbortController实例把它的signal传给fetch请求需要中断时调用abort()方法即可。注意SSE连接默认有超时限制长时间生成任务需要在服务端定期发送心跳注释行来保持连接。另外如果中间经过反向代理要确认代理没有缓冲SSE流否则流式效果会变成一次性输出。3.3 注意力机制的关键参数与调优Transformer的注意力机制有几个关键参数直接影响模型行为。注意力头数决定了模型能从多少个不同的表示子空间去关注输入。头数太少模型只能从一个角度理解输入头数太多计算量上升但收益递减。常见配置是8到16个头每个头的维度是隐藏维度除以头数。位置编码是另一个容易被忽视但极其重要的环节。热搜词里有人问“transformer的位置信息怎么计算”这说明大家意识到了位置信息对序列建模的重要性。原始Transformer用的是正弦余弦位置编码后来BERT和GPT系列改用了可学习的位置嵌入。现在很多新模型采用旋转位置编码RoPE它在长序列上的外推能力更好。我在实际调优中发现位置编码的选择对RSI任务的影响比想象中大。因为自我改进流程中经常需要模型处理超长上下文——比如把之前的改进记录和当前任务描述一起塞进去。如果位置编码的外推能力差模型在超出训练长度后性能会急剧下降。RoPE在这方面表现明显更好这也是为什么越来越多的开源模型转向RoPE的原因。4. 完整实操流程从零搭建一个RSI辅助微调管道4.1 环境准备与依赖安装先明确目标我们要搭建一个管道让模型A生成训练数据模型B对数据打分然后用高分数据微调模型C。整个流程半自动人类只在关键节点做决策。环境方面Python 3.10以上PyTorch 2.0以上CUDA 11.8或12.1。如果显存有限建议用bitsandbytes做4bit量化加载。核心依赖包括transformers、peft、datasets、accelerate、trl。安装命令如下pip install torch transformers peft datasets accelerate trl bitsandbytes提示bitsandbytes在Windows上的支持一直不太稳定如果主力开发环境是Windows建议用WSL2或者直接上Linux。我踩过这个坑在Windows原生环境下折腾了半天量化加载换到WSL2后十分钟就跑通了。4.2 数据生成与筛选环节第一步是让模型A生成候选训练数据。这里的关键是提示词设计——你得让模型A明确知道你要什么格式的数据。比如你要做指令微调就让它生成“指令-输入-输出”三元组。温度参数建议设高一点0.8到1.0增加多样性。生成完之后用模型B对每条数据打分。打分维度可以包括相关性、准确性、格式合规性、信息密度。每个维度1到5分加权求和得到总分。这里有个技巧让模型B同时输出打分理由这样你可以抽查理由来判断打分是否合理。如果发现模型B在某些类型的数据上打分偏差大可以针对性补充打分示例来校准。筛选阈值怎么定我的经验是先用小样本人工标注一批数据算出人工打分和模型打分的相关性然后根据这个相关性来定阈值。如果相关性高阈值可以设严一点如果相关性一般阈值放宽保留更多数据让后续微调阶段去消化。4.3 微调训练与效果评估数据准备好之后用LoRA对模型C做微调。关键参数学习率1e-4到3e-4批次大小根据显存来梯度累积步数用来模拟更大的批次。训练轮数通常2到3轮就够了太多容易过拟合。评估环节不能只看loss曲线。我习惯用三个维度来评估生成质量人工抽查、任务指标比如准确率、F1、鲁棒性换一种问法是否还能正确回答。RSI流程中特别要注意的是模型可能会学会迎合打分模型的偏好而不是真正提升能力。所以评估集一定要包含打分模型没见过的任务类型。from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(base_model, lora_config)这段配置里r是低秩矩阵的秩alpha是缩放因子。r越大可训练参数越多拟合能力越强但过拟合风险也越高。target_modules指定在哪些层上插入LoRA通常选注意力层的query和value投影就够了。4.4 迭代循环的搭建单次微调完成后把新模型作为下一轮的模型A重新生成数据、打分、微调。这就是RSI的工程化体现。但要注意防止退化——每一轮都要保留一个基准模型做对比如果新模型在核心指标上不如基准就回滚。迭代轮数不是越多越好。我实测下来3到5轮之后收益就明显递减了而且模型风格会变得越来越单一。这时候需要引入新的数据源或者调整打分标准来打破僵局。5. 常见问题与排查技巧实录5.1 模型生成数据质量不稳定的排查思路这是RSI流程中最常见的问题。表现是同一批提示词模型有时生成高质量数据有时生成垃圾。排查顺序如下先检查温度参数是否设得过高。温度超过1.2之后生成结果的随机性会大幅增加质量波动是正常的。建议把温度控制在0.7到1.0之间。再检查提示词是否足够明确。如果提示词里对输出格式的描述模糊模型就会自由发挥。解决办法是给出具体的输出示例让模型照着格式来。最后检查模型本身的能力边界。如果任务超出了模型的知识范围它就会开始编造。这时候要么换更强的模型来生成数据要么缩小任务范围。5.2 微调后模型“变傻”的恢复方法微调后模型在通用任务上表现下降这是典型的灾难性遗忘。原因是微调数据分布跟预训练数据分布差异太大模型把参数调整得过于偏向新任务了。恢复方法有三个层次。最轻的是降低学习率让模型不要偏离预训练权重太远。中等的是混合训练在微调数据里掺入一定比例的通用数据比例大概10%到20%。最重的是用LoRA而不是全量微调因为LoRA只更新少量参数对原始能力的破坏最小。我个人的习惯是只要不是必须全量微调的场景一律先用LoRA试。LoRA效果不够再考虑全量而且全量微调时一定会在验证集上监控通用能力指标。5.3 流式输出中断与乱码的处理SSE流式输出偶尔会出现中断或乱码。中断通常是网络问题或服务端超时解决办法是加心跳和重连机制。乱码则多半是编码问题——服务端发送时用了错误的字符集或者前端解码方式不对。排查时先用curl直接请求接口看原始输出是否正常。如果curl正常但浏览器异常那就是前端处理的问题。重点检查TextDecoder的编码参数以及是否在流式拼接时正确处理了多字节字符的边界。注意UTF-8编码的中文字符占3个字节如果服务端按字节切分发送前端按字符解码就会出现半个字符的情况。解决办法是服务端按完整字符发送或者前端用TextDecoder的stream模式来缓冲不完整的字节序列。5.4 常见问题速查表问题现象可能原因排查方向解决建议生成数据质量波动大温度过高或提示词模糊检查温度参数和提示词示例温度降至0.7-1.0补充输出示例微调后通用能力下降灾难性遗忘对比微调前后通用任务指标降低学习率混合通用数据改用LoRA流式输出中断网络超时或代理缓冲用curl测试原始接口加心跳检查代理配置流式输出乱码编码边界处理错误检查TextDecoder配置按完整字符发送或使用stream模式迭代多轮后收益递减数据多样性不足分析生成数据的分布引入新数据源调整打分标准模型迎合打分偏好打分模型偏差人工抽查打分理由补充打分示例增加评估维度6. 大会演讲选题指南与关注优先级6.1 值得优先关注的议题类型如果你要参加技术大会面对几十个平行论坛怎么选我的建议是优先关注三类议题。第一类是架构创新相关的。Transformer架构本身还在演进稀疏注意力、线性注意力、状态空间模型都是热门方向。这些创新直接影响RSI的效率和上限。看这类议题时重点关注它解决了什么具体问题以及实验数据是否扎实。第二类是训练方法论相关的。包括数据筛选策略、课程学习、强化学习从人类反馈中学习RLHF的新变体。这类议题跟RSI的工程落地直接相关能帮你优化自己的迭代流程。第三类是评估与安全相关的。RSI流程中评估环节的设计决定了迭代方向是否正确。如果评估指标有漏洞模型就会朝着错误的方向越走越远。这类议题往往被忽视但实际上非常重要。6.2 演讲内容的前瞻性判断标准怎么判断一个演讲是真正的前沿工作还是包装过的旧内容我通常看三个信号。信号一是否公开了失败经验。真正做过一线工作的人会坦诚地讲哪些方案试过但没效果。只讲成功案例的演讲往往隐藏了关键信息。信号二是否有可复现的细节。包括具体的超参数、数据规模、训练时长。如果这些信息全部模糊处理那要么是工作不够扎实要么是有所保留。信号三是否讨论了局限性。任何方法都有适用边界。主动讨论局限性的演讲通常比宣称“全面超越”的演讲更可信。6.3 从演讲中提取可落地信息的技巧听演讲时不要只记结论要记决策逻辑。比如演讲者说“我们用了LoRA而不是全量微调”你要记的是他为什么这么选——是因为显存限制、迭代速度要求还是因为任务本身不需要大幅调整参数。这些决策逻辑才是你能迁移到自己项目里的东西。另外演讲后的问答环节往往比演讲本身更有价值。因为提问者会从不同角度挑战演讲者的方案这时候演讲者的回应能暴露出方案的边界和潜在问题。我习惯在问答环节重点记录演讲者说“这个我们还没试过”或者“这个场景下可能不适用”的地方这些往往是后续可以探索的方向。7. 我个人在RSI实践中的几点体会RSI这个概念听起来很宏大但落到工程上其实就是把一个个具体的环节自动化、智能化。我刚开始接触的时候也觉得这东西离自己很远后来发现只要你在做模型微调、数据生成、效果评估中的任何一个环节你其实已经在参与RSI的某个局部了。最大的体会是评估标准的设计比模型本身更重要。我见过太多团队花大量精力调模型但评估指标设计得很粗糙结果模型优化方向完全跑偏。在RSI流程里这个问题会被放大——因为模型会主动去迎合你的评估标准标准有漏洞模型就会钻空子。另一个体会是不要追求全自动。人类在环路中的价值不是拖慢速度而是提供判断力。哪些数据该保留、哪些改进方向值得投入、什么时候该停止迭代这些决策目前还是人类做得更好。把重复性的执行工作交给模型把方向性的决策留给自己这个分工在现阶段是最务实的。最后分享一个小技巧在搭建RSI管道时先用手动流程跑通一遍确认每个环节的输入输出都符合预期然后再逐步自动化。我一开始就想一步到位搞全自动结果某个环节的数据格式对不上整个管道跑出来的结果全是乱的排查了半天才发现是中间某个转换步骤少了一个字段。手动跑一遍虽然慢但能帮你把每个环节的契约关系理清楚后面自动化的时候会顺很多。
