生产系统中的机器学习笔记（二）：选择、训练一个模型

这是我在学习DeepLearningAI上吴恩达老师的《生产系统中的机器学习》课程过程中的笔记。这一系列课程的质量很高，学习中受益匪浅。老师的讲授顺序是从模型部署至模型训练再到数据处理，模型部署部分的笔记忘记保存了，明天再整理，这一篇是模型中的选择和训练模型部分。

选择、训练一个模型

在模型选择与训练过程中，很多人往往会更倾向于不断优化模型的设计、参数的选择，这称为以模型为中心的人工智能开发（Model-centric AI development）。
但是事实上，经过这些年机器学习或者说深度学习的高速发展，大量的研究都是围绕着模型进行的，在模型的设计、实现上已经有着很多优秀的先例。我们甚至可以认为，当下现有的模型已经能够满足大部分生产系统的需求了，为了一个系统的部署、落地而再去围绕模型进行研究，其收获会相当有限。因此在吴恩达老师的课程中，更强调的是以数据为中心的人工智能开发（Data-centric AI development）。我们可以选用现有的模型设计，但是针对具体的应用场景、对数据进行更好的定制，为算法提供更高质量的数据，这样或许能训练出更符合业务要求的模型、使系统更有效地运行。

模型开发面临的挑战

训练一个机器学习模型，我们首先需要一套建立模型的算法（Algorithm/Model），接着需要在数据集（Data）上进行训练。当然，在训练中还有一系列的超参数（Hyperparameters）需要调整，但是超参数的搜索空间是有限的，我们往往更需要关注的是算法和数据这两部分。
对于实现用于生产目的而非研究目的的一个人工智能系统，我们大可不必煞费苦心地去设计新的神经网络，现有的研究成果已经足够使用了。但是，哪怕是将一个已经足够先进的模型部署到生产系统中，我们依然面临着很多挑战需要解决。
首先，我们必须确保模型能够在训练集（training set）上取得良好的表现，这往往使用平均训练误差来衡量。
接着，我们需要保证模型能在测试集（dev/test set)上有很好的预测结果。
许多机器学习工程师会认为，只要在测试集上得到很小的测试误差，就能够说明已经得到了一个很好的模型，并且能够马上将其投入部署了，但事实上，较低的平均训练误差对于一个要投入生产环境的模型而言依然是不够的。

吴恩达老师在课中举了一个搜索引擎的例子。
现如今的搜索引擎都会使用机器学习模型来匹配用户的搜索，旨在为用户提供更相关的搜索结果，从而优化用户体验。我们可以根据用户的目的，将搜索非为两类：信息、事务查询（Information and Transactional queries），和导航查询（Navigational queries）。

1. Information and Transactional queries
   当我们在搜索引擎查询某个食谱、电影或是其他资讯，这一类查询就是信息、事务类查询。对于这一类查询，模型行为与用户期望可能就存在着不小的差异。
   机器学习模型通过匹配训练样本中的某些模式来习得特征到标签的关系（映射），从而根据给定特征预测出标签。这一行为逻辑就决定了，模型返回给用户的是与用户搜索的相关度最高的结果。但是，用户期望的往往不止于相关度，用户可能还希望得到一个经过排名的结果，比如搜索食谱时会希望更好的食谱能在前面。
   不过对于信息、事务类查询，用户的宽容度往往更高，因为这一类查询中，对结果的排名并不是特别重要，比如对于一个食谱，用户可能并不能准确地鉴别返回的结果中哪一个更好。因此，在这一类查询中，模型能够更轻易地获得较低的平均测试误差。
2. Navigational queries
   当我们在搜索引擎查询某一个网站时，这就是一种导航类查询。显然，用户会希望模型返回的结果正是其搜索的网站，只要返回结果的排序与期望不一致便会被马上察觉，用户对这一类查询的误差，宽容度比上一类要低得多。

因此，即是搜索引擎的模型取得了较低的平均测试误差，但是一旦在导航类查询中有所失误，用户的使用体验便会降低，这依然不是一个很好的模型。
所以，较低的平均测试误差并不是生产系统中的机器学习模型的唯一评判标准，我们还应该重视模型在关键数据上的表现。
此外，测试数据的分布对模型的评估也会有很大的影响。这样的情况非常常见，我们会很希望搜集到的训练、测试样本能够服从或是接近正态分布，但是事实往往是这些样本是严重的偏斜分布（Skewed distribution）。
上学期在做一个大作业时，我选的题目是复现一个关于情感分析的论文。在下载数据集后，我并没有去检查数据集的分布情况，进行了简单的预处理，比如去掉多余的列、填补空缺项后我就把数据丢进了模型开始训练，很快就得到了一个很理想的平均损失，然而接着我就发现了问题——几乎所有的预测结果都是“N/A”。这是因为数据集中绝大多数样本的情感极性标签都是“N/A”，因此模型在训练中只要将标签全部打为“N/A”自然就能得到一个很低的平均损失了，但是，这样的模型当然是无效的。
吴恩达老师也举了一个类似的例子，说的是一个胸片诊疗系统，某一类疾病的样本数在数据集中占的比例很小，因此即便这类疾病的诊断错误，对平均损失的影响依然是微乎其微的——哪怕这其实是一类常见病，医生会很希望系统能够自动诊断这类疾病，但因为数据分布的不合理导致其被忽略，这样的模型显然是不能被投入生产系统的。

建立基线

为了评价模型的性能（Performance），我们首先要做的是建立一套评价基准（Baseline）。
吴恩达老师在课上举了一个很好的例子，是说在一个语音识别系统中，其识别准确率如下：

Type	Accuracy
Clear Speech	94%
Car Noise	89%
People Noise	87%
Low Bandwidth	70%

我们可能会下意识地认为，这个系统在“低带宽环境”中的表现不太理想，因此迫不及待地将优化的目标着重于此。但是事实上，我们可以再看看人工语音识别对应的准确率：

Type	Accuracy	Human Level Performance
Clear Speech	94%	95%
Car Noise	89%	93%
People Noise	87%	89%
Low Bandwidth	70%	70%

我们建立智能的语音识别系统的目的，显然是希望这一系统能达到人工识别的准确率，从而在这一工作中实现一定的自动化。因此我们可以将人工的表现作为评价模型的基线。在低带宽环境中，语音的质量自然是很糟糕的，虽然识别准确率较低，但是并没有必要在这一类情况上继续纠结，反倒是前三类环境的语音质量较好，我们应该准求更高的识别准确率。
吴恩达老师在课中将数据分为了非结构化数据（Unstructured data）和结构化数据（Structured data）两类。

1. 非结构化数据包括图片、音频、文本等。显然，人类是很擅长处理这一类数据的，因此对于这一类数据，很适合以人类水平表现（Human Level Performance，HLP）为基线。
2. 结构化数据是指数据库或是表格中的这类数据。显然，人类很难从这类数据出发进行预测，自然就不适合以HLP作为评价基线了。

课程中介绍了三种建立基线的方式：

1. 人类水平表现（HLP）。这一方式适用于非结构化数据；
2. 查阅最先进的文献或开源项目结果，参考他人的实验结果作为建立基线的出发点。其实在做研究时也往往会基于已有的结果出发，进行改进，从而得到更好的结果。这自然也是一个很好的建立基线的方法；
3. 如果当前的项目是对已有项目的改进，我们自然可以将已有项目的运行情况作为评价新系统的基线。

开始项目的一些建议

开始

查阅文献，是否有可用或可以参考的选择。如果是为了构建实用的生产系统，就不必去寻求最新、最先进的算法，已有的、经过更多验证和应用的算法可能更合适；
查找可用的开源实现；
一个有着高质量数据的合理的算法，可能比一个数据较差的优秀算法要更好。
回到主题，我们要关注的是Data-centric AI Development，所以创造一个先进的神经网络并不是我们所追求的。我们要尽快地选择一个经过实际考验的算法开始我们的迭代，在迭代中调整数据，来训练出符合我们业务需求的模型。

挑选模型时考虑部署约束

如果在调训模型时，已经定义好了明确的基线和系统目标，那么部署约束就是当下需要考虑的问题。我们需要考虑部署环境的网络情况、计算密集程度等等一系列问题。然而，如果还没有一个明确的系统目标，或是没有建立明确的基线，那么就可以先将部署约束放在一边，在挑选模型时更多考虑目标和基线的问题。

检查代码和算法

开始在很大的训练集上训练模型前，先尝试在较小的训练集上过拟合，以检视代码或是模型是否存在问题。如果模型甚至不能拟合小规模的训练样本，那么花好几个小时甚至更长时间在大规模的数据集上训练也没有太大意义。课后有这样一道练习题：

假设你在一个语音识别问题上运行了一个健康检查测试系统，试图对单个训练样本进行过度拟合。你选择了一个有人说“今天的天气”的清晰片段，但算法甚至无法匹配这一音频片段，输出“______”。你应该怎么做?

答案是 在转移到更大的数据集之前，首先调试代码/算法/超参数，使其通过这个完整性检查测试。