Jak aktualizować i usuwać dokumenty, nie zostawiając nieaktualnych odpowiedzi

Dlaczego usunięte dokumenty wciąż odpowiadają

Wykrycie zmiany jest łatwe, bo zmieniony plik nadal istnieje. Wykrycie usunięcia wymaga, żeby proces synchronizacji zauważył, że czegoś brakuje. Microsoft mówi to wprost o Azure AI Search: indeksery dla Azure Storage wykrywają nowe i zmienione bloby po znacznikach czasu, ale nie śledzą usunięć. Bez polityki soft delete dokumenty usuniętych plików zostają w indeksie jako sieroty.

Liczy się też moment. Ta sama dokumentacja mówi, że polityka usuwania musi działać od pierwszego przebiegu indeksera; dokumenty usunięte wcześniej zostają nawet po dodaniu polityki i zresetowaniu indeksera, a zalecanym rozwiązaniem jest nowy indeks. Przy źródłach Azure SQL polityka high water mark w ogóle nie wykrywa usuniętych wierszy, a wiersze wyczyszczone przez TRUNCATE nie znikają z indeksu po resecie i ponownym uruchomieniu. Inne platformy mają inne zasady i właśnie o to chodzi: sprawdź, jak twoja obsługuje usunięcia, zanim załadujesz dane po raz pierwszy.

Każda edycja zawiera małe usunięcie

Załóżmy, że po edycji polityka kurczy się z dwunastu chunków do dziesięciu. Jeśli ingestia aktualizuje chunki według pozycji, chunki jedenasty i dwunasty ze starej wersji zostają w indeksie i nadal mogą zostać pobrane. Bezpieczniejszy wzorzec wymienia wszystkie chunki z identyfikatorem dokumentu jako całość. Jeśli magazyn na to pozwala, zapisz nową wersję pod znacznikiem wersji i przełącz się na nią w jednym kroku. W przeciwnym razie usuń i wstaw, traktuj dokument w tym czasie jako niedostępny i sprawdź, co się dzieje, gdy ingestia przerwie się w połowie.

Frameworki wspierają część tego procesu. W LlamaIndex pipeline ingestii z magazynem dokumentów przechowuje hash dla każdego identyfikatora dokumentu; z podłączoną bazą wektorową dokument ze zmienionym hashem jest przetwarzany ponownie i aktualizowany, a niezmieniony pomijany. To sprawnie obsługuje edycje. Samo w sobie nie mówi jednak nic o dokumentach, które zniknęły ze źródła, więc usunięcia potrzebują osobnej ścieżki.

Identyfikatory muszą też przetrwać przeniesienia. Azure zaznacza, że zmiana kluczy dokumentów albo ścieżek psuje śledzenie, na którym polegają indeksery, a zmiana nazwy katalogu w ADLS Gen2 nie aktualizuje znaczników czasu blobów, więc nie są one ponownie indeksowane. Tam, gdzie to możliwe, używaj identyfikatora z systemu źródłowego zamiast ścieżki pliku.

Pięć zdarzeń, które musi obsłużyć każde źródło

Dla każdego źródła w zakresie zapisz, jak każde z tych zdarzeń trafia do indeksu i ile to trwa:

• Utworzenie: pojawia się nowy dokument
• Edycja: zmienia się treść i być może liczba chunków
• Usunięcie albo wycofanie: dokument musi przestać odpowiadać
• Przeniesienie albo zmiana nazwy: tożsamość musi pozostać ta sama
• Zmiana uprawnień: listy dostępu w indeksie muszą za nią nadążyć

Dane pochodne wymagają takiego samego traktowania. Kontekstowe podsumowania dołączone do chunków, cache odpowiedzi i zestawy ewaluacyjne zbudowane ze starego tekstu podtrzymują nieaktualną treść po zmianie źródła.

Testowanie aktualności dokumentami kanarkowymi

Kanarek to nieszkodliwy dokument testowy z unikalnym faktem, którego nie zawiera żaden prawdziwy dokument. Umieść po jednym w każdym źródle i po każdej zaplanowanej synchronizacji przeprowadź go przez opisane zdarzenia. Sprawdzaj, które chunki zostały pobrane, a nie tylko tekst odpowiedzi, bo model może sformułować poprawną odpowiedź, podczas gdy w kontekście nadal siedzi stary chunk.

# Freshness canary run (hypothetical; run after each scheduled sync)
1. create  canary-7f3a.md  "The canary parking code is BLUE-41."
   ask     "What is the canary parking code?"   expect BLUE-41, cites canary-7f3a
2. update  canary-7f3a.md  "The canary parking code is GREEN-12."
   ask     same question                        expect GREEN-12, no chunk says BLUE-41
3. delete  canary-7f3a.md
   ask     same question                        expect decline, zero chunks from canary-7f3a
4. restore canary-7f3a.md from recycle bin / soft delete
   ask     same question                        expect GREEN-12 again
record: time from each source change to the first correct answer

Krok przywracania ma swój powód. Azure dokumentuje, że przywrócony blob nie zawsze jest ponownie indeksowany, bo przywrócenie nie zmienia jego znacznika LastModified; ponowne zapisanie metadanych wymusza odświeżenie.

Gdy stara wersja ma pozostać dostępna

Nie każdy nieaktualny dokument powinien zniknąć. Wzór umowy z zeszłego roku może nadal obowiązywać dotychczasowych klientów. Wtedy zachowaj obie wersje, zapisz daty obowiązywania i status jako metadane i filtruj po nich, tak żeby zwykłe pytanie zwracało aktualną wersję, a pytanie o starszą umowę nadal docierało do starej.

Co obserwować na produkcji

• Liczba dokumentów na źródło w indeksie w porównaniu z systemem źródłowym
• Wpisy w indeksie, których identyfikatory nie istnieją już w źródle
• Czas ostatniej udanej synchronizacji i nieudane elementy dla każdego źródła
• Wyniki kanarków i zmierzone opóźnienie od zmiany do poprawnej odpowiedzi

Jeśli zmierzone opóźnienie jest dłuższe, niż akceptuje biznes, harmonogram nie jest jedyną dźwignią. Azure na przykład pozwala uruchamiać indeksery SQL najwyżej co pięć minut i zaleca bezpośrednie wypychanie zmian, gdy mają być widoczne szybciej.