Guide

Statut éditorial : En attente de relecture

Construire un jeu de tests pour évaluer un RAG

Créer un dataset représentatif qui sépare retrieval, génération et exigences métier afin de comparer les évolutions du RAG.

Classification du contenu

Types

  • Observabilité et évaluation
Niveau
Avancé
Publié le
24 août 2026
Dernière relecture
Relecture en attente
Prochaine vérification
24 novembre 2026

Un jeu de tests RAG ne se limite pas à une liste de questions avec des réponses rédigées. Pour diagnostiquer le système, il doit aussi indiquer quelles sources sont pertinentes, quels éléments sont obligatoires et quand le système devrait refuser de répondre.

Définir l’unité d’évaluation

Pour chaque cas, conservez question, contexte utilisateur, documents ou fragments attendus, critères de réponse, réponse de référence éventuelle et métadonnées de segmentation. Utilisez des identifiants de sources stables plutôt que de longues copies susceptibles de diverger.

Représenter le trafic réel

Échantillonnez les demandes de production après nettoyage, puis complétez avec synonymes, fautes, questions multi-parties, dates, tableaux et documents similaires. Incluez des cas sans réponse, des sources contradictoires et des utilisateurs sans autorisation. Équilibrez les catégories pour qu’un grand volume de questions faciles ne masque pas un segment critique.

Séparer retrieval et génération

Le premier score vérifie si les bons passages sont récupérés et bien classés. Le second juge fidélité au contexte, pertinence, citations, format et règles métier. Cette séparation indique si l’amélioration doit porter sur chunking, embedding, filtres, reranking, prompt ou modèle.

Contrôler la qualité du dataset

Faites relire un échantillon par deux personnes et discutez les désaccords. Versionnez les sources et marquez les cas devenus obsolètes. Gardez un ensemble final non utilisé pendant les réglages. Les exemples synthétiques accélèrent la couverture, mais ne remplacent pas les formulations et erreurs réelles.

FAQ

Combien de cas faut-il ?

Commencez avec quelques dizaines couvrant les risques, puis enrichissez avec les incidents.

Peut-on utiliser un LLM pour annoter ?

Oui pour aider, mais calibrez-le sur une revue humaine et inspectez les cas limites.

Quand exécuter les tests ?

À chaque changement de documents, chunking, embedding, retriever, prompt ou modèle.

Format JSONL et test de non-régression

~~~json {"id":"auth-01","question":"Quand expire le jeton ?","reference":"Après 30 minutes.","required_sources":["auth.md"],"tags":["critique","auth"]} {"id":"billing-01","question":"Comment télécharger une facture ?","reference":"Depuis Facturation > Documents.","required_sources":["billing.md"],"tags":["facturation"]} ~~~

~~~python import json

cases = [json.loads(line) for line in open("evals/rag.jsonl")] for case in cases: output = rag(case["question"]) assert set(case["required_sources"]) <= set(output.source_ids) if "critique" in case["tags"]: assert output.answer ~~~

Mélangez questions courantes, ambiguïtés, absence de réponse, documents contradictoires et contrôles d’accès. Versionnez corpus et tests ensemble. En CI, exécutez un sous-ensemble rapide ; lancez l’évaluation LLM complète de façon planifiée avec un budget explicite.

Sources utilisées