Self-Improvement Without the Science Fiction

摆脱科幻小说的自我改进——梯度流

摆脱科幻小说的自我改进

作者： Ben Lorica 2026年9月9日 2026年8月17日

分类： 未分类

.meta-info

.post-thumbnail

几周前我写过关于部署后持续学习的AI系统，而不是将每次交互视为全新开始。这引发了一些读者询问递归自我改进（RSI）。这种联系确实存在，但我觉得有必要区分三个概念。持续学习探讨的是经验是否能让系统下次表现更好。有限的自我改进更进一步，允许系统将经验转化为经过验证的持久性变更。RSI是更强的主张，即系统改进了最初生成这些改进的流程本身。这些并非阶梯上的步骤，系统可以单独实现其中任意一项而无需其他。

这封通讯由读者资助，而非广告。考虑成为付费支持者 🙏

RSI在前沿AI实验室中备受关注，因为如果它有效，可能会加速未来模型的开发。但大多数AI团队并未训练前沿模型，他们为何关心？因为一些实用工具将在全面实现RSI之前就已出现。一个能从生产故障中学习、提出自身应用堆栈变更建议、测试并保留有效方案的系统，将改变AI应用的构建和维护方式。短期来看，重点不在于无限制的自我优化，而在于自动化当前手动执行的改进流程部分。

##### 力量源于套件

对大多数应用团队而言，最有趣的并非模型权重本身。而是围绕模型的一切：提示、上下文、记忆、工具、路由、子代理和工作流。这种外围软件通常被称为套件。与前沿模型不同，套件是团队实际拥有的部分，也更容易修改、测试和回滚。一项实验在不触碰模型的情况下，将模型通过率从40%提升至62%。另一项发现，重新组织代理间的信息交换方式，可在减少多达60%推理成本的同时提升效果。

这让我想起我之前提到的观点：团队应抵制通过寻找更新或更大的模型来解决每个性能问题的冲动。通常，更好的投资是改进模型周围的系统。生产日志可以揭示反复出现的故障，代理可以逐步帮助诊断问题应归因于记忆、指令、工具使用、路由还是工作流设计。我建议从小幅调整入手，而非允许全面重写。更新记忆或调整路由比让代理重新设计整个运行环境更容易理解和回滚。

##### 为何循环可能欺骗你

生成候选改进方案正变得容易且廉价。判断其是否真正更好却要困难得多。在企业应用中，最容易衡量的指标通常并非业务真正关心的内容。关闭更多支持工单不一定意味着客户更满意。增加更多销售活动不一定意味着收入增长。一个自我改进循环可能非常擅长优化代理指标，而真正的目标几乎毫无进展。这使得评估成为产品架构的一部分，而非事后附加的组件。

给予循环更多自主权时，就越需要将某些评估置于其影响范围之外。一项实验发现，自我评估与现实之间存在巨大差距。系统自我评价显示自身在持续改进，但独立测试却表明许多系统并未实现进步。在另一项实验中，评分提升是因为代理学会了规避幻觉检测器的标记，而非真正减少了幻觉行为。这里并不需要任何神秘机制，这不过是普通指标博弈，只是使用了更高效的优化器。我会保留受保护的测试，每当生产环境暴露出新故障时就扩展回归测试套件，并确保回滚操作易于执行。

##### 自我改进首先奏效的领域

早期最有效的改进目标具有一个简单特性：环境可以明确告知系统变更是否产生了帮助。代码要么能编译，要么不能；测试要么通过，要么失败；游戏有明确的得分；芯片设计有仿真器和工程约束。这些环境允许系统尝试多种变更并获得相对较快的反馈。开放性知识工作更具挑战性，因为"更好"的判断可能需要耗费时间、主观判断或数月后才能显现。还存在另一个限制：更优质的提示词和工作流可以帮助模型更高效利用已有能力，但无法赋予其本不具备的能力。

对于生产系统，我会将每项拟议的改进视为一次软件发布。生成候选方案后，独立测试其效果，仅在通过测试时才推广使用，保留旧版本以备回退，并在影响重大时要求人工审批。某些内容应始终保留在不可编辑的层级，包括权限设置、安全边界、支出限制以及决定哪些内容进入生产环境的控制机制。随着机器接管更多实验工作，人类工作将转向更高层次：选择目标、设计评估环境以及判断哪些风险可被接受。

##### 递归机制生效前经济性可能更重要

自我改进的首要收益将是更便宜的AI，而非更智能的AI。一些最显著的案例涉及更高效的框架降低了推理成本，或更小的专用模型在特定狭窄工作流中超越了大型通用模型。一旦某个任务被重复足够多次且结果可衡量，直接针对该任务进行优化可能比持续购买通用能力更具吸引力。改进循环本身也存在成本：分析追踪数据、生成替代方案、运行评估都需要计算资源，而大多数提议的变更最终都会被丢弃。正确的比较应是这种实验成本与它所替代的工程人力、推理开销和重复失败之间的权衡。

更有趣的长期资产是循环积累的历史数据。生产追踪数据将不再只是调试废料，而是下一版本的原始素材。失败案例会转化为回归测试，成功策略会成为可复用的技能，被拒绝的变更会教会系统哪些尝试应该避免。这些都不需要完全实现递归自我改进。实际应用更接近现代软件，只是附加了自动化改进流水线。不必纠结递归自我改进何时到来，关键问题是：在第500天时，你的应用是否因为前1天到第500天之间经历的一切而真正变得更好？