根据公司的核心市场情况，你将猫咪app的图像数据划分为“美国”、“中国”、“印度”和“其它地区”四个区域。在设置开发集和测试集时，可以尝试将美国和印度的数据归于开发集，而中国和其它地区的数据归于测试集。也就是说我们可以随机地将其中两个区域分配给开发集，另外的两个区域分配给测试集。这样做对吗？显然是不对的。
一旦定义了开发集和测试集，你的团队将专注于提高开发集的性能，这就要求开发集能够体现任务的核心：使算法在四个地区都表现优异，而不仅仅是其中的两个。
开发集和测试集的分布不同伴随的第二个问题：你的团队开发的系统可能在开发集上表现良好，但在测试集上却表现不佳。我目睹过这样的事情发生，这将让人十分沮丧并且浪费大量的时间，因此希望你不要重蹈覆辙。
举个例子，假定你的团队开发了一套能在开发集上表现良好，却在测试集上效果不佳的系统。如果开发集和测试集分布相同，那么你就会非常清楚地知道问题在哪：在开发集上 过拟合 (overfit) 了。解决方案显然就是获得更多的开发集数据。
但是如果开发集和测试集来自不同的分布，解决方案就不那么明确了。此时可能存在以下一种或者多种情况：
- 在开发集上过拟合了。
- 测试集比开发集更难。尽管算法做得足够好了，却很难有进一步的改进空间。
- 测试集不一定更难，但却与开发集性质不同（分布不同）。因此在开发集上表现良好的算法不一定在测试集上也能够表现良好。如果是这种情况，大量改进开发集性能的工作都将是徒劳的。
构建机器学习应用已是一件难事，而开发集和测试集分布的不匹配又会引入额外的不确定性：提高算法在开发集上的性能表现，是否也会提升其在测试集的性能表现？开发集和测试集分布的不匹配导致很难弄清楚哪些工作是有效的，哪些工作是在浪费时间，从而会影响到工作的优先级确定。
在处理第三方基准 (benchmark) 问题时，提供方可能已指出了开发集和测试集数据是服从不同分布的。与数据分布一致的情况相比，此时运气带来的性能影响将超过你所使用的技巧带来的影响。开发在某个数据分布上进行训练后能够推广到另一个数据分布的学习算法，是一个重要的研究课题。但如果你只是想要在特定的机器学习应用上取得进展，而不是搞研究，我建议你尝试选择服从相同分布的开发集和测试集数据，这会让你的团队更有效率。