机器学习项目如何管理：工作内容

前一篇文章介绍了机器学习的基本过程，然后讨论了如何对机器学习项目设置期望的问题。我们了解到，度量准确率的指标可以有多种，需要根据应用场景来选择。一旦选好了度量指标，接下来就可以围绕这个指标来划分任务、监控进度、管理风险。

机器学习项目涉及哪些工作

站在非常宏观的角度，机器学习系统工作的方式是：你有一个模型，你把一堆数据输入给它，然后你以某种方式使用它提供给你的输出。所以机器学习项目要完成的任务也是三大块：处理输入；获得模型；提供产出。

1. 处理输入
   a. 你需要获得已有的数据
   b. 你需要对数据做矢量化操作，把原本丰富多样的数据变成有若干列的矢量
   c. 你需要对数据做特征工程，找出可能蕴涵了知识、值得被学习的那些特征项
2. 获得模型
   a. 实际上很多时候你可以使用现成的模型，包括：（i）下载现成的离线模型，或者（ii）使用在线的人工智能服务
   b. 如果没有现成的模型，你也可以考虑使用现有的数据来自行训练模型
3. 提供产出
   a. 机器学习的结果可能通过某种人-机（UI）或机-机界面（API）被用户直接使用
   b. 作为项目的产出，机器学习模型需要被嵌入到整个数据流水线中
   c. 作为项目的产出，机器学习模型的开发、测试、部署需要有DevOps的支撑

在所有这些任务中，只有2.b“自行训练模型”（上图右下角标星星的部分）需要新的技能和管理方法，其他都是传统的软件开发任务，可以用标准的Scrum等敏捷方法拆分任务和管理。也就是说，如果你需要的人工智能能力已经有一个现成的模型提供，那么整个项目就是一个传统的软件开发项目，只是需要使用一些新的工具或API而已。

下面我们聚焦讨论需要自行训练模型时，这部分工作应该如何拆分、如何管理进度和风险。

自行训练模型的流程

在自行训练模型的情况下，如上图所示，你会用历史数据（X和Y）来训练一个模型，然后用这个模型对未来的生产数据（X-hat）做预测（算出Y-hat）。不论采用什么指标来度量准确率，模型在训练数据上的表现一定好于在生产数据上的表现，这是因为模型从训练数据中“学到”的知识不一定在生产数据中完全重现，或者用黑话来说，模型在训练过程中“拟合”了训练数据的特征。也就是说，如果一个模型对训练数据表现出了95%的准确率（先不管采用哪个准确率指标），其实你并不知道这个模型对生产数据会表现什么水平的准确率，于是你也不知道这个模型是否好到可以上线运行。

为了更有效地衡量模型的表现，我们会在开始训练模型之前先拿出一小部分历史数据（例如全部历史数据的10%）用于测试，整个训练过程不接触这部分数据。于是我们就有了“训练集”（training set）和“测试集”（test set）。很多时候我们还会分出一小部分数据作为“验证集”（validation set），为了简化问题，我们可以先采用“训练集+测试集”这种设置。

把历史数据分成训练集和测试集以后，可以预期，模型在训练集上的表现会优于在测试集上的表现，这两个表现通常都会低于项目期望值。我们把“【模型在训练集上的表现】与【期望值】之间的差距”叫做Bias，把“【模型在训练集上的表现】与【模型在测试集上的表现】之间的差距”叫做Variance。

于是就有3种可能的情况：

1. High Bias：模型在训练集上的表现远低于期望，模型还不能实用（此时Variance如何并不重要）；
2. Low Bias, High Variance：模型在训练集上表现好，但是在测试集上表现差，模型还不能实用；
3. Low Bias, Low Variance：模型在训练集和测试集上表现都好，可以投入实用。

我们通常会从简单的机器学习算法、手边立即能获得的数据开始尝试。这时候通常Bias会高，因为过于简单的模型不足以呈现数据背后的知识，这时我们说模型“拟合不足”（Under-fitting）。在这种情况下，可以采用的措施包括：

• 使用更复杂的机器学习算法
• 使用更复杂的神经网络架构

用更复杂的机器学习算法和神经网络训练出来的模型，通常能更好地拟合训练集，进入“Low Bias”的状态。这时我们再关注模型在测试集上的表现，如果测试集的表现远差于训练集的表现，就说明模型过度地针对训练集的特征做了优化，我们说模型“过度拟合”（Over-fitting）训练数据。在这种情况下可以采用的措施包括：

• 引入Regularization通常能降低over-fitting的程度
• 通过特征工程可以避免一些over-fitting的情况，例如排除掉一些严重过度拟合的特征
• 引入更多的训练数据，包括数据量和特征量

最终我们的目标是得到Bias和Variance双低的模型。

潜在风险点

从上述的工作流程中，我们可以预先识别一些潜在的风险：

• 在Under-fitting的状态下，如果人员能力不足，就无法应用更复杂的算法
• 在Under-fitting的状态下，如果计算资源不足，就无法训练更复杂的模型
• 在Over-fitting的状态下，如果数据质量不足，就无法开展有效的特征工程
• 在Over-fitting的状态下，如果数据数量不足，就无法训练高效的模型
• 如果整个项目涉及的数据基础设施不足，就无法快速迭代实验

于是，训练一个机器学习模型就不再是一个神秘的、盲目的、随机的过程。借助Bias、Variance、迭代实验的频率等量化数据，IT管理者和不懂技术的业务代表能更清晰地看到项目的进展，整个团队能更好地判断接下来需要做什么：是需要尝试更高级的神经网络呢？还是需要想办法获得更多的数据？或者是需要更多的计算资源？还是需要寻找某些特定的知识和技能？这样就避免了业务代表怀有不切实际的期望、又不知道技术团队在做什么而感到恐慌。

在下一篇文章里，我会更加具体地介绍，如何借鉴Scrum和看板等敏捷方法的思路，把训练一个机器学习模型的工作拆分成更小粒度、更易于管理的任务，以及如何对机器学习项目进行可视化管理。

© 作者保留一切权利，未经许可请勿转载 © 2018 Transparent Thoughts. All rights reserved.