Phase 8: Evaluation, Safety & Observability · 60 min · Promptfoo · RAGAS · DeepEval
The Problem
A team ships an AI feature. The PM asks, "Is it good?" The engineer says, "I tried five queries and they looked right." Two weeks later, users report wrong answers. Nobody can tell whether last Friday's prompt change made things better or worse because there is no baseline, no test set, and no automated scoring.
This is vibes-based evaluation and it is the default in most teams. The alternative is systematic evaluation: a defined dataset, automated scoring, tracked over time.
The Concept
Why LLM Evaluation Is Different
Traditional ML evaluation is straightforward: you have a test set with labeled answers, you compute accuracy/F1/AUC, and you're done. There's one correct answer per input, and "correct" is unambiguous.
LLM evaluation is fundamentally different because there is no single correct answer. A summary can be good in infinitely many ways. A chatbot response can be helpful, concise, accurate, and friendly — or helpful, verbose, accurate, and formal — and both are "correct." This means you can't just compare output to a gold label; you need to evaluate properties of the output (accuracy, faithfulness, tone, safety) using a mix of methods.
The second challenge: LLM outputs are non-deterministic. The same prompt can produce different outputs on different runs (depending on temperature and sampling). This means your eval needs to run multiple times to get stable signal, or you need to use deterministic settings (temperature=0) for reproducibility.
The third challenge: LLM systems are pipelines, not single models. A RAG system has retrieval, ranking, prompt assembly, and generation — each can fail independently. An end-to-end eval tells you "the answer is wrong" but not where it went wrong. You need component-level evals to isolate failures.
The Eval Pyramid
The solution to the pipeline problem is the eval pyramid — four layers of evaluation, each catching different failure modes:
Your team only runs end-to-end integration evals on the full RAG pipeline. When quality drops, it takes days to isolate whether retrieval, generation, or the prompt caused it. What eval structure would fix this?
The eval pyramid has layers: unit (individual prompt assertions), component (retrieval/generation separately), and integration (end-to-end). When only the top layer exists, failures can't be attributed. Adding component-level evals lets you immediately see "retrieval recall dropped from 0.85 to 0.60" instead of guessing.
The Eval Pyramid
Each layer catches different failure modes. You need all four.
What Makes a Good Eval?
| Property | Good Eval | Bad Eval |
|---|
| Specific | Tests one behavior per case | "Does the output look right?" |
| Reproducible | Same input → same pass/fail criteria | Subjective judgment each time |
| Automated | Runs in CI, no human needed | Requires manual review |
| Representative | Covers real user queries and edge cases | Only tests happy path |
| Versioned | Tracked alongside code changes | Ad-hoc spreadsheet |
Types of Eval Metrics
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers Build It, Use It, Ship It, Evaluation, Exercises, Key Terms, Common Pitfalls, Interview Framing — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.