当开始一个新项目的时候，我会试图快速的选择开发/测试集，因为这样可以给团队一个很明确的目标。
我通常会要求我的团队在不到一周的时间内（几乎不会超过这个时间）提供一个初始的开发/测试集和评估指标，并且提出一个不太完美的方案迅速行动起来，这比花更多的时间去思考更好。但在一些比较成熟的应用上，一周时间可能不够，比如：反垃圾邮件（anti-spam）是一个成熟的深度学习应用。我见过一些团队会花费数月的时间在已完成的成熟系统上，去获得更好的开发集/测试集。
如果之后发现你最初的开发/测试集或评价指标与目标有些偏差，那么请修改它们。例如：如果你的开发集和评估指标在分类器A上表现的效果比B好，但是你的团队认为B在实际的产品中表现的更加优越，这可能表示你需要重新更改你的开发/测试集或者你的评价指标。
有三个主要原因导致开发集或评估指标错误的认为分类器A的效果更好：
- 你的实际数据与开发数据来自不同分布.
假设你的初始开发/测试集主要是一些成年猫咪的图片。而在APP上，用户上传了比预期多得多的幼年猫咪图片。所以导致你的开发集与测试集不在同一分布。在这种情况下，更新数据集是最好的选择。
算法在开发集上过拟合了 你把你的评估标准设置的过高，在开发集上反复评估导致算法过拟合，当完成开发后，如果你的算法在开发集上的效果明显高于在测试集上的效果，这就意味着你的算法在开发集上过拟合了。这种情况下，更新你的开发集。如果你需要跟踪团队进度，你也可以在测试集上定期对你的系统进行评估——每周或每月进行一次。但不要使用测试集来对你的算法进行改变。包括是否回滚到上一周的系统。如果你这样做，你的算法可能会在测试集上过拟合，并且不能在依靠它来对系统进行评估。 (如果你发表研究论文或者进行一个很重要的商业决策，就需要注意这一点).
评估指标衡量的并不是项目优化所需要的东西
假设对于你的猫咪APP，你的评估指标是分类准确率。在该指标下，分类器A优于分类器B。但是假设你尝试了这两种算法，发现分类器A偶尔会允许敏感图片通过。那么即使分类器A的精度优越于分类器B，偶尔让敏感图片通过，这是无法接受的。你需要做什么呢？这里，该评估指标不能辨别出对产品而言算法B比算法A好这一事实。所以，这时候你就不能相信这个指标可以帮你选择出最好的分类器，你需要重新选择评估指标。例如，你可以改变评估指标，当对敏感图片分类错误时对算法进行严厉“惩罚”。我强烈建议你选择一个新的评估指标，并用新的标准来为团队明确定义一个新的指标。而不是在一个不可信的指标下处理太长的时间。
在项目中改变开发/测试集或者评估指标是很常见的。拥有一个初始的开发/测试集和评估指标能帮你快速迭代你的idea。如果你发现你的开发/测试集或评估指标没有正确的引导你的团队前进，你可以随时更改它们。