Dlaczego ewaluacja ma znaczenie w RAG

System RAG może sprawiać wrażenie działającego, ponieważ zwraca płynne odpowiedzi brzmiące wiarygodnie. Jednak bez pomiarów nie wiadomo, czy rzeczywiście pobiera właściwe fragmenty ani czy generuje wierne odpowiedzi. Zespoły pomijające ewaluację często przez wiele miesięcy zmieniają strategie dzielenia tekstu i formaty promptów na podstawie intuicji, aby dopiero później odkryć, że pogorszyły sytuację. Rygorystyczna ewaluacja zmienia rozwój RAG z zgadywania w inżynierię.

RAG ma dwa odrębne etapy, które mogą zawodzić niezależnie: wyszukiwanie i generowanie. Wyszukiwanie zawodzi, gdy istotne fragmenty nie trafiają do wyników Top-K — LLM nie może wygenerować dobrej odpowiedzi, jeśli właściwe informacje nigdy nie zostały pobrane. Generowanie zawodzi, gdy poprawne fragmenty zostały pobrane, ale LLM je zignorował, błędnie odczytał lub dodał zmyślone informacje. Do wskazania komponentu powodującego problem potrzebne są osobne metryki dla każdego etapu.

Mierzenie wyłącznie jakości końcowej odpowiedzi ukrywa źródło błędów. Załóżmy, że system udziela błędnych odpowiedzi w 30% przypadków. Czy dzieje się tak dlatego, że wyszukiwanie nie znajduje właściwych fragmentów, czy dlatego, że LLM ignoruje dobre fragmenty? Jeśli znany jest tylko końcowy współczynnik błędów, nie można stwierdzić, który komponent należy naprawić. Instrumentuj oba etapy niezależnie: mierz jakość wyszukiwania za pomocą zbiorów danych wzorcowych, a jakość generowania za pomocą wyników wierności.

Ewaluacja wymaga zbioru danych wzorcowych: zestawu par pytanie–odpowiedź, dla których znana jest poprawna odpowiedź, a najlepiej również dokument i fragment, z którego ta odpowiedź pochodzi. W minimalnym użytecznym zbiorze ewaluacyjnym należy zgromadzić 50–100 pytań reprezentatywnych dla rzeczywistych zapytań użytkowników. Odpowiedzi przygotuj ręcznie lub na podstawie lektury dokumentów źródłowych. Uwzględnij różne typy pytań: wyszukiwanie faktów, porównania, wnioskowanie wieloetapowe oraz pytania spoza dziedziny, na które system powinien odmówić odpowiedzi.

Ręczne tworzenie 100 pytań jest żmudne. Można przyspieszyć ten proces za pomocą LLM do generowania danych: należy przekazać każdy fragment dokumentu do GPT-4o i poprosić o wygenerowanie 3–5 różnorodnych pytań, na które można znaleźć odpowiedzi w tym fragmencie, a także o podanie oczekiwanego tekstu odpowiedzi. Warto ręcznie sprawdzić próbkę, aby wykryć problemy z jakością. To podejście pozwala szybko skalować proces do tysięcy pytań, choć może pomijać przypadki brzegowe, o które zapytaliby wyłącznie prawdziwi użytkownicy.

Współczynnik trafień@K to odsetek pytań, dla których co najmniej jeden powiązany fragment pojawia się wśród K najważniejszych wyników wyszukiwania. Jest to najprostsza i najbardziej intuicyjna metryka wyszukiwania. Współczynnik trafień@5 równy 85% oznacza, że w przypadku 85 ze 100 pytań powiązany fragment znalazł się wśród 5 najważniejszych wyników. Należy śledzić współczynnik trafień osobno dla różnych typów dokumentów, długości zapytań i kategorii tematycznych, aby ustalić, z którymi przypadkami mechanizm wyszukiwania radzi sobie najsłabiej.

Wierność mierzy, czy wygenerowana odpowiedź zawiera wyłącznie informacje, które można zweryfikować w wyszukanym kontekście. Niewierna odpowiedź dodaje fakty, których kontekst nie potwierdza — jest to halucynacja. Wierność można ocenić, prosząc LLM pełniący rolę sędziego (lub człowieka oceniającego) o sprawdzenie każdego zdania odpowiedzi względem kontekstu i oznaczenie twierdzeń, których nie potwierdzają wyszukane fragmenty. Docelowy poziom wierności dla systemów produkcyjnych to co najmniej 95%.

Trafność odpowiedzi mierzy, czy wygenerowana odpowiedź rzeczywiście odnosi się do pytania użytkownika. Odpowiedź o wysokiej wierności może nadal mijać się z tematem, odpowiadając na pytanie powiązane, ale inne. Trafność należy mierzyć niezależnie od wierności. Można użyć LLM pełniącego rolę sędziego do oceny, czy odpowiedź bezpośrednio odnosi się do pytania, w skali od 1 do 5. Niska trafność odpowiedzi często wskazuje na problem ze strukturą promptu albo na to, że wyszukany kontekst nie zawiera faktycznej odpowiedzi.

Ocena jest najbardziej wartościowa, gdy śledzą Państwo metryki w czasie, w miarę wprowadzania zmian. Wyniki ocen należy przechowywać w bazie danych lub arkuszu kalkulacyjnym wraz ze znacznikami czasu i etykietami wersji (np. chunk_size=500, embed=3-small, k=5). Po wypróbowaniu nowej strategii dzielenia na fragmenty lub modelu osadzania należy przeprowadzić tę samą ocenę i porównać wyniki. Zapobiega to regresji — mogą Państwo poprawić wierność, ale przypadkowo obniżyć współczynnik trafień. Przed scaleniem zmian z wersją produkcyjną należy zawsze przeprowadzić pełną ocenę.

Oprócz konkretnych metryk ocena wymaga zmiany sposobu myślenia: należy traktować RAG jak system uczenia maszynowego o mierzalnej skuteczności, a nie jak chatbota ocenianego subiektywnie na podstawie rozmowy. Kryteria sukcesu należy określić z góry (np. hit rate@5 > 85%, faithfulness > 95%). Należy utworzyć zbiór testowy, który pozostaje zamrożony i nigdy nie jest używany do podejmowania decyzji dotyczących rozwoju. Do iteracji należy przeznaczyć osobny zbiór deweloperski. Ta dyscyplina odróżnia zespoły dostarczające niezawodne systemy RAG od tych, które dostarczają efektowne demonstracje zawodzące na produkcji.

Kluczową zasadą uczenia maszynowego, mającą zastosowanie również do oceny RAG, jest podział na zbiory treningowy, deweloperski i testowy. Zbiór testowy powinien być całkowicie zamrożony — nigdy nie należy używać go do podejmowania decyzji dotyczących rozwoju. Do eksperymentowania ze strategiami dzielenia na fragmenty, zmianami promptów i modelami osadzania należy używać osobnego zbioru deweloperskiego. Zbiór testowy należy uruchamiać dopiero wtedy, gdy uznają Państwo zmianę za gotową do wdrożenia na produkcji. Taki podział zapobiega nadmiernemu dopasowaniu potoku RAG do zbioru testowego i gwarantuje, że końcowe raportowane metryki odzwierciedlają rzeczywistą zdolność uogólniania.

W tej lekcji poznali Państwo: dwa niezależne tryby awarii wyszukiwania i generowania, które wymagają osobnych metryk, sposób budowania złotego zbioru danych zawierającego trójki pytanie–odpowiedź–fragment do obiektywnej oceny, współczynnik trafień jako podstawową metrykę wyszukiwania oraz wierność i trafność odpowiedzi jako podstawowe metryki generowania, a także znaczenie śledzenia metryk w czasie w celu zapobiegania regresjom. W następnej części zaimplementujemy konkretne metryki wyszukiwania, w tym MRR i NDCG.