Python怎么将多个特征处理步骤组合_FeatureUnion合并多种提取器

Python怎么将多个特征处理步骤组合_FeatureUnion合并多种提取器

FeatureUnion 在 scikit-learn 中早已被弃用

先说一个明确的结论：FeatureUnion 这个工具，从 scikit-learn 1.2 版本开始就被官方标记为弃用（deprecated）了。如果你还在用 1.4 或更高版本，调用它时会看到一个醒目的 FutureWarning 警告，这意味着它在未来的某个版本中会被彻底移除。现在代码里如果还依赖它，无异于埋下了一个定时冲击波。

所以，问题的关键已经不是“如何用好 FeatureUnion”，而是必须尽快迁移。当前的标准答案是：转向 ColumnTransformer 配合 make_column_transformer，或者利用 sklearn.pipeline.Pipeline 进行更灵活的嵌套组合。

FeatureUnion 从 scikit-learn 1.2 版本起被标记为 deprecated，1.4+ 版本触发 FutureWarning，后续将移除；必须迁移到 ColumnTransformer 或 Pipeline 嵌套组合。

ColumnTransformer 是当前标准做法

为什么是 ColumnTransformer？因为它从根本上解决了 FeatureUnion 的几个核心痛点。它天生就支持按照列的类型、名称或位置，将数据分发给不同的预处理器，从而避免了手动拼接数组的麻烦、列名丢失的困扰，以及对稀疏矩阵兼容性不佳的问题。

一个典型的应用场景是这样的：数值列需要做标准化，文本列要用 TfidfVectorizer 提取特征，类别列则进行 OneHotEncoder 编码，最后将所有处理结果合并成一个统一的特征矩阵。

上手时需要注意几个细节：

• 必须明确指定每组列，可以用列名列表如 ['age', 'income']，也可以用位置切片如 slice(0, 2)。
• 默认情况下，每个变换器的输出是稀疏格式（sparse=True）。如果混合了密集和稀疏的结果，需要统一设置或处理。
• remainder 参数控制未匹配列的行为，默认是 'drop'（静默丢弃）。调试阶段，建议先设为 'passthrough' 来确认数据流向，避免意外丢失重要列。

from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler
from sklearn.feature_extraction.text import TfidfVectorizer

preprocessor = ColumnTransformer(
    transformers=[
        ('num', StandardScaler(), ['age', 'income']),
        ('txt', TfidfVectorizer(max_features=100), 'review'),
        ('cat', OneHotEncoder(drop='first'), ['country'])
    ],
    remainder='drop'  # 明确意图，避免意外保留无关列
)

多个提取器输出维度不一致怎么办

迁移过程中，一个常见的拦路虎是报错：ValueError: blocks[0,:] has incompatible row dimensions。这通常意味着不同变换器处理后的样本数对不上了。

问题根源往往不在 ColumnTransformer 本身，而在于输入给各个子变换器的数据“不干净”。比如，某列存在缺失值导致 OneHotEncoder 报错，或者文本列有空字符串使得 TfidfVectorizer 输出全零行，都会破坏维度的一致性。

如何解决？关键在于前置的数据清洗与预检：

• 在数据进入 ColumnTransformer 之前，务必确保所有参与处理的列长度一致，并且没有会导致子变换器崩溃的非法值（例如，TfidfVectorizer 不接受包含 NaN 的输入）。
• 对于文本列，可以加一层 FunctionTransformer(lambda x: x.fillna('')) 来填充空值；对于类别列，设置 handle_unknown='ignore' 可以优雅地处理预测时遇到的新类别。
• 如果需要动态选择列（比如用正则表达式匹配列名），直接使用 make_column_selector(pattern=r'text_.*')，比自己手写列表更可靠，不易漏列。

想复用已有 FeatureUnion 逻辑？别硬改，重写更稳

如果你的老项目里已经堆积了不少基于 FeatureUnion 的自定义提取器（通常是继承了 BaseEstimator 和 TransformerMixin 的类），这里有个忠告：不要试图给这些旧类打补丁来强行适配新接口，这往往事倍功半。

更稳妥的路径是，将每个子提取器的核心逻辑，单独封装成符合 scikit-learn fit/transform 接口的转换器类。然后，直接把这些新类的实例，放入 ColumnTransformer 的 transformers 列表里即可——它不关心你的转换器之前是为谁设计的，只要接口合规就能用。

最后，有一个容易被忽略的技术细节：ColumnTransformer 在训练时，对每个子转换器调用的是 fit_transform() 方法，而不是分别调用 fit() 和 transform()。如果你的自定义类重写了 transform() 但没有妥善处理 fit_transform() 的默认继承或委托逻辑，就可能在这里栽跟头。检查并确保这一点，能让迁移过程更加平滑。