Skip to content

Approximate mode

Exact mode requires an additive model — per-feature term contributions must exist. For an unconstrained (interacting) LightGBM booster they do not, so TRIAD instead reallocates the booster's native TreeSHAP attributions into the same three channels. This is the spec's "approximate TRIAD", shipped in v0.1 (decision 1).

explainer = TriadExplainer(booster, bag_boosters=bags, X_ref=X_train)
exp = explainer.explain(X_test)
exp.approximate   # True

Mechanics

  • Attributions: \(\phi_j(x)\) from LightGBM's built-in predict(pred_contrib=True) — the shap package is not needed.
  • Variance: the per-instance variance of \(\phi_j\) across bag replicas (at least 2 required).
  • τ²: per feature, by method of moments about the zero prior on a reference population X_ref: \(\hat\tau^2_j = \max(0,\ \overline{\phi_j^2} - \bar v_j)\). SHAP attributions are centered on the training population, so a strongly nonzero mean triggers a warning that X_ref may not match the training data.
  • Channels: same routing as exact mode — \(I = w\phi\) on observed values, \(M = w\phi\) on missing values, \(D = \phi - I - M\) as the residual, so C1 holds exactly. C2 is TreeSHAP's local accuracy (verified ≤ 9e-15 in the test suite).
  • No out-of-range decay: bag disagreement already rises where training data is sparse, subsuming exact mode's decay heuristic; the oov flag is still emitted (decision 3).

What "approximate" gives up

Recorded in decision 5:

  • \(\phi_j\) is not a function of \(x_j\) alone — interaction effects leak into per-feature attributions via TreeSHAP's path-dependent allocation.
  • No per-bin audit tables — the audit payload becomes per-instance \(v\)/\(w\) plus per-feature \(\hat\tau^2\).
  • The decomposition depends on the reference population (base value and \(\hat\tau^2\)).

Waterfall plots of approximate explanations carry an "approximate" badge, and TriadExplanation.approximate is True.

The cross-mode invariant

On an additive-constrained booster the two modes coincide: LightGBM's pred_contrib attribution equals the centered shape value to ~1e-14. The test suite uses this to tie the two pipelines together — running mode="shap" on an additive booster is allowed and matches exact-mode totals (decision 12). The reverse is not: mode="exact" on a non-additive booster raises.