2020-7-13 吴恩达DL学习-C3结构化ML项目-w2 ML策略2(2.2 清楚标注错误的数据--如何判断是否值得修改/如何修改)

274 篇文章 24 订阅
233 篇文章 0 订阅

1.视频网站:mooc慕课https://mooc.study.163.com/university/deeplearning_ai#/c
2.详细笔记网站(中文):http://www.ai-start.com/dl2017/
3.github课件+作业+答案:https://github.com/stormstone/deeplearning.ai

你的监督学习数据由输入 x x x和输出标签 y y y构成。如果你观察一下你的数据,会发现有些输出标签错误,那么是否值得花时间去修正这些标签呢?

1.标记错误的样本

在这里插入图片描述

如上图,在猫分类问题中,图片是猫, y = 1 y=1 y=1;不是猫, y = 0 y=0 y=0
假设你看了一些数据样本,发现倒数第二张图片其实不是猫,所以这是标记错误的样本。“标记错误的样本”表示你的学习算法输出了错误的 y y y值。

对于标记错误的样本,在你的训练集或者测试集中 y y y的标签,人类给这部分数据加的标签,实际上是错的。上图中实际上是一只狗,所以 y y y其实应该是0,也许做标记的那人疏忽了。如果你发现你的数据有一些标记错误的样本,你该怎么办?

1-1.训练集

首先,我们来考虑训练集。
事实证明,DL算法对于训练集中的随机错误是相当健壮的(robust)。有时可能做标记的人没有注意或者不小心,按错键了。只要这些错误样本离随机错误不太远,如果错误足够随机,那么放着这些错误不管可能也没问题,而不要花太多时间修复它们。

DL algorithms are quite robust to random errors in the training set.

当然你浏览一下训练集,检查一下这些标签,并修正它们也没什么害处。有时候修正这些错误是有价值的,有时候放着不管也可以,只要总数据集总足够大,实际错误率可能不会太高。我见过一大批ML算法训练的时候,明知训练集里有些错误标签,但最后训练出来也没问题。

提醒一下,DL算法对随机误差很健壮,但对系统性的错误就没那么健壮了。
所以比如说,类似上图中的例子,如果做标记的人一直把白色的狗标记成猫,那就成问题了。因为你的分类器学习之后,会把所有白色的狗都分类为猫。但随机错误或近似随机错误,对于大多数DL算法来说不成问题。

1-2.开发集/测试集

其次,如果是开发集和测试集中有这些标记出错的样本呢?
如果你担心开发集或测试集上标记出错的样本带来的影响,一般建议你在错误分析时,添加一个额外的列(如下图,上一节课使用过该统计表),这样你可以统计标签 y y y错误的样本数。
在这里插入图片描述

如上图,比如说你想统计一下对100个标记出错的样本的影响,所以你会找到100个样本,其中你的分类器的输出和开发集的标签不一致。有时对于其中的少数样本,你的分类器输出和标签不同,是因为标签错了,而不是你的分类器出错。

假设在98号样本中,你发现标记的人漏了背景里的一只猫,所以在 “Incorrectly labeled” 列打个勾,来表示98号样本标签出错了。

假设100号样本实际上是猫的画,而不是一只真正的猫,也许你希望标记数据的人将它标记为 y = 0 y=0 y=0,而不是 y = 1 y=1 y=1,然后再在 “Incorrectly labeled” 列打个勾。

最终,正如上节课中介绍过的,当你统计出其他错误类型的百分比后(8%是狗,可能43%属于大猫,61%属于模糊),你还可以统计因为标签错误所占的百分比 6%,这就解释了为什么你的学习算法做出和数据集里的标记不一样的预测。

2.是否值得修正错误的样本

现在问题是,是否值得修正这6%标记出错的样本。
我的建议是,如果这些标记错误严重影响了你在开发集上评估算法的能力,那么就应该去花时间修正错误的标签。但是,如果它们没有严重影响到你用开发集评估成本偏差的能力,那么可能就不应该花宝贵的时间去处理。

那么如何判断是否影响开发集上评估算法能力呢?
可以通过看3个数字来确定是否值得去人工修正标记出错的数据。
在这里插入图片描述
例1

  • 整体的开发集错误率 Overall dev set error – 10%
    假设我们的猫分类系统达到了90%整体准确度,所以有10%错误率,那么你应该看看错误标记引起的错误数量或者百分比。

  • 错误标记引起的错误数量或者百分比 Errors due incorrect labels – 0.6%
    现在6%的错误来自标记出错,所以10%的6%就是0.6%。最后你应该再看看其他原因导致的错误

  • 其他原因导致的错误Errors due to other causes
    你的开发集上有10%错误,其中0.6%是因为标记出错,剩下的占9.4%,是其他原因导致的,比如把狗误认为猫,或者大猫图片,或者图片模糊。

根据上面的分析,有9.4%错误率需要集中精力修正,而标记出错导致的错误是总体错误的一小部分而已。所以如果你一定要这么做,你也可以手工修正各种错误标签,但也许这不是当下最重要的任务。

例2
再看另一个例子。

假设你在学习问题上取得了很大进展,错误率不再是10%了,而是降到了2%,但总体错误中的0.6%还是标记出错导致的。所以现在,如果你想检查一组标记出错的开发集图片,那么其中很大一部分,0.6%除以2%,实际上变成30%占比而不是6%了。而现在其他原因导致的错误是1.4%。当测得的那么大一部分的错误都是开发集标记出错导致的,修正开发集里的错误标签似乎变得更有价值。

如果你还记得设立开发集的目标的话,开发集的主要目的是,你希望用它来从两个分类器 A A A B B B中选择一个。

Goal of dev set is to help you select between two classifiers A & B.

所以当你测试两个分类器 A A A B B B时,一个在开发集上一个有2.1%错误率,另一个有1.9%错误率,但是你不能再信任开发集了,它无法告诉你 A A A这个分类器是否比 B B B这个好,因为0.6%的错误率是标记出错导致的。

现在你就有很好的理由去修正开发集里的错误标签,因为在例2中标记出错对算法错误的整体评估标准有严重的影响。而例1中标记出错对你算法影响的百分比还是相对较小的。

3.修正开发集/测试集样本

现在如果你决定要去修正开发集数据,手动重新检查标签,并尝试修正一些标签,这里还有一些额外的方针和原则需要考虑。

  • 首先,我鼓励你不管用什么修正手段,都要同时作用到开发集和测试集上

我们之前讨论过为什么开发和测试集必须来自相同的分布。开发集确定了你的目标,当你击中目标后,你希望算法能够推广到测试集上,这样你的团队能够更高效的在来自同一分布的开发集和测试集上迭代。如果你打算修正开发集上的部分数据,那么最好也对测试集做同样的修正以确保它们继续来自相同的分布。

Apply same process to your dev and test sets to make sure they continue to come from the same distribution

  • 其次,我强烈建议你要考虑同时检验算法判断正确和判断错误的样本

要检查算法出错的样本很容易,只需要看看那些样本是否需要修正,但还有可能有些样本算法判断正确,那些也需要修正。如果你只修正算法出错的样本,你对算法的偏差估计可能会变大,这会让你的算法有一点不公平的优势,我们就需要再次检查出错的样本,但也需要再次检查正确的样本,因为算法有可能因为运气好把某个东西判断对了。在这种特例里,修正那些标签可能会让算法从判断对变成判断错。这第二点不是很容易做,通常不会这么做,原因是,如果你的分类器很准确,那么判断错的次数比判断正确的次数要少得多。假设有2%出错,98%是对的,所以更容易检查2%数据上的标签,然而检查98%数据上的标签要花的时间长得多,所以通常不这么做,但也是要考虑到的。

Consider examining examples your algorithm got right as well as ones it got wrong.

  • 最后,如果你进入到一个开发集和测试集去修正这里的部分标签,你可能会,也可能不会去对训练集做同样的事情。

修正训练集中的标签其实相对没那么重要,你可能决定只修正开发集和测试集中的标签,因为它们通常比训练集小得多,你可能不想把所有额外的精力投入到修正大得多的训练集中的标签,这样其实是可以的。你的开发集和测试集来自同一分布非常重要。但如果你的训练集来自稍微不同的分布,通常这是一件很合理的事情。

Train and dev/test data may now come from slightly different distributions.

4.两点建议

最后我讲几个建议:

首先,深度学习研究人员有时会喜欢这样说:“我只是把数据提供给算法,我训练过了,效果很好”。这话说出了很多DL错误的真相,更多时候,我们把数据喂给算法,然后训练它,并减少人工干预,减少使用人类的见解。但我认为,在构造实际系统时,通常需要更多的人工错误分析,更多的人类见解来架构这些系统,尽管DL的研究人员不愿意承认这点。

其次,不知道为什么,我看一些工程师和研究人员不愿意亲自去看这些样本,也许做这些事情很无聊,坐下来看100或几百个样本来统计错误数量,但我经常亲自这么做。当我带领一个ML团队时,我想知道它所犯的错误,我会亲自去看看这些数据,尝试和一部分错误作斗争。我想就因为花了这几分钟,或者几个小时去亲自统计数据,真的可以帮你找到需要优先处理的任务,我发现花时间亲自检查数据非常值得,所以我强烈建议你们这样做,如果你在搭建你的ML系统,想确定应该优先尝试哪些想法,或者哪些方向。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值