Chapter 5 · Optional evaluation reading
Locate failures and test changes to a system
The main chapter introduces criteria, evaluation sets, code checks, and LLM judges. This optional reading asks what to do when those checks reveal failures. It uses the invoice task: return the correct payment due date in YYYY/MM/DD. All records and outcomes are fictional teaching examples.
1. A better average can hide a new failure
Suppose two prompts produce these results on the same four invoices, using the same due-date check:
| Invoice | Prompt A | Prompt B |
|---|---|---|
| A | Incorrect | Correct |
| B | Correct | Correct |
| C | Incorrect | Correct |
| D | Correct | Incorrect |
Accuracy rises from 2/4 to 3/4, but Invoice D now fails. A regression is a failure on a case that previously succeeded. Inspect which cases changed and the consequences of their failures; the average alone cannot determine whether a change is acceptable.
These invented outcomes illustrate a comparison, not measured model performance. Record the prompts, cases, and scoring rules so that a real comparison can be repeated.
2. Use the trace to locate the error
A final-output check tells us that an answer is wrong. To find the cause, inspect the intermediate steps. A trace records a workflow’s inputs, tool calls, and intermediate outputs.
Consider Invoice C, whose correct due date is 2026/12/01. Its issue date is 2026/11/20. A system retrieves the document, converts it to text, extracts a field, and formats the result:
| Step | Recorded result | What it establishes |
|---|---|---|
| Retrieve document | Invoice C returned | The requested document was selected. |
| Convert PDF to text | “Issued: 2026/11/20. Due: 2026/12/01.” | Both dates and their labels are available. |
| Extract due date | “2026/11/20” | The extraction step selected the wrong field. |
| Format output | “2026/11/20” | Formatting preserved that incorrect selection. |
Here, the first relevant mismatch occurs during field extraction. Changing the final date format would not address it.
A different trace could imply a different cause. If retrieval returned Invoice B, inspect document selection. If PDF conversion dropped the “Due” label, inspect text extraction. Locate where the needed information was first lost or misused before deciding what to change.
3. Test the component and the complete workflow
A component evaluation tests one part of a system with controlled inputs. To test the date selector, provide fixed invoice text with known issue and due dates, then check the selected value. To test PDF conversion, provide the original document and inspect whether the important fields survive in the extracted text.
An end-to-end evaluation runs the complete workflow from the original request to the final result. It catches interactions that a component test can miss: a date selector may work with clean text but fail on the text actually produced by PDF conversion.
A useful sequence is:
- Select a failed case using the final-output checks.
- Inspect its trace and state a specific explanation of the failure.
- Change the suspected component and test it with controlled inputs.
- Run the full workflow on the same evaluation set and inspect new failures.
Keep the cases and criteria fixed when comparing versions. Cases repeatedly used to adjust the system become development cases. Retain them to catch regressions, and also test on fresh cases that did not guide those adjustments. Success on familiar examples alone can reflect adaptation to those examples.
When using an LLM judge, record its instructions and compare sampled judgments with human decisions. Check that it receives the evidence required by the criterion: a chart’s readability requires its rendered image, while a summary’s coverage requires its reference facts. A score is useful only when its meaning and evidential basis are clear.
Return to Evaluation for the core examples.
Source
Andrew Ng, Agentic AI, Module 4: evaluation, error analysis, traces, and component evaluation. The invoice records and example outcomes were written for this course.