La qualité des documents détermine la fiabilité du RAG

Le RAG réduit les réponses non étayées sans garantir l’exactitude

Un modèle qui cite des documents d’entreprise peut tout de même donner une mauvaise réponse. La génération augmentée par récupération, ou RAG, donne aux équipes d’ingénierie davantage de contrôle sur les informations qu’un grand modèle de langage (LLM) reçoit avant de répondre. Ce contrôle compte pour les informations propriétaires ou critiques pour l’activité, mais sa garantie reste limitée : une réponse peut suivre les documents fournis et échouer malgré tout à une vérification distincte de l’exactitude.

Les conséquences des informations fabriquées ont été clairement visibles dans « l’incident Avianca ». En mars 2023, Steven Schwartz, avocat chevronné spécialisé en dommages corporels, a déposé un mémoire de 10 pages pour Roberto Mata, qui poursuivait Avianca Airlines pour des blessures subies lors d’un vol en 2019. Les avocats d’Avianca ont vérifié les citations et ont trouvé des affaires qui n’existaient pas. Le juge leur a donné raison, et Schwartz a reçu une sanction professionnelle.

Des défaillances similaires ont continué d’arriver devant les tribunaux. Une base de données publique tenue par Damien Charlotin, chercheur associé à HEC Paris, recensait 1 598 affaires judiciaires impliquant des citations ou contenus fabriqués par l’IA au 9 juin 2026, contre environ 200 un an plus tôt. Elle comptabilise les affaires dans lesquelles un tribunal ou une juridiction a explicitement constaté, ou clairement laissé entendre, un recours à des contenus fabriqués. Ces chiffres montrent la récurrence dans cette catégorie ; ils ne mesurent pas la fabrication dans l’ensemble des usages de l’IA en contentieux.

Le terme « hallucination » désigne une fabrication factuelle, et le mécanisme qui la produit compte aussi au sein d’une entreprise. La prédiction du token suivant sélectionne des continuations probables en unités de texte appelées tokens, tandis que les données d’entraînement incluent de la fiction, du sarcasme et des énoncés hypothétiques qui peuvent devenir des affirmations non étayées dans un autre contexte. Un entraînement supplémentaire ne peut pas garantir l’exactitude factuelle. Le RAG peut réduire les réponses non étayées, mais une mise en production exige des vérifications distinctes de l’ancrage, de la pertinence et de l’exactitude, ainsi que la possibilité de s’abstenir lorsque les connaissances disponibles sont insuffisantes.

La récupération fournit des preuves avant que le modèle ne génère une réponse

Le RAG réduit les réponses non étayées en modifiant les informations disponibles au moment où le modèle répond. Il récupère des contenus externes au moment de l’inférence, lorsqu’un modèle déployé traite une requête, et place les passages pertinents dans le prompt. L’application peut alors utiliser des connaissances contrôlées par l’organisation en complément des connaissances préentraînées du modèle. La technique a été théorisée avant que les LLM ne deviennent commercialement viables, même si l’usage en entreprise a rendu sa valeur pratique plus évidente.

La fourniture de ces connaissances relie le RAG à deux disciplines connexes. Le prompt engineering conçoit des instructions pour produire des réponses prévisibles et de haute qualité ; le context engineering assemble les informations et les instructions nécessaires à une tâche. Le RAG automatise une partie du context engineering en recherchant des contenus et en construisant le contexte de manière programmatique. Comme la requête et les documents disponibles peuvent changer, chaque demande peut produire un prompt différent.

Une requête de base passe par la récupération, la sélection du contexte et la génération de la réponse dans l’ordre suivant. Chaque étape détermine ce que la suivante peut accomplir :

1. L’application reçoit la requête de l’utilisateur avant de générer une réponse finale.
2. La récupération interroge une base de données vectorielle, qui stocke des représentations numériques du contenu, un autre index de recherche, ou les deux.
3. Le système classe les contenus récupérés et sélectionne le contexte.
4. L’assemblage du prompt combine ce contexte avec des instructions pour répondre dans ce cadre.
5. Le LLM génère une réponse censée être étayée par les contenus fournis.

« Ancré » signifie étayé par ce contenu, de sorte que l’étape finale doit toujours être évaluée. La récupération et la construction du prompt déterminent quel support le modèle reçoit et comment il est invité à l’utiliser. Les deux nécessitent des réglages et des tests. L’ancrage établit une relation entre la réponse et ses preuves ; l’exactitude exige une comparaison supplémentaire avec une référence validée.

Les déploiements répartissent généralement cette séquence entre trois services, accessibles via des endpoints auxquels les applications envoient des requêtes. Séparer leurs responsabilités aide une équipe à localiser les défaillances :

L’endpoint LLM utilise couramment une interface de programmation d’application (API) d’un fournisseur de modèles ou d’un hyperscaler, c’est-à-dire un grand fournisseur d’infrastructure cloud. Les modèles open source permettent d’autres modes d’inférence. Dans les deux cas, des appels réussis à chaque endpoint établissent que la requête a été menée à bien. L’évaluation doit ensuite déterminer si la réponse peut être utilisée.

Évaluer séparément les preuves, l’utilité et l’exactitude

L’évaluation d’une réponse terminée exige trois comparaisons distinctes. Les garder séparées aide l’équipe à identifier ce qui a échoué et à choisir une correction :

Un jeu de test doit couvrir ces trois attributs sur l’ensemble du travail que l’application rencontrera. Incluez des questions faciles, modérément difficiles, complexes et hors périmètre, et faites passer chaque requête par le processus complet de récupération et de réponse. Tester la génération à partir de passages sélectionnés manuellement laisse la récupération non testée. La séquence d’évaluation consiste donc à préparer les requêtes, exécuter la récupération et la génération, évaluer chaque attribut, puis décider de publier ou d’itérer.

Pour évaluer un grand nombre de réponses, les équipes peuvent utiliser LLM-as-a-judge, une méthode dans laquelle un modèle évalue les réponses générées. Cela doit rester une méthode de validation parmi d’autres, surtout lorsque les erreurs ont des conséquences importantes. Les applications à fort impact nécessitent aussi une revue humaine et des contrôles automatisés spécifiques à la tâche. Ces méthodes se complètent, car l’évaluation à grande échelle et le jugement d’expert servent des volets différents de la validation.

L’ancrage est le premier contrôle strict, car la fourniture de preuves est l’intervention centrale du RAG. Une réponse peut sembler cohérente avec les documents récupérés tout en introduisant une conclusion qu’ils n’établissent pas. L’évaluateur doit donc vérifier l’étayage des affirmations de la réponse, y compris ses conclusions. Les affirmations non étayées doivent être considérées comme des défaillances importantes, même lorsque la réponse se lit bien ou paraît utile.

Un échec d’ancrage renvoie au chemin qui mène des documents de connaissance au texte généré. La récupération a pu sélectionner de mauvais contenus, les documents peuvent être incomplets ou contradictoires, le prompt peut autoriser des ajouts non étayés, ou le modèle de réponse peut être inadapté. Une information manquante appelle une correction différente d’un échec à récupérer une information déjà existante. Des documents contradictoires exigent une autre investigation, car ils peuvent étayer des affirmations incompatibles.

Une fois l’étayage établi, la pertinence demande si la réponse résout la demande. Un LLM peut résumer fidèlement des passages récupérés tout en laissant sans réponse la question de l’utilisateur. Améliorer l’adhérence à ces passages peut préserver l’échec si le contenu lui-même est mal aligné sur la requête. La pertinence nécessite donc une évaluation graduée, distinguant une réponse largement sans rapport d’une réponse qui ne traite qu’une partie de la question.

Une pertinence partielle peut révéler un contexte manquant dans des résultats de récupération par ailleurs utiles. Le chunking, c’est-à-dire la division des documents en unités récupérables, peut séparer une explication des informations nécessaires pour la compléter. Les corrections possibles incluent la modification de la taille et du nombre de chunks, la réécriture des requêtes et le filtrage par métadonnées, c’est-à-dire les champs descriptifs associés au contenu. La recherche hybride combine la récupération par mots-clés avec la recherche vectorielle, tandis que le re-ranking réévalue les candidats récupérés pour améliorer leur ordre. Le choix dépend de la manière dont l’information nécessaire a été perdue ou exclue.

L’exactitude ajoute ensuite une référence indépendante, souvent appelée « ground truth », fournie par un expert ou une autre référence validée. Le résultat attendu est généralement enregistré comme une golden answer dans les données de test. Une réponse peut suivre le contenu récupéré et traiter la demande tout en différant de cette réponse. Un ancrage et une pertinence solides laissent donc ouvertes des questions sur la suffisance des documents, l’exhaustivité de la récupération et la capacité du modèle à combiner les preuves.

La préparation des réponses de référence exige que quelqu’un les fournisse ou les valide ; les tests d’exactitude se concentrent donc généralement sur un sous-ensemble prioritaire où les réponses comptent le plus. Les trois attributs peuvent ainsi avoir des niveaux de couverture de test différents. Le jeu de données plus large doit tout de même inclure des questions hors périmètre et « sans réponse possible », car elles testent si l’application reconnaît les limites de ses connaissances. Pour de telles demandes, le comportement attendu peut être l’abstention.

L’abstention consiste à refuser de répondre lorsque les preuves disponibles sont insuffisantes. Les équipes devraient autoriser la réponse « Je ne sais pas » et tester si le système utilise cette option de manière appropriée. Exiger un ancrage strict tout en imposant une réponse dans tous les cas crée des instructions contradictoires lorsque les preuves sont insuffisantes. Les exigences produit, les prompts et l’évaluation doivent tous permettre à l’application de s’arrêter dans cette situation.

Les résultats d’évaluation deviennent utiles lorsqu’ils orientent une investigation précise. Les schémas suivants identifient des points de départ plutôt que des causes garanties :

Des résultats séparés rendent aussi les décisions de mise en production plus instructives. Un score agrégé peut s’améliorer tout en masquant un problème persistant d’exactitude ou une tendance croissante à répondre hors périmètre. Enregistrer chaque attribut préserve la raison du prochain changement d’ingénierie. Si la suffisance des documents, la récupération et la synthèse du modèle ont été examinées et que l’exactitude reste faible, les résultats peuvent justifier de reconsidérer l’architecture.

Corriger les documents, la récupération, les permissions et les prompts à l’origine des défaillances

Avant de modifier l’architecture, il faut établir si les connaissances disponibles pour la récupération peuvent prendre en charge la tâche. Une collection de connaissances gérée doit offrir une couverture complète, de l’autorité, de l’actualité et un processus de détection des contradictions. Des mises à jour régulières comptent, car récupérer avec succès un document obsolète peut tout de même produire une mauvaise réponse. Le réglage de la récupération a une valeur limitée lorsque le contenu sous-jacent ne contient pas les informations requises.

La préparation de ce contenu dépend aussi de son format. Une enquête de la Cloud Security Alliance menée en novembre 2025 auprès de professionnels de l’IT et de la sécurité décrivait des volumes importants de données non structurées, comme les documents en texte libre, et de données semi-structurées, qui présentent une certaine organisation sans format d’enregistrement fixe. Ses conclusions portent sur la composition et la croissance des données :

Ces proportions décrivent des besoins de préparation plutôt que la part des organisations confrontées à un désavantage particulier en matière de récupération. Pour la préparation des documents, AWS recommande des titres et sous-titres clairs, des documents ciblés, des termes définis et, lorsque c’est approprié, des unités plus petites et autonomes. AWS vend des infrastructures cloud et des services d’IA ; l’entreprise bénéficie donc commercialement de l’adoption en entreprise de systèmes tels que le RAG. Ses recommandations relient la préparation des documents à la conception de la récupération, car les unités qu’une équipe rédige ou extrait influencent ce que son système peut récupérer.

La récupération de ces unités par le sens exige un modèle d’embedding, qui convertit le texte en vecteurs : des représentations numériques qui encodent certains aspects du sens et permettent une comparaison mathématique. Un tel modèle peut représenter « pommier » comme plus proche de « bananier » que de « centrale nucléaire ». Cela illustre la relation sémantique utilisée dans la récupération. Son utilité dépend néanmoins de la qualité avec laquelle le modèle représente la langue et la terminologie de l’application.

Une terminologie spécialisée rend les tests représentatifs essentiels. L’expression « nous avons fait une impression », par exemple, peut décrire un impact ordinaire ou la création d’une empreinte dentaire physique. Un modèle d’embedding généraliste peut traiter ces sens différemment de ce qu’exige une collection de documents médicaux ou dentaires. Les équipes devraient comparer les modèles aux exigences réelles du domaine et de la langue, en testant de manière particulièrement approfondie les charges de travail sensibles.

L’entrée du modèle d’embedding dépend aussi de la manière dont les documents sont divisés. De petits chunks conviennent à des paragraphes autonomes, de type liste, tandis qu’un raisonnement développé sur plusieurs paragraphes peut nécessiter une unité plus grande. Les pages HTML fournissent des limites via les balises , and; ; les livres fournissent des chapitres et des sections. Les tableaux denses et les formulaires exigent une attention particulière, car un découpage textuel ordinaire peut détruire les relations ligne-colonne, rendant nécessaire une extraction dédiée des tableaux avant une récupération fiable.

Une fois le modèle d’embedding et les unités documentaires sélectionnés, une base de données vectorielle ou un autre magasin vectoriel peut récupérer efficacement des contenus similaires. Les options de déploiement vont de systèmes open source auto-hébergés à des services d’entreprise à mise à l’échelle automatique. Le magasin renvoie un nombre configurable d’éléments candidats, souvent appelé top N. Ces candidats doivent aussi avoir des métadonnées associées à chaque chunk, car la similarité seule ne peut pas déterminer si le contenu s’applique.

Les métadonnées fournissent le contexte nécessaire pour porter ce jugement. Une collection de journaux peut associer la date de publication, le titre, l’auteur et la rubrique pour prendre en charge les citations et le filtrage par date. Une base de connaissances d’entreprise peut nécessiter le propriétaire du document, l’unité métier, la version, le type de document et les permissions d’accès. Ces champs permettent à la récupération de sélectionner le contenu qui s’applique à la fois à la demande et au demandeur.

Les permissions d’accès doivent donc influencer la sélection avant que les documents n’entrent dans le contexte de réponse. Un document peut être très pertinent tout en étant inaccessible à l’utilisateur, remplacé par une autre version ou applicable à une autre unité métier. La récupération doit appliquer les contraintes appropriées d’accès, de version, de propriété et d’unité métier. Sinon, le système peut produire une réponse étayée à partir d’informations qu’il n’aurait jamais dû fournir.

Au sein du contenu éligible, le nombre et la taille des chunks doivent être testés conjointement. Trop peu de chunks peuvent omettre des preuves nécessaires ; trop de chunks peuvent ajouter du contenu non pertinent et consommer davantage de tokens. Des chunks plus grands allongent aussi le contexte produit pour un même nombre de chunks, de sorte que modifier l’un ou l’autre paramètre affecte le résultat pratique de l’autre. Les tests d’intégration doivent utiliser des requêtes représentatives et le modèle de réponse final.

Lorsque ces tests révèlent des faiblesses de récupération, des techniques supplémentaires peuvent traiter des causes précises. La réécriture de requête reformule une demande ambiguë ou mal formulée ; la recherche hybride et le re-ranking peuvent améliorer les candidats qui parviennent à la sélection du contexte. Une demande peut passer par la réécriture, la recherche hybride, le re-ranking et la sélection de contexte top-N. Chaque ajout doit démontrer sa valeur face à la défaillance qu’il corrige.

Une fois que la récupération a sélectionné le contexte, la construction du prompt contrôle la manière dont il est demandé au modèle de l’utiliser. Les instructions de l’application et les données récupérées partagent le contexte du modèle ; un texte externe contenant un langage de type instruction peut donc créer de la confusion. Des délimiteurs cohérents devraient distinguer les instructions du contenu de référence. Lorsque les logiciels en aval ont besoin de citations, de plusieurs types de sortie ou d’autres informations structurées, JSON, un format de texte structuré, peut rendre les réponses plus faciles à analyser et à traiter.

Choisir l’architecture en fonction de la charge de travail

Certaines défaillances persistent après correction des documents, de la récupération et des prompts, ce qui fait de l’architecture la décision suivante. Le RAG classique convient aux connaissances privées, spécialisées ou fréquemment mises à jour, car les documents et les index peuvent être mis à jour indépendamment de l’entraînement du modèle. D’autres approches modifient le comportement appris, fournissent davantage de contexte directement ou récupèrent l’information en plusieurs étapes. Chacune exige toujours une évaluation de l’ancrage, de la pertinence, de l’exactitude et d’une abstention appropriée.

L’adoption commerciale croissante rend ces choix plus visibles, mais l’évaluation reste la base pour choisir entre eux. Les estimations du marché global du RAG aux États-Unis décrivent la croissance suivante :

Ces estimations couvrent le RAG dans son ensemble et n’établissent aucun avantage distinct pour les systèmes agentiques. Une équipe qui envisage une alternative doit toujours identifier le besoin auquel elle répondrait. Un comportement stable, une collection bornée de documents et des questions exigeant des recherches successives créent des problèmes d’ingénierie différents. Le fine-tuning, le prompting à long contexte et les agents de récupération répondent à ces problèmes de façons différentes.

Le fine-tuning modifie les poids du modèle par un entraînement supplémentaire, ce qui permet d’appliquer un comportement appris d’une requête à l’autre sans fournir à répétition des instructions identiques. Il peut convenir au style, à la classification, au formatage et à l’exécution de tâches spécialisées. Des connaissances factuelles qui changent fréquemment exigent un autre processus de mise à jour, car l’intégration de nouveaux faits nécessite généralement un entraînement supplémentaire, alors que le RAG peut mettre à jour ses documents et son index. Le fine-tuning exige aussi une expertise spécialisée et des tests approfondis, et offre à lui seul un contrôle limité des hallucinations.

Lorsque l’exigence principale consiste à fournir un corpus borné de connaissances, le prompting à long contexte peut placer directement dans le prompt de grandes quantités de contenu d’ancrage. Cela évite les embeddings et une base de données vectorielle, ce qui a conduit certaines équipes à y voir une manière plus simple de fournir des connaissances organisationnelles. La limite finale est la fenêtre de contexte du modèle, c’est-à-dire la quantité maximale de texte qu’il peut traiter en une fois, mais le coût, la latence, les informations non pertinentes et la difficulté à trouver un contenu utile peuvent devenir des problèmes plus tôt. Les tests devraient comparer le prompting sur l’ensemble de la collection avec un contexte plus restreint et soigneusement récupéré.

Les questions qui exigent des recherches successives posent un autre problème. Un agent de récupération peut utiliser des outils et interroger la base de connaissances à plusieurs reprises au fur et à mesure qu’il rassemble les informations, au lieu de s’appuyer sur un seul passage de récupération. Prendre en charge ce comportement exige des définitions d’outils, des prompts de retriever, une orchestration pour coordonner les étapes et une gestion d’état pour conserver les informations entre elles. Des appels supplémentaires au modèle augmentent les tokens, le temps de réponse, le coût d’inférence et la complexité opérationnelle ; les tests doivent donc tenir compte de ces coûts.

Les recommandations de Microsoft Azure AI Search relient cette distinction au choix selon la charge de travail. Elles associent le RAG classique à des priorités telles que la simplicité et le contrôle, et la récupération agentique à des questions conversationnelles complexes exigeant davantage de pertinence et d’exactitude. Microsoft vend des services de recherche et d’IA Azure, ce qui lui donne un intérêt commercial dans l’adoption de ces architectures. Ses recommandations fournissent un cadre de sélection de fournisseur que les équipes peuvent tester par rapport à leurs propres exigences.

Les arbitrages plus larges peuvent être comparés qualitativement. Les évaluations décrivent des tendances architecturales dont la valeur pratique dépend de la charge de travail et de la mise en œuvre :

Continuer à valider à mesure que les connaissances, les requêtes et les accès évoluent

Quelle que soit l’architecture choisie, une décision de mise en production établit les performances dans les conditions testées à ce moment-là. Les documents, les questions des utilisateurs, les modèles d’embedding et la taille de la collection peuvent tous modifier ces conditions ; un succès sur un petit jeu de test peut donc disparaître après le déploiement. Le comportement de récupération peut évoluer à mesure que davantage de contenu devient disponible, même si le code de l’application reste inchangé. La validation en production doit donc se poursuivre à mesure que le système de connaissances évolue.

La validation continue exige les contrôles opérationnels attendus des autres logiciels d’entreprise. L’authentification établit qui effectue une requête, tandis que l’autorisation détermine à quelles informations cette personne peut accéder. La sécurité des données, la journalisation, la supervision et l’auditabilité soutiennent le contrôle et l’investigation dans l’ensemble de l’application. Une récupération tenant compte des permissions doit rester efficace à mesure que les documents et les utilisateurs évoluent.

Le maintien de ces contrôles exige une responsabilité explicite. Quelqu’un doit maintenir la collection de connaissances, quelqu’un doit mesurer la qualité de la récupération, et quelqu’un doit contrôler les accès et détecter les défaillances. Leurs responsabilités doivent couvrir les mises à jour des documents ainsi que les changements d’embeddings, de paramètres de récupération et de schémas de requêtes. Sans responsabilité claire, un résultat d’évaluation peut rester inchangé sur le papier alors que le système qu’il décrivait continue d’évoluer.

Ces responsables doivent aussi avoir de la visibilité sur l’abstention. Une nouvelle lacune documentaire ou un changement de droits d’accès peut laisser une demande auparavant traitable sans preuve autorisée suffisante, auquel cas l’application devrait refuser. La supervision devrait rendre ce comportement visible pour les personnes responsables de la collection de connaissances. Elles peuvent alors améliorer les preuves disponibles, ajuster le périmètre pris en charge ou maintenir le refus parce que le système a atteint une limite réelle.

Points clés à retenir pour les dirigeants

• L’ancrage a ses limites : le RAG réduit les réponses non étayées en fournissant des preuves, mais une réponse étayée peut tout de même être erronée. Les responsables produit ont besoin de critères de mise en production distincts pour l’étayage des preuves, la pertinence et l’exactitude.
• Rendre les défaillances de récupération traçables : les équipes d’ingénierie doivent tester le chemin complet, de la requête utilisateur à la génération, en passant par la récupération et la sélection du contexte. La séparation des responsabilités entre services aide à identifier où une réponse a perdu l’information dont elle avait besoin.
• Évaluer les réponses selon des standards distincts : les responsables de l’évaluation ont besoin de requêtes représentatives, de réponses de référence validées par des experts pour les tâches prioritaires, et de tests hors périmètre. Les exigences produit et les prompts doivent autoriser l’abstention lorsque les preuves sont insuffisantes, avec une revue humaine pour les applications à fort impact.
• Corriger la chaîne de connaissances : les responsables des connaissances maintiennent des documents faisant autorité et à jour, tandis que les ingénieurs de récupération règlent les embeddings, le chunking et le classement en fonction des défaillances observées. Les permissions d’accès et les contraintes de version doivent filtrer le contenu avant qu’il n’atteigne le modèle.
• Adapter l’architecture à la charge de travail : les responsables de l’architecture peuvent comparer le RAG classique pour les connaissances évolutives, le fine-tuning pour un comportement stable, le contexte long pour des collections bornées, et la récupération agentique pour des recherches successives. La complexité supplémentaire doit apporter des bénéfices mesurables au regard des exigences d’exactitude, de latence et de coût.
• Attribuer la responsabilité de la validation continue : les responsables de production ont besoin d’une responsabilité explicite pour la maintenance des documents, la qualité de la récupération, les contrôles d’accès et la supervision des défaillances. La revalidation à mesure que les connaissances et les schémas de requêtes évoluent maintient la pertinence des preuves de mise en production et rend visibles les lacunes émergentes.