Walk through an online sampled eval setup for safety in production

**Online sampled eval** is how you keep watching safety after the model is in production without paying to grade every single request. The shape: production traffic flows normally. A small fraction of traces (typically 1 to 5%) are copied to a side queue. A separate worker pulls from that queue and runs an LLM-as-judge that scores each trace against your safety policy. The judge writes the score back into the trace as a span attribute. The user never waits for this; it is fully asynchronous. Over time, you compute a rolling baseline,say the mean score and refusal rate over the last 7 days. Alerts fire when today's mean drifts past threshold or when refusals spike. Cost stays bounded because only the sample is judged. The user-facing latency is unaffected because scoring is async. To make the sample smarter, stratify it. Over-represent traces from high-risk routes (refund, deletion, financial advice) so drift on dangerous flows is caught sooner than uniform sampling would catch it. The lift in coverage on dangerous routes is the cheapest reliability gain you will ever buy.

**Online sampled eval** copies a small fraction of production traces to a side channel where an asynchronous LLM-as-judge scores them against a safety rubric and writes the score back as a span attribute. The user-facing path is untouched: no extra latency, no doubled spend on the hot path. **The four moving parts:** 1. A sampler in your trace pipeline that selects 1-5% of traces, with stratification weights that boost high-risk routes (refunds, deletions, financial, medical). 2. A judge worker pool that pulls from the sample queue, runs a fixed-prompt LLM-as-judge against each trace, and returns a score plus categorical labels (refused, safe, borderline, unsafe). 3. A metrics store that aggregates scores over rolling windows (typically 1h, 24h, 7d) and computes mean, p95, refusal rate, and per-category counts. 4. An alerter that fires when the rolling mean drifts past threshold or a per-category count spikes. **Why stratify.** If 99% of your traffic is benign FAQ lookups, uniform sampling rarely sees the dangerous routes; drift on a financial-advice route would take weeks to surface. Stratifying by route lets you set a higher sample rate (say 20%) on those specific paths. **Why async.** Inline LLM-as-judge doubles per-request cost and adds 1-3 seconds of tail latency. The whole point of the sampled design is that the judging happens off the critical path. **What you alert on:** rolling refusal-rate spikes (sudden jump = jailbreak campaign), score-mean drops (model regression after a deploy), and per-category increases (PII leak, toxicity surfacing on a new route).