2. 可解释性基础

在进入审计方法之前，必须先建立一套稳定的概念坐标系。可解释性讨论中最常见的混乱，是把“模型本身是否透明”“解释覆盖多大范围”“解释在训练前还是训练后产生”这三件事混为一谈。它们其实是三个正交维度：透明程度、解释范围、解释时机。理解这三个维度，才能准确判断一个解释结论能否作为决策证据。

一、核心原理：三个正交维度

第一个维度是模型透明度。透明模型（transparent model）指其内部结构与决策规则可以被人类直接阅读和理解，例如线性回归、决策树、广义加性模型、规则列表。黑箱模型（black-box model）则指其内部参数规模或非线性组合方式超出人类直接阅读能力，例如深度神经网络、梯度提升树集成、大规模语言模型。需要强调：黑箱不等于不可解释，它只是不能“直接读懂”，需要借助外部解释工具。

第二个维度是解释范围。全局解释（global explanation）描述模型在整个输入空间上的整体行为，例如特征重要性排序、决策树整体结构、部分依赖图。局部解释（local explanation）只针对某一次具体预测，回答“为什么这个样本得到这个分数”，例如 LIME、SHAP 单样本值、反事实解释。全局解释适合模型审查与合规评估，局部解释适合个案申诉与人工复核。

第三个维度是解释时机。内在可解释（intrinsic interpretability）指模型在设计时就以可理解为约束，透明性来自结构本身。事后可解释（post-hoc interpretability）指模型训练完成后，用额外方法去近似或探测其行为。事后解释方便，但它解释的是“代理模型”或“近似行为”，并不等于模型真实内部机制，这一点在审计中必须明确标注。

二、方法流程：从模型到证据的四步链路

在审计场景中，可解释性不是“跑一个库函数”，而是一条证据链。建议按以下四步执行，每一步都留下可复核记录。

1. 模型定性：先判定模型属于透明还是黑箱，记录模型类型、参数量、训练框架与版本。
2. 解释目标定义：明确本次要回答的是全局问题（如“模型是否依赖敏感特征”）还是局部问题（如“为何该客户被拒”）。
3. 解释方法选择：根据目标选择内在或事后方法，并记录方法假设、采样参数与随机种子。
4. 证据固化：保存解释结果、输入样本、模型版本、代码提交号，形成可追溯的审计证据包。

三、案例/场景：信贷拒贷解释

某银行使用梯度提升树模型进行信贷审批。监管要求对拒贷客户给出理由。这里同时涉及三个维度：模型是黑箱（集成树），解释目标是局部（单个客户），解释时机是事后（训练后使用 SHAP）。

# 伪代码：局部事后解释证据固化
model_version = "gbdt-2024-11-03"
sample_id = "CUST-88213"
explainer = SHAPTreeExplainer(model)
shap_values = explainer.shap_values(sample_features)
top_reasons = rank_top_k(shap_values, k=3)
audit_log = {
  "model_version": model_version,
  "sample_id": sample_id,
  "method": "TreeSHAP",
  "top_reasons": top_reasons,
  "seed": 42
}
save_evidence(audit_log)

如果换成逻辑回归，则模型透明、解释可以是全局系数，也可以是局部贡献，且属于内在可解释。两种方案都能给出理由，但证据强度与可复核性不同：内在解释直接来自模型结构，事后解释依赖近似假设。

四、误区/复盘：四个常见陷阱