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