Sześć metryk oceny RAG, które są ważne w produkcji
Recall@K, nDCG, MRR, wierność wyników, opóźnienie oraz koszt — jak naprawiać problemy z wyszukiwaniem, które wyglądają lepiej na papierze, podczas gdy jakość odpowiedzi się pogarsza.
Pierwotne tutoriale dotyczące RAG sprawiają wrażenie, że droga do rozwiązania jest krótka: dzielenie dokumentów, wstawianie ich do systemu, przechowywanie wektorów, wybór małej wartości top_k, wywołanie modelu. Taki plan może wydawać się skuteczny w demonstracjach, ale w warunkach produkcyjnych sytuacja jest inna.
Zadania przychodzą w chaotycznym stanie – źródłowe dokumenty są sprzeczne ze sobą. Niektóre prośby wymagają informacji z kilku źródeł jednocześnie. Użytkownicy wymyślają sformułowania, których nigdy nie było w oryginalnym zestawie testowym. System, który dobrze radził sobie na gotowych benchmarkach, zaczyna dostarczać odpowiedzi o dziwnie niestabilnej jakości.
Podczas dostosowywania mechanizmu wyszukiwania dla asystenta typu enterprise ten wzorzec był wyraźnie widoczny. Brakujące dane zmuszały zespół do zwiększania głębokości wyszukiwania. Wyniki offline wzrastały, a wskaźnik召回 również. Metryki na papierze wskazywały na „lepszą” jakość, ale generowane odpowiedzi stawały się coraz gorsze.
Dodatkowy kontekst nie pomagał. Czasami nawet szkodził. Istotne fragmenty pojawiały się pomieszane z duplikatami, nieistotnymi elementami oraz sporadycznymi konfliktami.
To doświadczenie zmieniło sposób oceny. Pytanie przestało brzmieć „czy pobraliśmy właściwy plik?” i stało się „czy każdy etap procesu może pokazać, że wykonywa swoją pracę?”
Szybkie debugowanie systemów RAG w czasie rzeczywistym pozwala oddzielić różne aspekty, które w demonstracjach łączy się w jeden wynik: jak dobrze odnajdujesz dane, jak dobrze je sortujesz, jaka jest jakość odpowiedzi, czy twierdzenia są uzasadnione, jak długo użytkownicy czekają oraz ile kosztuje każda prośba. Kolejne pytanie, które wszyscy zadają – jak powinniśmy wybrać rozmiar fragmentów i wartość top-k? – nie wymaga już gotowych liczb.
Traktuj problem jako optymalizację offline: stwórz prawdziwe dane referencyjne, zmierz odpowiednie wskaźniki, określ kompromisy, sprawdź nieznane zapytania, a następnie potwierdź, że rozwiązanie nadal jest skuteczne w warunkach produkcyjnych.
Sześć wskaźników jest szczególnie przydatnych: Recall@K, nDCG, MRR, Faithfulness, Latency oraz Cost. Każdy z nich ujawnia inny rodzaj awarii. Razem wyjaśniają, jak prototyp przekształca się w system, który można obsługiwać.
Zacznij od pozyskiwania informacji
Gdy jakość odpowiedzi się pogarsza, wróć do początku procesu zanim przepiszesz zapytania, zamienisz modele lub dodasz nowe elementy. Zadaj bezpośrednie pytanie: czy w ogóle udaje się znaleźć odpowiednie dane? Model nie może korzystać z materiałów, które nigdy nie trafiły do okna kontekstowego.
1. Recall@K — stopień pokrycia niezbędnych dowodów
Recall@K określa, jaka część rzeczywiście istotnych elementów znajduje się wśród pierwszych K wyników.
Weźmy bota ITSM, który ma do rozwiązania problem: „Usługa płatności przestała działać po awarii bazy danych — jakie kroki naprawcze powinienem podjąć?”. Załóżmy, że potrzebne są pięć faktów. Pierwsze pięć wyników dostarczonych przez system zawiera tylko cztery z nich. Wtedy Recall@5 wynosi 0,80.
To pojedyncze liczby już kierują procesem debugowania. Generator może nie być winowajcą – dwadzieścia procent potrzebnych dowodów w ogóle nie dotarło. Zasada ogólna: popraw to, co model widzi, zanim będziesz winić sposób jego pisania.
To również wyjaśnia, dlaczego stała wartość top_k = 5 nie jest bezwzględnie konieczna. Zmiana wartości K z 5 na 10 i wzrost wskaźnika Recall z 0,80 do 0,94 wskazuje, że indeks zawiera potrzebne materiały, ale selekcja jest zbyt powierzchowna. Zwiększenie wartości K niesie też ryzyko przepełnienia promptu szumem – dlatego następnie przychodzą metryki rankingowe.
2. nDCG – czy najlepsze wyniki znajdują się na górze?
Sama obszerność informacji nie wystarcza. Ważna jest pozycja.
Dwa systemy mogą korzystać z tego samego zestawu procedur. Jeden umieszcza je na początku, potem kolejną przydatną procedurę, a następnie mniej istotne elementy. Drugi ukrywa ten zestaw na ósmej pozycji, pomiędzy słabo powiązanymi stronami. Podobny wskaźnik Recall; zupełnie różne efekty końcowe.
Wskaźnik nDCG (normalizowany zredukowany kumulatywny zysk) ocenia stopień istotności i premiuje umieszczenie najważniejszych elementów na początku. Klasyczne badania dotyczące zredukowanego zysku przeprowadzone przez Järvelina i Kekäläinena powstały właśnie z tego powodu.
Reranking ułatwia zastosowanie tej koncepcji w RAG. Pozyskuje się dwadzieścia kandydatów, z których pięć trafia do modelu, a kolejność tych dwudziestu decyduje o tym, czy te pięć będzie przydatnych. Wysokie odzyskiwanie informacji przy słabej kolejności mogą sprawić, że właściwy fragment pozostanie w grupie kandydatów, ale nie trafi do ostatecznego zapytania.
Odzyskiwanie informacji sprawdza efektywność odkrywania danych, natomiast nDCG sprawdza mądrą kolejność ich prezentacji.
3. MRR — jak szybko pojawia się pierwszy przydatny wynik?
Średnia odwrotna pozycja skupia się na pierwszym istotnym wyniku:
[
RR = \frac{1}{\text{rank of first relevant result}}
]
Pozycja 1 → RR 1,0. Pozycja 5 → RR 0,2. Przyśredniając wartości dla całego zbioru zapytań, MRR jest wyraźnym sygnałem wskazującym, że pierwszy dobry wynik dominuje w doświadczeniu użytkownika.
Asystenci interaktywne często przestają funkcjonować po pierwszym istotnym fragmencie tekstu. Asystent, który ukrywa odpowiednią instrukcję na dziewiątym miejscu w rankingu, może wydawać się sprawny w testie Recall@20, ale nadal mieć problemy w interfejsie użytkownika.
Kiedy „więcej kontekstu” szkodzi
Mimo poprawy wskaźników wyszukiwania, jakość odpowiedzi nadal spadała. Model tonął w zbędnym i sprzecznym tekście. Wskaźniki rankingu wyjaśniają ten problem: większa wartość K bez lepszego uporządkowania wprowadza szum do treści wejściowej, co prowadzi do konieczności sprawdzeń spójności.
4. Wierność — twierdzenia powiązane z odzyskanym tekstem
Wierność polega na sprawdzeniu, czy twierdzenia zawarte w odpowiedzi są poparte odzyskanym kontekstem. Gładki tekst, który wymyśla kolejny krok, próg lub łączy dwie zasady w jedną trzecią, nie spełnia wymogów wierności, nawet jeśli brzmi pewnie.
Należy traktować wierność oddzielnie od poprawności.
Załóżmy, że korpus nadal zawiera przestarzałe zasady hasła – wygasa co 60 dni. Model je odzyskuje i powtarza. Odpowiedź może być w pełni wierna odzyskanej stronie, a mimo to błędna w stosunku do zamierzonego źródła prawdy.
- Wierność: czy jest poparta tym, co zostało odzyskane?
- Sprawność: czy jest zgodna z zamierzoną polityką?
To rozróżnienie ma znaczenie, gdy bazy wiedzy zmieniają się w trakcie działania systemu.
5. Opóźnienie – na ile mogą czekać użytkownicy o wysokich wymaganiach
Jakość pracy offline jest bezużyteczna, jeśli produkt nie może sobie pozwolić na oczekiwanie.
Porównajmy dwa rozwiązania. A osiąga 91% dokładności odpowiedzi przy opóźnieniu odzyskiwania danych wynoszącym 120 ms. B osiąga 93% przy 650 ms. Samo pod względem dokładności B wygrywa. To ograniczenia produktu decydują o tym, czy B jest rzeczywiście lepsze. Asystenci interaktywni z ograniczonym budżetem czasu na odpowiedź mogą odrzucić takie opóźnienie, a odzyskiwanie danych to tylko jedna z części całkowitego czasu.
Zapytanie w czasie rzeczywistym może obejmować przepisanie, pobieranie danych, ponowną klasyfikację, tworzenie kontekstu oraz generowanie wyników. Należy mierzyć poszczególne etapy oraz cały proces od początku do końca. Lepiej polegać na rozkładach statystycznych niż na średniach. Średnia wartość 400 ms przy P95 wynoszącym 1,8 s w ogóle nie przypomina systemu, w którym wartości P50/P95/P99 pozostają niskie.
Należy uwzględnić opóźnienia w planie oceny od samego początku — a nie jako metrykę operacyjną dopiero po ustaleniu architektury.
6. Koszt — co się dzieje przy milionach zapytań
Ekonomia staje się istotna w momencie, gdy prototyp przechodzi w produkt.
Zwiększenie liczby elementów typu top-k wpływa nie tylko na precyzję wyników, ale także może zwiększyć obciążenie procesu ponownej klasyfikacji, rozmiar końcowego kontekstu, liczbę tokenów wejściowych, opóźnienia oraz zużycie zasobów infrastruktury.
Jeśli każdy fragment zawiera średnio 600 tokenów, to:
Final K = 5
wstrzykuje około 3000 pobranych tokenów. Przejdź do:
Final K = 15
A jesteś bliżej wartości 9 000 – co stanowi trzy razy większą masę uzyskaną w wyniku analizy. Niewielki ruch ukrywa rzeczywiste koszty. Miliony zapytań przekształcają je w możliwości wyboru produktu. Parametr top-k jednocześnie wpływa na jakość, czas reakcji i koszt.
Co naprawdę oznacza „dostosowanie wielkości fragmentów i wartości top-k”
Pytanie w wywiadzie nie dotyczy dwóch magicznych liczb, lecz projektu eksperymentalnego.
Stwórz około 200 reprezentatywnych zapytań dotyczących rozwiązywania problemów, procedur, incydentów/RCA, zasad, niejednoznaczności, procesów wieloetapowych oraz przypadków krawędziowych. Niech eksperci z danej dziedziny ocenią ich istotność.
Próbuj różnych wielkości fragmentów, na przykład:
Chunk sizes:
256
512
1024
2048
a także różnych układów / kandydatów-K, na przykład:
Overlap:
64
128
256Candidate K:
5
10
20
Układ 4 × 3 × 3 daje około 36 konfiguracji. Ocenić każdą należy za pomocą więcej niż jednej liczby:
Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost
Następnie wybierz optymalny poziom jakości, czasu reakcji i kosztu – a nie automatycznie maksymalną stopę odzyskania danych czy wartość F1.
Nieoczekiwane wyniki eksperymentów
Załóżmy, że trzy konfiguracje dają następujące wyniki:
- A: Recall@10 0,94, nDCG@10 0,81, dokładność 0,89, wierność 0,95, P95 510 ms, $0,025
- B: Recall@10 0,91, nDCG@10 0,88, dokładność 0,94, wierność 0,96, P95 560 ms, $0,027
- C: Recall@10 0,97, nDCG@10 0,79, dokładność 0,86, wierność 0,76, P95 820 ms, $0,034
Sam Recall koronuje konfigurację C. Ta generuje najslabsze wyniki — dodatkowe procesy wyszukiwania najwyraźniej szkodzą procesowi generowania. Konfiguracja B ma niższy wynik Recall, ale przewyższa pozostałe pod względem nDCG, dokładności i wierności, przy jedynie niewielkiej stratie czasu lub kosztów. To właśnie ta konfiguracja zasługuje na dalsze badanie, a także wyjaśnia, dlaczego zasada „zwycięża najwyższy wynik wyszukiwania” jest złym regułą ogólną. Należy optymalizować pod kątem rzeczywistego celu produktu.
Niepowodzenie → kolejne badania
- Słaby wynik Recall@K → dzielenie na fragmenty, embeddingi, indeks, filtry metadanych, kształtowanie zapytań, strategia wyszukiwania
To zestawienie przekształca debugowanie w procedurę.
Zachowaj pętlę w działaniu w środowisku produkcyjnym
Jednorazowy test benchmark nie jest końcowym celem. Potrzebna jest ciągła ocena. Ruch w środowisku produkcyjnym różni się od starannie przygotowanych zbiorów: zmieniają się sformułowania, dokumenty, aktualizują się zasady, pojawiają się nowe usługi, występują przypadki krawędziowe. Rozszerzaj zbiór do oceny na podstawie błędów w produkcji.
Zaawansowana tabela ocen
Żaden pojedynczy wskaźnik nie opisuje całej historii. Praktyczna karta umożliwia jednoczesne śledzenie zakresu pokrycia, rankingu, poprawności, wierności danych, percentyli opóźnienia oraz efektywności ekonomicznej.
Zadaj pytania przed dostosowaniem
Gdy ktoś żąda określonej wielkości fragmentów i wartości top-k, najpierw zadaj pytania: co mamy optymalizować, jak wygląda zbiór oznaczony etykietami i jaki jest koszt nieudanego odnalezienia? Dzięki tym odpowiedziom konfiguracje stają się wynikami eksperymentalnymi.
Jednym z możliwych rezultatów może być:
512 tokens
128 overlap
Candidate K = 20
Final K = 5
Innym:
1024 tokens
64 overlap
Candidate K = 10
Final K = 4
Semantyczne dzielenie na fragmenty może być lepsze od obu tych podejść. Narzędzie do ponownego rankowania może sprawić, że ostateczna wartość K będzie ważniejsza niż liczba kandydujących wartości K.
Nie ufaj wartości uniwersalnej bez pomiarów. System RAG nie jest „dobry” tylko dlatego, że znajduje więcej informacji, robi to szybciej lub brzmi przekonująco. Jest dobry, gdy znajduje właściwe dowody, dobrze je sortuje, dostarcza modelowi odpowiednią ilość kontekstu, tworzy odpowiedzi zarówno poprawne, jak i uzasadnione, oraz mieści się w ograniczeniach czasu reakcji i kosztów produktu.
To rozdzielenie – pomiędzy skonfigurowaniem prostego procesu a opracowaniem pełnego systemu produkcyjnego – jest sednem sprawy.
Przestań zgadywać
Nie istnieje magiczna długość fragmentu tekstu, uniwersalny parametr top-k ani pojedyncza miara, która mogłaby potwierdzić gotowość rozwiązania do użycia. Nawet lepszy wskaźnik Recall@K może pogorszyć jakość odpowiedzi. Skuteczne wyszukiwanie informacji nadal może doprowadzić do nieudokumentowanych twierdzeń. Wysoka dokładność może zawieść, jeśli czas reakcji lub koszty gwałtownie rosną w skali.
Zrównoważ rozmiar zakresu informacji, sortowanie wyników, jakość generowanych odpowiedzi, czas reakcji oraz koszty pod kątem rodzaju obciążenia, które faktycznie obsługujesz.
Należy preferować: prawdziwe dane → testy wydajności wyszukiwania → weryfikację rankingu → ocenę jakości odpowiedzi od początku do końca → weryfikację opóźnienia i kosztów → dane niewidziane → monitorowanie w produkcji → informacje o błędach w dostawie do zbioru.
Następnie chunk_size=512 lub top_k=5 stanowią dowód, a nie tylko przekonanie.
Zestawienie sześciu metryk na jednej stronie
Prawdopodobny wygląd sprawdzonego zestawienia ocen do cotygodniowej analizy RAG może wyglądać tak:
- Recall@K i MRR w celu sprawdzenia „czy znaleźliśmy dowody i jak szybko?”
- nDCG w celu sprawdzenia „czy umieściliśmy najlepsze dowody na początku?”
- Wierność i poprawność odpowiedzi w celu sprawdzenia „czy proces generowania pozostał uczciwy i dokładny?”
- Opóźnienie P50/P95 w celu sprawdzenia „czy użytkownicy mogą czekać?”
- Koszt na jedną udaną odpowiedź w celu sprawdzenia „czy finanse mogą czekać?”
Rozpatrzcie je razem. Wzrost wartości Recall@K przy spadku wierności nie jest sukcesem. Zmniejszenie opóźnienia, które powoduje spadek nDCG, również nie jest sukcesem. Celem sześciu metryk jest ujawnienie tych kompromisów zamiast ukrywania ich w jednej liczbie F1.
Prawda podstawowa to rzadki zasób
Metryki są tak dobre, jak etykiety, które im towarzyszą. Jeśli eksperci z danej dziedziny nigdy nie oceniają, które fragmenty są istotne, Recall@K staje się bezwartościowy. Jeśli nikt nie oznacza stopnia istotności, nDCG zamienia się w chaotyczny wynik binarny. Jeśli oceny wierności są niejednolite, wyniki mogą ulec odchyleniom.
Przydzielajcie czas na etykietowanie w taki sam sposób, jak przydzielacie czas na eksperymenty z embeddingiem. Dwieście starannie ocenionych zapytań zazwyczaj dają więcej informacji niż dwa tysiące nieetykietowanych. Uzupełniajcie ten zbiór na podstawie zgłoszeń z produkcji: każdy „błąd w odliczeniach”, „przestarzałe zasady hasła” czy „pominięty przewodnik” może być kandydatem na taki przypadek.
Gdy konfiguracja okazuje się najlepsza w środowisku offline, należy ją wdrożyć tak jak każdą inną zmianę w produkcji. Należy zarejestrować użytą siatkę testową, optymalne ustawienia, wyniki z prób pozostawionych bez modyfikacji oraz akceptowane ograniczenia czasowe i kosztowe. Następnie należy obserwować te same wskaźniki w rzeczywistym ruchu przez określony czas. Jeśli zapytania w produkcji będą się różnić, należy te błędy ponownie dodać do zaznaczonej grupy i przeprowadzić ponowne testy. To właśnie ten cykl – a nie domyślne ustawienia dotyczące rozmiaru partii w artykułach blogowych – odróżnia dobrze dostrojony system od przypadkowego przykładu.
Zeszyty demonstracyjne zazwyczaj ustalają zestaw zapytań, zamrażają korpus danych i ukrywają opóźnienia za pomocą jednego wywołania. W środowisku produkcyjnym dzieje się odwrotnie: zapytania zmieniają się, dokumenty są ciągle aktualizowane, a użytkownicy porzucają powolne odpowiedzi. Dlatego konfiguracja, która wydawała się doskonała na statycznym teście benchmarkowym, może okazać się niewiarygodna po uruchomieniu. Sześć wymienionych powyżej metryk to sposób na ujawnienie tych ukrytych aspektów przed wdrożeniem oraz na ich utrzymanie w widoczności po nim.
Gdy ktoś pyta o standardową wielkość partii danych i standardowy parametr top-k, należy przekształcić to żądanie w plan eksperymentu. Określ cel, zbiór oznaczonych danych, budżet na opóźnienia oraz górny limit kosztów. Następnie niech siatka eksperymentalna wygeneruje odpowiednie liczby. Wszystko inne to domysły pod pozorem inżynierii.
Zachowaj kartę wyników widoczną podczas cotygodniowych przeglądów, aby kompromisy pozostawały jasne dla całego zespołu.
Literatura pokrewna
- Mapa poziomów koncepcji inżynierii SI i okresów, gdy są istotne — Dowiedz się, które koncepcje inżynierii SI decydują o tym, czy system w ogóle funkcjonuje, które są ważne podczas tworzenia rozwiązań do produkcji, a które mogą poczekać.
- Zarządzanie LLM-jako-sędzią jako żywym systemem produkcyjnym — Przeczytaj, jak czterostopniowy cykl życia Netflixu – dane oparte na faktach, szkolenie dostosowane do kryteriów oceny, bezpieczne wdrożenie oraz ciągłe monitorowanie – zapewnia dokładność systemu sędziowskiego opartego na LLM w skali masowej.
- Monitorowanie LLM w produkcji: wskaźniki, jakość, koszt, bezpieczeństwo — SLI dotyczące opóźnień, błędów, tokenów, trafności informacji oraz bezpieczeństwa – plus alerty wykrywające stopniową degradację jakości.