01Why “it looks good” is a trap
The natural way to check an AI feature is to try it a few times, nod, and ship. That instinct will burn you. You test the three questions you happen to think of, they work, you feel confident — and then a real user asks the fourth kind of question and it falls apart, and you never knew because you never asked it. Worse: you tweak a prompt to fix one case and silently break five others you are not looking at. Vibes do not scale, and they do not catch regressions. Real AI work replaces the nod with a number.
02The golden dataset — your answer key
The foundation of all AI evaluation is a golden dataset: a collection of real questions paired with their known-correct answers, and — for RAG — the source that should be used. Think of it as the answer key to an exam you write once and grade against forever. Twenty or fifty carefully chosen questions is plenty to start: the common ones, the tricky ones, and crucially the ones that should be refused (Chapter 10) because no document covers them.
Building it is real, human work — you write the questions and the right answers yourself, because you are defining what “good” means for your system. That effort is not overhead; it is you turning a vague hope (“the bot should be helpful”) into something you can actually measure. The moment you have a golden dataset, every future change gets a verdict instead of a shrug.
You have seen exactly this system from the student’s side. A board exam is not graded on whether the answer “looks good” — there is a model answer sheet, written before any paper was marked, and every script is compared against it by people who never meet you. That is why two examiners give roughly the same marks. Your golden dataset is that answer sheet, written for your own project, and running it is the moment you stop marking your own homework.
03Grade the two halves separately
A RAG answer can be wrong for two very different reasons, and mixing them up wastes days. So grade them apart — this is Chapter 13’s diagnosis instinct, made systematic.
Retrieval quality: did the system fetch the right chunk at all? This one is almost like a normal test — you know which source should have come back, so you can check whether it did, across your whole golden set. Low retrieval score? The answer never had a chance; fix retrieval (Chapter 13). Answer quality: given the right context, was the final answer correct, grounded, and free of invention? Only worth looking at once retrieval is healthy. Two numbers, two different fixes — and knowing which is failing is most of the battle.
Notice: the prompt change lifts answer quality from 40% to 80%, while retrieval stays flat at 80% — it was never the problem. The WiFi question should miss retrieval and refuse; that is a correct refusal, not a failure. Two numbers tell you exactly what to fix next.
04How do you grade the words? Three ways
The hard part: for answer quality, how does a program decide if a freely-worded answer is “correct”? Three approaches, from crude to clever. Exact facts: when the answer contains a checkable fact — a date, a number, a name — just check it is present. Cheap and reliable for factual questions.
LLM-as-judge: the clever, now-standard trick. You use a second LLM call (Chapter 6) as the grader — you give it the question, the correct answer from your golden set, and the system’s answer, and ask “does the answer match the correct one? Reply yes or no with a reason.” A model is genuinely good at judging whether two differently-worded answers mean the same thing (that is just Chapter 8’s meaning-matching). It is not perfect, but it scales to hundreds of questions in minutes. And humans: the gold standard for the final check — you, reading a sample of answers with judgment no metric captures. Real teams use all three: automated checks for speed, human review for truth.
05Run it on every change — catch regressions
Here is where evaluation earns its keep and connects to Chapter 2’s whole workflow. Once you have a golden dataset and a way to grade, you run the entire set every time you change a prompt, a chunking strategy, or a model — and you get a score. Changed the prompt and the score went from 82% to 88%? Ship it. Went from 82% to 71%? You just caught a regression before a single user did — the AI-era version of the automated tests from Chapter 3. This is the difference between improving your system on evidence and changing it on hope.
06The honest reality
Two truths to keep you grounded. Evaluation is never perfect — an AI system is not a calculator, and “88% good” is a real, useful, honest number, not a failure to reach 100. The goal is not perfection; it is knowing where you stand and whether you are improving. And this is genuinely what the industry does: serious AI teams spend a large share of their effort on evaluation, because a system you cannot measure is a system you cannot safely improve. When an interviewer asks “how would you know your AI feature is good?” — a question that filters out the demo-makers instantly — you now have a real, structured answer.
07Do this today
Give your notice-board RAG an answer key. Write ten questions with their correct answers — eight the notices cover, two they do not (the refusal cases). Run all ten through your system and grade them by hand: did it retrieve the right notice, was the answer right, did it correctly refuse the two? Write down the score. Now change one thing — your prompt, your chunk size — and run all ten again. Watching a single number tell you whether your change helped or hurt is the moment AI development stops being guesswork and becomes engineering.