转载

Olivier Grisel谈scikit-learn和机器学习技术的未来

几周前，我们的Florian Douetteau (FD)对Olivier Grisel(OG)进行了一次访谈，正好我得到这个机会去旁听。Olivier是scikit-learn机器学习库的主要贡献者，因此他们两个详细地讨论了Olivier的工作和其它技术的发展。这是采访的第一部分。

Olivier Grisel 和 scikit-learn

FD：Olivier，你作为scikit-learn的主要贡献者已经有一段时间了。你可以告诉我们一些关于你的贡献么?

OG：大概是2010年，我就开始做scikit-learn这个项目。我是利用业余时间去做这个项目的。在2013年10月，我加入了Inria，一所面向计算机科学和自动化研究的法国研究院。我们有个团队，名叫Parietal，主要研究使用MRI数据对大脑进行建模。在这个项目中，我主要负责让scikit-learn发展地更长远，主要是指性能和可扩展性方面。

FD：scikit-learn已经发展了这么多年，而且知道开发过程中的许多阻碍。你能告诉我们一些关于将来的事么?

OG：当然可以。在过去的几年中，我们已经知道了一个重大的进展。现在，我们有很多新的用户和贡献者。根据我们的网站统计，我们每个月有150000到160000个独立访客，其中有1 / 3是回访用户，而且我们也有越来越多的贡献者。例如，在这些天，几乎有300个pull请求需要我们去处理。

scikit-learn大多数的新发展都来自用户社区自身的贡献。他们不断给scikit-learn库进行修改和补充，并为scikit-learn更好的后续版本提交这些工作。然后我们会对这些修改进行测试，并将其添加到每个新的版本中。例如，在最近的一个测试版本里，我们的一个贡献者开发了LDA估测器。这个算法在某种程度上可以替换scikit-learn已经存在的MMF，而且LDA在可扩展性方面表现的更强。

我开发的是一个更加长期的项目，这个项目涉及了大量的问题(因此它并不属于下一个版本的一部分)。我们正在努力使更多的scikit-learn算法能够以数据流模式，或核外模式，来管理数据，而不是在内存中控制整个数据集。我们希望它们逐渐地加载数据集，就像它们训练模型那样。

scikit-learn VS MLlib

FD：目前，在机器学习领域，我们听到了大量关于Spark的传闻。你有机会去尝试一下么?如何把它与scikit-learn进行比较呢?

OG：通过制作的两个Spark教程，我了解了一下Spark(教程1，教程2)。Spark和Python或scikit-learn之间的主要区别是，Spark默认是一个系统，以分布式的方式管理那些其它数据处理方法无法在内存中处理的数据。这也是MLlib一开始的设计方向(ed：Spark分布式机器学习框架)。他们选择仅实现可扩展性的算法，这些算法可以在它们有能力处理的那些数据上和大量集群中运行。通过只选择有这种特性的算法，他们目前已经解决了这个双重可扩展性问题。

scikit-learn最初的目的是处理内存中的数据，所以我们不存在偏见。我们有一些非常有效的算法，它们只在小数据集上有效。但事实上，我们有很多算法都是以批处理模式实现的。目前，我正在对它们进行重构，主要是为了让其具有更好的可扩展性。

scikit-learn并不是创建跨集群的功能。我们不想改变所有的功能，来处理存储在集群中的资源，但我们想把它作为一种可能性，确保scikit-learn模型可以嵌入到一个类似Spark的框架里，这样它们就可以分布在集群中。例如，当你在训练一个随机森林时，如果你认为你的数据小到可以在整个集群中进行复制，那么你可以很容易地训练每棵树。对于中等规模的数据集，我们也想要加快超参数搜索和交叉验证的速度，这自然就是并行。

在解决集群的分布式计算之前(正如Spark关注的)，我对于研究有效的核外处理方法(像Dato正在做的)也是很有兴趣的。目前我还没有真正地研究过细节，但似乎只要你能够更好地进行核外处理并重视算法效率，你就可以减少资源的浪费。这也可能成为scikit-learn未来发展的驱动力。

FD：以分布式方式存储大量数据会导致性能和结果的偏差么?我正在思考使用Spark运行随机森林的例子。

OG：MLlib随机森林算法在选择特征进行划分时，它是直接在每棵树的训练层面进行并行的。它并没有考虑所有可能的分裂。它建立的是一个直方图，并在划分的数据集上进行并行运算。然后，使用总的信息构建划分。这跟估计算法类似。尽管这种方法是近似估算，但在实际应用中，当你使用样本进行建模时，几乎不会出现问题。因为和非估计算法的结果相比非常接近，只是实现的效率差了点。

未来的方向是特征生成?

FD：当你去查看一个数据项目，很多时间–如果不是大部分时间–是用在数据预处理和特征生成。在过去的几个月里，scikit-learn在朝着特征工程方向发展。这是你将继续维持的方向吗?你会朝一个集成的管道工作吗?这似乎像是一条无止尽的路。有没有一些平行的项目专攻特定的数据类型和格式，同时又遵循scikit-learn的习惯和理念?

OG：在创建scikit-learn预测模型时，特征始终是一个关键点。因为pandas数据框的最新版本，我们越来越善于整合工具箱去操纵任何格式的数据，并把它转为其它格式或是任何其他的表示。

我赞同你的观点，特征工程对于一个具体的应用程序而言，永远是一个特殊环节。我们希望保留一个通用库。如果我们要专攻某个特定的领域并开发特征，它将成为一个独立的特定库的一部分。例如，在天体物理学中有一个叫AstroML的专用库。此前，我在INRIA的团队处理的是影像数据。我们已经开发了一个特定的库，叫做nilearn，它是scikit-learn的一个分支项目。事实上，划分不同项目的范围是很有好处的。它可以围绕社区特定的实践活动进行更好地交流。

FD：在特征工程这个主题上，你相信Spark和MLlib会改变数据科学家的工作方式么?

OG：最近的数据框API是Spark的一个优点。它给了数据科学家一个非常直观，灵活，并富有表现力的工具，用于测试他们不同的数据表示。

从更高层面来讲，最新版本的spark.ml包，允许在以数据组合为特征的“链”中创建管道和预测模型。在链的不同阶段可以交叉验证参数的相互作用。也正是这类API的优点，使它更易于测试。其实在scikit-learn中也可以安装插件，使用数据框作为输入并且添加用户自定义的scikit-learn转换脚本。事实上，使这个过程变得更加简单也正是我们应该努力的实践方向。

搜寻这些项目

FD：非常感谢您这次精彩的谈话!你觉得还有其他任何需要补充的吗?

OG：我认为Python生态圈越来越意识到当前的技术形势，特别是在谈及到处理大量数据时。Java和Scala领先于我们，尤其是Hadoop和Spark。开发人员对于这一点都非常清楚，他们正在寻找答案。如今有很多有趣的项目，如Blaze,Dask,或XRay。他们正在开发相关的APIs，努力使其像Pandas一样出色，并且能做核外计算，最终形成分布式的。Wes McKinney给Cloudera做的Ibis项目也很有趣。它使用的是Python，但用Impala作为后台，用其替代PySpark。其实，我并不相信在当今的生产中能够使用它，但我相信这个主题的发展将会很有趣。

敬请期待Olivier访谈的第二部分，在那里他给数据科学的入门人士和想知道应该培养什么技术的学者提出了一些建议。

正文到此结束