Global vs Local Explanations — The Friendly Argument Between the Big Picture and the Tiny Slice

"You wouldn't ask a cardiologist to explain your bank statement — so why ask one model to explain everything at once?" — probably me, 2 AM, after too many datasets.

Opening: Why this chapter matters (and how it builds on what you already know)

You just learned to automate pipelines, search hyperparameters, and track experiments reproducibly. Nice! You can now train models that behave reliably in CI, reproduce a result from three coffee-fueled nights ago, and hand an artifact to a teammate. But: your model's predictions are still a black box to stakeholders, regulators, or that one skeptical product manager.

This is where interpretability and responsible AI come in. We’re moving from "How to make the model better" to "How to understand and trust the model's decisions." And importantly, how to record those explanations as artifacts in your pipeline and experiment tracking system so downstream users don't have to re-run the entire training loop just to audit a decision.

---

Big idea: Global vs Local — the difference in one sentence

• Global explanations answer: How does the model behave overall? (the forest)
• Local explanations answer: Why did the model make this particular prediction? (the single tree)

Imagine a medical diagnostic model. A global explanation tells you which features the model generally uses to decide disease risk. A local explanation tells you why patient #123 was assigned a high-risk score today.

---

Global explanations: What the model generally cares about

Goal: Summarize model behavior across the dataset.

Common techniques:

• Feature importance (e.g., permutation importance, tree-based importances)
• Partial Dependence Plots (PDPs) — show average marginal effect of a feature
• Individual Conditional Expectation (ICE) plots — PDP but per instance
• Surrogate models — train an explainable model (like a shallow tree) to mimic the black box
• Global SHAP/Integrated Gradients aggregates — aggregate local contributions to get a global view

Strengths:

• Good for model debugging and communicating broad patterns
• Useful for feature selection and fairness audits (e.g., checking if protected features dominate)

Limitations:

• May hide heterogeneity — the average effect can be misleading if behavior varies by subgroup
• Can be less actionable for individual cases (legal appeals, customer support)

Analogy: Global explanations are like a company’s annual report. Useful for investors, but not for resolving why your paycheck was wrong this month.

---

Local explanations: Why this prediction for this person?

Goal: Explain an individual prediction.

Common techniques:

• LIME (Local Interpretable Model-agnostic Explanations) — fit a simple local surrogate around a point
• SHAP (SHapley Additive exPlanations) — game-theoretic feature attributions with strong axiomatic properties
• Counterfactual explanations — minimal changes to input that flip the decision ("If your income were $5k higher, you'd be approved")
• Gradient-based saliency (for neural nets) — highlight which input dimensions most influenced prediction

Strengths:

• Actionable for end users ("do X to change outcome Y")
• Essential for individual recourse, appeals, and debugging single unexpected predictions

Limitations:

• Can be unstable: explanations might vary a lot for tiny perturbations
• Usually limited fidelity: local surrogates approximate the model only in a small region
• Risk of over-interpreting correlational signals as causation

Analogy: Local explanations are like a customer support ticket. They explain one customer's issue, not the whole business.

---

Quick comparison table

Aspect	Global	Local
Question answered	How does the model behave on average?	Why did the model predict this for this instance?
Typical methods	Feature importance, PDPs, surrogate models	LIME, SHAP, counterfactuals
Best for	Policy, audits, feature engineering	Recourse, debugging single cases, legal review
Risk	Masks heterogeneity	Unstable / overconfident explanations

---

Practical workflow: Where these fit in your pipelines and experiment tracking

1. During training experiments, compute global explanations as lightweight artifacts: feature importances, PDPs, and a surrogate model. Log them with your experiment run.
2. For model releases, bundle representative local explanations (SHAP summaries on key samples, counterfactual templates) so product teams can reproduce user-facing rationale without re-training.
3. When debugging a regression of AUC or fairness metric in an experiment, use SHAP/ICE plots on a validation slice to identify subgroups where the model's decision rule changed.
4. Automate explanation generation in the pipeline (like you do hyperparameter sweeps) and version these artifacts. That way, audits can replay exactly the explanation that existed when a decision was made.

Code sketch (pseudocode):

# After training model
importance = permutation_importance(model, X_val)
shap_values = shap_explainer.shap_values(X_sample)
log_artifact(run_id, 'feature_importance.json', importance)
log_artifact(run_id, 'shap_sample.pkl', shap_values)

---

Responsible AI checklist: Don't be a garbage can of explanations

• Validate fidelity: For surrogate explanations, measure how well the surrogate predicts the original model in the locality (R^2 or fidelity metrics).
• Test stability: Do explanations change when you add small noise? If yes, warn users or prefer more stable methods.
• Watch out for proxy features: High importance doesn't equal causation — a ZIP code might proxy for race.
• Provide uncertainty: Report confidence intervals or variance over explanation runs.
• Human-centered presentation: Tailor the explanation to the audience—legal, product, engineering, or the end-user.

---

Pitfalls & gotchas (aka why your neat explanation might lie)

• Averaging is a lie: PDPs can hide multimodal behavior.
• Local methods can be brittle: LIME's neighborhood definition matters; SHAP approximations can be expensive.
• Explanations can be gamed: Models can be optimized to look explainable without being better.
• Regulatory context: Some jurisdictions require "meaningful information about the logic" — interpretability artifacts should be reproducible and auditable.

---

Quick heuristics: When to use what

• Want to audit model fairness across groups? Use global explanations + subgroup PDPs/ICE.
• Need recourse for a user? Provide counterfactuals or local SHAP/LIME plus clear guidance.
• Debugging strange predictions? Local explanations on failing cases, then follow with global checks.
• Building an interpretable model from the start? Prefer transparent models where possible; use global explanations to confirm.

---

Closing: TL;DR and an action plan

• Global = forest view. Use it for audits, feature selection, and communicating broad behavior.
• Local = tree view. Use it for recourse, support, and case-by-case debugging.

Actionable next steps:

1. Add automated global explanation artifacts to your training pipeline and log them with experiment runs.
2. Pick a stable local explainer (SHAP is a strong default), generate explanations for a curated sample, and log them too.
3. Validate explanation fidelity and stability as part of your test suite.

Final dramatic truth: Good models + good explanations = trust. Good explanations without reproducibility = theater. Keep your explanations versioned, reproducible, and human-readable — that's responsible AI in action.

---

Version notes: This builds on your work with pipelines, hyperparameter tuning, and experiment tracking — think of explanations as the final artifacts you must produce, version, and defend.