RAG : pourquoi la qualité des sources prime sur le modèle

Quand un système de génération augmentée par recherche, le RAG, renvoie des réponses médiocres, le premier réflexe est presque toujours le même : changer de modèle. On passe d’un modèle plus petit à un plus gros, d’un Mistral Small à GPT ou Claude par exemple, on attend une réponse plus juste, et on est déçu. Le problème n’est presque jamais le modèle. Il est dans ce que le système a trouvé avant même de générer une réponse.

Le RAG fonctionne en deux temps. D’abord, il recherche des passages dans une base de documents, puis il confie ces passages à un modèle de langage qui rédige la réponse. Si les passages récupérés sont faux, incomplets ou hors sujet, le meilleur modèle du monde rédigera une réponse fausse, incomplète ou hors sujet, avec une assurance parfaite. La qualité du résultat est plafonnée par la qualité de ce qui entre dans le contexte.

Cet article défend une idée simple et opérationnelle : avant de comparer des modèles, il faut comparer des sources. Vous y trouverez une définition concrète de ce qu’est une source de qualité, la liste des traitements qui la rendent exploitable, et une façon de mesurer la qualité en amont pour ne plus raisonner à l’aveugle.

Le modèle ne corrige pas une source fausse

Beaucoup d’équipes croient qu’un modèle plus puissant va compenser des sources médiocres. C’est une erreur qui coûte cher, au sens propre : les modèles les plus gros sont aussi les plus onéreux, et ils ne réparent rien. Un modèle ne peut pas savoir qu’une fiche produit contient un prix périmé si le document indexé affiche encore l’ancien prix. Il répétera l’erreur en la présentant comme certaine.

Prenons un exemple concret. Une équipe de support client construit un RAG sur sa documentation interne. Les premières réponses citent des procédures obsolètes, parce que les anciennes versions des pages n’ont jamais été retirées de l’index. L’équipe remplace le modèle par un modèle deux fois plus cher. Les réponses restent fausses, elles sont simplement mieux formulées. Le correctif réel a été de purger les versions obsolètes et de dater chaque document. Le coût est tombé, la justesse est montée.

Ce qu’il faut retenir : le modèle transforme, il ne vérifie pas. Il n’a pas accès à la vérité, seulement au contexte qu’on lui donne. Si le contexte est contaminé, la réponse le sera. La première ligne de défense d’un RAG n’est donc pas le modèle, c’est la politique d’indexation.

Ce que recouvre la qualité d’une source

Une source de qualité, ce n’est pas seulement un texte bien écrit. C’est un ensemble de propriétés mesurables : l’exactitude des faits, la fraîcheur de l’information, l’absence de doublons, la structure interne du document et la présence de métadonnées exploitables. Chacune de ces propriétés a un effet direct sur ce que le système retrouve et sur ce qu’il peut en faire.

L’exactitude est la propriété la plus évidente, mais pas la seule qui compte. Un document exact mais non daté est presque inutilisable pour une question sensible au temps, comme un tarif ou une disponibilité. Un document exact mais dupliqué vingt fois dans l’index va noyer la réponse dans des variantes qui se contredisent à la marge. Un document exact mais sans titre ni section sera mal découpé en passages et perdra du sens au moment du découpage en passages (chunking).

La qualité se joue donc à plusieurs niveaux qui se renforcent : le contenu lui-même, son cycle de vie, et sa représentation dans la base vectorielle. Négliger l’un des trois, c’est gaspiller les efforts faits sur les deux autres.

Le nettoyage avant l’indexation

Le moment le plus rentable pour intervenir n’est pas après coup, c’est avant l’indexation. Nettoyer les sources en amont coûte moins cher que de corriger des réponses en aval, et c’est là que les gains sont les plus massifs. Le nettoyage recouvre au minimum trois gestes : dédupliquer, normaliser, et retirer ce qui n’a pas vocation à être interrogé. Il commence par une extraction propre : sur des PDF ou des fichiers Office, Docling ou Unstructured conservent titres, listes et tableaux, là où un simple copier-coller du texte les détruit.

La déduplication est souvent le gain le plus rapide. Deux documents qui disent la même chose avec de légères variations produisent des passages concurrents qui tirent la réponse vers le flou. Un contrôle simple, par empreinte de contenu ou par similarité, élimine ce bruit en quelques heures de travail. La normalisation consiste à harmoniser les formats : dates, unités, sigles. Un index où la même donnée apparaît sous trois formats ne retrouve jamais rien de fiable.

Enfin, il faut avoir le courage de retirer ce qui ne sert pas. Les brouillons, les notes internes, les anciens supports de formation : tout ce qui n’est pas la référence à jour perturbe la recherche. Sur un SharePoint, un Google Drive ou un espace Notion, cela revient souvent à choisir les dossiers indexés plutôt qu’à tout brancher. Un index plus petit et plus propre donne de meilleurs résultats qu’un index exhaustif et bruité.

La fraîcheur et la structure comptent autant que le texte

Deux propriétés sont systématiquement sous-estimées : la fraîcheur et la structure. La fraîcheur, parce qu’une information périmée est pire qu’une information absente. La structure, parce qu’un document mal structuré résiste au découpage en passages et perd son sens.

Pour la fraîcheur, la règle simple est de dater chaque document et de poser une date d’expiration ou de revue. Une fiche de prix, une politique de remboursement, une disponibilité produit : ces contenus doivent être retirés ou mis à jour à une date connue, pas découverts trop tard. L’organisation de ces mises à jour est détaillée dans notre article sur la mise à jour des sources d’un RAG.

Pour la structure, il faut produire des documents pensés pour être découpés : des titres de section explicites, des paragraphes courts, des tableaux là où une liste suffit. Un document bien structuré se découpe en passages autonomes qui gardent leur sens une fois isolés. C’est la condition pour que la recherche retrouve la bonne section au lieu d’un fragment illisible.

Mesurer la qualité en amont, pas après coup

On ne gère bien que ce qu’on mesure. Pour la qualité des sources, cela signifie construire un petit jeu de questions de référence, avec les réponses attendues, avant de brancher quoi que ce soit. Ce jeu sert ensuite de jauge : on l’exécute, à la main ou avec un outil comme Ragas, à chaque changement de source ou de paramètre, et on regarde si le taux de réponses correctes monte ou descend.

Cette jauge ne demande rien de sophistiqué. Une trentaine de questions réelles, posées par de vrais utilisateurs ou extraites des tickets de support, suffit largement à révéler les documents manquants, les doublons, les passages mal découpés. Le résultat se lit en deux chiffres : combien de questions trouvent la bonne source, et combien de réponses finales sont justes.

L’avantage de cette approche est qu’elle rend les décisions objectives. Changer de modèle de langage, changer de modèle d’embedding, changer de découpage : chaque choix se juge sur la jauge, pas sur une impression.

La fiabilité d’un RAG commence en amont, à la saisie : comment tenir la saisie et le contrôle des données sans laisser d’erreurs passer.

En pratique : reprendre vos données en main

Améliorer la qualité des sources est un travail d’ingénierie de données autant qu’un travail d’IA, et c’est un chantier que peu d’équipes mènent seules jusqu’au bout, notamment parce qu’il touche à des documents qui appartiennent à plusieurs services.

La méthode est directe : on regarde vos sources, on mesure leur qualité avec une jauge de questions de référence, et on rend un diagnostic clair (ce qui est propre, ce qui doit être nettoyé, ce que ça coûte). On met ensuite en place le pipeline de nettoyage, d’indexation et d’évaluation, pour que chaque amélioration soit mesurée plutôt que supposée.

Avant de payer un modèle plus gros, il vaut presque toujours mieux regarder ce qu’il reçoit en entrée. Si votre RAG répond mal malgré un bon modèle, c’est le point de départ de nos projets de chatbot RAG. Et si ces documents contiennent des données clients ou confidentielles, la question de l’hébergement se traite en parallèle, avec une approche d’IA souveraine.