# 7 Habits of Highly Effective Generative AI Evaluations

Justin Muller, AWS | AI Engineer World's Fair 2025 | 25:39

Source: https://www.youtube.com/watch?v=wHhlvcQgi9M
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/7-habits-of-highly-effective-generative-ai-evaluations
Published: 2025-06-03
Tags: debugging, evals, reliability, testing

## TL;DR
- Evaluations help teams find and fix problems, rather than only producing a quality score.
- Fast, segmented evaluations let teams test hundreds of changes each day and identify which part of a workload is failing.
- Successful evaluation frameworks combine gold-standard data, generative AI judges, numerical checks, reasoning, and traditional metrics.

## Summary
Justin Muller argues that evaluations are the missing piece in scaling generative AI workloads. Teams often have a single quality number but no way to see which step caused an error. He describes a document-processing project that improved from 22% to 92% accuracy after the team built an evaluation framework and used it to locate specific failures. Muller treats evaluations as debugging tools. They should run quickly, produce numerical results, explain why a result received its score, evaluate each prompt or workflow step separately, cover the full range of use cases, and use traditional checks where those work better. He recommends building a reviewed gold-standard set, generating outputs and reasoning, judging them against the expected answers, and summarizing results by category. The talk is practical and candid about the work involved: teams that will not spend time building evaluations often have experiments, while teams that invest in them can iterate toward production.

## Key ideas
### Evaluations find problems before they become scaling failures
[01:02](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=62s)
Muller says the biggest challenge in scaling generative AI is the lack of evaluations. Customers mention cost, hallucinations, accuracy, and capacity, but he sees missing evaluations across workloads most often. In one document-processing project, six to eight engineers had worked for roughly six to twelve months, yet the project had only one end-to-end number: 22% accuracy. After Muller designed an evaluation framework, the team could see where failures occurred. Fixing the individual issues was relatively easy once they knew their causes. Over the next six months, accuracy reached 92%, above the 90% production threshold, and the workload launched at scale.

### A useful evaluation explains how to improve the system
[03:57](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=237s)
Muller says a score is a secondary reason to evaluate a generative AI workload. The main goal is to discover problems and, where possible, suggest solutions through generative AI reasoning. He compares this with grading an essay. A poor professor gives only an F, while a good professor points out what went wrong and how the student can improve. The same applies to model outputs. A weather summary that calls rainy, windy, 40-degree sensor data sunny deserves a zero, but the score alone does not explain the failure. Asking the model to explain its reasoning can reveal that it ignored the rain because it associated happiness with mental health.

### The reasoning process matters even when the answer is correct
[08:43](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=523s)
Muller uses a drilled hole in a piece of wood to show why output quality is not enough. A hole may look correct, while the method used to make it suggests the system will fail next time. He applies the same idea to generative AI. A weather prompt may produce the correct sunny answer for sunny input, yet the model's reasoning can still be unreliable. If an evaluation checks only the final answer, the team may approve a prompt that happened to work in one case. Evaluations should inspect the reasoning used to generate the response, and they should also inspect the reasoning used by the judge that scores it.

### Prompt decomposition makes failures visible at each step
[11:23](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=683s)
Large prompts are hard to evaluate because an error may come from any instruction inside the prompt. Muller compares this with placing a multimeter at the beginning and end of a large electrical system: the measurement tells you something is wrong, but not where. He recommends breaking a large prompt into a chain of smaller prompts and attaching an evaluation to each section. In the weather example, a model sometimes decided that wind speed seven was less than five. Moving that mathematical comparison into Python made the result fully accurate. Decomposition also helps teams choose whether generative AI belongs in a particular step.

### Fast evaluations allow hundreds of daily iterations
[15:32](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=932s)
The first habit is speed. Muller describes slow processes where an engineer sends a prompt to a test site, waits for a team to test it, and receives feedback a week later. That pace may allow only four or eight changes per month. His rule-of-thumb target is a 30-second evaluation. One ten-second stage generates results for 100 test cases in parallel. A second ten-second stage judges those results in parallel against the gold standard. The final ten seconds summarize the judgments by categories and describe patterns in correct and incorrect answers. The point is to make failures easy to inspect, rather than leaving an engineer with 100 responses to read manually.

### Numbers and diverse test cases make evaluation results useful
[18:14](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=1094s)
Effective frameworks produce numerical results even when individual judge scores vary. Muller says this variation is similar to a professor grading the same essay differently on different days. Running many test cases and averaging the results reduces the effect of that jitter. A broad test set also forces the team to define the product's scope. He gives the example of tax questions, where a team may disagree about whether the system should answer, redirect users, or refuse entirely. The test set should include core use cases and examples outside the intended scope, so the team can measure whether the model responds appropriately.

### Each workflow step needs its own evaluation
[21:01](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=1261s)
Muller says scaled workloads are usually made of multiple steps, so each step should be evaluated separately. This helps teams choose the smallest suitable model for each task. A semantic router might send easy inputs to a small model and harder inputs to a larger one. Evaluating the router and the downstream steps separately shows whether each part works. It also removes unnecessary instructions. If one large prompt contains instructions for both easy and hard queries, an easy query carries unused instructions that add cost and may confuse the model. Smaller, evaluated steps send only the information needed for the task.

### Traditional checks still belong in generative AI evaluations
[22:37](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=1357s)
Muller's final habit is to keep traditional evaluation methods where they fit. A numeric router output can be checked with a direct numeric comparison instead of asking another model to judge whether one equals one. Retrieval-augmented generation systems can use database accuracy measures such as retrieval, precision, and F1 scores. Cost and latency also remain suitable for conventional tooling. He warns against using generative AI for every evaluation simply because the workload uses generative AI. The evaluation method should match the output and the part of the system being tested.

### A reviewed gold-standard set determines the quality of the framework
[23:34](https://www.youtube.com/watch?v=wHhlvcQgi9M&t=1414s)
Muller presents the evaluation flow as a system built around a gold-standard set. Each input goes into a prompt template and language model, which produces an answer and reasoning. A judge compares that output with the matching expected answer and produces a score with its reasoning. The results can then be grouped by category and summarized. He says building the gold-standard set is the most valuable use of the team's time because every later component depends on it. Generative AI can help create a silver-standard set, but a human must review it before it becomes a trusted reference.

## Notable quotes
- "The main goal with any evaluation framework should be to discover problems." (04:38)
- "The number one thing that I see across all workloads is a lack of evaluations." (01:25)
- "The pace of innovation, the pace of increasing your accuracy is going to be much much faster." (16:26)
- "Your whole system is going to be pointed towards and designed towards this gold standard set." (23:34)

## Tools & references mentioned
- AWS
- Claude
- Nova Micro
- Python
- RAG
- AI World's Fair

## Who should watch
- You are trying to move a generative AI prototype into production and have only one overall quality score.
- Your team spends days waiting for manual tests or cannot tell which prompt step caused a failure.
- You are designing an evaluation framework and need guidance on test data, model judges, decomposition, and traditional metrics.

## Related talks

- [How to Run Evals at Scale: Thinking Beyond Accuracy or Similarity](https://aietalks.com/talks/how-to-run-evals-at-scale-thinking-beyond-accuracy-or-similarity) (Muktesh Mishra, Adobe, 09:25)
- [Productionizing GenAI Models](https://aietalks.com/talks/productionizing-genai-models) (Lukas Biewald, Weights & Biases, 22:36)
- [Engineering Better Evals: Scalable LLM Evaluation Pipelines That Work](https://aietalks.com/talks/engineering-better-evals-scalable-llm-evaluation-pipelines-that-work) (Dat Ngo & Aman Khan, Arize, 24:46)
- [Mastering AI Evaluation: From Playground to Production](https://aietalks.com/talks/mastering-ai-evaluation-from-playground-to-production) (Doug & Carlos Essan, Braintrust, 1:25:08)
- [The Build-Operate Divide: Bridging Product Vision and AI Operational Reality](https://aietalks.com/talks/the-build-operate-divide-bridging-product-vision-and-ai-operational-reality) (Chris Hernandez, Chime & Jeremy Silva, Freeplay, 12:50)