Explainable recommendation

A ranker that returns the right item but cannot say why is a black box your users distrust, your engineers cannot debug, and your regulators will not accept. The trick is to keep two questions apart — "is the model transparent?" and "can we attach an honest reason to this card?" — and to remember that an explanation is a claim about the model that most cheap methods fail to keep.

Why an explanation earns its latency

Explanations are not free — they cost compute, screen space, engineering time, and they can leak private signal (lesson 22 · Privacy). So before any method, name who the explanation is for, because the audience decides what "good" means. There are four, and they pull in different directions.

The interviewer who asks "why would you add explanations?" wants to hear that these are four jobs, not one. A method that is fine for a recommendation card ("people who liked this also liked…") can be malpractice in a fairness audit.

The master axis: intrinsic vs post-hoc

Every method sits on one side of a single axis. Either the model is transparent by construction (intrinsic, glass-box — the model is the explanation), or it is a black box you explain after the fact (post-hoc — an opaque model plus a separate explainer).

The choice is a business decision, not an aesthetic one. Pick intrinsic when the decision is high-stakes or regulated, when you are in cold start (lesson 15 · Cold start) and a simple rule is all the data supports anyway, or when the audit requirement is hard. Pick post-hoc when you have already paid for a deep ranker (lesson 04 · Ranking models) and cannot give up its accuracy — you bolt an explainer on and accept that the explanation is an approximation.

Intrinsic methods — when the model is the reason

Linear models and decision trees

A logistic CTR model p = σ(w·x + b) is self-explaining: feature i's contribution to the logit is exactly wᵢ xᵢ, and sorting those gives a per-prediction breakdown that is literally the computation (lesson 04 · Ranking models traces why we left LR behind). A decision tree hands you a root-to-leaf rule — "watch-time > 30s AND topic = cooking → recommend." In a regulated slice or for a brand-new user with three data points, that honesty is worth more than a deep model's last point of AUC.

Attention weights as explanations — and the honest caveat

Behavior-sequence rankers like DIN/DIEN (lesson 13 · User-behavior sequences) attend over the user's history: each past item hⱼ gets a weight αⱼ = softmax( a(hⱼ, cand) ) measuring its relevance to the candidate. The natural story is "we recommend this because of the high-attention items," visualized as a heat-strip over the history. It is the most popular explanation in industry — and the most over-claimed.

Knowledge-graph path explanations

The most satisfying intrinsic explanations come from models that reason over a knowledge graph of entities and relations (users, items, attributes, creators, topics). The recommendation is a path, and the path is the explanation — fully transparent and naturally human-readable.

Path-based recommenders (RippleNet, KPRN, PGPR) score a candidate by the strength of the connecting paths and surface the strongest one as the reason — faithful and readable in one object. The cost: you must build and maintain the graph, paths explode combinatorially, and graph coverage becomes the new bottleneck. But for a cold-start item with no interaction history, a semantic path ("recommended because you follow a science creator") is often the only reason you can honestly give.

Post-hoc methods — explaining a black box

You kept the deep ranker for its accuracy; now attach an explainer. Every post-hoc method shares one trick: probe the model by perturbing inputs and watch the output move.

LIME — a local linear surrogate

To explain one prediction, LIME samples perturbed versions of that input, gets the black box's prediction on each, and fits a tiny linear model in the neighborhood, weighting samples by closeness to the original. The surrogate's coefficients are the local feature importances. Model-agnostic and intuitive, but only as stable as the sampling — re-run it and the top features can wobble.

SHAP — fair credit from game theory

SHAP assigns each feature its Shapley value: the feature's average marginal contribution to the prediction, taken over all orderings in which features could be "added." It is the unique attribution satisfying three sane axioms — efficiency (contributions sum to prediction minus baseline), symmetry, and a dummy/null property:

φᵢ = Σ_{S ⊆ F∖{i}}   ( |S|! · (|F|−|S|−1)! / |F|! )   ·   [ f(S ∪ {i}) − f(S) ]     with   f(x) = φ₀ + Σᵢ φᵢ

Read it as: feature i's credit φᵢ is its marginal lift f(S∪{i}) − f(S), averaged over every coalition S of the other features. The exact sum is exponential in the feature count, so in practice you approximate — KernelSHAP (a weighted LIME-style regression) or, for tree ensembles, the exact-and-fast TreeSHAP in O(TLD²). The payoff: contributions that add up to the score, which is exactly what a developer breakdown and a fairness slice both want.

Attributing the objective, not just the feature — multi-task rankers

Everything above attributes a score to features. But a production ranker is almost never one head — it is a multi-task model (lesson 12 · Multi-task learning) that predicts watch-time, like, comment, share, and a diversity term in parallel, then fuses them score = Σ_k w_k · ŷ_k. The question a developer actually asks when the feed tilts is not "which feature fired?" but "which objective drove this card?" — and SHAP over input features cannot answer it, because two features can both feed the watch-time head and the diversity head at once. You need a second attribution axis: credit assigned over the heads / experts.

Two mechanisms, depending on how the model fuses objectives:

• LRP (Layer-wise Relevance Propagation) onto the fusion layer. Treat the final score as the relevance budget and back-propagate it through the fusion weights to each task head, conserving total relevance at every layer (the same conservation idea as SHAP's efficiency axiom, but propagated through the net rather than sampled over coalitions). The output is a clean decomposition: "this rec is 80% watch-time, 20% diversity."
• Per-expert activation in PLE / MMoE. In a gated expert architecture the gate already emits, per objective, how strongly each expert fires. Log those gate weights at serving time and you can read off when the model favored retention over clicks for a given user slice — e.g. "for new users the watch-time experts carry 0.65 of the gate mass; for power users the interaction experts carry 0.58." No extra pass; the explanation is a tensor you already compute.

Template and counterfactual explanations

Templates — the reason the user actually sees

Whatever runs under the hood, the card almost always renders through a template: "Because you watched X," "Popular with people you follow," "Trending in cooking." Templates are cheap, fast, and readable. The danger is the fake reason — filling the slot with a high-weight feature that wasn't the real driver, or a generic "popular near you" that has nothing to do with this prediction. A template is only as honest as the signal you bind into it, which is why you verify the binding with a counterfactual.

LLM-generated reasons — fluent, and a new way to lie

The emerging pattern (lesson 26 · LLMs & GenAI) replaces the rigid template slot with an LLM that writes the sentence: instead of "Because you watched X," it produces "Recommended because you saved 3 similar cooking tutorials this week and the creator is an expert you interact with often." More natural, more persuasive, higher click-through on the reason — and a fresh failure mode on top of the old one. A template can only show a fake reason (a real feature that wasn't the driver). An LLM can show a hallucinated reason: a fluent, plausible sentence describing behaviour that never happened ("because you love Italian cuisine" when the user has never touched a cooking video). The fluency is exactly what makes it dangerous — a hallucinated reason reads more trustworthy than a clumsy true one.

Counterfactuals — the most causal explanation you can cheaply give

A counterfactual answers what users and auditors actually mean: what would have to be different for the recommendation to change? "If you hadn't watched any gaming videos this week, this item would drop out of your top 10." You find it by searching for the smallest input change that flips the outcome:

x* = arg min_x'   d(x, x')    subject to    rank(item | x') > K    (item leaves the top-K)

Because it intervenes on the input and observes the output, a counterfactual is causal-by-construction — it sidesteps the "attention isn't causal" trap entirely. It is also the cleanest consistency check: if a card claims "because you watched cooking videos," remove the cooking videos and confirm the item really falls. If it doesn't, your stated reason was a lie. The cost is search (you may probe the model many times) and realism (the minimal change must be one the user could plausibly have made).

Evaluating explanations — because an unfaithful one is worse than none

Here is the dimension most candidates miss entirely. You can pick the right method, bind a beautiful template, and still ship a disaster — because you never measured whether the explanation works. The engineering line is sharp: an explanation is a claim about the model, and an unfaithful or useless claim is not neutral, it is negative. A wrong "because you watched X" actively erodes the trust the feature was supposed to build, teaches users to ignore reasons, and — if it leaks into a fairness narrative — hands a regulator a false account. So explanations get the same treatment as any other shipped surface: a metric suite, thresholds, and an A/B with causal attribution. The book devotes a whole section to this; the lesson would be incomplete without it.

Measure on three layers, because the four audiences (top of this lesson) need different evidence.

Now the obvious next question — when the experiment shows watch-time down but share-rate up (a real and common outcome), the verdict is not a single number. You build a weighted decision score across the objectives and decide explicitly, exactly the multi-objective reasoning of lesson 08 · Evaluation; the explanation framework feeds that decision, it does not bypass it.

The accuracy–explainability tradeoff (and why it's overstated)

The folk theorem: simple models are explainable but weak, powerful models are accurate but opaque, so you must trade one for the other. There is a kernel of truth — a 3-deep tree genuinely cannot match a DCN-v2 cross stack on a billion-event dataset. But the tradeoff is routinely overstated, for three reasons:

• Post-hoc breaks the dilemma. You keep the accurate model and get an explanation; you give up faithfulness-by-construction, not accuracy. For user-facing justification, approximate faithfulness is usually fine.
• On structured signals the gap is often tiny. A well-tuned gradient-boosted tree (intrinsically interpretable via TreeSHAP) frequently sits within a fraction of a percent of a deep net — and is glass-box. The supposed accuracy cost of interpretability evaporates on exactly the tabular data recommenders mostly run on.
• Explainability buys accuracy back elsewhere. Explanations are how you find the leaked label, the popularity runaway, the train–serve skew. A debuggable model converges to a better production metric faster than an opaque one you cannot diagnose.

Interactive · feature-attribution composer (toy SHAP)

Toggle which signals fired for one prediction. The widget shows a SHAP-style additive breakdown — each feature's φᵢ contribution to the logit, summing to the score — picks the template slot from the top contributor, and runs a counterfactual consistency check on the reason it would show. The numbers are toy; the failure modes are the point.

Interview prompts you should be ready for