企业官网建设流程全解析

记录一下我系统性补特征工程的第8天。前7天一直在处理缺失值、异常值和重复样本，到昨天为止，数据已经能切出来直接喂给树模型跑一版裸结果了——但裸模型的分数实在拿不出手。今天要做的事情很明确：把类别特征变成模型能消化的数字，同时把连续变量的分布尽可能调整到位。这篇文章不打算讲教科书式的定义，而是把我今天在标签编码和连续变量处理上踩过的坑、对比过的方案、最后定下来的流程全部写出来。如果你也在用pandas和sklearn做表格型数据的特征工程，这篇文章应该能直接用上，尤其是后面那份完整链路和误操作清单。

1. 标签编码：类别变量转数字时的信息守恒问题

1.1 为什么不能直接把字符串丢给模型

大多数表格型模型只能吃数值输入。业务数据里，渠道、设备类型、城市等级这些列天生是字符串，所以第一步必然是把字符串变成数字。我的判断流程分两步：

• 先看唯一值数量。性别这种二值类别，直接考虑0/1映射；城市这种成百上千类别的变量，就要认真思考编码方式，既保留信息，又不把维度撑爆。
• 再看类别之间有没有顺序关系。教育程度从小学到研究生，是有顺序的；血型、品牌名、来源活动，没有顺序。顺序关系存在与否，直接决定了用OrdinalEncoder还是OneHotEncoder。

有不少同学的做法是：跑一个for循环，把所有object类型的列全部扔给LabelEncoder，然后直接喂LightGBM。这样跑，分数也能出，可换一个验证集就忽上忽下。原因我说过很多次：LabelEncoder把类别映射成0、1、2、3……这些整数在树模型里会被当作有序变量，切分时会出现"渠道 <= 1"这种分支条件。渠道之间本来是并列关系，这种切分相当于在语义上引入了错误的排序，本质上是在拟合噪声。

举一个我实际调过的例子。某活动渠道字段包含"公众号、社群、短信、邮件、其他"。LabelEncoder按出现顺序映射后，"公众号"可能是1，"社群"可能是2，"邮件"可能是3。树模型在某个节点分裂时如果走了"渠道 <= 1"，等于把公众号和社群归到一侧，邮件和其他归到另一侧。这种分裂也许能在训练集上降低loss，但它没有现实业务含义，泛化能力自然受影响。这就是信息守恒被破坏的典型表现：字符串转数字的过程中，我们多塞进了不存在的顺序信息。

1.2 有序类别的场景才用OrdinalEncoder

如果特征本身具备顺序语义，比如会员等级"普通、银卡、金卡、钻石"或者教育程度"初中、高中、本科、硕士"，那映射成0、1、2、3是正确的，树模型可以合理利用"等级 >= 2"这种切分逻辑。这种场景我推荐直接使用sklearn的OrdinalEncoder，而不是手写字典做映射。理由是它更健壮，也能和Pipeline配合。

对比一下手写字典的做法：你得自己维护一个字典，如果线上服务遇到一个训练集没见过的新值，字典查询直接抛KeyError。我之前开发一个业务推荐模型时踩过这个坑，训练的时候渠道字段只有那几个值，上线一周后运营新增了一个渠道，服务端调用模型做预估时直接崩溃。后来我把所有类别列的编码逻辑统一改成OrdinalEncoder加Pipeline，再额外维护一份合法取值白名单，问题才算解决。

另外还有一个细节：OrdinalEncoder是按列处理的，公开接口是fit_transform(X)，其中X是二维DataFrame或数组。LabelEncoder的设计初衷是处理目标变量y的，它接受一维数组。如果像很多人那样写for col in categorical_cols: le.fit_transform(df[col])，每列倒是能处理一维序列，返回的也是一维数组，但你必须手动拼回DataFrame。更麻烦的是，LabelEncoder没有handle_unknown参数，新数据一旦出现新值，直接报错，你找不到统一的兜底方案。

我现在的习惯是：自定义一个列选择器，配合ColumnTransformer，把有序类别列、无序类别列、连续变量列分成三个组分别处理。这样训练集和测试集的转换完全对齐，Pipeline也能一键应用到线上服务，编码逻辑不会在训练和推理之间出现偏差。

1.3 无顺序类别硬上标签编码的三层代价

第1.1节讲了语义问题，这里补两个更隐蔽的代价。

第一，编码结果受类别出现顺序影响。同一个特征、同样的数据，哪怕只把训练集的行顺序打乱，LabelEncoder给出的数字映射也可能完全不同。我做过一个可复现性实验：同一份数据，两种行序，分别训练LightGBM并输出feature_importance，结果排序前几名有明显变化。虽然特征重要性的波动有一部分来自树模型的随机性，但把类别映射打乱之后，波动被进一步放大。如果你要给业务汇报特征重要性，这种现象会明显降低说服力。

第二，类别数字间距会被后续模型错误解读。标签编码对树模型的影响主要体现在切分顺序上，但如果你把标签编码后的特征喂给线性模型或神经网络，影响更严重：模型默认1和2的距离等于2和3的距离，而类别之间根本不存在这种距离定义。导致模型学出一堆没有业务含义的权重组合，调试起来非常头痛。

所以我的结论很直接：无序类别变量，要么OneHot、要么频率编码、要么目标编码，就是不推荐直接用标签编码。把这条规则定下来之后，后面的特征处理效率明显提高，不用再反复对比不同编码方式在验证集上的表现。

2. 连续变量的尺度战争：标准化与归一化的选择逻辑

2.1 先问模型：它对尺度敏不敏感

谈到连续变量，大多数教程都会让你"标准化之后建模"。但在实际工程里，这个结论必须看模型类型来修正。

对线性回归、逻辑回归、SVM、KNN这些模型，特征尺度确实重要。拿KNN举例，特征A的取值区间是0到10万（比如月消费金额），特征B的区间是18到80（比如年龄）。KNN通过欧氏距离找近邻，距离计算会对整个特征空间做等权求和，数值范围大的特征会天然主导距离贡献。消费金额差几千元带来的距离增量，可能比年龄差几十岁还大，结果年龄特征在近邻选择中形同虚设。这种情况下，缩放是必要的前置步骤。

对梯度下降类模型，特征尺度影响收敛速度和正则化的作用力。逻辑回归训练时，如果不先把不同量纲的特征统一，梯度更新会被大尺度特征霸占，损失函数等高线变得非常狭长，迭代过程震荡，收敛很慢。正则化项对每个特征的惩罚也会因为尺度不同而失衡，等于变相改了目标函数。

但对树模型来说，这个必要性大幅下降。决策树、随机森林、GBDT系列，都通过比较特征值与阈值来决定分裂，只用相对顺序，不涉及绝对尺度的距离运算。所以我在只用LightGBM或XGBoost的任务里，通常不会对连续变量做标准化。实测做过对比：同一份业务数据，标准化前后的LightGBM AUC几乎完全一致，差异在0.001以内，属于随机波动。

有一个例外值得记住：如果不只是用原始特征，还要构造距离聚合类的衍生变量，比如KNN插补缺失值、余弦相似度、聚类中心距离，那么在构建这些衍生变量之前，参与计算的原始特征必须先统一尺度。否则构造阶段就会被大尺度特征带偏。我记得一次缺失值填充实验里，用KNN估算年龄，原始特征里收入是万元级、年龄是十位级别，估算结果几乎只看收入，因为距离计算里收入占了绝大部分权重。统一缩放之后，年龄特征才真正发挥距离约束作用。

2.2 标准化、归一化、RobustScaler怎么选

如果确认模型需要缩放，接下来选择哪个方法就取决于数据分布。我自己常用三种，用表格做一个对比：

在业务数据里，最常碰到的是收入、消费金额这种长尾且带离群值的连续变量。我自己的首选是先做对数变换压缩长尾，再用Z-score标准化或者RobustScaler处理。比例类特征（注册转化率、点击率）天然有界，一般直接用Min-Max或者干脆不变换。分布近似正态的特征，直接Z-score是最稳妥的选择。

还有一个顺序安排很重要：缺失值处理和离群值处理必须放在标准化之前。原因不难理解，均值和标准差的计算会受到缺失值数量以及离群值极值的影响，如果还没处理就提前算均值和方差，你拿到的统计量是被污染过的。我日常的特征处理顺序基本固定为：缺失值处理 -> 离群值处理 -> 特征变换或分箱 -> 标准化或归一化。这个顺序帮我避掉了不少隐形误差。

2.3 两个不做缩放的场景：稀疏矩阵与极端离群值

归一化被滥用是我在圈子里见到最多的情况之一，至少两个场景它反而帮倒忙。

第一，稀疏矩阵。OneHot之后的用户-商品矩阵，每一行是上万维的稀疏向量，绝大多数是0。对这种矩阵做Min-Max，把非零值压到0到1之间，表面上看数值小了，问题在于归一化操作通常要把稀疏矩阵转成密集结构来做，内存和计算成本瞬间飙升。而且语义上也没有必要，稀疏向量本身已经用0和非零表达了大部分结构。我见过有人对高维稀疏特征做MinMax归一化，结果模型训练时间翻了几倍，效果毫无提升，纯粹是自找麻烦。

第二，离群值主导的归一化。Min-Max由最大值和最小值决定，离群值存在时，99%的样本都会被压到几乎同一个极小区间。我在电商项目里处理订单金额时，字段最大值是几百万，正常订单只有几十到几百块。直接MinMax后，正常样本都被压在0到0.001之间，等于把分布抹平了。后来改成log1p之后再做Z-score，模型表现才恢复正常。

所以缩放不能闭着眼睛选。你想要的是让模型更容易学到特征和目标的关联，而不是机械地套用某个标准动作。每次做缩放之前，先拉一个describe看一下分布，再决定方案，这个检查只需要几秒钟，换来的是后面省掉大量调试时间。

3. 分布偏斜与分箱：连续变量处理的进阶玩法

3.1 log变换与PowerTransformer的正确打开方式

长尾分布是业务连续变量里最常见的形态。点击量、消费金额、累计活跃天数，几乎都是大量数值集中在低值区，少量数值拖出长尾。对线性模型和神经网络来说，这种分布会带来两点问题：损失函数的梯度被极端值主导，特征和目标的线性关系难以体现。最常见的解决方案是对数变换。

实操上我推荐np.log1p(x)而不是np.log(x)，因为log1p在x=0时也有定义，结果是0，省掉引入NaN或者填充偏移量的烦恼。如果你的数据有负数，log1p也行不通，可以考虑PowerTransformer的yeo-johnson方法，它能在保持变换单调性的同时处理负值场景。

Box-Cox变换也值得一提。它是广义幂变换，通过极大似然估计自动选择最优的λ参数，在很多场景下比固定log变换更适配数据分布。sklearn的PowerTransformer封装得足够好用，一行代码就能完成。不过Box-Cox要求输入为正数，这一点常被忽略，报错之后才去查文档，挺浪费时间。

说句实话，树模型依然不需要这些变换。决策树的分裂只依赖排序，log变换对排序没有影响，做了等于白做。我的做法是：同一个特征不强行变换，只在基于距离的模型或神经网络上做变换。至于哪些特征需要变换，我一般先画分布图，看到明显长尾才动手。一张直方图几十秒就能出来，比盲目尝试高效得多。

3.2 分箱的三种思路和我的选择标准

把连续变量切成若干区间，让模型在区间级别上学习，是一种被低估的手段。常见的分箱思路有三种：

1. 等距分箱。把数值区间等分，适合分布相对均匀的数据，实现简单，但对长尾数据极不友好，大部分样本会落在同一个箱子，区分度不足。
2. 分位数分箱。按分位数切分，每个箱子里的样本量大致相同，适合长尾分布，也是我日常用得最多的方法。
3. 业务语义分箱。比如年龄按"未成年、青年、中年、老年"划分，收入按税档划分。这种分箱可解释性最强，但需要足够业务知识支撑，边界定义也未必能让模型找到最优分类。

我的选择标准很简单：样本量不够大（几百到几千行）且特征取值很多的时候，分箱往往比原始连续值更稳。原因是样本少时，精确到个体的数值几乎无法支撑有意义的统计推断，模型很容易记住个别样本而不是学到规律。分箱把特征从几百个取值压缩到几个区间，每个区间的样本量上来了，统计效应更可信，过拟合风险也下来。

分箱之后别忘了保留顺序信息。如果把"低、中、高"当成三个无顺序类别做OneHot，等于主动丢掉排序信息，非常可惜。一般流程是：先用pd.qcut分箱，再用OrdinalEncoder把箱的标签映射成有序整数。这样树模型既可以利用区间顺序做切分，又不会因为取值过细而过度拟合。这个联动思路我今天用在一个登录间隔特征上，效果直接体现在验证集指标上。

3.3 分箱边界在测试集上的漂移问题

分箱有一个我亲身体验过的坑：边界是在训练集上算出来的，新数据分布一旦漂移，新值会落在已有箱区间之外，如果编码逻辑没有处理越界值，轻则归入错误箱，重则直接报错。

我遇到过一个金额特征的例子：训练集里最大值是5万，我按分位数切成5箱，最大箱是"3万以上"。上线三个月后，业务促销推高客单价，相当一部分样本的金额到了8万、10万。如果分箱代码还是沿用旧边界，8万会落到"3万以上"这个最大箱里，虽然从编码角度不算错，但信息分辨率严重不足，模型把8万和3万当成一档，自然损失精度。

解决方法是分箱时预留尾部扩展空间。我现在习惯在分箱之后把首尾两箱的边界向外延伸一部分，比如把最大箱边界乘以1.2，或者在代码里对qcut生成的labels做一次clip操作，让超出边界的数据统一归入最边缘的箱。自定义一个Transformer在fit时记录边界值并统一应用这个裁剪逻辑，线上模型如果要长期运行，这一步必不可少。

4. 第8天实战复盘：从半成品数据到可训练特征

4.1 模拟项目设定与目标

这一节我拿一个模拟项目来串联今天的所有方法。某跨平台系统的用户运营数据集，目标变量是用户在未来30天内是否产生付费转化，二分类问题。原始表10万行、22列。其中类别特征6个：渠道、城市等级、设备类型、注册方式、会员等级、来源活动。连续特征8个：注册天数、最近登录间隔、累计消费金额、浏览次数、平均停留时长、投诉次数、优惠券使用数、邀请人数。其余为ID和时间戳，直接排除。

选择这个项目是因为它足够典型：类别变量里既有有序的（会员等级、城市等级），也有无序且取值多的（来源活动），连续变量则带着长尾和离群值，几乎每一条都有实际处理空间，用来演示今天的标签编码和连续变量处理正好合适。

4.2 完整处理链路与每一步的决策理由

我的操作顺序如下：

第一步，先做训练验证集切分。所有后续的fit都只基于训练集，验证集只在最后做预测和评估。数据泄漏在所有特征工程错误里影响最大，这里必须从源头杜绝。

第二步，处理缺失值。连续变量三个字段有缺失：累计消费金额缺失约8%，最近登录间隔缺失约5%，浏览次数缺失约2%。累计消费金额用中位数填充，因为分布有离群值，均值会被极端值拉偏。登录间隔同样用中位数。浏览次数缺失比例小，用众数填充即可。类别特征来源活动缺失约1%，单独归为"unknown"类别，不填充成其他已有值。

第三步，处理类别特征。渠道有3个取值，设备类型2个取值，都做OneHot并设置handle_unknown='ignore'，保证线上新类别不至于让编码阶段崩溃。来源活动有几十个取值，我用频率编码替代OneHot，每个取值替换成它在训练集里的出现频率。这样既保留类别信息，又没有把维度撑爆。会员等级4个有序等级，城市等级5个有序等级，用OrdinalEncoder按业务含义的顺序映射。

第四步，处理连续特征。累计消费金额先log1p，再Z-score标准化。邀请人数也有长尾，同样log1p后标准化。注册天数和最近登录间隔用RobustScaler。浏览次数接近幂律分布，log1p后标准化。平均停留时长和投诉次数分布相对均匀，直接用Z-score。

第五步，把一个特征作为对比实验：最近登录间隔分别用RobustScaler版本和分位数分箱版本放到模型里对比。最终分箱版本在验证集AUC上稳定高约0.8个百分点。原因是登录间隔对转化的影响本来就是非线性的，分箱让模型以区间粒度感知这种非线性，比连续数值更合适。

4.3 验证集指标与编码回退实验的结果

整个流程跑完，LightGBM在验证集上AUC从裸模型的0.62提升到0.71。这个提升主要来自三个动作：频率编码、log变换、对登录间隔的分箱。为了验证自己的判断不是巧合，我做了两组对照。

第一组，把所有类别特征全部改用LabelEncoder，其他保持不变。结果AUC掉了大约1.5个百分点。这个结果很直接地说明了无序类别硬上标签编码的代价，也呼应了第一部分的分析。

第二组，把所有连续特征全部做MinMax归一化，替代上面各自不同的处理方案。结果AUC下降了0.6个百分点左右。这说明缩放策略不能无脑统一，不同分布需要不同的处理，账面上看起来越简单的变换，往往越容易埋雷。

这两组对照不是浪费时间，它们帮我建立了"为什么这样处理"的参考基线。后续遇到新项目，我可以在同一套评估框架内快速验证自己选择的编码和缩放方案是否合理，而不是凭感觉下结论。

4.4 我从这些踩坑中总结出的操作清单

把第8天遇到的和之前积累的常见错误汇总成一张清单，给正在学的朋友对照自查：

这份清单我留着下次做新项目时逐条对照。哪怕只看其中两条，也能帮你少走不少弯路。

第8天的东西到这里基本收尾。我个人这几天的感受是：特征工程里很多步骤看起来是"标准动作"，但每个标准动作背后都有明确的适用前提，理解了前提，你才知道什么时候该做、什么时候可以跳过、什么时候必须换一种做法。下次再遇到类别变量和连续变量混在一起的数据，先问自己两句话：这个特征有没有顺序语义？这个模型对尺度敏不敏感？两个问题问完，处理方案基本就浮出水面了。