Aller au contenu

Améliorer un RAG, avant et après la mise en production

On améliore un RAG en mesurant, pas en empilant des outils. La bonne démarche tient dans une boucle. On construit un jeu d'évaluation avant la mise en production, on mesure séparément le retrieval et la génération, on analyse les erreurs une par une, puis on corrige le composant fautif et on recommence. En production, on prolonge cette même boucle sur les vraies requêtes. Le reste de cet article détaille chaque étape, avant et après la prod, de façon scalable.

Article mis à jour le 12 juillet 2026.

La course aux outils est une fausse bonne idée

Face à un RAG qui répond mal, le premier réflexe est souvent d'ajouter une brique. Un nouveau modèle d'embedding, un reranker, un autre framework. C'est presque toujours prématuré.

L'écosystème pousse à ça. Chaque outil promet un gain, chacun ajoute une couche. Mais tant qu'on n'a pas identifié quelle étape défaille, empiler ne fait qu'ajouter de la complexité et brouiller le diagnostic.

L'approche qui paie repose moins sur l'accumulation de briques que sur une analyse rigoureuse des erreurs et une amélioration continue de l'existant. C'est plus lent à admettre, c'est beaucoup plus rapide à corriger.

D'où vient une mauvaise réponse de RAG

Quand un RAG donne une mauvaise réponse, la cause se cache dans un petit nombre d'endroits. Les repérer avant de coder évite de corriger au hasard.

Quatre points de rupture reviennent le plus souvent.

  • Le LLM lui-même. Le modèle hallucine, il invente une information absente des chunks récupérés.
  • La récupération (retrieve). Les bons documents ne remontent pas. Le problème vient du modèle d'embedding, de la requête de recherche ou de l'indexation.
  • Le découpage (chunking). Le bon document est là mais l'information est coupée au mauvais endroit, ou le contexte manque autour.
  • Les données sources. L'information n'est tout simplement pas dans la base. Fréquent quand le RAG couvre un périmètre plus large que les documents ingérés.

Ajouter un outil sans savoir lequel de ces quatre points lâche, c'est corriger à l'aveugle. Je décortique ces causes avec des cas chiffrés dans les 4 causes techniques d'échec d'un RAG.

Hamel Husain place lui aussi l'analyse d'erreur au tout début de sa méthode, comprendre ses modes d'échec avant même d'envisager de changer de modèle (Hamel Husain, LLM Evals FAQ). J'ai appliqué cette logique en mission, elle évite des semaines perdues à optimiser le mauvais composant.

Comment savoir si on s'améliore vraiment ?

C'est la question qu'on pose rarement. On change une taille de chunk, un modèle d'embedding, on regarde deux ou trois exemples, ça semble mieux, on valide. Mauvaise méthode.

Sans jeu de test fixe, chaque changement est une supposition. La bonne approche tient en trois gestes.

D'abord, constituer un jeu de test fixe de 30 à 50 paires question/réponse attendue. Ce jeu ne bouge plus, c'est la baseline. Ensuite, mesurer les métriques avant et après chaque modification. Enfin, décider avec des chiffres, pas avec des impressions.

Il faut mesurer deux choses distinctes, dans cet ordre. Le retrieval d'abord, la génération ensuite. Un score de génération élevé ne dit rien si on ignore si les chunks récupérés étaient les bons.

Côté génération, trois métriques suffisent pour démarrer.

Faithfulness (fidélité) La réponse reste-t-elle fidèle aux chunks récupérés, sans aller au-delà de ce qu'ils contiennent. C'est la métrique principale contre les hallucinations.

Answer Relevancy (pertinence) La réponse répond-elle à la question posée. Un modèle peut être fidèle aux sources et répondre à côté.

Context Precision (précision du contexte) Les chunks récupérés sont-ils tous utiles. Si on en récupère cinq dont trois inutiles, le retrieval a un problème de précision.

Côté retrieval, on regarde le recall@k, qui vérifie que le bon chunk est bien dans les k récupérés, et le MRR, qui mesure à quelle position il ressort. Je détaille toutes ces métriques et leur calcul dans évaluer un RAG en production avec RAGAS. Des outils comme RAGAS les calculent automatiquement, en s'appuyant eux-mêmes sur un LLM juge.

Avant la prod, générer un jeu d'évaluation à la chaîne

Le jeu d'évaluation ne demande plus des semaines d'annotation. On le génère à partir de ses propres documents en faisant travailler un LLM, ce qui rend la démarche scalable.

Le procédé est simple. On prend les documents, on les fait passer dans un LLM indépendant du RAG, avec une sortie structurée, et on lui demande d'extraire des paires question/réponse pertinentes. Un modèle rapide et peu cher comme Gemini 3 Flash fait très bien ce travail, c'est ce que j'utilise en pratique. La sortie structurée garantit un format exploitable directement, sans reparser du texte libre.

On passe ensuite chaque question dans le RAG à tester, on récupère la réponse générée, et on la fait noter par un ou plusieurs LLM juges sur des critères précis. Est-ce que la réponse est complète, est-ce qu'il manque des informations, est-elle fidèle aux chunks. Faire voter plusieurs juges réduit le bruit d'un juge unique.

Je ne réexplique pas ici les deux briques en détail, elles ont leur propre article. La génération du golden dataset est couverte dans construire un dataset d'évaluation RAG, et le choix du juge, son coût réel et ses biais dans LLM juge, quand l'utiliser.

Cette idée de générer des questions synthétiques par chunk pour tester le retrieval et calculer precision et recall est au cœur du RAG flywheel de Jason Liu (Jason Liu, Systematically Improving Your RAG). J'ai repris cette mécanique sur plusieurs projets, elle transforme une évaluation qu'on repoussait toujours en une étape de routine.

Soyons honnête, un jeu synthétique couvre bien la structure de vos documents, il ne couvre pas les vraies formulations tordues de vos utilisateurs ni les questions hors périmètre. Il faut donc en faire valider un échantillon par un expert métier, et le compléter plus tard avec les questions réelles de production.

En production, mesurer sur les vraies requêtes

Un jeu d'évaluation offline est une photo. En production, le RAG dérive, les documents changent, les usages évoluent, et un score mesuré il y a trois mois ne dit rien de l'état du système aujourd'hui.

Le prolongement de la boucle, c'est de logger ce qui sort réellement du système. Et là, un détail technique fausse la mesure du retrieval si on ne le connaît pas. Dans un RAG conversationnel, ce n'est pas le message brut de l'utilisateur qui va chercher les chunks. La question de suivi est d'abord réécrite par un LLM en une requête autonome à partir de l'historique, ce qu'on appelle une requête standalone. C'est cette requête réécrite qui interroge la base vectorielle.

Donc c'est elle qu'il faut logger, pas le message d'origine. Concrètement, on trace pour chaque appel la requête standalone envoyée à la base, les chunks récupérés, leurs scores et surtout leur position. Avec ça, on calcule en ligne les mêmes métriques qu'en offline, le bon chunk est-il présent et à quelle place, avec la logique du recall et de la précision, mais sur du trafic réel.

En parallèle, on applique un LLM juge sur un échantillon des vraies requêtes, de façon asynchrone pour ne pas peser sur la latence. Le coût reste marginal, je le chiffre dans l'article sur l'évaluation RAG en production. On y ajoute les signaux utilisateurs, pouce haut ou bas, taux de reformulation de la question, escalade vers un humain.

Le dataset d'évaluation devient alors vivant. Les questions qui remontent des logs enrichissent le jeu de référence, qui reflète de mieux en mieux les vrais usages. C'est exactement l'idée de flywheel de Jason Liu, une boucle de données qui s'améliore toute seule à mesure qu'elle tourne (Jason Liu, The RAG Playbook). Il rapporte par exemple des gains de 20 à 40 % en affinant les embeddings sur ces retours, un chiffre à prendre comme une estimation issue de sa pratique, pas comme une loi générale.

Corriger à la source, puis boucler

Une fois la cause identifiée, la correction devient ciblée et surtout mesurable. On ne change qu'une chose à la fois, et on la valide sur la baseline avant de la garder.

Selon le composant fautif, le levier change.

La boucle complète, avant et après la prod, ressemble à ceci.

graph LR
    A["Documents"] --> B["LLM générateur\n(sortie structurée)"]
    B --> C["Jeu question/réponse"]
    C --> D["RAG à tester"]
    D --> E["LLM juge\n(complétude, fidélité)"]
    E --> F["Score baseline"]
    F --> G["Correction ciblée\nd'un composant"]
    G --> D
    H["Trafic réel"] --> I["Logs requête standalone\n+ chunks + position"]
    I --> J["Métriques retrieval en ligne"]
    J --> C

    style A fill:#fef3c7,stroke:#d97706,color:#000
    style D fill:#bbf7d0,stroke:#16a34a,color:#000
    style H fill:#e0e7ff,stroke:#4338ca,color:#000
    style G fill:#fce7f3,stroke:#db2777,color:#000

Un dernier levier souvent sous-estimé, l'UX du produit. Une simple reformulation de la question de feedback peut multiplier le volume de retours par cinq, et les clics sur les sources jugées non pertinentes fournissent des hard negatives directement réutilisables pour un reranker. Je détaille ces patterns dans UX d'un produit IA, 5 patterns qui multiplient le feedback. Pour voir la méthode appliquée bout en bout sur un cas réel, lisez comment un RAG multi-sources a été optimisé pour la rédaction d'appels d'offres BTP.

La méthode en une boucle

Améliorer un RAG n'a rien d'un coup de génie technique, c'est une discipline de mesure. On évalue avec un jeu de test fixe, on analyse la cause racine de chaque erreur, on corrige un composant à la fois, on remesure, et on prolonge la boucle en production sur les vraies requêtes.

Le reste, les outils, les frameworks, les dernières techniques à la mode, ne vient qu'après, et seulement quand un chiffre montre qu'on en a besoin. C'est moins spectaculaire qu'une nouvelle brique, c'est ce qui fait la différence entre un RAG qui plafonne et un RAG qui progresse.

Questions fréquentes sur l'amélioration d'un RAG

Comment améliorer un RAG concrètement ? En mesurant plutôt qu'en empilant des outils. On construit un jeu de test fixe de 30 à 50 paires question/réponse, on mesure séparément le retrieval et la génération, on analyse la cause racine de chaque erreur, puis on corrige le composant fautif et on recommence. En production, on prolonge cette boucle sur les vraies requêtes.

Faut-il ajouter des outils pour améliorer un RAG ? Rarement en premier. Ajouter un reranker ou un nouveau modèle d'embedding avant d'avoir identifié quelle étape échoue revient à corriger au hasard. On gagne le droit de complexifier une fois qu'on a mesuré où est le vrai problème.

Comment générer un jeu d'évaluation pour un RAG ? On le génère depuis ses propres documents. On parcourt les chunks et on demande à un LLM indépendant, avec une sortie structurée, de produire une paire question/réponse attendue par chunk. Un modèle rapide comme Gemini 3 Flash suffit. En quelques minutes et pour moins d'un euro sur quelques centaines de chunks, on a un golden dataset, qu'on fait valider par un expert métier sur un échantillon.

Comment mesurer la qualité du retrieval d'un RAG ? Avec le recall@k, qui vérifie que le bon chunk est dans les k récupérés, et le MRR, qui mesure sa position. On commence toujours par le retrieval, car un score de fidélité élevé ne veut rien dire si on ignore si les chunks récupérés étaient les bons.

Pourquoi logger la requête réécrite plutôt que le message utilisateur ? Parce que ce n'est pas le message brut qui va chercher les chunks. Dans un RAG conversationnel, la question de suivi est réécrite par un LLM en requête autonome à partir de l'historique, et c'est cette requête réécrite qui interroge la base vectorielle. Pour mesurer le retrieval en production, c'est elle qu'il faut logger, avec les chunks et leur position.

Si mes articles vous intéressent et que vous avez des questions ou simplement envie d'échanger sur vos propres défis RAG, écrivez-moi à anas@tensoria.fr. Vous pouvez aussi réserver un créneau d'échange ou vous abonner à ma newsletter :)

À propos de moi

Je suis Anas Rabhi, consultant Data Scientist freelance. J'accompagne les entreprises dans leur stratégie et mise en œuvre de solutions d'IA (RAG, Agents, NLP).

Découvrez mes services sur tensoria.fr ou testez notre solution d'agents IA heeya.fr.