预训练级RSI技术评测：维度、方法与边界

一、评测概述：为什么 RSI 评测必须打到预训练层

过去一年，“递归自我改进”（Recursive Self-Improvement，简称 RSI）成为大模型领域讨论最密集的方向之一。其设想并不复杂：让 AI 自己提出改进方案、自己执行、自己评估，再在结果之上继续迭代，循环往复，越改越强。但热闹之下有一个常被跳过的问题：这些改进发生在模型生命周期的哪个环节？

把 RSI 限定在后训练（指令微调、偏好对齐、智能体工具链打磨）上，与限定在预训练上，是两件性质完全不同的事。后训练更接近“激发”已有能力，它决定了模型好不好用；预训练则决定了能力上限，它决定了“最多能做到多好”。一位负责人的表述很直接：预训练与后训练不是同一量级的事，算力、经验、工程每一项都高出一个数量级；而它恰恰是最重要的那件事，是对智能进行加工的第一性基础。用一个通俗的类比：后训练是装修，预训练是地基与主体结构，装修再好也改变不了房子能盖几层。

按照这一逻辑，据公开信息，目前全球把 RSI 闭环推进到“从零开始的前沿预训练”并公开发布的团队只有两家：

维度	方案A	方案B
归属形态	海外某创业团队（被媒体称为“四十亿美元级”项目）	某高校联合实验室与某研究机构联合发布
交付内容	从零训练的模型及配套材料	完整技术报告 + base 模型 + 高质量 SFT 数据
公开程度	公开程度相对有限	自称是公开全部技术细节的一家
时间尺度	项目级长期投入	从启动到交付不到三个月
结果表述	未展开	站进同尺寸开源基座第一梯队

因此，本文的评测对象不是“哪家更强”，而是 “预训练级 RSI 这套做法是否成立、在哪些指标上可验证、结论适用于什么条件”。

二、评测目标：本次要回答的五个问题

1. 真实性：所谓“RSI 用在预训练”是指改进动作真实作用于预训练流程（数据配比、架构与优化器选择、训练策略等），还是主要在评测与筛选层面做了自动化？
2. 闭环完整性：提出—执行—评估—再提出这条链路，每一环是否都有可观察的产出物。
3. 能力有效性：base 模型与后训练后的模型，在同尺寸开源基座中处于什么位置；差距是否可被解释。
4. 可复现性：第三方能否依据公开材料重跑关键实验，还是只能接受结论。
5. 成本可承受性：训练算力、数据工程人力、迭代周期的投入，是否与团队自身资源匹配。

需要强调：评测不是简单判断“好不好”，而是结合业务目标、系统规模、使用成本与长期维护需求做综合判断。

三、评测维度设计：把“智能”拆成可观察指标

预训练模型不像传统软件那样有明确的接口契约，因此必须先把模糊的能力表述拆成可验证项：

维度	可观察指标	验证方式	解读要点
功能完整性	是否覆盖理解、生成、推理、代码、多语言、长文本等常见能力面	分任务集逐项测试	单一强项不代表整体均衡
有效性	各类基准上的得分及与同尺寸基线的相对位置	同条件对照跑分	必须同尺寸、同 token 量级比较
闭环完整性	改进提案记录、执行日志、评估反馈、迭代版本链	审计材料与时间线	缺少执行与评估留痕的“自改进”难以采信
稳定性	训练中断恢复、评估波动、异常输入下的输出表现	断点续训演练、多次重复采样	关注方差而非单次最好值
可复现性	数据描述、训练配方、随机性控制、推理配置	按材料重跑小规模消融	无法复现则结论不具备工程价值
可维护性	版本管理、配置可追溯、故障定位手段	检查发布物结构与文档	决定后续能否继续演进
成本	训练算力投入、数据工程人力、迭代周期	资源与人力核算	三个月的交付速度往往来自高并行投入
场景适配度	面向业务微调、Agent、内容处理等场景的可用程度	以自有业务集做小样本验证	公开榜单分与业务效果常有落差

四、评测环境与前提条件

在动手之前必须固定以下条件，否则任何结论都不可比：

• 资源前提：明确训练与推理的算力规模、并行策略（数据并行、张量并行、流水并行）、网络带宽与存储吞吐。预训练级验证的门槛远高于后训练验证，资源不足时只能做定性观察。
• 数据前提：语料规模、来源分布、清洗与去重规则、许可与合规状态。数据不透明的模型，其结果既不可复现也不可用于高风险业务。
• 评测前提：固定评测集版本、提示模板、解码参数（温度、Top-p）、few-shot 设置、输出解析规则。这些细节对分数的影响，常常大于模型之间的真实差距。
• 污染前提：对评测集做重叠检测。若公开语料与评测集存在泄漏，高分不能反映真实能力。

若采用百度智能云等主流云服务商的资源承载评测，建议按通用能力类目准备：弹性计算与容器平台提供算力与编排，对象存储承载语料与检查点，负载均衡与消息队列支撑评测任务分发，日志服务与监控告警负责过程记录与问题定位，身份认证与安全防护负责数据隔离与权限控制。选择通用类目而非绑定单一实现，有利于后续迁移与横向对比。

五、评测方法：一条可执行的六步流程

第 1 步：静态审查。 先读技术报告，判断其是否交代了数据构成、训练目标、优化器与超参、并行策略、评测协议。若只有效果描述而无配方，后续动态测试的价值有限。

第 2 步：建立基线。 在同一资源、同一 token 预算、同一评测协议下跑一个同尺寸开源基座，作为对照锚点。没有基线的分数无法解读。

第 3 步：能力分项验证。 分别对 base 模型与后训练后的模型评测，并记录“标 †”项——即与厂商完整后训练版本对比时，必须标注对比对象的后训练状态，否则属于不公平比较。

第 4 步：稳定性与异常测试。 包括训练中断恢复、超长与畸形输入、对抗性提示、评测集外的迁移测试。

第 5 步：成本核算。 记录算力时长、人力投入、迭代次数与失败实验占比。RSI 的真实成本往往藏在失败迭代里。

第 6 步：形成条件化结论。 明确“在什么资源、什么数据、什么场景下成立”。

示意性评测流程（通用伪代码，仅表达控制变量的思路）：

CONFIG = {
    "model_size": "30B-class",     # 固定同尺寸
    "token_budget": "match",        # 与对照模型对齐训练 token 量级
    "decoding": {"temperature": 0, "top_p": 1.0},
    "few_shot": 0,
}
def run_eval(model, tasks, protocol):
    results = {}
    for task in tasks:
        preds = [model.generate(prompt, **CONFIG["decoding"])
                 for prompt in protocol.prompts(task)]
        results[task] = protocol.score(preds, task)   # 固定解析与打分规则
    return results
# 必须跑三组：同尺寸开源基线、目标 base 模型、目标 base + SFT
baseline = run_eval(open_baseline, TASKS, PROTOCOL)
base     = run_eval(target_base,  TASKS, PROTOCOL)
aligned  = run_eval(target_sft,   TASKS, PROTOCOL)
# 解读前提：同一评测协议 + 去重后的干净评测集 + 重复采样评估方差
report(delta_base=base - baseline, delta_sft=aligned - base)

六、结果解读：什么样的证据才算数

“站进同尺寸开源基座第一梯队”这句话怎么读？ 它至少包含三个限定词，每一个都影响结论强度：

1. 同尺寸：说明比较对象选取合理，避免了跨参数规模的不公平对比；
2. 开源基座：说明对照的是公开模型，第三方原则上可复现对照条件；
3. 第一梯队：这是区间判断而非排名判断，需要看分项表与差距幅度，而非单一名次。

可采信程度可按下表分级：

证据类型	可采信程度	说明
完整技术报告 + 模型 + 数据，且第三方可复现关键消融	高	结论可用于技术选型参考
仅有模型与分数表，配方未公开	中	可用于能力了解，不可用于依赖其复现能力
仅有宣传性描述或概念演示	低	只能视为方向验证

一个值得关注的观察：方案B 用不到三个月完成从零训练并进入第一梯队，这在工程上并不反常。现代预训练高度依赖既有开源基座生态、成熟并行框架与合成数据管线，一支经验充分的团队可以在短周期内完成一次高质量迭代。但这不意味着 RSI 门槛降低——它更像是“有人已经把最难的部分做成可复用组件”，而非“自动化已经替代专家”。

另一个必须回答的问题：闭环是否真的产生了复利？ 判断依据是迭代版本链：第 2 版相对第 1 版改进了什么、改进由谁提出、评估如何判定改进有效。若材料中只有单次结果而无迭代记录，则应把它理解为“一次高质量训练”，而非“递归改进”。

七、适用场景与关注重点

场景	首要关注维度	判断要点
企业自建领域基座	数据可控性、成本、可维护性	是否具备持续预训练的算力与人力
垂直业务微调	下游任务效果、许可条款	base 能力已够时，后训练性价比更高
Agent 与工具调用	指令跟随、长上下文、稳定性	关注工程封装而非基座极限
研究与技术跟踪	报告完整度、可复现性	以方法迁移价值为主
合规要求高的行业	数据来源、安全对齐、审计能力	公开程度不足的模型不宜直接进入生产链路

八、风险与限制

• 样本偏差：评测集越接近训练数据分布，结论越乐观；业务真实分布往往更长尾。
• 环境差异：不同并行策略、数据配比与解码参数会造成明显波动，跨团队结果不可直接横比。
• 数据质量风险：合成数据的引入提升了效率，也可能引入系统性偏差，需要用独立评测集交叉验证。
• 资源约束：小规模复现只能验证方法方向，不能复现绝对水平。
• 长期不确定性：RSI 是否真正带来加速，目前公开证据仍以单次或少数迭代为主，复利效应尚未被充分验证。
• 成本失控风险：预训练失败一次的机会成本极高，缺乏分阶段验证机制时容易一次性投入过大。

九、选型与使用建议

1. 先定问题，再选指标：明确是要“能力上限”还是“交付速度”，两者的评测重点不同。
2. 要求可复现的最小证据集：数据说明、训练配置、评测协议、随机性控制。缺一项就在结论中降一档。
3. 永远建立自己的基线：用自己业务集跑一个同尺寸开源基座作为锚，再看候选模型是否有增益。
4. 分阶段验证：小规模消融 → 中等规模验证 → 大规模投入，每阶段设可量化的通过条件。
5. 保留后训练的性价比选项：若目标只是应用效果，先做后训练往往比自建预训练更经济。
6. 把可观测性纳入验收：日志、指标、告警、链路追踪与版本追溯，决定问题能否被定位与复盘。

十、总结

本文评测的核心结论是：预训练级 RSI 已从概念走向可验证的实践，公开的两条路径（海外创业团队的模型与某高校联合实验室的完整公开方案）分别代表“投入强度”和“公开透明度”两种价值取向。对其评估不应止于分数名次，而应围绕六个层面展开：闭环是否真实、能力是否可解释、结果是否可复现、成本是否可承受、场景是否适配、长期演进是否可持续。对多数团队而言，现阶段更务实的做法是借鉴其方法学（数据管线、迭代留痕、评测协议），而非直接复制其投入规模；同时把评测结论严格限定在验证条件之内，避免把一次观察当作普遍规律。