在竞赛中，由于数据集较大分批收集标注，经常会出现提供的数据不符合测试集分布的情况，或者数据集分布不均匀。同样，在实际项目中，训练集和测试集有时也会有差距很大。
竞赛实例：
根据百度车道线冠军的经验：
数据清洗方面，该团队最一开始采用了全部数据训练，发现loss经常出现不规则的跳动，经过排查，发现road 3存在几乎一半以上图像过曝的问题，并且road 3大多在强光下拍摄，不符合测试集的分布，所以很果断的舍弃了road 3，分数也提升了0.01左右。
出现训练集与测试集分布不一致的情况时候。果断舍弃一些不符合测试集分布的数据，反而更有利于提高模型精度。
实际项目：
开发集和测试集的分布不同，很容易导致一个问题：你的团队所开发的系统可能在开发集上表现良好，却在测试集上表现不佳。我曾目睹过这样的事件，这令人十分沮丧并且还会浪费大量的时间，因此希望你不要重蹈他们的覆辙。
举个例子，假设你的团队开发了一套能在开发集上运行性能良好，却在测试集上效果不佳的系统。如果此时开发集和测试集的分布相同，那么你就能清楚地明白问题所在：算法在开发集上过拟合了（overfit）。
解决方案显然就是去获取更多的开发集数据。但是如果开发集和测试集服从不同的分布，解决方案就不那么明确了。此时可能存在以下一种或者多种情况：
1. 算法在开发集上过拟合了。
2. 测试集比开发集更难进行预测，尽管算法做得足够好了，却很难有进一步的提升空间。
3. 测试集不一定更难预测，但它与开发集性质并不相同（分布不同）。
因此在开发集上表现良好的算法不一定在测试集上也能够取得出色表现。如果是这种情况，大量针对开发集性能的改进工作将会是徒劳的。
构建机器学习应用已并非易事，而开发集和测试集分布的不匹配又会引入额外的不确定性—— 即提高算法在开发集上的性能表现，是否也能提升其在测试集的性能表现？在这种情况下很难去弄清楚哪些工作是有效的，哪些工作又是在浪费时间，从而会影响到工作的优先级安排。
在处理第三方基准测试（benchmark）问题时，样本提供方很可能已经指定了服从不同分布的开发集和测试集数据。与数据分布一致的情况相比，此时运气带来的性能影响将超过你使用的技术所带来的影响。因此，寻找能够在某个分布上进行训练，同时也能够很好地泛化到另一个分布上的学习算法，同样是一个重要的研究课题。但是如果你想要在特定的机器学习应用上取得进展，而不是搞研究，我建议你尽可能地选择服从相同分布的开发集和测试集数据，这会让你的团队更有效率。