Un système RAG qui répond faux est le symptôme le plus frustrant qui soit : le document est dans la base, la question est claire, et pourtant la réponse est à côté, ou pire, affirmée avec assurance. Le réflexe consiste alors à changer de modèle, comme si la justesse dépendait de la taille du LLM. Dans la majorité des cas, le modèle n’est pas le coupable : la chaîne en amont, du découpage des documents à la sélection des passages, a introduit l’erreur bien avant la génération.
Chaque maillon du pipeline peut produire une réponse fausse : un découpage qui casse l’information, une recherche qui remonte le mauvais passage, un contexte trop chargé qui noie la bonne source, des documents qui se contredisent sans règle de priorité, une réponse jamais vérifiée contre sa source. Ces erreurs se cumulent et se masquent : la recherche renvoie un mauvais passage, le modèle compose une réponse plausible, et personne ne le remarque tant qu’un utilisateur ne se plaint pas.
La bonne nouvelle, c’est que ces erreurs sont identifiables et corrigeables une par une. Cet article passe en revue les six plus classiques, avec pour chacune le symptôme, la cause et le correctif. Vous pouvez les vérifier sur votre propre système, la plupart avec une dizaine de questions ciblées et quelques minutes de lecture de logs.
Un découpage qui coupe l’information en deux
Le chunking, ou découpage des documents en passages, est la première source d’erreur d’un RAG. Si un passage sur les conditions de remboursement est coupé au milieu d’une phrase, ou si le montant maximal est dans un morceau et les conditions d’application dans un autre, la recherche ne retrouvera jamais l’information complète. Le symptôme typique : la réponse cite bien un chiffre, mais rate la condition qui s’y applique, et l’utilisateur agit sur une information incomplète.
La cause est presque toujours un découpage par nombre fixe de caractères, qui ignore les paragraphes et les titres. Le correctif est simple : découper par sections sémantiques, en respectant la structure du document, avec si besoin un chevauchement minimal. Vérifiez avec une dizaine de questions dont la réponse dépend de deux passages distincts : si une seule échoue, votre découpage casse l’information quelque part.
Une recherche qui ne trouve pas le bon passage
La recherche vectorielle compare des représentations numériques du texte, pas les mots exacts. Si l’index a été construit avec un modèle d’embedding différent de celui utilisé à l’interrogation, ou si la question emploie des termes que le document ne contient pas (synonymes, jargon métier), le passage pertinent peut ne jamais remonter dans les résultats. Symptôme : le système répond « je n’ai pas trouvé cette information » alors que le document existe et contient la réponse.
Vérifiez d’abord la cohérence entre l’indexation et l’interrogation : le même modèle, la même version, la même normalisation du texte. Ensuite, testez une recherche hybride, qui combine la recherche lexicale classique et la recherche vectorielle : elle rattrape les cas où le mot exact est présent et les cas où il ne l’est pas. Enfin, mesurez le recall sur vos vraies questions, pas sur des questions inventées.
Un contexte trop chargé qui noie la bonne source
Plus le modèle reçoit de passages, plus il a de chances de s’appuyer sur le mauvais. Un top-k fixé à huit ou dix passages « au cas où » remplit le contexte de bruit : le passage pertinent est noyé parmi des passages voisins, similaires ou hors sujet, et le LLM n’a aucun moyen fiable de départager. Il compose alors une réponse qui mélange deux sujets, ou qui s’appuie sur un passage secondaire au détriment du passage décisif.
La correction passe par trois gestes. Réduisez le nombre de passages transmis au modèle, en ne gardant que l’essentiel. Ajoutez une étape de re-ranking, qui réordonne les résultats par pertinence avant la génération. Et filtrez par métadonnées : type de document, date, langue, périmètre. Un passage hors périmètre écarté avant d’atteindre le contexte ne peut plus faire de dégât.
Des documents qui se contredisent, sans règle de priorité
Deux versions d’une même procédure, un tarif mis à jour et l’ancien encore dans l’index, une brochure générale et une note de service plus récente : le RAG remonte les passages concurrents et le modèle tranche au hasard, souvent vers l’ordre de l’index plutôt que vers la version la plus à jour. Symptôme : la réponse change selon les jours, ou donne une information périmée avec la même assurance que la bonne.
La cause est l’absence de gestion des versions et de métadonnées de date. Le correctif : dater chaque document à l’indexation, utiliser cette date dans la recherche pour filtrer ou pondérer, et définir une règle de priorité explicite, par exemple « la version la plus récente fait foi ». Une règle simple et appliquée systématiquement vaut mieux qu’un modèle qui doit deviner quelle source domine.
Une réponse jamais vérifiée contre sa source
Un LLM peut générer une phrase grammaticalement parfaite, appuyée sur un passage retrouvé, et pourtant infidèle : elle avance un chiffre absent de la source, généralise un cas particulier, ou conclut ce que le passage ne dit pas. Sans étape de vérification, cette réponse part en production, fluide et crédible, et l’erreur est repérée par l’utilisateur, pas par vous.
Le correctif est une vérification de fidélité avant l’envoi : un second appel au modèle liste les affirmations de la réponse, puis vérifie chacune contre les passages retrouvés. Ce n’est pas infaillible, mais cela détecte les réponses décrochées et permet d’afficher une mention « réponse partiellement étayée » au lieu de livrer une erreur avec assurance. Couplée à une relecture humaine hebdomadaire, cette vérification transforme un bug silencieux en problème visible et corrigeable.
Aucune évaluation en conditions réelles
La sixième erreur est méthodologique : on teste le RAG avec trois questions inventées, on regarde deux réponses qui semblent bonnes, et on part en production sans avoir jamais mesuré quoi que ce soit. Les démos passent, les usages réels échouent : les vraies questions sont plus longues, plus ambiguës, elles mélangent plusieurs sujets et emploient le jargon du métier que le jeu de test ne contenait pas.
Le correctif tient en deux étapes. Construisez un jeu de référence d’une trentaine de questions relevées dans les demandes réelles, avec pour chacune la réponse attendue et les passages qui devraient être retrouvés. Puis suivez en production deux indicateurs simples : la proportion de réponses reformulées par l’utilisateur, qui signale presque toujours une réponse insatisfaisante, et la fidélité des réponses sur le jeu de référence à chaque modification du pipeline. Sans ces mesures, vous corrigez un RAG à l’aveugle ; avec elles, chaque correctif se valide par une différence mesurable.
L’accompagnement Agenticiel pour fiabiliser votre RAG
Ces six erreurs se corrigent avec de la méthode, mais l’œil extérieur fait gagner des semaines : un développeur qui n’a pas écrit le pipeline ne part pas du principe qu’il fonctionne, il mesure. Nos développeurs offshore francophones à Madagascar reprennent votre RAG existant, identifient le maillon fautif parmi ces six erreurs, appliquent le correctif et mettent en place le jeu de test qui prouve l’amélioration. Vous gardez la maîtrise des décisions et de la relecture des cas sensibles.
La sous-traitance de développement ne se limite pas à l’écriture de code : elle inclut la qualité des systèmes IA, et c’est précisément là qu’un regard neuf change le résultat.
Notre approche consiste à commencer par un diagnostic facturé 1 500 €, déduit du devis si vous poursuivez, qui identifie laquelle de ces six erreurs dégrade vos réponses, puis à corriger le maillon fautif avec une vérification mesurable à chaque étape.