11. 何时更改开发集/测试集和评估指标
Last updated
Last updated
当开始一个新的项目时,我会快速的选择开发集和测试集,因为这给团队一个明确定义的目标。
我通常会要求的团队在不到一周时间内提供出事开发/测试集和初始评价指标———很少会更长。最好能提出一些不完美的东西并迅速行动起来,而不是花更多时间过度思考这个问题。但是一周的时间表并不适用于成熟的应用。例如,反垃圾邮件是一种成熟的深度学习应用。我看到在成熟系统上工作的团队花费数月的时候来获取更好的开发集和测试集。
如果你后来意识到你的初始开发集和测试集并没有达到要求,那么一定要尽快更改它们。例如,你的开发集+评估指标认为分类器A好于分类器B,但你的团队认为分类器B更优,那么这可能表示你需要更改开发集/测试集或评估标准。
三个主要原因可能会引起在开发集/评估指标上分类器A发生得分更高的错误:
假设你的初始开发测试集主要是成年猫的图片。你发送你的猫应用程序并发现用户比预期上传更多的小猫图片。所以,开发集/测试集的分布并不代表很好的实际分布。在这种情况下,更新你的开发/测试集以使它更有代表性。
在开发集上重复评估想法会引起你的算法逐渐“过拟合”(overfit)到开发集。当你完成开发后,你将在测试集上评估你的系统。如果你发现算法在开发集的表现比在测试集上的表现好的多。这表明你过拟合了开发集。在这种情况下,获取一个新的开发集。
如果你需要跟踪团队的进度,你可以定期评估你的系统,比如在测试集上一周评估一次或者每月一次。但是不要使用测试集对算法做任何决定,包括回滚到一周前的系统。如果你这样做了,你将会开始过度适应测试集,并且不能依靠它来做完全无偏估计你的系统性能(如果你发表研究论文或者使用这个度量标准做重要的商业决定)。
假设对于你的猫应用程序,你的度量标准是分类准确率。这个度量标准目前认为分类器A优于分类器B。但是当你尝试了这两种算法的时候,发现分类器A偶尔会允许色情图片划过。即使分类器A准确率更高,但偶尔的色情图片留下的不良印象是不可接受的。你会怎么做呢?
这里,该度量标准并没有检测到对于产品而言,算法B事实上比A好的事实。所以你不能再相信你的评估指标可以选出最佳算法。现在是时候改变你的评估指标了。例如,你可以评估指标对色情图片进行严重处罚。我强烈建议你选择一个新的评估指标,并使用新的评估指标来为团队明确定一个新的目标,而不是在没有可信的度量标准情况下持续太长时间,并恢复到手动选择分类器的状态。
在项目中更改开发/测试集或评估指标是很常见的。使用初始开发/测试集和评估指标可帮助你快速迭代。如果你发现开发/测试集或评估指标不能指引你的团队朝着正确的方向发展,那这没什么!只要改变他们,并确保你的团队知道新的方向。