Vous avez expédié un système RAG. Cela fonctionne... pour la plupart. Parfois, les réponses sont incroyablement bonnes. Parfois, il affirme avec assurance quelque chose de complètement faux, citant un document qui ne dit pas ce que le modèle prétend dire. Et parfois, la réponse passe complètement à côté, même si le bon document se trouve directement dans votre base de connaissances.
Il s’agit de l’état normal d’un système RAG de production. La question n’est pas de savoir si vous avez des problèmes de qualité – c’est vrai – mais si vous disposez d’un moyen systématique pour les trouver et les résoudre. C'est à cela que servent les rétrospectives RAG : examiner régulièrement où votre pipeline tombe en panne et apporter des améliorations ciblées au lieu de deviner.
Pourquoi les systèmes RAG ont besoin de leurs propres rétrospectives
RAG n'est pas un système. Il s'agit d'une chaîne de composants et la qualité de chaque maillon détermine le résultat final. Lorsque la réponse est mauvaise, l’échec peut survenir n’importe où :
- Ingestion : les documents ont été mal analysés, des morceaux ont été divisés aux mauvais endroits, les métadonnées ont été perdues
- Récupération : La requête de recherche ne correspondait pas aux bons documents, le modèle d'intégration a raté la connexion sémantique, votre top-K était trop petit ou trop grand
- Assemblage de contexte : les morceaux récupérés étaient pertinents individuellement mais se contredisaient, ou la fenêtre contextuelle était remplie de bruit
- Génération : Le modèle a halluciné malgré un bon contexte, ou il a ignoré le contexte pertinent au profit de sa connaissance paramétrique
Les rétrospectives logicielles standard ne sont pas équipées pour démêler ces modes de défaillance. Vous avez besoin d'un format qui retrace les mauvaises sorties tout au long du pipeline pour trouver le point de défaillance réel. Sinon, vous finissez par « réparer » la récupération lorsque le véritable problème était le regroupement, ou par réécrire les invites lorsque le véritable problème était la récupération.
Mesures à suivre
Avant de lancer une rétrospective RAG, vous avez besoin de données. Pas toutes les mesures possibles : juste assez pour diagnostiquer les modes de défaillance les plus courants.
Qualité de récupération
Precision@K : Parmi les K documents récupérés, combien étaient réellement pertinents ? Si vous retirez 10 morceaux et que seulement 2 sont utiles, vous inondez la fenêtre contextuelle de bruit.
Recall@K : Parmi tous les documents pertinents de votre base de connaissances, combien se sont retrouvés dans vos résultats top-K ? Un faible rappel signifie que les bonnes réponses existent mais que votre récupération ne parvient pas à les trouver.
MRR (Rang réciproque moyen) : Où apparaît le premier résultat pertinent dans votre classement ? Si le meilleur document est systématiquement en position 5 au lieu de la position 1, votre classement doit être amélioré même si le rappel est correct.
Vous n'avez pas besoin de les calculer sur l'ensemble de votre base de connaissances. Échantillonnez 50 à 100 requêtes récentes, demandez à un juge humain quels documents récupérés étaient pertinents et calculez à partir de là. Faites cela tous les mois.
Qualité de génération
Fidélité : La réponse générée reflète-t-elle réellement ce que disent les documents récupérés ? C’est la question des hallucinations. Vous pouvez vérifier cela en comparant les résultats au contexte fourni.
Pertinence de la réponse : La réponse répond-elle réellement à la question posée ? Il est possible de générer un résumé parfaitement fidèle des documents récupérés qui passe complètement à côté de l'intention de l'utilisateur.
Utilisation du contexte : Lorsque la bonne information est dans le contexte récupéré, le modèle l'utilise-t-il réellement ? Si vous récupérez systématiquement de bons documents et que le modèle les ignore, il s'agit d'un problème côté génération (généralement un problème d'incitation).
Mesures opérationnelles
Latence : Combien de temps prend le pipeline complet entre la requête et la réponse ? Décomposez cela par composant afin de savoir si la récupération ou la génération est le goulot d'étranglement.
Coût par requête : Suivez l'utilisation des jetons et les coûts de l'API. Certaines améliorations de la qualité (telles que l'agrandissement de la fenêtre contextuelle ou le reclassement) augmentent considérablement les coûts.
Organiser la rétrospective
Préparation (avant la réunion)
Désignez quelqu'un pour préparer un « échantillon d'échec » : 10 à 15 requêtes récentes dont le résultat était erroné ou de mauvaise qualité. Pour chacun d'entre eux, capturez l'état complet du pipeline : la requête d'origine, ce qui a été récupéré, quel contexte a été envoyé au modèle et ce que le modèle a généré. Cette trace est essentielle. Sans cela, vous déboguez à l'aveugle.
Préparez également vos tendances métriques. Les choses vont-elles mieux ou pire depuis la dernière rétro ? Des changements brusques ?
La réunion (60 minutes)
Révision des métriques (10 minutes). Parcourez les métriques de récupération et de génération. Concentrez-vous sur les tendances et les surprises, pas sur une récitation numéro par numéro. "Precision@5 est passé de 0,72 à 0,58 ce mois-ci" est utile. Lire chaque métrique d’un tableau de bord ne l’est pas.
Analyse des pannes (35 minutes). C'est le cœur du rétro. Prenez l'échantillon de défaillance et classez chacun selon l'endroit où le pipeline s'est rompu :
- Échec de récupération : Les bons documents n'ont pas été récupérés. Pourquoi? Incompatibilité entre la requête et le document ? Limite du modèle d’intégration ? Filtrage des métadonnées trop agressif ?
- Échec du regroupement : le bon document a été récupéré, mais les limites des fragments ont divisé la réponse en deux fragments et un seul a été renvoyé. Ou bien le morceau était trop volumineux et dilué avec un contenu non pertinent.
- Échec du contexte : de bons morceaux ont été récupérés, mais l'ordre ou la troncature de la fenêtre contextuelle a perdu les informations importantes. Ou des éléments contradictoires ont confondu le modèle.
- Échec de génération : Un bon contexte a été fourni, mais le modèle a quand même halluciné, ignoré le contexte ou donné une réponse vague au lieu de celle spécifique disponible dans les documents.
Pour chaque échec, demandez : « Quelle est la solution la moins chère qui aurait permis de détecter ou d’empêcher ce problème ? » Parfois, c'est une modification rapide. Parfois, il s'agit de regrouper un document spécifique. Il s'agit parfois d'un changement systémique.
Priorisation et éléments d'action (15 minutes). Regroupez les échecs par cause première. Le modèle qui a causé le plus d’échecs retient le plus l’attention. Choisissez 2-3 améliorations à mettre en œuvre avant la prochaine rétro.
Modèles de défaillance courants et correctifs
Voici les modèles que vous verrez le plus souvent et les approches pratiques pour chacun :
"Le bon document est dans notre base de connaissances mais la récupération le manque." Il s'agit généralement d'un problème de similarité d'intégration. La requête de l'utilisateur utilise un vocabulaire différent de celui du document source. Correctifs : ajoutez une étape d'expansion de la requête (réécrivez la requête de l'utilisateur en plusieurs formulations), implémentez une recherche hybride (combinez des intégrations sémantiques avec une correspondance de mots clés comme BM25) ou améliorez votre filtrage des métadonnées pour restreindre l'espace de recherche.
"Nous récupérons le bon document mais le mauvais morceau." Votre stratégie de segmentation est plus importante que la plupart des équipes ne le pensent. Si vous utilisez une segmentation de taille fixe (par exemple, 500 jetons), vous divisez presque certainement le contenu important au-delà des frontières. Correctifs : utilisez le regroupement sémantique (divisé en fonction des changements de sujet), ajoutez un chevauchement de fragments, essayez le regroupement hiérarchique où les fragments parents plus grands fournissent un contexte pour les fragments enfants plus petits.
"Le modèle ignore le bon contexte et invente les choses." Il s'agit d'un problème d'invite et de comportement du modèle. Les connaissances paramétriques du modèle entrent en conflit avec le contexte fourni et les connaissances paramétriques sont gagnantes. Correctifs : ajustez l'invite de votre système pour demander explicitement au modèle d'utiliser uniquement le contexte fourni, ajoutez une instruction "si le contexte ne contient pas la réponse, dites-le", envisagez de réduire la température du modèle.
"Les réponses sont correctes mais trop lentes." Les problèmes de latence proviennent généralement de l'un des trois endroits suivants : trop d'appels de récupération, une fenêtre contextuelle trop grande (plus de jetons = génération plus lente) ou des étapes de reclassement qui ajoutent du temps de traitement. Profilez votre pipeline composant par composant. Le correctif dépend de l'endroit où passe le temps.
"La qualité est incohérente – excellente pour certains sujets, terrible pour d'autres." Cela signifie généralement que certaines parties de votre base de connaissances sont mieux indexées que d'autres. Peut-être que certains documents ont été mal analysés ou que certains sujets ne sont pas suffisamment couverts. Cartographiez vos échecs par domaine thématique et vous trouverez les lacunes.
Construire une boucle d’amélioration continue
Les équipes RAG les plus efficaces traitent leur système comme un produit et non comme un projet. Ce n’est jamais « fait ». Chaque rétrospective devrait produire des améliorations progressives, et ces améliorations devraient être mesurables lors de la prochaine rétrospective.
Une cadence pratique :
- Weekly : Examen rapide des mesures de qualité automatisées (peut être asynchrone, il suffit de vérifier le tableau de bord)
- Bihebdomadaire ou mensuel : Rétrospective complète avec analyse des pannes
- Trimestriel : Décisions architecturales plus importantes : devrions-nous changer les modèles d'intégration, restructurer notre base de connaissances, adopter une nouvelle stratégie de segmentation ?
Conservez un document courant de ce que vous avez essayé et de son impact. L'optimisation RAG est itérative et non linéaire : vous revisiterez parfois des approches qui n'ont pas fonctionné auparavant, car le reste du pipeline a suffisamment changé pour qu'elles fonctionnent désormais.
Évitez le piège des objets brillants
Chaque semaine, un nouveau document ou cadre prétend résoudre la qualité RAG. Résistez à l’envie de réorganiser votre pipeline sur la base d’un article de blog. Au lieu de cela, utilisez vos données rétrospectives pour identifier votre plus gros problème de qualité et résoudre ce problème spécifique. La réponse réside peut-être dans un nouveau modèle de reclassement sophistiqué. Plus probablement, il s'agit de corriger la façon dont vous décomposez la documentation de votre produit.
Les équipes qui s’améliorent le plus rapidement ne sont pas celles qui utilisent l’architecture la plus sophistiquée. Ce sont eux qui ont la boucle de rétroaction la plus étroite entre « ce résultat était mauvais » et « voici précisément pourquoi, et voici ce que nous avons modifié ».
Essayez NextRetro gratuitement — Catégorisez les modèles de défaillance RAG avec des colonnes et votez sur les améliorations du pipeline à prioriser.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
