论机器学习的可重复性危机

雷锋网 AI 科技评论按：机器学习研究者、Jetpac 的 CTO、《The Public Data Handbook》和《The Big Data Glossary for O’Reilly》两本书的作者 Pete Warden 最近在自己的个人博客上发表了一篇文章，讨论了机器学习领域令人头疼的模型的可重复性问题，广大研究人员们想必深有同感。雷锋网 AI 科技评论把文章编译如下。

我最近和朋友聊到，他的初创企业的机器学习模型组织得太糟糕了，在他的团队成员间基于互相的成果做进一步开发，以及提交给客户时都出现了严重的问题。即便是原作者训练同一个模型有时也无法得到相似的结果。他希望我能推荐一个解决方案，但我必须承认，我自己的工作也在和类似的问题作斗争。这很难向那些非机器学习领域的人解释，但事实上，当我们尝试追踪变化、从零开始重建模型的时候仍然是摸着黑前进的。这种状况太糟糕了，有时候就好像回到了那个编程的时候没有源代码控制的年代。

当我在90年代中期开始正式编程时，源代码的变更追踪和合并的标准是Microsoft’s Visual SourceSafe。简单说一下它的使用体验，它没有原子登入，所以不能支持多个人编辑同一个文件；网络副本要连夜扫描以避免奇怪的崩溃现象，甚至这还不能保证数据库在早上还保持完好无损。尽管如此，我仍感觉幸运，有一次面试的地方，我注意到有一面墙，上面贴满了便利贴，每张对应文件树中的一个文件。程序员要修改哪个文件的时候就把对应的便利贴摘下来，然后修改完成以后再把它粘回去！

说了这么多都是为了说明，当提到版本控制，我从来不是一个羞怯的人。我曾经经历过一些糟糕的系统，如果有需要的话，我现在都还能用 rsync 和铁丝网去捣鼓出一个解决方案。即便我已经经历了这么多风风雨雨，凭良心说，机器学习还是我遇到过的在代码合并和变更追踪方面最糟糕的系统。

为了解释清楚这是为什么，下面我列举一个典型的机器学习模型开发周期

• 研究人员决定尝试一个新的图像分类架构。

• 她从先前的项目里复制粘贴一些代码来处理她要使用的数据集的输入。

• 数据集在网络中的其中一个她的文件夹中，这可能是从 ImageNet 下载的一个数据集，但不确定具体是哪一个。也许不知道什么时候会有人把其中那些非 JPEG 格式的图像删掉，或者做一些其它的小改动，但是这些操作都没有历史记录

• 她会尝试很多种稍有区别的想法，改 bug 和稍微调整算法。这些在她自己的本地电脑上完成，当她想训练这些模型的时候，她就直接把一大堆源代码复制到 GPU 集群上。

• 她会把训练过程执行很多遍，通常程序在跑的时候，要花几天或者几个星期去完成，通常在这期间她还会在自己的本地电脑上修改一些代码。

• 可能在集群上跑到快结束的时候出现了 bug，那么在跑的过程，她需要修改一个文件的代码，然后把这个改动拷贝到所有的机器上，然后继续运行程序。

• 她可能从一个跑出来的程序里拿出部分训练到的权重，然后在这个新的起点上，运行不同的代码。

• 她会记录所有运行过程得到的权重和对应的评分，然后当她没有时间做更多实验的时候就从里面挑出一组作为最终的模型。这些权重可能来自任何一个跑出来的结果，甚至来自于和她现在手上跑着的代码非常不同的代码。

• 她可能会把最终的程序代码在源代码控制中做个登记，不过这是在她的个人文件夹上。

• 她发表她的结果，附上代码和训练权重。

这已经是发生在一位认真负责的研究人员身上的比较乐观的景象了，同时你想必也已经看出来了，让另一个人接手把所有这些步骤重复一遍，最终还要得到同样的结果会有多难。每一个关键的地方都是不和谐的点能偷溜进来的机会。事情更诡异的是，ML 框架会为了运行速度牺牲一部分数值计算的精度，所以，如果一个人能奇迹般地把每一步准确地复制过去，最终结果依然会有细微的差别！

在许多现实例子中，研究人员不会记笔记或者准确记住她做过什么，所以就算是她本人也不能再现模型。就算她能，模型框架的代码也会随着时间变化，有时甚至是很彻底的，所以为了让一切正常工作，她还需要给整个系统做快照。当我接触那些 ML 研究人员，希望他们帮我重现模型结果时，他们对于需要花费的时间都相当大方，但即便在这些原作者的帮助下，我也还是常常需要花费数月的时间。

为什么这些很重要？有几个朋友联系我说，为了在自己的论文里复现别人发表的模型，他们花费了很多精力。如果他们不能得到和原作者相同的准确性，那他们怎么能说自己得到了新的结果是进步？同时很显然地，在依赖模型的产品系统中，如果你不能重建这些模型来适应改变的需求设计和平台要求，这也会令人担心。从这个角度上看，你的模型就从技术债务上的高利率信用卡变得更像某种高利贷放贷人了。同时这对于研究实验也是令人窒息的，因为既然改代码和训练数据都是很难撤回的操作，那么要试更多的变量似乎是一个困境，就像在没有源代码控制的时候修改代码一样会增加实验中改变变量花费的精力。

也不全是沮丧和厄运的消息，这个圈子里也有一些关于复现的值得注意的努力。其中一个我最喜欢的是 Toby Boyd 团队领导 the TensorFlow Benchmarks 的项目。他们团队的使命是，不仅要准确展现出如何在各种不同的平台上以很高的训练速度训练出一些顶级的模型，同时还要保证这些模型训练完毕之后可以达到预期的准确率。我曾见过他为了让模型达到那种精度付出了很多心血，由于我上面列出的任何一个步骤中发生一点变化都会影响到结果，而且也没有什么简单的方法可以发现背后的原因是什么，即便有原作者参与帮忙。所以他仍在努力。这也是一个没有止境的工作，因为来自 TensorFlow 的，GPU 驱动的，甚至数据集上的变化，都能对准确性产生微妙的影响。通过这项工作，Toby 的团队帮我们找到并且修好了由于模型上的 TensorFlow 的改变而产生的 bug 和追踪到由外部依赖项造成的问题，但这仍然只能覆盖到相对很少的一部分平台和模型。

我还知道一些其他的团队在认真考虑把模型用在生产上，花了和复现别人的模型差不多的时间精力保证他们的训练结果能被别人复现，但问题在于这仍旧是一个非常手动的过程。没有什么东西可以等同于源代码控制，甚至为了未来能成功再次运行模型应该采用什么样的训练流程都没有公认的最佳做法。。对此我也没有解决方案，但为了方便讨论，在这里列举了一些我觉得可能有用的原则：

• 研究人员能容易地将新的想法加进去，不用付出很大的“过程税”。如果这不能实现，他们就不会使用它。理想情况下，系统会有效促进生产。

• 如果负责的研究人员出车祸了（划掉）或者建立自己的初创公司之后就离开了，其它的人第二天就能把原来的事情接过来并训练所有他们至今创造的模型，而且得到相同的结果。

• 应该存在某种方法能找到包含针对某一特定模型的所有需要训练的参数，按照这种方法能够不拖泥带水地公开分享构建模型需要的参数。

• 为了再现结果，代码、训练数据和整个平台的信息都需要准确地记录下来。

我已经在开源社区和初创公司里看到了一些尝试解决这些问题的有趣尝试，对我个人而言，我巴不得马上就能减少自己花在处理这些相关问题上的时间，但我也不期待短期能完全解决这个问题。无论我们想出什么都会对我们处理模型的方法产生变化，同样的，源代码控制意味着对我们个人编程过程也是一个大的改变。将来我们的训练的一致性和教育这个圈子的后辈的效果一定会和我们想出来的工具一样繁荣，我都等不及看到这些了。

via Pete Warden's blog，雷锋网(公众号：雷锋网) AI 科技评论编译

。