Hy4 preview 的递归自我改进：模型真的在训练自己吗？
解释腾讯混元 Hy4 preview 发布稿中的递归自我改进、推理优化和 Codex 实验闭环。
腾讯混元在 Hy4 preview 发布稿里用了一个很容易引发误解的说法：模型参与了训练方法、数据策略、评估体系和底层算子的自动优化，形成了初步的递归自我改进闭环。这里的“自我改进”不应理解成模型脱离人类和基础设施自行升级，而应拆成一条可以检查的实验流水线。
先说结论
- 这里的“递归改进”是模型参与的实验流水线，不是脱离监督的自我升级。
- 必须冻结独立评测集，避免模型通过修改测试本身获得提升。
- 吞吐数字要和准确率、显存、尾延迟、随机种子及基线配置一起报告。
- 不可变日志和最小权限是实验结果的一部分，不是可有可无的运维细节。
闭环到底包含什么
发布稿描述的流程是：模型提出方案，运行实验，根据结果继续迭代；实验代码、日志和反馈进入下一轮探索。这个过程更接近一个由模型负责提出假设和协调工具的 researcher agent。真正决定结果的仍然是数据、评测、算力、权限和人类设定的目标。
腾讯还称 Hy4 preview 能管理多个 Codex Session，在小模型后训练任务中同时探索多个评测目标，并在 8 项评测上优于 Codex 独立探索。要判断这是否成立，至少需要知道基线配置、随机种子、预算、停止条件和每个目标的具体分数。
31.8% 吞吐提升应该怎么读
腾讯披露，Hy4 preview 自主定位推理系统瓶颈，并围绕算子融合、通信优化等方向多轮实验，端到端吞吐较基线提升 31.8%，且在不同上下文长度和并发度下都有收益。
这是一个有价值的系统工程结果，但它回答的是“在这套系统和基线上，优化是否有效”，不是“模型可以无监督优化任何推理基础设施”。复现时要锁定硬件、编译器、批大小、上下文长度和测量窗口，同时报告准确率、显存和尾延迟，避免只挑吞吐最高的一组数字。
如何建立可信的实验日志
每轮实验都应记录假设、改动文件、依赖版本、输入数据、随机种子、硬件、运行命令、指标和失败原因。模型可以自动生成日志，但日志必须写入不可变存储，并允许人工检查。对于会改动训练代码或集群配置的动作，采用最小权限和审批门槛。
SandBase 这类网关可以帮助记录模型调用、token、延迟和 request ID，但它不能替代实验平台的版本控制和数据治理。模型调用日志与科研实验日志应该分开保存，再通过任务 ID 关联。
“自我改进”最容易被夸大的地方
如果模型只是在固定目标下搜索更好的代码，它提升的是搜索效率；如果目标、数据和评估标准也会被它修改，验证难度就会显著增加。研究团队需要防止模型通过改变评测方式制造“自我提升”的假象，也要检查是否出现过拟合某一组任务的情况。
因此，独立留出的测试集、冻结的评估脚本和人工抽查非常重要。任何新版本都应该与旧版本在同一套隐藏任务上比较，并公开失败案例，而不是只展示最好的一次实验。
一个最小可复现闭环
冻结一个目标、一个独立评估器和一个资源预算。让协调器提出三个改动，在隔离工作区运行，并返回带证据的排序结果；再由第二个进程按照运行清单重跑胜者。如果无法复现，得到的只是个例，不是改进。
除了最佳分数，还要报告试验次数、耗时、token、失败运行、回滚、内存和 held-out 集得分。训练实验应保存 checkpoint 和数据指纹，区分方法变化与输入变化。
发布时如何表述
发布说明应分开写模型报告的动作、机器测量的结果和人工解释。尽可能链接代码、配置、日志和评估器版本，并明确哪些仍是厂商报告、哪些已经独立复现。这样才能把有吸引力的递归改进演示变成可复用的工程结果。
责任边界
模型可以排序假设或起草补丁，但训练代码、评估脚本和集群设置的变更应由明确的工程师批准；质量、内存或尾延迟恶化时使用 canary 和自动回滚。
结论
Hy4 preview 展示的是“模型参与研发流程”的早期形态，而不是一个完全自主的训练系统。它最值得关注的地方，是把假设、代码、实验和反馈串成了可持续迭代的环路。要把这个环路变成可信能力，下一步仍需要可复现的基线、独立评测和完整日志。
证据截图
图 1：腾讯发布说明描述了递归改进循环的厂商说法。
图 2：官方仓库用于查看公开代码和实验产物。
图 3：研究页面提供厂商声明的背景与限制。
