Evals & Quality for AI Features
Knowing — not hoping — that your feature works
A practical quality system for AI features: define quality, read outputs with error analysis, build golden datasets from real usage, write code-based and model-graded checks, evaluate extraction and RAG, and run evals in development, CI, and production.
- Lessons
- 9
- Reading time
- 97 min
- Level
- Intermediate
- Access
- Full course
Lessons in this module
- 9.110 min
What Quality Means for an AI Feature
Turn "make it good" into measurable criteria per feature — correctness, completeness, format, tone, safety — and decide which ones block a release.
- 9.210 min
Error Analysis: Read Your Outputs First
The highest-leverage quality habit: review real outputs, write open notes, group them into failure categories, and fix the biggest bucket first.
- 9.310 min
Building a Golden Dataset from Real Usage
Assemble a test set that represents reality: sampling production traffic, covering edge cases, labeling efficiently, and keeping it fresh.
- 9.410 min
Code-Based Checks and Assertions
The cheap, deterministic evals to write first — format, schema, length, required facts, forbidden content — and a tiny eval runner in TypeScript.
- 9.511 min
Model-Graded Evals You Can Trust
Write grader prompts with clear pass/fail criteria, calibrate them against human labels, and track agreement so your grader stays honest.
- 9.612 min
Evaluating Extraction, Classification, and Generation
The right metrics for each feature type: field-level accuracy, precision and recall, confusion matrices, and pairwise comparison for open-ended text.
- 9.712 min
Eval-Driven Development and CI
Make evals part of every change: a fast local loop while iterating, a regression suite in CI, and release gates for prompt and model updates.
- 9.811 min
Monitoring Quality in Production
Sample live traffic for grading, watch for drift, alert on quality drops, and close the loop from production failures back into your test set.
- 9.911 min
Experiments and A/B Tests for AI Changes
Test prompt and model changes on real users: choosing metrics that reflect value, sample sizes, guardrail metrics, and reading noisy results honestly.
About this module
An eval is a repeatable test for an AI feature: a set of real inputs, a definition of what a good output looks like, and a way to check every output against that definition. Because language models are probabilistic, the same prompt can produce a great answer today and a subtly wrong one tomorrow, and a change that fixes one case can quietly break ten others. Evals are how you know whether your feature works, whether a change made it better, and whether a new model is safe to switch to.
Most teams start with vibes: run a few examples, read the outputs, ship if they look good. That works for a demo and fails in production, where users send messy, multi-part, unexpected inputs and the rare severe failure, like a reply that promises a refund nobody approved, matters more than the average. A practical quality system replaces vibes with named criteria, real test data, and checks you can run on every change.
This module builds that system step by step for a realistic help-desk feature. You will define quality as pass/fail criteria with release gates, read real outputs with error analysis to find the failures that actually happen, and build a golden dataset from production traffic. Then you will write cheap deterministic code checks, add model-graded evals for criteria that depend on meaning, and calibrate those graders against human labels so you can trust their numbers.
The second half covers choosing the right metrics for extraction, classification, and open-ended generation; running evals in a fast local loop and as a regression gate in CI; monitoring quality on live traffic; and running A/B tests for prompt and model changes. Code examples are in TypeScript with the Anthropic SDK, and the methods apply to any model provider.
Questions about Evals & Quality for AI Features
What are LLM evals?
LLM evals are repeatable tests for features built on language models. Each eval runs your feature on a set of test inputs and checks the outputs against defined criteria, using code checks, model graders, or human review. They tell you whether a prompt or model change made quality better or worse before users find out.
How do I start evaluating an AI feature?
Start by reading 50 to 100 real outputs and writing down what goes wrong, then group those notes into failure categories and count them. Turn the most common and most severe categories into criteria, collect test cases from real usage, and write cheap code checks first. Add model-graded evals only for criteria code can't check.
What is LLM-as-judge and can I trust it?
LLM-as-judge means using a model to grade another model's output against written criteria. It is useful for judgments that depend on meaning, such as whether a reply answered every question. You can trust it only after measuring how often it agrees with careful human labels, and you should re-check that agreement whenever the grader or the feature changes.
How big should an eval dataset be?
Fifty to one hundred well-chosen cases drawn from real usage is enough to catch large regressions and guide prompt work. Grow toward a few hundred over time, adding mostly real failures and under-covered edge cases. Watch small slices: with 20 cases in a slice, one case flipping moves its pass rate by 5 points.
Should I use code checks or model-graded evals?
Use code checks wherever they can reliably decide the outcome: format, length, schema, required facts, forbidden phrases, and invented identifiers. They are free, instant, and consistent. Use model graders for criteria that depend on meaning, and keep each grader focused on one pass/fail criterion.