Build stratified test cases across categories — lab audio overview

Host: Welcome back. You're in GenAI Evaluation, Safety and Governance — a course about making sure the AI systems you ship actually behave the way you claim they do. This chapter is all about building evaluation datasets. That means the collection of test questions and expected behaviors you use to measure whether a large language model — an LLM, the kind of model behind chat assistants — is doing its job. Today's skill: making sure your test set covers the full range of things the model will face in the real world. Expert: Let me paint the scenario. Imagine you're on a platform team at a mid-sized fintech, maybe forty engineers, and you've just launched an internal AI assistant that answers employee questions, summarizes policy documents, and helps write customer emails. Three weeks in, someone from compliance pings you: the assistant gave a wrong answer on a translation task. You check your evaluation results — ninety-four percent accuracy, looks great. But when you dig in, you realize your test set was eighty percent question-answering examples and almost no translation examples. Your score was high because you were barely testing the thing that broke. This is the silent killer of evaluation work. If your test cases aren't balanced across the kinds of tasks your model actually does, your quality numbers are lying to you. They're measuring the easy stuff and hiding the hard stuff. What you need is a test set that is deliberately spread across every task type and every difficulty level, so no single weakness can hide behind a good average. Host: Okay, so that's the stakes. In the previous exercise, you built the blueprint — the rulebook that defines what a valid test case looks like, including the list of task categories and difficulty levels you're allowed to use. Now you're extending that. So what exactly are we building in this one? Expert: You're building a test case generator. Think of it as a small factory. You tell it "give me fifty test cases," and it produces a balanced collection, automatically spread across five task categories and three difficulty levels. The five categories are the common things people ask language models to do: answering factual questions, summarizing long text, classifying text into buckets like positive or negative sentiment, generating new content like emails or code, and translating between languages. The three difficulty levels are easy, medium, and hard — short simple inputs versus long tricky ones. The factory uses templates. A template is a fill-in-the-blank pattern, like "Translate this sentence from English to French: blank." You have a handful of these patterns for each category, and the generator fills them in with different values to produce lots of varied test cases without you writing each one by hand. Now the key idea, the real "aha": this is called stratified sampling. Instead of generating cases randomly and hoping the mix works out, you deliberately allocate a quota to each category and each difficulty level, and you fill those quotas on purpose. That's what stops the silent failure I described earlier. After the generator runs, you also analyze the result — you count how many cases landed in each bucket and flag any gaps, like "we have zero hard translation cases." That gap report is just as important as the data itself. Host: Got it. Before someone starts, what's the part that's going to trip them up? Expert: The trap is the word "balanced." People hear "balanced" and assume it means equal — exactly the same number of cases in every bucket. That's not quite right. True balance means proportional to what you care about measuring. If your production traffic is half question-answering and only five percent translation, a perfectly equal split actually over-tests translation and under-tests the common case. But — and this is the twist — for evaluation, you often want to over-test the rare categories on purpose, because that's where you have the least real-world data and the highest risk of a blind spot. So the concrete tip: don't just check that the counts are even. Also check that every combination — every pairing of a category with a difficulty level — has at least some minimum number of cases, maybe three or five. A single missing combination, like "hard summarization," is exactly the kind of gap that will embarrass you later. Your coverage analysis should make those gaps loud and visible. Host: Perfect. So bring it home — what will someone walk away able to do, and where does this lead next? Expert: After this exercise, you'll be able to take any evaluation problem and produce a deliberately structured test set — one where you can point at the coverage and defend it, category by category, difficulty by difficulty. You'll also be able to spot the holes in an existing test set, which is a skill your team will lean on every time someone asks "are we really testing this model properly?" This is a foundational building block. The generator you build here is the kind of tool your platform team can reuse across every model evaluation project going forward. And next, in the third and final exercise of this sequence, you'll extend this work by building a dataset loader that reads test cases from a file, validates each one against the rulebook from exercise one, and produces a full coverage report — including how categories and difficulty levels overlap. That's where these three pieces click together into a real evaluation pipeline you can bring back to your team's architecture discussions. Thanks for listening, and enjoy the lab.