Building a Test Set

Why a Test Set?

A system based on a language model is not tested like a classic function: the same question can receive different phrasings, and a prompt change that improves one case can degrade ten others. Trying three questions by hand before going to production gives a misleading impression of quality.

The basis of any evaluation is a test set (also called a golden dataset): a versioned list of cases, each with an input and what is expected. For AI it plays the role that unit tests play for code.

Structure of a Case

CASES = [
    {"id": "T01", "categorie": "frequent", "input": "Où est ma facture de mars ?", "expected": "facturation"},
    {"id": "T02", "categorie": "limite", "input": "factur mars ???", "expected": "facturation"},
    {"id": "T03", "categorie": "hors_perimetre", "input": "Quelle est la capitale du Pérou ?", "expected": "hors_sujet"},
]

A good test set:

• starts from real requests (anonymized) or very realistic ones, not only from cases imagined by the team;
• covers frequent cases, edge cases (typos, ambiguous requests), out-of-scope requests, and manipulation attempts;
• indicates each case’s category, to track results by type;
• is versioned with the code, and enriched with each incident found in production.

A few dozen well-chosen cases are worth more than hundreds of redundant ones. Avoid keeping personal data you do not need.

Checking Automatically: Normalized Matching

When the expected output is short (a category, a date, an identifier), you compare it to the expected result after normalization: lowercase, accents removed, extra whitespace removed.

import unicodedata

def normalize(text):
    text = unicodedata.normalize("NFKD", text)
    text = "".join(c for c in text if not unicodedata.combining(c))
    return " ".join(text.lower().split()).strip(" .!")

Without normalization, “Facturation.” and “facturation” would be counted as different, and the score would reflect formatting rather than correctness.

Checking Automatically: Rules

When the answer is free text, there is no single right answer. You then check criteria:

• required elements: the “30 days” return period must appear;
• forbidden elements: no promise of a refund, no card number;
• format: maximum length, valid JSON, language.

These rules are simple, fast, and free. They do not measure everything (tone, relevance), which you will complement with a judge model in the next lesson.

Score and Failure Analysis

You compute a success rate, but above all you look at the failing cases. A score of 90% can hide 0% on out-of-scope requests if there are few of them. Hence the value of the score by category.

Regression Testing

The test set is used at every change: new prompt, new model, new quantization, new documents in the knowledge base. The process:

1. run the test set on the current version and on the candidate version;
2. compare the global and per-category scores;
3. examine each case that used to pass and now fails;
4. decide, and keep the results with the version.

Also think about variability: with a non-zero temperature, the same case can pass and then fail. Set the temperature to 0 for evaluation when possible, or run each case several times.

Key Takeaways

• A versioned, representative, continuously enriched test set is the basis of evaluation.
• Short outputs: normalized matching; free-form outputs: rules.
• You track the score by category and read the failures.
• Every change goes through the test set before production.