Un corpus RAG mal audité produit des réponses fausses avec une confiance apparente intacte. Voici une méthode opérationnelle pour détecter doublons, documents obsolètes et incohérences avant toute mise en production.
La plupart des projets RAG sont validés sur la base d'une démonstration : un corpus propre, des questions choisies à l'avance, un taux de réponse satisfaisant dans un notebook. Cette impression de maturité se construit souvent sur un échantillon non représentatif, qui masque les défauts structurels du corpus réel.
Le problème n'apparaît pas dans les métriques de latence ou de disponibilité, qui restent vertes. Il se loge dans la similarité sémantique elle-même : un retriever surfacera avec confiance un document de taux d'intérêt obsolète classé à 0,92 de similarité cosinus, pendant que le document correct, plus récent, se classe à 0,87. Le système renvoie la mauvaise réponse avec une grande confiance, sans générer de signal d'erreur. C'est ce que les praticiens appellent la « pourriture de fraîcheur des données », un mode de défaillance de production silencieux et systémique.
L'écart de performance entre un corpus gouverné et un corpus non gouverné est documenté : un RAG sur données gouvernées atteint 85 à 92 % de précision de récupération, contre 45 à 60 % sur sources non gouvernées. Le taux d'hallucination suit la même logique, puisqu'une étude JMIR Cancer de 2024 a montré qu'une approche RAG identique utilisant une base de connaissances curée et spécifique au domaine produisait 6 % d'hallucinations.
Avant d'investir dans l'optimisation du reranking ou du chunking, il faut donc traiter la cause en amont. Comme le rappellent les praticiens du secteur, les échecs de récupération sont eux-mêmes causés par des problèmes de qualité de données en amont : des documents obsolètes produisent des scores de similarité trompeurs, des actifs pauvres en contexte produisent des embeddings faibles, des sources non vérifiées produisent des résultats bruyants. Corriger la mécanique de récupération sur des données non gouvernées améliore les symptômes ; corriger la base de connaissances traite la cause.
Un corpus documentaire d'entreprise accumule des versions successives du même contenu : politique RH republiée, contrat renégocié, procédure mise à jour sans archivage de l'ancienne. Les versions dupliquées sont un problème silencieux : si trois versions de la même politique sont indexées, la récupération peut faire remonter la mauvaise. Sans étiquetage de version clair, le modèle ne peut pas distinguer le contenu actif du contenu archivé.
La détection combine deux approches complémentaires. Les algorithmes de détection de doublons peuvent identifier les documents quasi identiques par comparaison de hachage ou par seuils de similarité sémantique. Une fois les doublons trouvés, une version doit être marquée comme faisant autorité, les autres archivées ou exclues, et un étiquetage de contrôle de version garantit que les documents obsolètes sont clairement signalés. En pratique, le hachage exact détecte les copies strictes, tandis qu'un modèle d'embedding léger type MiniLM repère les reformulations proches, ce qui améliore la précision de récupération en éliminant les chunks qui signifient la même chose même formulés différemment.
Le vieillissement du corpus ne se voit pas dans les logs applicatifs. La latence et le débit ne sont pas affectés : les vecteurs obsolètes n'interrogent pas plus lentement que les vecteurs frais, et chaque métrique opérationnelle reste au vert. La dégradation est diffuse : aucune requête individuelle ne déclenche d'échec évident, mais sur des centaines de requêtes la précision peut chuter de 90 % à 65 % sans qu'aucune réponse isolée ne semble manifestement fausse.
L'ampleur du phénomène est mesurable : des embeddings entraînés sur un corpus de janvier peuvent perdre 15 à 20 % de précision de récupération lorsqu'ils sont appliqués à des questions portant sur des informations de juin. Et la cause n'est pas technique mais documentaire : ce n'est pas un problème de qualité de modèle, c'est un problème d'ingénierie des données. L'embedding représente fidèlement ce que disait le document ; le document ne dit simplement plus ce qui est vrai.
Un corpus qui contient plusieurs réponses différentes à une même question factuelle est plus dangereux qu'un corpus incomplet. Une mauvaise qualité des données — y compris les documents dupliqués, les informations contradictoires et le contenu non pertinent — aggrave le problème d'obsolescence. Lorsque la base de connaissances contient plusieurs versions du même fait avec des réponses différentes, le récupérateur peut extraire des informations contradictoires et le LLM aura du mal à générer des réponses cohérentes. La remédiation passe par des processus de résolution de conflits qui identifient les informations contradictoires et établissent quelle version fait autorité, couplés à des workflows de dépréciation qui marquent les documents obsolètes comme archivés plutôt que de les supprimer.
L'audit doit porter sur quatre domaines distincts, chacun avec des critères de passage explicites plutôt que des impressions qualitatives.
Un audit ponctuel avant mise en production ne suffit pas : le corpus évolue en permanence et la dérive se produit sans incident déclencheur. Les métriques à suivre en production se répartissent en deux catégories.
Un suivi de la dérive d'embeddings donne un signal quantitatif précoce. La méthode consiste à échantillonner un ensemble stable de documents de référence et les ré-embedder périodiquement avec le pipeline actuel, puis comparer les nouveaux embeddings aux versions indexées. Les seuils observés en pratique sont les suivants : une distance cosinus inférieure à 0,001 signale une situation stable, entre 0,001 et 0,02 une dérive mineure à surveiller, entre 0,02 et 0,05 une dérive significative justifiant une investigation du pipeline, et au-delà de 0,05 une dégradation sévère de la qualité de récupération.
La stabilité des voisins les plus proches complète ce signal : exécuter un ensemble de requêtes canoniques chaque semaine et comparer les identifiants de documents récupérés en top-k contre une référence, sachant que les systèmes sains maintiennent 85 à 95 % de recouvrement en top-10.
Côté pipeline d'ingestion, il faut suivre le décalage de fraîcheur, le taux de réussite de synchronisation, le backlog de tombstones, les échecs d'invalidation de cache et le temps de récupération après échec des jobs, ainsi que le taux de chunks dupliqués et le délai de traitement des tombstones.
Au-delà de Precision@K et Recall@K, il convient de suivre dans le temps l'évolution de la précision de récupération, les taux de contenu obsolète, les résultats dupliqués et la qualité de classement, car un pipeline de récupération peut sembler sain au lancement et se dégrader discrètement un mois plus tard.
Pour aller plus loin que les mesures structurelles, certains outils d'audit calculent un score d'utilité estimée de récupération par document, afin d'arbitrer les coûts d'embedding : à grande échelle, embedder chaque document n'est pas l'action par défaut ; le score d'utilité de récupération estimée est le filtre qui détermine quels documents valent la peine d'être embeddés, et les documents dont l'utilité est inférieure à 0,2 doivent être exclus.
L'audit ne doit pas être un one-shot précédant le go-live, mais un jalon récurrent intégré au cycle de vie du corpus. Trois principes pratiques s'en dégagent :
Ces exigences rejoignent les constats de la littérature académique sur l'évaluation rigoureuse des systèmes RAG : malgré leurs promesses, les RAG ne garantissent pas l'absence d'hallucinations, et leurs performances varient fortement selon le domaine métier. L'audit du corpus n'élimine pas ce risque, mais il en réduit la probabilité et, surtout, il rend la dégradation détectable avant qu'elle n'atteigne les utilisateurs finaux. Pour les organisations qui déploient un RAG dans un contexte réglementé ou à fort enjeu métier, cette traçabilité documentaire devient un prérequis de conformité autant qu'un levier de performance — un sujet que nous traitons en détail dans notre offre de conseil data et IA.
Un corpus RAG non audité produit des défaillances invisibles aux tableaux de bord classiques : la latence reste bonne, la disponibilité reste bonne, mais la pertinence des réponses se dégrade silencieusement. La checklist présentée ici — fraîcheur, doublons, couverture, cohérence — doit être appliquée avant toute mise en production, puis réinstrumentée en continu via des métriques de dérive d'embedding et de stabilité de récupération. C'est un travail d'ingénierie des données avant d'être un travail de modélisation, et c'est précisément là que se jouent la fiabilité et la défendabilité d'un système RAG en entreprise.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus