Retirer un document RAG sans laisser ses copies répondre

Une procédure est retirée, mais le chatbot continue de reprendre son ancienne règle. Le fichier source a disparu du parcours documentaire ; son passage reste dans l’index, une réponse en cache ou une conversation sauvegardée. Une ingestion en attente peut même le remettre après nettoyage. Le risque concerne la chaîne de copies et leur autorité, pas seulement la présence du document dans son répertoire initial.

En pratique, le retrait doit fermer l’utilisation de la source, puis suivre la purge des objets qui en dépendent. Une recherche sans résultat ne prouve pas que toutes les copies ont disparu. La conception d’un RAG d’entreprise doit conserver l’identité documentaire dans index, réponses et tâches pour empêcher qu’un ancien état redevienne admissible après une reprise.

Seize cas SQLite et FTS5 suivent un document dans l’index, le cache, l’historique et une tâche différée. Aucun LLM ou moteur vectoriel n’est utilisé. Retirer l’entrée de recherche laisse certaines copies accessibles tant que leur contrôle accepte encore la source ; supprimer des lignes ne prouve pas non plus un effacement physique. L’accompagnement IA sur mesure de Dawap peut établir cet inventaire des dérivés et qualifier les accès à fermer avant leur purge.

Pour qui le retrait dépasse la suppression d’un fichier

Distinguer règle retirée, source remplacée et accès révoqué

Un propriétaire peut retirer une procédure devenue fausse, remplacer une pièce ou fermer son usage pour certains lecteurs. Ces événements ne possèdent pas le même périmètre. La révocation porte sur les permissions ; le retrait global porte sur l’admissibilité du document. Le service doit savoir ce qui est décidé, par qui et quels objets dérivés doivent changer, au lieu de convertir tous les événements en une suppression d’index indistincte.

Le document fictif D38 contient une courte procédure de remplacement, génération 1 et révision 3. Son retrait rend la génération 2 inactive. Une réouverture explicite produit ensuite génération 3, révision 4 et nouveau contenu. Les valeurs ne constituent pas une règle métier de délai. Elles permettent de retrouver si un passage appartient à l’époque admise ou à celle qui a été retirée.

Décider ce qui reste consultable comme historique

Une ancienne pièce peut parfois rester consultable pour expliquer une décision passée, tout en cessant d’être une référence pour une nouvelle réponse. Cette politique doit être explicite, avec lecteurs et usages admis. Le banc choisit un retrait strict des anciens snapshots. Il ne résout pas une politique de conservation historique ni une obligation d’archivage ; ces décisions doivent être qualifiées dans le contexte du système concerné.

Le métier fixe le besoin de retrait et l’équipe technique identifie les supports qui continuent à produire ou conserver une information. Une liste de fichiers à supprimer ne suffit pas lorsqu’un résumé, une citation ou une file d’ingestion porte encore la source. La recette doit partir d’une question que l’ancienne pièce pouvait soutenir, puis examiner les différents chemins susceptibles de la réintroduire.

Identifier la source et la génération de ses dérivés

Donner au fragment un lien vers la décision de cycle de vie

Chaque snapshot du banc conserve doc_id, generation, revision et body. L’identifiant retrouve la source ; la génération distingue retrait et réouverture ; la révision et le contenu vérifient la version précise. Un titre ou un chemin seul serait fragile face à renommage et remplacement. L’indexation doit transmettre les repères nécessaires à la décision plutôt que fabriquer des fragments dont l’origine devient introuvable.

La génération du laboratoire est un entier choisi localement. Elle n’est pas un mécanisme natif commun à tous les moteurs. En production, le contrat doit définir comment ce repère est attribué, conservé et propagé, et ce qui se passe lorsque la source d’autorité manque. Une marque de retrait perdue lors d’une restauration peut rendre de nouveau admissible un objet que le propriétaire avait fermé.

Conserver les contributeurs des réponses assemblées

Une réponse peut mêler plusieurs documents et l’historique. Son invalidation demande de retrouver les sources qui ont réellement contribué, pas seulement la dernière citation affichée. Un résumé stocké sans provenance ne permet pas toujours de retirer le fait issu d’une pièce particulière. La politique doit décider s’il faut purger, réexaminer ou fermer l’objet entier lorsque cette dépendance est connue ou incertaine.

Notre cache et notre historique contiennent seulement un snapshot documentaire structuré. Aucun résumé libre ni réponse générée n’est enregistré. La vérification de leur provenance est donc volontairement étroite. Une recette LLM doit ajouter faits implicites, réponses combinées et sources non citées, afin qu’une liste de références propre ne masque pas une affirmation encore héritée d’un document retiré.

Fermer l’usage avant de terminer la purge

Séparer admissibilité et existence matérielle d’une copie

R38-02 retire la source sans nettoyer ses dérivés. La recherche brute retrouve encore un passage, mais la sélection contrôlée en admet zéro et le cache reçoit retired. Cette expérience montre un arrêt d’usage applicatif alors que les tables conservent des données. Elle ne constitue pas une suppression complète. Les accès directs à la base pourraient contourner le contrôleur, dont la portée doit rester explicite.

SELECT chunks.doc_id, chunks.generation, chunks.revision, chunks.body
FROM chunks
JOIN source AS current ON current.doc_id = chunks.doc_id
WHERE chunks MATCH ? AND current.active = 1
AND current.generation = chunks.generation
AND current.revision = chunks.revision AND current.body = chunks.body
ORDER BY chunks.doc_id

La requête exige une source active et un fragment dont génération, révision et contenu correspondent. Le contrôle des copies applique les mêmes dimensions. Si l’autorité est indisponible dans R38-11, le banc ferme la sélection et la copie. La production doit décider son comportement avec un registre de retrait inaccessible, en fonction des exigences de lecture et des garanties de propagation effectivement possibles.

Revalider un passage qui avait été sélectionné avant le retrait

Un passage peut quitter l’index avant que le retrait soit connu du service qui construit le contexte. La recette doit vérifier les objets déjà sélectionnés avant leur utilisation et leur restitution. Le contrôle local reçoit l’ancien snapshot et le compare au registre courant. Cette frontière permet de fermer une copie, mais ne récupère pas une information déjà transmise au modèle, au lecteur ou à un autre service.

La production doit donc nommer les fenêtres entre contrôle, génération et affichage. Annuler une demande en cours peut réduire certains usages futurs ; cela n’efface pas automatiquement ses transmissions antérieures. Les journaux et sorties doivent permettre de retrouver quelles versions ont pu contribuer. Le laboratoire ne mesure pas ces fenêtres distribuées ni une capacité d’annulation d’un fournisseur.

Vérifier la disparition dans les lectures du moteur

Éprouver l’API et le périmètre de suppression réellement utilisés

La purge locale utilise DELETE sur les lignes FTS5 ; la recherche brute du fichier ne retrouve ensuite aucun passage. Un moteur distant possède ses propres opérations, namespaces, filtres et délais de visibilité. La documentation Pinecone sur la suppression distingue les opérations selon le type d’index et rappelle la cohérence éventuelle de la visibilité. Aucun appel Pinecone n’est effectué ici.

La recette réelle doit vérifier identifiants de fragments, périmètre de société et totalité des branches de recherche. Une suppression dans un index vectoriel ne prouve pas le nettoyage de l’index lexical d’une recherche hybride. Le résultat de commande et le résultat des lectures sont deux observations à conserver. Un compteur global stable ne permet pas à lui seul de retrouver la source précise qui devait disparaître.

Distinguer acquittement et visibilité pour une nouvelle question

La documentation Elasticsearch du paramètre refresh explique les conditions de visibilité des changements et le rôle de wait_for. Le moteur et la requête retenus doivent être testés avec leur configuration. Le banc SQLite lit après commit local ; il ne reproduit pas une période de cohérence éventuelle ou un refresh distribué.

Le délai de retrait doit être observé depuis le geste du propriétaire jusqu’aux lectures concernées, avec des points de contrôle attribués. Il n’existe pas de durée universelle déduite de nos seize cas. Une exigence courte peut nécessiter fermeture applicative immédiate puis purge suivie. L’équipe conserve le seuil convenu, les mesures et les chemins encore ouverts au lieu d’annoncer tout supprimé dès l’acquittement d’une seule API.

Bloquer puis purger les valeurs en cache

Reconnaître une réponse conservée après nettoyage de l’index

Cas concret : R38-03 purge l’index sans retirer la source. La recherche ne retrouve rien, mais la copie cache reste admitted. R38-04 retire d’abord la source puis purge l’index ; le cache subsiste matériellement et sa lecture est refusée. La paire montre pourquoi absence de résultat dans l’index et disparition des réponses conservées ne doivent pas être annoncées comme une même preuve.

Une clé de cache peut contenir personne, question ou version de service sans porter toutes les sources contributrices. Le retrait doit retrouver les valeurs dépendantes, avec une purge ou une revalidation adaptée. Augmenter la version du prompt peut contourner une ancienne clé pour les nouvelles requêtes, sans supprimer les données de l’ancien cache. Les deux effets doivent être distingués dans le suivi de cycle de vie.

Retirer les copies selon leur support et leur lecteur

Le banc nettoie une table locale ; un système réel peut avoir plusieurs instances, régions ou caches de navigateur. Les règles de conservation et d’invalidation doivent être vérifiées pour ces supports. Les permissions et le registre de retrait restent utiles avant restitution, même si une tâche de purge est prévue. Une durée de vie ne garantit pas la fermeture d’un usage pendant tout son intervalle.

Le coût caché comprend inventaire des dépendances, invalidations répétées, lectures de statut et vérification des objets manqués. La production doit décider quels caches valent cette charge et comment observer leur nettoyage. Une réponse générée sans provenance complète peut exiger fermeture plus large ou réexamen manuel. Le laboratoire ne démontre pas une purge de ces objets ni leur conformité à une politique réelle de conservation.

Traiter les conversations et citations déjà conservées

Distinguer rendu contrôlé et contenu encore stocké

R38-10 retire D38 ; la lecture contrôlée de l’historique reçoit retired. Un accès SQL brut retrouve encore le mot sept dans son payload. Le contenu reste donc présent avant purge, malgré l’arrêt de son affichage par le contrôleur. Une interface qui restitue directement la conversation sans cette vérification pourrait reprendre l’ancienne information. Le test ne cache pas ce reste sous le vocabulaire de suppression.

Une conversation peut également avoir été exportée, copiée ou transmise hors du service. Son inventaire dépasse l’index et le cache serveur. Le propriétaire doit qualifier ces destinations et les actions possibles sur chacune. Le système ne peut pas promettre de rappeler une réponse déjà lue ou une copie qu’il ne contrôle plus. Il doit préciser ses preuves et la portée des opérations disponibles.

Réexaminer la citation et la réponse qui la contient

Fermer l’ouverture d’une ancienne citation n’enlève pas nécessairement le fait présent dans la réponse. Le service doit traiter la référence et ses objets dépendants, selon la politique d’historique retenue. Une citation peut porter seulement un identifiant tandis que le corps de conversation contient un extrait. Ces deux supports doivent rejoindre la recette de retrait plutôt que d’être considérés comme une copie unique.

Le banc ne rend pas une interface de conversation ni un lien de citation externe ; il contrôle un snapshot structuré. La production doit tester conversation sauvegardée, nouvelle question qui la reprend et accès au document cité. Les variantes de rendu et de partage doivent conserver la décision de cycle de vie. Une réponse nouvelle ne doit pas hériter automatiquement d’un fait fermé parce qu’il est visible dans un ancien tour.

Refuser une ancienne tâche après retrait ou réouverture

Vérifier l’admissibilité au moment d’écrire dans l’index

Une tâche peut avoir lu la source avant son retrait et terminer plus tard. R38-06 purge les passages après fermeture, puis présente l’ancien snapshot à la fonction d’ingestion. Le verdict ingest_retired ne crée aucune ligne. L’absence actuelle dans l’index ne suffirait pas si le worker pouvait réécrire ce qu’il avait préparé. Il doit consulter l’autorité courante avant de publier ses dérivés.

Le banc conserve une tâche en table et utilise sa copie initiale pour représenter cet ancien travail. Aucun broker, worker concurrent ou connecteur n’est lancé. Une production doit tester attente, retry et publication avec son infrastructure réelle. La fenêtre entre vérification et écriture doit aussi être traitée, car un retrait intervenant dans cet intervalle ne serait pas automatiquement rendu atomique par le contrôle local montré ici.

Empêcher la réouverture de rendre l’ancienne époque valable

R38-08 rouvre D38 sous génération 3 et reçoit pourtant ingest_generation_mismatch pour la tâche de génération 1. R38-09 utilise le nouveau snapshot, révision 4, et réindexe un passage admissible. La réouverture est une décision explicite ; elle ne donne pas une seconde vie à tous les objets anciens qui portent encore le même doc_id.

Paradoxalement, garder un repère de retrait peut être nécessaire après purge afin de bloquer une arrivée tardive. Ce repère n’a pas besoin de conserver tout le contenu fermé, selon le contrat retenu. Le laboratoire garde le corps source pour ses comparaisons ; il ne propose pas ce choix comme politique universelle. La durée et le support du marqueur doivent couvrir les reprises et restaurations effectivement possibles.

Seize cas et les copies qui restent dans le banc

Compter les objets au lieu de déduire la purge d’une réponse vide

Les fichiers SQLite sont créés séparément pour chaque cas avec le même état initial. Les compteurs couvrent les lignes de passages, cache, historique et tâches, dans cet ordre. Le tableau distingue résultats bruts et admissibles de la recherche. Il ne compte ni octets de fichier ni copies en mémoire Python. Le corps du registre source reste conservé dans tous les essais sauf R38-12, qui retire sa ligne.

R38-05 ferme la source et nettoie les quatre tables dérivées ; tous leurs compteurs valent zéro, mais sourceBodyRetained reste vrai. Ce résultat ne s’appelle donc pas effacement complet. R38-16 remplace la valeur cache par un snapshot actuel après réouverture : le cache devient admissible, tandis que l’index ancien ne l’est toujours pas. Chaque support doit être vérifié selon son propre état.

Rapprocher le verdict au support réellement contrôlé

Admitted qualifie la copie cache dans R38-01, R38-03 et R38-16 ; il ne déclare pas tout le système admissible. Les verdicts d’ingestion portent sur la tentative de publication. Les colonnes de lecture restent séparées. Cette distinction empêche de confondre un cache actuel avec un index nettoyé, ou une tâche refusée avec une purge déjà achevée de son payload.

Exemple concret de reprise : R38-13 réinsère manuellement une ancienne ligne après purge. Le registre encore inactif ferme son usage. Ce test représente un retour de dérivé ancien, sans exécuter une vraie restauration de sauvegarde. Une production doit vérifier aussi le retour du registre, des caches et des files ; restaurer ensemble un ancien index et une ancienne autorité pourrait annuler la protection présentée.

Distinguer tables vides et effacement complet

Définir ce que la preuve SQL couvre

Le banc utilise SQLite 3.53.1 avec FTS5. Un compteur nul et une recherche vide attestent l’état des tables lues dans ce fichier après les commandes exécutées. Ils ne prouvent pas que les octets anciens sont irrécupérables. La documentation FTS5 sur secure-delete distingue conservation interne d’entrées supprimées et options de nettoyage. Aucun test forensique ou réglage d’effacement physique n’est exécuté ici.

Le registre source, les snapshots conservés en mémoire par le programme et les fichiers de résultats font partie du laboratoire. Les quatre compteurs ne sont donc pas un inventaire exhaustif de toutes ses représentations. Une politique de suppression doit préciser stockage, sauvegardes et destinataires à couvrir. Notre expérience montre fermeture et purge de tables ciblées, sans attribuer à ces opérations une portée qu’elles n’ont pas.

Vérifier les copies détenues par d’autres composants

Un service de modèle peut avoir reçu un contexte, un reranker des passages et un outil de support des traces. Leurs interfaces et conditions de conservation doivent être qualifiées séparément. Aucun de ces services n’est utilisé dans le banc. La suppression d’un document dans le RAG local ne démontre pas leur nettoyage, pas davantage que l’absence d’une citation ne démontre le retrait des faits d’une réponse déjà produite.

Le délai et la preuve attendus doivent être définis pour chaque composant. Certains objets peuvent être invalidés immédiatement, d’autres purgés par une tâche vérifiable, d’autres conservés selon une décision applicable. Le responsable retrouve le support, les lecteurs possibles et le résultat de l’opération. Une copie non contrôlée reste dans les éléments à traiter ; elle ne disparaît pas de l’inventaire parce que le moteur principal a terminé sa purge.

Erreurs fréquentes dans le cycle de vie d’un corpus RAG

Annoncer la suppression à partir du seul moteur principal

Un delete réussi peut laisser un cache, une branche lexicale, un historique et une tâche ancienne. Le service doit conserver un inventaire et vérifier leurs transitions, avec une preuve par support. Un signal faible apparaît lorsque la nouvelle recherche ne retourne plus la source mais qu’une réponse identique revient sur une question fréquente. La revue doit suivre les copies plutôt que modifier le prompt pour cacher le symptôme.

Une autre erreur consiste à reconstruire l’index depuis une exportation plus ancienne sans appliquer les retraits survenus depuis. La reconstruction peut réintroduire des pièces parfaitement indexables mais fermées. Le contrat doit conserver l’autorité de cycle de vie lors des replays, avec contrôle de génération. Un index neuf ne signifie pas que ses sources sont actuellement admissibles.

Effacer la marque de retrait avant les arrivées tardives

Si la seule preuve de fermeture disparaît tandis qu’une ancienne tâche peut encore publier, le service risque de traiter son arrivée comme une première ingestion. La durée de conservation du repère doit être justifiée par les fenêtres de reprise et les supports réels. Une source introuvable doit avoir un comportement défini. Le banc ferme source_missing au lieu d’autoriser le snapshot faute de contradiction disponible.

Un autre signal est un pic de réapparitions après maintenance ou réouverture du corpus. Le même identifiant peut avoir été réutilisé sans changement d’époque, ou un ancien cache peut avoir retrouvé sa clé. L’équipe doit rapprocher générations, révisions et tâches, puis tester le nouveau parcours. Augmenter la fréquence de purge ne corrige pas une publication qui ne vérifie jamais l’admissibilité courante.

Plan d’action pour une preuve de retrait suivie

Le contrat de retrait décrit entrée, périmètre et sorties attendues : usage fermé, purge demandée puis purge observée. La responsabilité du registre et de chaque support est attribuée. L’instrumentation retrouve source, génération et motif de conservation. Le repli ferme les copies non vérifiables sans déclarer leur effacement ; le propriétaire peut suivre séparément ce qui ne répond plus et ce qui reste à nettoyer.

1. Qualifier le geste documentaire. Définissez retrait global, nouvelle version ou révocation de lecture. Identifiez le propriétaire et la pièce précise, avec un repère stable. Choisissez si un historique reste consultable et dans quel contexte, avant de transmettre des commandes techniques qui pourraient fermer trop ou pas assez.
2. Inventorier les dérivés et leur provenance. Suivez passages, index, réponses, conversations, traces et tâches. Vérifiez les sources contributrices des objets composés. Nommez les copies hors du contrôle direct du service, avec les moyens disponibles pour les traiter et les limites qui devront rester visibles dans la preuve finale.
3. Fermer l’admissibilité puis suivre la purge. Établissez l’autorité de retrait et contrôlez sélection, contexte et restitution. Lancez les opérations propres à chaque support. Mesurez le délai depuis la décision jusqu’aux lectures et aux suppressions attendues, avec les compteurs et requêtes qui permettent de retrouver cette source.
4. Provoquer les retours d’anciens objets. Présentez une tâche en attente, une copie cache et une conversation conservée. Testez réouverture, révision modifiée et dérivé réintroduit. Ajoutez restauration réelle dans l’environnement prévu, avec l’autorité de retrait conservée ou reconstruite selon une règle prouvée.
5. Clôturer selon des preuves distinctes. Conservez usage fermé, tables purgées et supports encore concernés comme états différents. Fixez seuil de revue et responsable des exceptions. La clôture indique ce qui a été observé, ce qui est conservé et ce qui ne peut pas être rappelé, sans transformer une réponse vide en garantie totale.

Le rollback doit préciser si le corpus rouvre et quelles générations peuvent revenir. Restaurer le service ou son index ne doit pas réactiver implicitement une pièce retirée. La traçabilité conserve les décisions et leurs dépendances, avec les permissions nécessaires à la reprise. La recette de retour peut alors distinguer une ingestion actuelle autorisée d’un ancien payload qui attendait simplement une nouvelle occasion de publication.

Guides pour accès, découpage et mémoire de mission

Conserver la source dans sa preuve documentaire

Le RAG documentaire fondé sur corpus, accès et preuve place l’admissibilité avant l’interprétation d’une réponse. Le découpage d’un corpus RAG doit conserver cette origine dans les fragments. La purge ne peut pas retrouver correctement leurs dépendances si la transformation a perdu la pièce initiale.

Le contrôle des droits sur passages, citations et caches traite les lecteurs qui peuvent accéder à une pièce. Le retrait ajoute une autre condition : le document reste-t-il admis par son propriétaire ? Une permission de lecture peut rester présente alors que la procédure entière a été fermée pour les nouvelles réponses.

Éviter que la mémoire transporte une autorité retirée

La mémoire d’un agent entre état de mission et sources distingue faits acquis et références à revalider. Le retrait documentaire ne doit pas effacer arbitrairement l’état du travail, mais il doit fermer les preuves devenues inadmissibles. Une mission peut conserver une décision passée tout en demandant de nouvelles sources pour sa prochaine étape.

Le traitement des versions contradictoires complète ce contrôle lorsque plusieurs pièces restent admises. Une source fermée ne constitue plus un vote concurrent sur la règle actuelle. Le service doit d’abord décider son usage possible, puis comparer les preuves restantes. La présence des anciens mots dans une mémoire ne leur attribue pas une autorité que le corpus courant ne reconnaît plus.

Conclusion : retirer l’autorité et suivre les copies

Le retrait d’une source et la suppression de ses représentations répondent à des questions différentes. Le premier ferme son usage selon une décision courante ; la seconde nettoie des supports avec leurs propres moyens. Le service doit garder identité et provenance pour contrôler les copies déjà présentes et les tâches susceptibles de revenir. Une réouverture explicite ne valide pas automatiquement l’ancien contenu.

Les seize cas FTS5 montrent ces distinctions sur un fichier local : un cache survit à la purge d’index, le registre fermé bloque ses usages et une ancienne ingestion reste refusée sous une nouvelle génération. Les tables dérivées peuvent être vides alors que le corps source est encore conservé. Aucun effacement physique, service distant ou réponse générée n’est éprouvé dans ce laboratoire.

La construction d’un RAG d’entreprise doit définir ces états avec les propriétaires documentaires et les équipes d’exploitation. La recette suit les lectures, les purges et les retours d’anciens dérivés dans l’environnement réel. Elle donne une preuve dont le périmètre reste explicite, avec les copies encore concernées et leur responsable.

Pour retirer une pièce utilisée par votre RAG, notre expertise IA sur mesure peut identifier ses copies et tester leur fermeture avant la purge. Le contrôle doit couvrir un passage déjà sélectionné, une réponse en cache et une tâche encore en attente. Une réouverture explicite crée une nouvelle génération de référence ; les anciennes copies doivent rester refusées. Les supports externes et exigences d’effacement nécessitent ensuite leurs propres vérifications.