LLM Evaluation & Testing in Production

Start with real inputs

The most important step costs a day and gets skipped constantly: collect fifty to a hundred real inputs before building.

Real means what users will actually submit — messy, ambiguous, badly formatted, occasionally hostile. Not the clean examples you'd write to demonstrate the feature. The gap between those two distributions is where AI products fail.

For each, record the correct output. Where "correct" is a judgment call, record what a good answer must contain and what it must not.

Choosing how to score

Match the method to the task:

Exact match for classification and extraction with a defined answer. Cheap and unambiguous — use it wherever it applies.

Contains / must-not-contain assertions for generated text with hard requirements. "Must cite a source." "Must not promise a refund." Fast, deterministic, and catches most compliance failures.

LLM-as-judge for open-ended quality where the criteria are real but not mechanical. Give the judge a rubric and examples, and validate it against human ratings on a sample before trusting it. An unvalidated judge measures nothing.

Human review on a sample, always. Automated scores drift from what people actually want, and periodic human checks are what catch it.

Wire it into the loop

An eval set you run manually gets run twice and abandoned. Make it automatic:

Every prompt change runs the suite; the score goes in the pull request
A regression threshold blocks the merge
The suite runs on a schedule against production traffic samples, because the model can change under you

That last point matters more than teams expect. Providers update models. An application accurate in March can drift in June with no code change. Log the model version against every inference — it's what lets you distinguish "the model changed" from "our retrieval broke."

Metrics worth tracking

Beyond a headline accuracy number:

Per-category accuracy — an aggregate of 85% can hide one class at 30%
Latency at p50 and p95 — the tail is what users complain about
Cost per request, tracked alongside quality, so improvements that triple spend are visible
Refusal and fallback rate — a rising rate signals drift or a prompt problem
Retrieval hit rate separately from answer quality, so you know which half is failing

What good looks like

An evaluation set built from real inputs, scoring appropriate to the task, running automatically on every change, with per-category breakdowns and cost tracked next to quality. Plus a documented picture of where the system is weak — every AI feature has a failure envelope, and knowing yours is the difference between managing it and being surprised.

We build this during the engagement rather than after, because retrofitting evaluation onto a shipped feature means reconstructing what "correct" meant months later.

FAQ

How do you test an LLM feature?

Build an evaluation set of 50-100 real user inputs with known-good outputs, pick scoring appropriate to the task (exact match for extraction, assertions for hard requirements, a validated LLM judge for open-ended quality), and run it automatically on every prompt change with a regression threshold that blocks merges.

What is LLM-as-judge and can you trust it?

Using a model to score another model's output against a rubric. It's useful for open-ended quality where criteria are real but not mechanical — but you must validate the judge against human ratings on a sample first. An unvalidated judge produces numbers that measure nothing.

How do you catch model drift?

Log the model version against every inference and run your evaluation suite on a schedule, not just on code changes. Providers update models, so an application accurate in March can degrade in June with no change on your side — version logging is what lets you tell that apart from a regression in your own retrieval.