Tester le RAG : récupération vs génération
Le RAG alimente le modèle avec des documents, puis lui demande de répondre à partir d'eux. Il échoue à deux endroits complètement différents — et appeler les deux « l'IA a tort » est l'erreur qui fait mal-attribuer des bugs pendant des semaines.
Deux étapes, deux bugs
- La récupération a rapporté les mauvais documents — la bonne réponse n'était jamais devant le modèle. Corriger le prompt ne fait rien ; la recherche est cassée.
- La génération a eu les bons documents et a quand même mal répondu — les a ignorés, mélangés, ou a inventé quelque chose. La recherche va bien ; le modèle n'est pas ancré.
Même symptôme visible — une mauvaise réponse — correctifs opposés. Chaque test RAG doit dire quelle étape a échoué, ou le bug va à la mauvaise équipe.
Notez-les séparément
- Récupération : les morceaux récupérés contenaient-ils la réponse ? (Le document connu-correct a-t-il atteint le top-k ?)
- Fidélité : chaque affirmation de la réponse est-elle soutenue par les morceaux récupérés — rien d'ajouté ? C'est la vérification anti-hallucination.
- Pertinence de la réponse : répond-elle réellement à la question, pas juste citer le contexte à l'utilisateur ?
▸ The two-question test
chunks = retrieve(question)
answer = generate(question, chunks)
# stage 1 — retrieval
assert known_answer_doc in chunks # was the answer even available?
# stage 2 — generation, given those chunks
assert judge(answer, chunks,
"every claim is supported by the chunks, nothing invented")Basé sur les pratiques publiées d'évaluation RAG (métriques de récupération et de fidélité)
Toutes les leçons de Tester les fonctionnalités IA : évals, RAG & hallucinations
- On ne peut pas assertEqual un LLM
- Golden sets et évals hors-ligne
- Tester le RAG : récupération vs génération
- Mesurer l'hallucination
- Test adverse : jailbreaks et injection
- Garde-fous, CI, et la réponse d'entretien