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, 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 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é.
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. 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.
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 à 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.
L’accompagnement Agenticiel pour 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. Agenticiel accompagne les PME et les éditeurs qui veulent un RAG fiable, en commençant par ce qui compte vraiment : l’état de leurs documents, pas le choix du modèle.
La méthode est directe. Nous regardons vos sources, nous mesurons leur qualité avec une jauge de questions de référence, et nous rendons un rapport clair : ce qui est propre, ce qui doit être nettoyé, ce que cela coûte. Ensuite, nous mettons en place le pipeline de nettoyage, d’indexation et d’évaluation, de façon à ce que chaque amélioration soit mesurable. Le travail est mené par une équipe de développeurs offshore francophones, basée à Madagascar, avec laquelle vous échangez directement dans votre langue et sur vos horaires. La sous-traitance de développement change le coût, pas la rigueur du résultat.
Notre approche consiste à sécuriser la base avant de toucher au modèle : on rend vos sources propres et mesurables, et le reste du système s’améliore ensuite tout seul.