Évaluer un RAG sans dataset golden : ce qu'on fait à la place

L'évaluation rigoureuse d'un RAG suppose un dataset gold : des questions avec les réponses attendues, les chunks pertinents identifiés, annotés à la main. En pratique, constituer un tel dataset coûte cher en temps humain qualifié, et les clients n'ont généralement ni le budget ni la disponibilité pour le construire avant le premier déploiement.

On ne peut pas se passer d'évaluation. Voici ce qu'on fait à la place.

Ce que l'absence de dataset gold implique vraiment

Sans gold dataset, on ne peut pas mesurer précisément le recall (est-ce que le système retrouve tous les chunks pertinents ?) ni la précision de la réponse finale (est-ce que la réponse est exacte ?).

On peut mesurer des proxies. Ce sont des estimations, pas des vérités. L'enjeu est de choisir des proxies qui corrèlent réellement avec la qualité perçue par l'utilisateur, et d'être honnête sur ce qu'ils ne mesurent pas.

Méthode 1 : génération synthétique de questions-réponses avec Ragas

Ragas propose un module de génération de dataset synthétique. L'idée : passer les chunks du corpus à un LLM pour qu'il génère des questions auxquelles ces chunks répondent, puis mesurer si le RAG retrouve les bons chunks sur ces questions générées.

from ragas.testset import TestsetGenerator
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI, OpenAIEmbeddings

generator = TestsetGenerator(
    llm=LangchainLLMWrapper(ChatOpenAI(model="gpt-4o-mini")),
    embedding_model=OpenAIEmbeddings(model="text-embedding-3-small"),
)

# documents : liste de Document LangChain
testset = generator.generate_with_langchain_docs(
    documents=documents,
    testset_size=100,  # 100 questions synthétiques
)

Le résultat est un jeu de paires (question, chunk source, réponse attendue). On l'utilise pour mesurer le recall@k du retrieval, combien de fois le bon chunk source apparaît dans le top-k.

Limite critique : les questions générées tendent à correspondre très directement au texte du chunk source. Elles ne représentent pas les reformulations ambiguës des vrais utilisateurs. Les scores de recall sur ces questions synthétiques surestiment systématiquement les performances réelles. On l'utilise pour détecter des régressions entre versions, pas pour valider le niveau absolu de qualité.

Méthode 2 : métriques sans référence avec un LLM juge

Ragas propose plusieurs métriques calculables sans gold dataset :

• Faithfulness : la réponse est-elle entièrement supportée par les chunks retrieval ? Un LLM vérifie si chaque affirmation de la réponse est traçable dans les sources.
• Answer Relevancy : la réponse répond-elle à la question posée ? Mesuré par similarité entre la question originale et des questions que le LLM génère depuis la réponse.
• Context Precision : les chunks retrieval sont-ils pertinents pour la question ?

from ragas.metrics import faithfulness, answer_relevancy, context_precision
from ragas import evaluate
from datasets import Dataset

# dataset contient : question, answer, contexts, ground_truth (optionnel)
results = evaluate(
    dataset=Dataset.from_list(sample_records),
    metrics=[faithfulness, answer_relevancy, context_precision],
)
print(results)
# {'faithfulness': 0.84, 'answer_relevancy': 0.79, 'context_precision': 0.71}

Ces métriques sont des approximations. Faithfulness, par exemple, rate les hallucinations subtiles où la réponse est techniquement supportée par un chunk mais tire une conclusion erronée par raisonnement.

Méthode 3 : échantillonnage humain ciblé

On ne peut pas annoter tout le corpus, mais on peut annoter 30 à 50 requêtes représentatives. Ce petit jeu d'échantillons, annoté en 2 à 3 heures par un expert métier, sert de référence qualitative.

On sélectionne ces requêtes par stratégie :

• 10 requêtes "faciles" (terme exact présent dans le corpus)
• 10 requêtes "moyennes" (reformulation, synonymes)
• 10 requêtes "difficiles" (inférence, comparaison, requête multi-documents)
• 10 requêtes "hors corpus" (le système doit dire qu'il ne sait pas)

Sur ces 40 requêtes annotées manuellement, on mesure la précision des réponses en binaire (correct / incorrect). Ce benchmark minimal coûte peu et détecte les problèmes les plus flagrants avant le go-live.

Ce qu'on surveille en production

Une fois déployé, en l'absence de feedback utilisateur explicite (pas de bouton pouce haut/bas), on surveille des signaux indirects :

Score de similarité moyen du top-1. Si la moyenne glisse vers le bas sur une fenêtre glissante, le corpus ou les requêtes ont changé. Signal précoce de dérive.

Longueur des réponses. Les réponses très courtes ("Je n'ai pas trouvé d'information...") ou très longues (reformulation de tout le contexte sans synthèse) signalent souvent un retrieval défaillant.

Taux de réponses "je ne sais pas" si le prompt système inclut cette instruction. Un taux anormalement haut ou bas est suspect.

Ces métriques ne remplacent pas une évaluation de qualité, elles alertent sur des anomalies.

La limite qu'on ne contourne pas

Aucune de ces méthodes ne mesure ce qui compte le plus : est-ce que l'utilisateur obtient l'information qu'il cherchait ? Cette question nécessite du feedback humain en contexte réel.

Sur les projets où l'enjeu est élevé (décision médicale, conformité réglementaire, support client), on insiste pour qu'un mécanisme de feedback minimal soit intégré dès le lancement, même un simple binaire. Sans lui, on navigue à l'aveugle après quelques semaines.

La question ouverte : comment distinguer, dans les métriques de production, une baisse de qualité RAG d'une baisse de qualité des questions posées par les utilisateurs ?