LLM Evaluation in Production
The difference between teams that ship models weekly and teams that fear every change is a promotion gate. What to measure, how to automate judgment you can trust, and where evaluation data is allowed to live.
5
Eval layers a production stack actually needs
50–100
Golden examples to start a useful suite
0
Models promoted without passing the last model's evals
24/7
Online monitoring after the gate — drift never sleeps
Every Unevaluated Model Is a Production Incident on Layaway
LLM systems change constantly — prompts get edited, models get swapped, retrieval corpora grow, providers push silent updates. Each change can improve one behavior and quietly break three others, and unlike conventional software, nothing crashes when it happens. The output just gets worse, and the first detector is a customer. Evaluation is how you find out before they do: a measured baseline, a suite of checks every change must clear, and monitoring for what the suite couldn't foresee.
In the AI Scaling guide we make the case that evaluation gates are one of the four operational fixes separating the teams that deploy models daily from the majority that can't. This page is the practitioner's version of that fix: what the gate is made of, layer by layer.
How LLM Evaluation Goes Wrong
Three patterns account for most quality incidents we see in the field. All three are cheaper to fix than the incidents they cause.
"It looks good" is the whole test plan
Someone pastes five prompts into a chat window, nods, and the model ships. Two weeks later a customer finds the failure mode nobody typed. Vibes-based QA doesn't scale past the demo it was invented for.
- No baseline — 'better' has no number attached
- No coverage — the hard cases are exactly the ones nobody tries
- No memory — last month's regression comes back and nobody notices
Benchmarks stand in for your workload
MMLU and leaderboard scores measure a model's general ability — not whether it extracts your contract clauses or answers your support tickets. Public benchmarks are for shortlisting models, never for promoting them.
- Benchmark tasks rarely resemble production tasks
- Contamination inflates scores on public test sets
- A 2-point leaderboard gap says nothing about your domain
Evaluation happens once, at selection
The team runs a bake-off, picks a winner, and never measures again. But prompts change, models get swapped, retrieval indexes drift, and providers update behavior on their schedule — quality is a moving target that needs standing instrumentation.
- Prompt edits ship without regression runs
- Provider model updates silently change outputs
- RAG quality decays as the corpus and index drift
The Five-Layer Evaluation Stack
Each layer catches what the others can't. Skipping one doesn't save work — it relocates the work to an incident channel.
Golden datasets
RegressionA versioned set of real inputs with known-good outputs — your unit tests for model behavior. Every prompt change, model swap, or retrieval tweak runs against it before anything ships. Start with 50–100 examples drawn from production, not imagination.
LLM-as-judge
JudgmentA strong model scores outputs against a rubric — correctness, completeness, tone — at a scale humans can't match. Judges need calibration against human labels and periodic audits; an unexamined judge is just automated vibes.
Human review
Ground truthDomain experts label a sample of outputs to calibrate the judges and catch what rubrics miss. Expensive per item, so spend it where it counts: judge calibration, dispute resolution, and the failure modes that reach customers.
Retrieval & faithfulness
RAG-specificRAG systems fail in two separable places: retrieval (did the right context surface?) and generation (did the answer stay faithful to it?). Measure both independently — most 'hallucination' complaints in production are retrieval misses wearing a disguise.
Production monitoring
OnlineSampled scoring of live traffic, user feedback signals, latency and cost per request on the same dashboard as quality. Offline evals gate what ships; online monitoring catches what the gate couldn't foresee.
Tooling exists at every layer — promptfoo and DeepEval for regression suites, Ragas for RAG metrics, Langfuse and Arize Phoenix for tracing and online scoring, and cloud-native options like Amazon Bedrock's evaluation jobs for teams running Claude and other foundation models on AWS. The stack is the easy part; the discipline below is what makes it bite.
Four Rules That Turn Evals Into a Gate
Metrics inform; gates decide. These are the rules that move evaluation from a dashboard nobody checks to a pipeline step nobody bypasses.
Version datasets like code
Golden sets live in git or a registry with versions, owners, and review. When an eval fails, you need to know whether the model changed or the test did — and un-versioned datasets can't answer that.
Gate promotion, don't advise it
Evals belong in the deployment pipeline with pass/fail authority: no model, prompt, or retrieval change reaches production without clearing the suite the last version cleared. Advisory dashboards get ignored the week a deadline hits.
Keep evaluation behind the boundary
Eval datasets are distilled from your most sensitive data — real contracts, real tickets, real records. Run evaluation where that data is allowed to live, under the same governance boundary as inference. Shipping your golden set to a third-party eval SaaS is a data transfer decision, not a tooling default.
Feed production back into the suite
Every incident, thumbs-down, and support escalation is a candidate golden example. The suite that catches next quarter's regressions is built from this quarter's failures — close the loop on a schedule.
The boundary rule deserves emphasis: evaluation datasets are distilled from exactly the data your governance policy exists to protect. Where evals run is a sovereignty decision — the full argument is in the Sovereign AI guide.
Evaluation Is a Pipeline Stage, Not a Project
In our engagements, the evaluation harness ships with the platform, not after it. The six-week rapid strike timeline includes the promotion pipeline precisely because retrofitting a gate onto a live service is harder than building on one — the first model through the pipe establishes the baseline every successor must beat.
That's the shape of our AI consulting work generally: LLM evaluation and governance as a first-class capability alongside MLOps pipeline discipline — versioned golden sets, calibrated judges, gated promotion, and online monitoring, operated by US-based platform engineers on infrastructure you control.
LLM Evaluation Questions, Answered
Related Resources
AI Scaling Guide
Evaluation gates are one of four operational fixes that get teams deploying models daily — the full picture.
Sovereign AI Guide
The governance boundary that decides where models run and where eval data may travel.
Open WebUI on Kubernetes
The interface layer of the self-hosted stack this guide's promotion gates protect.
AI Consulting
Evaluation harnesses and governance are a core capability of our AI consulting practice.
MLOps Solutions
The pipeline discipline — CI/CD, GitOps, promotion — that evaluation gates plug into.
Case Study: Six-Week AI Rapid Strike
Production inference in six weeks — including the promotion pipeline models ship through.
Evaluation Is Where AI Programs Grow Up
There's a reliable maturity marker in enterprise AI, and it isn't model choice or GPU count — it's whether the team can answer "did this change make the system better?" with a number. Early-stage programs argue from anecdotes: a stakeholder's impressive demo, a customer's bad screenshot. Mature programs argue from eval runs. The transition usually happens after the first quality incident that a fifty-example golden set would have caught, which is why our advice is always to build the small suite now rather than the comprehensive one later. Fifty real examples with a pipeline gate beats five hundred planned examples in a backlog, every time.
The evaluation conversation is also inseparable from the platform conversation. Teams running on hyperscaler AI platforms — Claude on AWS Bedrock, models behind Azure or Google endpoints — inherit useful primitives: managed evaluation jobs, logging, guardrail hooks. Teams running open-weight models on their own Kubernetes inherit something different but arguably more valuable: total control over where evaluation data lives and total visibility into what changed when quality moved. Most enterprises end up hybrid, and the evaluation suite becomes the connective tissue — the same golden sets and rubrics scored against every backend, producing the comparable evidence that routing and governance decisions actually need.
What makes this discipline affordable is that it compounds. The first golden set is a week of annoying curation; every subsequent one is cheaper because the harness, the judge calibration, and the pipeline wiring already exist. Production failures stop being pure cost and start being test cases. Model upgrades stop being leaps of faith and start being afternoon experiments — run the suite, read the diff, promote or don't. That loop, more than any individual metric, is what evaluation buys: the ability to change AI systems at the speed the ecosystem changes, without gambling the customer experience on each move.
Ready to make AI operational?
Whether you're planning GPU infrastructure, stabilizing Kubernetes, or moving AI workloads into production — we'll assess where you are and what it takes to get there.
US-based team · All US citizens · Continental United States only