Znaczniki usunięcia w indeksie wektorowym: jak usunięte pliki pozostają dostępne w wyszukiwaniu do czasu kompakcji

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Usunięte pliki mogą pozostać możliwe do odnalezienia, gdy indeks rejestruje logiczny znacznik usunięcia, ale starsze segmenty, repliki, pamięci podręczne lub pochodne fragmenty nadal obsługują wyszukiwanie.

Usunięcie pliku PDF z domowego serwera NAS nie musi oznaczać usunięcia jego wektora reprezentacji, tekstu miniatury, wyniku OCR ani buforowanego wyniku wyszukiwania. Wiele silników pamięci masowej najpierw oznacza rekordy jako usunięte, a dopiero później odzyskuje zajmowane przez nie bajty podczas kompaktowania. Prawidłowe ścieżki zapytań powinny respektować ten znacznik natychmiast, ale niepełna propagacja lub pominięcie filtra może pozwolić na ujawnienie nieaktualnych danych.

Znacznik usunięcia oddziela usunięcie logiczne od fizycznego odzyskania miejsca

W pamięci masowej zorientowanej na dopisywanie przepisywanie dużego segmentu przy każdym usunięciu byłoby kosztowne. Znacznik usunięcia informuje, że dany identyfikator nie jest już aktywny. Zapytania sprawdzają ten stan, a działające w tle kompaktowanie później scala segmenty i usuwa zarówno nieaktualny rekord, jak i jego znacznik, gdy jest to bezpieczne.

Wyjaśnienie dotyczące logicznych znaczników usunięcia w bazach danych wskazuje, że znaczniki zapobiegają zwracaniu usuniętych wierszy, zanim kompaktowanie usunie ich dane fizyczne. Ta sama zasada ma znaczenie w systemach wektorowych, nawet jeśli stosują one inne implementacje segmentów i map usunięć.

To rozróżnienie wyjaśnia, dlaczego ilość zajętego miejsca na dysku może nie zmniejszyć się po usunięciu. Samo w sobie nie wyjaśnia jednak widocznego wyniku wyszukiwania: prawidłowe bieżące zapytanie musi wykluczyć wektor oznaczony jako usunięty, nawet gdy jego bajty nadal znajdują się na dysku.

Usunięty plik może pozostawić kilka niezależnych pochodnych

Jeden plik źródłowy może wygenerować fragmenty, wektory reprezentacji, indeksy słów kluczowych, podsumowania, tekst OCR, miniatury i wpisy w pamięci podręcznej odpowiedzi. Usunięcie wyłącznie identyfikatorów wektorów pozostawia aktywne inne ścieżki wyszukiwania. Ponowne pozyskanie danych pod nowym identyfikatorem może również utworzyć duplikaty, których nie obejmuje pierwotna lista usunięć.

Dokumentacja baz danych dotycząca czyszczenia podczas kompaktowania wyjaśnia, że odzyskiwanie miejsca odbywa się w trakcie kompaktowania, ponieważ ciągłe przepisywanie danych jest kosztowne. Do czasu zakończenia skoordynowanego czyszczenia pamięć fizyczną i widoczność logiczną należy traktować jako dwa odrębne stany. To rozróżnienie zmienia wynikającą z tego decyzję dotyczącą gospodarstwa domowego.

Rzetelny rejestr usunięć powinien więc mapować tożsamość źródła na każdą pochodną i przestrzeń nazw. Powinien również rejestrować usuwaną generację, aby opóźnione zdarzenie usunięcia nie ukryło przypadkowo nowszego zamiennika o tej samej nazwie pliku.

Gdzie nieaktualne repliki i pamięci podręczne zakłócają działanie usuwania

Rozproszone lub wieloprocesowe wyszukiwanie wprowadza opóźnienia propagacji. Jeden proces roboczy może respektować znacznik usunięcia, podczas gdy inny udostępnia starszy segment; pamięć podręczna odpowiedzi może zwrócić wcześniej utworzoną odpowiedź bez ponownego odpytywania indeksu. Kopie zapasowe mogą później przywrócić usuniętą pochodną, jeśli zasady przechowywania nie obejmują również jej.

DataStax opisuje znaczniki usunięcia replik jako znaczniki propagowane między replikami przed ich ostatecznym usunięciem. Okres prolongaty chroni przed ponownym pojawieniem się danych w pamięci rozproszonej, ale pokazuje również, dlaczego przedwczesne czyszczenie i niespójne repliki wymagają starannej koordynacji. Ta granica pozostaje widoczna podczas późniejszego przeglądu danych.

Granica awarii dotyczy widoczności w zapytaniach, a nie zajętych bajtów. Jeśli jakakolwiek obsługiwana ścieżka wyszukiwania może nadal zwrócić usunięte dane po upływie obiecanego okna usunięcia, system nie zakończył usuwania, nawet jeśli panel raportuje sukces.

-15% OFF

Udowodnij usunięcie na każdej ścieżce wyszukiwania

Przed usunięciem zapisz identyfikator źródła, identyfikatory pochodnych fragmentów, unikalną frazę oraz jedno buforowane pytanie. Usuń plik, a następnie wykonaj zapytania według frazy, parafrazy semantycznej, filtra metadanych, identyfikatora źródła i buforowanego pytania przed kompaktowaniem oraz po nim.

Stosuj tę samą zasadę pracy wyłącznie z aktualnymi plikami, opisaną w stanie indeksowania przyrostowego: test powinien rozróżniać widoczność logiczną, pamięć fizyczną i przechowywanie historyczne. Sprawdź każdą skonfigurowaną replikę lub proces roboczy, zamiast ufać jednemu pomyślnemu zapytaniu. Zależność należy zatem w praktyce mierzyć osobno.

Test można uznać za zaliczony dopiero wtedy, gdy żadna ścieżka w bieżącym trybie nie zwraca źródła ani jego pochodnych, pamięci podręczne zostaną unieważnione, a kompaktowanie ostatecznie odzyska oczekiwane miejsce. Jeśli odzyskiwanie historyczne jest zamierzone, należy odizolować je za pomocą odrębnych uprawnień i uniemożliwić dostęp do niego zwykłym zapytaniom RAG.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.