Tombstone degli indici vettoriali: come i file eliminati restano ricercabili fino alla compattazione
I file eliminati possono restare individuabili quando un indice registra un tombstone logico, ma segmenti più vecchi, repliche, cache o chunk derivati continuano a servire le ricerche.
Rimuovere un PDF da un NAS domestico non elimina necessariamente il suo embedding, il testo della miniatura, l’output OCR o il risultato di recupero memorizzato nella cache. Molti motori di archiviazione contrassegnano inizialmente i record come eliminati e recuperano i relativi byte in un secondo momento durante la compattazione. I percorsi di query corretti dovrebbero rispettare immediatamente il contrassegno, ma una propagazione incompleta o un filtro aggirato possono far emergere dati obsoleti.
Un tombstone separa l’eliminazione logica dal recupero fisico
Nello storage orientato all’aggiunta, riscrivere un segmento di grandi dimensioni per ogni eliminazione sarebbe costoso. Un tombstone registra che un identificatore non è più attivo. Le query consultano questo stato, mentre la compattazione in background unisce successivamente i segmenti ed elimina sia il record obsoleto sia il relativo contrassegno quando è sicuro farlo.
Una spiegazione dei tombstone logici dei database osserva che i tombstone impediscono la restituzione delle righe eliminate prima che la compattazione ne rimuova i dati fisici. Lo stesso principio vale per i sistemi vettoriali, anche quando le implementazioni dei segmenti e delle mappe di eliminazione sono diverse.
Questa distinzione spiega perché l’utilizzo del disco potrebbe non diminuire dopo un’eliminazione. Da sola, però, non spiega un risultato di ricerca visibile: una query corrente corretta deve escludere il vettore contrassegnato come eliminato anche quando i relativi byte restano sul disco.
Un file eliminato può lasciare diversi derivati indipendenti
Un singolo file sorgente può produrre chunk, embedding, indici di parole chiave, riepiloghi, testo OCR, miniature e voci nella cache delle risposte. Eliminare solo gli ID dei vettori lascia intatti gli altri percorsi di recupero. Anche una nuova acquisizione con un identificatore diverso può creare duplicati che l’elenco di eliminazione originale non copre.
La documentazione sui database relativa alla pulizia tramite compattazione spiega che il recupero avviene durante la compattazione perché riscrivere continuamente i dati è costoso. Fino al completamento della pulizia coordinata, lo storage fisico e la visibilità logica devono essere trattati come stati separati. Questa distinzione modifica la decisione domestica finale.
Un registro affidabile delle eliminazioni associa quindi l’identità della sorgente a ogni derivato e spazio dei nomi. Registra inoltre la generazione che viene rimossa, impedendo a un evento di eliminazione ritardato di nascondere accidentalmente una sostituzione più recente con lo stesso nome di file.
Dove le repliche obsolete e le cache compromettono la semantica dell’eliminazione
La ricerca distribuita o composta da più processi aggiunge ritardi di propagazione. Un worker può rispettare il tombstone mentre un altro serve un segmento più vecchio; una cache delle risposte può restituire una risposta composta in precedenza senza interrogare affatto l’indice. In seguito, i backup possono ripristinare il derivato eliminato, a meno che le regole di conservazione non lo includano.
DataStax descrive i tombstone delle repliche come contrassegni propagati tra le repliche prima della rimozione definitiva. Il periodo di tolleranza protegge dalla resurrezione nei sistemi distribuiti, ma mostra anche perché la pulizia anticipata e le repliche incoerenti richiedano un coordinamento accurato. Questo limite resta visibile durante le successive verifiche delle evidenze.
Il limite di errore riguarda la visibilità nelle query, non i byte occupati. Se un qualsiasi percorso di ricerca supportato può ancora restituire l’evidenza eliminata dopo la finestra di eliminazione promessa, il sistema non ha completato l’eliminazione, anche se una dashboard segnala il successo.
Dimostrare l’eliminazione attraverso ogni percorso di ricerca
Prima dell’eliminazione, registra l’ID della sorgente, gli ID dei chunk derivati, una frase univoca e una domanda memorizzata nella cache. Elimina il file, quindi esegui query con la frase, una parafrasi semantica, un filtro sui metadati, l’ID della sorgente e la domanda memorizzata nella cache, prima e dopo la compattazione.
Usa la stessa disciplina sui file correnti descritta nello stato dell’indicizzazione incrementale: il test dovrebbe distinguere la visibilità logica, lo storage fisico e la conservazione storica. Controlla ogni replica o worker configurato invece di affidarti a una sola query riuscita. La dipendenza deve quindi essere misurata separatamente nella pratica.
Considera il test superato solo quando nessun percorso in modalità corrente restituisce la sorgente o i suoi derivati, le cache sono invalidate e la compattazione recupera infine lo spazio previsto. Se il recupero storico è intenzionale, isolalo dietro autorizzazioni separate e rendilo non disponibile alle normali query RAG.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Embedding multilingue: come un unico spazio vettoriale collega i documenti domestici tra lingue diverse
Scopri come gli embedding allineati collegano documenti in lingue diverse, perché la qualità del recupero varia e come testare localmente la copertura delle evidenze...
Conflitti nella memoria dell’agente: perché le correzioni recenti possono soccombere a fatti più vecchi ripetuti
Scopri come i vecchi ricordi duplicati prevalgono sulle correzioni, dove le regole di recenza falliscono e come testare la sostituzione in un archivio di...
Riordinamento privato della ricerca: come un secondo modello modifica l’ordine finale delle evidenze
Scopri perché la similarità della prima fase e la rilevanza della seconda fase non concordano, quando il reranking aiuta il RAG privato e come...
