Kontrola jakości odpowiedzi RAG: od testów do monitoringu

System RAG łączy wyszukiwanie dokumentów z generowaniem odpowiedzi, dlatego błąd może powstać na kilku etapach: przy podziale treści, indeksowaniu, doborze fragmentów albo syntezie. Sama poprawna składnia odpowiedzi nie dowodzi, że jest ona zgodna ze źródłami. W obsłudze klienta może to oznaczać podanie nieaktualnego warunku zwrotu, a w narzędziu wewnętrznym — pominięcie wyjątku z procedury.

Przed wdrożeniem określ, co oznacza jakość w konkretnym zastosowaniu. Dla asystenta dokumentacji ważne mogą być trafność źródeł i możliwość wskazania cytowanego fragmentu; dla wyszukiwarki wiedzy — kompletność wyników i szybkość. Spisz typowe pytania, dopuszczalne odpowiedzi, sytuacje wymagające odmowy oraz konsekwencje błędu. Nie zakładaj, że jeden wskaźnik obejmie wszystkie potrzeby. Zestaw kryteriów powinien wynikać z ryzyka i sposobu użycia systemu.

Zbierz pytania z rzeczywistych zgłoszeń lub warsztatów z użytkownikami, usuwając dane osobowe i sekrety. Dodaj przypadki proste, wieloznaczne, wymagające połączenia informacji z kilku dokumentów, a także pytania, na które baza nie powinna odpowiadać. Dla każdego przykładu zapisz oczekiwane fakty, dozwolone źródła oraz warunki uznania odpowiedzi za niebezpieczną lub niekompletną. Nie zapisuj wyłącznie jednej wzorcowej wypowiedzi: model może poprawnie wyrazić tę samą informację innymi słowami.

Podziel przykłady na zestaw deweloperski i odłożony zestaw walidacyjny. Ten drugi powinien pozostać poza codziennym dostrajaniem promptów, aby porównanie zmian było bardziej wiarygodne. Włącz pytania z literówkami, skrótami i nazwami używanymi przez organizację. Zadbaj o wersjonowanie testów oraz dokumentów źródłowych. Jeśli próbka jest mała albo nie obejmuje ważnego procesu, wyniki są jedynie sygnałem do dalszej kontroli, a nie dowodem jakości całego systemu.

dexter.rzeszow.pl

Najpierw sprawdź, czy dla pytania system pobiera właściwe fragmenty. Oceń, czy istotne źródło znalazło się wśród wyników oraz czy fragment zawiera dość kontekstu, by rozstrzygnąć pytanie. Jeśli właściwy dokument nie trafia do kontekstu, zmiana promptu generowania może zamaskować problem, ale go nie usunie. Przetestuj warianty zapytań, filtrowanie metadanych i rozmiar fragmentów na przykładach z zestawu walidacyjnego. Każda zmiana powinna mieć uzasadnienie w obserwowanym błędzie.

Następnie oceniaj odpowiedź względem pobranych źródeł: czy odpowiada na pytanie, nie dopowiada niepotwierdzonych faktów i prawidłowo sygnalizuje brak danych. Sprawdzaj też, czy odwołania prowadzą do materiału, który faktycznie wspiera dane twierdzenie. Automatyczny sędzia oparty na modelu może przyspieszyć przegląd, ale sam może się mylić; wprowadź ręczną weryfikację próbek i przypadków wysokiego ryzyka. Nie przedstawiaj wyniku takiej oceny jako obiektywnej prawdy bez sprawdzenia metody i zgodności z zadaniem.

Przygotuj przypadki, w których źródła są sprzeczne, nieaktualne lub niepełne. Sprawdź, czy system ujawnia niepewność, pyta o doprecyzowanie albo odmawia zamiast tworzyć pozornie pewną odpowiedź. Przetestuj również instrukcje ukryte w dokumentach, które próbują odwrócić cel asystenta; treść pobrana z bazy powinna być traktowana jako materiał do analizy, nie jako nadrzędna instrukcja. Wynik testu zapisuj wraz z wersją promptu, modelu, indeksu i dokumentów.

Po aktualizacji korpusu ponownie uruchom testy dotyczące zmienionych treści, a po zmianie modelu lub konfiguracji — pełniejszy zestaw regresyjny. Przykład z życia: po zmianie regulaminu sprawdź pytania o wyjątki i daty obowiązywania, a nie tylko ogólne streszczenie zasad. Dodaj testy graniczne dotyczące uprawnień, filtrowania wyników według działu oraz dokumentów, których użytkownik nie powinien widzieć. Zakres kontroli prywatności i bezpieczeństwa dobierz do architektury; sama obecność filtrów nie potwierdza zgodności z wymaganiami prawnymi.

Po uruchomieniu zapisuj mierniki użyteczne do diagnozy, na przykład opóźnienie, błędy pobierania, liczbę pustych wyników, użycie funkcji odmowy i zgłoszenia użytkowników. Ogranicz rejestrowanie treści wrażliwych; ustal retencję, dostęp do logów i sposób anonimizacji zgodnie z polityką organizacji. Wskaźniki oglądaj osobno dla typów pytań i obszarów korpusu, bo średnia może ukryć awarie dotyczące konkretnej procedury.

Zapewnij użytkownikowi prostą drogę zgłoszenia: odpowiedź błędna, nieaktualna, niekompletna lub bez właściwego źródła. Zespół powinien móc odtworzyć problem na bezpiecznych danych i ustalić, czy zawinił dokument, wyszukiwanie, uprawnienia czy generowanie. Zmiany wdrażaj stopniowo, z możliwością powrotu do poprzedniej konfiguracji. Progi alarmowe ustal na podstawie własnego ruchu bazowego i kosztu błędu; bez danych z konkretnego wdrożenia nie da się rzetelnie podać uniwersalnych wartości. Po każdej poprawce dodaj przypadek regresyjny do zestawu testów.

Przed publikacją zmiany wymagaj sprawdzenia kluczowych scenariuszy, porównania z poprzednią wersją oraz przeglądu przypadków ryzykownych przez osobę znającą domenę. Zapisz, kto zatwierdza źródła, kto odpowiada za konfigurację wyszukiwania i kto reaguje na zgłoszenia po wdrożeniu. W małym zespole role mogą się pokrywać, ale odpowiedzialność nadal powinna być jawna. Dla zmian dotyczących polityk, finansów lub zdrowia ustal ostrożniejszą ścieżkę weryfikacji i jasną informację, kiedy decyzję musi podjąć człowiek.

Nie traktuj przejścia zestawu testów jako gwarancji poprawności w każdej rozmowie. Testy obejmują wybrane przypadki, a rzeczywiste pytania i dokumenty zmieniają się w czasie. Ustal harmonogram przeglądu korpusu, kontrolę przeterminowanych materiałów i kryteria wycofania funkcji, jeśli pojawi się powtarzalny błąd. Każdy raport powinien opisywać zakres testów, znane ograniczenia i nieweryfikowane obszary. Jeśli wymagana jest ocena zgodności prawnej lub branżowej, zleć ją właściwym specjalistom; test techniczny sam jej nie potwierdza.