Marqueurs de suppression des index vectoriels : comment les fichiers supprimés restent accessibles dans les recherches jusqu’à la compaction

Les fichiers supprimés peuvent rester détectables lorsqu’un index enregistre un marqueur logique de suppression, mais que d’anciens segments, des répliques, des caches ou des fragments dérivés continuent d’alimenter les recherches.

Supprimer un PDF d’un NAS domestique ne supprime pas nécessairement son vecteur d’embedding, le texte de sa miniature, sa sortie OCR ni le résultat de recherche mis en cache. De nombreux moteurs de stockage marquent d’abord les enregistrements comme supprimés et ne récupèrent leurs octets que plus tard, lors de la compaction. Les chemins de requête corrects doivent respecter immédiatement ce marqueur, mais une propagation incomplète ou un filtre contourné peut laisser apparaître des éléments obsolètes.

Un marqueur de suppression sépare la suppression logique de la récupération physique

Dans un stockage orienté ajout, réécrire un grand segment à chaque suppression serait coûteux. Un marqueur de suppression indique qu’un identifiant n’est plus actif. Les requêtes consultent cet état, tandis que la compaction en arrière-plan fusionne ensuite les segments et supprime l’enregistrement obsolète ainsi que son marqueur lorsque cela ne présente plus de risque.

Une explication des marqueurs de suppression logiques des bases de données précise qu’ils empêchent le renvoi des lignes supprimées avant que la compaction ne supprime leurs données physiques. Le même principe s’applique aux systèmes vectoriels, même lorsque leurs implémentations des segments et des cartes de suppression diffèrent.

Cette distinction explique pourquoi l’espace disque peut ne pas diminuer après une suppression. Elle n’explique toutefois pas, à elle seule, l’apparition d’un résultat de recherche : une requête actuelle correcte doit exclure le vecteur marqué comme supprimé, même si ses octets restent sur le disque.

Un fichier supprimé peut laisser plusieurs dérivés indépendants

Un seul fichier source peut produire des fragments, des embeddings, des index de mots-clés, des résumés, du texte OCR, des miniatures et des entrées de cache de réponses. Supprimer uniquement les identifiants des vecteurs laisse intacts les autres chemins de récupération. Une réingestion sous un nouvel identifiant peut également créer des doublons que la liste de suppressions d’origine ne couvre pas.

Les recommandations des bases de données sur le nettoyage par compaction expliquent que la récupération intervient lors de la compaction, car réécrire continuellement les données est coûteux. Tant que le nettoyage coordonné n’est pas terminé, le stockage physique et la visibilité logique doivent être considérés comme deux états distincts. Cette distinction modifie la décision à prendre au sein du foyer.

Un registre de suppressions fiable associe donc l’identité source à chaque dérivé et à chaque espace de noms. Il enregistre également la génération supprimée, afin d’empêcher qu’un événement de suppression différé masque accidentellement un remplacement plus récent portant le même nom de fichier.

Quand les répliques et les caches obsolètes compromettent la sémantique des suppressions

La recherche distribuée ou multiprocessus ajoute un délai de propagation. Un worker peut respecter le marqueur de suppression tandis qu’un autre sert un segment plus ancien ; un cache de réponses peut renvoyer une réponse composée précédemment sans interroger l’index. Les sauvegardes peuvent ensuite restaurer le dérivé supprimé si les règles de rétention ne l’incluent pas.

DataStax décrit les marqueurs de suppression des répliques comme des marqueurs propagés entre les répliques avant leur suppression définitive. La période de grâce protège contre la résurrection des données dans un stockage distribué, mais elle montre également pourquoi le nettoyage prématuré et les répliques incohérentes exigent une coordination rigoureuse. Cette limite reste visible lors d’un examen ultérieur des éléments utilisés comme preuves.

La limite à surveiller concerne la visibilité dans les requêtes, et non l’espace occupé par les octets. Si un itinéraire de recherche pris en charge peut encore renvoyer les éléments supprimés après le délai de suppression promis, le système n’a pas terminé la suppression, même si un tableau de bord signale sa réussite.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Prouver la suppression sur chaque chemin de recherche

Avant la suppression, enregistrez l’identifiant source, les identifiants des fragments dérivés, une phrase unique et une question mise en cache. Supprimez le fichier, puis effectuez des requêtes par phrase, par paraphrase sémantique, par filtre de métadonnées, par identifiant source et avec la question mise en cache, avant et après la compaction.

Appliquez la même rigueur concernant les fichiers actuels que celle décrite dans l’état de l’indexation incrémentielle : le test doit distinguer la visibilité logique, le stockage physique et la rétention historique. Inspectez chaque réplique ou worker configuré au lieu de vous fier à une seule requête réussie. La dépendance doit donc être mesurée séparément en pratique.

Ne validez que si aucun chemin en mode actuel ne renvoie la source ou ses dérivés, si les caches sont invalidés et si la compaction récupère finalement l’espace de stockage attendu. Si la récupération historique est intentionnelle, isolez-la derrière une autorisation distincte et rendez-la indisponible aux requêtes RAG ordinaires.