数据预处理与特征工程实战指南：从清洗到编码的完整方法论-平芜编程栈

开头写完了，继续往下写主体。

1. 数据预处理的核心思路与常见误区

1.1 预处理的优先级为什么高于模型调参

我先说一个判断：数据预处理做得好不好，直接决定模型效果的上限，调参只是在逼近这个上限。这个道理很多人都听过，但实际操作中一到项目里就变味了。我见过不少同学拿到一份数据，先不管三七二十一跑个 baseline，发现效果不行就调参，调了两天提升不到 1 个点，最后回头检查数据才发现：时间字段解析错了、同一个用户 ID 在不同表里格式不一致、缺失值直接用 0 填了——这些问题任何模型都救不回来。

原因很简单。模型学的是数据里的规律，如果数据本身脏、乱、不一致，模型学到的就是脏规律。你调参调的是“模型对规律的拟合方式”，但规律本身是数据给的。数据预处理的核心优先级应该是：先保证数据是可信的、一致性的、不含明显泄漏的，然后再谈特征工程和模型选择。顺序反了，后面全白干。

1.2 先清洗还是先做特征：顺序背后的逻辑

很多人问我先清洗还是先做特征，我的答案是：先做一次快速清洗，再做特征工程，最后再回到清洗，形成一个循环。为什么？因为特征工程过程中会暴露很多数据问题。

举个例子，你在做时间特征时，想把“注册时间”和“最后登录时间”相减得到活跃周期，结果发现有一部分用户的最后登录时间早于注册时间——这显然不是用户穿越了，而是数据录入或者同步出了问题。这种问题不做特征工程你根本发现不了。所以我现在的习惯是：第一轮清洗只处理明显的错误和缺失，比如空值、重复行、格式不一致；做完一轮特征后，对新生成的特征再做一次质量检查，把遗留问题挖出来。两轮下来数据质量会扎实很多，而不是指望一次清洗搞定一切。

2. 清洗环节里真正见效的骚操作

2.1 缺失值填充：别只会均值和中位数

缺失值处理是数据预处理里最基础也最容易糊弄过去的环节。最常见的就是 fillna(0)，或者干脆填均值。说句实话，某些场景下这么做确实没问题，但更多时候会引入偏误。我举个例子：用户收入字段存在缺失，如果你直接填全体均值，低收入和高收入群体的区分度会被拉低，模型学出来就是一条歪斜的边界。

我更推荐按分组统计填充。比如用户收入缺失，可以按用户所在城市等级、职业类别分组后取中位数填充。这种做法的逻辑是：同一个组的用户在收入分布上更相似，用组内中位数比用全局均值靠谱得多。实现也不复杂，一行代码就能搞定。

import pandas as pd df['income'] = df.groupby(['city_level', 'job_category'])['income']\ .transform(lambda x: x.fillna(x.median()))

如果缺失比例很高（比如超过 30%），我通常会新增一列income_missing_flag把缺失情况本身作为特征喂给模型。缺失这个事实本身就可能承载信息，比如某些用户不愿意填收入，这背后可能和人群属性有关。这招在风控和用户增长项目里经常有效。

还有一个细节：填充之后一定要检查填充值的分布和原始分布是否接近，不要填充完就直接建模。你会发现很多时候填出来的中位数让整体分布出现了一个明显的尖峰，这时候可以考虑用随机采样填充（从一个合适的分布里采样填入）来保持方差。

2.2 异常值检测：比 3σ 更稳的 MAD 法和 IQR 法

很多教材里讲异常值检测就是 3σ 原则，但实际数据里它一点都不稳。因为均值和标准差本身对异常值极度敏感，一个极端大值把均值拉高、标准差拉大，结果真实异常反而被淹没了。这就相当于让犯罪嫌疑人自己当法官，逻辑上就不成立。

我在实际项目中用得最多的是 IQR（四分位距）法和 MAD（绝对中位差）法。IQR 法大家相对熟悉一些，小于 Q1-1.5*IQR 或者大于 Q3+1.5*IQR 的点都算异常。MAD 法对极端值更稳健，它是用中位数替代均值、用绝对偏差的中位数替代标准差：

import numpy as np def mad_outlier_detect(s: pd.Series, threshold: float = 3.0): median = s.median() mad = (s - median).abs().median() modified_z_score = 0.6745 * (s - median) / mad return modified_z_score.abs() > threshold

这串代码里 0.6745 是把 MAD 转换为和标准差同尺度的常数，这样 threshold 取 3 就和 3σ 口径近似，但抗干扰能力强得多。

处理异常值的方式也值得琢磨。我现在的习惯是：训练集里的极端异常值如果是真实业务事件（比如一笔合法的超大额交易），不会直接删除，而是用 Winsorize 截尾处理，把超出上下限的值压到边界值；如果确认是数据录入错误，才会删除。删除之前一定要记录删了多少行、删的依据是什么，这是数据审计的基本素养。

2.3 脏数据里的格式问题：字符串清洗的几板斧

格式问题是数据预处理中最烦人的部分，因为脏得毫无规律。身份证号里有空格、手机号带着+86前缀、日期一会儿是2024/12/01一会儿是2024-12-01、还有那种把数字写成"1,200"的千分位格式。如果你不做统一，模型会把它们当成完全不同的类别。

我总结了一套字符串清洗的常规流程：

strip 去首尾空格，统一大小写。
用正则表达式把全角字符转半角。
日期字段统一解析成标准datetime；解析不了的记录单独标记出来。
数值字段去掉千分位逗号、货币符号，强制转成 float。
电话、手机号这一类字段，先去掉非数字字符，再做长度校验。

这些步骤看起来笨，但能化解大量后端问题。特别是日期解析，我踩过一次大坑：一批数据里混了13月这种脏日期，pandas 默认to_datetime解析会直接报错，整个预处理流程中断。后来我在所有日期解析外面套了一个安全函数，解析失败的日期统一置为 NaT 并填入缺失标志列，流程再也没因为脏数据中断过。

from datetime import datetime def safe_parse_date(val): if pd.isna(val): return pd.NaT try: return pd.to_datetime(val, errors='raise') except Exception: return pd.NaT

3. 特征工程里的高效技巧

3.1 时间特征：拆出“周期性”比拆出“年月日”更有用

时间特征是最常见也最容易被浪费的特征。很多人拿到时间戳就拆年、月、日、小时，然后直接丢给模型。问题是：模型并不知道“2 月”和“3 月”是相邻的，对树模型来说它俩就是两个独立的类别，完全没有顺序关系。你想表达时间的连续性，这种拆法反而把信息打散了。

我通常会额外构造三类时间特征：周期位置、时间跨度、以及节假日标志。

周期位置最常见的是把小时用三角函数编码，让 23 点和 0 点在特征空间里是相邻的：

df['hour_sin'] = np.sin(2 * np.pi * df['hour'] / 24) df['hour_cos'] = np.cos(2 * np.pi * df['hour'] / 24)

这个技巧在用户行为相关数据里很有用。比如外卖平台，晚上 23 点和凌晨 0 点的行为模式其实高度相似，但如果只按小时拆成类别特征，模型会认为它们是两个毫无关系的离散值，白白浪费了这种相似性。

时间跨度特征是另一个重点。注册时间和当前时间的差值、上次登录距今天数、连续活跃天数——这些特征比单独放时间戳更能表达“用户活跃度”。注意计算跨度时单位要统一，全部转成天或者小时，不要一会儿秒一会儿天。

3.2 数值特征的分桶与编码：别让长尾数据干扰模型

数值型特征经常面对长尾分布的困境，比如用户消费金额，少数大客户动辄消费几万，大部分用户可能就几十几百。这种分布放进线性模型里会被极端值拉着走；放进树模型里，切分点也会集中在样本密度高的区域附近，长尾信息被浪费。

处理长尾的第一选择不是分桶，而是取对数，log1p能把消费金额压缩到相对均衡的区间。如果取完对数还是偏，再考虑分桶：按分位数把数据切成等频区间。这玩意儿可以自己写一个小函数，方便重复调用：

def quantile_bucket(s: pd.Series, q: int = 10) -> pd.Series: try: buckets = pd.qcut(s, q=q, duplicates='drop') except ValueError: buckets = pd.cut(s, bins=q) return buckets

分桶之后最好保留原始值作为另一个特征，因为分桶一定会损失部分精度，二者互补信息更全。我在实际项目里发现，对某些场景来说，分桶后的类别特征和原始连续值特征同时喂给模型，效果比单独用任何一个都要好，因为树模型既能基于精确数值切分，也能利用桶之间的粗粒度关系。

3.3 类别特征编码：标签编码、独热和频次编码的选择逻辑

类别特征的处理经常引发争论。我的经验是：高基数类别特征直接独热编码等于自杀，比如城市有几百个，独热后维度爆炸不说，还容易过拟合。低基数类别（比如性别、设备类型）用独热没问题，简单直接。

对于高基数类别，我强烈推荐频次编码和目标编码结合使用。频次编码用类别出现的次数替代类别本身，逻辑是“出现频率高的类别往往对应主流群体”，这个特征在很多场景下有不错的泛化能力。目标编码则是用该类别的目标均值替代类别本身，但极其容易过拟合，必须配合交叉验证来使用。

# 目标编码示例：需要放在交叉验证折内做，防止泄漏 for fold_train_idx, fold_valid_idx in cv.split(X, y): train_fold, valid_fold = X.iloc[fold_train_idx], X.iloc[fold_valid_idx] target_mean = train_fold.groupby('category')['label'].mean() valid_fold['category_target_enc'] = valid_fold['category'].map(target_mean)

说白了，目标编码是拿“这个类别历史上大概是什么结果”作为先验告诉模型。顺手提醒一句：这个操作特别容易造成数据泄漏，小红书刷到很多人问为什么自己离线指标高、线上不涨，我见过十有八九是目标编码做得太草率，用了全量数据去算均值。

3.4 特征组合：从人工拼接过渡到多项式特征

特征组合是提升模型表达能力的有效手段，但“怎么组合”是有讲究的。最基础的做法是手工拼接，比如把“城市”和“品类”拼成一个复合类别，这在用户偏好挖掘里非常常见。复合之后原来每个维度看不太出来的规律就会浮现出来，例如“北京+夜宵”这个组合特征能显著区分某类用户行为，而单纯看城市或者品类都没那么明显。

如果特征都是数值型的，可以直接使用 PolynomialFeatures 生成二阶交互项。用过的人都知道这个函数会产生一大堆组合，需要注意控制数量，否则维度膨胀严重影响效率。我更推荐的方式还是基于业务理解去人工选择交互对，只构造那些在业务上有明确含义的组合特征，剩下的交给模型自己去学。

从实践来看，特征组合的方向可以参考这几种思路：

用户特征 × 物品特征，比如用户等级 × 价格段。
时间特征 × 行为特征，比如星期几 × 是否下单。
地理位置特征 × 时间特征，比如区域 × 时段。

4. 提升预处理效率的工作流技巧

4.1 pandas 的性能瓶颈与向量化改造

很多人处理大一点的数据就喊卡，根源在于 pandas 的 apply 循环太慢了。如果你在逐行用 for 循环遍历 DataFrame，几百万行数据跑起来非常痛苦。我接手过一段别人写的预处理代码，一个简单的规则函数用 for 循环跑了将近 40 分钟，改成向量化操作后不到半分钟出结果。

向量化的核心思路是：能用内置方法就用内置方法，能批量处理就绝不放循环。比如根据某列条件创建新列，不要写循环，直接用np.where：

df['is_high_value'] = np.where(df['amount'] > df['amount'].quantile(0.9), 1, 0)

如果业务逻辑确实复杂，无法直接用内置函数，可以先sort_values排序再用groupby+shift这类批量操作实现窗口计算，而不是在纯 Python 里循环。实在需要逐行处理，也优先用itertuples()而不是iterrows()，前者比后者快好几倍。

4.2 用 Pipeline 把预处理步骤固化成一个流程

数据预处理最忌讳的是代码散落一地，上一轮用的是这个写法，下一轮又改成另一种写法，最后连自己都搞不清处理逻辑是什么。我在项目中始终用 Pipeline 把预处理步骤串起来。这个做法还有一个额外的好处：预测阶段你只需要调用同一个 pipeline 处理新数据，不用重新写一遍清洗逻辑，模型上线时也能保证线上线下逻辑一致。

from sklearn.pipeline import Pipeline from sklearn.compose import ColumnTransformer from sklearn.impute import SimpleImputer from sklearn.preprocessing import OneHotEncoder preprocessor = ColumnTransformer( transformers=[ ('num', SimpleImputer(strategy='median'), numeric_features), ('cat', OneHotEncoder(handle_unknown='ignore'), categorical_features) ])

这一步的价值在于保证每个环节可追溯，上线排查的时候特别方便。你不需要记住昨天填缺失值用的中位数还是均值，看 pipeline 配置一目了然。

4.3 数据验证：在预处理前和预处理后都要各检查一遍

预处理流程扎实与否，最后的检查很关键。我会在预处理开始前先跑一个数据快照：记录行数、列数、缺失率、分布分位数、类别数量；预处理结束后同样跑一遍快照。两份快照做对比，能清晰看到每一步产生了什么影响，异常情况一目了然。

一个典型的检查策略包括：

行数是否与预期一致？如果少了，确认是去重还是过滤异常值导致的。
数值字段的 min/max 是否在合理范围内？
类别字段的 unique 数量是否符合预期？
新生成的标签分布是否发生了偏移？

这套检查我吃过不少亏之后才养成的习惯。有一次做完预处理发现数据量少了 20%，一查原来是 merge 的时候把外连接写成了内连接。如果没有快照对比，这种错误可能到模型训练完才发现。

5. 常见问题与排查技巧实录

5.1 泄漏问题：目标编码和特征选择里的隐形炸弹

数据泄漏是预处理里最隐蔽、最致命的问题。最常见的一种是：你在做特征工程的时候，用了包含目标信息的全局统计量。比如做目标编码时用全量数据计算目标均值再映射回原数据，这直接把验证集的信息灌进了训练集，指标自然好看，上线必翻车。

正确的做法是：一切涉及目标变量的统计计算必须在训练集内部完成，并且通过交叉验证的方式在不同折内重复计算，验证集和测试集只做映射，不参与计算。一般而言，泄漏问题很难用代码调试发现，它需要你在设计特征时多问一句：这个特征的计算过程是否使用了未来信息或样本外信息。

另一种容易忽略的泄漏是特征选择环节。先用全量数据做特征筛选、再去做交叉验证，这也是慢性泄漏的一种，因为特征筛选过程已经“看过”全量数据的标签了。最好把特征筛选也放进交叉验证的每一折里面去做，保证流程闭环。

5.2 数据类型隐藏的坑：object 列里全是数值

读入数据后第一件事是查看 dtypes，而不是直接开搞。pandas 里经常出现一种情况：数值列因为混入了空字符串或者'-'，被识别成 object 类型。你如果没发现，后续所有计算都会报错或者自动变成字符串拼接，结果完全不可用。

我处理这种情况时用一个自定义函数，先把列尝试转成数值，无法转换的值记录为缺失，再加一个标记列说明原值是什么形态。这样既保证类型正确，又不丢失“这个单元格为什么不是数值”的信息。

def safe_to_numeric(s: pd.Series): converted = pd.to_numeric(s.astype(str).str.replace(',', ''), errors='coerce') invalid_mask = converted.isna() & s.notna() return converted, invalid_mask.astype(int)

5.3 缺失值填补后分布畸变的排查思路

很多人在填充缺失值后发现模型效果反而变差了，但找不到原因。一个大概率问题是填充造成的分布畸变。比如收入列用中位数填充后，中位数那个位置会出现一个异常高的频数峰，模型会误以为“中位数收入”是一个特殊群体，反而学出一堆噪声规律。

排查方法很直接：画出填充前后该字段的分布直方图。如果填充后有明显的人造尖峰，就说明填充策略引入偏误了。这种场景下我的建议是采用带噪声的随机填充：先估计该字段的分布情况，再从分布中抽样填充，尽量保持原有方差。除了画图检查，也可以对比填充前后的标准差、偏度系数，一旦差异过大就要警惕。

5.4 预处理常见问题速查表

异常现象	可能原因	排查方向
模型准确率正常但线上 A/B 不涨	目标编码或特征选择泄漏	检查统计特征是否用到全量数据
数据量比预期少很多	join 类型错误或过滤条件过严	逐段对比快照，检查每步行数变化
收入等数值列全变成字符串拼接	列被识别为 object	检查原始数据是否混入脏字符
填充后模型效果下降	分布产生人造尖峰	画分布直方图，对比填充前后统计量
日期解析总是报错中断	存在异常日期格式	统一用 safe_parse 捕获异常
独热编码后维度爆炸	高基数类别直接独热	改用频次编码或目标编码