stacking不适合融合弱分类器，因其验证预测噪声大、方差高，导致元特征不稳定、次级模型难以学习可靠权重；sklearn建议基模型应具备合理性能，关键在于误差不相关而非数量多。
Stacking 不是用来“融合弱分类器”的——它更适合组合多个结构差异大、表现中等偏上
为什么不能直接用弱分类器堆Stacking
弱分类器（比如深度为1的决策树、极小样本量训练的SVM）在验证集上的预测结果噪声大、方差高，作为元特征输入给次级模型时，会把不稳定信号放大。次级模型（如LogisticRegression）无法从混乱的预测分布里学到可靠加权逻辑。
- 实测中，用5个
DecisionTreeClassifier(max_depth=1)做基模型，Stacking准确率常比单个强模型还低5%以上 -
StackingClassifier默认对每个基模型做CV生成元特征，但弱模型的CV预测波动剧烈，导致元特征矩阵列间高度相关甚至近似线性依赖 - sklearn文档明确建议：基模型应具备“reasonable performance”，不是越弱越好
选哪几个基模型才真正有效
关键不是数量多，而是误差不相关。以下组合在多数中小规模分类任务（
-
XGBClassifier（擅长非线性、排序敏感） +RandomForestClassifier（擅长高维稀疏、抗噪） -
SVC(probability=True)（核空间映射能力强） +LogisticRegression（线性可解释、边界清晰） - 避免同质组合：比如两个不同参数的
RandomForestClassifier，提升通常＜0.3%
注意：cv参数必须设为整数（如cv=5），不能用ShuffleSplit等非k折对象，否则StackingClassifier内部会静默降级为非CV模式，引发数据泄露。
手动实现比调用StackingClassifier更可控
当需要调试元特征质量、或基模型输出格式不统一（比如有的返回概率、有的只返回标签）时，手动两阶段流程更稳妥：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 用
KFold(n_splits=5, shuffle=True, random_state=42)对X_train切分，每个fold上训练基模型并预测对应X_val部分 → 拼出meta_X_train - 基模型对
X_test直接predict_proba → 得到meta_X_test - 确保所有基模型都支持
predict_proba，否则需统一用predict+OneHotEncoder编码，但会丢失概率置信度信息
示例关键行：meta_X_train = np.column_stack([model.predict_proba(X_val)[:, 1] for model in base_models])
元模型选简单线性模型反而更稳
别被“元模型越强越好”误导。真实场景中，LogisticRegression或RidgeClassifier比MLPClassifier泛化更好：
- 元特征本身已是高阶抽象，再用复杂模型容易过拟合，尤其当基模型少于4个时
-
LogisticRegression的系数能直观看出各基模型贡献权重（比如coef_[0]对应XGBoost的影响力） - 若基模型输出是多分类概率，用
LogisticRegression(multi_class='ovr')，别用'multinomial'——后者对输入缩放更敏感
真正容易被忽略的是：元模型训练前必须对元特征做标准化，哪怕基模型都是树模型。因为predict_proba输出范围差异极大（SVM概率常集中在0.4~0.6，XGBoost可能0.1~0.9），不标准化会导致LogisticRegression梯度爆炸。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
