Jak ocenić system RAG, zanim dopuścisz do niego użytkowników

Każdy projekt retrieval augmented generation dochodzi do tego samego momentu. System odpowiada na pytania, demo robi wrażenie i ktoś pyta, czy można to wypuścić na produkcję. Na takie pytanie trzeba odpowiedzieć dowodami, nie wrażeniami. Oto jak sprawdzamy asystenta opartego na dokumentach, zanim zacznie na nim polegać ktokolwiek spoza zespołu wdrożeniowego.

Dlaczego działające demo prawie nic nie mówi

Pierwsze pięć pytań, które wpisujesz, to pytania, na które znasz już odpowiedź. Właśnie dlatego wypadają dobrze. Retrieval sypie się na długim ogonie: skrót używany przez jeden dział i nikogo więcej, zeszłokwartalna zmiana w regulaminie, dokument istniejący w trzech sprzecznych wersjach. Za dwa miejsca, w których może pójść źle, odpowiadasz ty i trzeba je rozdzielić - retrieval wyciągnął złe fragmenty albo generowanie źle użyło tych właściwych. Ustal wcześniej, co asystent musi trafić bezbłędnie, a gdzie odmowa odpowiedzi jest w pełni dobrą odpowiedzią.

Zestaw testowy buduj z prawdziwych pytań

Pytania bierz ze zgłoszeń do supportu, z wewnętrznego czatu, z materiałów wdrożeniowych i od ludzi, którzy naprawdę będą z tego korzystać. Nigdy z samych dokumentów. Pytanie napisane w trakcie czytania dokumentu sprawdza tylko to, czy potrafisz ten dokument znaleźć ponownie, a to zadanie dużo łatwiejsze niż to, co przyniosą użytkownicy. Zapisuj oczekiwaną odpowiedź razem z dokumentem źródłowym i sekcją, żeby oceniać retrieval osobno od sformułowania odpowiedzi.

Świadomie dorzuć trudne kategorie:

• Pytania, na które w całym korpusie nie ma odpowiedzi
• Pytania z kilkoma równie poprawnymi odpowiedziami
• Pytania obejmujące dwa dokumenty, które trzeba połączyć
• Pytania, na które właściwą odpowiedzią jest wskazanie osoby

Co naprawdę mierzyć

1. Jakość retrievalu: czy właściwy fragment w ogóle się pojawił i jak nisko w rankingu?
2. Osadzenie w źródłach: każde twierdzenie da się wskazać w pobranym fragmencie, co sprawdzasz przez przeczytanie źródła, a nie przez zaufanie, że przypis się wyświetlił.
3. Przydatność: odpowiedź na tyle pełna, żeby dało się na jej podstawie działać, o właściwym zakresie, a nie asekuracyjne powtórzenie pytania.
4. Zachowanie przy odmowie: pewne siebie zmyślanie tam, gdzie korpus milczy, niszczy zaufanie szybciej niż cokolwiek innego z tej listy.
5. Czas odpowiedzi i koszt na pytanie przy realistycznej liczbie równoległych zapytań, a nie na bezczynnej maszynie.

Czytaj przypisy, a nie tylko je licz

Źródło podpięte do odpowiedzi to twierdzenie, które da się sprawdzić. Więc je sprawdź. Otwórz fragment i potwierdź, że mówi to, co odpowiedź mu przypisuje. Poluj na typowy wzorzec: pobrany chunk jest tematycznie związany z pytaniem, ale konkretna liczba, data albo warunek wzięły się z ogólnej wiedzy modelu. Granice chunków dokładają własną klasę błędów. Fragment urwany w połowie zdania potrafi odwrócić sens, który z pozoru niósł.

Wskazówka: daj dwadzieścia odpowiedzi razem ze źródłami do przeczytania ekspertowi dziedzinowemu, nie inżynierowi. Wyłapie te wiarygodnie brzmiące, ale błędne, obok których inżynier przejdzie obojętnie.

Testuj korpus, nie tylko model

Większość błędów retrievalu, które rozkładamy na czynniki pierwsze, okazuje się problemem z dokumentami. Nieaktualne wersje wciąż siedzące w indeksie, skany bez warstwy tekstowej, tabele spłaszczone do nieczytelnych wierszy. Sprawdź, jaka część korpusu w ogóle daje się wyszukać - dokumenty, które nigdy nie wypływają, to martwy balast udający pokrycie tematu. Uprawnienia też należą do planu testów. Zadaj identyczne pytania z kont o różnym dostępie i potwierdź, że odpowiedzi różnią się tam, gdzie powinny. Przed startem ustal też odpowiedzialność: kto usuwa nieaktualny dokument i jak szybko dociera to do indeksu?

Rodzaj wdrożenia zmienia to, co trzeba sprawdzić

Wdrożenie w chmurze i on-premise mają wspólne pytania testowe, ale nie wspólną listę ryzyk. Przy instalacji na własnej infrastrukturze sprawdź, że nic nie wychodzi poza sieć - łącznie z wywołaniami embeddingów, telemetrią i raportowaniem błędów. Lokalny sprzęt ogranicza rozmiar modelu i liczbę równoległych zapytań, więc mierz jakość na modelu, który naprawdę uruchomisz. Nie na największym, jaki był w testach.

Wskazówka: po każdej zmianie w infrastrukturze puść zestaw testowy jeszcze raz. Wymiana modelu embeddingów albo chunkera po cichu przesuwa wyniki retrievalu, nawet jeśli nikt nie tknął kodu aplikacji.

Od pilotażu do produkcji bez zgadywania

Zacznij od małej grupy, która zna materiał na tyle dobrze, żeby wychwycić błędną odpowiedź, i daj jej zgłaszanie błędu jednym kliknięciem. Loguj każde pytanie, pobrane fragmenty i odpowiedź, żeby reklamacja zamieniała się w odtwarzalny przypadek, a nie w jego opis. Zgłoszone odpowiedzi tworzą rosnący zestaw regresyjny, przez który przechodzi każda kolejna zmiana. Z góry uzgodnij, co uruchamia wycofanie wdrożenia, i trzymaj asystenta wyraźnie oznaczonego jako narzędzie pomocnicze.

Najczęściej zadawane pytania

Ile pytań testowych potrzeba przed startem?

Tyle, żeby pokryć typy pytań, które użytkownicy naprawdę zadają, z realnym udziałem trudnych kategorii. Mały zestaw wzięty z prawdziwych zgłoszeń bije duży wygenerowany z własnych dokumentów.

Czy odpowiedzi może oceniać model językowy?

Skaluje się dobrze, o ile najpierw skalibrujesz go na próbce ocenionej przez ludzi. Jako jedyny sygnał pozostaje zawodny wszędzie tam, gdzie pomyłka coś kosztuje.

Jak często powtarzać ocenę?

Przy każdej zmianie korpusu, sposobu chunkingu, modelu embeddingów, ustawień retrievalu albo modelu generującego. Każda z nich samodzielnie przesuwa wyniki.

Co znaczy wystarczająco dobrze

Ocena służy jednej decyzji: czy ten asystent pomaga bardziej, niż wprowadza w błąd, przy tym korpusie i tych użytkownikach? To nie jest bramka, którą przechodzi się raz. To przyrząd, który trzymasz wycelowany w system o ciągle zmieniających się danych wejściowych. Zrobiona porządnie daje zespół, który dokładnie wie, gdzie asystent jest słaby, i mówi to na głos - a to właśnie buduje zaufanie do tych części, które działają.