总结自快速机器学习算法基准测试的重要经验

2017-11-30

根据KDNuggets网站的介绍,增强决策树正支撑着Kaggle机器学习挑战赛中超过半数的胜出解决方案。除了卓越的性能表现之外,这些算法亦拥有现实层面的吸引力——即最大程度降低调整需求。在今天的文章中,我们将评估两款高人气升级包:XGBoost与LightGBM,亦包括其GPU实现方案。如果您觉得文章太长而不想通读,那么我们会将对六套数据集进行测试所得出的结论总结如下:

  1. XGBoost与LightGBM拥有相似的准确度水平。
  2. LightGBM对于全部测试数据集,无论是在CPU抑或GPU之上,LightGBM的训练时长都要短于XGBoost及其基于直方图方法的XGBoost hist。两套库之间的训练时间差异主要取决于实际数据集,且时耗差别可高达25倍。
  3. XGBoost GPU实现方案无法有效扩展至大型数据集当中,并曾在测试过程当中发生内存不足问题。
  4. 当特征维度较高时,XGBoost hist的执行速度往往明显低于原始XGBoost。

我们的全部代码皆属于开源成果,且可从此repo当中获取。我们将解释这些库当中所使用的具体算法,同时立足不同数据集对其加以评估。您是否希望自己的机器学习方案拥有更快的运行速度?如果是,请跟着我们的脚步继续推进。

增强决策树基础知识

梯度增强属于一种机器学习技术,其能够以弱分类器集合的形式生成预测模型,同时对可微损失函数进行优化。目前最具人气的梯度增强类型之一正是增强决策树,其内部由一组弱决策树集合组成。目前有两种不同策略可进行树计算:逐级与逐叶。其中逐级策略以逐级方式进行树状结构创建。通过这种策略,各个节点通过分割数据对靠近树根处的节点进行优先级排序。逐叶策略则立足损失变化最大的节点处进行数据分割。对于规模较小的数据集而言,逐级增长往往效果更好(逐叶增长在这类场景下往往存在过度拟合问题); 而逐叶增长则比较合适应用于大规模数据集——这是因为其速度表现要明显优于逐级增长。

(点击放大图像)

逐级增长策略对逐叶增长策略。其中逐级增长策略会随着树状层级数量的增加而带来较高复杂性。相比之下,逐叶策略则通过优化损失函数的方式生成分支。

训练强化决策树过程中的一大挑战,在于为各个“叶”找到最佳分割计算成本。对于常规技术而言,要找到各叶的精确分割方式,需要对每一次迭代当中的全部数据进行扫描。而另一种可行方法则通过构建特征直方图找出粗略分割方式。如此一来,算法本身将不必评估特征中的每个单一值,而只需计算直方图边界即可完成分割计算。这样的处理方式对于大型数据集而言效率更高,且不致对准确度产生不利影响。

XGBoost项目始于2014年,且目前已经在多轮Kaggle挑战赛中取得优胜并积累起可观人气。最初的XGBoost基于一套逐级增长算法,但近期其亦添加了新的逐叶增长选项,旨在利用直方图实现近似分割。我们将这套版本称为XGBoost hist。LightGBM的面世时间则更晚,始于2016年3月,并于同年8月转为开源项目。其基于逐叶算法与直方近似值,且凭借着出色的速度表现而得到高度关注(免责声明:本篇文章的联合作者之一Guolin Ke为LightGBM项目的核心贡献者之一)。除了多线程CPU之外,目前XGBoost与LightGBM亦皆可利用GPU实现加速。

评估XGBoost与LightGBM

我们面向六组不同数据集进行了机器学习测试。这些实验皆被保存在我们GitHub repo当中的Python notebook当中,感兴趣的朋友可以点击此处查看。我们还展示了实验中使用的XGBoost与LightGBM具体编译版本,同时提供实验的安装与设置步骤说明。另外,我们还尝试利用CPU与GPU处理分类与回归问题。全部实验皆运行在一套Azure NV24虚拟机当中,其拥有24个计算核心、224 GB内存以及英伟达M60 GPU。操作系统选择了Utuntu 16.04。在全部实验当中,我们发现XGBoost与LightGBM的准确度表现基本相当(可参见F1评分),因此本文将专注于讨论其训练时间差异。下表所示为这两套库在CPU与GPU场景下的训练时长与训练时间比。

(点击放大图像)

CPU与GPU场景下XGBoost与LightGBM训练时间与训练时间比测试结果比较。其中XGBoost GPU训练时间并未显示(-),因为我们在过程中遭遇内存不足问题。而在CPU场景下利用XGBoost处理Airline数据集时(-*),我们在5小时后停止了计算。各组数据集的最佳训练时间以黑体显示。

来自测试的启示

虽然基准测试不能代表一切,但其中部分结论确实有其价值。通过实验,我们发现逐叶方法一般而言较逐级方法速度更快。然而,CPU场景下的BCI与Planet Kaglle数据集处理结果,以及GPU场景下的GCI处理结果显示,XGBoost hist的处理时长要远长于标准XGBoost。这主要是由于数据集本身拥有庞大的体积与特征数量,导致XGBoost需要耗费极为可观的内存资源。

我们同时发现,XGBoost的GPU实现方案在扩展性方面表现较差——其在3套规模较大的数据集处理过程中皆引发了内存错误。此外,我们不得不在5个小时之后人为中止了XGBoost在Airline数据集上的训练。

最后,在LightGBM与XGBoost之间,我们发现LightGBM在全部测试中皆带来优于XGBoost与XGBoost hist的速度表现,且实际速度最高可达XGBoost的25倍与XGBoost hist的15倍。

我们希望调查不同数据集规模及轮数对于CPU及GPU性能的影响。在下表当中,我们展示了使用Airline数据集内某一子集时的处理结果。在对CPU及GPU的训练时间进行比较时,我们发现LightGBM的GPU版本在数据集较大且轮数越多时,拥有超越CPU版本的表现。而正如预期那样,在使用小型数据集时,RAM与GPU内存之间的数据复制IO开销被GPU自身的计算速度优势所抵消。而值得一提的是,我们在使用XGBoost hist GPU版本时并没有发现任何性能提升效果。顺带解释一句,根据近期的其它研究文章,与多核心CPU相比,XGBoost的标准版本(即采用精确分割而非直方图方法)同样无法在GPU场景下得到提升。

(点击放大图像)

.XGBoost、XGBoost hist以及LightGBM训练时间基准测试与不同数据规模及轮数情况下的AUC结果。与之前一样,XGBoost在GPU场景下的1亿行实验同样因内存不足而未能得出结果(-)。XGBoost的1亿行500轮训练则在运行5小时后被我们人为中止(-*)。各示例的最佳训练时间与最高AUC结果以黑体显示。

总体而言,我们发现LightGBM在CPU与GPU场景下的速度表现皆优于XGBoost。另外,如果大家决定使用XGBoost,我们建议您密切关注特征维度与内存消耗情况。LightGBM显著的速度优势将可转化为对更多迭代进行搜索的能力及/或更快的超参数搜索速度。因此,如果您可用于模型优化的时间较为有限,或者希望尝试更多不同的特征工程思路,那么LightGBM无疑将成为更理想的选择。

祝各位工作愉快!

查看原文链接

没有评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注