Author: admin

MSD0024 LinkedIn Job Recommendation
Design the job recommendation system for LinkedIn Jobs. When a member visits the Jobs page or receives a job alert email, the system must rank open positions from a catalog of millions by how likely the member is to apply and, ultimately, to get hired.
The ranking must respect hard constraints (location, work authorization, years of experience, salary expectations), handle the cold-start problem for new members and newly posted jobs, and avoid recommending jobs the member has already seen or dismissed. LinkedIn’s two-sided marketplace means the system also affects employers, who pay for applications and churn if candidate quality is poor.
How would you design this system? Cover the candidate generation and ranking funnel, the feature set (member profile, job requirements, interaction history), how you handle cold start, the online and offline metrics, and how you balance member and employer value.

The Problem: one member with hard eligibility constraints, millions of open postings, and a recruiter on the other side who pays for applications and leaves if the applicants are unqualified.
Answer
The design is a standard four-stage recommender funnel wrapped around a two-sided objective: hard-constraint filtering, multi-source candidate generation down to roughly a thousand jobs, a multi-task ranker, then a policy re-rank layer that enforces marketplace and compliance rules. The pivotal design decision is what the ranker optimizes. Optimizing apply probability alone maximizes member clicks and floods a few popular postings with unqualified applications, so the score blends P(apply), P(recruiter treats the application as qualified), and a delayed P(hire) head, which is the objective LinkedIn’s own confirmed-hires framing points at. The second pivotal decision is to treat eligibility as a pre-filter in the retrieval index rather than a learned soft feature, because a job the member cannot legally take is a wasted slot for both sides.
(1) Hard Constraints As Pre-Filters: location radius or remote flag, work authorization, seniority window, and compensation band are boolean index filters applied before scoring, never soft features the ranker can trade away.
(2) Multi-Source Candidate Generation: a two-tower ANN over job embeddings, plus saved searches and alerts, plus graph sources (“members with your title applied here”) and company affinity, unioned to about 1000 candidates.
(3) Multi-Task Ranker: one shared-bottom or MMoE model with heads for apply, qualified-application, and confirmed hire; the serving score is a weighted combination whose weights are the marketplace policy knob.
(4) Cold Start By Content Plus Exploration: both towers are content-based (title, extracted skills, seniority, company), so new members and postings get vectors immediately, and new postings receive a small guaranteed impression budget.
(5) Policy Re-Rank Layer: deduplicate seen and dismissed jobs, cap applicant load per posting, spread traffic beyond the head of the catalog, and apply fairness-aware re-ranking.
(6) Two Serving Paths: the Jobs page runs the funnel online under a ~200 ms budget; alert emails run the same models in a nightly batch with frequency caps and a higher score threshold.

Figure 1: The funnel narrows 20M postings to 25 shown jobs, and the loop back through label joining is what turns applies, recruiter replies, and hires into tomorrow’s model.
Clarify Before Designing:
(1) Surface And Budget: Jobs page (online, latency-bound) or alert email (batch, frequency-bound), and what end-to-end latency budget does the page allow?
(2) Label Availability: do we have recruiter-side signals (application viewed, candidate contacted) and confirmed hires, or only member-side clicks and applies?
(3) Catalog Scale And Freshness: how many open postings, what is the median posting lifetime, and how quickly must closed jobs disappear?
(4) Monetization: are promoted or sponsored jobs blended into the same slots, and is there a separate auction and pacing layer?
(5) Compliance: which fairness and audit requirements apply (employment discrimination law, automated hiring-tool bias audits), and which member attributes are forbidden as features?
(6) Employer Capacity: do postings expose applicant caps or response-time signals we can use to protect candidate quality?
Login to view more content
August 22, 2026
MSD0023 YouTube Copyright Detection
Design the copyright detection system for a video platform like YouTube. Every uploaded video (hundreds of hours per minute) must be scanned against a reference corpus of tens of millions of copyrighted songs, movies, and clips, and matched even when the content is pitch-shifted, cropped, overlaid with voiceover, recorded off a screen, or remixed. The system must return matches within minutes so that rightsholders can block, monetize, or track the use, and it must keep the false-positive rate low enough that legitimate fair use and original content are not wrongly claimed.
How would you design this system? Cover the audio and video fingerprinting representations, the matching index at scale, the latency and throughput budget for the upload firehose, how you handle partial and transformed matches, and how disputes and appeals are routed.

The Problem: the copy is never bit-identical, the corpus is tens of millions of references, the answer is owed in minutes, and a wrong claim silences a legitimate creator.
Answer
The design is a two-stage fingerprint retrieval system: cheap, high-recall candidate generation from compact per-modality fingerprints, then strict temporal verification that only accepts a candidate if many hash hits agree on a single time offset. Audio and video are fingerprinted separately because their attack surfaces differ. Audio uses spectral peak landmark hashes plus a neural fallback for pitch and tempo edits, while video uses learned copy-detection embeddings that survive cropping, overlays, and screen recording. The two pivotal decisions are to make the verification stage, not the recall stage, own precision, and to convert model confidence into tiered actions (auto-claim, human review, track-only) so that an uncertain match costs a reviewer’s time rather than a creator’s channel.
(1) Dual-Modality Fingerprints: audio landmark hashes of the form $(f_1, f_2, \Delta t)$ at roughly 30 hashes per second, and video frame descriptors sampled at 2 to 4 fps after letterbox and border normalization.
(2) Two-Stage Retrieval: a sharded inverted index (plus ANN search over neural embeddings) proposes a few hundred candidate references per query chunk; verification rejects almost all of them.
(3) Offset Voting And Segment Stitching: a real match produces a spike in the histogram of $t_{ref} - t_{query}$ ; adjacent winning chunks are stitched into segments with a minimum matched duration.
(4) Chunked Parallel Ingest: uploads are split into 10-second chunks that fingerprint in parallel, with a priority queue so premieres and large channels finish first.
(5) Tiered Actions: high confidence auto-claims, medium confidence routes to human review or track-only, low confidence is logged and dropped.
(6) Dispute Loop As Training Data: every appeal outcome becomes a label, feeding whitelists, threshold retuning, and reference-corpus cleanup.

Figure 1: One path for uploads (fingerprint → lookup → verify → policy) and one offline path that fingerprints rightsholder references with the same extractor; disputes flow back from the policy engine into verification thresholds and whitelists.
Clarify Before Designing:
(1) Scope Of Rights: do we match sound recordings only, or also compositions and melodies, since a cover song copies the composition without copying any audio?
(2) Verdict SLA: must the scan block publishing, or may the video go live and be claimed minutes later, and does the SLA differ for monetized channels?
(3) Corpus Scale And Registration: how many references, how fast is the corpus growing, and who is allowed to register a reference?
(4) Cost Asymmetry: what false-claim rate is acceptable versus missed detections, and who pays for human review of the uncertain band?
(5) Transformation Catalog: which edits must be caught (crop, pitch shift, speed change, voiceover, screen capture, remix, AI covers), because that choice decides the fingerprint representation?
(6) Available Actions: block, monetize, or track, and are the policies territory-specific?
Login to view more content
August 22, 2026
MSD0022 Model Drift Dashboard
A large platform runs thousands of ML models in production: ranking models, fraud classifiers, content moderators, recommendation embedders, each with its own feature pipeline, serving path, and delayed-label feedback. A single broken upstream feature, a silent model upgrade, or a gradual distribution shift can degrade any of them for days before anyone notices.
The ML platform team needs one real-time monitoring system that surfaces drift, performance, and data-quality issues across the entire fleet, with alerting that catches real regressions without drowning on-call engineers in false alarms. How would you design this system? Cover the metrics each model emits, the streaming and storage architecture for thousands of models, the drift and anomaly detection methods that scale across heterogeneous model types, the alerting and triage workflow, and how you measure the monitoring system itself (mean time to detect, alert precision).

The Problem: one model in a fleet of thousands is quietly getting worse, and the on-call engineer is already ignoring a pager full of alerts that were never real.
Answer
The design is a fleet-wide observability service with three layers. Every serving path emits a uniform telemetry record through a shared logging SDK, a streaming job compresses those records into per model, feature, slice and window sketches, and a detection layer runs cheap statistical guards on everything plus expensive label-joined performance checks on the models that carry real money. The two pivotal decisions are that detection never scans raw events at query time (it reads compact profiles, which is what makes thousands of models affordable), and that alerting is engineered for precision rather than coverage: a trigger must clear an effect-size floor, persist across several windows, and survive root-cause grouping before it pages anyone. The monitoring system is itself a product with SLOs, scored on mean time to detect and alert precision against continuously injected synthetic regressions.
(1) Uniform Telemetry Contract: one prediction record schema (model id and version, feature values or hashes, score, slice keys, join key, latency) emitted asynchronously by a sidecar or SDK, so the platform never reimplements logging per team.
(2) Sketch-Based Aggregation: a streaming job keeps t-digest quantiles, count-min sketches for categoricals, and null/count/cardinality counters per 5-minute window, turning terabytes of events into tens of gigabytes of profiles.
(3) Tiered Detection: tier-1 data-quality and drift guards run on every model and feature; tier-2 label-joined AUC, calibration, and slice regressions run only on business-critical models.
(4) Delayed-Label Handling: proxy signals (score distribution, positive rate, confidence) fire in minutes, while true performance is computed on maturity-aware cohorts so immature labels never trigger a page.
(5) Precision-Engineered Alerting: adaptive seasonal baselines, an effect-size floor, multi-window persistence, and deduplication by feature lineage turn thousands of triggers into a handful of owned incidents.
(6) Self-Measurement: synthetic drift and corrupted-feature injections give a labeled incident corpus, so MTTD and alert precision are measured, not asserted.

Figure 1: Raw predictions are compressed once into profiles; every detector, dashboard, and alert afterwards reads those profiles instead of the event stream.
Clarify Before Designing:
(1) Fleet Shape: how many models, how many features each, aggregate QPS, and how many are business-critical versus experimental?
(2) Detection Budget: is the target time to detect minutes, an hour, or a day, and is it the same for a fraud classifier and a feed ranker?
(3) Label Latency: per use case, how long until ground truth arrives (clicks in seconds, chargebacks in weeks, moderation appeals in days)?
(4) Cost Ceiling: what fraction of serving cost may monitoring consume, and can we sample rather than log every request?
(5) Remediation Authority: may the system auto-rollback a model version or quarantine a feature, or does it only page a human owner?
(6) Data Constraints: which features are PII or regulated, and what is the retention limit on stored feature values?
Login to view more content
August 22, 2026
MSD0021 Hashtag Video Relevance
On a short-video platform like TikTok or Instagram Reels, creators attach hashtags to reach an audience, and a large share of those tags are clickbait: #fyp or a trending sports tag stapled onto a video that has nothing to do with the topic behind it. The core problem is a multimodal relevance scoring mechanism. Given a video (sampled frames, audio, OCR’d on-screen text, creator caption) and a candidate hashtag, produce a relevance score that separates honest tagging from spam.
How would you design this model? Cover the candidate fusion architectures (late fusion of per-modality encoders, early token-level fusion, cross-attention, contrastive hashtag-video embedding), how you represent the hashtag itself (its text, its trending-topic cluster, its co-occurrence graph), how you generate training labels at scale when human-labeled relevance is scarce, and how you handle cold start for a brand-new hashtag with no co-occurrence history.

The Problem: the same video carries an honest tag and a hijacked trending tag, and nothing in the upload tells you which is which. You need a score for every (video, tag) pair, over a tag vocabulary of tens of millions and with almost no human relevance labels.
Answer
The design is a two-stage multimodal relevance model. A contrastive dual tower is pretrained on billions of weakly labeled creator (video, tag) pairs, which gives every tag in the vocabulary a cheap vector and initializes both encoders. A cross-attention scorer then rescores the handful of tags actually attached to a video, letting the tag’s query tokens read the video’s frame, audio, OCR, and caption tokens so a localized mismatch (a football tag on a pasta video, or a single on-screen word borrowed from a trend) becomes visible. Two decisions are pivotal. First, the hashtag is a sum of three slots (subword text, trending-topic cluster centroid, co-occurrence graph embedding) trained with slot dropout, which is what makes cold start work rather than a special case bolted on later. Second, labels come from creator behavior plus frequency-matched hard negatives drawn from the same topic cluster, anchored by a small human gold set used only for calibration and as the release gate.
(1) Late Fusion: one encoder per modality, each pooled to a vector, concatenated with the tag vector into a shallow MLP; everything cacheable, no token-level interaction.
(2) Early Fusion: all modality tokens plus the tag tokens in one transformer from layer 1; maximally expressive and completely uncacheable across candidate tags.
(3) Cross-Attention Scorer: video tokens encoded once as keys and values, hashtag slots as a small query set, a few cross-attention layers plus a sigmoid head.
(4) Contrastive Embedding: dual-tower video and tag encoders trained with InfoNCE or a sigmoid pairwise loss so relevance is a dot product in a shared space.

Figure 1: The scoring mechanism: the video is encoded once into a token set, the hashtag arrives as three composable slots, and cross-attention decides whether the video contains evidence for the tag.
Clarify Before Designing:
(1) Input budget: how many frames per video, is audio and reliable OCR available, and is the caption trustworthy or itself keyword-stuffed?
(2) Compute budget: how many candidate tags are scored per video, and may the video encoder run once at upload so per-tag cost is the only thing multiplied?
(3) Pretrained assets: is there an in-house video-language encoder to freeze, or must the towers be trained from scratch on platform data?
(4) Vocabulary shape: how large is the tag vocabulary, what fraction of traffic is meta-tags such as #fyp, and how fast do new tags appear?
(5) Label reality: how many human-labeled pairs exist today, and can we buy a gold set for calibration even if we cannot buy a training set?
(6) Output contract: is the consumer a hard threshold, a ranking feature, or a reviewer queue, since only the first two need a calibrated probability?
Login to view more content
August 22, 2026
MSD0020 Distributed Training System
Design the distributed training system for a 100B+ parameter language model on a cluster of thousands of GPUs, the way Meta, OpenAI, and DeepSeek run their frontier models. A single run spans weeks to months, costs millions of dollars in compute, and must survive GPU failures, network bottlenecks, and stragglers without restarting from scratch.
The system has to combine data, tensor, and pipeline parallelism, checkpoint efficiently, and keep GPU utilization high enough that the run finishes on budget.
How would you design it? Cover the parallelism strategy and communication topology, fault tolerance and checkpointing, cluster scheduling, and how you diagnose and fix the bottlenecks that keep utilization below target.

The Problem: the model does not fit on one GPU, the cluster is big enough that something breaks every few hours, and every idle GPU-second is billed. The design question is how to keep thousands of accelerators busy on one gradient for a month.
Answer
The design is 3D parallelism mapped onto the bandwidth hierarchy, wrapped in an elastic supervisor that treats hardware failure as a routine event. Tensor parallelism stays inside a node where NVLink is cheap, pipeline parallelism crosses nodes because only stage activations travel, and data parallelism with sharded optimizer state sits outermost where the gradient all-reduce can be overlapped with the backward pass. Fault tolerance is asynchronous distributed checkpointing at a mathematically chosen interval plus a hot-spare pool, so a dead GPU costs minutes rather than the run. The single number the whole system is managed against is MFU (model FLOPs utilization), because at this scale every lost percentage point is real money, and every design choice below is justified by its effect on that number.
(1) Bandwidth-Matched Parallelism: tensor parallel degree capped at the intra-node GPU count, pipeline parallel across nodes, data parallel outermost; context parallelism added only when sequences get long.
(2) Sharded State And Selective Recompute: optimizer states and gradients sharded across the data-parallel group, with selective activation recomputation trading roughly 8% extra FLOPs for the memory that makes the fit possible.
(3) Async Checkpointing At The Optimal Interval: copy state to host memory in seconds, flush to storage in the background, and set the interval from measured cluster MTBF instead of habit.
(4) Elastic Recovery With Hot Spares: a watchdog detects hangs and stragglers, a spare node replaces the failed one in place, and training resumes from the last checkpoint including data-loader position.
(5) Topology-Aware Gang Scheduling: the job is placed inside one network island as an all-or-nothing gang, after a preflight burn-in that rejects slow links and weak GPUs before the run starts.
(6) MFU As The Run’s SLO: per-rank step-time histograms, profiler traces, and a loss budget that attributes every missing point of peak FLOPs to a named cause.

Figure 1: One step is load → forward → backward → reduce → update → stage checkpoint. The lower loop is what makes a month-long run survivable: detect, replace, restore.
Clarify Before Designing:
(1) Hardware And Interconnect: how many GPUs per node, what intra-node link (NVLink or PCIe), and what inter-node fabric bandwidth per GPU?
(2) Token Budget And Deadline: how many training tokens, and is the constraint calendar time, total GPU-hours, or dollars?
(3) Sequence Length: is context 8k or 128k, because long context changes activation memory and adds a whole parallelism axis?
(4) Precision Policy: is FP8 or BF16 allowed for GEMMs, and what loss-curve deviation from a reference run is acceptable?
(5) Storage And Checkpoint SLA: what aggregate write bandwidth exists, and how much lost work per failure is tolerable?
(6) Cluster Ownership: dedicated reservation or shared preemptible pool, and how large a hot-spare pool can be held idle?
Login to view more content
August 21, 2026
MSD0019 On-Device Small LLM Polite
Design a small LLM that runs entirely on a phone for a privacy-preserving assistant, in the style of Apple Intelligence’s on-device foundation model or Gemini Nano on Pixel. The model must fit in roughly 2-4 GB of RAM, respond in under 300 ms on a mobile NPU, and work with the radio off.
It also has to stay polite. It should refuse harmful requests, avoid toxic or biased outputs, and hold a respectful tone even when the user is deliberately provoking it. Battery life and offline capability matter as much as raw benchmark quality, and no user text may leave the handset.
How would you design this system? Cover model compression and quantization for the NPU, the alignment strategy that keeps the model polite at a small scale, the on-device serving path, and how you evaluate safety without sending user data to the cloud.

The Problem: a few gigabytes of RAM, a fraction of a second, no network, and a user who is testing how rude the assistant will get.
Answer
The design is a distilled 3B-parameter model compressed with quantization-aware training to about 2 bits per weight, served on the NPU with per-feature LoRA adapters and a tiny always-resident guard model. Politeness is trained in rather than prompted in: a large aligned teacher supplies refusal and tone supervision, a preference pass sharpens “polite but not preachy”, and safety data stays inside the quantization loss so alignment survives compression. Two decisions are pivotal. First, safety is re-verified after quantization, because low-bit weights erode refusal behavior faster than they erode average benchmark quality. Second, a separate 100M-parameter guard screens the prompt and the streamed output, so a single jailbroken generation is caught by a component that can be patched over the air without retraining the base model.
(1) Distill + QAT + Adapters: prune and distill a large teacher into ~3B parameters, then quantization-aware train to 2-4 bits and ship 16-bit LoRA adapters per feature (summarize, reply, rewrite).
(2) Scratch-Trained Small Model + PTQ: train a 1-2B model on curated data and apply post-training 4-bit quantization; simplest pipeline, weakest quality per byte.
(3) Elastic Nested Model: a MatFormer-style checkpoint whose submodels can be extracted at different sizes, letting the runtime trade quality for RAM under memory pressure.
(4) On-Device Draft + Private Cloud Escalation: answer locally by default and escalate hard prompts to a privacy-hardened server tier with explicit consent.

Figure 1: Everything inside the dashed boundary runs on the handset: guard, decode loop, adapters, and cache. Nothing crosses the boundary, so every check has to happen before pixels appear.
Clarify Before Designing:
(1) Latency Definition: is 300 ms the time to first token or the full reply? Streaming a 60-token answer at 30 tokens per second takes two seconds no matter how good the prefill is.
(2) Task Set and Context: which features ship (reply suggestions, summarization, rewriting), and what is the maximum prompt length? Prefill cost and KV cache size follow directly from that number.
(3) Device Floor: which chip generation is the minimum, and what does its NPU actually execute natively (INT8, INT4, palettized weights, per-channel scales)?
(4) Escalation Policy: is any server path permitted with consent, or is strict offline operation a product promise we cannot break?
(5) Safety Bar: which refusal taxonomy applies, and what false-refusal rate on benign-but-edgy prompts is acceptable? Over-refusal is the failure users complain about.
(6) Telemetry Rules: may we collect differentially private aggregate counters and opt-in donated conversations, or literally nothing?
Login to view more content
August 21, 2026
MSD0018 Ads Policy Violation Detection
Design an end-to-end ML system to detect ads selling weapons and other policy-violating goods on a large ads platform like Meta or Google Ads. Millions of new ad creatives arrive daily as text, images, and video, and advertisers constantly adapt their creative to evade detection. Google’s Ads Safety Report describes blocking or removing billions of ads per year, so this is an industrial-scale enforcement problem, not a one-off classifier.
The system must block prohibited ads before they serve, route borderline cases to human reviewers, and keep the false-positive rate low enough that legitimate advertisers are not churned.
How would you design this system? Cover the multimodal detection model, the human-review queue prioritization, the adversarial adaptation problem, and how you measure recall and precision at platform scale.

The Problem: millions of new creatives arrive every day, roughly one in ten thousand is a prohibited-goods listing, and the decision must be made before the ad is shown even once.
Answer
The design is a pre-serve multimodal gate inside the ad-ingestion path. A cheap first stage kills known-bad creatives by hash and embedding near-duplicate lookup, then a shared vision-language encoder with per-policy heads scores every creative (ad copy, OCR text, landing-page text, image, video keyframes) before the first impression. Each policy class gets three calibrated bands: auto-block, human review, allow. Two decisions carry the design. First, thresholds are set from the asymmetric cost of a served weapon ad versus a wrongly blocked advertiser, per policy and per locale, rather than from a single global score cut. Second, the whole system is treated as an adversarial loop where the time from a new evasion pattern to a deployed block (hours, not quarters) matters more than static offline AUC.
(1) Staged Funnel: creative-hash cache and embedding kNN against known violations resolve most repeat traffic in milliseconds; only novel creatives pay for the full multimodal pass.
(2) Multimodal Model: a frozen vision tower plus a multilingual text tower over copy, OCR, ASR, and landing-page text, fused into multi-label per-policy heads instead of one binary “violating” output.
(3) Three-Band Decision Policy: per-policy calibrated thresholds split traffic into auto-block, review, and allow, so precision on the auto-block band is protected by construction.
(4) Expected-Harm Review Ranking: the reviewer queue is sorted by violation probability times forecast impressions times policy severity, not by score alone, and clusters of near-duplicate creatives collapse into one decision.
(5) Adversarial Response Loop: evasion signals (re-upload similarity, account bursts, appeal patterns) feed hard-negative mining, an embedding blocklist hotfix within hours, and account-level enforcement that raises the attacker’s cost.
(6) Measurement by Sampling: recall is estimated from stratified random audits of allowed traffic, precision from reviewer audits of blocks and from appeal-overturn rates.

Figure 1: Ingest → asset extraction → encoders → per-policy scores → three-band decision, with reviewer labels and the near-duplicate index closing the loop back into the model.
Clarify Before Designing:
(1) Scale and Asset Mix: how many new creatives per day, how many assets each, and what share is video (video dominates compute cost)?
(2) Enforcement SLA: must an ad go live within minutes of upload, or is holding a creative for a deep asynchronous pass acceptable?
(3) Policy Taxonomy: how many prohibited-goods classes, which are legally mandated, and how much do they vary by jurisdiction?
(4) Cost Asymmetry: what is the tolerated false-block rate before advertiser churn becomes the bigger loss, and what is the appeal SLA?
(5) Review Capacity: how many reviewer hours per day, in which languages, and with what accuracy on gold sets?
(6) Label Availability: do we have historical enforcement decisions, appeal outcomes, and account-level history, or are we starting from policy text only?
Login to view more content
August 21, 2026

DL0203 LLM Bias Detection Mitigation

How do you detect and mitigate bias in LLM outputs, and what pipeline of classifier scoring, threshold calibration, and mitigation strategies can be applied?

Answer

Bias is not a single scalar you can read off a model, so detection begins by fixing a measurement protocol rather than by picking a classifier. The standard construction is a counterfactual prompt set in which only a demographic token changes, several sampled generations per prompt under fixed decoding parameters, and a scorer ensemble that turns each generation into numbers (toxicity, regard, sentiment, stereotype agreement, refusal). The quantity that matters is then a gap between groups with a confidence interval, not an absolute score, because every scorer has an offset that cancels when you subtract. Only after the gaps are measured does thresholding enter, and a single global threshold is almost always wrong because the guard classifier has its own group-dependent error rates. Mitigation is a ladder from cheap and reversible to expensive and durable: system-prompt constraints, decode-time filtering with rewrite, preference tuning on paired data, and finally changes to the pretraining or SFT mixture. The hardest part in production is that the detector and the model must be evaluated together, since a biased guard silently converts fairness work into unequal censorship.

(1) Counterfactual Prompt Design: generate matched pairs where only the group term varies, so any score difference is attributable to that token rather than to topic or length.
(2) Scorer Ensemble, Not One Classifier: a toxicity head, a regard/sentiment head, a rubric-driven LLM judge, and a refusal detector disagree in useful ways; a single classifier both misses stereotype-without-toxicity and over-flags reclaimed language.
(3) Gaps With Uncertainty: report $\Delta_{ab}$ with a bootstrap confidence interval per slice, because a 2-point gap on 40 prompts is noise and a 2-point gap on 4,000 prompts is a launch blocker.
(4) Threshold Calibration Per Slice: choose the operating point from a per-group FPR target on benign text, and record how far apart the group thresholds have to be; that distance is itself a bias metric of the guard.
(5) Mitigation Ladder: system prompt → decode-time filter and rewrite → counterfactual data augmentation and DPO → data-mixture change, in increasing cost, latency impact, and durability.
(6) Guard The Guard: toxicity classifiers show measured dialect bias, so evaluate the detector on group-labelled benign text before you trust any gate it powers.

Left-to-right pipeline: counterfactual prompt pairs feed the LLM under test with eight samples per prompt at fixed decoding, which fans out to three scorers (toxicity and regard classifier, stereotype LLM judge with rubric, refusal and sentiment detector), which feed per-group aggregation of gaps with bootstrap confidence intervals, then a threshold gate calibrated per group at five percent false-flag rate, which routes to allow, rewrite and re-sample, or refuse and log slice; a bottom loop sends aggregated gaps into an offline mitigation box covering counterfactual data augmentation, DPO on paired preferences, activation steering, and a tighter system prompt, which feeds back into the model

Figure 1: The measurement half of the pipeline is online and the mitigation half is offline. The gate on the right acts on a single generation, while the aggregation block is the only place where a bias claim can legitimately be made, because bias lives in a distributional gap and not in any individual score.

Two implementation details decide whether the numbers mean anything. First, decoding must be frozen across the counterfactual arms: temperature, top-p, seed policy, and sample count identical, otherwise you are measuring sampling variance. Second, refusals must be scored separately. A model that answers a question about one group and declines the matched question about another has a large refusal-rate gap while showing a near-zero toxicity gap, and a pipeline that only tracks toxicity will report the model as clean. On the mitigation side, the same discipline applies in reverse: any intervention must be re-measured on the identical prompt set plus a general-capability suite, because prompt-level and decode-time fixes routinely buy a lower gap at the price of higher refusal on benign requests, which is a regression that no bias dashboard shows.

Mathematical Formulation:
$s = f_{\phi}(x, y) \in [0, 1]$
$\Delta_{ab} = \mathbb{E}[s \mid g = a] - \mathbb{E}[s \mid g = b]$
$\mathrm{FPR}_g(\tau) = P(s > \tau \mid g, \mathrm{benign})$
$\tau_g = \min \{ \tau : \mathrm{FPR}_g(\tau) \leq \alpha \}$
$\mathrm{ECE} = \sum_{b=1}^{B} \frac{n_b}{N} |\bar{s}_b - \bar{y}_b|$

Where:

$s$ is the scorer output for prompt $x$ and generation $y$ , produced by a guard classifier or judge with parameters $\phi$ that are separate from the model under test.
$g$ is the group or slice label attached to the prompt (demographic term, dialect, language), and $a, b$ are the two arms of a counterfactual pair.
$\Delta_{ab}$ is the group gap, the primary detection statistic; it is reported with a bootstrap interval over prompts, not over samples, since samples within a prompt are correlated.
$\tau$ is the gate threshold and $\alpha$ the tolerated false-flag rate on benign text, so $\tau_g$ is the smallest threshold meeting that budget within group $g$ .
$b \in \{1, \ldots, B\}$ indexes confidence bins with $n_b$ items out of $N$ ; $\bar{s}_b$ is the mean score and $\bar{y}_b$ the empirical label rate, so ECE measures whether a score of 0.7 actually means 70% harmful.

Worked Calibration Example (5,000 benign sentences per group):
$\mathrm{FPR}_a(0.50) = 115 / 5000 = 0.023$
$\mathrm{FPR}_b(0.50) = 455 / 5000 = 0.091$
$\tau_a = 0.40$
$\tau_b = 0.58$

The same threshold of 0.50 therefore flags benign text from group $b$ roughly four times as often, and equalizing the false-flag rate at $\alpha = 0.05$ requires thresholds 0.18 apart. That spread is the diagnostic: it says the guard classifier, not the generator, is the largest bias source in the stack, and the correct response is usually to fix the classifier’s training data rather than to ship group-conditional thresholds.

Line chart of false-flag rate on benign text versus gate threshold for two groups, both decreasing curves with group B consistently above group A; a vertical dashed line at threshold 0.5 meets the curves at 2.3 percent and 9.1 percent, a horizontal line marks the 5 percent target, and two circular markers show the per-group thresholds 0.40 and 0.58 that achieve 5 percent each

Figure 2: A single operating point produces two different error rates. Reading the gate at fixed threshold hides the disparity, while reading it at fixed false-flag rate exposes it as a horizontal distance between the two curves, which is the quantity to drive toward zero when you retrain the guard.

Property	Prompt / system level	Decode-time filter and rewrite	Training-time (CDA, DPO)
Where it acts	Instruction and few-shot context, no weight change	Guard score on the sampled output, then re-sample or refuse	Weights, via augmented pairs or preference optimization
Cost to ship	Hours, revertible with a config push	One extra forward pass per output, plus rewrite latency on flags	Days of data work and a full eval cycle per iteration
Durability	Low, defeated by paraphrase and long context drift	Medium, bounded by the guard’s own recall and calibration	High, the behaviour itself moves rather than being masked
Dominant failure mode	Over-refusal on benign group-related questions	Inherits the classifier’s dialect bias, so filtering is unequal	Capability regression and reward hacking of the preference signal
What to measure after	Refusal-rate gap on benign prompts per slice	Per-group FPR at fixed threshold, plus added p95 latency	Counterfactual gap, general benchmarks, and win rate versus baseline

August 21, 2026

DL0202 RL Production Recommendation

What are the challenges of using Reinforcement Learning in a production recommendation system, such as the YouTube home feed or Spotify’s carousels?

Answer

The hard part is almost never the learning algorithm. A production recommender is an off-policy problem with a combinatorial action space, a corrupted reward signal, and a closed feedback loop, and each of those violates an assumption that textbook RL takes for granted. You cannot explore freely on paying users, so the only training data is what yesterday’s serving policy logged, which makes importance weighting and its variance the central engineering problem rather than a footnote. The action is not one item but a slate of K items drawn from a catalogue of order $10^{8}$ , so enumerating a Q value per action is impossible and the policy must be factorized or decomposed. Finally, the reward you actually want, long-term satisfaction, arrives days after the action, and is confounded by position bias, seasonality, and the recommendations themselves.

(1) Off-Policy By Construction: training data comes from a logging policy $\beta$ , not from the policy you are optimizing, so every gradient needs an importance correction whose variance grows with the mismatch.
(2) Combinatorial Slate Actions: a page of $K$ items from $N$ candidates gives $\binom{N}{K}$ actions, forcing decompositions such as top-K correction or SlateQ‘s per-item value factorization.
(3) Reward Specification And Delay: clicks are immediate and gameable, retention is the real objective and is observed days later, so credit assignment spans sessions rather than steps.
(4) Feedback Loops And Non-Stationarity: the deployed policy shapes tomorrow’s training distribution, so a small early bias compounds instead of averaging out, and the catalogue and user base drift underneath the model.
(5) Offline Evaluation Is Unreliable: off-policy estimators are high variance on large action spaces, so offline value gains routinely fail to reproduce in an A/B test.
(6) Infrastructure Cost: you must log propensities at serving time, keep the randomization budget small, and still return a ranked page inside a tens-of-milliseconds latency budget.

Closed-loop diagram with four boxes in a row: serving policy pi-theta with retrieval and ranker over a 10^8 item catalogue, slate of K items shown to the user where position bias enters, logged feedback carrying the action, the propensity beta and a delayed reward, and off-policy training with IPS weights, clipping and top-K correction, with a return arrow deploying new policy weights back to serving

Figure 1: The loop is the problem. Supervised ranking treats the log as a fixed dataset, but here the policy under training generates its own future training distribution, so bias compounds across deployments and the reward attached to each logged action is both delayed and confounded by presentation.

The standard production recipe, popularized by YouTube’s top-K REINFORCE recommender, is to keep policy-gradient learning but reweight each logged trajectory by the ratio between the new policy and the logging policy. Two corrections then appear. The first is weight clipping, which caps the influence of any single log line and trades unbounded variance for a controlled downward bias. The second is the top-K correction factor, which accounts for the fact that the system shows $K$ slots rather than sampling one item, and which flattens the gradient on items the policy already places with near certainty. Both are variance-control devices, and understanding why they are needed is the difference between a candidate who has read the paper and one who has shipped the system.

Mathematical Formulation:
$J(\theta) = \mathbb{E}_{\tau \sim \pi_{\theta}}\left[\sum_{t=0}^{T} \gamma^{t} r_{t}\right]$
$w_t = \dfrac{\pi_{\theta}(a_t \mid s_t)}{\beta(a_t \mid s_t)}$
$\tilde{w}_t = \min(w_t, c)$
$\lambda_K(s_t, a_t) = K\left(1 - \pi_{\theta}(a_t \mid s_t)\right)^{K-1}$
$\hat{g} = \sum_{t} \tilde{w}_t\, \lambda_K\, R_t\, \nabla_{\theta} \log \pi_{\theta}(a_t \mid s_t)$
$\mathrm{ESS} = \dfrac{\left(\sum_i w_i\right)^{2}}{\sum_i w_i^{2}}$

Where:

$J(\theta)$ is the expected discounted return of the target policy over a user trajectory $\tau$ , with discount $\gamma \in (0,1]$ and per-step reward $r_t$ .
$s_t$ is the user state (interaction history and context), $a_t$ the item actually shown and logged, and $R_t$ the return following that action.
$\pi_{\theta}$ is the target policy and $\beta$ the logging (behavior) policy; $w_t$ is their ratio, and it is undefined wherever $\beta(a \mid s) = 0$ .
$c$ is the clipping threshold; $\tilde{w}_t$ is the truncated weight, which is biased but bounded.
$\lambda_K$ is the top-K correction for showing $K$ slots instead of one; it tends to $K$ for rare items and to $0$ as $\pi_{\theta}(a \mid s)$ approaches $1$ .
$\mathrm{ESS}$ is the effective sample size over $i \in \{1,\ldots,N\}$ logged records, and it is the number that decides whether a 10M-row log is really 10M rows.

Log-scale line chart of effective sample size fraction versus policy mismatch sigma, showing an unclipped importance-sampling curve collapsing from near one to about one thousandth as sigma grows to three, a curve clipped at one hundred decaying more slowly, and a curve clipped at ten still retaining several percent, with an annotation marking that at sigma equal to two the unclipped estimator retains about two percent of the logged rows

Figure 2: Why off-policy learning is a variance problem before it is an optimization problem. As the target policy drifts from the logging policy, the effective sample size of the log collapses exponentially, so a huge log can carry the statistical weight of a small one. Clipping restores usable sample size at the price of a systematic downward bias on exactly the actions the new policy likes most.

This is also why the choice between supervised ranking, a contextual bandit, and full sequential RL is a real design decision rather than a question of ambition. A bandit captures most of the exploration benefit with a single-step correction and no long-horizon credit assignment, and it is what Spotify’s explainable-recommendation work uses for carousel and explanation selection. Full RL earns its cost only when an action genuinely changes the future state, for example when promoting a new creator today changes what the user is willing to watch next month.

Property	Supervised ranker	Contextual bandit	Full sequential RL
Objective	Predict the immediate label, click or watch probability	Maximize immediate reward under uncertainty	Maximize discounted return across future sessions
Data required	Logged impressions and labels only	Logged action plus its propensity	Full trajectories with propensities and delayed rewards
Correction needed	None in principle, though position bias still needs debiasing	Single-step IPS or doubly robust	Per-step IPS, clipping, top-K factor, bootstrapped value targets
Exploration cost	None, and therefore no counterfactual coverage	Small randomized slot, epsilon-greedy or Thompson sampling	Randomization plus pessimism penalties for out-of-support actions
Dominant failure	Myopic optimization that rewards clickbait	No credit for downstream session value	Variance explosion offline and feedback-loop drift online

August 21, 2026

DL0201 Pretraining Loss Spike Debugging

During pretraining of a 100B parameter model on a large GPU cluster, you suddenly see loss spikes. How do you debug this, and is it a data issue, a learning-rate problem, or hardware failure?

Answer

All three causes are real at this scale, and they leave different fingerprints, so the answer is a triage order rather than a guess. Run the checks in order of cost: first the numerics and per-rank logs you already have on disk (NaN or Inf, one data-parallel rank far from the mean loss, XID or ECC events, NCCL timeouts), then the optimizer traces (global gradient norm, Adam update ratio, maximum attention logit, output logit magnitude), and only then the data, which is proven guilty only by replaying the exact batch from the pre-spike checkpoint. The shape of the curve already narrows the space: a single sharp spike that recovers within a few thousand steps is usually a batch-times-model-state interaction, a slow creeping divergence preceded by growing logits is a learning-rate or numerics problem, and an instant jump to NaN with a stalled step time is hardware. The industry-standard mitigation for the first case is the one PaLM reported: rewind to a checkpoint roughly 100 to 200 steps before the spike and skip a few hundred batches, which removes the spike even though the same data is harmless from a different model state. That asymmetry is the single most important fact in this debugging problem, because it means “the data was bad” is almost never the correct conclusion on its own.

(1) Read The Shape First: recoverable spike, creeping divergence, and hard fault are three distinct signatures, and each maps to a different subsystem.
(2) Cheapest Check First: numerics and per-rank divergence cost nothing to inspect, optimizer traces cost one dashboard query, and a batch replay costs about one node-hour.
(3) Never Trust The Global Loss: with 512 data-parallel ranks a single sick rank moves the average by a fraction of a percent, so log per-rank loss and gradient-norm maxima, not just the mean.
(4) Silent Data Corruption Has No NaN: a degrading GPU can return wrong arithmetic with no error flag, so keep a bitwise-reproducibility canary that reruns one batch on two hosts and compares.
(5) Data Is Guilty Only On Replay: rerun batch $b_s$ from the checkpoint at step $s-1$ on a fresh replica; if the spike does not reproduce, the batch is not the cause.
(6) Skip-And-Resume Versus Config Change: rollback is right for isolated spikes, but recurring spikes plus growing attention logits mean you must pay for QK-norm, z-loss, a lower peak learning rate, or fp32 optimizer state.

Two-row by three-column chart grid. Top row shows training loss versus step for three cases: a single sharp spike at step 9000 that recovers to trend, a creeping divergence starting near step 11500 that never returns, and a curve that ends abruptly at step 15000 with a NaN marker. Bottom row shows the corresponding global gradient norm on a log scale with a clipping threshold line at 1.0: a single narrow 15x spike, a gradient norm that creeps up for two thousand steps before the loss moves, and a flat trace that terminates in an infinite value.

Figure 1: The same symptom, three diseases. Case A is a recoverable spike whose gradient norm spikes for a handful of steps and then returns, case B is a creeping divergence in which the gradient norm rises for roughly 2,000 steps before the loss visibly moves, and case C is a hard fault with no precursor at all. Note that gradient clipping at 1.0 caps the applied update but does not hide the raw norm, which is exactly why the raw norm must be logged.

The mechanism behind case B is worth being precise about, because it is the one people misdiagnose as bad data. As training proceeds, attention logits $q_i^\top k_j / \sqrt{d_h}$ can grow without bound; the softmax saturates, one head collapses onto a single position, and the gradient through that head becomes both tiny and extremely sharp. In parallel, the output logits drift so that $\log Z$ wanders, which makes the cross-entropy surface stiff in a direction the optimizer cannot see from the loss value alone. Case A has a different mechanism: in bf16 or when optimizer state is stored in low precision, the Adam second moment for a rarely-activated parameter block (embeddings for rare tokens are the classic example) can decay toward the epsilon floor, after which one moderate gradient produces an update whose effective step size is orders of magnitude larger than intended. The debugging pipeline is therefore always the same: detect → localize → replay → mitigate, with instrumentation decided before the run rather than after the first spike.

Mathematical Formulation:
$\ell_t > \mu_{t-W:t} + 3\,\sigma_{t-W:t}$
$\theta_{t+1} = \theta_t - \eta_t \dfrac{\hat m_t}{\sqrt{\hat v_t} + \epsilon}$
$r_t = \dfrac{|\hat m_t|}{\sqrt{\hat v_t} + \epsilon}$
$r_{\max} \approx \dfrac{1-\beta_1}{\sqrt{1-\beta_2}}$
$s_{ij} = q_i^\top k_j / \sqrt{d_h}$
$\mathcal{L} = \mathcal{L}_{\mathrm{CE}} + \alpha (\log Z)^2$

Where:

$\ell_t$ is the training loss at step $t$ , and $\mu$ and $\sigma$ are the mean and standard deviation over a trailing window of $W$ steps (a few hundred works well); this is the spike detector that should fire an alert, not a human eye on a dashboard.
$\theta_t$ are the parameters, $\eta_t$ the scheduled learning rate, and $\hat m_t$ and $\hat v_t$ the bias-corrected first and second Adam moments with decays $\beta_1$ and $\beta_2$ .
$r_t$ is the update ratio, the per-block quantity to log alongside the gradient norm, because it exposes the actual step size the optimizer is taking rather than the size of the gradient.
$r_{\max}$ is the ratio a single outlier gradient can produce, roughly $0.1/\sqrt{0.05} \approx 0.45$ for $\beta_1 = 0.9$ and $\beta_2 = 0.95$ ; this bound holds only while $\sqrt{\hat v_t}$ dominates $\epsilon$ , and it is epsilon underflow that breaks it.
$s_{ij}$ is the pre-softmax attention logit for query $i$ and key $j$ with head dimension $d_h$ ; tracking $\max_{ij} |s_{ij}|$ per layer is the earliest available warning of the creeping-divergence mode.
$Z = \sum_{v=1}^{V} \exp(z_v)$ is the softmax partition function over vocabulary size $V$ , and $\alpha$ is the z-loss coefficient (commonly $10^{-4}$ ) that pins $\log Z$ near zero at negligible quality cost.

The $r_{\max} \approx 0.45$ bound is the reason “one weird document blew up the run” is usually wrong: with healthy second moments, Adam already damps a single 30x outlier gradient to less than a normal step. What actually hurts is a sequence of correlated large gradients, or a block whose $\hat v_t$ has collapsed so that the denominator is dominated by $\epsilon$ . That distinction determines the fix: correlated gradients are a data-ordering and learning-rate problem, while a collapsed second moment is a precision problem solved by keeping optimizer state in fp32 and raising $\epsilon$ .

Left-to-right triage diagram. A trigger box for a detected loss spike fans out to three ordered check boxes: numerics and per-rank divergence, optimizer signals such as gradient norm and maximum attention logit, and a replay of the offending batch from the previous checkpoint. Each check has a yes branch to an evidence box listing concrete symptoms, and each evidence box points to a verdict box: hardware, learning rate and numerics, or data crossed with model state. Vertical clean arrows connect check one to check two and check two to check three.

Figure 2: The triage order that makes this question answerable in an interview. The three branches are ordered by cost per bit of information, not by likelihood, and the replay step is what separates a genuinely corrupt shard from a batch-times-state interaction that a 400-batch skip will silently fix.

Signal	Data and model state	Learning rate and numerics	Hardware and interconnect
Loss shape	Sharp isolated spike, recovers to trend within a few thousand steps	Repeated spikes of growing size, or a divergence that never recovers	Instant NaN or Inf, or a flat line while step time stalls
Gradient norm	One narrow burst of a few steps, clipping engages briefly	Slow upward drift over thousands of steps, clipping engages permanently	Jumps straight to Inf, or becomes exactly zero on one rank
Per-rank pattern	Elevated on the ranks holding the offending microbatches only	Uniform across all ranks, since the cause is the shared update	One rank or one host is an extreme outlier, or a canary mismatches bitwise
Replay test	Reproduces from the same checkpoint, disappears from a different one	Reproduces from any nearby checkpoint with the same schedule	Does not reproduce on a healthy node with identical inputs
Corroborating logs	Sample dump shows repeated n-grams, a truncated shard, or non-text bytes	Max attention logit and update ratio rising, parameter norm inflating	XID or ECC entries, NCCL timeouts, thermal throttling, link flaps
First mitigation	Rewind about 200 steps, skip 200 to 500 batches, then dedup or drop the shard	Lower peak LR, extend warmup, add QK-norm and z-loss, keep fp32 optimizer state	Fence the host, restore the last checkpoint, rerun on a spare node

The operational context matters for how much of this you should automate. Meta reported 419 unexpected interruptions during Llama 3 405B pretraining, with roughly 78% traced to hardware, which means at 100B scale a fault-driven anomaly is not an exotic event but a weekly one. That argues for treating spike response as a control loop: an automatic detector on the trailing-window rule, automatic checkpoint retention dense enough to rewind 200 steps, automatic host fencing on XID events, and a human decision only for the residual class where the numerics themselves are unstable.

August 21, 2026