Idée en 30 secondes
Golden dataset est un ensemble figé de cas de test qu'une équipe utilise pour vérifier le comportement d'un agent de façon stable.
La valeur principale : la même version du dataset donne des résultats comparables entre candidate et baseline.
Le problème
Sans golden dataset, le testing devient vite aléatoire :
- aujourd'hui, on teste un jeu de requêtes ;
- demain, un autre ;
- après-demain, certains cas ne sont même pas exécutés.
Dans ce mode, il devient difficile de comprendre ce qui a changé après une release : le comportement de l'agent ou simplement le jeu de scénarios.
Conséquences les plus fréquentes :
- les régressions sont détectées trop tard ;
- le
diffentre versions paraît instable ; - le CI gate devient bruité et l'équipe cesse de lui faire confiance.
Concept principal / modèle
Golden dataset n'est pas seulement un ensemble d'exemples, c'est un artefact versionné : structure de cas claire, règles de labellisation et version contrôlée.
| Élément du cas | Pourquoi c'est utile |
|---|---|
id | Identifie le cas de manière stable entre les versions |
input | Fixe exactement ce qui est envoyé à l'agent |
expected_behavior | Définit ce qui est considéré comme un résultat correct |
checks | Définit des validations déterministes pour le système d'évaluation |
tags | Permet de regrouper les cas par risques et types de scénarios |
Plus le schéma des cas, la labellisation et la version du dataset sont stables, moins on risque d'expliquer les différences entre runs par du bruit plutôt que par un vrai changement de comportement.
Comment ça fonctionne
En pratique, golden dataset est mis à jour via un processus séparé, pas avec chaque release. Chaque nouveau cas suit les mêmes étapes avant d'entrer dans une version du dataset.
Comment une version exploitable de golden dataset est construite
- Sources - les cas viennent des traces production, incidents et edge cases importants.
- Dedupe and filter - les doublons et scénarios bruités sont retirés avant labellisation.
- Canonical schema - chaque cas est normalisé vers une structure unique (
id,input,expected_behavior,checks,tags). - Review and label - le comportement attendu et les critères de validation sont fixés.
- Version and freeze - le dataset reçoit une version (par exemple
v1.4) et est utilisé tel quel dans les eval runs.
Golden dataset ne lance pas les tests à lui seul. Il fournit une base stable pour eval harness et les comparaisons de régression.
Implémentation
En pratique, golden dataset repose sur quelques règles simples. Les exemples ci-dessous sont schématiques et non liés à un framework précis.
1. Schéma canonique d'un cas
expected_behavior peut contenir à la fois des attentes strictes pour des checks déterministes et des critères pour un scoring via LLM-as-a-judge.
case = {
"id": "support_refund_partial_outage",
"input": "Refund my order #8472",
"expected_behavior": {
"selected_tool": "payments_api",
"allowed_stop_reasons": ["completed", "tool_error_handled"],
},
"checks": ["tool_selection", "valid_output_schema"],
"tags": ["payments", "support", "partial-outage-risk"],
}
Un schéma clair enlève l'ambiguïté pendant l'analyse des cas problématiques.
2. Déduplication et filtrage du bruit
def is_duplicate(case, seen_signatures):
signature = f"{case['input']}|{case['expected_behavior']}"
return signature in seen_signatures
def is_noisy(case):
return len(case["input"].strip()) == 0
Un dataset plus petit mais stable vaut mieux qu'un grand ensemble rempli de doublons et de bruit.
3. Labellisation du comportement attendu
def validate_case(case):
required = ["id", "input", "expected_behavior", "checks"]
for key in required:
if key not in case:
raise ValueError(f"missing_field:{key}")
La labellisation doit être vérifiable : si l'attendu n'est pas testable, le cas n'est pas prêt pour le golden dataset.
4. Versionnement du dataset
dataset_version = "golden-v1.4"
metadata = {
"dataset_version": dataset_version,
"created_from": "incidents_2026_q1",
"notes": "added outage and tool-fallback cases",
}
Le dataset doit être versionné avec la même discipline que le code.
La comparaison entre candidate et baseline doit être liée à une version précise du dataset.
Modifier les cas sans nouvelle version du dataset revient en pratique à changer de jeu de tests.
5. Intégration avec eval harness
run_eval_suite(
agent=candidate_agent,
dataset_path="datasets/golden-v1.4.json",
baseline_report="reports/baseline-golden-v1.4.json",
)
Une même version du dataset doit être utilisée pour candidate et baseline, sinon le diff perd son sens.
Notes pour QA et l'automatisation
Les équipes QA construisent généralement des suites de régression automatisées sur golden dataset : un smoke set court pour chaque PR et un set de régression complet pour les runs planifiés.
Les tags de cas (payments, support, outage-risk) permettent de former ces sets de façon stable sans sélection manuelle et de localiser rapidement la classe de scénarios où une régression est apparue.
Erreurs typiques
Le dataset change entre les runs
Des cas sont ajoutés ou modifiés sans nouvelle version, donc les résultats de deux runs ne sont plus comparables.
Cause typique : absence de processus explicite de versionnement du dataset.
Uniquement des cas happy path
Le dataset couvre seulement des requêtes "propres" et n'inclut ni incidents ni edge cases.
Cause typique : les cas sont ajoutés manuellement sans analyse des traces production.
Labellisation floue de expected behavior
Les cas contiennent un input mais pas d'attendu vérifiable, donc les evaluators ne peuvent pas rendre un verdict fiable.
Cause typique : labellisation en texte libre sans schéma.
Conditions de run non figées
Même des tests corrects ne donnent pas des résultats comparables si le modèle, le runtime ou les dépendances externes changent entre runs.
Cause typique : alias de modèle, paramètres runtime flottants ou environnement instable.
Pas de tags de couverture
L'équipe ne voit pas quelles classes de risque sont déjà couvertes par le dataset et lesquelles restent vides.
Cause typique : cas stockés sans tags et sans regroupement par scénarios.
Cas instables dans le golden dataset
Le même cas passe puis échoue aléatoirement, ce qui pollue le signal de régression.
Cause typique : dépendances externes instables ou runtime partiellement non contrôlé.
En bref
- Golden dataset rend les eval runs reproductibles.
- Un cas sans schéma clair ni comportement attendu ne doit pas entrer dans le golden dataset.
- La version du dataset doit être identique pour
candidateetbaseline. - Les meilleurs cas viennent des incidents production et des edge cases.
FAQ
Q : Quelle différence entre un golden dataset et un jeu de tests classique ?
R : C'est une base de cas stable et versionnée, utilisée pour comparer le comportement de l'agent entre versions.
Q : À quelle fréquence mettre à jour le golden dataset ?
R : En général via des versions séparées après accumulation de nouveaux incidents ou scénarios importants, pas avant chaque petite release.
Q : Peut-on inclure des cas synthétiques ?
R : Oui, mais la base doit reposer sur des scénarios production réels. Les cas synthétiques complètent bien la couverture des edge cases.
Q : Que faire des cas instables ?
R : Soit stabiliser le runtime et les checks, soit retirer temporairement le cas du golden dataset jusqu'à normalisation des conditions de run.
Et ensuite
Après avoir construit le golden dataset, branchez-le sur Eval Harness, puis contrôlez les changements entre versions via Regression Testing.
Pour les incidents en environnement réel, ajoutez Replay and Debugging. Pour garder une vision complète, gardez Testing Strategy comme référence.