Question presented to candidate: "Our RAG support assistant scored well at launch and nobody has touched the prompt since, but support leads say answers feel worse this month. How would you set up monitoring so that a slow decline in quality is detected by us, with evidence, before customers tell us β and how would you work out what caused it?"
What a strong answer should cover:
- Quality can change with zero deploys, and why: input drift (the question mix changes), upstream data drift (documents in the index go stale or change format), provider-side change (alias moves, serving or infrastructure bugs), and slow accumulation of small config changes
- Two kinds of signal: direct quality measured on a daily sample of live traffic (LLM judge or human labels, with a calibrated judge) and cheap proxies on all traffic (thumbs-down, rephrase and retry rate, escalations, refusals, guardrail triggers, output length, parse failures)
- Statistics that fit: a rolling baseline instead of fixed thresholds, the noise of a daily sample (about plus or minus 4 points at 200 samples and 91%), a change detector such as CUSUM or EWMA for small sustained drops, and a distribution distance such as PSI for the input mix
- Slicing by topic, customer, language and model version, because drift is usually concentrated in one slice and the slice points to the cause
- The response loop: confirm with a full eval run, separate input drift from a real regression, fix (data, prompt, routing, model pin) and add the new failure pattern to the golden set
Clarifying questions expected:
- How much traffic per day, and how much judging budget, so we know how many conversations we can score?
- Is the model pinned to a dated snapshot, and do we get notice of provider changes?
- Which outcome matters most β correct answers, resolved tickets, or safety β so the primary metric is clear?
Code / implementation expected: Optional β a monitor that compares daily metrics with a baseline (CUSUM, EWMA or PSI), or a sampling and judging pipeline sketch.