当开始一个新项目，我试图迅速选择开发/测试集，因为这给团队定义了一个明确的目标。
我通常要求我的团队在一周之内找到初始开发/测试集和初始评估指标。从不完美的开始，并迅速行动起来，比过度思考要更好。但这个一周的时间要求并不适用于成熟的应用。比如，反垃圾邮件是一个成熟的深度学习应用。我曾经见过一些有着成熟系统的团队花费数个月获取更好的开发/测试集。
如果你后来意识到你的初始开发/测试集或评估指标和目标不一致，那么迅速地使用一切手段改变它们。比如，如果在你的开发集和评估指标上分类器A比分类器B表现得好，但是你的团队认为分类器B在你的产品上表现会更好，那么这可能就是你需要改变开发/测试集或评估指标的信号。
有三个主要原因可能导致开发/测试集把分类器A排得更高：
-
你要表现得好的数据实际分布和开发/测试集不一致；
假设初始开发/测试集主要是成年猫的图片。你发布app，发现用户上传了比预期更多的幼猫的图片。这样，开发/测试集的分布不能代表你需要做得好的数据的实际分布。在这种情况下，更新你的开发/测试集，使得更具有代表性。
你过拟合了开发集
在开发集上重复评估想法的过程导致你的算法逐步“过拟合”（overfit）开发集。当你完成开发，你需要在测试集上评估你的系统。如果发现开发集性能远好于测试集，这是你过拟合开发集的信号。在这种情况下，你需要更新开发集。
如果你需要跟踪你的团队的进展，你也可以在测试集上定期（比如一周一次或一个月一次）评估你的系统。但是不要使用测试集为算法制定任何决定，包括是否回退到上一周的系统。如果这样做，你将开始过拟合测试集，而且再也不能在上面对系统性能做无偏估计（你可能在发表论文需要这个估计，或使用这个估计制定重要的商业决策）。评估指标衡量的不是项目需要优化的
假设对于你的猫app，评估指标是分类准确率。在这个指标下分类器A比分类器B表现得好。但是假设你尝试了两种算法，发现分类器A偶尔会允许色情图片通过。即使分类器A具有更好的准确率，色情图片偶尔的通过带来的坏影响导致它的性能不可接受。你会怎么做？
此处，实际上评估指标不能识别出对于你的产品算法B比算法A更好。所以你不再相信这个评估指标可以获取最好的算法。是时候改变评估指标了。比如，你可以将评估指标修改为严重惩处色情图片。我强烈推荐选择一个新的评估指标，并使用该指标为团队定义一个新目标，而不是长时间在不信任的评估指标下继续前行，并回退到人工选择分类器。
在项目中改变开发/测试集或评估指标很正常。有一个初始的开发/测试集和评估指标可以帮助你快速迭代。如果你发现开发/测试集或评估指标不再指引你的团队走向正确的方向，这不是什么大问题！改变它们，并确保你的团队指导新的方向。
