吴恩达《Machine Learning Yearning》学习笔记（二）：模型指标

1.建立单一数字的评估指标

        指标太多会影响不同模型的判别，找一个你最关心的性能指标，以它为基准，再进行模型的调试，会起到事半功倍的效果

2.优化指标和满足指标

        

这是组合多个评估指标的另一种方法。

假设你同时关心算法的准确率和运行时间。你需要在下面三个分类器中进行选择： 
 
这里如果将准确率和运行时间组合为单个评估指标会看起来不太自然，例如：

Accuracy−0.5∗RunningTimeAccuracy−0.5∗RunningTime

这里你可以替代为这样：首先，定义一个“可接受”的运行时间。例如我们说任何运行时间在100ms以内的算法都是可接受的。这里，运行时间就是一个“满足度量（satisficing metric）”——你的算法只需要在这个指标上表现地“足够好（good enough）”就行，在这个意义上它应该满足最多100ms。准确率是一个“优化度量（optimizing metric）”。

如果你正在权衡N个不同的标准，例如模型的二进制文件大小（这对于移动app很重要，因为用户不想要下载很大的程序），运行时间和准确率等。你可以考虑设置其中N-1个标准为“满意（satisficing）”指标，也就是说你只需要他们满足特定的值即可。然后将最后一个定义为“优化（optimizing）”指标。例如，为二进制文件大小和运行时间设定可接受的阈值，并尝试在这些约束条件下不断优化准确率。

3.有一个开发集和评估指标来加速迭代

对于一个新问题，很难事先知道什么方法是最合适的。即使经验丰富的机器学习研究者在发现满意的方法之前也会尝试各种各样的idea。在构建机器学习系统时，我经常会：

（1）首先想出一些构建系统的想法（idea）

（2）在代码（code）中实现这些idea

（3）进行实验（experiment），通过实验判断我的想法 work的怎么样。（通常我的前几个想法都不是很work！）基于这些知识，再生成更多的idea，并不断迭代。

这是一个不断迭代的过程。你循环得越快，你的进展也就越快。这就是 开发/测试集 和评估指标非常重要的原因：每次你尝试一个新的想法时，在开发集上测试其表现性能，这将使你快速判断你是否在朝着正确的方向前进。

相反，如果你没有特定的开发集和评估指标。那么每次你的团队开发出一个新的猫分类器时，你必须把它移植到你的应用程序，并亲身体验几个小时来感受一下这个新的分类器性能是否有提升。这将是极其极其慢的！并且，如果你的团队将分类器的准确率从95.0%提升到95.1%，你可能无法通过亲身体验来感受到这0.1%的改进。而通过这些0.1%的不断改进，你的系统将取得很大的进步。有一个开发集和评估指标，你可以很快地检测出哪些想法给你的系统带来了小（或大）的改进，然后你就清楚地知道了哪些想法可以进一步改善，而哪些需要被舍弃。

4.何时更改开发/测试集和评估指标

当开始一个新项目时，我一般会试图快速选择一个 开发/测试集 ，因为这可以给团队制定一个明确的目标。

我通常会要求我的团队在不到一周之内想出一个初始的开发/测试集和评估指标。提出一个不太完美的方案并迅速行动起来往往比过分考虑这些会更好。但是“一周”这个时间表并不适用于成熟的应用。例如，反垃圾邮件是一个成熟的深度学习应用。我曾经见过那些开发已经成熟的系统的团队可能会花费数月时间来获得更好的开发/测试集。

如果你后来发现你初始的开发/测试集或评估指标与你的目标并不完全一致，那么通过一切手段快速更改它们。例如，如果在你的开发集和评估指标上分类器A比分离器B表现好，但你的团队认为实际应用中分类器B更适合您的产品，这可能是一个你需要更改开发/测试集或评估指标的迹象。

有三个主要原因可能会造成开发集/评估指标不正确地把分类器A排得更高：

1. 你需要做得好的实际数据分布和开发/测试集是不同的。 
   假设你的初始开发/测试集主要是一些成年猫的照片。你查看猫app的后台，发现用户上传了比预期多很多的幼猫的照片。所以，开发/测试集的数据分布并不能代表你需要做好的实际的数据分布。这种情况下，更新你的开发/测试集，使其更具代表性。 
   

2. 你已经过拟合了开发集。 
   在开发集上重复地评估不同方法的过程可能导致你的算法逐渐对开发集“过拟合（overfit）”。当你做完开发后，你将在测试集上评估你的算法。如果你发现算法在开发集上的表现远好于在测试集上的表现，这可能是你已经过拟合开发集的迹象。这种情况下，你需要更新你的开发集了。 
   如果你需要跟踪团队的进度，你也可以用测试集定期评估你的系统——每月或每周一次。但不要使用测试集来做出关于改进算法的任何决定，包括是否回退到上一周的系统。如果这样做了，你将开始过度拟合测试集，并且不可能再依靠它来给出系统性能的完全无偏估计（unbiased estimate）（你可能会在发表论文或做出重要商业决策是使用这个估计）。

3. 评估指标正在衡量的并不是项目所需要优化的东西。 
   假设对于你的猫app，你的评估指标是分类准确率。该指标现在把分类器A排在分类器B前面。但是假如你尝试了这两种算法，发现分类器A会偶尔允许色情图片通过。那么即使分类器A准确率更高，色情图片所带来的坏影响也意味着其表现是不被接受的。你需要做什么呢？ 
   这里，评估指标不能辨别出对产品而言算法B比算法A更好这一事实。所以，你不能再相信该指标能挑选出最佳算法。现在时改变评估指标的时候了。例如，你可以改变评估指标，严重惩罚色情图片分类错误。我强烈建议你选择一个新的评估指标，以此来为你的团队明确定义一个新的目标，而非在不信任的评估指标下一直前行，并恢复到手工选择分类器。

在项目中改变开发/测试集和评估指标是很常见的。拥有一个初始的开发/测试集和评估指标能帮助你快速迭代。如果你发现 开发/测试集和评估指标 不再使你的团队在正确方向上前进，这不是什么大问题！只需要改变它们，并确保你的团队知道新的方向。

5.小结

• 从分布中选择开发集和测试集，以反映你期望在未来获得的数据，并希望在上面做得很好。这可能和你的训练数据分布不同。
• 如果可能的话，选择来自同一分布的开发集和测试集。
• 为你的团队选择单一数字的评估指标进行优化。如果你关心多个目标，请考虑把它们合并到一个公式中（例如平均多个错误指标），或设定满足指标和优化指标。
• 机器学习是一个高度迭代的过程：在发现你满意的方法之前你可能需要尝试很多的idea。
• 具有开发/测试集和单一数字评估指标可以帮助你快速评估算法，因此迭代地更快。
• 当开始一个全新的应用时，尝试快速建立开发/测试集和评估指标，最好在一周之内。当然，在成熟的应用程序上花费更长的时间也是ok的。
• 依据70%：30%的比例划分训练/测试集这一经验性的方法不太适用于你拥有大量数据的情况；开发/测试集可以占有远小于30%的数据量。
• 你的开发集数据量应足够大，大到能检测出你的算法准确性上的有意义的改变，但没必要更大。你的测试集应该足够大，大到能对你的系统整体性能评估拥有一个很高的自信度。
• 如果你的开发集和评估指标不再使你的团队在正确方向上前进，快速改变它：（i）如果你过拟合了开发集，去获得更多的开发集数据。（ii）如果你所关心的实际分布和 开发/测试集 的分布不同，那么得到新的开发/测试集 数据。（iii）如果你的评估指标不再能衡量对你来说最重要的东西，请改变评估指标