企业官网建设流程全解析

三年前接了个用户流失预测的需求，数据大概八百万行、两百多个特征，当时用另一套方案跑一次五折交叉验证要将近四十分钟，调一轮参数就得干等一个下午。后来把模型换成 LightGBM，同样数据、同样机器，单轮训练压到十几秒，五折跑完不到两分钟。那次之后，LightGBM 就成了我处理结构化数据任务的默认首选。这篇内容想聊的就是 LightGBM 从装环境到调参、从原理到踩坑的完整路径，偏实战，不搞论文式推导。不管你是刚接触梯度提升树的新手，还是已经用了一段时间但总觉得模型效果卡在某个瓶颈的老手，应该都能从里面找到点能直接拿去用的东西。文中所有代码都在 Python 环境下验证过，参数解释会尽量说清楚“为什么这么设”，而不是丢一堆配置让你自己猜。

1. 先想清楚：为什么结构化数据任务值得优先考虑 LightGBM

1.1 同类方案横向对比后的取舍逻辑

梯度提升树这一族里，常见的几个选择无非是 XGBoost、CatBoost 和 LightGBM。三者本质上都是 boosting 框架，差异主要在树的生长方式、特征处理策略和工程实现上。我做过一轮不算严谨但足够说明问题的对比：在同一份大约五十万行、八十列混合类型的数据上，用相同的特征和相近的参数规模，跑五折交叉验证，记录训练耗时和 AUC。

数据摆在这里，结论很清楚：在中等规模的结构化数据上，LightGBM 的速度优势是数量级的，精度并没有因为快而掉下来。CatBoost 在类别特征多的场景下确实省心，但训练速度偏慢；XGBoost 生态成熟、文档齐全，可一旦数据量涨上去，不加直方图模式就很难受。

选 LightGBM 的核心理由有三条。第一是训练快，这让参数搜索从“奢侈”变成“日常”，你可以放心地跑几十组参数组合而不至于等到失去耐心。第二是内存占用低，直方图把连续特征离散成桶，特征矩阵的实际存储量大幅下降，普通开发机就能扛住百万级样本。第三是原生支持类别特征，不需要你自己去做一堆 one-hot 展开，省掉的列数往往是几十上百列。

当然它也不是没有短板。小数据量下（比如几千行）Leaf-wise 的生长方式容易过拟合，这时候老老实实用 XGBoost 或者把num_leaves压得很低反而更稳。数据噪声极大、标签本身很脏的时候，任何 boosting 方案都容易把噪声学进去，LightGBM 也不例外。所以选型这件事，从来不是“哪个模型最强”，而是“哪个模型和当前数据规模、时间预算、团队维护成本最匹配”。

1.2 它到底适合解决哪几类问题

从任务类型上看，LightGBM 覆盖的是标准的表格型监督学习：二分类、多分类、回归、排序。落到实际业务里，我遇到过并且跑得比较顺的场景有这么几类。

第一类是风控与欺诈识别。这类任务的特征往往是数值型统计量加上大量类别型字段（渠道、设备类型、地区编码之类），样本量动辄百万级，正负样本极度不平衡。LightGBM 对不平衡不算特别敏感，配合scale_pos_weight或者自定义权重就能调得比较稳，而且训练快意味着可以频繁重训，跟上欺诈手法的变化节奏。

第二类是点击率与转化率预估。这类场景特征维度高、稀疏，大部分是用户 ID、物品 ID 这类高基数类别特征。LightGBM 的类别特征支持配合目标编码思路，能省掉大量手工特征交叉的工作。不过要注意高基数类别特征直接丢进去容易过拟合，后面会专门讲怎么处理。

第三类是销量、流量这类回归预测。时间序列本身有很强的时间结构，纯 LightGBM 不做时序建模，但把滞后特征、滑窗统计量、节假日标记这些手工特征做好之后，树模型抓非线性交互的能力很强，实际效果经常比一些专门的时序模型还稳。

第四类是排序与推荐召回。lambdarank目标函数可以直接用，配合分组信息做 Learning to Rank。这块相对小众，但真有需求时能省掉换框架的成本。

反过来，图像、文本、语音这类非结构化数据就别硬上了，特征工程做完再喂给树模型，效果大概率不如直接上深度模型。LightGBM 的舒适区始终是“行列清晰、有明确特征含义”的表格数据。

1.3 读这篇内容前需要具备的基础

不需要你手推梯度提升的公式，但最好知道决策树怎么分裂、什么叫过拟合、交叉验证在防什么。代码层面，会写基础的 Python、用过 pandas 和 numpy 就够了。如果连fit和predict都没写过，建议先找个简单的分类任务练手，再回来看参数那几节，不然容易一头雾水。

2. 原理拆开看：LightGBM 的快到底快在哪

2.1 直方图算法：把连续特征塞进有限个桶

传统 GBDT 在找最优分裂点时，要对每个特征的每个取值排序，然后逐个尝试切分。假设一个特征有 N 个不同取值，一次分裂的候选点就是 N-1 个，每次还要算左右子节点的梯度统计量，复杂度很吓人。数据量一大，光排序和遍历就吃掉了大部分时间。

LightGBM 的做法是先做特征离散化：把连续特征映射到 K 个桶里（默认max_bin=255），之后所有分裂搜索都在桶的粒度上做。原来要考虑几千个切分点，现在最多 255 个。这个操作带来的收益是双重的——候选点少了，计算量直线下降；同时每个桶只需要维护一份梯度累加和样本计数，内存占用也降下来了。

用生活化的说法类比：假设你要在一整条街上找一个位置开店，最优解可能需要精确到米。直方图的做法是先按街区划分，只在街区边界上做决策。听起来粗糙，但在样本量足够大的情况下，桶内的细微差异对最终分裂收益的影响微乎其微，而速度提升是实打实的。

这里有个参数值得注意：max_bin调大能提升精度，但训练时间和内存都会涨。我一般默认用 255，只有在特征分布特别均匀、精度要求又极高的情况下，才会尝试调到 511。还有一个min_data_in_bin，控制每个桶最少放多少样本，默认是 3，样本量小的时候可以适当调大，避免桶里只有一两个样本导致统计量抖动。

直方图还有个隐藏好处：它天然支持“直方图做差”。父节点的直方图建好之后，算右子节点的直方图只需要用父节点减去左子节点，省掉一半的统计工作。这个优化在深层树上累积起来的收益非常可观，也是 LightGBM 在小max_bin下依然能保持精度的原因之一。

2.2 Leaf-wise 生长：一把效率很高但需要约束的刀

大部分 GBDT 实现采用 Level-wise 生长，也就是一层一层地扩展，同一层的所有节点都会分裂。这种方式平衡，但有个明显浪费：有些节点分裂带来的增益很小，甚至接近零，可它依然会被分裂，白白增加计算量和过拟合风险。

LightGBM 默认用 Leaf-wise，每次从当前所有叶子节点里挑出分裂增益最大的那一个去分裂。这样在同样的叶子数量限制下，模型能更快地降低损失，精度往往也更好。直觉上就像修剪一棵树，你不是均匀地把每一根枝条都剪短，而是盯着长得最旺的那根反复修剪，资源利用率更高。

但这把刀有刃。Leaf-wise 容易长出很深的单侧分支，如果数据里有噪声或者样本量不够，它会沿着某条“看似有效”的路径一路深挖，把训练集里的偶然模式当成规律学进去。所以用 LightGBM 时num_leaves和max_depth这两个参数必须认真对待，不能全用默认值。

我的经验是：num_leaves控制在 31 到 127 之间比较常见，数据量小就往 15 到 31 靠，数据量大再往上放。同时把max_depth显式设成一个值（比如 7 到 10），给生长加个硬顶。有人会问既然有num_leaves了为什么还要max_depth，因为 Leaf-wise 在没有深度限制时可能出现一条极深的链，num_leaves管的是叶子总数，管不住单条路径的深度。

提醒一句：num_leaves理论上应该小于2^max_depth。如果设了max_depth=5却把num_leaves设成 200，实际会被深度卡住，参数等于白设。

2.3 GOSS 与 EFB：两个容易被忽略的加速细节

GOSS 全称是 Gradient-based One-Side Sampling，思路是梯度大的样本说明模型还没学好，应该保留；梯度小的样本说明已经拟合得差不多了，可以按比例抽样。具体做法是保留梯度最大的前 a% 样本，再从剩下的样本里随机抽 b%，并给这部分样本的梯度乘一个放大系数来保持分布无偏。默认top_rate=0.2、other_rate=0.1，很多人根本不知道这两个参数存在，但在百万级样本上开启它能明显缩短训练时间。

EFB 是 Exclusive Feature Bundling，针对的是稀疏特征。举个例子，如果两个特征几乎不会同时非零（互斥），那它们其实可以合并成一个特征，用不同的取值区间区分。这种互斥特征在高维稀疏数据里非常常见，EFB 把它们打包之后，有效特征数下降，训练进一步加速。默认enable_bundle=true，一般不用动，除非你发现特征被合并后模型效果异常，才需要关掉排查。

这两项优化叠加起来，才是 LightGBM 相对其他实现速度优势的完整来源。单看直方图只能解释一部分，Leaf-wise 解释了精度，GOSS 和 EFB 解释了大规模数据下的可扩展性。理解这一层，你在调参时就不会把top_rate当成无关紧要的摆设。

3. 环境搭起来：从安装到跑通第一个模型

3.1 安装方式与版本选择

最省事的方式是 pip 安装：

pip install lightgbm

如果要 GPU 支持或者想自己编译，就得走源码构建，需要 CMake 和对应的编译器。日常使用我建议直接用预编译包，省心。版本上不要追最新，选一个发布了一段时间、社区反馈稳定的版本更稳妥，尤其是生产环境。

依赖方面，LightGBM 本身只依赖 numpy 和 scipy，画图评估会用到 matplotlib 和 scikit-learn。建议单独建虚拟环境，避免和系统里其他包的版本打架。我自己习惯用 conda 建环境，把 Python 版本固定在 3.9 或 3.10，这两个版本和主流科学计算库的兼容性最好。

装完之后跑一句python -c "import lightgbm; print(lightgbm.__version__)"，能打印出版本号就说明装好了。如果报找不到动态库，大概率是系统缺少 OpenMP 运行时，Linux 下装一下libgomp1基本能解决。

3.2 一个最小可运行的二分类示例

先不搞复杂特征工程，用一份模拟数据把流程跑通。下面这段代码覆盖了数据准备、模型定义、训练、早停和评估的完整链路：

import numpy as np import lightgbm as lgb from sklearn.datasets import make_classification from sklearn.model_selection import train_test_split from sklearn.metrics import roc_auc_score # 造一份带噪声的二分类数据 X, y = make_classification( n_samples=200000, n_features=40, n_informative=18, n_redundant=8, n_classes=2, flip_y=0.05, random_state=42 ) X_train, X_valid, y_train, y_valid = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y ) # 构建 Dataset，这一步是 LightGBM 的核心数据结构 dtrain = lgb.Dataset(X_train, label=y_train) dvalid = lgb.Dataset(X_valid, label=y_valid, reference=dtrain) params = { "objective": "binary", "metric": "auc", "boosting_type": "gbdt", "learning_rate": 0.05, "num_leaves": 63, "max_depth": 8, "min_data_in_leaf": 50, "feature_fraction": 0.8, "bagging_fraction": 0.8, "bagging_freq": 1, "lambda_l2": 1.0, "verbosity": -1, "seed": 42, } model = lgb.train( params, dtrain, num_boost_round=3000, valid_sets=[dtrain, dvalid], valid_names=["train", "valid"], callbacks=[ lgb.early_stopping(stopping_rounds=100), lgb.log_evaluation(period=100), ], ) pred = model.predict(X_valid, num_iteration=model.best_iteration) print("valid auc:", roc_auc_score(y_valid, pred)) print("best iteration:", model.best_iteration)

跑下来大概十几秒，验证集 AUC 在 0.93 左右（模拟数据本身比较干净）。这段代码里有几个点值得单独拎出来说。

lgb.Dataset不是简单的数组包装，它在构建时会做特征离散化，生成直方图所需的结构。所以构建 Dataset 本身是要花时间的，数据量大的时候这一步可能占掉总耗时的两三成。如果要做多轮实验，把 Dataset 构建一次、保存成二进制文件反复加载，能省不少时间：

dtrain.save_binary("train.bin") dtrain_loaded = lgb.Dataset("train.bin")

reference=dtrain的作用是让验证集复用训练集的 bin 边界。如果不指定，验证集会自己重新算一套分桶，两边不一致会导致评估结果失真，这个坑我踩过，表现是验证集指标莫名其妙比训练集高一大截。

3.3 训练日志里的信息怎么读

开启log_evaluation之后，每 100 轮会打印一行类似这样的输出：

[100] train's auc: 0.9512 valid's auc: 0.9301 [200] train's auc: 0.9687 valid's auc: 0.9345 [300] train's auc: 0.9789 valid's auc: 0.9351

看这组数要抓两个信号。一是训练集和验证集指标的差距，差得越大过拟合越明显；二是验证集指标什么时候开始不涨甚至回落，那就是早停该介入的位置。上面这组数据里，300 轮之后训练集还在涨、验证集基本平了，说明模型容量已经够用，再加树只是徒增过拟合。

早停的stopping_rounds=100意思是连续 100 轮验证集指标没有提升就停。这个值设太小容易误停（指标偶尔抖动一下就被判死），设太大又浪费时间。我一般在 50 到 200 之间取，数据噪声大的往大调。

4. 参数体系：按优先级一个个啃下来

4.1 调参的正确顺序与被高估的参数

很多人一上来就调num_leaves和learning_rate，其实顺序反了。我习惯的顺序是：先定目标函数和评估指标，再定树结构相关参数（num_leaves、max_depth、min_data_in_leaf），然后是采样与正则（feature_fraction、bagging_fraction、lambda_l1、lambda_l2），最后才动learning_rate配合树的数量。

learning_rate是最容易被神化的参数。它确实影响很大，但本质上是“每棵树的贡献权重”，调小它、增加树数量，效果通常更好但训练更慢；调大它、减少树数量，训练快但容易欠拟合。在早停机制下，learning_rate=0.05搭配几千轮的上限，是一个比较平衡的起点。真正难调的是树结构和正则，因为这两块直接决定了模型能表达多复杂的函数。

一张常用参数的速查表：

min_data_in_leaf被严重低估。它约束的是每个叶子节点至少包含多少样本，调大之后模型被迫做更粗的分裂，过拟合明显缓解。小数据量场景下，我经常把它设到 50 甚至 100，效果比调num_leaves更直接。

4.2 过拟合的诊断与针对性压制

LightGBM 过拟合的典型表现是：训练集指标一路走高，验证集指标早早就平了甚至往下掉；特征重要性里出现一堆只出现一两次的稀有特征排在前列；新数据上预测分布明显比训练时更极端。

诊断之后要分情况压制。如果训练集和验证集差距在 0.02 以内，那基本不算过拟合，别瞎折腾。差距在 0.05 以上，按下面的优先级依次尝试：先把min_data_in_leaf翻倍，再把num_leaves砍一半，然后开feature_fraction到 0.7 左右，最后加lambda_l2。每一步单独改、单独验证，别一次改四五个参数，否则你不知道是哪个起了作用。

有一种情况特别隐蔽：用bagging_fraction做了行采样，但忘了设bagging_freq。bagging_freq默认是 0，意思是“从不做 bagging”，此时bagging_fraction设了也白设。这个坑我见过不止一个人踩，表现就是“参数调了没反应”。

4.3 类别特征的正确打开方式

LightGBM 原生支持类别特征，但前提是你得正确声明。方法有两种，一种是在 Dataset 构建时用categorical_feature指定列名或列索引，另一种是把 pandas 的 category 类型列直接传进去，LightGBM 会自动识别。两者选其一，不要混用。

cat_cols = ["channel", "device_type", "city_level"] for c in cat_cols: df[c] = df[c].astype("category") dtrain = lgb.Dataset( df[features], label=df["label"], categorical_feature=cat_cols, free_raw_data=False, )

原生类别特征的处理逻辑是基于类别在各类别下的梯度统计做分裂，效率比 one-hot 高很多。但要小心高基数类别，比如用户 ID 这种几万个取值的列，直接声明成类别特征会让模型疯狂记住每个 ID 的表现，严重过拟合。这类特征应该走目标编码或者频率编码，转成数值再用。

还有个参数max_cat_threshold，控制类别特征分裂时候选类别分组的最大数量，默认 32。类别取值特别多的时候可以适当调大，但别超过 64，否则单次分裂的搜索成本会明显上升。

5. 完整实操：从原始数据到可交付模型

5.1 特征工程的几个关键动作

拿到原始表之后，我通常按这么几步走。第一步是类型梳理，把数值、类别、时间、文本分开，不同类型特征的处理路径完全不同。第二步是缺失值处理，LightGBM 本身能处理缺失（默认把缺失分到增益更大的一侧），但缺失率超过 60% 的列我会直接看情况丢掉，因为这类列的统计意义很弱，还容易引入噪声。第三步是异常值处理，树模型对异常值不像线性模型那么敏感，但极端值会把直方图的桶区间拉得很宽，导致正常样本全挤在一两个桶里，这时候做个分位数截断或者对数变换是必要的。

第四步是构造交叉特征和统计特征。这块最耗时也最出效果。举个实际的例子，做用户购买预测时，“近 30 天订单数”和“近 30 天平均客单价”单独看都有用，但“订单数除以活跃天数”这种比值特征往往更能区分高频低额和低频高额两类用户。构造这类特征不需要什么高深技巧，靠的是对业务的理解加上反复试。

第五步是特征筛选。特征不是越多越好，冗余特征会增加训练时间、稀释重要性、还可能引入噪声。我的做法是先跑一遍全量特征，看重要性排序，把重要性接近零且业务上解释不通的列删掉，再跑一遍对比。通常删掉两三成特征，效果不会掉甚至略有提升，训练时间却能省下不少。

5.2 交叉验证与早停的配合方式

单次 train/valid 划分的结果波动比较大，尤其是样本量在几万这个量级时。稳妥的做法是分层 K 折交叉验证，每折内部用早停确定最佳轮数，最后把各折的最佳轮数取平均（或者中位数）作为最终模型的树数量，再用全量数据重训一次。

from sklearn.model_selection import StratifiedKFold skf = StratifiedKFold(n_splits=5, shuffle=True, random_state=42) best_iters = [] oof_pred = np.zeros(len(X_train)) for fold, (tr_idx, va_idx) in enumerate(skf.split(X_train, y_train)): dtr = lgb.Dataset(X_train[tr_idx], label=y_train[tr_idx]) dva = lgb.Dataset(X_train[va_idx], label=y_train[va_idx], reference=dtr) m = lgb.train( params, dtr, num_boost_round=3000, valid_sets=[dva], callbacks=[lgb.early_stopping(100, verbose=False)], ) best_iters.append(m.best_iteration) oof_pred[va_idx] = m.predict(X_train[va_idx], num_iteration=m.best_iteration) print("每折最佳轮数:", best_iters) print("OOF AUC:", roc_auc_score(y_train, oof_pred))

这套流程的价值在于，OOF 预测能给你一个接近真实泛化能力的评估，同时各折最佳轮数的离散程度也能反映数据稳定性。如果五折的最佳轮数分别是 300、800、1500、400、1200，那说明数据内部差异很大，单一模型可能不够，得考虑分群建模或者补充特征。

最终重训时用各折轮数的平均值（比如取 800），不要再带验证集，直接用全量数据训练固定轮数。这里有个细节：重训时把learning_rate保持不变、轮数取平均即可，不要试图通过调低学习率再增加轮数来“提精度”，那样容易在缺乏验证的情况下过拟合。

5.3 模型解释与特征重要性的正确读法

model.feature_importance()默认返回的是分裂次数（importance_type="split"），这个指标对高基数特征有偏——取值多的特征天然有更多分裂机会。更能反映真实贡献的是importance_type="gain"，也就是该特征带来的总增益。

imp_gain = model.feature_importance(importance_type="gain") imp_split = model.feature_importance(importance_type="split")

我一般两个都看。gain 高但 split 低的特征，说明它虽然分裂次数少，但每次分裂都很关键，这类特征值得重点关注甚至深挖；split 高但 gain 低的特征，往往是那种取值很多、到处参与分裂但贡献很小的“陪跑型”特征，可以考虑删掉。

如果要做单样本级别的解释，可以用 SHAP 配合 LightGBM 的pred_contrib=True：

contrib = model.predict(X_valid[:5], pred_contrib=True) # 最后一列是基准值，前面的列对应各特征的贡献

这个输出在排查“为什么这个样本被判成高风险”时特别有用，业务方也更容易接受这种逐特征的归因结果。

6. 踩过的坑与排查手册

6.1 训练阶段的典型报错

报错一：Label must be in [0, 1] for binary classification。二分类的标签必须是 0 和 1，不能是 -1 和 1，也不能是字符串。遇到过有人把标签编码成 True/False，LightGBM 能识别成 1/0，但如果是 "yes"/"no" 就会直接报错。

报错二：Cannot convert argument value to string。通常是特征里混进了 object 类型但没声明成类别特征，或者存在无法转成数值的脏字符串（比如数字列里混了空格、逗号）。排查方法是逐列看 dtype，把 object 列全部过一遍。

内存爆掉。数据量在千万级以上时，构建 Dataset 阶段的内存峰值可能是原始数据的 2 到 3 倍。缓解办法包括：用float32而不是float64存特征、把max_bin调小、分块构建 Dataset、或者用two_round=true让 LightGBM 分两遍读数据而不是一次性载入。

训练速度异常慢。先确认是不是无意中关掉了直方图优化（设了max_bin特别大或者enable_bundle=false），再确认num_threads有没有设对。默认会用满所有核心，但在容器环境里有时识别不到真实的 CPU 配额，手动设成实际可用核数反而更快。

6.2 指标不达预期的排查路径

这块我给一个我自己常用的排查顺序，从成本最低的开始。

第一步，看数据。训练集和验证集的标签分布是否一致，特征分布有没有明显偏移。这一步经常能发现大问题，比如验证集里某个类别特征的取值训练集里压根没有。

第二步，看基线。先跑一个逻辑回归或者只用少量特征的极简模型，拿到一个基线分数。如果 LightGBM 跑出来还不如基线，那基本可以确定是数据或流程有问题，而不是参数问题。

第三步，看学习曲线。把训练集和验证集的指标随轮数的变化画出来，判断是欠拟合还是过拟合。欠拟合就加容量（num_leaves、树数量），过拟合就压容量加正则。

第四步，看特征重要性。如果重要性高度集中在少数几个特征上，考虑是不是有数据泄漏；如果重要性非常平均，说明特征区分度不够，得回头做特征工程。

第五步，才动参数。前面四步都没问题，再来调参才有意义。很多人跳过前四步直接调参，结果在错误的方向上花了大把时间。

6.3 上线部署时的注意事项

模型训练完导出，常用方式是存成文本文件：

model.save_model("model.txt") booster = lgb.Booster(model_file="model.txt")

文本格式的好处是跨语言加载方便，Java、C++ 都有对应的解析实现。缺点是文件偏大，几百棵树的时候可能几十 MB。如果对加载速度有要求，可以考虑转成 ONNX 格式，或者做树剪枝把贡献极小的树去掉。

版本一致性是个大坑。训练用的 LightGBM 版本和推理用的版本不一致时，偶尔会出现加载失败或者预测结果对不上的情况。我现在的做法是在模型文件旁边放一个元数据文件，记录训练时的库版本、特征顺序、类别特征的编码映射。特征顺序这一点尤其重要，训练时和推理时的列顺序如果不一致，模型不会报错，但预测结果会悄悄错掉，这种问题排查起来非常痛苦。

还有一个容易被忽略的点：推理时的缺失值处理要和训练时一致。如果训练时用中位数填充了缺失，推理时也必须填充；如果训练时保留 NaN 让模型自己处理，推理时就不能擅自填 0。这种不一致在小流量测试时可能看不出来，全量上线后才会暴露。

7. 最后聊几句实战里攒下的经验

参数搜索这件事，我的建议是先用随机搜索跑二三十组，把参数空间大致摸清楚，再在表现最好的区域附近做小范围网格搜索。贝叶斯优化工具听起来很高级，但在参数维度不高（十来个）的情况下，收益相比随机搜索并不明显，反而多了一层调参工具本身的复杂度。

num_leaves和min_data_in_leaf这两个参数，我现在的习惯是先固定num_leaves在一个中等值（比如 63），然后重点调min_data_in_leaf，从 20 一路试到 200，看验证集指标怎么变。这个参数对最终效果的影响经常比想象中大，而且它的作用和数据的噪声水平直接相关，没有普适的最优值，只能试。

另一点是我越来越倾向于少做特征筛选、多做特征监控。删特征省下的那点训练时间，远不如上线后因为某个特征分布漂移导致效果下滑带来的损失大。与其纠结删不删，不如把每个特征的分布监控起来，一旦发现偏移就及时重训或者调整。

还有个小技巧分享给做多分类的朋友：当类别数很多（比如几十上百类）时，objective="multiclass"的训练成本会随类别数线性上升。如果各类之间有明显层级关系，可以拆成多层二分类来训练，总耗时往往更低，而且每一层的样本更聚焦，效果有时反而更好。

LightGBM 这套东西，入门容易，真正把参数和特征吃透需要时间。但只要把直方图、Leaf-wise、GOSS 这几块原理理解了，再看参数就不会觉得是一堆玄学数字。剩下的就是拿真实数据反复练，练到看见验证集曲线就知道该动哪个参数，基本就算摸到门道了。