Stacking集成模型与SHAP解释：糖尿病风险预测实战-代码聚汇网

Stacking集成模型与SHAP解释：糖尿病风险预测实战

水间清亦浅·2026-09-02·阅读 22 GEO检测（免费）

机器学习StackingSHAP

|难度：普通|阅读约 37 分钟

先聊个真实的场景。上次有个朋友问我：手里有一份医疗表格数据，要预测一个人是不是有糖尿病风险，模型到底用XGBoost还是随机森林？我说你先别在这两个里纠结，你把随机森林、XGBoost、LightGBM，再加一个逻辑回归，做成两层结构的Stacking模型，效果往往比单选任何一个都稳。他接着问：那领导要解释，这个黑箱模型凭什么说这个人风险高？这就轮到SHAP分析了。

所以今天这篇文章不聊虚的，直接用一份经典的糖尿病数据集，从数据清洗到Stacking模型训练，再到SHAP解释，把这条完整链路走一遍。文章的风格就是标题那句话——先来点实在的，直接上代码，关键地方给你接地气地解释为什么这么干。适合谁看？已经会跑sklearn基础模型、但对集成策略和模型解释还停留在“听说过”阶段的读者，看完就能照着复现。

1. 糖尿病数据不是拿来就用，先处理几个要命的细节

1.1 为什么选了这份数据集，而不是sklearn自带的糖尿病数据

很多教程一上来就用load_diabetes，那个其实是“糖尿病进展程度”回归数据集，预测的是一个连续数值，任务类型和大多数人想做的“是否患病”完全不同。今天我们用的是Pima印第安人糖尿病数据集，二分类任务，预测一个人是否患有糖尿病，输出0或1。

这个数据集在Kaggle和GitHub上都很容易找到，原始仓库地址是jblearning的经典数据文件，直接用pandas读取CSV就能用。特征一共8个：怀孕次数、血糖、血压、皮肤厚度、胰岛素、BMI、糖尿病遗传函数、年龄，标签是Outcome。样本量只有768条，正例占比约35%，是个典型的小数据集二分类问题。

选择这份数据还有一个重要原因：样本量小、特征少（8个），意味着我们既能跑Stacking模型，也能在合理时间内跑完SHAP分析。你要是换一份几十万行、几百个特征的数据集，下面的代码跑起来会非常吃力，尤其SHAP部分，这点后面会专门说。

1.2 那些0值不是真零，是缺失

这是第一道坎。很多人拿到数据直接丢给模型，结果发现效果奇差无比，其实问题出在数据本身。Pima数据集里，血糖（Glucose）、血压（BloodPressure）、皮肤厚度（SkinThickness）、胰岛素（Insulin）、BMI这几列都存在0值。

医学上，空腹血糖不可能是0，血压也不可能是0，BMI更不可能。这些0本质上就是缺失值，只是当时采集的时候用0占位了。如果不处理，模型会把“血糖为0”当成一种有意义的取值模式去学习，结果就是灾难。

处理方式很常规：把这些列里的0替换成NaN，再用中位数填充。为什么用中位数而不是均值？因为这几列尤其是胰岛素，分布非常偏斜，均值容易被极端值带偏，中位数更稳健。代码很简单：

python复制import pandas as pd
import numpy as np

url = 'https://raw.githubusercontent.com/jbrownlee/Datasets/master/pima-indians-diabetes.data.csv'
cols = ['Pregnancies', 'Glucose', 'BloodPressure', 'SkinThickness', 
        'Insulin', 'BMI', 'DiabetesPedigreeFunction', 'Age', 'Outcome']
df = pd.read_csv(url, header=None, names=cols)

zero_cols = ['Glucose', 'BloodPressure', 'SkinThickness', 'Insulin', 'BMI']
for col in zero_cols:
    df[col] = df[col].replace(0, np.nan)
    df[col] = df[col].fillna(df[col].median())

注意，怀孕次数（Pregnancies）里的0是合法值，没怀孕过就是0，不能动。糖尿病遗传函数和年龄也不存在0值问题，所以只处理上面五列。这步做完，再查看数据分布就会顺眼很多。

1.3 数据切分：留出一个独立的“质检员”

数据量小，切分更要讲究。我用train_test_split，test_size=0.2，同时加stratify=y做分层抽样，保证训练集和测试集里正负样本比例一致，都是35%左右的正例。random_state=42固定下来，方便复现。

python复制from sklearn.model_selection import train_test_split

X = df.drop('Outcome', axis=1)
y = df['Outcome']

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42, stratify=y
)

print(X_train.shape, X_test.shape)
print(y_train.mean(), y_test.mean())

这里有一个关键意识：测试集一旦切出来，在整个建模过程中就只能用来做最终评估，不能再参与任何训练决策。你在调参、做特征工程时反复看测试集的效果，本质上就是在“偷看答案”，最后的结果会虚高，上线后就现原形。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. Stacking到底是叠了个啥：原理和“为什么这么配”

2.1 不是投票，是“二手预测再学习”

很多人把Stacking理解成多个模型一起预测然后投票，这是误区。投票是硬性或者软性地把几个模型的输出拼在一起，每个模型还是各自独立决策。Stacking不一样，它多了一层“元学习器”。

打个比方：你是一个科室主任，下面有四个医生。普通集成就是四个医生分别出诊断意见，你按少数服从多数来定。而Stacking是四个医生先把各自的诊断意见写在你面前，你根据自己多年的经验，综合这些意见再做一个判断。关键区别在于：你（元学习器）不是简单数票，而是会学习“哪个医生在哪类情况下更可靠”。

对应到代码上，就是第一层的四个基模型（随机森林、XGBoost、LightGBM、逻辑回归）各自对训练集做交叉验证，产生预测结果。这些预测结果拼接成新的特征矩阵，再作为第二层元学习器的输入，元学习器的输出就是最终预测。这样，Stacking模型不但学了原始特征，还学了“基模型们对原始特征的理解”。

2.2 基学习器和元学习器怎么配，为什么是这四选

选择基学习器的核心原则是“好而不同”。四个模型如果本质一模一样，叠起来也没意义；如果都太弱，集成出来也强不到哪去。我选了四个流派差异明显的模型：

模型	流派	特点
随机森林	Bagging	对高方差数据稳健，不容易过拟合
XGBoost	Boosting	对特征交互捕捉能力强，泛化能力好
LightGBM	Boosting（叶子生长）	训练快，对偏斜分布数据敏感
逻辑回归	线性模型	提供线性决策边界，和树模型互补

随机森林和XGBoost/LightGBM虽然都是树模型，但Bagging和Boosting的机制差异很明显。逻辑回归作为唯一的线性模型，能捕捉到树模型可能忽略的线性关系。四个模型放在一起，预测结果的多样性足够，Stacking才有提升空间。

元学习器我选择逻辑回归，这是经验法则。为什么不用XGBoost或者随机森林？因为第二层的输入是基模型的预测概率，本身信息量比较浓缩，再用复杂模型学一遍，很容易在训练集上拟合过头——毕竟只有4个特征。逻辑回归简单、稳定，而且它的系数还能让我们看出每个基模型在最终决策中的权重，这一点后面解释SHAP时还会用到。

2.3 sklearn的StackingClassifier到底做了什么

StackingClassifier是sklearn提供的一个封装，代码写起来很简单，但内部逻辑值得弄清楚，否则你都不知道自己跑了多久、跑出了什么。

核心参数是cv，默认是5。意思是每个基模型在训练集上做5折交叉验证。比如随机森林，先用第1-4折训练，预测第5折；再用第1、2、3、5折训练，预测第4折……这样循环5次，得到整个训练集上“干净的”预测概率。这5次训练出来的模型，还要分别去预测测试集，最后取平均，得到测试集上的预测概率。这里面的细节如果不理解，你可能不会意识到：cv=5意味着每个基模型实际上被训练了5次，加最后的元学习器，训练成本就是单模型的5倍还多。

这个交叉验证的设计是为了防止数据泄漏。如果第一层直接用同一个模型既训练又预测训练集，预测结果会过于乐观，元学习器学到的是“模型在见过的数据上有多自信”，而不是“模型在新数据上有多准”，这样Stacking就废了。

3. 跑通Stacking并和四个单模型正面PK

3.1 环境依赖和基础导入

先确认环境，需要scikit-learn、xgboost、lightgbm、shap、pandas、numpy、matplotlib这几个库。版本没有特别严格的要求，但注意XGBoost新版如果没指定eval_metric会出警告，代码里我会写上。

python复制import numpy as np
import pandas as pd
import matplotlib.pyplot as plt

from sklearn.ensemble import RandomForestClassifier, StackingClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score, roc_auc_score, confusion_matrix, classification_report
from xgboost import XGBClassifier
from lightgbm import LGBMClassifier

3.2 单模型表现：先看底牌

做集成之前，必须先摸清每个单模型在这份数据上的底子。我先把四个模型分别在训练集上训练，再预测测试集，记录准确率和AUC。这份数据样本少，模型参数我都控制得比较保守，没有做大规模调参，因为本篇重点在集成和解释，不在调参。

python复制models = {
    'RandomForest': RandomForestClassifier(n_estimators=200, random_state=42),
    'XGBoost': XGBClassifier(n_estimators=200, eval_metric='logloss', random_state=42),
    'LightGBM': LGBMClassifier(n_estimators=200, verbose=-1, random_state=42),
    'LogisticRegression': LogisticRegression(max_iter=1000, random_state=42)
}

results = {}
for name, model in models.items():
    model.fit(X_train, y_train)
    y_pred = model.predict(X_test)
    y_prob = model.predict_proba(X_test)[:, 1]
    results[name] = {
        'accuracy': accuracy_score(y_test, y_pred),
        'auc': roc_auc_score(y_test, y_prob)
    }
    print(f"{name}: acc={results[name]['accuracy']:.4f}, auc={results[name]['auc']:.4f}")

在我固定随机种子下，四个单模型准确率在0.73到0.78之间，AUC在0.80到0.83之间。随机森林和XGBoost表现比较突出，逻辑回归稍微弱一点，但这不意味着逻辑回归没有贡献——不同样本上，模型间的错误模式不同，Stacking要利用的正是这种差异性。

3.3 构建Stacking模型，看看集成后的提升

接下来是主角。我把刚才那四个模型作为estimators列表传进StackingClassifier，元学习器用逻辑回归，交叉验证折数cv=5，然后同样训练、预测、评估。

python复制base_models = [
    ('rf', RandomForestClassifier(n_estimators=200, random_state=42)),
    ('xgb', XGBClassifier(n_estimators=200, eval_metric='logloss', random_state=42)),
    ('lgb', LGBMClassifier(n_estimators=200, verbose=-1, random_state=42)),
    ('lr', LogisticRegression(max_iter=1000, random_state=42))
]

stack_model = StackingClassifier(
    estimators=base_models,
    final_estimator=LogisticRegression(max_iter=1000),
    cv=5
)

stack_model.fit(X_train, y_train)
y_pred_stack = stack_model.predict(X_test)
y_prob_stack = stack_model.predict_proba(X_test)[:, 1]

stack_acc = accuracy_score(y_test, y_pred_stack)
stack_auc = roc_auc_score(y_test, y_prob_stack)

print(f"Stacking: acc={stack_acc:.4f}, auc={stack_auc:.4f}")

跑完你会发现，Stacking的准确率和AUC大概率是四个单模型里最高的，至少也能排在最前面。这是Stacking的典型特征：未必在所有指标上都碾压最强单模型，但整体更稳定，方差更小。

3.4 别只盯准确率：AUC和混淆矩阵里的故事

在小样本二分类问题里，准确率是有迷惑性的。因为正例只占35%，就算把所有样本都预测成0，准确率也有65%。所以必须同时看AUC和混淆矩阵。

python复制cm = confusion_matrix(y_test, y_pred_stack)
print(cm)

tn, fp, fn, tp = cm.ravel()
print(f"真正例: {tp}, 假负例: {fn}, 假正例: {fp}, 真负例: {tn}")
print(f"召回率: {tp / (tp + fn):.4f}")

在糖尿病预测这种场景里，漏诊比误诊更严重——把一个真有糖尿病的人判断为健康，代价远大于把健康人误判为需要复查。所以召回率是我特别关注的指标。Stacking的优势一般在AUC上体现得最明显，因为元学习器综合了多个模型的预测概率，排序能力更强，AUC恰恰衡量的是排序能力。

可以看到，Stacking整体AUC提升可能只有0.01-0.03，看似不多，但当模型要应用在真实医疗筛查场景时，AUC提升0.02已经意味着能多筛出好几十个高风险患者，这个增量是有实际意义的。

4. SHAP撬开Stacking黑箱的两种实操路线

4.1 SHAP到底在算什么：把预测值拆成“每个特征贡献多少”

模型训完了，准确率也不错，但业务方会问一个问题：这个模型凭什么判断一个人患糖尿病的概率是0.8？这就是模型可解释性要回答的事情。

SHAP（SHapley Additive exPlanations）核心思想来自博弈论里的Shapley值。它把一个预测结果拆成每个特征的贡献之和。打个比方：四个人合伙做了一单生意，赚了100块，如何公平地分配这笔钱？Shapley值说，要看每个人在不同组合下的边际贡献，然后取平均。SHAP就是把“赚了100块”换成“预测的概率值相对基准值高了多少”，把“四个人”换成“八个特征”，然后计算每个特征贡献了多少比例。

传统特征重要性只能告诉你“哪些特征重要”，SHAP还能告诉你“这个特征是怎么影响的”——比如血糖高会增加风险还是降低风险，对某一个具体的人，血糖这个特征把他的风险推高了多少。

4.2 难点：Stacking不能直接套TreeExplainer

这是今天最值得注意的一个技术点。

如果你想当然地写一行shap.TreeExplainer(stack_model)，大概率会报错。因为TreeExplainer只适用于树模型类，而StackingClassifier不是一棵树，它是一个包含多个基模型和元学习器的复合结构。XGBoost、LightGBM、随机森林单独拿出来都能用TreeExplainer，但包在Stacking外面就不行了。

面对这种情况，有两条实操路线，各有优劣。

4.3 路线A：用KernelExplainer直接解释整体模型

第一条路线是把整个Stacking模型的预测函数包装一下，用KernelExplainer去算SHAP值。KernelExplainer是一个通用的、不依赖模型结构的解释器，只要传入一个“输入特征矩阵，输出预测概率”的函数即可。它的原理是不断扰动特征，观察预测值如何变化，从而估计每个特征的贡献。

python复制import shap

# 取一部分训练数据作为背景数据集，加速计算
background = X_train.sample(50, random_state=42)

# 包装Stacking模型的预测函数（取正类概率）
def stack_predict_proba(X):
    return stack_model.predict_proba(X)[:, 1]

explainer = shap.KernelExplainer(stack_predict_proba, background)
shap_values = explainer.shap_values(X_test.iloc[:100], nsamples=200)

KernelExplainer这么写的好处是，它解释的是整个Stacking模型的完整行为，不影响模型内部任何结构。但代价是慢。768条样本，8个特征，100个测试样本，加上200次采样，跑起来还能等；如果特征加到几十个、样本加到上万，这行代码可能跑几个小时。

所以在数据集规模大、或者只关注树模型的场景下，路线A不是首选。另外要注意，不同版本的SHAP输出格式有差异，二分类时shap_values可能是二维数组，也可能是列表，自行用np.shape确认一下。

4.4 路线B：分别解释基学习器再合并（近似方案）

第二条路线是工程上更常用的近似做法：对四个基学习器分别解释，再加权合并。因为四个基模型里，随机森林、XGBoost、LightGBM都可以直接用TreeExplainer，逻辑回归可以用LinearExplainer，这几个都是专门的快速解释器，速度比KernelExplainer快几个数量级。

python复制rf_explainer = shap.TreeExplainer(stack_model.named_estimators_['rf'])
rf_shap = rf_explainer.shap_values(X_test)

xgb_explainer = shap.TreeExplainer(stack_model.named_estimators_['xgb'])
xgb_shap = xgb_explainer.shap_values(X_test)

lgb_explainer = shap.TreeExplainer(stack_model.named_estimators_['lgb'])
lgb_shap = lgb_explainer.shap_values(X_test)

lr_explainer = shap.LinearExplainer(stack_model.named_estimators_['lr'], X_train)
lr_shap = lr_explainer.shap_values(X_test)

但这样得到的是四个互不相干的SHAP结果，怎么合并成一个“Stacking模型的SHAP”？严格来说，这需要沿着元学习器的决策链路把梯度传播回去，比较复杂。工程上可以做近似：查看元学习器的系数stack_model.final_estimator_.coef_，它表示每个基模型的预测概率在最终预测中的权重，然后用这些权重对四个SHAP矩阵做加权平均。

python复制weights = stack_model.final_estimator_.coef_[0]
# 确保和基模型顺序对应：rf, xgb, lgb, lr
weights = weights / weights.sum()  # 归一化
approx_shap = weights[0] * rf_shap + weights[1] * xgb_shap + weights[2] * lgb_shap + weights[3] * lr_shap

这个方案明显快得多，但需要心里有数：这是近似结果。它的前提假设是元学习器对基模型输出是线性加权关系，而且忽略了基模型之间的交互。优点是在生产环境里跑得快，能给出一个可用的全局排序和方向判断；缺点是不够精确。

我的建议是：如果你的目标是给业务方一个全局的、定性的结论，路线B足够；如果是要对某一个具体样本做精确解释，而且样本量不大、时间也允许，用路线A。

4.5 图怎么读：summary图和force图

算完SHAP值，最直观的是画summary plot，它能同时展示特征重要性排序和影响方向。

python复制shap.summary_plot(shap_values, X_test.iloc[:100], feature_names=X.columns)

横轴是SHAP值，正的方向表示该特征把预测概率往“患病”方向推，负方向往“健康”方向推；颜色表示特征值高低，红色是特征的高值，蓝色是低值。以这份数据为例，通常血糖（Glucose）会排在第一位，红点集中在横轴右侧，意思是血糖越高，模型越倾向于判断为糖尿病，这个结论和医学常识是对得上的——这也是SHAP价值所在，它输出的结论和领域知识互相印证，模型才可信。

如果要解释某一个人，可以用force plot：

python复制shap.force_plot(explainer.expected_value, shap_values[0, :], X_test.iloc[0, :])

它会画出一条基线预测概率，然后按SHAP值把每个特征的推高或拉低作用可视化出来。比如某个人的预测概率是0.7，基线期望值可能是0.35，其中血糖贡献了+0.15，BMI贡献了+0.1，年龄贡献了+0.05，而血压拉低了0.02。这样业务方一眼就能看懂，模型不是拍脑袋，而是有据可循。

5. 实战中的取舍：这套组合拳什么时候值得用

5.1 什么时候收益大，什么时候别硬上

Stacking + SHAP不是银弹。我把它拆开说。

Stacking适合的场景：单模型效果都已经不错、但彼此差异较大，数据量和特征复杂度也支撑得起交叉验证的训练成本。就像Pima这种几百条样本、8个特征的数据，跑起来没什么压力，收益也看得见。但如果你手里有100万行数据、500个特征，四个基模型每个都做5折交叉验证，训练时间会非常可怕，这时候你要先想清楚，Stacking带来的那一点点AUC提升，是否值得这么多算力开销。

SHAP适合的场景：模型结果需要向业务方解释，或者你自己需要排查模型是否学到了符合直觉的模式。如果只是做一个纯离线打分系统，没人关心原因，那SHAP可以省掉；但如果涉及医疗、金融、风控这类需要理由和审计的领域，SHAP基本是标配。

5.2 容易踩的坑清单

第一步数据清洗时，如果漏掉0值处理，特征重要性会被虚拟模式带偏，SHAP图里会出现“血糖为0导致风险极低”这种诡异结论，不是模型聪明，是数据脏。

Stacking用交叉验证生成第二层特征时，外层评估千万不能再复用训练集。常见错误是用同一个训练集同时做Stacking内部的交叉验证和外部的效果评估，这样得到的AUC会偏乐观。正确做法是像我前面一样，先用train_test_split切出独立的测试集，全程不碰它，最后再评估。

KernelExplainer的nsamples参数别贪大，200已经够用。默认值可能上千，在小样本上也会拖慢速度。另外背景数据集background也不需要全量训练数据，50-100个代表性样本足够，前提是它覆盖了数据分布。

SHAP值给出的解释是“模型做了什么”，不等于“真实世界因果”。尤其Stacking模型本身就是多模型复合决策，SHAP对它的解释更是近似。给业务方汇报时，建议说“模型主要依据血糖、BMI、年龄等特征做出判断”，而不是说“血糖导致糖尿病”，前者是解释模型，后者是医学论断，别越界。

5.3 从“能跑”到“能讲故事”：汇报里怎么用SHAP结论

代码跑通只是第一步，真正让这套组合拳体现价值的是你怎么把结果讲出去。

以这份糖尿病数据为例，一次完整的分析汇报可以分三步。第一步，展示单模型和Stacking的评估对比，说明集成为什么带来了AUC提升，用混淆矩阵说明预测结果里有多少漏诊风险。第二步，用SHAP summary图展示全局特征重要性，点名血糖、BMI、年龄是核心风险因子，并用依赖图解释血糖在不同取值区间的影响——比如血糖超过一定阈值后，风险快速上升，这时候就可以结合医学上的筛查阈值去做决策建议。第三步，对个别高风险患者做force plot解释，说明模型为什么把这个人判为高风险，是哪几个特征起了主要作用。

这样一套下来，你交出去的不只是一个准确率数字，而是一个业务方能听懂、能认可、能拿去决策的完整结论。这也是我今天想强调的核心：Stacking负责让模型更准，SHAP负责让模型“说得清”，两个组合起来，才是真正可以上线的机器学习项目。

最后补充一个我踩过的坑。早期的模型报告里，我只放准确率，结果业务方根本不买账，说这模型看着像个黑盒子。后来加了SHAP，虽然AUC只提升了零点零几，但解释图一摆出来，对方反而愿意上线试用了。这也侧面说明，实际工作中，让人理解模型，有时候比提升那几个百分点更重要。