企业官网建设流程全解析

1. 为什么我把 SHAP 当成了模型交付前的必做项

做机器学习项目做到一定年头，你会发现一个绕不开的坎：模型指标挺好，AUC 0.86，KS 0.42，离线验证一塌糊涂地漂亮，可一旦拿去跟业务方过结果，第一句话往往不是"模型能不能再准一点"，而是"为什么这个人被判成了高风险"。这时候你要是只能掏出一张特征重要性条形图，那基本等于没答上来。特征重要性只告诉你"这个特征整体上重要"，但业务方问的是"这一个人的这一条预测，是由哪几条特征顶上去的，各顶了多少"。这两件事差别巨大，前者是全局统计，后者是局部归因。

SHAP（SHapley Additive exPlanations）就是用来补上这个缺口的。它的核心承诺非常干脆：把任意一个样本的模型输出，拆解成"基准值 + 每个特征各自的贡献量"，而且这些贡献量加起来严格等于该样本的预测值。你拿到的不是一个模糊的"重要程度"，而是一笔一笔可以加总的账。这个性质在实操里价值极高，因为它意味着解释和预测是同源的，不会出现"解释说 A 特征推动上涨，但模型输出反而下降"这种自相矛盾的情况。

我写这篇的出发点，是把我自己从"跑通shap.summary_plot就完事"到"能拿着 SHAP 结果和业务方、和风控、和审核同事对齐口径"这一路的经验摊开讲。内容包括 Shapley 值的数学底座到底在算什么、KernelSHAP 和 TreeSHAP 两条计算路线各自的实现思路、背景数据集怎么选、六类可视化图分别该在什么场合用、以及一堆文档里不会写但会让你结果跑偏的坑。适合已经能训练模型但解释环节还比较粗糙的同学，也适合被要求"模型必须可解释"而临时抱佛脚的同学，代码部分照着改就能落到自己的数据上。

1.1 三类真实场景，决定了你必须做局部归因

先说清楚什么情况下 SHAP 是真需求，什么情况下是锦上添花。我遇到的场景大致分三类。

第一类是单样本解释必须能落地。比如审批、质检、设备预警这类场景，模型给出一个结论后，是要有人照着这个结论去做动作的。操作的人需要知道"是哪个信号触发的"，否则他不会信，也不敢按模型说的做。这类场景里，全局特征重要性毫无用处，你必须给出单条样本的分解。

第二类是模型排障与特征体检。模型上线后效果衰减，你要快速判断是数据漂移、特征失效，还是某个特征和标签的关系变了。SHAP 值按时间切片看均值漂移，比看特征分布漂移更直观，因为它直接反映"这个特征对输出的推动力变了多少"。

第三类是跨模型对齐。同一个任务上你可能有树模型、线性模型、深度模型在跑，想把它们的判断逻辑对一对。SHAP 的好处是它给出的是同一套语义单位（对输出的贡献量），不同模型之间可以直接比，这是 LIME 那类局部代理模型做不到的——LIME 每次解释都要重新拟合一个局部线性模型，两次解释之间都不保证稳定。

反过来说，如果只是内部做个粗筛、模型结论不需要向任何人解释，那老实说算个 permutation importance 就够了，不必上 SHAP，那个计算成本不值。

1.2 几种可解释方案的取舍，我为什么最后落到 SHAP

这张表是我自己踩过一遍之后整理的，用来在项目启动时快速定位该用哪套方案。

这里有个关键点值得展开：SHAP 的局部值可以自动聚合成全局结论。把全部样本的 SHAP 值取绝对值再求均值，得到的就是全局重要性排序；把 SHAP 值和特征值做散点，得到的就是依赖关系；把 SHAP 值按特征求和做条形图，得到的就是每个特征对整体输出的净推动方向。也就是说，一套计算结果能同时支撑局部解释和全局分析，不用维护两套工具链。这是我在实际项目里最看重的效率优势。

注意：SHAP 的"严格可加"是建立在指定的基准值之上的。基准值一变，所有特征的贡献量都会平移，虽然相对关系和加总性质不变，但绝对值会变。跟业务方对齐口径时，一定要说明基准是什么，否则同一模型两次汇报的数字对不上，很难解释。

1.3 用一个比喻把 SHAP 的核心思想说透

如果要用一句话讲明白 SHAP，我会这么说：它把一次预测当成一场分钱，每个特征是一个参与人，分的是预测值相对基准值的那部分差额。

假设模型对某个样本输出 0.83，而全体样本的平均输出是 0.30，那么多出来的 0.53 就是这单"要分的钱"。SHAP 干的事，就是按每个特征的边际贡献，把这 0.53 分下去。有人分到 +0.21，有人分到 -0.08，有人分到 0，加起来正好 0.53。

"分得公不公平"是这套方法的核心问题。你当然可以随便分，比如按特征方差分、按相关系数分，但那都是拍脑袋。Shapley 值的价值在于，它给出了唯一一组满足若干条公平性要求的分法。这也是为什么 SHAP 在学术上站得住、在工业界能推广开——它不是又一种启发式，而是有公理支撑的唯一解。

2. Shapley 值的数学底座，以及它凭什么说自己公平

2.1 从合作博弈到特征归因

Shapley 值最早不是为机器学习发明的，它来自合作博弈论：几个人合作产生了一笔总收益，怎么分才公平？答案的思路是——看每个人在各种可能的"合作组合"里的平均边际贡献。

搬到机器学习上，参与人变成了特征，总收益变成了模型输出。设特征全集为 F，|F| = M，对于任意子集 S ⊆ F，定义 v(S) 为"只用 S 中的特征、其余特征按背景分布处理时，模型的期望输出"。那么特征 i 的 Shapley 值就是：

$$\phi_i = \sum_{S \subseteq F \setminus {i}} \frac{|S|!,(M-|S|-1)!}{M!}\left[v(S \cup {i}) - v(S)\right]$$

这个式子的读法：枚举所有不包含 i 的特征子集 S，计算"把 i 加进去"带来的输出变化，再用一个权重加权平均。权重那一坨阶乘，本质是在数"在 M 个特征的随机排列中，i 排在第 |S|+1 位、且它前面恰好是 S 这一组的概率"。所以整条公式等价于一句话：把特征以所有可能的顺序逐个加入，每次记录新加入特征带来的增量，最后对全部顺序取平均。

这句话非常重要，因为几乎所有工程实现（包括 TreeSHAP 的路径枚举）都是这句话的变形。你理解了排列平均，后面看任何实现都不会晕。

2.2 四条公理，是 SHAP 区别于"随便分"的关键

Shapley 值之所以被称为唯一合理分法，是因为它同时满足四条性质。我用接地气的话翻译一下。

效率性（Efficiency）：所有特征的贡献加起来，恰好等于"该样本预测值 − 基准值"。不多不少，没有残差项。这条直接决定了 SHAP 可以用作审计——账对得上。

对称性（Symmetry）：如果两个特征在任何组合下的边际贡献都完全一样，那它们分到的值必须相等。防止出现"两个功能相同的特征，一个分到大头一个分到零"的荒谬结果。

虚拟性（Dummy）：如果一个特征加不加进去都不改变输出，它分到的必须是 0。这条听起来废话，但在实际项目里很有用——它意味着你可以理直气壮地说"这个特征对这条预测没影响"，而不是"影响很小但说不清"。

可加性（Additivity）：两个模型组合起来（比如输出相加）的 Shapley 值，等于各自 Shapley 值之和。这条保证了模型融合场景下解释仍然自洽。

我在实际使用中最常引用的是第一条和第三条。第一条用来做核对（代码里sum(shap_values) + base_value ≈ prediction），第三条用来砍特征（大量样本上 SHAP 恒为 0 的特征，基本可以下线）。

2.3 手算一个三特征的例子，把公式走一遍

不手算一遍，公式永远是公式。我构造一个极小的例子，三个二值特征 A、B、C，模型为：

$$f(A,B,C) = 2A + B + 0.5C + A \cdot B$$

注意最后那个交互项 $A \cdot B$，这是刻意加的，用来观察交互效应怎么被分摊。由于特征都是 0/1，v(S) 直接取"子集内特征按给定值代入、子集外特征置 0"的输出。八个组合的取值如下：

以特征 A 为例，需要枚举不含 A 的子集 {∅, {B}, {C}, {B,C}}，权重分别为 1/3、1/6、1/6、1/3（M=3 时，|S|=0 和 |S|=2 的权重都是 1/3，|S|=1 的权重是 1/6）。

• S=∅：v({A}) − v(∅) = 2.0 − 0 = 2.0，权重 1/3
• S={B}：v({A,B}) − v({B}) = 4.0 − 1.0 = 3.0，权重 1/6
• S={C}：v({A,C}) − v({C}) = 2.5 − 0.5 = 2.0，权重 1/6
• S={B,C}：v({A,B,C}) − v({B,C}) = 4.5 − 1.5 = 3.0，权重 1/3

φ_A = 2.0×(1/3) + 3.0×(1/6) + 2.0×(1/6) + 3.0×(1/3) = 0.667 + 0.5 + 0.333 + 1.0 =2.5

同理算 B 和 C，结果如下：

这张表最有意思的地方是 A 和 B 各分了 0.5 的交互项。交互项 $A \cdot B$ 在两特征都为 1 时才生效 1.0，但公平分法是各承担一半——因为谁也无法单独"认领"这个增益。C 没有交互，所以它的 0.5 一分不少全归自己。这就是对称性和效率性在具体数字上的体现。

同时也暴露了 SHAP 的一个认知门槛：**它把交互效应平摊，所以你看到的单特征贡献里可能混着交互的部分。**后面讲 dependence plot 和交互值时会专门处理这件事。

2.4 从 2^M 到工程可行：指数爆炸怎么破

上面那个例子只有 3 个特征，8 种组合，手算还行。真实表格数据动辄几十上百个特征，2^100 这个量级没有任何算力能枚举。所以所有可用的 SHAP 实现，本质都在解决"怎么在可接受时间内逼近上面那个加权平均"。

算法的直觉是：不枚举全部子集，改用采样。随机抽若干个特征排列，每个排列从头走到尾，记录每次加入新特征时的增量，再对采样到的排列取平均。采样次数越多越接近精确值，代价是时间线性增长。这就是 KernelSHAP 的思路骨架。

另一种思路是 TreeSHAP 走的：对树模型而言，给定样本在树上走一遍只经过有限条路径，v(S) 的期望可以在树上直接解析算出来，不用采样。这一条路把复杂度从指数级压到了与树的叶子数相关的多项式级，是 SHAP 能在生产环境落地的关键突破。

3. 计算过程拆解：三条主流路线各自在算什么

3.1 KernelSHAP：把解释问题伪装成一个加权线性回归

KernelSHAP 的做法第一次看会觉得有点绕，但想通了很漂亮。它不去直接算上面的加权平均，而是构造一个线性模型去拟合 v(S)：

$$\hat{f}(z) = \phi_0 + \sum_{i=1}^{M}\phi_i z_i$$

其中 $z_i \in {0,1}$ 表示第 i 个特征"在不在"，$z$ 是特征子集的一种编码。然后关键的一步来了：对每个子集 z 赋一个权重

$$\pi(z) = \frac{M-1}{\binom{M}{|z|}\cdot|z|\cdot(M-|z|)}$$

有了这组权重，用加权最小二乘去拟合所有子集上的 v(S)，解出来的线性系数 $\phi_i$ 就恰好等于 Shapley 值。这个结论不是巧合，而是可以证明的：这组特殊的权重（业内叫 SHAP kernel）正好让加权回归的解与 Shapley 值一一对应。

我理解它的方式是这样的：子集越"极端"，权重越小。全是特征或全不是特征的子集，权重被拉到无穷小（所以代码里直接设成 1e6 这种大数近似"排除"），而中间规模的子集权重更大。直觉上说得通——"一个特征单独加进来"和"只差一个特征"这两种情况信息量最大，中间规模的情况需要密集采样。

工程上要注意，KernelSHAP 是采样近似，每次运行都可能略有差异。想复现结果必须固定随机种子。同时它需要对模型做大量前向推理（每个子集一次），计算开销随样本数和采样次数线性上升。所以我的习惯是：从测试集里挑 100 到 300 个有代表性的样本做解释，不要直接跑全量。

3.2 TreeSHAP：沿树路径做递归分配

树模型的特殊性在于，v(S) 那个"其余特征按背景分布边缘化后的期望输出"可以在树上精确算出来，不需要采样。TreeSHAP 的算法核心是一个递归遍历：从根节点出发，同时维护"当前已经按真实样本值走过了哪些特征（记为 in-set）"和"还有哪些特征没走过（记为 out-set）"，遇到分裂节点时按子样本量比例把贡献分给下面的叶子。

具体一点说，遍历到某个节点时，如果分裂特征已经在 in-set 里，那就只有一条路可走（按真实样本值的那一侧），直接递归；如果分裂特征在 out-set 里，就要两条路都走——真实样本值那一侧算"这个特征确定了"，另一侧算"这个特征没确定，取的是平均"，并按两边的样本权重把结果加权汇总。走到叶子时得到一个输出值，回溯过程中按"确定/不确定"的比例把差额分配给对应的特征。

这个描述听起来繁琐，但它带来的好处是决定性的：TreeSHAP 是确定性算法，没有随机性，几次结果完全一样；而且复杂度是特征数乘以树的深度的指数级别内可控，实测上千棵树的森林在几百个样本上跑解释也就几十秒。

TreeSHAP 还有两个必须知道的实现变体，选错了结果会差很多。tree_path_dependent模式用训练时每条路径的样本覆盖数来估计 v(S)，不需要背景数据集，速度快，但当训练集有严重的数据泄漏或者特征高度相关时，会高估某些特征的作用。interventional模式则需要你显式提供一个背景数据集，按背景集的数据分布来做边缘化，更贴近"如果我们把某特征换成随机一个样本的值会发生什么"这个反事实的问题。我的默认选择是：要做归因汇报、要给业务方看，用 interventional，背景集从训练集里随机抽 100 到 500 条；要快速做特征体检、跑几千个样本，用 path_dependent。

3.3 背景数据集怎么选，这一步比选算法更影响结果

这是我最想强调的一节。太多人第一次跑 SHAP 就随手写shap.KernelExplainer(model.predict, X_train)，把整个训练集塞进去当背景，结果一是慢到怀疑人生，二是解释出来的基准值毫无业务意义。

基准值（base value）的含义是"当所有特征都不知道时，模型平均会输出什么"。它应该对应一个业务上说得通的参照系。举例来说，如果你在做一个设备维护预警模型，基准值取全量样本的平均预测概率，那解释就是"相对全体平均水平，这台设备的这几条特征把它推高了多少"。这个口径最通用，我大多数时候用它。

但有些场景下你需要换参照系。比如设备按型号分群，A 型号的基准故障率本来就高，如果你用全量平均做基准，A 型号的样本会出现"所有特征都在往上推"的假象，实际只是型号差异。这种情况我会把基准限定在同型号的样本内，解释就变成"相对同型号平均水平"。这个细节能让汇报时的说服力提升一个档次，因为对比的对象是业务方心里的参照物。

背景集规模的经验值：KernelSHAP 用 50 到 200 条，TreeSHAP 的 interventional 模式用 100 到 500 条。抽取方式必须是随机的，最好分层抽，保证覆盖各个类别。不要用训练集前 N 条，如果数据有时间排序，前 N 条可能全是最早期的分布，基准会偏得很离谱。

注意：背景数据集里如果包含待解释的样本本身，那个样本的基准会被拉向自己，导致解释偏保守。做严格评估时，背景集应和待解释样本集分离。

3.4 计算资源与精度的权衡表

下面这张表是我按实际跑出来的耗时量级整理的（几十个特征、几千行数据的规模，供参考）。

实际项目里我的路径通常是这样：先用 path_dependent 的 TreeSHAP 全量扫一遍，把全局重要性排出来、找出恒零特征和异常特征；确定要深入分析的几十个样本后，切到 interventional 模式加背景集，出正式的单样本解释和图；如果最终交付的是非树模型（比如融合了线性项或深度模型），再用 KernelSHAP 对少量样本做交叉验证，看两种路线的结论是否一致。

4. 六类可视化图怎么读，什么场合用哪张

4.1 summary plot：全局第一张图，但别只看条形版

shap.summary_plot有两个形态，条形图和蜂群图（beeswarm）。条形图是"全局重要性排序"，把每个特征的 SHAP 绝对值取均值排序，直观但信息量少。蜂群图才是真正有用的那个：横轴是 SHAP 值，每个点是一个样本，颜色表示该特征本身的取值高低，纵向按重要性堆叠。

读蜂群图有三个层次。第一看排序，谁在上面谁影响大。第二看方向，点集中在零轴右侧表示整体推高输出，左侧表示压低。第三看颜色和横轴的对应关系，如果高值（红）集中在右侧、低值（蓝）集中在左侧，说明这个特征与输出是单调正相关；如果红蓝交叠在两侧，说明关系非单调，可能存在阈值效应或者交互作用，这时候必须切到 dependence plot 去看形状。

我见过最常见的误读是：看到某个特征蜂群很宽，就断定"这个特征很重要，业务上要重点关注"。但宽度只代表"模型在用这个特征"，不代表"这个特征和真实业务结果有因果关系"。如果这个特征本身是个代理变量（比如用某个 ID 编码隐式表达了分组信息），模型会重度依赖它，但它在业务上毫无意义，甚至是个风险点。这一条我吃过亏，后来养成了习惯：蜂群图上排前几名的特征，逐个回到业务口径上问一句"这个特征我们采集合规吗、上线后稳定吗"。

4.2 waterfall 和 force plot：单样本解释的两把刀

要给具体某一条记录做解释，waterfall 是我首选。它从基准值出发，把每个特征的贡献按大小排列，一根一根往上或往下叠，最后落到该样本的预测值。视觉上就是一栋横向的瀑布，一眼能看出"哪几条把它顶上去了、哪几条把它拉下来了"。汇报时截图放进文档，非技术同事也能看懂。

force plot 的视觉更花哨，把所有特征压缩在一根横轴上，红蓝对冲。它在 Jupyter 里做交互浏览很爽，但截图放进 PPT 往往因为太宽而失去可读性。我的用法是：探索阶段用 force plot 快速翻样本，正式材料用 waterfall。

有个实操细节值得说。waterfall 默认只显示前若干个特征，剩下的合并成 "N other features"，这个 N 要显式调大或者调小。我在给业务方看的版本里通常设成 8 到 10 个，太多反而失焦；给自己排查用的版本会设成 30 个，确保没有遗漏。

注意：分类模型（尤其是基于 log-odds 训练的树模型）的 SHAP 值默认输出在 log-odds 空间，而 waterfall 图上显示的可能是概率。这两个空间的数值不能直接对比，也不能把 log-odds 的贡献量当成"概率变化了几个百分点"来讲。要讲概率口径，得在解释器构造时显式指定输出空间，并且清楚这会带来一定的一致性损失。

4.3 dependence plot：看形状、找阈值、发现交互

单特征的 SHAP 值和特征取值做散点，就是 dependence plot。它回答的是"这个特征取不同值时，对输出的推动力怎么变"。我在做特征工程复盘时最常用这张图，因为它能直接暴露三件事。

一是非线性形状。比如散点呈阶梯状，说明模型学到了一个阈值，超过某个值后推动力突然跳变。这种情况下，如果业务上能接受，把原始特征换成"是否超过阈值"的二值特征，模型会更稳、解释也更干净。

二是方向翻转。散点先升后降，说明这个特征存在最优区间。这时候千万别在汇报里说"这个特征越大越好"，会被业务方当场抓住。

三是交互作用。dependence plot 支持用第二个特征上色，如果同一横坐标下不同颜色的点纵向分离明显，就说明这两个特征存在交互。这时候要看的是"在 B 取高值时 A 的作用被放大/削弱了"，而不是 A 单独的作用。

再往深一层，shap.interaction_values可以算出两两交互的强度矩阵，配合层次聚类能自动把特征分组。我在特征数量超过 50 的项目里会用这个来找"哪几个特征其实在说同一件事"，对降维和去冗余很有帮助。但要注意，交互值的计算成本明显高于普通 SHAP 值，特征多的时候不要全量跑。

4.4 从图到结论：把分析写成可执行的口径

图看得再明白，落不到文档和规则上就是白做。我的做法是固定产出三样东西。

第一样是特征贡献清单。对目标样本群，把每个特征的平均 |SHAP| 排序，同时给出"推动方向占比"（多少比例的样本是被这个特征推高的）。这两列一起看，能区分"影响大但方向一致"和"影响大但方向混乱"两类特征，后者的业务含义通常更微妙。

第二样是阈值规则。从 dependence plot 上读出拐点，转成可执行的判断条件。比如"某特征超过 X 后，SHAP 值稳定为正且幅度明显上升"，这条就能写进人工复核的提示语里。

第三样是稳定性备注。记录这次分析用的背景集、解释器模式、样本范围。下次再做的时候，如果这些前提变了，结论就不能直接对比。这一条看起来是形式主义，但真到了要复盘"三个月前为什么这么判断"的时候，能救命。

5. 完整实操：从建模到出图的整条链路

下面这套代码是我自己项目里的骨架，数据用模拟生成的设备运行数据代替，你可以把读取部分换成自己的表，其余基本不用改。

5.1 环境准备与依赖版本

pip install "shap>=0.44" scikit-learn pandas numpy matplotlib

版本这件事必须提一句。shap 在 0.40 之后把explainer(X)的返回值统一成了Explanation对象，和老版本的explainer.shap_values(X)返回 numpy 数组的行为不完全一样。新写法更清爽（sv.values、sv.base_values、sv.data三件套），但网上大量老教程还是旧写法，混着抄会报各种莫名其妙的错。我的建议是统一用新写法，遇到旧代码就手动转一下。

5.2 构造数据与训练模型

import numpy as np import pandas as pd from sklearn.ensemble import GradientBoostingClassifier from sklearn.model_selection import train_test_split rng = np.random.default_rng(42) n = 4000 temp = rng.normal(68, 9, n) # 运行温度 load = rng.uniform(0.2, 1.0, n) # 负载率 run_hours = rng.gamma(3, 400, n) # 累计运行时长 vib = rng.gamma(2, 1.2, n) # 振动幅值 humidity = rng.normal(55, 12, n) # 环境湿度 since_mnt = rng.exponential(30, n) # 距上次维护天数 # 人为构造一个带阈值和交互的标签生成过程 logit = ( 0.09 * (temp - 68) + 5.5 * (load - 0.6) + 0.0016 * (run_hours - 1200) + 1.1 * (vib - 2.4) + 0.035 * (humidity - 55) + 0.05 * (since_mnt - 30) + 3.0 * ((temp > 78).astype(float)) # 阈值效应 - 2.2 * (load * (vib > 3.0)) # 交互效应 - 0.9 ) p = 1 / (1 + np.exp(-logit)) y = rng.binomial(1, p) X = pd.DataFrame({ "运行温度": temp, "负载率": load, "累计运行时长": run_hours, "振动幅值": vib, "环境湿度": humidity, "距上次维护天数": since_mnt, }) X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.3, random_state=7, stratify=y) model = GradientBoostingClassifier( n_estimators=300, max_depth=3, learning_rate=0.06, subsample=0.9, random_state=7 ) model.fit(X_tr, y_tr) print("测试集 AUC:", round(__import__("sklearn.metrics", fromlist=["roc_auc_score"]) .roc_auc_score(y_te, model.predict_proba(X_te)[:, 1]), 4))

这里刻意在标签生成里放了阈值项和乘积交互项，是为了后面看 dependence plot 时能验证"图能不能把这个结构读出来"。如果图上读不出你已知的结构，说明解释流程有问题，这比盲目信任图要靠谱得多。

5.3 构造解释器并计算 SHAP 值

import shap # 背景集：从训练集分层随机抽 200 条 bg = X_tr.sample(n=200, random_state=11) # interventional 模式，显式给背景集，结果更贴近反事实语义 explainer = shap.TreeExplainer( model, data=bg, feature_perturbation="interventional", model_output="raw", # log-odds 空间 ) # 待解释样本：测试集抽 300 条 sample = X_te.sample(n=300, random_state=11) sv = explainer(sample) # 返回 Explanation 对象

算完之后第一件事是核对效率性，这一步我强烈建议固化成习惯：

import numpy as np recon = sv.values.sum(axis=1) + sv.base_values pred = model.predict_proba(sample)[:, 1] # 概率空间 # 因为 SHAP 在 log-odds 空间，先转换再比 logit_pred = np.log(pred / (1 - pred)) print("最大偏差:", np.abs(recon - logit_pred).max())

正常情况下这个偏差应该在 1e-6 量级。如果偏差很大，八成是model_output设的和预期不一致，或者模型被包装过（比如外面套了一层 pipeline，解释器认不出内部结构）。这个自检能省掉后面无数次"图看起来怪怪的"的困惑。

5.4 六张核心图的代码

import matplotlib.pyplot as plt # 1) 全局重要性条形图 shap.plots.bar(sv, max_display=12, show=False) plt.tight_layout(); plt.savefig("bar.png", dpi=150); plt.close() # 2) 蜂群图：方向 + 分布 + 特征取值 shap.plots.beeswarm(sv, max_display=12, show=False) plt.tight_layout(); plt.savefig("beeswarm.png", dpi=150); plt.close() # 3) 单样本瀑布图 idx = int(np.argmax(sv.values.sum(axis=1))) # 挑被推得最高的那个样本 shap.plots.waterfall(sv[idx], max_display=10, show=False) plt.tight_layout(); plt.savefig("waterfall.png", dpi=150); plt.close() # 4) 依赖图：看形状和阈值 shap.plots.scatter(sv[:, "运行温度"], color=sv[:, "负载率"], show=False) plt.tight_layout(); plt.savefig("dep_temp.png", dpi=150); plt.close() # 5) 交互强度聚类（特征多时才有必要） shap.plots.bar(sv, max_display=12, clustering=shap.utils.hclust(sample, X_tr.columns.tolist()), show=False) plt.tight_layout(); plt.savefig("cluster.png", dpi=150); plt.close() # 6) 分群对比：按某特征的高低位切两组，看贡献结构差异 mask = sample["负载率"] > sample["负载率"].median() shap.plots.bar(sv[mask.values].mean(0), show=False) plt.tight_layout(); plt.savefig("group_high.png", dpi=150); plt.close()

第 6 张图容易被忽略，但我认为它信息量最大。把样本按某个业务维度切两群，分别出全局条形图，两边的贡献结构差异会立刻显现——比如高负载组的"振动幅值"贡献明显高于低负载组，这就直接印证了交互效应，比看依赖图上的颜色分离更直观，也更好写进结论。

5.5 把结果落成可执行规则

代码跑完只是原料，落地还得转一道。我通常按这个模板整理：

| 特征 | 平均 |SHAP| | 推高样本占比 | 关键拐点 | 建议动作 | |---|---|---|---|---|---| | 运行温度 | 0.61 | 72% | 约 78 以上明显转正 | 超过 78 触发复核提示 | | 振动幅值 | 0.48 | 65% | 3.0 附近陡增 | 超过 3.0 且高负载时加权 | | 负载率 | 0.42 | 58% | 无明确拐点 | 作为连续量参与打分 | | 距上次维护天数 | 0.19 | 54% | 无明显拐点 | 保持监控，暂不设阈值 |

这张表的用法是：拐点来自 dependence plot，占比来自 SHAP 值的符号统计，平均 |SHAP| 来自全局排序。三列合起来，业务方拿到的就不是"模型觉得这个特征重要"，而是"这个特征在什么情况下、对多少比例的样本、往哪个方向起作用"。

6. 踩坑记录与常见问题速查

6.1 我实际遇到过的典型问题

问题一：所有特征的 SHAP 值加起来对不上预测值。最常见的原因是模型输出空间搞错了。树模型在 log-odds 空间算 SHAP，你拿概率去比，永远对不上。第二个原因是样本顺序错位——explainer(sample)之后又对 sample 做了排序或过滤，导致sv和sample不再一一对应。第三个原因是 pipeline 包装，解释器只看到了外层。排查顺序就按这三条来。

问题二：两个高度相关的特征，SHAP 值一个很大一个接近零。这不是 bug，是 Shapley 值的正常行为。当两个特征几乎等价时，模型任选其一使用，Shapley 分配会把贡献集中到实际被使用的那一个上。这叫"归因分裂"，读图时如果两个强相关特征的重要性排序看起来很随机，先做相关性检查，把冗余特征合并或删掉再重新解释，结论会稳定很多。

问题三：KernelSHAP 跑得极慢，甚至内存溢出。三个原因：背景集太大（用全量训练集）、待解释样本太多（用全量测试集）、采样次数默认值偏高。按 200 条背景、300 条样本、默认采样来配，一般几分钟内能出结果。如果模型本身就是深度网络且输入维度高，那老老实实缩小样本量，别指望全量。

问题四：分类模型的 waterfall 图数字看着不对。检查model_output参数。设成"probability"时图上的数值是概率口径，但这时 SHAP 的一致性性质会有轻微损失；设成"raw"是标准的 log-odds 口径，数值可加总但不直观。我的处理方式是：图给业务看用概率，内部核对用 raw，两套分开算。

问题五：不同次运行的 SHAP 值有细微差异。用了 KernelSHAP 且没固定随机种子时会这样。所有采样类方法都必须设种子，否则无法复现，做审计时是硬伤。

6.2 常见问题速查表

6.3 几条文档里不会写的心得

第一，先做特征体检，再上 SHAP。我现在的顺序是：先看相关性矩阵和缺失率，把高度冗余和缺失严重的特征处理掉，再跑 SHAP。原因是 SHAP 会把冗余特征之间的归因搞得很难看，你花时间纠结"为什么这个特征没分到贡献"，实际问题是特征本身冗余，解释环节背锅了。

第二，SHAP 值做监控比做归因更值钱。大多数人只在建模阶段用一次就扔了。我会把每个特征的平均 |SHAP| 按周统计存下来，当作一个监控指标。当某个特征的 SHAP 均值突然翻倍或者方向翻转，通常意味着上游数据出问题了——采集口径变了、单位换了、某个传感器的量程调整了。这个信号往往比特征分布漂移检测更早、更准，因为它直接反映"模型对输出的判断依据变了"。

第三，解释的稳定性要测，不能假设。同一批样本，换一次随机抽样重跑，SHAP 的排序变了多少？我的做法是抽 5 组不同的背景集，各跑一遍，看排名前 5 的特征是否稳定。如果排序每次都不一样，说明模型本身的判断就不稳，这时候拿去做业务解释是危险的。这个检查我一般花二十分钟，但能挡掉不少后面的大麻烦。

第四，别只截单样本的图去汇报。单条样本的解释最容易被质疑"是不是挑了个特殊的例子"。我的做法是永远配一组：一张全体蜂群图说明整体格局，一张目标样本的 waterfall 说明这一条的细节，再补一句"该样本的贡献结构与群体平均水平相比，主要差异在 X 特征"。这样说服力完全不同。

第五，交互效应别硬拆。如果你的数据里存在明确的业务交互（比如高负载下的温度效应和低负载下完全不同），单特征 SHAP 给出的平均贡献量其实是一个混合体，直接拿去讲会误导。这种情况要么用交互值显式建模，要么按交互的另一维切群，分群解释。硬把交互拆成主效应，是解释环节最容易翻车的地方。

最后分享一个我在实际用下来觉得很省事的习惯：每次做完 SHAP 分析，把这次用的背景集抽样方式、解释器类型、输出空间、样本范围这四个信息写在分析文档的第一行。看着琐碎，但等到三个月后有人问"当时为什么说温度是主因"，你能在三十秒内复现整个流程，而不是从头再猜一遍参数。这个习惯帮我省掉的时间，比任何算法优化都多。