This LLM evaluation guide covers what evaluation is, what to measure, how to pick samples, and the mistakes that waste everyone's time. No jargon where a plain word works. If you ship anything a language model writes, this is the discipline that keeps it honest.
We grade outputs. We do not train models, run fine-tuning, or sell experts we cannot verify.
LLM evaluation is the practice of checking what a language model produces against a defined standard, sample by sample, before you trust it. Teams use it to decide whether a model is ready to ship, which model to pick, and whether a prompt change helped or hurt. Good evaluation means a written rubric, real samples, and grades you can act on. It is different from testing software: there is no single right answer to assert, only outputs to judge.
Skipping evaluation does not remove the failures. It just moves them to your users.
Someone read ten outputs, they looked fine, the feature shipped. Ten friendly samples tell you nothing about the ten-thousandth, and the failure modes that matter are the ones that only show up at scale. Vibes are not a method.
The model nailed the five examples in the pitch deck and falls apart on real user input. Demos are curated; production is not. Evaluation on representative samples is the difference between a good demo and a good product.
A prompt tweak, a model version bump, a retrieval change, and suddenly the answers are worse in a way nobody notices for weeks. Without a standing evaluation, every change is a gamble. With one, it is a measurement.
"The new prompt is better." "No it isn't." Two engineers, two anecdotes, no data. A shared rubric and graded samples end these arguments in an afternoon, because now there is something to point at.
Every evaluation answers one question: did this output meet the standard? The standard has a few dimensions, and you should name the ones that matter for your product before you grade a single sample.
Is it true? For factual outputs this is the whole game: claims checked against sources, numbers exact, no invented details. Correctness is where hallucination detection lives. If your product states facts, measure this first and measure it strictly.
Did the model do what was asked? The right answer in the wrong format, the summary that ignores the length limit, the JSON with an extra field your parser chokes on. This dimension is mechanical and easy to under-grade, but it is where most production breakage actually lives.
Does the output help the person reading it? A correct answer buried in fluff, a technically right explanation pitched three levels too high, a polite refusal where a partial answer would do. Usefulness is judged from the reader's chair, which is why human reviewers keep beating pure automation here.
Nothing harmful, nothing the product should never say. Safety is binary in practice: either the sample crossed a line or it did not. It gets its own dimension because a single failure outweighs a thousand good samples, and because it needs different reviewers and different care than quality grading.
Most bad evaluations fail in the same handful of ways. Knowing them in advance saves you a wasted round.
The team that wrote the prompts grades the outputs. They know what the model was "supposed" to say, so they read generously. Independent reviewers, people with no stake in the prompt, grade what is actually on the page. If you want the truth about your outputs, do not let the authors be the only judges.
Ten samples prove nothing; ten thousand cost a fortune. The useful middle is a few dozen well-chosen samples that cover your real input distribution, including the awkward cases. Our sampling guide walks through how to pick them.
"Rate the quality from 1 to 5" is not a rubric. It is an invitation for every grader to use a different scale. A real rubric names the criteria, describes what each level looks like, and gives examples. See our rubric writing guide for the full method.
A batch that averages 4.2 out of 5 can still contain three catastrophic outputs. Averages hide exactly the failures you most need to see. Grade every sample, keep the worst ones visible, and report the distribution, not just the mean.
Models change, prompts change, user behavior changes. A single evaluation is a photograph; you need a feed. Re-run your evaluation on a schedule, or move to continuous monitoring, so regressions get caught in days instead of quarters.
You send 20 to 50 model outputs plus your rubric, or we help you write one.
Trained reviewers grade every sample against the rubric, backed by automated checks.
Sample-level grades, issue patterns, recommended fixes, and a walkthrough call.
Software tests assert exact expected values. LLM outputs are open-ended, so there is no single right string to compare against. Evaluation judges each output against a rubric: criteria, severity levels, and written reasons. We wrote a full comparison on our evaluation vs testing page.
Partly. Automated judges are fast and cheap and work well for mechanical checks like format, length, and basic factual consistency. They struggle with tone, nuance, and novel failure modes. The honest answer is a mix: automation for scale, trained humans for judgment. Our automated evaluation page explains where each fits.
For a pilot, 20 to 50 samples is enough to surface the repeating patterns. For ongoing monitoring, you grade smaller batches on a schedule. The full method for picking samples is in our sampling guide.
Named criteria, a description of each severity level with examples, and no room for grader improvisation. Our rubric writing guide walks through the whole thing, including a worked example you can adapt.
At minimum, before every launch and after every meaningful change to prompts, models, or retrieval. Mature teams evaluate on a schedule because models and user behavior drift. If you want that running without thinking about it, that is what continuous monitoring is for.
With a pilot: 20 to 50 samples graded in 2 to 3 business days once scope is confirmed, with a walkthrough call. One pilot usually answers the only question that matters: is this thing ready?
Send 20 to 50 samples. Get a real read on your model in 2 to 3 business days once scope is confirmed.
Not sure where to start? Talk to us and we will point you at the right evaluation.