首页 > 其他分享> > 如何看待微软新开源的LightGBM?

如何看待微软新开源的LightGBM?

2021-06-26 23:30:11 作者：互联网

地址：GitHub - Microsoft/LightGBM: LightGBM is a fast, distributed, high performance gradient boosting (GBDT, GBRT, GBM or MART) framework based on decision tree algorithms, used for ranking, classification and many other machine learning tasks.
与Xgboost相比如何

Experiments · Microsoft/LightGBM Wiki · GitHub
看他们自己实验的结果，真是惊人

https://github.com/guolinke

497 人赞同了该回答

03/26/2020 更新：

这两年内，多亏了大量的贡献者，LightGBM 迭代很多新版本，功能上越来越丰富，文档越来越完整，用户越来越多，速度也越来越快（相比两年前的版本，速度提高了近一倍）。

值得一提的是，XGBoost 也实现了 histogram 算法，比原来presorted算法快了不少。但相比LightGBM，还是慢了一些，且内存占用还是比较大。具体可以参考：https://github.com/microsoft/LightGBM/blob/master/docs/Experiments.rst#comparison-experiment

10/19/2017 更新：

完整的更新列表可以参考： Microsoft/LightGBM/Key-Events.md

下面列出一些比较大的更新

R-package 已完成
缺失值（missing value）的自动处理
类别特征(Categorical Feature) 的进一步优化，不再使用类似one-hot coding的分割方式。对于类别数量很多的类别特征，使用one-vs-other的切分方式会长出很不平衡的树，不能实现较好的精度。这是树模型在支持类别特征的一个痛点。 LightGBM可以找出类别特征的最优切割，即many-vs-many的切分方式。并且最优分割的查找的时间复杂度可以在线性时间完成，和原来的one-vs-other的复杂度几乎一致。

cf: NIPS 2017 有什么值得关注的亮点？

12/17/2016 更新：

完成了python-package，欢迎使用。
直接支持类别特征(Categorical Feature)，不需要进行0/1展开。相对0/1展开的解决方案，速度快非常多，且精度一致。

大多数机器学习工具都无法直接支持类别特征作为输入，一般需要转换成多维0/1特征，带来计算和内存上的额外消耗。LightGBM增加了针对于类别特征的决策规则，这在决策树上也很好实现。主要的思想是，在对类别特征计算分割增益的时候，不是按照数值特征那样由一个阈值进行切分，而是直接把其中一个类别当成一类，其他的类别当成另一类。这实际上与0/1展开的效果是一样的。

---------------------------------------

正好开源了一个月，强答一下。

GBDT 虽然是个强力的模型，但却有着一个致命的缺陷，不能用类似 mini batch 的方式来训练，需要对数据进行无数次的遍历。如果想要速度，就需要把数据都预加载在内存中，但这样数据就会受限于内存的大小；如果想要训练更多的数据，就要使用外存版本的决策树算法。虽然外存算法也有较多优化，SSD 也在普及，但在频繁的 IO 下，速度还是比较慢的。

为了能让 GBDT 高效地用上更多的数据，我们把思路转向了分布式 GBDT，然后就有了 LightGBM。设计的思路主要是两点，1. 单个机器在不牺牲速度的情况下，尽可能多地用上更多的数据；2.
多机并行的时候，通信的代价尽可能地低，并且在计算上可以做到线性加速。

基于这两个需求，LightGBM 选择了基于 histogram 的决策树算法。相比于另一个主流的算法 pre-sorted（如 xgboost 中的 exact 算法），histogram 在内存消耗和计算代价上都有不少优势。

Pre-sorted 算法需要的内存约是训练数据的两倍(2 * #data * #features
* 4Bytes)，它需要用32位浮点来保存 feature value，并且对每一列特征，都需要一个额外的排好序的索引，这也需要32位的存储空间。对于 histogram 算法，则只需要(#data
* #features * 1Bytes)的内存消耗，仅为 pre-sorted算法的1/8。因为 histogram 算法仅需要存储 feature bin value (离散化后的数值)，不需要原始的 feature value，也不用排序，而 bin value 用 uint8_t (256 bins) 的类型一般也就足够了。
Pre-sorted 算法虽然理论上可以过一次数据，长满一层叶子。但由于每个特征对梯度的访问顺序都是随机的，且访问顺序不一样。这么多的随机访问会有很大的cache miss，导致实际运行效率低很多。而 histogram 算法里，不同特征访问梯度的顺序是一样的，可以提前把梯度存在连续的数组中，让不同特征访问的时候都是连续的，不会产生cache miss的问题
另一个计算上的优势则是大幅减少了计算分割点增益的次数。对于一个特征，pre-sorted 需要对每一个不同特征值都计算一次分割增益，而 histogram 只需要计算 #bin (histogram 的横轴的数量) 次。
最后，在数据并行的时候，用 histgoram 可以大幅降低通信代价。用 pre-sorted 算法的话，通信代价是非常大的（几乎是没办法用的）。所以 xgoobst 在并行的时候也使用 histogram 进行通信。

当然， histogram 算法也有缺点，它不能找到很精确的分割点，训练误差没有 pre-sorted 好。但从实验结果来看， histogram 算法在测试集的误差和 pre-sorted 算法差异并不是很大，甚至有时候效果更好。实际上可能决策树对于分割点的精确程度并不太敏感，而且较“粗”的分割点也自带正则化的效果。

在 histogram 算法之上， LightGBM 进行进一步的优化。首先它抛弃了大多数 GBDT 工具使用的按层生长
(level-wise) 的决策树生长策略，而使用了带有深度限制的按叶子生长 (leaf-wise) 算法。 level-wise 过一次数据可以同时分裂同一层的叶子，容易进行多线程优化，不容易过拟合。但实际上level-wise是一种低效的算法，因为它不加区分的对待同一层的叶子，带来了很多没必要的开销。因为实际上很多叶子的分裂增益较低，没必要进行搜索和分裂。leaf-wise则是一种更为高效的策略，每次从当前所有叶子中，找到分裂增益最大(一般也是数据量最大)的一个叶子，然后分裂，如此循环。因此同 level-wise 相比，在分裂次数相同的情况下，leaf-wise 可以降低更多的误差，得到更好的精度。leaf-wise 的缺点是可能会长出比较深的决策树，产生过拟合。因此 LightGBM 在leaf-wise 之上增加了一个最大深度的限制，在保证高效率的同时防止过拟合。

另一个比较巧妙的优化是 histogram 做差加速。一个容易观察到的现象：一个叶子的直方图可以由它的父亲节点的直方图与它兄弟的直方图做差得到。通常构造直方图，需要遍历该叶子上的所有数据，但直方图做差仅需遍历直方图的 k 个桶。利用这个方法，LightGBM 可以在构造一个叶子的直方图后，可以用非常微小的代价得到它兄弟叶子的直方图，在速度上可以提升一倍。

如需要更多的细节，可以参考github上的文档：https://github.com/Microsoft/LightGBM/wiki/Features

编辑于 2020-03-26

292 人赞同了该回答

非常赞的工作，实现了和XGBoost不一样的搜索策略，所以在算法效果上并不是完全一样。

- XGBoost在单机默认是exact greedy，搜索所有的可能分割点。分布式是dynamic histogram，每一轮迭代重新estimate 潜在split candidate。
- LightGBM和最近的FastBDT都采取了提前histogram binning再在bin好的数据上面进行搜索。在限定好candidate splits,
- 主要的速度提升似乎来自于两点。一个是搜索的时候选取delta比较大的叶子扩展。第二个是pre-bin之后的histogram的求和用了一个非常巧妙的减法trick，省了一半的时间。

在算法和效果上面

最近比较多的工作都开始基于提前限定分割点的近似算法然后快速求histogram。这一类算法的潜在问题是限制了分割点只能是一开始的定下来的潜在这些。不知道这一点对于实际应用的影响会有多大。理论上数据越多，树越深的时候，需要的潜在分割点越多，可能需要根据训练来动态更新潜在的分割点。

在算法上面采用delta比较大的扩展方向可以集中搜索提高比较重要的区域。一个潜在的问题是可能会忽略掉一些未来有潜力的节点。

当然这些讨论都和具体的应用场景有关。个人觉得exact greedy和histogram方法的还会共存一段时间。或许可以比较好的在系统上面对这两个一起支持

在系统上面

因为集中做针对叶子的分割，似乎会对于数据集的random access有一定的要求。如果不shuffle data的情况下可能会有cache 的问题。这个数据结构是一个有趣的问题

非常值得学习，机器学习系统优化是非常重要的方向。希望可以看到越来越多这样实际的工作

编辑于 2016-10-18

赞同 29216 条评论

数据挖掘话题下的优秀答主

52 人赞同了该回答

刚刚跑完lightGBM，相比于xgboost，速度的确很快。5万多样本，60多个feature，300的树，3秒跑完！
在github上面看到，lightgbm改进的地方主要是特征选择方法上，使用的是histogram bin 的方式，而不是全部特征进行计算。还支持真正的分布式，多台机器一起跑，而且配置文件相当简单
可喜的是第一个版本竟然就支持lambdaMART的排序功能，这个很不错
其他的，由于没有详细的论文，具体细节还无法得知

缺点也是很明显的，没有cv, imbalance , verbose, early stopping 等，以及还没支持PYTHON,R等语言的接口，不过相信肯定会尽快完善

编辑于 2016-10-18

赞同 529 条评论

在北京，不用辞职就能读研究生！专本可报，毕业双证，学信网可查

985/211双一流名校可选，部分专业只考2科，170分即可就读，效力等同全日制研究生，学信网可查查看详情

wepon

145 人赞同了该回答

下午跑了一个分类实验，30万样本，40维特征，lightGBM在22秒内跑完，速度惊人，比xgboost快不少，精度与xgboost不相上下。但是易用性和特性相比xgboost还有待提高，cv，early stopping这两个我觉得非常重要的特性并没有找到。当然，相信这些特性很快就会有了。

对于数据挖掘(竞赛)爱好者来说，又多了一项好工具。

Excited!

发布于 2016-10-17

赞同 145添加评论

规则大法好

36 人赞同了该回答

XGBOOST缺点：
在选择树的分隔点时，需要遍历所有的特征值，这在时间、空间上都是很大的开销；
LightGBM改进：
1. 基于Histogram的决策树算法；
2. 带深度限制的Leaf-wise的叶子生长策略；
3. 直接支持类别特征(Categorical Feature)
4. ......

第一点:

先把连续的浮点特征值离散化成k个整数，同时构造一个宽度为k的直方图。在遍历数据的时候，根据离散化后的值作为索引在直方图中累积统计量。

第二点：

Level-wise过一次数据可以同时分裂同一层的叶子，容易进行多线程优化，也好控制模型复杂度，不容易过拟合。但实际上Level-wise是一种低效的算法，因为它不加区分的对待同一层的叶子，带来了很多没必要的开销，因为实际上很多叶子的分裂增益较低，没必要进行搜索和分裂。

Leaf-wise则是一种更为高效的策略，每次从当前所有叶子中，找到分裂增益最大的一个叶子，然后分裂，如此循环。因此同Level-wise相比，在分裂次数相同的情况下，Leaf-wise可以降低更多的误差，得到更好的精度。Leaf-wise的缺点是可能会长出比较深的决策树，产生过拟合。因此LightGBM在Leaf-wise之上增加了一个最大深度的限制，在保证高效率的同时防止过拟合。

试验了一下，训练时间提升了75%以上，相同召回情况下，准确率略降。

编辑于 2019-06-20

赞同 362 条评论

程惠阁

nlp image

17 人赞同了该回答

微软出品值得学习, 对实现原理感兴趣的可以参考这篇文档，基本原理应该一致。
LightGBM中GBDT的实现
 http://files.cnblogs.com/files/rocketfan/LightGBM%E4%B8%AD%E7%9A%84GBDT%E5%AE%9E%E7%8E%B0.pdf
GBDT的基本原理
 GBDT原理实例演示 1
GBDT原理实例演示 2

编辑于 2016-12-17

赞同 173 条评论

Izsak

微信公众号：统计译文

6 人赞同了该回答

图源链接如下：

Microsoft/LightGBM

最近一份围绕GBM算法的速度测评表在从github流出，其中gpu加速版的LightGBM更比年前那个秒杀XGBoost的表现更上一层楼。陈奕迅也唱道“听别人故事，如何的春风得意，也是别人故事”啊！那么好玩的东西，今天等我来试试！

安装过程遇到些许困难，具体原因就是虽然R的console显示的是64-bit R，但在安装过程却奇怪地默认了32-bit的R来安装，于是安装界面一直报错。后来上github留言报错情况，开发人员回复很及时；意识到原因后重装了R与Rtools，在安装流程中只给64-bit打勾，不管32-bit，最后重新安装LightGBM，就成功了！

小编留意到很多机器学习爱好者的电脑都没有配备着像1080 / TITAN X这样的高端显卡，我们统计译文编辑部秉着“人人都能玩“的精神，用出货量最高的1060显卡进行测评。这次测评用了三个量级的著名数据集，分别是只有234Kb的iris数据集，121 Mb的MNIST数据集以及7.48Gb的Higss Bosom数据集。硬件与软件配置如下：

硬件

cpu：AMD Ryzen 7 1700 8核 16线程

gpu：Nvdia gtx 1060 6G

内存：8 Gb

软件

系统：Windows 10

OpenCL：Cuda 8

Boost Binary：msvc-14.1-64

计算软件：R语言 3.3.3 + Rtools 3.4

计算软件包：LightGBM 0.2 + XGBoost 0.6-4

GBM算法参数设定：

nrounds = 100

learning rate / eta = 1

early_stopping_rounds = 10

mission：iris(3分类) / MINST(10分类) / Higss Bosom(2分类)

测评结果如下:

我们不妨把上面每个数据集分类任务中用时最短的算法的秒数定为1，再计算其他算法用时的倍数：

从上面两张测评结果，我们得到一些结论：

在小型和中型数据集里面，gpu版LightGBM都不是最快的；所以在处理量级偏小的数据集时，不必大费周章上gpu了。
gpu-LightGBM与另外两个版本在处理速率上的差距随着数据集的量级增加而减少，并在大型数据集里面超越了cpu-LightGBM和XGBoost，果然gpu加速是科学计算之光啊！所以经常处理大型数据集的朋友赶紧入手gpu版本吧。
在大型数据集上，gpu版本的LightGBM已经比cpu版本的快1倍了，更不用说远远抛离了cpu版本的XGboost。不过在这里仅使用cpu版本XGBoost，以后有机会上gpu版本的XGBoost再更新这个测评结果。
这三个版本的测评结果都显示随着数据集从Kb到Mb，再到Gb，这数个1024倍的跳跃，都没有造成算法在计算速度有指数级的增加，这显示这三个版本的软件包背后优秀的吞吐优化，以及对大型数据集的优异运算性能。

最后来一份视频看看gtx 1060加速下的LightGBM计算7.48Gb的希格斯粒子数据集的速度吧！（矿机卡都好意思拿出来...哪位看官贡献个1080ti请留言嘻嘻）

LightGBM_趣味科普人文_科技_bilibili_哔哩哔哩

下期继续围绕LightGBM展开翻译，包括：

教大家怎么安装gpu-LightGBM (小编还会把需要提前安装的软件放上网盘)
LightGBM参数解释以及调参说明

敬请期待我们的公众号——统计译文！

http://weixin.qq.com/r/cC93bwDE5l2ZrUQM93pi (二维码自动识别)

发布于 2017-07-01

赞同 61 条评论

2 人赞同了该回答

XGBoost， LightGBM给了我很多思考，对于这样优秀的算法，每次看完LightGBM相关论文之后，总是会引发额外的思考，如梯度信息的直接使用，这些东西在元学习(`Learning to Learn with Gradients`)中经常见到，在不平衡样本学习中损失函数的改造也可以看到它的影子(`Gradient Harmonized Single-stage Detector`)，领域迁移学习中(`Domain-Adversarial Training of Neural Networks`)的梯度翻转等，而关于互斥特征(`Exclusive Feature Bundling, EFB`)合并的内容，结合实际的应用场景，如风控系统中挖掘到的很多稀疏规则进行适当的改进似乎可以很容易生成可用的特征等，解决高维稀疏特征的使用问题。
后面也看到基于这样的工具去做模型的可解释性，寻找对训练影响大的训练样本等
对于一个没有写过轮子的来说，是很好的学习例子，降低了门槛，养活了一大批可以只更关注自己业务的算法工程师，数据挖掘工程师；
希望可以白嫖微软更多的工具

发布于 2020-05-02

赞同 2添加评论

继续