Verwijderde bestanden kunnen vindbaar blijven wanneer een index een logisch tombstone registreert, maar oudere segmenten, replica's, caches of afgeleide chunks nog steeds zoekopdrachten bedienen.
Een pdf verwijderen van een thuis-NAS verwijdert niet noodzakelijk de embedding, tekst uit de miniatuur, OCR-uitvoer of het gecachte zoekresultaat. Veel opslagsystemen markeren records eerst als verwijderd en maken hun bytes later vrij tijdens compaction. Correcte querypaden moeten de markering onmiddellijk respecteren, maar onvolledige verspreiding of een omzeild filter kan ervoor zorgen dat verouderd bewijsmateriaal toch zichtbaar wordt.
Een tombstone scheidt logische verwijdering van fysieke vrijgave
Bij opslag die uitsluitend toevoegingen uitvoert, zou het herschrijven van een groot segment voor elke verwijdering duur zijn. Een tombstone registreert dat een identifier niet langer actief is. Queries raadplegen deze status, terwijl achtergrondcompaction de segmenten later samenvoegt en zowel het verouderde record als de markering verwijdert zodra dat veilig is.
Een uitleg van logische tombstones in databases merkt op dat tombstones voorkomen dat verwijderde rijen worden teruggegeven voordat compaction hun fysieke gegevens verwijdert. Ditzelfde principe is van belang voor vectorsystemen, ook wanneer hun implementaties van segmenten en verwijderingskaarten verschillen.
Dit onderscheid verklaart waarom het schijfgebruik na verwijdering mogelijk niet daalt. Het verklaart op zichzelf niet waarom een zichtbaar zoekresultaat verschijnt: een correcte actuele query moet de vector met tombstone uitsluiten, ook zolang de bytes ervan nog op schijf staan.
Een verwijderd bestand kan verschillende onafhankelijke afgeleiden achterlaten
Eén bronbestand kan chunks, embeddings, trefwoordindexen, samenvattingen, OCR-tekst, miniaturen en vermeldingen in de antwoordcache opleveren. Alleen de vector-ID's verwijderen laat andere zoekpaden intact. Opnieuw opnemen onder een nieuwe identifier kan ook duplicaten creëren die niet in de oorspronkelijke verwijderingslijst staan.
Databasehandleidingen over compaction voor het opruimen leggen uit dat vrijgave tijdens compaction plaatsvindt, omdat het voortdurend herschrijven van gegevens kostbaar is. Totdat gecoördineerd opruimen is voltooid, moeten fysieke opslag en logische zichtbaarheid als afzonderlijke statussen worden behandeld. Dat onderscheid verandert de uiteindelijke beslissing voor het huishouden.
Een betrouwbare verwijderingsadministratie koppelt de bronidentiteit daarom aan elke afgeleide en namespace. Ze registreert ook de generatie die wordt verwijderd, zodat een vertraagde verwijderingsgebeurtenis niet per ongeluk een nieuwere vervanging met dezelfde bestandsnaam verbergt.
Waar verouderde replica's en caches de verwijderingssemantiek doorbreken
Gedistribueerd zoeken of zoeken met meerdere processen brengt verspreidingsvertraging met zich mee. Eén worker kan de tombstone respecteren terwijl een andere een ouder segment aanbiedt; een responscache kan een eerder samengesteld antwoord teruggeven zonder de index überhaupt te raadplegen. Back-ups kunnen de verwijderde afgeleide later herstellen als de bewaarbeleidsregels deze niet omvatten.
DataStax beschrijft tombstones voor replica's als markeringen die over replica's worden verspreid voordat ze uiteindelijk worden verwijderd. De graceperiode beschermt tegen het opnieuw verschijnen van gegevens in gedistribueerde opslag, maar laat ook zien waarom voortijdig opruimen en inconsistente replica's zorgvuldige coördinatie vereisen. Deze grens blijft zichtbaar bij latere beoordeling van het bewijsmateriaal.
De foutgrens ligt bij de zichtbaarheid in queries, niet bij ingenomen bytes. Als een ondersteund zoekpad het verwijderde bewijsmateriaal nog kan teruggeven na het beloofde verwijderingsvenster, is de verwijdering niet voltooid, ook al meldt een dashboard succes.
Bewijs de verwijdering via elk zoekpad
Leg vóór de verwijdering de bron-ID, afgeleide chunk-ID's, een unieke zin en één gecachte vraag vast. Verwijder het bestand en voer daarna vóór en na compaction queries uit op de zin, een semantische parafrase, een metadat filter, de bron-ID en de gecachte vraag.
Gebruik dezelfde discipline voor actuele bestanden als beschreven bij de status van incrementele indexering: de test moet logische zichtbaarheid, fysieke opslag en historische bewaring van elkaar onderscheiden. Controleer elke geconfigureerde replica of worker in plaats van op één geslaagde query te vertrouwen. De afhankelijkheid moet daarom in de praktijk afzonderlijk worden gemeten.
Slaag alleen wanneer geen enkel pad in de actuele modus de bron of de afgeleiden teruggeeft, caches ongeldig zijn gemaakt en compaction uiteindelijk de verwachte opslagruimte vrijmaakt. Als historisch herstel opzettelijk is toegestaan, scherm het dan af met afzonderlijke autorisatie en maak het onbeschikbaar voor gewone RAG-queries.
Tech & AI HUB
Meer om te lezen

Meertalige embeddings: hoe één vectorruimte documenten uit huishoudens in verschillende talen met elkaar verbindt
Ontdek hoe uitgelijnde embeddings documenten in verschillende talen met elkaar verbinden, waarom de kwaliteit van het ophalen varieert en hoe je de dekking van...

Conflicten in het agentgeheugen: waarom recente correcties het kunnen afleggen tegen herhaalde oudere feiten
Ontdek hoe dubbele oude herinneringen correcties overheersen, waar recentheidsregels tekortschieten en hoe je overschrijving in een privégeheugenopslag voor agents kunt testen.

Privézoekresultaten opnieuw rangschikken: hoe een tweede model de uiteindelijke volgorde van het bewijsmateriaal verandert
Ontdek waarom de gelijkenis in de eerste fase en de relevantie in de tweede fase van elkaar verschillen, wanneer herordening private RAG helpt en...

