11. When to change dev/teset sets and metrics
开始一个新项目时，我一般试着快速选出开发/测试集，因为这可以给团队一个明确的目标。
我通常要求我的团对在一周之内想出一个初始的开发/测试集和一个初始指标—从不会长于一周。提出一个不太完美的方案并且快速行动起来往往比过度思考要好的多。但是一周这个时间并不应用在成熟的应用中。比如，垃圾邮件识别是一个成熟的深度学习应用。我曾经见过许多团队在已经成熟的系统上花费数月来获取更好的开发/测试集。
如果你后来意识到你初始的开发/测试集或者指标与目标不一致，那么快速更改它们。比如，如果在你的开发集和指标上分类器A比分类器B好，但是你的团队认为分类器B在实际中更适合你的产品，这可能意味着你需要更改你的开发/测试集或评估指标。
有三个主要的原因可能会造成开发集/评估指标错误的把分类器A排的更高：
- 你需要做的好的实际数据的分布和开发/测试集是不同的。
假设你初始的开发/测试集主要是成年的猫。你查看你的猫分类器app，发现用户上传了比预测多了许多的小猫图片。因此，开发/测试集分布不能体现真实的分布。在这个案例中，更新你的开发/测试集，使其更具有代表性。
- 在开发集上过拟合。
在开发集上重复地评估各种想法的过程导致你的算法最终在开发集上发生了“过拟合”。当你完成开发后，你会在测试集上评估你的系统。如果你发现你的算法在开发集上的表现比在测试集上表现的要好的多时，这意味着你的算法在开发集上产生了“过拟合”。这种情况下，需要更新你的开发集。
如果你需要跟踪你团队的进程，你也可以有计划地在测试集上评估你的系统—一周一次或一月一次。但是不要使用测试集对你的算法做任何决定，包括是否回滚回上一周的系统。如果你这样做了，那么开始在测试集上形成过拟合，并且不可能依靠它来给系统性能做出完全无偏估计(unbiased estimate)(在你发表研究论文或使用这个指标做出重要的商业决策时你可能会使用无偏估计)。
- 评估指标是用来衡量的而不是项目需要优化的
比如对你的应用，你的评估指标是分类精度。这个指标当前认为分类器A比分类器B好。但是假如你尝试了两种算法，你发现分类器A偶尔会允许色平图片通过。即使分类器A更加精确，但是偶尔通过的色情图片产生的坏影响也意味着分类器的表现是不可接受的，你怎么做呢？
这个例子中，评价指标就不能确定对于你的产品算法B比算法A更好这个事实。因此，你不能一味相信评估指标能选择更好的算法。是是时候改变评估指标了。比如，你可以改变评估指标，对色平图片通过的分类器加严格的惩罚项。我强烈建议选择一个新的指标并且使用新的指标为你的团队明确定义一个新目标，而不是在不信任的指标下一直前行，并通过手工在分类器中做选择。
在一个项目中改变开发/测试集或评估指标是很常见的。使用初始开发/测试集和评估指标可以帮你快速的迭代。如果你最终发现开发/测试集或者评估指标不在指导你的团队向正确的方向，没什么大不了！仅需要改变他们并且确保你的团队了解新的方向。
