MLY -- 11.When to change dev/test sets and metrics

当开始做一个新项目时，我会快速选择开发集和测试集，因为这会给团队一个明确的目标。

通常，我会要求我的团队在一周之内提出初始的开发集、测试集和度量，大多时候都不会多于一周。先提出一些不完美的东西使项目能前进下去，比过多考虑开发集、测试集、度量好的多。但是，一周时间线并不适用于成熟的应用。例如，垃圾邮件是一个成熟的深度学习应用。我曾见到在已经很成熟的系统上工作的团队花费数月的时间去获得好点儿的开发/测试集。
如果在后续开发中，你发现初始开发集、测试集、度量偏离了目标方向（missed the mark），一定要快速地改进。例如，如果你的开发集+度量使分类器A得分优于分类器B，但是你的团队认为分类器B实际上对你的产品更好，那么这就可能是你需要改进你的开发集、测试集或者度量的时候了。
1.实际的分布和开发集、测试集的分布不同
假设你初始的开发/测试集主要由成年猫的图片组成。当发布了app后，出乎意料，你发现用户会上传很多幼年猫的图片。此时，开发/测试集的分布就不能代表实际的分布了。在这种情况下，你需要更新开发/测试集，使其更具代表性。

2.过拟合开发集了
重复地用开发集来评价ideas可能导致过拟合开发集。当项目开发结束时，需要在测试集上评估你的系统。如果你发现开发集的表现比测试集好，那么这可能就是过拟合开发集了。在这种情况下，你需要一个新的开发集（a fresh dev set）。
如果你需要跟踪团队的进展，你可以用测试集定期评估你的系统（例如每周一次或每月一次）。但是不要用测试集做任何关于算法的决策，包括是否要回滚到上一个系统。如果你这么做了，系统将会开始过拟合测试集。并且不能再依赖测试集给出系统性能的完全无偏评估（当你发表论文或使用这个评估去做商业决策时就需要完全无偏评估）。
3.度量（the metric）中不包括项目需要优化的东西
假设对于猫分类器，你选择了分类准确度（classification accuracy）作为度量（metric），在这种度量下，分类器A比分类器B好。但是，当你实际去用这两种算法时，你发现分类器A偶尔会允许色情图片溜过去。即使分类器A准确率更高，但偶尔的一张色情图片会给用户留下坏印象，因此分类器A并不可取。
此时，度量未能分辨出算法B实际上比算法A好。因此，度量不再可信，是时候改变度量了。例如，你可以改变度量使其惩罚色情图片通过。我强烈建议选择一个新的度量，并用这个新度量为团队定义一个新目标，而不是在没有可信度量的情况下工作太长时间甚至恢复到手动选择分类器。
在项目期改变开发/测试集或评价度量是很常见的。初始的开发/测试集能帮助你快速进入迭代期。如果你发现开发/测试集或者度量不再能指引正确的方向，那也没事儿。只要改变它们并且保证你的团队知道新的方向就行了。