RAG en production

Framework d'évaluation RAG : des métriques qui expliquent la qualité

Un framework RAG par couches couvrant datasets, retrieval, réponses sourcées, citations, opérations, décisions de release et feedback de production.

9 avril 20265 min de lectureÉvaluation RAGRAG

Tester un RAG avec quelques questions faciles et conclure que le résultat « semble bon » ne suffit pas pour une release. Une réponse finale peut être incorrecte parce que la source manque, que le parsing a détruit un tableau, que le retrieval a sélectionné le mauvais passage, que le modèle a ignoré une bonne preuve ou que la politique a autorisé une affirmation non sourcée. Un framework utile isole ces couches. Son objectif n'est pas de produire un score impressionnant, mais d'expliquer où la qualité a changé, rendre les releases comparables et transformer les échecs réels en cas reproductibles.

Construire le dataset autour des besoins d'information réels

Je commence par des questions représentatives des utilisateurs, et non uniquement par des variantes générées. Chaque exemple doit contenir :

la demande brute et le contexte utilisateur utile ;
le périmètre de sources et les contraintes d'accès ;
les documents ou passages requis ;
les éléments attendus dans la réponse ;
les affirmations interdites ;
le comportement acceptable de refus ou de clarification ;
les labels d'intention, difficulté, langue et risque.

Le snapshot des sources est important. Si les documents évoluent entre deux campagnes, la comparaison devient ambiguë. La version du dataset, du corpus, du parsing et du retrieval doit donc être reliée à chaque expérience. Les exemples synthétiques peuvent améliorer la couverture de situations rares, mais ils ne remplacent pas le vocabulaire réel, l'ambiguïté et les défauts documentaires. Je les utilise pour compléter un noyau fondé sur des demandes réelles, puis je vérifie leur plausibilité avec le métier.

Évaluer le retrieval avant la génération

L'évaluation du retrieval cherche à savoir si le système a trouvé les preuves utiles et les a classées assez haut pour la couche de réponse. Les métriques courantes incluent :

Recall at k : au moins une source requise apparaît-elle parmi les candidats ?
Precision at k : quelle part du contexte sélectionné est pertinente ?
MRR : à quelle position apparaît le premier résultat pertinent ?
nDCG : le classement complet respecte-t-il les niveaux de pertinence ?
justesse des filtres : accès, statut, langue et date ont-ils été appliqués ?

Le choix dépend du workflow. Une question exigeant un paragraphe précis d'une politique diffère d'une comparaison fondée sur plusieurs documents. Une pertinence au niveau du document peut également être trop grossière lorsque l'information se trouve dans une section unique. Les métriques doivent être accompagnées d'une revue des traces. Un chunk peut être jugé pertinent tout en ayant perdu le titre ou le tableau indispensable à son interprétation. À l'inverse, plusieurs passages différents peuvent soutenir la même réponse. L'évaluation doit accepter plusieurs jeux de preuves valides lorsque le domaine le permet.

Évaluer séparément réponses sourcées et citations

Une fois le retrieval compris, j'évalue :

Dimension	Question d'évaluation
Groundedness	Chaque affirmation importante est-elle soutenue par les preuves ?
Complétude	La réponse couvre-t-elle les points requis sans masquer l'incertitude ?
Validité des citations	Chaque citation vise-t-elle un passage accessible qui soutient l'affirmation ?
Politique	Le système a-t-il clarifié, refusé ou escaladé lorsque les preuves manquaient ?
Présentation	La réponse est-elle utilisable par le workflow et l'audience visés ?

Les contrôles déterministes couvrent l'existence des citations, l'accès aux sources, les champs requis et les sorties interdites. Des évaluateurs par grille peuvent aider sur l'ancrage factuel et la complétude, mais ils exigent des exemples calibrés, un versionnement et une revue humaine régulière. Un modèle juge reste un composant susceptible de dériver ou de se tromper.

Preuves associées à la version candidate

Transformer les métriques en décision fondée sur le risque

Il n'existe pas de seuil universel de groundedness ou de recall qui rende chaque RAG sûr. Une gate doit venir d'une baseline validée, de l'importance de chaque intention, du coût d'une mauvaise réponse et du bruit de l'évaluateur. J'utilise trois catégories :

Blocages stricts pour les défauts d'autorisation, citations inaccessibles, affirmations interdites et réponses critiques non sourcées.
Comparaisons segmentées pour les intentions, langues, familles de sources et questions difficiles.
Revue des tendances pour les mouvements de qualité, latence, coût, fallback et couverture qui exigent du contexte.

Chaque gate en échec doit pointer vers des exemples et des traces. L'équipe détermine ensuite si la cause vient du périmètre, de l'ingestion, du parsing, du retrieval, de la synthèse, de la politique ou de l'évaluateur. Mon étude de cas RAG Equity Research Agent illustre comment retrieval hybride, reranking, citations et synthèse multi-étapes créent plusieurs surfaces testables indépendamment. La politique d'évaluation d'un système réel doit toujours refléter ses propres utilisateurs et risques.

Fermer la boucle avec les preuves de production

L'évaluation offline protège les comportements connus. La production révèle de nouvelles formulations, des sources changeantes, des conditions d'accès et des pannes d'intégration. Les signaux utiles incluent feedback relié aux traces, reformulations, fallbacks, sources manquantes, citations invalides, corrections expertes, latence et coût par résultat réussi. Les exemples doivent être éditorialisés avant d'intégrer le jeu de régression. Les données sensibles sont protégées, les doublons consolidés et le comportement attendu revu. Le guide du RAG en production couvre l'architecture plus large d'ingestion, retrieval, observabilité et rollout qui produit ces signaux.

Modes d'échec, compromis et déploiement

L'évaluation peut créer une fausse confiance. Un dataset peut surreprésenter les questions simples. Les labels de pertinence peuvent être incomplets. Les moyennes masquent un segment critique. Un modèle juge peut favoriser les réponses longues ou partager les angles morts du système. Le feedback de production peut surreprésenter les utilisateurs les plus engagés. Je commence par un jeu limité et soigneusement relu sur les workflows à forte valeur. Les métriques de retrieval et contrôles déterministes arrivent en premier. Les grilles de groundedness et complétude sont calibrées sur des exemples humains. La suite informe d'abord la revue de release avant que les contrôles stables deviennent bloquants. Les échecs de production sont ajoutés avec leur cause racine. Le meilleur framework ne prétend pas qu'un score unique représente la qualité. Il conserve assez de contexte pour répondre à quatre questions : qu'est-ce qui a échoué, dans quel segment, dans quelle couche et quelle preuve valide la correction ?

Sources et références

Documentation RAGASConcepts d'évaluation du contexte récupéré, de la génération sourcée et des expérimentations
Documentation LangSmith sur l'évaluationDatasets, expériences, évaluateurs, comparaisons et revue des traces

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Voir les études de cas Consulter mon CV

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.

28 mars 20265 min de lectureRAGGénération augmentée par recherche