30小时真机数据训练模型？工程师眼中最大的风险不是算法

如果团队告诉我只用了30小时真机数据就出了模型，我的第一反应不是兴奋，而是打开他们的CI/CD看测试覆盖率。这不是抬杠，是工程直觉。

短期看，Ψ₀团队的成果确实漂亮。30小时真机数据能收敛到可用策略，说明他们在数据效率上做了扎实的工程优化。数据增强、动作空间压缩、模型架构轻量化，这些每一条都需要代码层面的精心设计。我注意到他们强调“用对方法”，那意味着造数据的人形、传感器的标定参数、环境配置，大概率都被硬编码成了可复现的配置模板。这种工程习惯值得点赞。但单看结果——真机数据量这么小，最大的隐患不是过拟合，而是模拟器盲区。模型在真实场景里没见过对抗样本，一旦输入分布偏移，策略可能直接崩溃。测试集里有多少种光照、摩擦系数、物体材质变化？如果没做鲁棒性验证，那这个模型在量产部署时就是一颗定时炸弹。

长期看，30小时的数据量意味着团队需要对整个pipeline有极度精细的控制。数据采集的质量、标签的一致性、模型更新的频率，每一条都依赖严格的代码审查和自动化测试。相比那些动辄上千小时数据的大厂，Ψ₀的做法反而对工程要求更高——因为你不能靠数据量来掩盖bug。我关心的是他们的训练脚本里有没有写死随机种子，验证集是否真的独立于训练集，以及每次实验的配置版本是否用git tag打了标记。这些细节不做好，所谓的“30小时奇迹”就只是实验室里的烟花，放完就散。

一句话总结：数据少不是问题，但必须用工程化的测试框架来防御那些数据无法暴露的边界条件，否则捷径是通往技术债最短的路。

原文链接：https://www.leiphone.com/category/private/XjLhqoCs0fFsyEIN.html