Ghost Vectors : les embeddings supprimés restent récupérables dans les bases vectorielles RAG

De quoi s’agit-il ?

En juin 2026, Chandranil Chakraborttii, Jackeline García Alvarado, Sitora Abdulofizova et Shivanshu Dwivedi (Trinity College) ont publié Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases. L’article examine une hypothèse discrète présente dans presque toutes les architectures de génération augmentée par récupération (RAG) : lorsqu’un enregistrement est supprimé de la base vectorielle, la donnée aurait disparu.

Ce n’est généralement pas le cas. La plupart des bases vectorielles de production reposant sur des index HNSW (Hierarchical Navigable Small World) implémentent la suppression comme une suppression logique (soft delete) : l’enregistrement est marqué d’un « tombstone » pour que la recherche cesse de le renvoyer, mais l’embedding sous-jacent reste physiquement écrit dans les fichiers d’index sur le disque. Les auteurs montrent que ces vecteurs « supprimés » peuvent être lus directement dans l’index brut, au niveau de la couche de stockage, puis inversés pour reconstituer une approximation du contenu original. Comme les embeddings encodent fréquemment des données personnelles ou médicales, une simple demande de suppression devient un problème de conformité au regard des régimes d’effacement des données comme l’article 17 du RGPD et HIPAA.

Comment ça marche

Deux constats se combinent, et aucun ne suppose d’attaquer une API de requête en production.

Premièrement, la suppression logique n’efface pas. Pour rester rapide, un index HNSW marque un nœud comme supprimé et l’ignore lors du parcours, en reportant la récupération effective de cet espace à une compaction ou une reconstruction ultérieure (souvent rare). Jusque-là, le vecteur, et toute charge utile stockée à ses côtés, reste sur le disque. Les auteurs ont confirmé ce comportement sur trois implémentations HNSW distinctes : la lecture des fichiers d’index bruts récupère des vecteurs que l’API déclare supprimés, en contournant entièrement la couche d’accès.

Deuxièmement, les embeddings ne sont pas à sens unique. À l’aide du modèle d’inversion Vec2Text, prêt à l’emploi et sans aucun réglage fin propre au domaine, l’équipe a reconstitué un contenu lisible à partir des vecteurs récupérés sur plusieurs jeux de données réels et plusieurs modalités, textes comme images, avec des taux de reconstruction significatifs. Aucun code d’exploitation n’est nécessaire pour comprendre le résultat : un embedding est une projection avec perte mais réversible de son entrée ; quiconque peut lire le vecteur peut approcher le texte source. Le modèle de menace vise ici toute personne ayant accès à la couche de stockage — un instantané de disque volé, un bucket de sauvegarde mal configuré, un volume cloud laissé lisible, ou un acteur interne — et non un utilisateur distant interrogeant le point d’entrée de recherche.

Pourquoi c’est important

Les pipelines RAG sont devenus, sans bruit, des entrepôts durables de textes sensibles : transcriptions de support, dossiers RH, notes cliniques, contrats. Les équipes considèrent l’embedding comme un bloc numérique opaque et anonymisé, et traitent une suppression au niveau de l’API comme l’exécution d’une demande d’effacement. Cet article invalide les deux hypothèses à la fois. Le vecteur est récupérable, et il est réversible : « nous l’avons supprimé » peut donc être faux précisément au moment où un régulateur, un auditeur ou une obligation de notification de violation exige que ce soit vrai.

La faille est d’autant plus dangereuse qu’elle est invisible depuis le point de vue de l’application. Interrogez l’API après une suppression : l’enregistrement a bel et bien disparu. Inspectez le fichier d’index ou une sauvegarde nocturne : il est toujours là. Chaque réplica, instantané et sauvegarde froide ayant capté le vecteur avant compaction est une copie indépendante de la donnée « oubliée ». C’est le cousin, au niveau du stockage, de la fuite au moment de la récupération traitée dans la fuite de base de connaissances RAG, et un rappel — aux côtés de travaux comme l’échec des défenses par embeddings en multi-agent — que les embeddings méritent le même traitement que les données brutes qu’ils encodent.

Défenses

L’article est constructif : il nomme la faille et livre une parade.

1. N’assimilez pas un tombstone à un effacement. Si votre posture de conformité affirme que la donnée est supprimée, le vecteur et sa charge utile doivent être réellement retirés de l’index, de ses réplicas et de ses sauvegardes, et pas seulement masqués de la recherche. Planifiez et vérifiez les compactions/reconstructions au lieu de les reporter indéfiniment.

2. Effacez par cryptographie plutôt que par suppression logique. Les auteurs proposent l’Epoch Key Rotation : chiffrer les vecteurs stockés et, à la suppression, détruire la clé pour rendre le chiffré irrécupérable. Ils rapportent que cela ramène la reconstruction de PII observée à 0 %, s’exécute en environ 2,5 ms pour 500 vecteurs supprimés, et émet une preuve signée ECDSA attestant que la suppression a eu lieu — un artefact auditable à présenter à un régulateur.

3. Traitez les embeddings comme des données réglementées. Chiffrez les index vectoriels au repos, restreignez l’accès aux fichiers bruts et aux instantanés avec les mêmes contrôles que ceux appliqués au corpus source, et gardez les embeddings de données personnelles ou de santé hors des stockages peu fiables.

4. Étendez la suppression à toute la lignée. Un effacement vérifié doit atteindre chaque sauvegarde, réplica et instantané exporté ayant un jour contenu le vecteur. Inventoriez ces copies avant de promettre à un utilisateur que sa donnée a disparu.

5. Produisez une preuve de suppression. Pour l’article 17 du RGPD et HIPAA, une preuve d’effacement cryptographique et horodatée est bien plus solide qu’une API renvoyant « introuvable ».

Statut

Élément	Référence	Date	Notes
Article Ghost Vectors (arXiv 2606.18497)	arXiv	2026-06	Trinity College ; trois implémentations HNSW analysées
Méthode de récupération	arXiv	2026-06	Lecture des fichiers d’index bruts au niveau du stockage + inversion Vec2Text, sans réglage fin
Types de données reconstitués	arXiv	2026-06	Embeddings de texte et d’image sur plusieurs jeux de données
Cadrage conformité	arXiv	2026-06	Article 17 du RGPD, exigences d’effacement HIPAA
Défense proposée	arXiv	2026-06	Epoch Key Rotation : 0 % de reconstruction de PII, ~2,5 ms / 500 vecteurs, preuve de suppression signée ECDSA

À retenir : non pas que « les bases vectorielles sont cassées », mais que la suppression dans un magasin RAG est une propriété de la couche de stockage, pas une réponse d’API — et si vos garanties d’effacement s’arrêtent à l’interface de requête, le fantôme de chaque enregistrement supprimé est toujours présent dans vos fichiers d’index.