Utrzymanie uczciwości magazynu wektorowego: cykl życia, model dzierżawy, metadane, wyszukiwanie hybrydowe

Technik terenowy pyta pracownika wsparcia wewnętrznego, jak zastąpić pompę hydrauliczną. Odpowiedź wydaje się poprawna: właściwa rodzina urządzeń, właściwy typ pompy, sensowny ciąg kroków. Jest ona jednak już pół roku stara. Obecny komunikat wymaga aktualizacji oprogramowania przed zainstalowaniem pompy, a stary w ogóle o tym nie wspomina. Obie notyfikacje znajdują się w bazie danych wektorowej. Nowa została prawidłowo skatalogowana, ale nikt nigdy nie usunął starej. Model nie wygenerował żadnych błędnych informacji – po prostu otrzymał przestarzałe dane.

Takie pytania decydują o tym, czy można ufać systemowi wyszukiwania.

• Która wersja dokumentu może być obecnie odzyskiwana?
• Jak szybko po zatwierdzeniu aktualizacja staje się dostępna do wyszukiwania?
• Czy jeden klient może kiedykolwiek zobaczyć treści innego klienta?
• Co się dzieje, gdy użytkownik szuka dokładnego numeru części, a nie ogólnej koncepcji?

Które pola metadanych muszą istnieć, zanim fragment danych zostanie dopuszczony do korpusu podlegającego wyszukiwaniu?

Żadne z tych elementów nie dotyczy jakości modelu. Chodzi o codzienną obsługę magazynu wektorowego.

Konkretne ustawienie: wsparcie techniczne dla wielu klientów

Wyobraźmy sobie platformę wsparcia używaną przez dealerów sprzętu w kilku krajach. Zawiera ona instrukcje obsługi produktów, biuletyny naprawcze, katalogi części, zasady gwarancji, procedury konserwacji oraz notatki napisane przez poszczególnych dealerów. Technik może zapytać, jaka procedura wymiany jest zatwierdzona dla pompy hydraulicznej MX-204, wersja 5.2, w jego regionie.

To nie jest zwykłe wyszukiwanie semantyczne. System musi odczytać intencję konserwacji, zachować dokładne identyfikatory, takie jak wersja MX-204 5.2, w niezmienionej formie, zwrócić aktualną procedurę naprawczą, zastosować odpowiednią politykę regionalną i pominąć wszystko, co należy do innych dealerów lub kont. Prosta zapytanie oparte na podobieństwie nie może zapewnić tych gwarancji. Warstwa wyszukiwania musi funkcjonować jak zarządzany serwis informacyjny.

Traktuj indeksowanie jako zarządzanie publikacją dokumentów

We wczesnych wersjach RAG indeksowanie jest zazwyczaj postrzegane jako pojedynczy proces: przesłanie pliku, podział na fragmenty, włączenie ich do struktury, zapisanie – i to wszystko. Po tym dokument pozostaje dostępny do wyszukiwania, dopóki ktoś przypadkiem nie zauważy problemu. Późniejsze awarie są łatwe do przewidzenia.

• Zrewidowany podręcznik istnieje obok swojego poprzednika.
• Projekt polityki staje się dostępny do wyszukiwania jeszcze przed jej zatwierdzeniem.
• Procedura wycofania pozostaje dostępna, ponieważ nie istnieje proces usuwania.
• Błąd w łańcuchu przetwarzania powoduje, że dokument zostaje częściowo zindeksowany, więc można pobrać tylko jego fragmenty.

Dla korpusu wsparcia najmniejszy użyteczny zbiór stanów cyklu życia wygląda następująco:

• Projekt: otrzymany, jeszcze nie zatwierdzony do pobierania.
• Kandydat: zindeksowany i w trakcie weryfikacji.
• Aktywny: zatwierdzony i dostępny do pobierania.
• Zastąpiony: zastąpiony nowszą wersją, przechowywany w celach audytu, ukryty przed zwykłymi zapytaniami.
• W kwarantannie: zatrzymany z powodu błędu w weryfikacji, sprawdzeniach metadanych lub recenzji treści.
• Usunięty: usunięty z korpusu, a także z podstawowego magazynowania, jeśli tego wymagają zasady.

Jedna zasada ma kluczowe znaczenie: wyszukiwanie powinno dotyczyć wyłącznie dokumentów w stanie Aktywnym. Musi być egzekwowana za pomocą filtrów metadanych, a nie przez zwyczaje nadawania nazw plikom czy instrukcje zawarte w zapytaniu.

Każdy dokument wymaga również stabilnego identyfikatora dokumentu oraz odrębnego identyfikatora wersji. Pierwszy określa logiczny element, np. konkretne biuletyn naprawczy, a drugi wskazuje jedną z jego wersji. Zatwierdzenie nowej wersji aktywuje ją i oznacza, że poprzednia została zastąpiona, przy czym ta zmiana powinna nastąpić atomowo. Dzięki temu system przestaje zwracać treści, które są istotne, ale już nie są aktualne.

Odświeżanie embeddingów: stopniowe, w wersjach, odwracalne

Odświeżanie embeddingów jest często opisywane jako zadanie do wykonywania za każdym razem, gdy zmienia się model. Rzeczywiste powody są bardziej zróżnicowane:

• Dokument źródłowy został edytowany.
• Polityka osiągnęła datę wejścia w życie lub wygaśnięcia.
• Schemat metadanych się rozszerza.
• Strategia dzielenia na fragmenty ulega udoskonaleniu.
• Model embeddingu jest aktualizowany.
• Dokument jest wycofywany lub przeklasyfikowany.
• Prawa użytkownika zmieniają się.

Każda z tych sytuacji wymaga innego rozwiązania. Zaktualizowany komunikat może wymagać jedynie aktualizacji na poziomie poszczególnych sekcji. Nowy model embeddingu może oznaczać konieczność odbudowy całego systemu. Nowe pole metadanych wymaga kontrolowanej uzupełniania danych, a wycofany dokument musi natychmiast zostać usunięty z aktywnego indeksu.

Dlatego proces odświeżania powinien śledzić cztery wersje: wersję źródłową, logikę dzielenia na fragmenty, model embeddingu oraz schemat metadanych używany do filtrowania. Bez takiej ścieżki przyczynowo-skutkowej nikt nie jest w stanie wyjaśnić, dlaczego dwa fragmenty zachowują się inaczej podczas wyszukiwania.

W praktyce plik przychodzący jest porównywany z aktualną wersją za pomocą hasza treści lub strukturalnego diffa. Sekcje, które uległy zmianie, są ponownie podzielone na fragmenty i włączone, natomiast nienaruszone sekcje pozostają bez zmian, chyba że zmieniła się metoda dzielenia na fragmenty lub włączania ich do struktury.

Zwiększanie rozmiaru modelu wymaga bezpieczniejszej procedury: należy stworzyć równoległy indeks kandydatów, przeprowadzić zapytania oceniające wobec obu indeksów, sprawdzić kontrole dostępu i przekierować ruch tylko wtedy, gdy nowy indeks działa w przyjęty sposób. Kluczowe pytanie nie brzmi, czy nowy model osiągnął wyższy wynik w teście benchmarkowym, lecz czy nowy indeks zwraca właściwe, zatwierdzone dane dla zapytań rzeczywiście wysyłanych przez użytkowników.

Wymagaj przestrzegania zasad użytkowania przed pobieraniem danych, a nie po nim

Niebezpieczną, ale powszechną wadą projektową w systemach RAG wielu najemców jest filtrowanie według najemcy po przeprowadzeniu wyszukiwania. System pobiera szeroki zakres wyników, a następnie usuwa te, które należą do innych organizacji. To już za późno. Filtry najemcy i dostępu muszą określić przestrzeń kandydatów przed rozpoczęciem jakiegokolwiek dopasowywania wektorów lub słów kluczowych.

W platformie wsparcia treści dzielą się na trzy grupy.

• Treści globalne: instrukcje producenta oraz wspólne procedury bezpieczeństwa.
• Treści dealerów: wewnętrzne wytyczne serwisowe, umowy handlowe oraz lokalne instrukcje obsługi.
• Treści klientów: historia aktywów, warunki umów oraz poufne notatki operacyjne.

Nie muszą one mieć takiego samego układu przechowywania. Treści globalne mogą dzielić się korpusem danych. Treści dealerów mogą korzystać z indeksu chronionego obowiązkowymi filtrami użytkowników. Klienci o szczególnie wrażliwych danych mogą potrzebować własnych kolekcji lub izolowanych indeksów, w zależności od wymogów regulacyjnych, umownych i związanych z ryzykiem.

Informacje o użytkowniku, roli, regionie, uprawnieniach do produktu oraz poziomie poufności muszą pochodzić z autoryzowanej sesji, a nie z treści zapytania. Technik wpisujący nazwę innego dealera do zapytania nie powinien mieć możliwości zmiany filtrów. W praktyce żądanie wyszukiwania dotyczy wyłącznie tych danych, do których ma dostęp ten autoryzowany użytkownik, i dopiero wtedy rozpoczyna się sortowanie według znaczenia lub słów kluczowych. To chroni poufność i jednocześnie eliminuje nieistotne wyniki.

Wyszukiwanie hybrydowe dla dokładnych identyfikatorów

Intensywne wyszukiwanie wektorowe sprawdza się, gdy ludzie opisują problem językiem potocznym, na przykład pytając, jaką wersję oprogramowania jest potrzebna przed zainstalowaniem zamiennego pompy w MX-204. Numery części, kody sterowników i łańcuchy wersji zachowują się inaczej, a indeks leksykalny znacznie lepiej umożliwia ich dokładne dopasowanie.

W przypadku MX-204 wyszukiwanie leksykalne może przynieść dokładny dokument informacyjny, ponieważ zawiera on identyfikatory sterownika i pompy, natomiast intensywne wyszukiwanie dostarcza powiązanych wskazówek dotyczących konserwacji. Następnie mechanizm ponownego rankowania może faworyzować dokument zawierający wymagania dotyczące oprogramowania oraz zatwierdzoną sekwencję działań.

Gdy skuteczność wyszukiwania jest niska, dodawanie większej liczby fragmentów tekstu do kontekstu rzadko pomaga. Większa liczba wyników typu top-k przede wszystkim dodaje szum, opóźnienia oraz zwiększa szanse na uzyskanie wiarygodnej odpowiedzi, której nie popierają żadne dane. Lepiej jest ustalić, na którym etapie doszło do błędu.

• Czy właściwy dokument był nieaktywny?
• Czy błąd w filtrze metadanych spowodował jego wykluczenie?
• Czy wyszukiwanie leksykalne pominęło alternatywny format numeru części?
• Czy mechanizm ponownego rankowania faworyzował dokument ogólny zamiast bardziej specyficznego?

Każdy z tych problemów stanowi mierzalny problem systemowy.

Metadane jako warstwa sterująca

Metadane są często traktowane jako opcjonalne tagi dodawane podczas przetwarzania danych. W środowisku produkcyjnym decydują one o tym, co system może pobrać. Przydatny schemat obejmuje pięć obszarów.

• Tożsamość: dokument źródłowy, system, z którego pochodzi fragment, oraz hash treści.
• Życiowy cykl: wersja, status zatwierdzenia, daty wejścia w życie i wygaśnięcia, oraz to, co ma pierwszeństwo przed czym.
• Dostęp: identyfikator użytkownika, region, uprawnienia roli, dostęp do produktu, klasa poufności oraz ograniczenia prawne.
• Pobieranie: typ dokumentu, język, model urządzenia, rodzina komponentów, linia produktów oraz kategoria treści.
• Operacje: wersja embeddingu, wersja dzielenia na fragmenty, czas pobierania, identyfikator wykonywania pipeline’u oraz status walidacji.

Dzięki taka strukturze pytania, które w inny sposób były trudne do zadania, stają się prostymi zapytaniami. Które aktywne dokumenty nadal używają starego modelu embeddingu? Które procedury naprawcze wygasają w przyszłym miesiącu? Które fragmenty nie posiadają metadanych regionalnych? Który użytkownik ma najwyższy odsetek pustych wyników? Które systemy źródłowe powodują najwięcej błędów przy pobieraniu danych?

Metadane powinny zostać zweryfikowane, zanim dokument trafi do aktywnego korpusu. Fragment bez informacji o użytkowniku, stanie życiowym, linii produktów czy statusie zatwierdzenia nie powinien stać się dostępny do wyszukiwania tylko dlatego, że został wygenerowany embedding. Wiele systemów RAG staje się niewiarygodnych właśnie w tym momencie: baza danych funkcjonuje zgodnie z projektem, ale model metadanych jest zbyt prosty, by odzwierciedlać rzeczywiste zasady organizacji dotyczące dostępu, cyklu życia i polityk.

Obserwowalność, która znajduje awaryjną fazę

Gdy użytkownik zgłasza błędną odpowiedź, może dojść do różnych problemów. Prawidłowy źródło może w ogóle nie zostać zindeksowane, albo zostać zindeksowane, ale oznaczone jako nieaktywne, lub wykluczone przez filtr. Może dotrzeć do zestawu kandydatów, ale otrzymać zbyt niską ocenę. Może trafić do kontekstu modelu, ale zostać zignorowany. Albo model może napisać coś, czego nie potwierdzają dostępne dowody. Każdy przypadek wymaga innego rozwiązania.

Dlatego zaawansowana usługa wyszukiwania rejestruje całą ścieżkę:

• Zapytanie i kontekst użytkownika.
• Filtrzy dostępu i cyklu życia, które zostały zastosowane.
• Gęste kandydaty i kandydaci leksykalni.
• Zintegrowana ocena i wynik ponownego rankingu.
• Ostateczne dowody przekazane modelowi.
• Cytaty użyte w odpowiedzi.

Przydatne środki obejmują opóźnienie pomiędzy zatwierdzeniem źródła a aktywacją indeksu, udział aktywnych treści w obecnej wersji embeddingu, dokumenty z więcej niż jedną aktywną wersją, wskaźniki braku wyników według typu zapytania, stopień pokrycia w testach z known-answer, wskaźniki odrzuceń przez filtry oraz wszelkie próby dostępu między użytkownikami.

Przydatnym wskaźnikiem jest pokrycie kandydatów: w przypadku zapytania z znana odpowiedzią, czy poprawne źródło pojawiło się wśród kandydatów przed ponownym rankowaniem? Jeśli nie, należy sprawdzić indeksowanie, filtrowanie lub projekt wyszukiwarki. Jeśli pojawiło się, ale miało niską pozycję, należy przyjrzeć się procesowi fuzji lub ponownego rankowania. Jeśli miało dobrą pozycję, a odpowiedź je zignorowała, problem leży w generowaniu treści lub komponowaniu promptów. Rozdzielenie tych etapów zapobiega próbom naprawiania wszystkiego poprzez edycję promptu.

Rutyna operacyjna

Magazyn wektorowy wymaga takiej samej dyscypliny jak każda służba danych produkcyjnych. Codzienne sprawdzania powinny obejmować błędy przy pobieraniu danych, zaległości w odświeżaniu, dokumenty utknięte w stanie kandydującym lub w karantannie, brakujące obowiązkowe metadane oraz opóźnienia w procesie zatwierdzania indeksowania. Tygodniowe przeglądy powinny analizować jakość wyników wyszukiwania dla różnych rodzajów zapytań – od pytań konwersacyjnych po proste kodы, nazwy produktów, wyszukiwania zasad, zapytania w innych językach oraz niejasne prośby.

Każda zmiana dotycząca dzielenia danych na fragmenty, modeli embeddingowych, schematu metadanych lub polityki dostępu powinna najpierw zostać przetestowana w środowisku kandydującym. Zbiór do oceny musi zawierać rzeczywiste zapytania użytkowników, przypadki o znanych odpowiedziach, testy kontroli dostępu oraz zapytania przeznaczone do wykrywania wycieków danych lub przestarzałych treści.

Celem nie jest pozyskiwanie większej liczby dokumentów. Chodzi o dostarczenie właściwych, zatwierdzonych dowodów odpowiedniemu użytkownikowi we właściwym momencie. Magazyn wektorowy nie jest pasywną bazą danych za chatbotem, ponieważ to on decyduje, które dowody mogą wpłynąć na odpowiedź. Gdy przestarzałe dokumenty pozostają aktywne, filtry użytkowników stają się opcjonalne, identyfikatory znikają w procesie dopasowywania semantycznego lub metadane nie są w stanie wyrazić zasad biznesowych, wtedy system jest niewiarygodny, bez względu na możliwości modelu.