Cross-source conflation : quand votre RAG cite la bonne information... à la mauvaise source

Un RAG peut répondre juste et citer la mauvaise source. Ce failure mode silencieux, invisible aux benchmarks usuels, fragilise la traçabilité documentaire.

Une requête sur un RAG d’entreprise renvoie une réponse exacte. Le fait cité est bien dans le corpus. La source affichée à côté, en revanche, ne le contient pas — l’information existe ailleurs, dans un autre document. Personne dans la chaîne ne le voit : la réponse « sonne » vraie, sourcée, exploitable. Sur k-ai.ai, la requête qui décrit exactement ce mécanisme — une information correcte mais attribuée à la mauvaise source, ce que la littérature récente sur le RAG commence à nommer cross-source conflation — génère déjà des impressions de recherche en position 3,83, sans qu’aucun contenu dédié n’existe encore pour y répondre. Ce vide éditorial est un symptôme : ce failure mode n’est identifié nulle part comme sujet de fond, ni chez les éditeurs de RAG d’entreprise, ni chez les fournisseurs de frameworks d’évaluation.

Un failure mode qu’aucun dashboard ne capte

La conflation cross-source n’est pas une hallucination au sens classique. Une hallucination invente un fait qui n’existe dans aucun document du corpus — c’est le failure mode que les frameworks d’évaluation (RAGAS, DeepEval, LettuceDetect) savent détecter, en comparant la réponse générée aux passages récupérés. La conflation, elle, est plus retorse : le fait existe bel et bien dans le corpus, la réponse est correcte sur le fond, mais le système attribue cette information au mauvais document. Le score de fidélité (« faithfulness ») d’un pipeline peut rester excellent puisque le contenu de la réponse n’est pas fautif — seule la chaîne de preuve, la citation qui l’accompagne, est rompue.

C’est un failure mode distinct de la contradiction inter-sources que nous avions documentée en mai dernier, où deux documents du corpus se contredisent frontalement sur un même fait — un problème de cohérence du contenu. Ici, le contenu est cohérent et correct ; c’est la traçabilité de la provenance qui échoue silencieusement.

Pourquoi c’est plus dangereux qu’une hallucination franche

Une hallucination pure a un avantage paradoxal : elle finit par se voir. Un fait inventé, absent de tout document source, peut être détecté par un reranker, une étape de vérification factuelle, ou tout simplement par un relecteur qui ne retrouve pas la citation dans le document indiqué. La conflation cross-source, elle, passe ces filtres. Le fait est vrai. Le document cité existe. Rien ne clignote.

Le problème surgit au moment où quelqu’un — un auditeur, un régulateur, un client, un collègue juriste — remonte la chaîne de preuve pour vérifier une affirmation dans un contexte où la source compte autant que le fait : une politique de conformité, une clause contractuelle, une procédure de sécurité versionnée. Si la source citée ne contient pas réellement l’information, la vérification échoue, même si l’information elle-même était juste. Dans un contexte réglementé, cette rupture de traçabilité pèse autant que l’erreur factuelle qu’elle prétend éviter.

Ce que dit la littérature récente sur l’écart retriever-générateur

Un travail académique récent apporte un éclairage utile, même s’il ne porte pas nommément sur la conflation cross-source : le papier RAG-E: Quantifying Retriever-Generator Alignment and Failure Modes (arXiv, janvier 2026) mesure, sur plusieurs jeux de données, l’écart entre ce que le retriever remonte comme documents pertinents et ce que le générateur utilise réellement pour produire sa réponse. Ses auteurs constatent que, selon les configurations testées, entre 47,4 % et 66,7 % des requêtes voient le générateur ignorer les documents les mieux classés par le retriever, et qu’entre 48,1 % et 65,9 % des cas s’appuient sur des documents moins pertinents que ceux disponibles.

Ce chiffre ne mesure pas directement la conflation — il mesure un symptôme voisin : le lien entre ce qui est récupéré et ce qui est effectivement cité n’est pas fiable par construction. Un système qui peut ignorer le bon document pour en utiliser un moins pertinent peut, de la même manière, produire une réponse correcte tout en pointant vers la mauvaise source parmi plusieurs candidats plausibles. La littérature commence à documenter ce type de dérive de l’alignement retriever-générateur ; elle ne l’a pas encore, à notre connaissance, vulgarisée pour un public de décideurs non techniques.

Un territoire qu’aucun acteur du marché n’occupe

Nous avons passé en revue une vingtaine d’acteurs de l’écosystème RAG d’entreprise et de gouvernance documentaire — concurrents directs sur le positionnement Document Knowledge Platform, plateformes d’Enterprise Search et de Knowledge Management, éditeurs de data catalog étendus au non-structuré. Aucun ne traite l’attribution de source comme sujet éditorial autonome. Le sujet apparaît, au mieux, en filigrane : une fonctionnalité de traçabilité de citation glissée dans une note de version produit, ou un argument secondaire dans une étude de cas sur le grounding. Du côté des outils d’évaluation RAG spécialisés — les frameworks qui mesurent justement la fidélité et la pertinence des réponses — aucun ne publie non plus de contenu dédié à ce terme précis, alors que plusieurs disposent déjà d’un vocabulaire voisin (précision de citation, attribution de chunk).

Ce silence collectif n’est pas anodin. Il reflète une limite structurelle : la plupart des outils du marché évaluent la qualité du pipeline de récupération et de génération. Peu d’entre eux évaluent la qualité du corpus source lui-même — sa cohérence interne, sa granularité documentaire, la clarté avec laquelle chaque information peut être reliée sans ambiguïté à un document et un seul.

Le coût métier d’une mauvaise attribution en contexte réglementé

Dans un cabinet de conseil, une banque ou un assureur, une réponse générée par un assistant IA interne peut être correcte et pourtant inutilisable telle quelle si sa source ne résiste pas à la vérification. Un juriste qui cite une clause contractuelle doit pouvoir remonter au document exact, à la version exacte. Un contrôleur de conformité qui documente une décision au titre de l’AI Act doit pouvoir prouver la chaîne de preuve de l’information utilisée par un système, pas seulement l’exactitude du résultat final. L’article 12 de l’AI Act, consacré à la tenue de registres et à la traçabilité, s’inscrit précisément dans cette logique : ce n’est pas seulement le résultat d’un système d’IA qui doit pouvoir être audité, mais le chemin qui y mène.

Une mauvaise attribution de source, même quand le fait cité est juste, complique cette preuve. Elle transforme une réponse a priori fiable en point de friction lors d’un audit — avec un coût qui n’est pas technique mais organisationnel : temps de vérification manuelle, perte de confiance des utilisateurs métier, exposition en cas de contrôle externe.

Ce que change une architecture de traçabilité native

C’est précisément le type de défaillance que la couche DKP est censée neutraliser en amont. Une architecture de type graphe sémantique — plutôt qu’un cosine de similarité vectorielle — relie chaque affirmation extraite à son document d’origine de façon explicite, et non par proximité statistique. Sur un seul référentiel documentaire audité lors d’un premier diagnostic, les équipes K-AI identifient en général plusieurs centaines d’incohérences de ce type — recoupements imprécis entre documents proches sémantiquement, métadonnées de provenance manquantes ou obsolètes, versions qui se chevauchent sans marqueur de validité. Ce chiffre ne dit rien du volume à l’échelle d’une organisation entière ; il illustre l’ampleur du travail de fond nécessaire avant qu’un système de génération puisse citer ses sources de façon fiable.

Auditer cette couche de provenance avant de brancher un pipeline RAG ou un agent n’est pas un luxe méthodologique. C’est une condition pour que la traçabilité documentaire résiste à l’examen — celui d’un client, d’un régulateur, ou simplement d’un collaborateur qui a besoin de faire confiance à ce que son assistant IA lui montre.

K-AI accompagne déjà CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies et CEVA Logistics. Partenaires : AWS, Snowflake, Microsoft, Wavestone, Devoteam.

Foire aux questions

Qu’est-ce que la conflation cross-source dans un système RAG ?

La conflation cross-source (cross-source conflation) désigne un cas où un système RAG (Retrieval-Augmented Generation) génère une réponse dont le contenu factuel est correct — l’information existe réellement dans le corpus documentaire — mais l’attribue à la mauvaise source ou au mauvais document. Contrairement à une hallucination classique, où le fait lui-même est inventé, ici seule la chaîne de citation est rompue. La réponse paraît fiable et sourcée, ce qui rend l’erreur plus difficile à détecter qu’une hallucination franche.

Comment détecter quand un système attribue une information à la mauvaise source ?

La détection nécessite de vérifier, document par document, que chaque affirmation citée est effectivement présente dans la source indiquée — un contrôle que les métriques de fidélité usuelles (faithfulness) ne réalisent pas nécessairement, puisqu’elles évaluent la cohérence entre la réponse et l’ensemble des passages récupérés, pas la correspondance précise entre chaque affirmation et son document d’origine. Une architecture qui trace explicitement la provenance de chaque affirmation, plutôt que de s’appuyer sur une similarité vectorielle globale, permet de croiser systématiquement l’affirmation générée avec le document exact dont elle est issue.

Pourquoi un RAG peut-il se tromper de source même quand les faits sont corrects ?

Les architectures RAG classiques identifient les documents pertinents par proximité sémantique (similarité vectorielle), sans distinguer nécessairement, parmi plusieurs documents proches et traitant du même sujet, celui qui contient réellement l’affirmation précise citée. Quand plusieurs documents du corpus abordent un thème similaire — versions successives d’une politique, déclinaisons régionales d’une procédure — le système peut retrouver l’information correcte tout en pointant vers un document voisin plutôt que le document exact.

En quoi la conflation cross-source diffère-t-elle de la contradiction inter-sources ?

Ce sont deux failure modes distincts. La contradiction inter-sources se produit quand deux documents du corpus se contredisent frontalement sur un même fait — un problème de cohérence du contenu, que nous avions documenté en détail en mai 2026. La conflation cross-source, elle, ne suppose aucune contradiction : le contenu est cohérent et correct, seule l’attribution à la source précise est erronée. La première expose un désaccord factuel dans le corpus ; la seconde expose une rupture silencieuse de la chaîne de preuve, alors même que l’information restituée est exacte.

Quel est le coût métier d’une mauvaise attribution de source dans un contexte réglementé ?

Dans un contexte d’audit, de conformité AI Act ou de vérification contractuelle, la valeur d’une réponse générée ne dépend pas seulement de son exactitude factuelle mais de la capacité à en prouver la source exacte. Une attribution erronée transforme une réponse correcte en point de blocage lors d’une vérification : temps de contrôle manuel supplémentaire, perte de confiance des équipes métier vis-à-vis de l’outil, et exposition accrue en cas de contrôle réglementaire externe, où la démonstration de la chaîne de preuve documentaire peut être requise au même titre que le résultat produit.

Pour aller plus loin

Si votre organisation déploie ou envisage de déployer des agents IA sur des sources documentaires internes, la question de la traçabilité de provenance mérite d’être posée avant celle de l’architecture de récupération. Pour en discuter, contactez-nous à contact@k-ai.ai.

Sources citées

Randl, M. et al., RAG-E: Quantifying Retriever-Generator Alignment and Failure Modes, arXiv, 29 janvier 2026. https://arxiv.org/abs/2601.21803
EU AI Act — Article 12 (tenue de registres), texte officiel. https://artificialintelligenceact.eu/article/12/
Hebbia, What’s New: June Disclosure 2026 (fonctionnalité “Citations in Slides”). https://www.hebbia.com/blog/whats-new-june-disclosure-2026/
Pinecone, Pinecone Nexus integrates with Microsoft OneLake, 3 juin 2026. https://www.pinecone.io/newsroom/microsoft-onelake-nexus/