Jak często reindeksować i co się psuje, gdy o tym zapomnisz

Indeks to zdjęcie stanu. Utrwala dokumenty w chwili, gdy powstały ich embeddingi, i nic poza tym. Asystent odpowiada z tego zdjęcia, nigdy z żywego źródła, więc każda odpowiedź jest tak dokładna, jak moment ostatniej synchronizacji. Częstotliwość reindeksowania nie jest więc tak naprawdę ustawieniem technicznym. To obietnica, jak stara może być odpowiedź, i lubię spisać tę obietnicę, zanim ktokolwiek dotknie harmonogramu. Kiedy staje się umową, można ją negocjować z biznesem, zamiast zostawiać jako ukryte domyślne ustawienie inżynierów.

Co naprawdę się psuje, gdy indeks zostaje w tyle

Nieaktualność jest cicha. I na tym polega problem. Nieobowiązująca już procedura zostaje zacytowana z pełnym przekonaniem, bo pobrany fragment nadal istnieje i nadal wygląda wiarygodnie, razem z przypisem do źródła. Najbardziej bolą ceny, zasady i numery wersji. Na tym ludzie działają od razu.

• Nieaktualna odpowiedź, poprawny przypis: link do źródła działa, treść poszła dalej.
• Dokumenty widma: skasowanie pliku nic nie zmienia, dopóki indeks się o tym nie dowie.
• Zepsute linki do źródeł: pliki po zmianie nazwy albo przeniesieniu dają przypisy prowadzące donikąd, a to niszczy zaufanie szybciej niż błędna odpowiedź.
• Zduplikowane fragmenty zostawione przez niedokończony przebieg.
• Ciche luki w pokryciu, gdy nowych dokumentów w ogóle nie wciągnięto.

Niech tempo wyznacza dokument, a nie kalendarz

Dzielimy źródła na poziomy według dwóch rzeczy: jak szybko zmienia się ich treść i jak drogo kosztowałaby błędna odpowiedź. Notatki o wydaniach, cenniki i procedury awaryjne wymagają synchronizacji niemal ciągłej. Podręcznik przepisywany raz w roku? Zupełnie nie.

• Sterowanie zdarzeniami dla systemów wysyłających webhooki o zmianach
• Co noc dla systemów zarządzania treścią i dysków współdzielonych
• Co tydzień dla stabilnych podręczników
• Na żądanie dla archiwów

Podział na poziomy utrzymuje moc obliczeniową proporcjonalnie do ryzyka. Wskazówka: zapisz tempo już przy rejestracji źródła, żeby nikt nie musiał pamiętać, który zbiór chodzi na jakim harmonogramie.

Synchronizacja przyrostowa a pełna przebudowa

Synchronizacja przyrostowa porównuje sygnał zmiany i rusza tylko to, co się zmieniło. Tego powinny używać rutynowe harmonogramy. Hash treści bije tu na głowę znaczniki czasu modyfikacji, i to bez zbliżenia - znaczniki zmieniają się, gdy nic istotnego się nie stało, co podbija koszty i przemiela embeddingi za darmo. Usunięcia trzeba obsłużyć osobno. Przebieg, który szuka tylko nowych i zmienionych plików, nigdy niczego nie skasuje. Nigdy.

Pełne przebudowy należą się przy zmianach strukturalnych: nowy model embeddingów, inny chunking, poprawiony schemat metadanych albo zbiór, któremu przestałeś ufać. Nigdy nie mieszaj modeli embeddingów w jednym indeksie, bo wektory z różnych modeli po prostu nie są porównywalne. Zmiana modelu oznacza przebudowę, nie łatanie.

Przebudowa bez wyłączania asystenta

Buduj do nowego indeksu, sprawdź go, potem przełącz wskaźnik. Nieudany przebieg embeddingów nigdy wtedy nie zostawi użytkowników z pytaniami do zbioru wypełnionego w połowie. Trzymaj poprzedni indeks przy życiu, dopóki następca nie obsłuży prawdziwego ruchu - wycofanie zmiany to jedyna tania naprawa złej decyzji o chunkingu, a kiedyś będziesz jej potrzebować. We wdrożeniach chmurowych równoległe indeksy to drobiazg. Na infrastrukturze klienta rozmowa wygląda inaczej: miejsce na dysku i budżet GPU na dwie kopie trzeba zaplanować z wyprzedzeniem. Przepustowość embeddingów i limity zapytań decydują, ile trwa przebudowa, więc zmierz to raz na prawdziwym zbiorze i traktuj tę liczbę jak ograniczenie, a nie szacunek.

Wskazówka: każdą przebudowę uruchamiaj na stałym zestawie znanych pytań, porównując odpowiedzi i cytowane źródła przed i po. Regresje chunkingu wyjdą wtedy tam, a nie przed użytkownikami.

Pomiary, które mówią, że indeks jest nieaktualny

Zapisuj, jak stary był każdy cytowany fragment w chwili podania, i alarmuj na ogonie rozkładu, nie na średniej. Średnie w tej sprawie kłamią. Regularnie porównuj też liczbę dokumentów w źródle z liczbą zaindeksowanych, bo rosnąca różnica oznacza, że wciąganie treści po cichu zawodzi. Zapisuj każdy przebieg synchronizacji z wynikiem dla każdego źródła - inaczej konektor, który sypie błędami od tygodni, pozostanie niewidzialny. A skok liczby odpowiedzi bez kontekstu zwykle znaczy, że nowa terminologia dotarła wcześniej niż jej dokumenty.

1. Ostatnia udana synchronizacja dla każdego źródła
2. Dokumenty dodane i usunięte
3. Elementy z błędami, wraz z przyczynami
4. Najstarszy fragment podany w prawdziwej odpowiedzi

Kto powinien być właścicielem

Reindeksowanie nie sprawdza się jako sprawa czysto inżynierska. Ludzie, którzy wiedzą, że dokument się zdezaktualizował, to ci, którzy go napisali. Daj właścicielom treści sposób na uruchomienie ponownej synchronizacji własnych źródeł, zamiast zgłaszania ticketu i czekania. Zasady usuwania też potrzebują wskazanego właściciela - ktoś musi zdecydować, czy materiały archiwalne dalej dają się wyszukać, czy znikają z odpowiedzi. W środowiskach regulowanych możliwość wskazania, która wersja dokumentu dała odpowiedź, liczy się tak samo jak sama odpowiedź.

FAQ

Czy reindeksowanie wszystkiego co noc rozwiązuje problem?

Ukrywa go. Pełne nocne przebudowy palą budżet na embeddingi, i tak zostawiają nawet dobę nieaktualności na pilnych treściach i zasłaniają to, które źródła naprawdę nie chcą się synchronizować.

Skąd wiemy, że dokument zniknął z systemu źródłowego?

Tylko z porównania pełnej listy źródła z indeksem. Sprawdzanie nowych i zmienionych nie wykryje braku, więc zaplanuj okresowy przebieg uzgadniający.

Czy trzeba reindeksować po zmianie promptu albo podmianie modelu odpowiadającego?

Nie. Prompty i modele odpowiadające siedzą nad warstwą wyszukiwania. Reindeksowanie jest potrzebne tylko przy zmianie modelu embeddingów, chunkingu albo schematu metadanych.

Co ustalilibyśmy najpierw

Zacznij od obietnicy świeżości dla każdego poziomu źródeł, potem dobierz mechanikę, która ją spełni. Nie wybieraj interwału na chybił trafił. Używaj hashy treści, obsłuż usunięcia wprost, trzymaj jeden model embeddingów na indeks, zachowaj możliwość wycofania zmiany. I mierz nieaktualność tam, gdzie boli - wiek faktycznie podanych fragmentów - a nie tam, gdzie wygodnie mierzyć. Zapomnienie nie daje ci wolnego asystenta. Daje ci pewnego siebie, cytującego coś, co przestało być prawdą.