AI Engineering Interview Questions: LLM Evaluation & Safety

Evaluation starts by defining what good means (criteria/metrics), then assembling a representative dataset of inputs with expected outcomes. You score candidate variants against it, compare and select the winner, and finally monitor in production, routing real-world failures back into the dataset so the eval set hardens over time. Skipping the dataset step is the classic mistake — you can't iterate on quality you don't measure.

A golden set is a versioned, labeled dataset of representative inputs with known-good expectations; running both prompt versions against it and comparing scores catches regressions before they ship and localizes which cases changed (c). Watching the live thumbs-down rate (a) is post-hoc, slow, and noisy — it only tells you something broke after real users hit it, and can't isolate the regressed cases. Eyeballing a handful (b) doesn't cover the long tail you were already passing. Temperature (d) is unrelated to whether the new prompt is actually better.

An A/B test measures online outcome metrics (engagement, task success, thumbs-up) on live traffic — valuable, but slow, noisy, confounded by traffic mix, and only observable after you have already exposed real users to the change. It gives you no labeled ground truth on known-hard cases, can't catch a regression before it ships, and can't tell you which inputs broke. An offline golden set — versioned, labeled, and run in CI on every change — is the pre-ship regression gate. A/B testing complements it (does the improvement hold up with real users?); it does not replace it.

Treat prompts like code: a versioned eval dataset with deterministic checks plus an LLM judge for subjective dimensions, run on every change so you catch regressions instead of guessing. LLM judges are useful but biased — they reward verbosity, drift between runs, and can prefer their own family's outputs — so anchor the judge to human-labeled examples, use a strict rubric, and keep its temperature low. Eyeballing a handful of outputs is not evaluation.

LLM-as-judge unlocks scalable evaluation of subjective/open-ended outputs, but it's a measurement instrument that must itself be validated against human labels and de-biased — otherwise you optimize toward the judge's quirks rather than real quality.

For open-ended generation, LLM-as-judge over a fixed, versioned eval set scales and correlates reasonably with human judgment when you give the judge a clear rubric and, ideally, a reference answer. The essential caveat is that the judge is itself a fallible model — it shows known biases (position bias, verbosity/length bias, self-preference) — so you must validate it against a sample of human labels and re-check when you change the judge model. Exact match (a) fails by design for free-form text where many wordings are equally correct. BLEU against a single reference (c) was built for machine translation and penalizes valid paraphrases; its weakness is poor correlation with quality on summaries, not speed. Reading every output manually (d) does not scale to weekly iteration; spot-checking belongs alongside an automated eval, not as the primary gate.

LLM-as-judge evaluation is powerful but carries known biases that distort scores in a predictable direction when the judge and the system under test are the same or closely related models. Self-preferencing bias: the model tends to rate outputs stylistically similar to what it would generate more favourably. Verbosity bias: longer answers are scored higher regardless of accuracy. Position bias: in pairwise comparisons, the first presented answer gets a boost. Mitigation strategies include using a different, stronger judge model, presenting pairwise comparisons in both orders and averaging, adding calibration examples to the judge prompt, and triangulating with at least one human or deterministic metric. A single-judge self-evaluation score should never be the sole quality gate.

Context precision = relevance/signal of the retrieved passages (relevant ones ranked high); context recall = coverage (did retrieval fetch everything needed, usually checked against a reference answer). Faithfulness (a.k.a. groundedness) = the share of the answer's claims entailed by the retrieved context — the anti-hallucination signal. The fourth common metric, answer relevance, checks that the answer actually addresses the question. Splitting retrieval metrics from generation metrics is what lets you attribute a failure to the right stage.

Line 4 returns the cheap tier's text the instant the call succeeds, with no check on whether the answer is actually any good. The catch block only fires on a thrown exception — a timeout, a 5xx, a malformed-request error — never on a response that came back fine but is low-confidence, off-topic, or simply wrong. Cascades work specifically because escalation is driven by a quality/confidence signal on the cheap tier's real output — a verifier score, a self-consistency check, a validator against the expected shape, or the model's own confidence — not by whether an exception was thrown (this is the core idea behind cascade-based serving approaches like FrugalGPT). As written, this code silently serves bad answers from the cheap tier on exactly the hard requests it was supposed to catch and escalate, while only ever escalating for unrelated infrastructure failures. The fix is to score cheap.text against a threshold after line 4 and route to the strong tier when it doesn't clear it.

Agent loops are testable to the exact degree that the loop is separable from the two things that make it non-deterministic and slow. Injecting tools (a) and the model client (b) is what lets a test drive the loop through a scripted run — including the paths that matter most and are hardest to trigger live: a tool 500, a malformed argument, an unterminated run hitting the step cap. Asserting on the call sequence (c) rather than the prose gives you a stable oracle, because "which tools, with what arguments, in what order" is the loop's actual behaviour; the wording of the final answer is not. Keeping control logic network-free (d) means the step cap and stop condition are ordinary functions with ordinary unit tests. Option (e) is the trap: temperature 0 reduces variance but does not guarantee identical output — batching and floating-point non-determinism on the provider's side still shift results, models are updated underneath you, and the test now needs network access and a budget on every pull request. Reproducible-looking beats reproducible right up until it flakes in someone else's branch.