
RAG odpowiada płynnie, ale źle? Mierz wyszukiwanie osobno od odpowiedzi

Jakość RAG mierz osobno dla wyszukiwania i wygenerowanej odpowiedzi. Sprawdź najpierw, czy system pobrał właściwe i wystarczające fragmenty, a potem czy odpowiedź wynika z tych fragmentów i rozwiązuje problem użytkownika. Publikacja RAGAS rozróżnia jakość pobranego kontekstu, wierność jego wykorzystania i jakość generacji. Płynny język nie rozstrzyga żadnej z tych ocen.
Przed wdrożeniem przygotuj stały zestaw pytań, zapisz fakty potrzebne do odpowiedzi i zachowuj fragmenty pobrane przy każdym uruchomieniu. Dokumentacja metryk Ragas wymienia context precision, context recall, faithfulness i response relevancy. Oddzielne wyniki pomagają ustalić, czy poprawy wymaga wyszukiwanie, sposób wykorzystania kontekstu czy sama odpowiedź.
Zbuduj zestaw 30 pytań z własnego korpusu
Trzydzieści pytań to proponowany mały zestaw do wykrywania usterek i porównywania kolejnych wersji systemu, a nie próg gwarantujący reprezentatywność. Możesz przeznaczyć 12 na pojedyncze fakty, 8 na odpowiedzi wymagające połączenia kilku fragmentów, 6 na wyjątki lub konkurujące wersje dokumentów oraz 4 na pytania, na które w korpusie nie ma odpowiedzi. Ostatnia grupa sprawdza, czy system potrafi wskazać brak danych zamiast dopowiadać brakujący fakt.
Zapisz każde pytanie tak, jak mógłby je sformułować użytkownik. Obok umieść wymagane fakty, identyfikator i wersję dokumentu, z którego pochodzą, oraz oczekiwane zachowanie przy braku odpowiedzi. Przy pytaniu złożonym wypisz każdy konieczny fakt osobno: ogólna odpowiedź wzorcowa może ukryć to, że wyszukiwarka dostarczyła tylko część materiału.
Uwzględnij zadania typowe dla planowanego zastosowania oraz przypadki, w których łatwo pomylić podobne nazwy, wyjątek od reguły albo starszą wersję dokumentu z aktualną. Zachowaj migawkę korpusu użytego w teście. Jeśli treść źródeł zmieni się między próbami, sam spadek oceny nie powie, czy pogorszył się system, czy zmieniła się podstawa odpowiedzi.
Połącz metrykę z danymi i rodzajem błędu
Przed liczeniem wyników ustal, jaki fragment rzeczywiście pomaga odpowiedzieć na każde pytanie. Wyszukiwanie oceniaj względem potrzebnych faktów lub wskazanych źródeł, a nie tylko względem tego, co generator ostatecznie napisał. Gdy odpowiedź pominie wymagany fakt, porównanie jej wyłącznie z pobranym kontekstem nie pokaże, czy fakt w ogóle dotarł do modelu.
Poniższe zestawienie wskazuje minimalne dane do oceny i błąd, którego należy szukać:
- Context precision — pytanie, pobrane fragmenty w ich kolejności i ocena przydatności; ujawnia fragmenty zajmujące wysokie miejsca mimo małej wartości dla odpowiedzi. Wymagane dane referencyjne zależą od wybranego wariantu metryki.
- Context recall — pobrane fragmenty i lista faktów potrzebnych do poprawnej odpowiedzi; pokazuje, których informacji wyszukiwanie nie dostarczyło.
- Faithfulness — odpowiedź i fragmenty przekazane generatorowi; ujawnia twierdzenia, których nie da się uzasadnić dostarczonym kontekstem.
- Response relevancy — pytanie i odpowiedź; wskazuje, czy odpowiedź odnosi się do pytania. Sama trafność tematyczna nie wystarcza jednak do oceny, czy uwzględniono wszystkie wymagane fakty.
- Użyteczność według własnej rubryki — pytanie, odpowiedź, wymagane fakty i warunki zadania; pozwala ocenić kompletność, istotne zastrzeżenia i formę potrzebną użytkownikowi.
Wierność pobranym fragmentom nie oznacza jeszcze, że dokumenty są aktualne albo poprawne. Z kolei odpowiedź na temat może zawierać zdanie bez oparcia w źródłach. Dlatego zachowuj osobne wyniki tych ocen: jedna średnia z różnych metryk zaciera miejsce, w którym powstał błąd.
Uruchamiaj test w tych samych warunkach
- Zamroź pytania, oczekiwane fakty i wersję korpusu. Zapisz konfigurację wyszukiwania, liczbę pobieranych fragmentów, instrukcję dla generatora oraz użyty model.
- Dla każdego pytania zachowaj identyfikatory i kolejność pobranych fragmentów, pełną odpowiedź oraz wyniki poszczególnych ocen. Bez śladu wyszukiwania nie ustalisz, czy brak w odpowiedzi zaczął się przed generacją.
- Po zmianie konfiguracji uruchom ten sam zestaw. Porównaj przypadki pojedynczo i według rodzaju pytania, w tym osobno pytania bez odpowiedzi w korpusie.
Jeśli jednocześnie zmienisz indeks, model i instrukcję, wzrost wyniku nie wskaże, która zmiana pomogła. Zachowuj również przykłady nowych pomyłek. Średnia może się poprawić, choć system zaczął błędnie odpowiadać na pytanie szczególnie ważne dla użytkownika.
Pytania bez odpowiedzi wymagają własnego kryterium: poprawnym zachowaniem może być jasne wskazanie braku danych. Nie traktuj pustego wyniku wyszukiwania automatycznie jak niepowodzenia w odzyskaniu oczekiwanego faktu, skoro taki fakt nie istnieje w testowanym korpusie. Oceniaj tu raczej to, czy generator powstrzymał się od nieuzasadnionego twierdzenia.
Porównaj automatyczne oceny z kontrolą ręczną
Model oceniający również może źle zaklasyfikować przydatny fragment albo uznać przekonujące zdanie za poparte kontekstem. Instrukcja Ragas dotycząca zgodności ocen pokazuje porównanie etykiet sędziego LLM z ocenami ludzi i analizę rozbieżności. Wynik automatyczny powinien więc wskazywać przypadki do kontroli, a nie samodzielnie rozstrzygać o jakości systemu.
Przejrzyj ręcznie wszystkie zauważone twierdzenia sprzeczne ze źródłem, pytania bez odpowiedzi w korpusie oraz próbkę wyników ocenionych wysoko i nisko. Oceniający powinien mieć przed sobą pytanie, właściwą wersję źródła, fragmenty pobrane przez system i odpowiedź. Przy rozbieżności zapisz konkretny powód: brakujący fakt, pomyloną wersję, zdanie bez uzasadnienia albo pominięte wymaganie użytkownika.
Jeśli model i człowiek regularnie różnią się przy tym samym rodzaju przypadku, doprecyzuj kryterium i ponownie oceń tę samą próbkę. Zachowaj poprzednie etykiety, aby było widać, co rzeczywiście się zmieniło. Szczególnej uwagi wymagają skróty branżowe, podobne nazwy i zastrzeżenia, które zmieniają sens reguły.
Dopasuj poprawkę do miejsca usterki
Gdy brakuje potrzebnych faktów w kontekście, sprawdź pokrycie korpusu, filtrowanie, podział dokumentów na fragmenty i liczbę pobieranych wyników. Jeśli potrzebne fakty są pobierane, lecz giną wśród wielu nieprzydatnych fragmentów, przyjrzyj się rankingowi. To różne problemy wyszukiwania i mogą wymagać różnych zmian.
Jeżeli potrzebne fakty dotarły do generatora, ale odpowiedź dodaje twierdzenia bez podstawy, pracuj nad instrukcją generowania i sposobem wiązania stwierdzeń z dostarczonym materiałem. Gdy odpowiedź jest wierna kontekstowi, lecz pomija część pytania, oceniaj jej kompletność według zapisanych wcześniej wymagań. O gotowości do wdrożenia decydują błędy istotne w danym zastosowaniu oraz ich powtarzalność, a nie sama płynność odpowiedzi czy pojedynczy wynik zbiorczy.
Przeczytaj także:
Powiązane artykuły


ReviewBench mierzy recenzentów AI — 219 pull requestów zamiast dema

Pinecone czy pgvector? Filtry potrafią zmienić zwycięzcę

NotebookLM czy Perplexity? Własne źródła i otwarty web zmieniają wynik

Meta Muse tworzy profile znajomych co godzinę — pamięć ma koszt prywatności

AstaBrief pisze raport 3,5 raza szybciej — cytaty nadal trzeba sprawdzać
Zapisz się do naszego newslettera
Otrzymuj najnowsze wiadomości o Web3, AI i kryptowalutach prosto na swoją skrzynkę.