MLY -- 6.Your dev and test sets should come from the same distribution

根据你app应用的市场：（i）US，（ii）China，（iii）India，（iv）Other，你将猫图片数据分为四个部分。

若想要一个开发集和一个测试集时，我们可以随机地选两个作为开发集，剩下的两个作为测试集。例如，可以选US和India作为开发集，China和Other作为测试集。

一旦确定好了开发集和测试集，你的小团队将专注于提高学习算法在开发集上的表现。因此，开发集应该反映你想要改进的任务：在四个地理位置上表现都好，而不是两个。
此外，当开发集和测试集分布不同时，还会有问题：有可能你的团队将要构建一个在开发集上表现很好的东西，却发现这个东西在测试集上表现的很差。这种结果有多挫败和浪费精力，避免让它发生在你身上吧。
举个例子：假设你的团队做出的系统在开发集上表现很好，而在测试集上却表现不佳。如果你的开发集和测试集来自于用一个分布，那么你会知道是过拟合开发集(是否还有可能是训练集过拟合？)了，此时明显的解决办法就是获得更多开发集数据。
但是，若开发集和测试集来自不同的分布，那么就不容易找到解决方向了。有几个导致在测试集上表现不佳的原因：
1. 过拟合开发集
2. 测试集比开发集更严格。此时你的算法可能跟预期的一样好了，没有能改进很多的方法了
3. 测试集不一定更严格，只是和开发集不同而已。所以在开发集上表现好的算法不一定在测试集上表现的也好。对于这种情况，你为提高算法在开发集上的表现所做的工作，就没用了。

在“机器学习应用”上工作已经够难了，开发集和测试集不匹配又将会带来不确定性：若算法在开发集上表现提高，是否在测试集上表现也会提高？开发集和测试集的不匹配让我们更难找出什么样的解决方向能奏效，从而使得很难确定工作的优先级。
如果你正在处理 3rd party benchmark 问题，这个问题的创建者可能已经指定开发集和测试集来自不同的分布。在这种情况下，运气，而非技术，将会对算法表现有较大影响。如何将“在一个分布上训练的算法能泛化到其他分布上”是一个重要的科研问题。但是，如果你的目标是在一个特定的机器学习应用领域取得进步，而不是使科研问题进步，那么我建议你选择开发集和测试集来自同一分布，这会使你的团队更有效率。