（转）机器学习：开发集和测试集

转子吴恩达deeplearningai

 

根据公司的核心市场情况，你将猫咪 app 的图像数据划分为“美国”、“中国”、“印度”和“其它地区”四个区域。在设立开发集和测试集时，可以尝试将美国和印度的数据归于开发集，而中国和其它地区的数据归于测试集。也就是说我们可以随机地将其中两个区域分配给开发集，另外的两个区域分配给测试集。这样做对吗？

 

 

当然不对！一旦定义了开发集和测试集，你的团队将专注于提高开发集的性能表现，这就要求开发集能够体现任务的核心：使算法在四个地区都表现优异，而不仅仅是其中的两个。

开发集和测试集的分布不同还将导致第二个问题：你的团队开发的系统可能在开发集上表现良好，但在测试集上却表现不佳。我目睹过这样的事情发生，这将让人十分沮丧并且浪费大量的时间，因此希望你不要重蹈覆辙。

举个例子，假设你的团队开发了一套能在开发集上运行性能良好，却在测试集上效果不佳的系统。如果开发集和测试集分布相同，那么你就会非常清楚地知道问题在哪：在开发集上过拟合了（overfit）。解决方案显然就是获得更多的开发集数据。

但是如果开发集和测试集来自不同的分布，解决方案就不那么明确了。此时可能存在以下一种或者多种情况：
1. 在开发集上过拟合了。
2. 测试集比开发集更难进行预测，尽管算法做得足够好了，却很难有进一步的改进空间。
3. 测试集不一定更难预测，但与开发集性质不同（分布不同）。因此在开发集上表现良好的算法不一定在测试集上也能够表现良好。如果是这种情况，大量改进开发集性能的工作将会是徒劳的。

构建机器学习应用已是一件难事，而开发集和测试集分布的不匹配又会引入额外的不确定性，即提高算法在开发集上的性能表现，是否也会提升其在测试集的性能表现？在这样的情况下很难弄去清楚哪些工作是有效的，哪些工作是在浪费时间，从而会影响到工作的优先级确定。

 

在处理第三方基准测试（benchmark）问题时，提供方可能已经指定了服从不同分布的开发集和测试集数据。与数据分布一致的情况相比，此时运气带来的性能影响将超过你所使用的技巧带来的影响。找到能够在某个分布上进行训练，并能够推广到另一个分布的学习算法，是一个重要的研究课题。但如果你想要在特定的机器学习应用上取得进展，而不是搞研究，我建议你尝试选择服从相同分布的开发集和测试集数据，这会让你的团队更有效率。

开发集的规模应该大到足以区分出你所尝试的不同算法间的性能差异。例如，如果分类器 A 的准确率为 90.0% ，而分类器 B 的准确率为 90.1% ，那么仅有 100 个样本的开发集将无法检测出这 0.1% 的差异。相比我所遇到的机器学习问题，一个样本容量为 100 的开发集的规模是非常小的。通常来说，开发集的规模应该在 1,000 到 10,000 个样本数据之间，而当开发集样本容量为 10,000 时，你将很有可能检测到 0.1% 的性能提升。

从理论上说，还可以检测算法的变化是否会在开发集上造成统计学意义上的显著差异。 然而在实践中，大多数团队并不会为此而烦恼（除非他们正在发表学术研究论文），而且我在检测过程中并没有发现多少有效的统计显著性检验。

像广告服务、网络搜索和产品推荐等较为成熟且关键的应用领域，我曾见过一些团队非常积极地去改进算法性能，哪怕仅有 0.01% 的提升，因为这将直接影响到公司的利润。在这种情况下，开发集规模可能远超过 10,000 个样本，从而有利于检测到那些不易察觉的效果提升。

那么测试集的大小又该如何确定呢？它的规模应该大到使你能够对整体系统的性能进行一个高度可信的评估。一种常见的启发式策略是将 30% 的数据用作测试集，这适用于数据量规模一般的情况（比如 100 至 10,000 个样本）。但是在大数据时代，我们所面临的机器学习问题的样本数量有时会超过 10 个亿，即使开发集和测试集中样本的绝对数量一直在增长，可总体上分配给开发集和测试集的数据比例正在不断降低。可以看出，我们并不需要远超过评估算法性能所需的开发集和测试集规模，即开发集和测试集的规模并不是越大越好。