0% completed
The Eval Development Loop
On This Page
The Five Steps
One Turn of the Loop
How Often the Loop Turns
When to Fix Without an Eval
Ways the Loop Breaks
Key Takeaways
Practice Questions
What did your team change in its LLM feature last week, and how do you know the change helped?
Most teams can answer the first half of that question. The second half usually gets an answer such as "we tried a few requests and the outputs looked better", which says little about the hundreds of requests nobody tried. The eval development loop is the working habit that makes the second half answerable every time.
This lesson describes the five steps of the loop, follows one full turn of it on the job ticket assistant, and explains when a problem should be fixed directly without writing an eval at all.
The Five Steps
The eval development loop is a repeated cycle of five steps: look at outputs, name the failures, measure them, change the feature, and check again. Each step uses the result of the one before it.
- Look. Read real outputs of the feature, one by one, with the inputs that produced them.
- Name. Describe each failure you find in specific words, then group similar failures under one name.
- Measure. Turn the most important failures into test cases and a grader, and record the current pass rate.
- Change. Edit the prompt, the code, or the model to fix one failure.
- Check. Run the eval again on every case, compare the results case by case, and return to the first step.
Notice that the loop begins with reading, not with measuring. A team that starts by measuring can only measure the failures it already imagined, and the failures that matter most are often ones nobody predicted.
One Turn of the Loop
Look. A developer on the job ticket team reads 40 tickets from the previous day, each next to the customer's request. Most summaries are accurate. Seven of them contain a detail that is not in the request: a refrigerator brand, a model number, or an age such as "about ten years old".
Name. The developer writes a note on each of the seven, then gives the group one name: invented detail in the summary. The name comes with a definition that someone else could apply: the summary states a fact about the appliance or the home that the customer did not give.
Measure. The 40 tickets become 40 test cases, each labeled pass or fail for this one failure. The current result is 33 of 40, or 7 failures. The developer also confirms that the regression set, which checks urgency and trade, passes in full before anything changes.
Change. The developer adds one instruction to the prompt: "Use only details the customer wrote. Do not add brands, model numbers, or ages."
Check. The 40 cases now produce 2 failures instead of 7. The regression set still passes, so the change did not break urgency or trade. Reading the two remaining failures shows something new: both summaries now name a likely cause of the fault, such as "probably a worn seal". That is a different failure, a diagnosis the assistant does not promise to make, and it starts the next turn of the loop.
Notice that the check step did two jobs. It confirmed that the change worked and broke nothing, and it found the next problem by reading outputs again. Forty cases are enough to see a drop from 7 failures to 2, but not to state a precise rate, which later lessons on statistics address.
How Often the Loop Turns
A small turn, like the one above, can take an afternoon. Larger turns, in which someone reads a fresh sample of production traffic, take longer and happen on a schedule. Hamel Husain and Shreya Shankar, who teach this method, report that the teams they have seen typically repeat such a review every two to four weeks.
The schedule matters because users change what they send. New customers arrive, seasons change the mix of requests, and a model provider updates its model. A loop that turned only once, before launch, measures a feature that no longer exists.
When to Fix Without an Eval
Not every failure needs an eval; some need only a fix. Suppose the developer finds that some replies stop in the middle of a sentence. The cause is a setting in the code that limits replies to 60 tokens, the word pieces a model reads and writes. Nobody needs a grader to know the fix: raise the limit, confirm with a few requests, and add one long reply to the regression set so the limit cannot quietly return.
A failure deserves its own eval when one or more of these is true:
- It needs judgment to recognize, as invented detail does, so a quick look cannot confirm the fix.
- It depends on how the input is written, so a fix that works on three requests may fail on the fourth.
- It could come back after a later prompt or model change.
- It is costly, such as a missed emergency, so the team must know its rate, not only that it was fixed once.
A failure that meets none of these, such as a broken template or a wrong setting, is a bug. Fixing it directly and moving on is the faster and better choice.
Ways the Loop Breaks
Teams rarely abandon the loop on purpose. It breaks in a few predictable ways:
- Measuring without looking. The team tracks a score but nobody reads outputs, so new kinds of failure never get a name.
- Checking only the target. The team reruns the seven failing cases and skips the rest, so side effects go unnoticed.
- Tuning to the test set. The team edits the prompt until every case passes, and the prompt then works on those cases more than on real traffic. The lesson Keeping a Test Set Useful shows how to prevent this.
- Turning it once. The team builds the eval before launch and never reads production outputs again.
Key Takeaways
- The eval development loop has five steps: look, name, measure, change, and check.
- It begins with reading outputs, because the most important failures are often ones nobody predicted.
- The check step reruns every case and compares results, and it often finds the next failure.
- The loop repeats on a schedule, because users, inputs and models change.
- A failure needs an eval when it needs judgment, depends on wording, could return, or is costly; otherwise, fix it directly.
The first step of the loop, reading outputs and naming what went wrong, has its own method. The next lesson, Why Error Analysis Comes First, explains why it comes before any metric.
Practice Questions
1. A team starts its eval work by adopting a list of ten standard quality metrics. What does the loop suggest instead?
<details><summary>Show answer</summary>Start by reading the feature's own outputs. A standard list measures failures someone imagined in advance. Reading outputs finds the failures this feature actually has, such as invented details in a summary, and those become the metrics.
</details>2. After the prompt change, the developer reruns only the seven cases that used to fail, and all but two now pass. What has been skipped?
<details><summary>Show answer</summary>The check on every other case. The change could have broken cases that used to pass, such as urgency or trade. The check step reruns the whole set and the regression set, and compares results case by case.
</details>3. Replies are cut off because a code setting limits them to 60 tokens. Should the team build a grader for cut-off replies?
<details><summary>Show answer</summary>No, this is a bug to fix directly. The cause is known and the fix can be confirmed with a few requests. One long reply added to the regression set is enough to stop the limit from returning.
</details>4. Why does reading outputs again in the check step matter, even when the pass rate improved?
<details><summary>Show answer</summary>Because a fix can turn one failure into another. In the example, the summaries stopped inventing details but began naming likely causes. Only reading the outputs revealed this, because the count of failures did not say what kind they were.
</details>Reading Progress
0%
On This Page
The Five Steps
One Turn of the Loop
How Often the Loop Turns
When to Fix Without an Eval
Ways the Loop Breaks
Key Takeaways
Practice Questions