2.6 管道 (Pipeline)

2.6 管道 (Pipeline)

本节摘要：管道（Pipeline）把多个预处理转换器和一个最终估计器串成一个对象，让"数据怎么洗、模型怎么训"变成一条不可拆散的流水线。它最值钱的地方不在省代码，而在防数据泄漏——交叉验证或调参时，每一步的统计量都只从训练集拟合，绝不偷看验证集。本节讲清管道的执行规则、如何用列转换器处理混合特征、如何对整个管道调参，以及训练好的管道怎么整体保存复用。

本节导读

阅读完本节，你应当能够：

1. 说清管道的构成：前若干步是转换器，最后一步是估计器
2. 解释管道在交叉验证中如何防止数据泄漏
3. 用列转换器对不同类型特征做差异化预处理
4. 写出对整个管道调参的步骤名加参数名写法
5. 把训练好的管道整体保存并复用

一、没有管道，问题出在哪

先看一段"没有管道"的写法，几乎每个初学者都写过：

scaler = StandardScaler()
X_train_scaled = scaler.fit_transform(X_train)
X_test_scaled = scaler.transform(X_test)
model = LogisticRegression()
model.fit(X_train_scaled, y_train)
y_pred = model.predict(X_test_scaled)
​

单看这段，没毛病。可一旦放进交叉验证，问题就来了。交叉验证要把数据切成 K 折，每折都得"在训练折上重新 fit、再 transform 验证折"。如果你在切分之前就把整个数据标准化了，那标准化用的均值和方差里，已经混进了验证折的信息——验证折不再是"没见过"的数据，你得到的分数被乐观地抬高了。这就是数据泄漏，一种会让模型在测试时显得比真实水平更好、上线后却翻车的隐患。

管道就是来治这个病的。它把"标准化 + 训练"打包成一个整体，交叉验证切割的是这个整体，而不是散落的两个对象。于是每一步都乖乖地在训练折上拟合、再应用到验证折，泄漏的口子被从结构上堵死了。

更要命的是，泄漏往往不报错，只是让分数好看那么一点点，你根本察觉不到。等模型上线、碰到真正的新数据，那点虚高的分数才现出原形。所以它不是"分数误差"的小问题，而是"你对模型有多自信"的失真。

二、管道的结构：一条顺序流水线

管道本质是一个有序步骤列表。除最后一步必须是估计器（能 fit 和 predict），其余每一步都必须是转换器（能 fit 和 transform）。构造方式如下：

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression

pipe = Pipeline([
    ("scaler", StandardScaler()),
    ("clf", LogisticRegression(max_iter=1000)),
])
pipe.fit(X_train, y_train)
pipe.predict(X_test)
​

一个管道对象自带 fit、predict、score 等方法，和普通模型用起来一模一样。它的内部执行规则值得记牢：

• 调用 fit 时，从第一步到最后一步依次走：转换器执行"拟合再转换"（fit_transform），把结果传给下一步；最后一步估计器只执行 fit。
• 调用 predict 时，数据先依次穿过所有转换器的 transform，再进入最后估计器的 predict。
• 关键点在于：fit 阶段学的统计量（均值、方差、编码映射）只来自训练数据，transform 阶段只是拿这些统计量去套新数据。

上面的图是训练路径。预测路径更简单：数据经过每个转换器只做 transform，最后进估计器 predict。两条路径共享同一套已学好的统计量，这正是管道"整体一致"的来源。

三、防止数据泄漏：管道真正的价值

用一个具体对比说清楚。假设你在做五折交叉验证，数据里有数值列需要标准化：

差异在原理上很微妙，在结果上却很实在。全局标准化会让模型在验证折上"提前知道"了整体的尺度分布，分数被温和地抬高；数据越小、预处理越激进（比如用全量数据做特征选择），泄漏越严重。

💡 关键直觉：预处理不是"和模型无关的前置步骤"，它是模型的一部分。任何会从数据里学出参数的操作——标准化、编码、降维、特征选择——都该和模型一起塞进管道，让交叉验证把它们当成整体来切。

除了标准化和编码，特征选择是另一个高危泄漏点。如果你先用全量数据筛出"最重要的 10 个特征"再去做交叉验证，特征选择就已经看过了验证折的标签，后面的分数自然虚高。正确做法是把特征选择器也当成一个转换器塞进管道，让它在每一折内部重新筛：

from sklearn.feature_selection import SelectKBest
pipe = Pipeline([
    ("select", SelectKBest(k=10)),
    ("clf", LogisticRegression(max_iter=1000)),
])
​

把选择器放进来后，交叉验证每次都会在训练折上重新计算特征重要性、再应用到验证折，泄漏的口子就补上了。这也印证了上面那条总原则：任何会从数据里学出参数的组件，一律放进管道。

这也解释了为什么前面模型选择那节反复强调"预处理要在交叉验证内部做"。管道就是把这个纪律固化成了代码结构，让你想犯错都难。

为什么统计量只能来自训练折

这条纪律值得再掰开一点。标准化的均值方差、独热编码的类别清单、特征选择的重要性排序，这些本质上都是"从数据里学出来的参数"，和模型系数一样，都该只从训练折里长出来。设想你提前用全量数据算好均值，把它当常数写死在预处理里：验证折的每个样本在标准化时，其实已经用到了验证折自己的信息，等于考试前偷偷翻了答案。分数高出的那一截，不是模型变强了，而是验证折泄了题。

反过来看，在训练折上算统计量、再套到验证折上，模拟的才是"上线后拿到全新数据"的真实处境——上线那批数据的均值和方差，你事先并不知道，只能用训练时学到的去套。管道把这一整套动作封装成一步，交叉验证每切一刀，都重新在训练折上 fit、再 transform 验证折，保证模拟和现实对得上。这就是"预处理必须放进管道"的根本原因，不是代码洁癖，是让评估分数诚实。

四、列转换器：混合特征的流水线

真实数据里，一列是年龄、一列是城市、一列是收入，不同类型要不同洗法。数值列要标准化，类别列要独热编码。把它们拆成两条支线、再汇合，靠的是列转换器：

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import OneHotEncoder

pre = ColumnTransformer([
    ("num", StandardScaler(), ["age", "income"]),
    ("cat", OneHotEncoder(), ["city"]),
])
pipe = Pipeline([
    ("pre", pre),
    ("clf", LogisticRegression(max_iter=1000)),
])
​

ColumnTransformer 接受一个三元组列表：名字、转换器、作用的列。列可以用列名，也可以用列下标。没被点到的列默认直接丢弃，若想原样保留，把 remainder 设为 "passthrough"。

这里有个新手常踩的小坑：独热编码会把"城市"一列扩成"城市_北京、城市_上海……"多列，特征维度瞬间膨胀。如果类别数巨大，独热编码会让特征矩阵变得又宽又稀疏，这时可以考虑先做类别合并或改用目标编码等其他方案。

如果内置转换器不够用，管道也接受你自己写的转换器——只要它继承基础转换器接口、实现 fit 和 transform 两个方法。一个经典例子是"计算特征平方并拼回原矩阵"的特征工程步骤。自定义转换器放进管道后，同样享受防泄漏待遇：每折都在训练折上 fit、再 transform 验证折。写法要点是 fit 通常什么都不做、直接返回自身，真正的变换逻辑写在 transform 里。

五、对整个管道调参和持久化

管道是整体，调参自然也能对整体调。参数名要用"步骤名加两个下划线加参数名"的写法，才能定位到管道里某个步骤的参数：

from sklearn.model_selection import GridSearchCV
param = {
    "clf__C": [0.1, 1.0, 10.0],
    "pre__num__with_mean": [True, False],
}
gs = GridSearchCV(pipe, param, cv=5)
gs.fit(X_train, y_train)
print(gs.best_params_)
​

注意看 pre__num__with_mean 这个三段式：列转换器本身也是一层命名空间，套在它里面的 num 分支参数要再往下走一层。这种命名能让你同时调"预处理参数"和"模型参数"，一网打尽。

这套命名能生效，是因为管道实现了统一的 get_params 和 set_params 接口。搜索器靠 get_params 列出所有可调参数，再靠 set_params 把候选值灌进去重训。所以只要你的自定义转换器也遵守这个接口，它一样能进入搜索空间被调优——这是管道和调参无缝配合的底层原因。

训练好的管道还能整个存下来，下次直接加载用，省得重新训练、也省得手写预处理：

import joblib
joblib.dump(pipe, "model.joblib")
loaded = joblib.load("model.joblib")
loaded.predict(X_new)
​

部署时只加载这一个对象，预处理和预测就在里面一次性完成，不会出现"训练时做了标准化、上线时忘了做"的错位。

⚠️ 常见坑：手动标准化后却用管道里的模型，或者反过来，导致训练和上线用的预处理不一致。症状是线上分数和离线分数对不上。根治办法是——永远只保存和加载管道整体，别单独保存裸模型。

⚠️ 常见坑：管道里混进一个不能 fit_transform 的对象，或者把估计器放在了中间。管道对"最后一步是估计器、其余是转换器"有硬约束，放错了会直接报错。

💡 关键直觉：把管道当成"一件家具"而不是"一堆零件"。装好的家具你只会整体搬，不会拆成木板再重新拼——模型加预处理也是同理，整体保存、整体复用，错误自然少。

图标题：管道的数据流动

六、调试管道与几个使用边界

管道把步骤藏进了一个黑盒，想查看中间某一步的状态，用 named_steps 就能把它拎出来：

pipe.named_steps["scaler"].mean_   # 看标准化学到的均值
​

如果懒得给每一步起名，可以用 make_pipeline，它会按类名自动生成步骤名，适合快速搭原型。

管道虽好，也不是处处该用。什么时候用、什么时候别用，一张表说清：

还有两个边界要注意。一是有些预处理依赖"整批数据"的统计而非训练折，硬塞进管道会改变它的语义；二是在探索阶段过早封装会拖慢试错节奏。等方案定型、准备做交叉验证和部署时，再收进管道不迟。

说到底，管道解决的是"一致性"问题——训练、验证、上线三套数据走的是同一条预处理路径，分数才敢拿来当真。这也是为什么正规项目几乎都把管道当默认写法。

温故知新

• 管道是有序步骤列表：前若干步是转换器，最后一步是估计器，整体就是一个可 fit 可 predict 的对象。
• 训练时转换器先拟合再转换：统计量只来自训练数据，估计器只负责拟合。
• 预测时转换器只变换不拟合：用训练阶段学好的统计量套新数据。
• 管道从结构上防数据泄漏：交叉验证切割的是整个管道，验证折不会污染预处理。
• 列转换器处理混合特征：数值列标准化、类别列编码，两条支线再汇合。
• 调参用步骤名加双下划线：列转换器里的分支要再往下一层写。
• 整体保存、整体复用：训练和上线共享同一套预处理，杜绝错位。

下一节我们回到更底层的一对概念——超参数和参数，把"哪些是人在调、哪些是模型自己学"彻底分清。