踩过坑才知道哪些路是不可行的，有时候犯错误也能帮助我们变得更加专业。

数据科学家ArchydeBerker在本文中详述了他和周围同伴们在机器学习探索中踩过的坑，这也都是大家经常性遇到的问题。他希望通过这一篇文章，带大家了解机器学习中一些有趣的错误——一些只有你深入了这个领域才能接触到的错误。

这不是一篇入门级的文章，想要读懂本文，最好先在Pytorch或Tensorow上多练习下毁坏模型。

本文主要集中在绿色分布的错误，但紫色分布和黄色分布也会部分涉及

一、机器学习中的常见错误

Berker将机器学习中出现的各种错误归为三大类，严重程度由低到高。

1、这些错误只会浪费你的时间

计算科学中最难的两件事是命名和缓存失效，图中这条推文高度概括了此类错误。shapeerror是最可怕又最常见的错误，通常是由于大小不一致的矩阵相乘导致。

本文不会花太多时间来讨论这类错误，因为错得非常明显。大家很容易找到错误，然后进行修复，然后再犯错，然后再修复。这是个不断重复的过程。

2.这些错误会导致结果不准确

这类错误会让你付出很大代价，因为它会造成模型结果不准确。

年，有一架从澳大利亚悉尼飞往马来西亚吉隆坡的亚航航班因出现技术故障，在墨尔本机场紧急降落。如果模型的结果不准确，就如同这架飞机的技术故障，最终会飞到错误的目的地。

举个例子，假如你在模型中新增了一个特征并同时增加了许多参数，在未进行超参数调优的情况下对比之前的性能，发现增加特征后模型性能变差了，于是得出结论，增加的特征会让模型性能变差。这是不对的，实际上你需要更加规范化的操作，以寻求更具表现力的模型。

错误对于模型的影响会随着时间而加重，导致更加不准确的实验结果。因此，尽早发现错误是非常有价值的。

3、这些错误会让你误认为自己的模型已经「完美」

这是很严重的错误，会让你高估模型的性能。这种错误通常很难发现，因为我们从心底里不愿承认看似”完美“的模型可能是假象。

当模型表现得出奇差时，我们倾向于不相信然后再测试一遍，但当模型表现得出奇好时，我们通常会相信并开始沾沾自喜。这就是所谓的确认偏差（ConfirmationBias），即个人无论合乎事实与否，都倾向于偏好支持自己的见解、猜想。

模型性能看似「完美」，通常是因为过拟合的原因，导致训练数据已经不再有代表性，或者是因为选错了评价指标，这两点后文都会详细解释。

如果你只能从本文带走一点，希望你记住：没有什么比你发现模型的真正结果实际上很糟糕这件事更令人尴尬和沮丧的了。

二、机器学习的生命周期

机器学习就如同上图香肠机的三个阶段一样：获取数据，将数据输入到模型中，然后通过一些指标来量化输出。

接下来我们会讨论到每个阶段中一些看似愚蠢的错误。

1、输出什么：评价指标

机器学习可以归结为不断减少损失函数值的过程。

但是，损失函数绝不是最终的优化目标，它只是一个近似值。例如训练分类任务时，通过交叉熵损失函数来优化训练集或者验证集，但实际上我们更加信任在测试集上的结果或者说F1、AUC评价指标。在实际优化目标的数据差异非常小的情况下，在模型评价上采用低置信度来加速评价过程会导致问题更加严重。

无论在哪种环境下，如果损失函数已经不能代表模型的真实表现，那么麻烦就大了。

此外还有一些让模型更糟糕的做法：

1）混合训练集和测试集

混合训练集和测试集是很容易的，而且通常会训练出来很不错的性能，但这样的模型在复杂的真实环境中会表现非常糟糕。

所以，训练集、验证集、测试集数据是不能相交的，各自需要包含不同的样本数据。我们要思考模型需要怎样的泛化能力，这最终会通过测试集的性能来量化。

以商店收据的数据为例，使用商店的收据进行分析预测，那么测试集显然需要包含以前没见过的新数据，但是测试集是否也需包含以前没见过的新商品以保证模型不会对特定商店过度测试呢(过拟合)？

最好的方式是一次性将数据分为训练集、验证集和测试集，然后放在不同的文件夹下，且命名都应该非常明确，例如TrainDataLoader和TestDataLoader。

2）错误使用损失函数

错误使用损失函数其实是很少出现的，因为已经有无数的材料教会大家如何使用损失函数。最常见的两种错误使用损失函数的情况，一个是搞不清楚损失函数要使用概率分布还是对数（即是否需要添加softmax），另一个就是混淆了回归函数和分类函数。

即使在学术界，混淆回归函数和分类函数也是很普遍的。例如亚马逊用户的评价和评星数据AmazonReviews数据集，经常被顶级实验室用于分类任务，但这其实是不太对的，因为与1星评价相比，5星评价显然更类似于4星评价，应该采用有序回归。

2、选错评价指标

不同的任务使用的损失函数不一样，而在模型性能的验证上，我们也经常组合多个侧重点不一样的评价指标来评估模型性能。例如，机器翻译首选BLEU作为评价指标，自动文摘采用ROUGE来验证性能，而对于其他任务，可以选用准确性，精确度或召回率作为评价指标。

通常，评价指标比损失函数容易让人理解。一个好的思路是尽可能多地记录日志。

认真思考如何划分不相交的训练集、测试集和验证集，让模型具有优异而不过度的泛化能力。在训练过程中可以使用评价指标来测试模型性能，而不必等到最后才开始使用测试集来测试。这样有助于更好地理解模型当前的训练结果，防止问题到最后才暴露。

评价指标的选择上要多注意。举个例子，你不能用简单使用准确性来评估序列模型的性能，因为序列间的非对齐情况会导致准确率为0。因此对于序列数据要采用距离来评估。选错评价指标是非常痛苦的事情。

还是以序列模型为例，请确保排除了所有特殊字符，特殊字符通常是序列的开头、结尾和填充。如果忘记了排除特殊字符，可能会得到看起来不错的模型性能，但这样的模型实际上只能预测充满填充字符的长序列。

有一个让作者印象非常深刻的错误，其曾经做过一些语义解析工作，目的是将自然语言语句转换为数据库查询，回答诸如「明天从蒙特利尔到亚特兰大有多少趟航班？」这样的典型SQL问题。为了评价模型的准确性，他们将模型转义的SQL查询发送到数据库，检查返回的内容是否与真实查询的内容匹配。他设置了一种情况，如果向数据库发送毫无意义的查询，数据库返回「error」。然后，他发送了已经被损坏的预测SQL和真实SQL到数据库查询，两者都返回「error」，模型将这种情况计算为：％准确。

这就引出了指导原则，你犯的任何错误只会使性能变差。要坚持检查模型实际做出的预测，而不仅仅是

转载请注明:http://www.aideyishus.com/lkgx/1546.html