吴恩达《Machine_Learning_Yearning》中文版 第9、10、11、12章

问题导读
1.如何让机器学习算法准确率高，运行时间短？
2.在建立一个机器学习系统时，我们通常怎么做？
3.何时修改开发集、测试集和度量指标？




上一篇吴恩达《Machine_Learning_Yearning》中文版 第8章使用单值评估指标进行优化
http://www.aboutyun.com/forum.php?mod=viewthread&tid=24536



9 优化指标和满意度指标

下面将提到组合多个评估指标的另一种方法。
假设你既关心学习算法的准确率（accuracy），又在意其运行时间（running time），请从下面的三个分类器中进行选择：

将准确率和与运行时间放入单个公式计算后可以导出单个的指标，这似乎不太自然，例如：

Accuracy - 0.5 * RunningTime

你可以有一种替代的方案：首先定义一个“可接受的”运行时间，一般低于 100ms 。接着在限定的运行时间范围内最大化分类器的准确率。此处的运行时间是一个“满意度指标” —— 你的分类器必须在这个指标上表现得“足够好”，这儿指的是它应该至多需要 100ms，而准确度是一个“优化指标”。

如果考虑 N 项不同的标准，比如模型的二进制文件大小（这对移动端 app 尤为重要，因为用户不想下载体积很大的 app）、运行时间和准确率。你或许会考虑设置 N-1 个“满意度”指标，即要求它们满足一定的值，下一步才是定义一个“优化”指标。例如为二进制文件的大小和运行时间分别设定可接受的阈值，并尝试根据这些限制来优化准确率指标。

最后再举一个例子，假设你正在设计一个硬件设备，该设备可以根据用户设置的特定“唤醒词”来唤醒系统，类似于Amazon Echo 监听词为 “Alexa”，苹果（Apple） Siri 监听词为 “Hey Siri”，安卓（Android） 监听词为 “Okay Google”，以及百度（Baidu）应用监听 “Hello Baidu.” 我们关心的是假正例率（false positive rate）—— 用户没有说出唤醒词，系统却被唤醒了，以及假反例率（false negative rate）——用户说出了唤醒词，系统却没能正确被唤醒。这个系统的一个较为合理的优化对象是最小化假反例率（优化指标），同时受到每24小时不超过一次误报的约束（满意度指标）。

一旦你的团队的评估指标保持一致并进行优化，他们将能够取得更快的进展。

10 通过开发集和度量指标加速迭代

我们很难事先就知道哪种方法最适合解决面临的新问题，即使是一个经验丰富的机器学习研究员，他通常也需要在发现令人满意的方案前尝试不同的想法。在建立一个机器学习系统时，我往往会这样：

• 尝试一些关于系统构建的想法（idea）。
• 使用代码（code）实现想法。
• 根据实验（experiment）结果判断想法是否行得通。（第一个想到的点子一般都行不通！）在此基础上学习总结，从而产生新的想法，并保持这一迭代过程。
  
  
  

上图展示的是前面所提到的迭代过程，循环得越快，你也将进展得越快。此时拥有开发集、测试集和度量指标的重要性便得以体现了：每当你有了一个新想法，在开发集上评估其性能可以帮你判断当前的方向是否正确。

假如你没有一个特定的开发集和度量指标，则需要在每次开发新的分类器时把它整合到 app 中，并且体验几个小时来了解分类器的性能是否有所改进。这相当耗费时间！另外，如果你的团队将分类器的准确率从 95.0％ 提高到 95.1％，这 0.1% 的提升可能很难被检测出来。但是积少成多，通过不断积累这 0.1％ 的改进，你的系统将取得很大的改进。拥有开发集和度量指标，可以使你更快地检测出哪些想法给系统带来了小（或大）的提升 ，从而快速确定要继续研究或者是要放弃的方向。

11 何时修改开发集、测试集和度量指标

开展一个新项目时，我会尽快选好开发集和测试集，因为这可以帮团队制定一个明确的目标。

我通常会要求我的团队在不到一周（一般不会更长）的时间内给出一个初始的开发集、测试集和度量指标，提出一个不太完美的方案并迅速采取行动 ，比花过多时间去思考要好很多。但是一周的时间要求并不适用于成熟的应用程序，譬如垃圾邮件过滤。我也见到过一些团队在已经成熟的系统上花费数月的时间来获得更好的开发集和测试集。

如果你渐渐发现初始的开发集、测试集和度量指标设置与期望目标有一定差距，快速想方法去改进它们。例如你的开发集与度量指标在排序时将分类器 A 排在 B 的前面，然而你的团队认为分类器 B 在实际产品上的表现更加优异，这个时候就需要考虑修改开发集和测试集，或者是你的评估指标了。

在上面的例子里，有三个主要原因可能导致分类器 A 的评分较低：

• 你需要处理的实际数据的分布和开发集/测试集数据的分布情况不同。
  假设你的初始开发集和测试集主要是成年猫的图片，然而你在 app 上发现用户上传的更多是小猫的图片，这就导致了开发集和测试集的分布与你需要处理的实际分布情况不同。在这种情况下，需要更新你的开发集和测试集，使之更具代表性。
  
  
  

• 你在开发集上过拟合了。
  在开发集上反复评估想法会导致算法“过拟合”。当你完成开发后，应该在测试集上评估你的系统。如果你发现算法在开发集上的性能比测试集好得多，则表明你很有可能在开发集上过拟合了。在这种情况下，你需要获取一个新的开发集。
  如果需要跟踪团队的进度，你可以每周或者每月在测试集上对系统进行一次定期评估。但不要根据测试集对算法做任何决定，包括是否将系统回滚到前一周的状态。坚持这样做会导致算法在测试集上开始过拟合，且不再能根据它对你的系统性能进行完全无偏估计（这对发表研究论文以及需要做出商业决策的人来说影响很大）。
• 该指标所度量的不是项目应当优化的目标。
  假设你的猫咪应用当前的度量指标为分类准确率，而该指标认为分类器 A 优于分类器 B。然而在尝试了两种算法后，你发现分类器 A 竟然允许出现一些色情图片，这实在难以容忍。应该怎么办呢？
  此时的度量指标并不能辨别出算法 B 在实际产品的表现比 A 更好，因此根据该指标来选择算法就不那么可靠了，说明是时候改变现有的评估指标了。你可以修改指标，使之对出现色情图片的情况进行严重惩罚。强烈建议你选择一个新的指标并为你的团队制定一个新的目标，而不是在不可信的指标上耗费太多的时间后，最终回过头对分类器进行人工选择。
  
  

在项目中改变开发集、测试集或者度量指标是很常见的。一个初始的开发集、测试集和度量指标能够帮助团队进行快速迭代，当你发现它们对团队的导向不正确时，不要担心，你只需要对其进行修改并确保团队了解新的方向是什么。

原文链接

进一步补充：

小结：建立开发集和测试集

• 选择作为开发集和测试集的数据，应当与你预期在将来获取并良好处理的数据有着相同的分布，但不需要和训练集数据的分布一致。
• 开发集和测试集的分布应当尽可能一致。
• 为你的团队选择一个单值评估指标进行优化。需要考虑多项目标时，不妨将它们整合到一个表达式里（比如对多个误差指标取平均），或者定义满意度指标和优化指标。
• 机器学习是一个高速迭代的过程：在最终令人满意的方案出现前，你可能要尝试很多想法。
• 拥有开发集、测试集和单值评估指标可以帮你快速评估一个算法，从而加速迭代过程。
• 当你探索一个全新的应用时，尽可能在一周内建立你的开发集、测试集和指标，而在成熟的应用上则可以花费更长的时间。
• 传统的 70% / 30% 训练集/测试集划分对大规模数据并不适用，实际上开发集和测试集的比例会远低于 30%。
• 开发集的规模应当大到能够检测出算法精度的细微改变，但也不用太大；测试集的规模应该大到能够使你对系统的最终性能作出一个充分的估计。
• 当开发集和评估指标不再能给团队一个正确的导向时，就尽快修改它们：(i) 如果你在开发集上过拟合，则获取更多的开发集数据。(ii) 如果开发集和测试集的数据分布和实际关注的数据分布不同，则获取新的开发集和测试集。 (iii) 如果评估指标不能够对最重要的任务目标进行度量，则需要修改评估指标。