科学（比如物理、化学等）的主要原则（或者至少是科学的理想原则）之一是：可重复性。只有结果能被清楚地再现并经过严格的同行评议后，真正“科学的”结论才能被学术界所接受。当然，不管是学术界里科学家还是数据科学家，在实际操作过程中，事情都会变的有些混乱。很多数据科学家所使用的流程都还远未达到可重复性。这些流程可能是如下的几种形式：

• 一系列的Jupyter notebook，里面包括不断增加的描述性的文件名，比如second_attempt_at_feature_selection_for_part2.ipynb。
• Python或R的脚本，被手工拷贝到一台机器上，并用crontab来设置定时运行。
• 相当鲁棒但很难看懂的应用程序。一般是由数据科学家完成需求文档，并交由软件工程师来开发的。
• 一些应用程序，它们生成的结果几乎不可能与一个或多个持续变化的数据集的特殊状态相关联起来的。

最好的情况是，这些工作流的产出结果一般可以被这些项目的参与人员所重新生成。但是，如果让新加入项目的人员或者是进行项目评估的人再重新生成同样的结果，就不可能了。

与可重复性相关的苦恼已经在整个数据科学社区中被广为探讨：

“数据分析是非常容易出错的，很难知道你什么时候得到了正确的结果。这使得形成可重复的研究变的非常重要”——《可重复性不仅仅只是研究人员需要关注的》，数据学院。

“曾经试图去重复你几个月前做的一个分析吗？或者是几年之前？尽管可能是你自己写的代码，但是现在你几乎不可能去理解并决定是用哪一个程序来完成任务。是make_figures.py.old？还是make_figures_working.py？或者是new_make_figures01.py？”——Cookiecutter数据科学

“6个月之后，别人问了一个你分析里没有涉及的问题，这要求你必须重复你的分析。但是你就是记不得你把文件存在电脑的什么地方了。如果你是一个数据科学家，特别是关注决策科学和决策分析的那种，你一定碰到过这种情况。”——《最无聊/有价值的数据科学的建议》，Justin Bozonier

可重复的问题是一个机构里的数据科学团队在某个时间点不得不面对的问题。然而，这是一个好消息！只要运用一点点原则和正确的工具，数据科学团队就可以获得可重复的能力。这篇博文将会讨论一下可重复性的价值，并提供实现可重复性的一些实战方法。

为什么数据科学团队需要关心可重复性？

一些人可能会认为只要模型和分析能输出“好的”结果，这个结果是否能够被重复并不重要。然而如果忽略可重复性，即使是一个很小的数据科学团队也可能会出问题。在数据科学中，可重复性不应该被放弃，无论你的机构有多大或者有多成熟，因为可重复性是以下活动的前提条件：

合作：数据科学，或是通常意义上的科学，都是一个合作的行为。没有一个数据科学家知道所有的建模技术和分析方法。即使有人全都知道，但是现代公司里的数据问题的复杂度和规模已经超出了单个人所能控制的范畴。因此作为一个数据科学家，你应该总是要关心如何把你的结果分享给你的同事，以及你们如何在分析和建模时进行合作。特别是，你应该使用一个专门的方式来分享和部署产品，能让别人使用相同的数据，重复你的方法，产出相同的结果。不然，你的团队将无法把团队合作出的知识变现，同时团队内部的进步将也仅仅只能被个别人了解，而成为个人的进步。

创新：怎么能知道一个新模型比旧的模型要有更好的表现？怎么能恰当地证明对分析所加入的创新的精细度或复杂度更好？不幸的是，这些问题的答案通常都是通过个别人的试错（例如用一个notebook）得到的，而一般在做出决定后就被忘掉了。但是如果分析是可重复的，数据科学团队就可以(1)明确地判定新的分析结果是否比旧的好，因为旧的分析可以被再现，且新的分析是用已知的数据来进行的；(2) 清晰地了解到过去哪一个分析的表现比较差，从而能避免犯同样的错误。

合规：随着越来越多的统计、机器学习和人工智能的应用做出对用户产生直接影响的决定，将会越来越多的来自大众的压力，要求解释这些决定，并能重现结果。事实上，欧盟已经对很多由算法生成并对用户产生影响的决定提出了“获取解释的权利”。如果没有一个清晰可理解的和可再现结果的工作流，这样的解释将无法给出，而相应的审计也无法进行。

数据科学团队怎样才能实现可重复性？

在不同的组织里来成功地实现可重复性的方法会有不同，因为数据科学团队所解决的任务是非常不同的。不过通过对于下述最佳实践、技术和工具的组合使用，将有可能帮助你的工作流程更接近可重复性。

努力实现简单、可解释的解决方案，并为之喝彩

深度学习就是一个典型的很强大但通常非常难重复的分析工具的例子。并不是所有的业务问题都需要使用深度学习，尽管它和其他类型的神经网络算法都明显更好。经常是一个简单的统计聚合（例如计算最大和最小值）就能为数据驱动的决策提供非常好的支持。在某些场合下，简单的线性回归或是决策树也有可能产生足够好的（甚至是非常好的）预测结果。

在这些场景里，使用更复杂的建模技术所带来的精确度和准确度的提升可能并不能抵消在可解释性上付出的代价。这里的基线就是，如果使用更复杂的数据处理管道和建模技术后不能保证可重复性，那么可重复性应该比使用最新和最好的模型的价值更高。

无重复性，不部署

无论你面临着什么样的时间节点压力，都不应该把一个不完善的分析应用上线。作为数据科学家，我们努力地创造一个依靠数据驱动来制定决策的文化。如果你的应用故障了，还没有一个解释（很可能是因为你无法再现故障的结果），大家就会对你的应用丧失信心，并不会依据它的产出来做决定。即使你最终修复了故障，用户丧失的信心却是非常难以挽回。

数据科学团队应该按照要求有单元测试、静态代码分析、代码版本控制和代码回顾一样的方式来要求有可重复性。如果不能用已知的数据持续重复地生成同样或者更好的结果，分析就绝对不能进入开发阶段。可重复性的具体的表现可以使用与集成测试相同的技术来衡量。更进一步，如果可能，新的模型应该和已有的系统上运行的模型并行运行，对相同的数据做分析，从而实现相互的比较。

你可以自己完成上述测试和测量的排程，但你也可以考虑使用诸如LeVar这样的工具。LeVar提供了“一个数据库来存储分析用的数据集和使用它们的实验，从而可以用它来记录和跟踪新的方法对于静态和已有的数据的运行和表现”。

版本化你的数据

即使你已经版本化了代码或者Jupyter的notebook，但如果你不能使用同样的数据，你还是无法重复之前的分析。这意味着你需要制定计划，并用工具来获取历史上某个点的分析和数据的状态。现在越来越多的数据版本化的工具出现了，下面会对它们做简单的分析。不过你的团队应该制定一个数据版本化的计划，并严格执行。实现数据版本化之前的数据科学犹如Git之前的软件工程。

Pachyderm是我非常了解的一个工具（曝光一下，我就在Pachyderm工作）。它可让你如在Git上提交代码一样的提交数据。Pachyderm的文件系统是由“数据资料库”构成的，你可以提交任何格式的数据文件。

对数据的任何操作，你都可以把它们包装成一个版本后提交到Pachyderm里。这意味着操作是可回溯的，而对你和你的同事而言新状态是可重复的。就如在Git里一样，提交是可回退的，所以你的数据可以回退到之前的任何状态。

知道你数据的渊源

实际上，版本化数据还不够。数据来的时候可能是用它自己的封包形式，可能是来自一系列的转换后形成的。因此你有可能会需要理解数据的渊源。没有上下文的结果是没有意义的。你分析的每一步中，你需要能理解数据是从哪里来的，以及它们是如何变成当前的形式的。

类似Pachyderm这样的工具（作为一个工具或是你自己过程的一个模型）在这里也能帮忙。例如，通过Pachyderm运行的一个分析在执行过程中会自动的记录起源。在输入数据没有成为输出的起源时，分析是不会采用此输入的。

记录下来

如果你想，这一步也可以叫“文档化”。在任何时间，你的文档都应该包含一个“实验笔记”，用来记录你是如何做出会影响分析结果的决定的。每个决定都应该有一个被记录下来的动机和与之相关的代价。

例如，你非常可能需要去正则化一个变量。然而在你正则化的时候，与这个变量相关的单位信息就会丢失，并可能造成别人无法理解这个变量。其他情况可能是其他人在利用你的分析时也可能会基于列名来假定测量单位。

Elias Ponvert在他的博文《我们是怎么用人的模式来进行数据科学的》里对这一点做了非常好的讨论。：

 “实验笔记太重要的了。没有它，数据科学家非常难以重新开始他或她在一个实验项目里遗留下来的工作，即使他或她仅仅只是做了一两天这个实验。”

结论

在你的数据科学工作流里确保可重复性看起来像是一个很恐怖的任务。然而，遵循一些最佳实践并运用合适的工具就能帮你完成。最终你所做的这个努力都是值得的，并会在一个合作、创新和合规的环境里得到回报。