Un assistant RAG doit pouvoir retirer une source et ses dérivés, puis démontrer qu'ils ne participent plus aux nouvelles réponses. Supprimer le fichier d'origine ne suffit pas si des fragments, des copies d'index ou des réponses mises en cache restent accessibles.
Le passage d'une démonstration à un service documentaire change la question technique. Pendant le prototype, on vérifie surtout que l'assistant retrouve une bonne réponse. En exploitation, il faut aussi vérifier qu'il cesse de donner une réponse devenue fausse. Les procédures changent, les droits d'accès évoluent et certaines sources sont retirées sans être remplacées.
Une réponse exacte hier peut devenir dangereuse aujourd'hui
Prenons un scénario fictif : une entreprise utilise un assistant pour expliquer ses procédures de retour de matériel. Une ancienne version autorise l'envoi direct vers un atelier. La nouvelle demande d'abord un accord du service concerné. Les deux documents portent presque le même titre et contiennent de nombreux paragraphes identiques.
Si les deux versions restent dans l'index, leur proximité sémantique ne permet pas de déterminer laquelle fait autorité. Un modèle peut produire une réponse cohérente en mélangeant des étapes incompatibles. Le problème n'est pas seulement la qualité de la génération : la règle de validité documentaire manque en amont.
L'équipe métier doit donc pouvoir désigner la version active, sa date d'effet et les versions remplacées. La date de modification du fichier ne représente pas nécessairement la date à laquelle une procédure devient applicable.
Construire une identité documentaire qui traverse les copies
Attribuez un identifiant stable au document logique et un identifiant distinct à chaque version. Chaque fragment doit conserver ce lien, avec son emplacement dans la source et les règles d'accès nécessaires à la recherche.
Cette filiation permet de répondre à une question simple : où les informations de cette version ont-elles été copiées ? La réponse peut inclure l'index de recherche, des résumés intermédiaires, un cache de réponses et un jeu d'évaluation. Le périmètre dépend de l'architecture réellement utilisée.
Ne transformez pas cette liste en promesse de suppression absolue. Les journaux, sauvegardes et obligations de conservation éventuelles demandent un traitement séparé. L'objectif opérationnel ici est précis : empêcher une version retirée d'alimenter les nouvelles réponses, tout en documentant le devenir des autres copies.
Le connecteur doit observer le retrait
La documentation Azure AI Search sur les blobs supprimés décrit une politique de détection fondée sur la suppression réversible. L'indexeur doit voir l'objet dans cet état pour retirer le document correspondant. Microsoft recommande une rétention suffisamment supérieure à l'intervalle d'indexation pour laisser le temps au traitement.
Cette dépendance explique un échec fréquent de conception : retirer définitivement une source avant que le connecteur ait observé son retrait. Un pipeline d'ajout parfaitement fiable ne devient pas automatiquement un pipeline de suppression fiable.
Dans le scénario proposé, un registre marque d'abord la version comme retirée. Le traitement identifie ses fragments et déclenche les opérations nécessaires. Une vérification ultérieure confirme leur absence dans les résultats accessibles. Si le traitement échoue, le registre conserve une tâche visible avec un responsable.
Distinguer écriture, recherche et réponse
Les modifications d'un moteur de recherche ne sont pas toujours immédiatement visibles aux requêtes. Elastic décrit le rôle du rafraîchissement dans la recherche quasi temps réel. Ce mécanisme est un exemple concret de la différence entre accepter une opération et observer son effet dans la recherche.
Un RAG ajoute encore une étape : une génération peut déjà avoir récupéré l'ancienne source lorsqu'un retrait intervient. Définissez ce qui doit arriver à cette réponse en cours. Pour une procédure sensible, une vérification de validité avant affichage peut imposer une nouvelle recherche ou un message d'indisponibilité.
Les caches doivent suivre la même décision. Conserver uniquement le texte final, sans les identifiants des sources utilisées, rend leur invalidation beaucoup plus difficile. Une réponse stockée doit pouvoir être rattachée aux versions dont elle dépend.
Faire du retrait un exercice reproductible
Préparez un petit dossier de recette avec la procédure ancienne, sa remplaçante et des questions qui distinguent clairement leurs réponses. L'exercice doit porter sur le résultat visible par l'utilisateur, pas uniquement sur un compteur technique.
- ▸Poser la question avant la mise à jour et relever la source citée.
- ▸Activer la nouvelle version et vérifier la date d'effet attendue.
- ▸Retirer l'ancienne version pendant une indexation interrompue.
- ▸Relancer le traitement et vérifier les fragments, citations et caches.
- ▸Retirer aussi la nouvelle version et vérifier que l'assistant signale l'absence de source valable.
Ajoutez un utilisateur dont les droits viennent d'être révoqués. Ce cas teste une autre cause d'inéligibilité documentaire : le document existe encore, mais cette personne ne doit plus pouvoir l'utiliser. Le contrôle doit couvrir les réponses déjà en cache, selon la politique retenue.
Choisir une fraîcheur adaptée au métier
Toutes les sources ne demandent pas le même délai de propagation. Une notice stable peut tolérer une synchronisation périodique. Une instruction opérationnelle modifiée en urgence peut exiger un blocage immédiat à la lecture, même si le nettoyage physique est encore en cours.
Exprimez cette différence dans le service attendu : délai de retrait des nouvelles réponses, traitement des opérations en cours, détection des échecs et rôle du propriétaire documentaire. Un affichage « dernière synchronisation réussie » aide davantage qu'une promesse générale de données toujours à jour.
Notre article sur le cadrage et la recette d'un logiciel métier aide à formaliser ces engagements. Le guide technique de recherche RAG, en anglais, complète la partie récupération.
Pour vos intégrations IA, TuniCyberLabs peut étudier un cycle documentaire complet. Décrivez une procédure qui change souvent : son retrait constitue un excellent point de départ pour une recette utile.