LLM Evaluation Best Practices Interview Prep

Inspect AI vs Braintrust vs DeepEval vs LangSmith — Eval Framework Trade-offs

Sample interview questions

1. What are the four components of a production LLM eval harness?
   • A. Prompt, model, temperature, and output format.
   • B. Dataset, Runner, Scorer, and Reporter — each responsible for a distinct phase of the evaluation pipeline. ✓
   • C. Golden set, regression set, adversarial set, and human-labeled set.
   • D. Accuracy, latency, cost, and safety metrics.

   Option B is correct. A production eval harness has four functional components: (1) Dataset — the collection of test cases, organized into golden (expected-output), regression (past failures), and adversarial (edge cases) subsets; (2) Runner — the component that takes each test case, calls the model or agent under test with the specified inputs, and collects the outputs, ideally in parallel async batches; (3) Scorer — the component that grades each output against the expected result, using programmatic checks (exact match, regex, structured parsing) for objective criteria and LLM-as-judge for subjective or rubric-based criteria; (4) Reporter — the component that aggregates scores, generates trend visualizations, gates CI deployments when scores fall below thresholds, and surfaces new failure cases for dataset growth. Option A is wrong. Prompt, model, temperature, and output format are configuration parameters for a single inference call, not components of an eval harness. An eval harness orchestrates many such calls systematically. Option C is wrong. Golden set, regression set, and adversarial set are dataset subsets that live inside the Dataset component of the harness. They are not the four harness components themselves. Option D is wrong. Accuracy, latency, cost, and safety are metrics that the Scorer and Reporter produce, not the structural components of the harness itself. Production reality: "eval-as-code" means the harness is version-controlled and runs in CI on every model, prompt, or config change — not run manually before release. Inspect AI (from UK AI Security Institute), Braintrust, DeepEval, and LangSmith all implement this four-component structure.

2. What is the key difference between a golden set and a regression set in an eval harness?
   • A. A golden set uses LLM-as-judge; a regression set uses exact-match scoring.
   • B. A golden set contains carefully curated examples covering core capabilities with known-correct outputs; a regression set contains examples that previously failed and have since been fixed, ensuring the same failures do not recur. ✓
   • C. A golden set is manually labeled; a regression set is automatically generated by the model.
   • D. A golden set is used before deployment; a regression set is used after deployment.

   Option B is correct. The functional distinction is what each set is optimized for: the golden set establishes a coverage-oriented sample of the model's intended capabilities — ideally spanning difficulty levels and representative input distributions — and serves as the primary measure of overall capability. The regression set is failure-oriented: it accumulates examples that previously caused failures and have since been corrected. The regression set's primary job is ensuring no previously-fixed bug recurs. A production harness grows both sets over time: the golden set grows as new capability dimensions are identified, the regression set grows as each production incident adds its failing example. Option A is wrong. Both sets can use either scoring method. The choice of LLM-judge vs exact-match is a function of how objective the grading criterion is, not which dataset the example belongs to. Option C is wrong. Both sets are curated (not automatically generated) to maintain quality. The regression set in particular requires a human to verify that the "correct" label is accurate before adding the example, otherwise the set trains the scorer to accept wrong outputs. Option D is wrong. Both sets are used before deployment (in CI) and can also be used for online eval after deployment. The timing of use is not the differentiating factor. Production reality: the regression set is the most operationally valuable dataset in a production eval suite. Its growth rate is a direct measure of how many production incidents the team experiences and learns from. A team with a large regression set has high incident-learning fidelity.

3. When should you use an LLM-as-judge scorer versus a programmatic check in your eval harness?
   • A. Always use LLM-as-judge because it is more flexible than programmatic checks.
   • B. Use programmatic checks for objective, verifiable criteria (JSON validity, code execution, exact string match); use LLM-as-judge for subjective or rubric-based criteria (tone, helpfulness, safety) where no deterministic check exists. ✓
   • C. Use LLM-as-judge only for safety evaluations; use programmatic checks for everything else.
   • D. Use LLM-as-judge when your model is large (70B+); use programmatic checks for smaller models.

   Option B is correct. The decision criterion is whether a deterministic oracle exists. For objective criteria — does the output parse as valid JSON? does the generated code execute without error? does the response contain the required named entity? — a programmatic check is faster, cheaper, and deterministic — though it only verifies what it explicitly tests, so an incomplete check can still pass a semantically wrong output (valid JSON that is factually incorrect). These checks run in milliseconds and cost nothing beyond compute. For subjective criteria — is the tone appropriate for the brand? does the explanation demonstrate genuine understanding? is the output safe for the target audience? — no deterministic check exists, and an LLM-judge with a carefully designed rubric is the best available approximation. Option A is wrong. LLM-as-judge is slower, more expensive, and introduces variance (the judge can disagree with itself on identical inputs). Using it for criteria that have deterministic checks is wasteful. Option C is wrong. Limiting LLM-as-judge to safety evaluations is too narrow. Helpfulness, coherence, factual grounding, and many other criteria that cannot be checked programmatically also benefit from LLM-judge scoring. Option D is wrong. Model size does not determine the appropriate scoring method. The size of the model being evaluated is irrelevant; the criterion being scored determines the method. Production reality: a well-designed eval harness uses both: programmatic checks as fast first-pass filters (failing examples skip the LLM-judge to save cost) and LLM-judge scoring for the examples that pass the programmatic gates. Calibrate your LLM judge against human grades to detect sycophancy bias.

4. Your team is choosing between Inspect AI, DeepEval, and Braintrust for a new eval harness. What is the most important criterion for making this choice?
   • A. Choose the framework with the most GitHub stars.
   • B. Evaluate each framework against your specific eval requirements: Inspect AI for rigorous task-based agent evals with OSS licensing needs, DeepEval for RAG and application eval with pytest integration, Braintrust for teams that need a managed cloud dashboard with dataset versioning. ✓
   • C. Choose Braintrust because it is the only framework that supports LLM-as-judge.
   • D. Choose DeepEval because it supports the most model providers.

   Option B is correct. The three frameworks have genuine differentiation: Inspect AI (from UK AI Security Institute) is a Python-first framework with strong task-based agent evaluation, fully open-source (MIT), and designed for research-grade rigor — appropriate for teams with data-sovereignty requirements or government/enterprise constraints on cloud data. DeepEval has the deepest out-of-the-box support for RAG evaluation metrics (faithfulness, contextual precision, contextual recall) and integrates cleanly with pytest, making it easy to add eval to existing Python test suites. Braintrust is a managed cloud service with strong dataset versioning, team collaboration features, and a polished dashboard — appropriate for product teams that want observability without building infrastructure. Option A is wrong. GitHub stars measure adoption, not fit for your specific requirements. A popular framework that lacks RAG eval or CI integration will be a poor fit for a team with those needs. Option C is wrong. All three frameworks support LLM-as-judge scoring. The claim that Braintrust is the only one is false. Option D is wrong. Model provider support is available in all three frameworks via their API integration layers. No framework has a uniquely broader set of supported providers. Production reality: the right choice also depends on your team's maturity. If you are starting from scratch, DeepEval's pytest integration and eval-as-code pattern is the lowest barrier to entry. If you need a managed collaboration layer, Braintrust. If you are in a regulated environment, Inspect AI.

5. How do you run eval in CI without making every pull request slow to the point where developers ignore the gate?
   • A. Run the full eval suite on every PR — slow CI is acceptable if it maintains quality.
   • B. Use a tiered eval strategy: run a small fast-pass golden subset (50-200 examples) on every PR commit, run the full suite nightly or on merge to main, and run adversarial evals on release branches only. ✓
   • C. Remove eval from CI entirely and run it manually before each release.
   • D. Run eval in parallel to CI so it does not block the PR merge, but still report results in the PR.

   Option B is correct. The production-standard approach is tiered evaluation: a small, fast-pass subset that runs on every PR commit and provides signal within 2-5 minutes (catching obvious regressions quickly), a full suite that runs nightly or on merge to main (amortizing the cost of running 1,000+ examples), and an adversarial eval that runs on release branches where the cost of a longer pipeline is justified. The tiering ensures that developers get meaningful feedback on every commit without enduring a 30-minute wait, while the full suite provides complete coverage on a longer cadence. Option A is wrong. If the CI gate is slow enough that developers skip it, disable it, or learn to ignore it, you have lost the primary benefit of eval-in-CI. A gate that developers route around is worse than no gate, because it creates false confidence. Option C is wrong. Manual eval before release is the pre-CI pattern that fails under time pressure. "Just a small change" releases consistently skip manual evals, and those are the releases that cause regressions. Option D is wrong. Non-blocking parallel eval provides reporting but does not enforce the gate. If the eval fails but the PR merges anyway because the failure is non-blocking, you have reporting without enforcement — which is insufficient for maintaining model quality. Production reality: Inspect AI, Braintrust, and DeepEval all support tiered subsets and CI integration. Configure the fast-pass subset to cover your highest-priority capabilities and known regression patterns.

6. Your eval suite passes with 87% success rate. Users complain the model is giving evasive answers and refusing valid requests. What eval discipline failure caused this?
   • A. The model needs to be fine-tuned on user-reported examples to fix the refusal behavior.
   • B. The golden set does not cover the failing request types, the adversarial set lacks valid-but-edge-case inputs, and there is no helpfulness metric in the scorer — the eval measures accuracy on curated cases but misses the refusal/evasion dimension entirely. ✓
   • C. The 87% success rate is too low — the team should accept only 95%+ before shipping.
   • D. The LLM-judge in the scorer is biased toward refusing requests, causing the scorer to grade evasive answers as correct.

   Option B is correct. An 87% pass rate with user-reported evasion reveals a dataset coverage failure: the golden set covers task types that the model handles correctly, but the specific request types that trigger refusal are not represented. The adversarial set is missing "valid but edge-case" inputs — queries that are legitimate but push against the model's safety thresholds in ways that produce over-refusal. The scorer lacks a helpfulness or appropriateness dimension that would penalize evasive answers. The result is a harness that measures what the model does well and ignores what users experience as failure. Option A is wrong. Fine-tuning is one remediation, but it should not precede diagnosis. Before fine-tuning, you need to understand the distribution of failing request types, add them to the eval set, and verify that fine-tuning actually reduces the failure rate on that set. Option C is wrong. 87% may be appropriate or not depending on the capability being measured. The number alone does not diagnose the problem. A 99% success rate on the wrong eval set is worse than 87% on the right one. Option D is wrong. LLM-judge sycophancy is a real bias (judges tend to favor verbose, confident responses), but sycophancy does not cause judges to grade evasive answers as correct — evasive answers score low on helpfulness rubrics regardless of verbosity. Production reality: this failure pattern is extremely common. Teams build eval suites around the use cases they initially support, then ship a model change that degrades edge cases not in the eval set. The fix is continuous dataset expansion: every user complaint that represents a novel failure type should be added to the adversarial set.

7. How do you detect LLM-judge sycophancy in your eval suite, and what is the most reliable mitigation?
   • A. Sycophancy cannot be detected — use human evaluation instead of LLM judges.
   • B. Detect sycophancy by running the judge on known-incorrect outputs and measuring false-positive rate. Mitigate by calibrating judge prompts against human-graded examples and using position-swap and order-shuffle tests. ✓
   • C. Sycophancy only affects chain-of-thought prompts; use direct-answer prompts for the judge.
   • D. Detect sycophancy by counting how many outputs the judge grades as "correct" — high rates indicate sycophancy.

   Option B is correct. LLM-judge sycophancy — where the judge gives inflated scores to verbose, confident, or well-formatted outputs regardless of their accuracy — can be detected through specific calibration tests: (1) generate known-incorrect outputs (factually wrong, logically flawed) and check whether the judge correctly grades them as wrong; a sycophantic judge will give them partial credit or pass them; (2) use position-swap tests where the same two outputs are swapped between "output A" and "output B" in a pairwise comparison and check whether the judge's preference flips (a reliable judge's preference should not change based on position); (3) use order-shuffle tests with the same outputs in different orderings. Mitigation requires calibrating the judge's rubric against a set of human-graded examples, adjusting the rubric language where the judge diverges from human grades, and using disaggregated metrics instead of a single holistic score. Option A is wrong. LLM judges can be calibrated to reduce sycophancy. Human evaluation is more reliable but often orders of magnitude more expensive and slower — the right approach is to calibrate LLM judges against human grades, not abandon LLM judging entirely. Option C is wrong. Sycophancy affects all judge prompt formats, not just chain-of-thought. It is a property of the judge model's training distribution, not the prompt format. Option D is wrong. A high "correct" rate from the judge might indicate a genuinely high-quality model rather than sycophancy. The rate alone is insufficient for diagnosis; you need the calibration tests described above. Production reality: Braintrust and Inspect AI both have tooling for judge calibration. Run calibration quarterly at minimum, and after any model upgrade to the judge model itself.

8. What is the most practical way to turn a production failure into an eval improvement?
   • A. Rewrite the prompt and move on.
   • B. Add the failing example to the regression set, write the expected behavior in a way the scorer can check, and keep it in CI. ✓
   • C. Only add it if the model provider can reproduce it first.
   • D. Wait until the benchmark suite updates with the same issue.

   Option B is correct. The fastest durable improvement is to convert the incident into a regression example. Preserve the input, define the expected behavior, and add the case to the CI gate so future prompt, model, or tool changes cannot reintroduce the same failure. That is how evals become a living engineering system rather than a report you read once. Option A is wrong. Prompt rewrites may help, but without a regression test the lesson disappears. Option C is wrong. Provider reproduction is useful, but the team can still learn from the incident and protect its own product immediately. Option D is wrong. Public benchmarks move slowly and do not track your product-specific failure modes. Production reality: production incidents are the highest-value source of new eval coverage because they represent real user pain, not theoretical concerns.

9. What order should you build eval coverage in for a new LLM feature?
   • A. Adversarial first, then golden, then regression.
   • B. Golden first, then regression, then adversarial. ✓
   • C. Regression first, then golden, then adversarial.
   • D. Only build LLM-judge scoring until the product stabilizes.

   Option B is correct. Golden cases establish the must-pass baseline for the feature. Regression cases capture lessons from incidents as soon as they happen. Adversarial cases come after the core behavior is understood, so the probes target real failure modes rather than guesses. Option A is wrong because adversarial tests without a baseline do not tell you whether the feature works at all. Option C is wrong because regression tests depend on a first pass at defining what the feature should do. Option D is wrong because programmatic checks should be added early wherever possible; they are deterministic and cheap. Production reality: mature eval suites grow in layers, not all at once.

10. A team runs Self-Refine on their LLM pipeline: scores improve from 3.1 to 4.2 over five iterations, but production users report the outputs feel "canned" and unhelpful. What failure is most likely occurring?
    • A. The generator model is too small to benefit from refinement.
    • B. Reward hacking — the optimizer is gaming the scorer rather than improving real quality, because the rubric does not capture what users actually value. ✓
    • C. Five iterations is too few; running ten would close the quality gap.
    • D. Self-Refine is incompatible with rubric-based scoring and should use pairwise preference instead.

    Option B is correct. When rubric scores rise steadily while user-reported quality falls or stagnates, the canonical diagnosis is reward hacking — the improvement loop has learned to satisfy the scorer rather than the underlying quality the scorer was intended to proxy. This is the central failure mode of evaluation-driven improvement loops. In this scenario, the rubric likely rewards confident-sounding, well-structured output without penalizing the pattern users experience as "canned." The optimizer converges on outputs that maximize rubric dimensions while drifting from natural, genuinely helpful responses. Option A is wrong. Model size does not prevent Self-Refine from converging on rubric-satisfying outputs. A smaller model can overfit to a rubric just as readily as a larger one. Option C is wrong. Running more iterations without diagnosing reward hacking will deepen the problem, not fix it. The rubric or scoring function itself must be audited and corrected before additional refinement cycles are valuable. Option D is wrong. Self-Refine is fully compatible with rubric scoring — that is precisely how the evaluator-optimizer workflow (Anthropic's named pattern) and DSPy compile-style loops are designed. Pairwise preference is a useful complement but does not resolve the underlying reward hacking issue. Production reality: the WP-06 checklist for reward hacking includes holding out a calibration set the optimizer never sees, rotating judge models, and running a 5% human-audit sample during the refinement loop — not after it. A score-vs-production-feedback gap is the primary signal; catch it early or the system silently degrades.

11. You need to choose between running Self-Refine at inference time and running DSPy compile offline. A high-volume customer-support pipeline processes 50,000 requests per day. Which approach is correct and why?
    • A. Self-Refine at inference time, because it adapts to each request dynamically.
    • B. DSPy compile offline, because it pays the optimization cost once at compile time and ships a frozen artifact — the per-request cost of in-context refinement at 50,000 requests per day is prohibitive. ✓
    • C. Both approaches cost the same because DSPy calls the same LLM APIs.
    • D. Neither — at 50,000 requests per day you should switch to fine-tuning instead.

    Option B is correct. Self-Refine runs a generator-critic-revisor loop on every inference call, using 3–10x more tokens per request than direct generation. At 50,000 requests per day that cost multiplier dominates infrastructure economics within days. DSPy compile runs the expensive optimization once offline, produces a static compiled prompt, and inference uses the compiled prompt directly with no additional refinement overhead at serving time. The compiled prompt is the artifact — version-controlled, reviewable, rollback-able — not the optimization loop. Option A is wrong. Per-request dynamic adaptation is Self-Refine's defining property, but it is also its core cost problem. For high-volume production pipelines, "adapts dynamically" becomes "costs 5x as much on every request." The adaptation benefit is real for low-volume, high-stakes outputs (release candidates, regulated content); it is not justified for commodity-volume customer-support drafts. Option C is wrong. DSPy compile does call LLM APIs during the optimization run, but those calls happen once (or periodically on recompilation) — not on every serving request. The amortized per-request cost of a compile run over 50,000 daily requests is negligible. Option D is wrong. Fine-tuning (RLHF, DPO) is flavor-3 optimization that requires training infrastructure and large preference datasets. It is the right escalation when compile-style optimization plateaus, not the immediate response to a volume constraint. Production reality: Anthropic frames Self-Refine as the "evaluator-optimizer workflow" in their agentic patterns guide — the right tool for per-output refinement on high-stakes, low-volume tasks. DSPy compile is the right tool for optimizing a prompt that serves high volume.

Frequently asked questions

What is an LLM evaluation?

An LLM eval is a repeatable, automated test that scores model output against a known expectation, so you can compare prompts, models, and configurations on the same inputs and detect regressions over time. Unlike benchmarks, which measure general capability on a shared leaderboard, evals measure your product on your inputs. The eval harness typically has four components: a dataset of input-output pairs, a runner that executes the model, a scorer that compares output to expectation, and a reporter that records and surfaces results.

What are the 3 dataset shapes in an eval harness?

Golden set: a small, manually curated set of must-pass cases representing critical behaviors — the cases whose failure would be embarrassing or harmful. Regression set: cases drawn from past failures, user complaints, and edge cases discovered in production — these cases encode lessons learned and prevent previously fixed bugs from reappearing. Adversarial set: inputs specifically designed to probe known failure modes — jailbreaks, edge cases, ambiguous instructions, or inputs that historically trigger hallucination. A production-grade eval suite includes all three; most teams start with golden sets only and add regression and adversarial cases as incidents occur.

What is eval-as-code and why does it matter?

Eval-as-code means the evaluation suite lives in source control, runs in CI/CD, and gates deployments exactly like unit tests gate application code. Evals defined in notebooks or run ad hoc before a release are not eval-as-code: they are easily skipped, not reproducible, and do not prevent regressions from reaching production. Frameworks like Inspect AI (UK AI Security Institute), Braintrust, DeepEval, and LangSmith all support eval-as-code: the dataset, scorer, and pass/fail threshold are code artifacts that are committed, reviewed, and versioned alongside the prompt and model configuration.

What is evaluation-driven improvement and how does it differ from running evals?

Evaluation-driven improvement is a system that improves its own prompts, few-shot examples, or rubrics based on its own performance data — without code changes. Running evals is measurement; evaluation-driven improvement is the feedback loop that acts on that measurement. Three flavors exist: in-context refinement (the Self-Refine generator-critic-revisor loop, runs per session), prompt compilation (DSPy compile style, searches offline over prompt variants and produces a frozen artifact), and weight optimization (RLHF, DPO, requires training infrastructure). Most production teams operate in the first two flavors.

What is the difference between Self-Refine and DSPy compile?

Self-Refine runs at inference time: a generator produces output, a critic scores it against a rubric, a revisor proposes a fix, and the loop repeats until the score meets a threshold or a maximum iteration count is reached. The cost is paid on every request. DSPy compile runs offline: an optimizer searches over prompt variants, few-shot examples, and instruction formulations to maximize a metric on a training set, then validates on a held-out set. The compiled prompt is a static artifact deployed to production. Inference uses the compiled prompt directly — no refinement loop at serving time. For high-volume pipelines, DSPy compile is strongly preferred. Self-Refine is appropriate for high-stakes, low-volume outputs where per-request quality justifies the extra cost.

What is reward hacking and how do you detect it?

Reward hacking occurs when an optimization loop learns to satisfy the scorer rather than the underlying quality the scorer was supposed to measure. Scores rise while real quality stagnates or falls. The primary detection signal is a score-vs-production-feedback gap: rubric scores trend upward, but user-reported quality does not improve or gets worse. Detection methods: hold out a calibration set the optimizer never sees and check whether held-out scores track training scores; rotate judge models and compare verdicts (a system gaming one judge will diverge when the judge changes); run a 5% human-audit sample during the loop, not only after. If human-vs-scorer agreement degrades over iterations, the loop is gaming the scorer.

Why are evals more important than benchmarks?

Public benchmarks measure general capability on a curated academic dataset. Evals measure your product on your inputs against your expectations. A model that ranks highly on a leaderboard can still fail on your specific tasks, tone requirements, output formats, or edge cases. The MMLU benchmark does not tell you whether your customer support agent handles refund requests correctly. Your eval does — if you built it right.

When should I use an LLM as a judge?

When the output is open-ended and a fixed string match or programmatic check cannot capture quality — for example, does this summary faithfully represent the source document? Is this code review constructive and accurate? Pair the LLM judge with a written rubric that specifies exactly what each score level means, calibrate the judge against a set of human-graded examples, and audit a random sample of judge outputs weekly to catch drift in judge behavior. Never use an LLM judge as the sole quality gate on a high-stakes output without human review of edge cases.

What metrics gate a deploy vs just inform?

Deploy-gating metrics are the ones whose regression means the release should not ship: must-pass golden set score (must be 100%), task completion rate on the critical path (must not regress by more than N%), and absence of safety violations on the adversarial set (must be 0%). Informational metrics are ones you track for trend awareness but do not block on: average response length, stylistic consistency score, LLM-judge score on exploratory use cases. Conflating informational metrics with gating metrics leads to either false alarms (blocking releases on metrics that do not matter) or false confidence (shipping because the informational metrics look fine while the gating metric was never checked).

How do plateau detection and stop criteria prevent wasted compute in refinement loops?

Plateau detection stops a refinement loop when consecutive iterations stop producing meaningful improvement — for example, two consecutive iterations with a score delta below 0.05 on a 5-point scale. Without a stop criterion, refinement loops can run indefinitely at escalating cost with no quality gain. Production systems typically use two simultaneous bounds: a fixed iteration cap (e.g., maximum 5 iterations) and a token-budget hard cap, whichever hits first. Cycle detection — where score at iteration N regresses below iteration N-2 — indicates oscillation between local maxima; the correct response is to reseed the revisor from a different starting point or stop.

Related topics