Aktualizacja i wersjonowanie wiedzy w RAG

Dział produktu zmienia cennik w piątek po południu. Asystent RAG obsługuje zapytania klientów przez weekend, odpowiadając na podstawie wektorów wygenerowanych we wtorek. Klient dostaje błędną cenę, składa reklamację, dział obsługi spędza godzinę na wyjaśnieniach. To nie jest scenariusz hipotetyczny. To wzorzec, który pojawia się w każdym wdrożeniu RAG, które nie ma przemyślanej warstwy aktualizacji wiedzy.

Problem nie leży w samym modelu językowym ani w wyszukiwarce wektorowej. Leży w założeniu, że baza wiedzy to stan, a nie strumień. Firmy, które to rozumieją, budują pipeline aktualizacji razem z pipeline indeksacji — nie jako osobny projekt na „później".

Pierwsze wdrożenia RAG często wyglądają tak samo: jednorazowa indeksacja kilkuset dokumentów, wynik zachwyca, projekt idzie na produkcję. Po miesiącu pojawiają się pierwsze skargi na nieaktualne odpowiedzi. Po kwartale utrzymanie bazy wiedzy jest pełnoetatowym zadaniem kogoś z zespołu.

Przyczyna jest prosta. Dokumenty firmowe nie są statyczne. Procedury się zmieniają, cenniki się aktualizują, produkty są wycofywane. Każda zmiana, która nie trafia do indeksu, tworzy rozbieżność między tym, co wie organizacja, a tym, co odpowiada asystent. Ta rozbieżność to ryzyko: błędna informacja do klienta, zły wniosek pracownika, eskalacja do konsultanta, która nie powinna mieć miejsca.

Trzy mechanizmy pogłębiają problem w miarę jak baza rośnie:

Stary wektor nie znika automatycznie. Gdy dokument zostanie zaktualizowany, jego poprzednia wersja nadal siedzi w bazie wektorowej jako osobny rekord. Przy zapytaniu semantycznym obydwa wektory mogą być trafne — model dostaje sprzeczne fragmenty i albo wybiera losowo, albo łączy je w niespójną odpowiedź.

Pełna reindeksacja jest kosztowna. Przy 10 000 dokumentów i modelu embedding działającym lokalnie pełny reindeks trwa kilkanaście minut. Przy modelu w chmurze generuje koszt proporcjonalny do liczby tokenów. Robiąc to co noc, za tydzień masz siedem pełnych reindeksów, z czego sześć i pół to wektory, które się nie zmieniły.

Dryf wiedzy jest niewidoczny bez monitoringu. System działa, odpowiedzi przychodzą, metryki operacyjne są zielone. Ale jakość odpowiedzi powoli spada, bo coraz więcej zapytań trafia na przestarzałe fragmenty. Bez aktywnego pomiaru trafności ten dryf jest niewidoczny do momentu, gdy zgłosi go użytkownik.

Właściwe rozwiązanie to reindeksacja zdarzeniowa: każda zmiana dokumentu wyzwala reindeks tylko tego dokumentu, nie całego korpusu.

Potrzebne są cztery elementy:

Detektor zmian. Każdy dokument ma hash zawartości (SHA-256 wystarczy) przechowywany razem z metadanymi wektora. Przed indeksacją pipeline porównuje hash bieżącej wersji z hashem przechowywanym. Reindeks następuje tylko przy różnicy. Przy integracji z CMS, SharePoint albo repozytorium Git można zamiast tego słuchać na webhooki lub zdarzenia API — zmiana dokumentu bezpośrednio wyzwala zadanie indeksacji.

Kolejka zadań. Zdarzenia indeksacji trafiają do kolejki (Redis, Celery lub dedykowany message broker). Kolejka gwarantuje, że nagły batch aktualizacji (np. aktualizacja cennika przed sezonem) nie blokuje systemu — zadania są przetwarzane stopniowo, z priorytetyzacją dokumentów o wysokiej liczbie zapytań.

Atomowe zastępowanie wektorów. Przy aktualizacji dokumentu stare wektory są oznaczane jako wycofane (soft delete z timestampem), nowe są indeksowane, następnie stare są usuwane. Nigdy odwrotnie. Okno, w którym w bazie istnieją obie wersje, wynosi kilka sekund i jest zarządzane przez wersjonowanie metadanych.

Logi indeksacji. Każda operacja (nowy, zaktualizowany, usunięty) jest logowana z timestamp, identyfikatorem dokumentu i wersją. Log jest niezależny od samej bazy wektorowej i pozwala na audyt: kiedy dany dokument był ostatnio reindeksowany, ile razy był zmieniany, czy indeksacja się powiodła.

Wersjonowanie w systemie RAG działa na dwóch poziomach, które warto rozdzielić koncepcyjnie.

Wersjonowanie dokumentów odpowiada na pytanie: jaka wersja dokumentu jest teraz aktywna? Minimalna implementacja to pole version lub valid_from / valid_to w metadanych każdego fragmentu. Przy zapytaniu filtr metadanych wyklucza fragmenty z valid_to w przeszłości. Dzięki temu możliwe jest wycofanie aktualizacji: cofnięcie valid_to przywraca poprzednią wersję bez reindeksacji.

Wersjonowanie wektorów odpowiada na pytanie: czy ten wektor pochodzi z modelu embeddingów, który teraz używamy? Modele embeddingów zmieniają się. Migracja z jednego modelu na inny (np. upgrade do nowszej wersji BGE-M3 albo zmiana wymiaru wektora) oznacza, że stare i nowe wektory nie są porównywalne. Metadane każdego wektora powinny zawierać identyfikator modelu i wymiar. Przy migracji modelu stare wektory są stopniowo zastępowane nowymi — dual-index przez czas przejścia, potem usunięcie starych.

Pełna reindeksacja powinna być operacją wyjątkową, nie rutynową. Jeśli musisz robić ją regularnie, to sygnał, że architektura detekcji zmian nie działa.

Dryf wiedzy to rosnąca rozbieżność między tym, o co pytają użytkownicy, a tym, co jest w bazie. Dwa typy są najczęstsze.

Dryf treściowy: dokumenty w bazie są aktualne, ale pytania użytkowników dotyczą tematów, które nie są jeszcze zaindeksowane. Widoczne w metrykach jako rosnący odsetek odpowiedzi z komunikatem „nie mam tej informacji" albo rosnąca liczba eskalacji do konsultantów.

Dryf jakościowy: dokumenty w bazie zawierają nieaktualne informacje, ale wektory nadal są trafne semantycznie, więc system odpowiada pewnie na podstawie złych danych. To trudniejszy przypadek, bo metryki operacyjne nie sygnalizują problemu. Widoczne tylko przez aktywny pomiar trafności lub przez feedback użytkowników.

Praktyczna detekcja dryfu wymaga trzech elementów:

Regularnych testów trafności na zestawie złotych pytań i oczekiwanych odpowiedzi. Zestaw powinien obejmować pytania z różnych domen wiedzy i być aktualizowany razem z bazą. Raz w tygodniu wystarczy dla większości systemów.

Alertu na rosnący odsetek odpowiedzi „nie wiem". Nagły wzrost to sygnał, że pojawiły się nowe tematy bez pokrycia w bazie — albo że dokumenty z tej domeny zostały zmienione i nie zostały reindeksowane.

Śladu wersji w każdej odpowiedzi. Logowanie, z jakiej wersji jakiego dokumentu pochodzi fragment użyty do odpowiedzi, pozwala po fakcie sprawdzić, czy odpowiedź była bazowana na aktualnej czy wycofanej treści. Bez tego audyt jest niemożliwy. Ten wzorzec jest też wymaganiem AI Act w systemach klasyfikowanych jako wysokiego ryzyka — ślad decyzji musi być odtwarzalny.

Przy ograniczonych zasobach indeksacyjnych warto priorytetyzować. Nie każdy dokument ma takie samo znaczenie dla jakości odpowiedzi.

Wysoki priorytet to dokumenty, na których bazie system udziela odpowiedzi najczęściej. Logowanie identyfikatora dokumentu przy każdym użyciu (jeśli respektujesz RODO i anonim. PII) pozwala zbudować ranking popularności dokumentów. Dokumenty w górze rankingu powinny być sprawdzane pod kątem aktualności przy każdej zmianie domeny.

Wysoki priorytet to też dokumenty z krótkim cyklem życia: cenniki, SLA, regulaminy, harmonogramy. Ich metadane powinny zawierać pole valid_to ze zdefiniowanym terminem wygaśnięcia. System powinien automatycznie oznaczać je jako przestarzałe po tym terminie i wymuszać potwierdzenie właściciela dokumentu przed dalszym użyciem.

Niski priorytet to dokumenty koncepcyjne i historyczne, które nie zmieniają się często. Mogą być reindeksowane raz na kwartał lub tylko przy jawnej aktualizacji.

Baza wiedzy RAG może zawierać dane osobowe: transkrypcje rozmów z klientami, e-maile, notatki z projektów. Prawo do bycia zapomnianym (art. 17 RODO) obowiązuje nie tylko bazę dokumentów, ale i wektory.

Usunięcie dokumentu z repozytorium nie usuwa automatycznie wektorów wygenerowanych na jego podstawie. Wymagane jest jawne usunięcie z bazy wektorowej z potwierdzeniem w logu. Procedura powinna być udokumentowana i testowalna: po usunięciu żadne zapytanie nie powinno zwracać fragmentów z usuniętego dokumentu.

Przy danych wrażliwych (np. transkrypcje zawierające dane klientów) standardowa ścieżka to maskowanie PII przed indeksacją. Zaindeksowany fragment nie zawiera wtedy danych osobowych i usuwanie na żądanie dotyczy tylko oryginalnych dokumentów, nie wektorów. Szczegółowy wzorzec opisujemy w artykule o anonimizacji PII przed AI.

Przy wrażliwych danych i wymaganiach regulacyjnych całość stosu (embeddingi + baza wektorowa + model) powinna działać lokalnie. Self-hosting eliminuje pytanie o transfer danych do chmury i upraszcza DPIA.

Opisz strukturę swojej bazy wiedzy i częstotliwość zmian dokumentów, a model zaproponuje architekturę pipeline aktualizacji dopasowaną do skali — jako punkt wyjścia do dyskusji z zespołem technicznym (playground: PII maskowane, zero retencji):

Odpowiedź zależy od tempa zmian dokumentów, nie od arbitralnego harmonogramu. Dla dokumentów zmieniających się co tydzień lub częściej właściwy wzorzec to reindeksacja zdarzeniowa: webhook lub hash diff wyzwala reindeks natychmiast po zmianie. Dla dokumentów statycznych lub rzadko zmienianych wystarczy cotygodniowy lub comiesięczny harmonogram. Pełna reindeksacja całego korpusu powinna być wyjątkiem, nie rutyną — wykonujesz ją przy migracji modelu embeddingów lub przy poważnej reorganizacji bazy.

System zwróci oba jako kandydatów do odpowiedzi. Model językowy dostanie sprzeczne fragmenty i zachowa się nieprzewidywalnie: może wybrać losowo, może połączyć sprzeczne informacje, może przyznać się do rozbieżności. Właściwy wzorzec to atomowe zastępowanie: nowe wektory są indeksowane, stare są oznaczane jako wycofane i usuwane w jednej transakcji. Okno niespójności powinno wynosić sekundy, nie minuty.

Trzy sygnały warto monitorować. Pierwszy: rosnący odsetek odpowiedzi „nie mam tej informacji" w porównaniu do baseline. Drugi: wzrost liczby eskalacji do konsultantów na pytania, które wcześniej były obsługiwane automatycznie. Trzeci: regularne testy trafności na zestawie złotych pytań z oczekiwanymi odpowiedziami. Połączenie tych trzech daje wczesne ostrzeżenie zanim problem stanie się widoczny dla klientów. Wzorzec pomiaru opisujemy szczegółowo w artykule o monitoringu jakości agenta AI.

Tak. Wektor wygenerowany z dokumentu zawierającego dane osobowe jest pochodną tych danych i podlega tym samym obowiązkom co oryginał. Usunięcie dokumentu ze źródłowego repozytorium nie wystarczy — wymagane jest jawne usunięcie wektorów z bazy wektorowej, potwierdzone w logu z timestampem. Rekomendowaną alternatywą jest maskowanie PII przed indeksacją: zaindeksowany fragment nie zawiera wtedy danych osobowych, a prawo do usunięcia dotyczy tylko oryginalnych dokumentów.

Stare i nowe wektory nie są porównywalne geometrycznie — nie można mieszać wektorów z różnych modeli w jednej kolekcji. Bezpieczna procedura migracji to dual-index: równoległe utrzymanie starej kolekcji (z której odpowiada produkcja) i nowej (do której trafia przyrostowa reindeksacja). Po zreindeksowaniu całego korpusu ruch przełącza się na nową kolekcję, stara jest usuwana. Czas migracji zależy od rozmiaru korpusu i dostępnych zasobów obliczeniowych — przy self-hostingu z lokalnym modelem zwykle kilka do kilkunastu godzin.