Comment tenir à jour un corpus RAG et vérifier que les anciens documents n’apparaissent plus

Maintenir le corpus ne revient pas à évaluer les réponses

Un corpus RAG est correctement maintenu lorsque le contenu disponible pour la recherche correspond toujours aux sources que l’équipe considère comme valides. Le travail consiste à identifier les documents et leurs versions, à traiter les changements, à mettre à jour les unités indexées et à vérifier le résultat. Cette tâche est différente de l’évaluation de la justesse d’une réponse rédigée par le modèle ou de la qualité de son ancrage dans les fragments récupérés. Ces deux types d’évaluation peuvent être liés, mais ils ne se remplacent pas : un test de récupération peut révéler qu’un document retiré apparaît encore, même si la réponse générée semble raisonnable.

La documentation fournie de Microsoft décrit la création d’un pipeline de données non structurées pour des applications d’IA. La documentation de Google Cloud porte sur l’administration d’un corpus RAG et indique, d’après les informations disponibles, qu’elle couvre la création d’un corpus ainsi que l’importation ou le téléversement de documents. Ces références apportent un contexte sur le traitement et l’ajout de contenu, mais les éléments disponibles ne confirment pas l’existence d’une procédure universelle de mise à jour ou de suppression des documents. Les étapes ci-dessous constituent donc une méthode opérationnelle adaptable, et non l’affirmation qu’une fonction donnée existe dans tous les produits.

L’objectif pratique est de pouvoir répondre à des questions sur l’état du contenu : quelle source est à l’origine d’un fragment, quelle version a été traitée, si un échec partiel s’est produit et quel test prouve qu’une suppression a bien été prise en compte. Si l’équipe ne peut pas répondre à ces questions, elle ne devrait pas considérer le corpus comme à jour au seul motif qu’une exécution de traitement s’est terminée.

Inventorier les sources avant d’automatiser

Commencez par répertorier les sources susceptibles d’alimenter le corpus et attribuez un responsable à chacune d’elles. Une source peut être un dépôt de documentation interne, un catalogue, un ensemble de normes ou une collection de fichiers. L’inventaire n’a pas besoin de dépendre d’un produit particulier, mais il doit permettre de distinguer chaque origine et de savoir qui décide si le contenu est ajouté, modifié ou retiré.

Pour chaque document, conservez un identifiant stable si le système d’origine en fournit un. Notez également son emplacement ou sa collection d’origine, son propriétaire, une date ou une version vérifiable et son état — par exemple actif, en attente de traitement ou retiré. S’il n’existe pas de version formelle, vous pouvez consigner un indicateur de changement disponible dans la source, à condition que l’équipe documente sa signification et ses limites. Ne partez pas du principe qu’une date de modification suffit à distinguer deux contenus identiques ou deux révisions différentes.

Associez ces propriétés à chaque unité dérivée qui est indexée, par exemple un fragment ou un enregistrement. L’objectif est de pouvoir retrouver toutes les unités provenant d’une source lorsque celle-ci change ou est retirée. Si le mécanisme d’indexation ne permet pas de stocker des métadonnées ou ne documente pas comment filtrer et retirer des enregistrements, consignez-le comme une limite à tester ; ne supposez pas que la suppression du fichier d’origine supprime automatiquement ses dérivés.

Définissez également les règles d’ajout et de retrait. Précisez, par exemple, qui autorise le passage d’un document à l’état actif, ce qu’implique un remplacement et comment les sources contradictoires sont départagées. Il s’agit de décisions de gouvernance propres à l’équipe, et non de caractéristiques inhérentes au RAG. Les consigner par écrit évite qu’une mise à jour technique détermine accidentellement quelle version doit être considérée comme valide.

Décider quels changements nécessitent un nouveau traitement

Tous les changements ne nécessitent pas forcément le même travail. Une correction localisée peut justifier le traitement d’un seul document ; une modification des règles d’extraction ou de découpage du texte peut concerner une collection entière. Une modification de la configuration qui transforme la représentation stockée peut justifier une reconstruction plus large. Ce sont des catégories de décision : avant de les appliquer, vérifiez les composants utilisés par votre pile et les opérations qu’elle prend en charge.

Rédigez une politique qui relie les indicateurs de changement au périmètre du nouveau traitement. Par exemple : une nouvelle version identifiée dans la source déclenche le retraitement du document concerné ; une modification globale de l’extraction déclenche un examen de la collection concernée ; un doute sur la cohérence de l’ensemble peut conduire à une reconstruction de test. Ne transformez pas ces exemples en automatismes avant d’avoir validé l’identification des documents, la capacité de suppression et le comportement de l’outil.

Le pipeline décrit par Microsoft peut servir de référence générale pour réfléchir au traitement des données non structurées, mais les informations disponibles ne précisent pas les opérations de mise à jour incrémentielle, de synchronisation ou de suppression qu’il met en œuvre. De même, la référence de Google Cloud sur l’administration d’un corpus confirme les thèmes de création et d’importation, mais ne permet pas de conclure quelles conditions s’appliquent à la modification ou à la suppression des enregistrements. Le comportement réel doit être vérifié dans la documentation de la pile choisie et au moyen de tests contrôlés.

Concevoir le cycle d’ajout et de modification

Un cycle de mise à jour peut être organisé en étapes explicites. On détecte d’abord une nouvelle source ou un changement au moyen d’un indicateur disponible dans le système d’origine. On consigne ensuite la version observée et l’on vérifie que le document peut être admis selon les règles de l’équipe. Le contenu est alors extrait et traité avec la configuration convenue ; les métadonnées nécessaires pour remonter jusqu’à la source sont conservées.

Avant de publier le résultat, décidez comment gérer la transition entre les versions. Une stratégie possible consiste à préparer et vérifier la nouvelle version avant de la rendre disponible, si la plateforme permet de la maintenir séparément. Une autre consiste à remplacer directement le contenu puis à le vérifier. Aucune de ces stratégies n’est toujours préférable : le choix dépend des fonctions documentées, de la tolérance du système à une interruption et de la gestion des états partiels.

Le journal d’exécution devrait indiquer au minimum la source et la version visées, la date de détection, le périmètre prévu, l’état de chaque étape et le résultat des vérifications. Si le processus est interrompu, ces informations permettent de distinguer une source qui n’a pas été détectée, un échec d’extraction et une mise à jour appliquée seulement en partie. Ne marquez pas une version comme en vigueur au seul motif que son traitement a commencé.

Définissez un critère d’achèvement observable. Par exemple, l’opération ne passe à l’état terminé qu’après avoir vérifié que les unités attendues sont récupérables et que l’ancienne version n’apparaît plus lorsqu’elle a été remplacée. Ce critère doit pouvoir être appliqué avec l’outil concerné. Si celui-ci ne permet pas de le vérifier, consignez cette limite et concevez un test de récupération externe.

Gérer les suppressions et les remplacements sans laisser de résidus

Retirer un fichier de la source et retirer ses représentations de l’index sont deux opérations différentes, sauf si l’intégration concernée documente et démontre le contraire. Une suppression peut laisser des fragments, des copies dérivées ou des enregistrements en double si toutes les unités provenant de la source ne sont pas identifiées. C’est pourquoi le lien entre l’identifiant de la source et les unités indexées doit être conçu avant la première suppression.

En cas de remplacement, consignez quelle version n’est plus valide et laquelle doit la remplacer. Vérifiez que la nouvelle version est traitée correctement et que l’ancienne ne ressort plus dans les recherches où elle était auparavant pertinente. Si les deux versions doivent coexister pour une raison légitime, définissez comment les distinguer et précisez l’état de chacune. Ne les présentez pas comme équivalentes si la politique de la source les considère comme incompatibles.

Une suppression doit laisser des traces : source retirée, date de la demande, responsable, unités concernées ou périmètre de l’opération, résultat et requêtes de test. Si l’opération échoue, conservez un état en attente ou en échec et évitez de présenter le corpus comme entièrement à jour. La reprise peut consister à réessayer, à reconstruire une partie ou à faire remonter le problème ; le choix dépend des capacités disponibles et doit être consigné.

Les sources fournies ne permettent pas d’affirmer qu’une plateforme précise supprime automatiquement tous les fragments dérivés lorsqu’un document est effacé. La discussion Reddit incluse parmi les sources est anecdotique et ne permet pas d’établir un comportement garanti. Vérifiez les fonctions de suppression dans la documentation officielle du produit concerné et, surtout, contrôlez le résultat au moyen d’un test reproductible.

Contrôler les mises à jour partielles et les échecs

Un processus de mise à jour peut s’arrêter après la détection du changement, pendant l’extraction ou après n’avoir modifié qu’une partie de l’index. La procédure opérationnelle doit rendre ces différences visibles. Définissez des états simples, par exemple en attente, en cours de traitement, terminé et en échec, puis précisez ce que chacun signifie. Si l’équipe a besoin de suivre des étapes plus détaillées, elle peut les ajouter à condition que les opérateurs comprennent leurs liens.

Décidez quel contenu reste disponible tant que la mise à jour est incomplète. Dans certains systèmes, il peut être possible de conserver l’ancienne version jusqu’à ce que la nouvelle soit validée ; dans d’autres, la mise à jour peut créer une période d’indisponibilité ou des résultats mêlant les deux versions. Ne promettez ni atomicité ni remplacement sans interruption, sauf si la documentation de la plateforme le confirme et qu’un test l’a vérifié.

Définissez une politique de nouvelle tentative qui ne crée pas de doublons. Avant de relancer un processus, vérifiez si l’opération précédente a laissé des unités partielles et comment les identifier. Si vous ne pouvez pas le déterminer, considérez le résultat comme incertain et évitez une seconde écriture à l’aveugle. Consignez le périmètre, la décision prise et le test effectué ensuite, afin qu’un autre opérateur puisse reconstituer quelle version était disponible.

Choisir entre mise à jour incrémentielle et reconstruction

La mise à jour incrémentielle limite le travail aux documents ou aux collections concernés ; elle peut convenir lorsque le système permet d’identifier précisément chaque source et de retirer ou remplacer ses dérivés. La reconstruction traite à nouveau un ensemble plus large et peut faciliter une vérification globale, mais elle peut aussi demander davantage de temps et de ressources. Il s’agit de considérations opérationnelles générales, pas de garanties de performance ni de la description d’un outil particulier.

Comparez les deux options à partir de données issues de votre environnement : volume des sources, fréquence des changements, durée observée, coût de traitement, facilité d’identification des éléments concernés et conséquences d’une mise à jour incomplète. Ajoutez les capacités documentées de la pile en matière de mise à jour, de suppression, de consultation des états et de restauration d’une version antérieure. Si une capacité essentielle n’est pas confirmée, consignez cette incertitude et résolvez-la avant d’automatiser.

Ne choisissez pas l’incrémental uniquement parce qu’il semble moins coûteux, et ne reconstruisez pas automatiquement à chaque changement. La décision dépend de la possibilité de délimiter l’impact et de démontrer la cohérence du résultat. Un test de reconstruction dans un environnement contrôlé peut aider à estimer la durée et à repérer des différences ; il ne prouve pas, à lui seul, qu’une reconstruction en production est sans risque.

Vérifier que le corpus reflète l’état attendu

Les tests d’acceptation doivent vérifier le comportement du corpus, et pas seulement confirmer qu’une tâche technique s’est terminée sans erreur. Les informations fournies sur la création de corpus orientés RAG et leur utilisation pour l’évaluation confirment qu’il est pertinent de concevoir des vérifications pour les systèmes RAG, mais elles ne prescrivent ni une batterie de tests précise ni un seuil universel. Les requêtes et les critères doivent découler des sources et des risques propres à chaque application.

Constituez un ensemble restreint et stable de requêtes. Incluez des requêtes qui devraient récupérer une version actuelle, des requêtes distinctives portant sur une source retirée et des requêtes concernant des documents sans rapport qui doivent rester disponibles. Consignez la source et la version attendues, le résultat observé et la date d’exécution du test. Si la récupération dépend du classement, de seuils ou d’autres paramètres, notez la configuration pertinente afin de pouvoir interpréter les différences entre exécutions.

Ajoutez des tests de détection des doublons et des conflits. Une recherche peut renvoyer l’ancienne et la nouvelle version, deux copies du même document ou des fragments dont la provenance n’est pas assez précise pour les distinguer. Définissez les résultats acceptables : par exemple, une seule version active lorsque la politique exige l’exclusivité, ou les deux versions clairement identifiées lorsque leur coexistence est autorisée.

Un test négatif — ne pas récupérer une source retirée — demande de la prudence : l’absence d’un résultat pour une requête donnée ne prouve pas que la source a disparu de l’ensemble de l’index. Utilisez plusieurs requêtes représentatives et, si l’outil le permet, examinez les enregistrements associés à l’identifiant de la source. Indiquez la portée réelle de la vérification et ne transformez pas un échantillon en garantie absolue.

L’évaluation de la récupération ne permet pas non plus, à elle seule, de déterminer si le modèle rédige une réponse correcte. Si l’équipe doit également évaluer la réponse finale, elle doit maintenir un jeu de tests distinct, assorti de critères adaptés à cette tâche. Elle pourra ainsi différencier un problème d’actualité du corpus d’un problème de génération ou d’utilisation du contexte.

Routine périodique et limites des éléments disponibles

Une routine périodique devrait examiner les changements en attente, les exécutions en échec, les sources sans responsable, les versions dont l’actualité n’a pas été confirmée et les tests d’acceptation qui n’ont pas été exécutés. La fréquence dépend du rythme des changements et du niveau de risque : une collection réglementaire peut nécessiter des contrôles plus fréquents qu’une archive consultée occasionnellement. Les sources fournies ne définissent aucune périodicité universelle ; chaque équipe doit justifier la sienne.

Vérifiez également si les règles d’extraction ou de traitement ont changé depuis la dernière mise à jour et si cela impose de retraiter les documents précédents. Contrôlez que les identifiants et les métadonnées sont toujours associés aux unités récupérées. S’il est impossible de reconstituer les sources et les versions ayant contribué à un test, donnez la priorité à la résolution de ce manque de traçabilité avant d’étendre l’automatisation.

Les sources disponibles ont une portée limitée. La documentation de Microsoft confirme le sujet des pipelines de données non structurées pour l’IA ; celle de Google Cloud, l’administration et l’importation de documents dans un corpus RAG ; et l’article de l’Institut d’ingénierie des connaissances, la création de corpus pour le RAG et leur utilisation pour l’évaluation. Aucun des extraits fournis ne confirme le comportement exact d’une plateforme en matière de suppressions, de remplacements, de transactions, de reconstructions ou de mises à jour incrémentielles. Ces fonctions doivent être vérifiées dans la documentation à jour du produit et par des tests réalisés dans l’environnement réel.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.