Concept de suppression RAG pour chatbots IA : retirer le contenu de l'index, du cache et des réponses

Une fiche tarifaire a expiré, une consigne de sécurité a été retirée ou un client exige la suppression de ses données personnelles. Dans le système source, le fichier concerné se supprime rapidement. Pourtant, un chatbot de site web peut continuer à s'appuyer sur l'ancien contenu pendant des minutes, des heures, voire plus longtemps : une copie réside peut-être dans la zone d'importation, le fichier a été découpé en plusieurs fragments de texte (chunks), leurs embeddings se trouvent dans l'index vectoriel et un cache de réponses conserve une déclaration déjà formulée. Un concept de suppression RAG solide ne traite donc pas seulement le fichier source, mais l'ensemble de la chaîne de dérivation.

L'objectif n'est pas de tout détruire instantanément de manière aveugle. Il s'agit d'établir un processus contrôlé qui retire immédiatement les contenus obsolètes ou révoqués du flux de réponses actif, respecte les obligations légales et opérationnelles de conservation, puis démontre que la recherche d'informations (retrieval) et les réponses n'utilisent plus ce contenu. C'est précisément cette preuve qui distingue une simple action de nettoyage d'une procédure d'exploitation fiable.

Pourquoi la suppression dans un système RAG comporte plusieurs étapes

La génération augmentée par récupération (Retrieval-Augmented Generation ou RAG) associe un modèle linguistique à des connaissances externes. Entre la source originale et la réponse se trouvent plusieurs états techniques : le robot d'exploration (crawler) ou le téléversement, le fichier normalisé, la reconnaissance de texte, les chunks, les métadonnées, les embeddings, l'index vectoriel et plein texte, le cache de requêtes, les passages extraits et la réponse générée à partir de ceux-ci. Certains systèmes enregistrent en plus l'historique des sessions, des échantillons de qualité ou des traces. Si seul le premier état est supprimé, les copies en aval peuvent rester accessibles.

À cela s'ajoute un problème de temporalité. Une suppression peut être traitée de manière asynchrone alors que de nouvelles requêtes arrivent en parallèle. Une réindexation nocturne ne suffit pas : jusqu'à son exécution, le chatbot pourrait continuer à fournir l'information révoquée. Inversement, un import ultérieur ne doit pas restaurer la source par inadvertance. C'est pourquoi chaque suppression nécessite à la fois un blocage rapide dans le chemin des requêtes et un nettoyage complet en arrière-plan.

Définir clairement le périmètre de suppression au préalable

Tout commence par une identité de source stable. Le nom de fichier ou l'URL seuls sont souvent insuffisants, car ils peuvent changer ou apparaître plusieurs fois. Il est judicieux d'utiliser un ID de source interne, la version, le tenant (client), la langue, le domaine d'accès et un hachage (hash) du contenu importé. Chaque chunk et chaque entrée d'index doivent pouvoir être rattachés à cette identité. Ce n'est qu'à cette condition qu'il est possible de déterminer avec certitude quelles dérivations appartiennent à une source.

On définit ensuite ce que signifie « supprimé » dans le cas concret. Pour une information produit obsolète, il peut suffire de la désactiver de la base de connaissances active et de la remplacer par une nouvelle version. Lors d'une rétractation, d'une demande relative à la protection des données ou de la fin d'une licence, des délais plus stricts et des emplacements de stockage supplémentaires peuvent être concernés. Les sauvegardes, les journaux de sécurité et les preuves requises par la loi ont souvent leurs propres règles. La décision doit donc impliquer les responsables des données, les équipes d'exploitation et, pour les contenus à caractère personnel ou réglementés, les responsables du RGPD ou du service juridique.

Un processus de suppression sécurisé en sept étapes

1. Enregistrer et vérifier la demande : Notez l'ID de la source, la version, le motif, le délai demandé, les tenants concernés et la personne ou le rôle ayant validé l'action. Pour les suppressions sensibles, les autorisations doivent être vérifiées avant toute modification des données.
2. Placer un tombstone : Marquez immédiatement la source comme bloquée. Les filtres de retrieval doivent prendre en compte ce statut afin que les chunks associés ne soient plus inclus dans de nouvelles réponses, même si le nettoyage physique est toujours en cours.
3. Résoudre les dépendances : Identifiez les copies brutes, les résultats du parseur, les chunks, les embeddings, les documents plein texte, les caches, les éléments de réponse prégénérés et, le cas échéant, les jeux de données de test. L'ID de la source sert de clé commune.
4. Nettoyer les index actifs : Supprimez ou désactivez tous les enregistrements concernés dans les index vectoriels et de mots-clés. Vérifiez les retours du service concerné ; une tâche acceptée n'est pas encore une preuve de suppression terminée.
5. Invalider les caches : Videz de manière ciblée les caches de retrieval, de requête et de réponse. Si une invalidation sélective est impossible, utilisez des clés de version ou un nouveau namespace pour rendre les anciennes entrées inaccessibles.
6. Exécuter les tests de confirmation : Effectuez des recherches sur des formulations connues, des titres de documents, des termes rares et des variantes sémantiquement proches. Une interrogation directe par ID de source et un échantillonnage dans le chatbot doivent tous deux rester sans résultat.
7. Clôturer l'opération : Enregistrez un journal de suppression concis indiquant l'horodatage, le périmètre, les réponses du système, le résultat de la vérification et les délais de conservation restants. Ce journal doit prouver l'opération sans copier inutilement le contenu supprimé.

Pourquoi le tombstone intervient avant la suppression physique

Cet ordre évite deux erreurs classiques. Premièrement, un robot d'exploration (crawler) ne peut pas toujours associer proprement un fichier source supprimé à une entrée d'index existante. Certains indexeurs attendent un signal de suppression logique (soft delete) tant que la source reste reconnaissable. Deuxièmement, des tâches en cours peuvent réécrire des données entre la suppression de la source et le nettoyage de l'index. Un tombstone central bloque cette réintégration. Il doit être conservé même si les données utiles elles-mêmes ont déjà été retirées – mais uniquement avec les métadonnées minimales nécessaires et une durée de conservation claire.

Le versionnage rend la suppression de cache maîtrisable

Les caches sont particulièrement vulnérables aux erreurs si les clés ne contiennent que la question de l'utilisateur. Il est préférable d'utiliser une clé incluant également la version de la base de connaissances, le tenant, la langue et le contexte d'autorisation. Après une suppression, la version est incrémentée. Même si une entrée de cache individuelle existe techniquement encore jusqu'à son expiration, l'application active ne peut plus la solliciter. Cela ne remplace pas l'invalidation ciblée dans tous les cas, mais réduit le risque de réapparition d'anciennes réponses.

Les caches HTTP suivent quant à eux leurs propres règles. La norme RFC 9111 décrit le moment où les réponses stockées sont fraîches, obsolètes ou doivent être invalidées. Pour les applications RAG, cela signifie qu'il faut traiter séparément le cache du CDN, de l'API et de l'application. Une nouvelle version de base de données ne suffit pas à elle seule à vider un cache de réponse distribué en périphérie (edge).

Exemple concret : Une notice de montage retirée

Admettons qu'un fabricant retire la version 3 d'une notice de montage en raison d'une modification apportée à une étape d'assemblage. La version 4 est déjà validée. Le système place immédiatement un tombstone pour la source V3 et publie la V4 sous un nouvel ID de version. Le moteur de retrieval filtre exclusivement les sources validées et privilégie la version actuelle. En parallèle, un processus en arrière-plan supprime l'ensemble des chunks V3 des index vectoriels et plein texte, et invalide les caches dont la liste de dépendances contient cet ID de source.

L'assurance qualité ne se contente pas de poser la question « Comment monter le composant ? ». Elle utilise également une formulation spécifique de la V3, une question paraphrasée ainsi qu'une question à laquelle on ne pouvait répondre auparavant qu'avec la V3. Le résultat attendu est soit la réponse étayée issue de la V4, soit une indication claire qu'aucune information validée n'est disponible. Une citation de source pointant vers la V3, un fragment littéral ou une réponse sans référence actuelle est considéré comme une erreur. Pour savoir comment afficher les sources dans les réponses, consultez l'article Justifier les réponses d'un chatbot avec des sources.

Vérifier si la suppression est réellement effective

Un statut API au vert ne suffit pas. La vérification doit s'effectuer à plusieurs niveaux. Au niveau du stockage, on recherche l'ID de la source, les ID de chunks et les hachages connus. Au niveau du retrieval, on exécute des questions de test et on contrôle les extraits renvoyés. Au niveau de la réponse, on vérifie si l'ancienne affirmation apparaît encore textuellement ou selon le sens. Enfin, un test de redémarrage est nécessaire : après l'exécution du crawler, la reconstruction de l'index ou la restauration d'une sauvegarde, la source ne doit pas réapparaître.

Conservez pour chaque catégorie de connaissances critique un petit jeu de référence (Golden Set) composé de cas positifs et négatifs. Les cas positifs prouvent que la source de remplacement est correctement trouvée ; les cas négatifs montrent que les informations bloquées ne réapparaissent plus. Cette procédure complète le contrôle continu de la Qualité pour maintenir à jour la base de connaissances d'un chatbot IA. Lors de modifications d'index majeures, une reconstruction parallèle avec basculement contrôlé s'avère utile, comme décrit dans le guide sur le Changement de modèle d'embeddings RAG.

Check-list pour l'exploitation au quotidien

• Chaque source possède un ID stable, une version, une origine, une langue et un responsable identifié.
• Les chunks, embeddings, documents d'index et caches peuvent être rattachés à cet ID de source.
• Un tombstone bloque immédiatement la source dans le retrieval et empêche toute réimportation.
• L'ordre de suppression est idempotent : une répétition ne génère ni erreur ni nouvel enregistrement.
• Les tâches d'arrière-plan ne renvoient pas seulement un statut « accepté », mais un état finalisé avec le détail des erreurs.
• Les caches de retrieval et de réponse peuvent être invalidés de manière sélective ou dissociés via le versionnage.
• La recherche directe, la recherche sémantique, le test de réponse et le test de redémarrage sont documentés.
• Les sauvegardes et les journaux ont des durées de conservation définies et une procédure pour les restaurations ultérieures.
• Le journal de suppression ne contient que les métadonnées nécessaires et aucune copie inutile du contenu retiré.
• La responsabilité, la procédure d'escalade et le délai maximal de traitement sont définis et régulièrement testés.

Ne pas confondre gouvernance et protection des données

Un concept de suppression technique explique comment une source disparaît en toute sécurité du flux RAG actif. Déterminer si et quand elle doit être supprimée est une autre question. Le Règlement Général sur la Protection des Données (RGPD) prévoit à l'article 17 un droit à l'effacement sous certaines conditions, ainsi que des exceptions. Une affirmation globale telle que « chaque demande supprime immédiatement chaque sauvegarde » serait donc tout aussi risquée qu'un stockage indéfini sans motif. La base juridique et le délai applicables doivent être définis pour chaque cas d'usage ; le texte officiel du règlement est accessible via EUR-Lex.

Sur le plan organisationnel, le processus s'inscrit dans la gouvernance des contenus (Content Governance) : Qui a le droit de retirer du contenu ? Qui confirme le nettoyage ? Que se passe-t-il si un service vectoriel externe est indisponible ? L'article Gouvernance du contenu pour chatbots IA montre comment s meublent les rôles des responsables, les validations et le contrôle des modifications (Change Control). Pour les risques élevés, le principe du double contrôle est recommandé ; pour les mises à jour standard, un flux de travail automatisé et entièrement journalisé peut suffire.

Sources officielles et références techniques

• Microsoft Learn : Détection des blobs modifiés et supprimés dans Azure AI Search
• Microsoft Learn : API Documents pour Azure AI Search
• Google Cloud : Gérer les fichiers et corpus dans Vertex AI RAG Engine
• RFC Editor : RFC 9111 – HTTP Caching
• NIST : Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex : Règlement Général sur la Protection des Données

Conclusion : La capacité de suppression est une fonction de qualité

Une base de connaissances RAG n'est fiable que si les contenus peuvent non seulement être intégrés, mais aussi retirés de manière contrôlée. Des ID de source stables, des tombstones, des registres de dépendances, des caches versionnés et des tests répétables transforment une intervention ponctuelle incertaine en un processus maîtrisé. Associer la validation fonctionnelle, le nettoyage technique et une assurance qualité traçable permet de réduire les réponses obsolètes et de poser les bases d'un chatbot dont l'apprentissage et le savoir sont rigoureusement pilotés.