skip to content

How does the choice of background set change a Shapley explanation of the same prediction?

level: principalimportance: nice to knowfreq 28%

answer

  1. explanations are always relative to something
  2. the reference sets the total being split
  3. a feature at the reference gets zero
  4. pick it from the question being asked
  5. version it like a model artifact

basics

~20 s

The background set defines what the prediction is compared against, so it decides the whole explanation: attributions sum to the prediction minus the background's prediction, and a feature already sitting at its background value gets zero credit.

solid answer

~50 s

Every Shapley attribution answers "why this prediction rather than *that* one", and the background set is the *that*. Explain the same delivery-ETA row against an all-zeros row, against the training median row, and against last quarter's customers, and you get three different sets of numbers - all correct, answering three different questions. The mechanics: the attributions must sum to the prediction minus the background's prediction, so a different background changes the total being split; and any feature whose value already matches the background contributes nothing, so it disappears from the report. That makes the background a product decision, not a default. Pick a reference the audience would recognise as the natural comparison - a typical customer, an approved applicant, the relevant cohort - then freeze it, version it alongside the model, and treat a change to it as a change to every explanation you have ever shipped.

go deeper

for a junior

Remember that an attribution is always a comparison: it says how this prediction differs from a reference prediction, so the reference has to be stated alongside the numbers for them to mean anything.

for a middle

Explain the mechanics of the shift - the reference prediction sets the total the attributions must sum to, and a feature already at its background value receives zero, so changing the background changes both the totals and which features appear.

for a senior

Show you would pin it in production: one chosen background, versioned with the model, its identity printed with every explanation, and a debugging instinct that checks the reference before suspecting the model when attributions move.

for a principal

Own the choice and its blast radius - which comparison the audience actually needs, whether different surfaces justify different named backgrounds, and the governance that treats a background change as a change to every explanation already issued.

## The background is half the explanation A Shapley attribution is never absolute. It splits `prediction - baseline_prediction`, and the baseline comes from the background set: the rows used to fill in whatever features a coalition leaves out. Change the background and every number changes, even though the model and the row being explained are untouched. Teams that treat the background as an implementation default end up shipping explanations whose meaning nobody has actually chosen. ## Mechanically, what moves 1. **The total being split.** Efficiency ties the attributions to `f(row) - E[f(background)]`. A background whose average prediction is 26 minutes and one whose average is 33 give totals of 12 and 5 for a 38-minute prediction. The same drivers get compressed or stretched. 2. **Which features are visible.** A feature whose value in this row equals its background value has zero marginal contribution in every coalition, so its attribution is zero. Against an all-zeros background, a customer with a zero balance shows nothing for balance; against a median-customer background, that same zero balance is a large negative deviation and shows up strongly. Nothing about the customer changed - only the comparison. 3. **The sign of familiar drivers.** Attributions are deviations from the reference, so a feature that reads "+" against a low-scoring reference can read "-" against a high-scoring one. ## The common choices and what each one means - **A single all-zeros or all-defaults row.** Cheap - one model evaluation per coalition - and deterministic. Its weakness is interpretive: "why 38 rather than what the model says about a customer with zeros everywhere" is rarely a question anyone asked, and a zeros row is often not a coherent customer at all, so the reference point is hard to defend to a reviewer. - **A single central row (training medians and modes).** Reads naturally as "compared to a typical customer", still one evaluation per coalition. But a row of per-column medians can itself be an unrealistic combination, and a single row throws away the spread of the population. - **A sample of the training set.** The reference becomes the model's average prediction, which is the most defensible general-purpose meaning: "why this order is slower than an average order". Cost scales with the sample size, so the sample is chosen for a variance/compute trade. - **A cohort-specific background - for example, last quarter's customers, or only approved applicants.** This makes the explanation answer a targeted question: "why is this order slower than the ones we handled last quarter?" It is the most decision-relevant option and the most dangerous one, because two explanations computed against different cohorts are not comparable with each other, and a drifting cohort silently rewrites the meaning of a stable dashboard. ## The organisational decision The principal-level call has three parts. **Choose by the question, not the default.** Write down the sentence the explanation is meant to complete - "this order is 12 minutes slower than a typical order because…" - and pick the background that makes the sentence true. If different audiences need different sentences (an operations dashboard versus a customer-facing message), that is an argument for two explicitly named backgrounds, not for one background used loosely for both. **Freeze and version it.** The background is a model artifact, on the same footing as the trained weights: stored, versioned, and shipped with the model. Recomputing it monthly from "recent data" means yesterday's explanation of an unchanged prediction differs from today's, and no one will be able to tell whether the model, the data or the reference moved. Any change to the background is a change to every explanation ever issued against it, and should go through the same review a model change does. **State it wherever the numbers appear.** An attribution shown without its reference point is unfalsifiable. The audit-friendly form is "predicted 38 minutes, 12 above the reference of 26 (typical order, background v3)", followed by the split. That single line makes efficiency checkable by the reader and makes a later background change visible rather than silent. ## Sizing and cost Background size is a straight variance-versus-compute trade: a single row is cheapest and noiseless but interpretively narrow; a large sample is the most faithful notion of "average" but multiplies every coalition evaluation. A modest stratified sample - covering the segments the audience cares about in proportion - usually captures nearly all of the interpretive benefit at a fraction of the cost of the full training set. ## The failure to watch for The characteristic incident is not a wrong number but an unexplained change: attributions on a dashboard shift, an analyst chases a model regression, and the cause turns out to be a background quietly recomputed from newer data. Versioning the background and printing its identity next to the numbers converts that multi-day investigation into a one-line diff.

  • Attributions on a dashboard shifted overnight with no model release - where do you look first?
    At the background. If it is recomputed from recent data rather than pinned, the reference prediction moves, the total being split moves, and every attribution shifts even though the model and the rows are unchanged. The fix is to version the background with the model and print its identity beside the numbers so the change is a visible diff instead of a mystery.
  • Is there a downside to using a cohort-specific background instead of the whole training sample?
    It buys relevance at the cost of comparability. "Slower than last quarter's orders" is the question operations actually asks, but explanations computed against different cohorts cannot be compared with each other, and a drifting cohort silently changes what a stable-looking report means. Use it deliberately, name it in the output, and freeze the cohort snapshot.

saying these in an interview costs you the question

  • Treats the background as an implementation detail
  • Reports attributions without stating the reference point
  • Recomputes the background from fresh data every run
  • Assumes an all-zeros row is a neutral reference
  • Compares attributions computed against different backgrounds

context