构建实战机器学习系统的10点经验（二）

原文：10 More lessons learned from building real-life Machine Learning systems — Part II
译者：刘翔宇
审校：赵屹华
责编：周建丁

在我上一篇博客中，我介绍了10点新的经验，并且讲述了其中5个。那么现在来讲讲剩下的5个吧。

6.特征工程的烦恼与收获

一个性能良好的机器学习特征的主要特性有：

• 可复用性
• 可转换性
• 可解释性
• 可靠性

这些特性究竟意味着什么？

• 可复用性：你应该可以在不同的模型，应用和团队中重复使用特征。
• 可转换性：除了直接重复使用特征，还应该能轻松使用它的转换形式（比如log(f)，max(f)，在时间窗口内使用∑ft ）。
• 可解释性：为了实现前面所述的操作，你必须要理解特征的含义并且能够解释它们的值。
• 可靠性：在特征中应该要很容易监控和检测漏洞/问题。

我们来看看特征工程中一个实际案例：Quora的答案排名。我们如何知道开发一个好的答案排名模型需要的特征呢？首先我们要确定Quora中对于“好”答案的定义是什么。幸运的是，我们有一份详细的Quora答案策略（Quora Answer Polices）描述。在这份描述中我们会找到如下的修饰语：

• 真实的
• 可重复使用的
• 提供解释
• 格式良好

Quora的答案排名是一个 非常有趣的机器学习问题，需要良好的特征工程

那么，我们如何将我们关心的维度转换成特征，然后输入到机器学习模型中呢？技巧就是，我们哪些产品数据具备那些特性呢。我们可以使用与写作质量，互动特征（比如赞同或者评论），用户特征（比如话题中用户的专业知识和诚信度）相关的特征。

7.机器学习基础架构的两个方面

每当你在开发任何机器学习基础架构的时候，你需要知道两种不同的基础架构：

• 模式1：机器学习实验。在这种模式中，我们注重灵活性，易用性和可重用性。
• 模式2：机器学习产品。在这种模式中，我们除了注重上一模式所有注重的之外，还注重性能和可扩展性。

理想情况下，我们希望这两种模式尽可能的相似。那么，我们如何才能将它们结合呢？

一个可能的解决方案是偏向使用实验法，直到有一定效果之后才投入生产。这可能意味着，比如，让机器学习研究人员使用R，之后让工程师自己选择语言来实现产品。另一种解决方案完全相反：偏向使用生产模式，然后让研究人员自己琢磨如何进行实验。比如，你可以选择使用高度优化的C++代码，然后让机器学习研究人员只通过日志或数据库中的数据进行实验。

现实情况是，上述的两种选择都不起作用。它们效率不高，耗费资源，最终导致至少一种模式不能正常工作。

技巧就是要实现可以解决这两种模式需求的中间解。有一个例子就是，让机器学习研究人员在Ipython Notebooks上使用Python工具（scikit-learn，Theano等）进行实验，在生产过程中，尽可能复用工具，仅在需要时实现优化版本。另一种选择是在优化的实现顶部实现抽象层，这样就可以用更友好的实验工具访问。

8.你为什么应该关心回答（关于模型的）问题？

机器学习模型的价值就是它给产品带来的价值。产品的拥有者和利益相关者在这个过程中对产品表现有所期待，并且希望验证它们。能够回答模型为什么做某件事或者为什么失败是非常重要的。模型的可调试性实际上可以弥合产品设计和机器学习算法之间的差距。

我可以这么说，模型的可调式性至关重要，它可以最终确定，或至少影响所用的模型，依赖的特征，或用于实现的工具。

调试决策树将是件简单的差事（使用BIGML UI）

Tensor Flow中调试计算图形

作为一个例子，我们在Quora上有一个调试工具，它可以让我们分析为什么我们在首页输入中看到特定的问答。这个工具不仅可以报告单个问答，还可以报告关联到它的特征。它同样可以比较不同的问答，并且理解决定最高排名的问答的特征。这在调试问题的时候非常有用，同样，在使产品团队和其他利益相关者更好理解模型行为方式以及什么重要、什么不重要时也非常有用。

对Quora的输入信号调试特征值

将一个“对象”从产品（比如Quora答案）变成特征非常棒！

9.你不需要分布式机器学习算法

最近，有种行业趋势，似乎建议应该默认地使用分布式机器学习算法。如果你不这么做，那可能因为这你的数据“不够大”，对吗？好吧，在这里我认为不是这么回事。实际上，人们使用机器学习应用需要做的大部分事情应该可以在一台（多核）机器上完成。当然，也有一些值得注意的例外情况，例如，如果你正在构建大规模深度人工神经网络来识别猫。但是，我们大多数不需要做这种系统。

好吧，如果你正在做识别猫的模型，你可能需要分布式机器学习算法。

当然，为了让所有东西在一台机器上运作，你需要了解其他方法。例如，你需要了解（智能）数据采样的好处，如何使用离线处理方案，或如何用单机并行计算。我在此进行了讨论。

写了许多关于分布式机器学习的东西

此外，我认为诸如Hadoop和Spark这样的方法通过隐藏大部分复杂性提供分布式处理平台的“简易”使用方式，在某种程度上是危险的。特别是，如果你在意成本或者延迟，保持它们的透明性或易于理解是一个好主意。

下面是来自Quora的一个有趣例子，说明了这方面的一些问题。在某些时候，我们意识到有一个Spark实现效率特别低。15台机器花了6小时运行某些东西，而粗略计算告诉我们所需时间远不用这么久。我们一位工程师花了4天时间分析它，比如，分析Spark调度程序如何展开查询。最终的C++实现目前运行在一台机器上而且只花了10分钟来完成计算！

10.数据科学与机器学习工程不为人知的故事

我们都听说并阅读过关于什么是数据科学家的回答。它们大多数都是讲述他们如何结合数学，软件和专业知识。

著名的数据科学家韦恩图

现代数据科学家（“古老”数据科学家是这样吗？）

有一个不同的问题，数据科学团队如何融入机构之中。许多公司已经克服或正在克服这点。大多数都会认同，拥有可以从数据中获取价值和知识的强大数据科学家是非常重要的。但是，不管有些人会怎么说，拥有雄厚工程技术的强大数据科学家是独角兽，找到他们并非易事。这往往会导致这样的情况，数据科学家需要依靠工程师进行生产，而另一方面，工程师不想这么做，因为他们自己已经有足够的事情要去做，而无暇生产其他人的想法。

那么，该如何解决呢？我的建议是考虑使用典型机器学习相关项目的漏斗模型。这有3个不同的阶段。

1. 漏斗的第一部分是数据的研究方向。在这里，团队研究数据并试图理解问题是什么，以此提出假设。用户在周五晚上比其他日子点击的红色按钮要多吗？用户更喜欢新内容即使它质量可能不高吗？我们如何处理新内容的冷启动与成熟内容的权衡问题？

2. 漏斗的第二部分是一旦提出假设，我们需要实现一个机器学习解决方案。它包括模型选择，特征工程，在生产中实现解决方案。同样还包括解决方案的初始版本，以及将来迭代来优化和改善当前系统。

3. 漏斗的第三个也是最后一个部分的重点是运行在线实验（AB测试）和分析结果。这样，我们就可以明白实现的解决方案是否真正工作以及证实我们最初的假设。

要注意，这三个阶段并不需要花费很长的时间，它们应该在迭代和敏捷过程的上下文中尽快发生。

基于我所看过，听过以及经历过的案例，我的建议是数据科学家负责第一和第三部分，工程师负责第二部分。在迭代过程中使数据科学家负责第一和第三部分可以得到更快的迭代，因为实验中的结果迅速地回流来改进假设。在Quora，我们将数据科学家和工程师都参与到所有项目中，并让他们密切协同工作，同时，仍让他们明确自己的负责领域。查看William Chen答“Quora的机器学习工程师和数据科学家的区别是什么？”了解更多详细信息。

数据驱动的创新漏斗

最后需要说明的是，为了让机器学习工程团队高效，可能需要扩大对机器学习工程的定义。再次，很难找到一大群在机器学习和软件工程方面都很杰出的工程师（就像将11位投手建立一个球队一样是困难的）。一个好的机器学习工程团队包括有着高度机器学习知识的编码专家和拥有软件技巧的机器学习大师。

结论

在实现实际机器学习解决方案上有很多不明显的问题。其中有一些与你在出版物上读到的非常不同，甚至与被认同的“通常做法”也非常不同。如果我要在几个维度上对这10点新的经验进行总结，我想要强调以下几点：

• 确保你训练的模型可以学习你想要的
• 结合监督式/非监督式技术是许多机器学习应用的关键
• 专注于特征工程非常重要
• 对机器学习基础设施/工具考虑周到
• 组织你的团队

我希望这些建议大有裨益，但我也承认，它们中有一些存在争议。我非常愿意倾听不同的观点和方法，请在评论区评论。