从权重空间编程看递归自我改进的评测误区

一、先把概念拆开：权重空间编程不是“读心术”

所谓“权重空间编程”，可以理解为：不通过提示词、上下文拼接或外挂工具来改变模型行为，而是把模型权重本身当作可编辑对象，由优化器、搜索器或生成式模型提出一组权重补丁，再通过评测反馈决定是否接受。它与提示工程、常规微调、参数高效微调、神经架构搜索有交集，但关注点更集中：补丁改在哪里、改了多少、为什么改、改完是否可验证。

一个典型的受控流程大致如下：

目标 = 人类给出的任务说明与验收标准
基座 = 加载待改进模型
审计日志 = []
for 轮次 in 搜索预算:
    证据 = 在探针集上评测基座，定位失败模式
    补丁 = 根据目标与证据生成候选权重修改
    候选 = 将补丁应用到基座
    分数 = 在隔离评测集上评估候选
    if 接受准则(分数, 稳定性, 安全性):
        基座 = 候选
        审计日志.append(目标、证据、补丁、分数、回滚点)
return 基座, 审计日志

这个流程里真正决定性质的不是“是否自动生成补丁”，而是四个变量：目标由谁提出、评测由谁定义、接受准则由谁设定、循环能否持续且保留收益。如果目标、评测和验收标准都来自人类，系统只是把“定位缺陷—尝试修改—回归测试”执行得更快，那么它属于自动化优化，而不是递归自我改进。

二、分数跃升最先要问：修了哪个“短路”

一组公开实验之所以引发讨论，是因为少量参数修改带来了评测通过率的大幅提升：例如仅改动约万分之几的权重，就让某小参数模型在数学推理、小学算术和指令遵循类评测上明显上升。表面看，这像是在“理解另一个模型的脑回路”；但从工程归因角度看，首先要排除更朴素的解释：模型原本存在重复生成、无法终止、格式跑偏或指令解析短路等缺陷，补丁主要修复了这些缺陷，分数自然上升。

这类现象并不神秘。小参数模型对终止符、位置编码、注意力模式、输出格式和早期层特征非常敏感；一个很小的权重扰动，既可能破坏行为，也可能修复一个长期存在的“卡死点”。而许多评测集的通过率对“是否能停”“是否按格式输出”“是否重复最后一句”极其敏感。因此，看到分数从低位跃升，不能直接推出“模型读懂了另一个模型”，更不能推出“系统理解了改进目标”。

更严谨的做法是建立对照矩阵：

• 随机同量编辑：随机改动相同数量或相同比例的权重，观察分数变化，排除“随便扰动就涨”的可能。
• 只修终止行为：仅调整停止条件、解码策略或输出格式，看是否能获得大部分收益。
• 提示修复对照：在不改权重的情况下，用更明确的提示或少量示例修复同类缺陷。
• 常规微调对照：用同等数据与算力做常规监督微调，比较补丁的性价比与泛化性。
• 同预算搜索对照：固定搜索预算，比较不同补丁生成策略，而不是只展示最佳结果。
• 多随机种子与留出集：报告均值、方差和置信区间，避免单次评测的偶然性。
• 消融与最小补丁：逐步裁剪补丁，确认哪些参数真正贡献收益，哪些只是噪声。

如果“只修终止行为”或“提示修复”就能拿到大部分涨幅，那么更合理的结论是：系统擅长定位并修复一个具体工程缺陷，而不是掌握了跨模型的通用理解能力。公开日志越完整，这种归因越应该被认真执行；日志透明不等于结论自动成立。

三、为什么这还不是递归自我改进

递归自我改进通常需要几个门槛同时成立：系统能够自主提出改进目标，能够自主构造或更新评估标准，能够修改自身或后代系统，能够持续循环并保留收益，还要有安全约束与可回滚机制。少一个环节，能力性质就会变化。

可以用一个粗略的自动化层级来区分：

层级	特征	是否接近 RSI
L0	人类手工修改权重或参数	否
L1	系统自动提出补丁建议，人类筛选	否
L2	系统自动搜索补丁，人类给定目标与验收	通常否
L3	系统在人类给定目标下持续循环优化	仍不是完整 RSI
L4	系统自主生成目标、自评、持续改进并安全保留收益	接近完整 RSI

从公开描述看，实验更接近“人类给定具体目标与规则，系统自动执行搜索、生成补丁、跑评测”的层级。它把执行过程自动化了，而且做得相当漂亮，但目标来源、评测口径和接受标准仍由人定义。执行自动化不等于目标自主，优化闭环不等于自我改进闭环。这两者混为一谈，会让讨论迅速滑向科幻叙事。

四、评测陷阱：基准涨幅不是能力证明

权重空间编程最容易踩的坑，是把“单点基准涨幅”当作“通用能力提升”。需要警惕以下问题：

1. 评测集过拟合：补丁可能针对探针集或公开评测分布优化，换到分布外任务就退化。
2. 奖励黑客：系统可能学会迎合评测格式、绕过终止条件或输出评测偏好的模板，而非真正解决问题。
3. 能力漂移：修复一个任务的同时损害另一个任务，缺少全量回归就会漏掉副作用。
4. 可复现性不足：随机种子、评测版本、解码参数不同，结论可能不可复现。
5. 安全性缺失：权重补丁可能引入不可解释行为，若没有回滚与监控，上线风险很高。

建议把评测分成至少六层：功能修复验证、分布内回归、分布外泛化、跨任务保持、持续循环收益、安全与回滚测试。每一层都要记录版本、随机种子、评测集隔离情况和失败案例。对于“是否接近 RSI”的判断，尤其要关注持续循环后收益是否保留，而不是一次补丁带来的峰值。

五、工程落地：把权重补丁当作受控变更

无论研究还是生产，权重补丁都应当被当作一次受控的模型变更来管理。可行实践包括：补丁版本化与签名、离线复现环境、隔离评测集、影子流量、灰度发布、监控告警和快速回滚；同时保留每轮目标来源、提示记录、补丁差异、评测结果和失败样本。通用云平台中的对象存储可用于保存补丁与审计日志，日志服务可用于追踪变更链路，容器平台可用于复现实验环境，监控告警可用于上线后的行为漂移检测。

对外沟通也应分级：如果只是“人类指定目标下的自动补丁搜索”，就应明确称为自动化优化或受控模型修复；只有在目标生成、自评、持续循环和安全保留收益都可验证时，才适合讨论递归自我改进。把执行自动化包装成 RSI，既会误导投资判断，也会掩盖真正需要解决的安全与评测问题。

六、结论

权重空间编程有真实价值：它可能用于模型缺陷修复、能力注入、可解释性探索和自动化维护。但一组“改权重后分数大涨”的实验，并不能自动证明系统理解了目标，更不能证明它已经能改自己、评自己、持续变强。当前更可信的判断是：系统在人类给定目标下完成了高效的自动搜索与修复。RSI 的关键门槛仍然是自主目标、可验证自评、持续闭环和安全回滚。把这些边界说清楚，比追逐“AI 开始动脑子”的标题更重要。