Ragas czy DeepEval? Wygodna metryka może nie zgadzać się z człowiekiem

Do analizy odpowiedzi systemu RAG na stałym zbiorze pytań dobrym punktem wyjścia jest Ragas. Przykład ewaluacji RAG łączy pytanie, wygenerowaną odpowiedź, pobrane fragmenty i odpowiedź wzorcową w zestaw, który można ocenić kilkoma metrykami. Taki układ pomaga ustalić, na których pytaniach zmiana wyszukiwania lub generowania poprawiła wynik, a na których go pogorszyła.

Jeżeli ocena ma działać jako test blokujący zmianę w CI, wygodniejszym punktem wyjścia jest DeepEval. Instrukcja testowania RAG pokazuje przypadki testowe, asercję „assert_test” i uruchomienie przez „deepeval test run”. Wybór biblioteki nie rozstrzyga jednak, czy jej wynik odpowiada jakości ważnej dla użytkownika: przed ustawieniem progu trzeba porównać metrykę z ocenami ludzi na własnych odpowiedziach.

Ten sam mini-zestaw, te same dane wejściowe

Przyjmijmy warunkowy przykład bazy zasad sklepu. Pobrany fragment mówi jedynie: „Zamówienie można anulować przed wysyłką”. Pierwszy przypadek to pytanie o termin anulowania i odpowiedź „Przed wysyłką”. Drugi zawiera to samo pytanie, ten sam fragment oraz błędną odpowiedź „Po wysyłce”. W trzecim użytkownik pyta o możliwość anulowania już wysłanego zamówienia. Sam fragment nie pozwala tego rozstrzygnąć, więc pożądaną reakcją jest wskazanie braku informacji, a nie dopisanie reguły.

Każdy przypadek powinien zachować dokładne pytanie, rzeczywistą odpowiedź systemu i fragmenty przekazane generatorowi. W Ragas odpowiadają im pola „user_input”, „response” i „retrieved_contexts”; odpowiedź wzorcową zapisuje się jako „reference”. W DeepEval te same dane można przekazać do przypadku „LLMTestCase” jako „input”, „actual_output” i „retrieval_context”, a wzorzec jako „expected_output”. Warto zachować również kolejność pobranych fragmentów: zmiana kontekstu między uruchomieniami zmieni zadanie oceniane przez metrykę.

To jest mini-zestaw do porównania zachowania narzędzi, nie gotowy benchmark sklepu. Pokazuje za to trzy różne sytuacje, które łatwo zlać w jedną średnią: odpowiedź zgodną ze źródłem, odpowiedź sprzeczną ze źródłem oraz pytanie, na które źródło nie daje odpowiedzi. Jeśli w obu bibliotekach podasz inne fragmenty albo inaczej sformułujesz wzorzec, różnicy wyników nie będzie można przypisać samym metrykom.

Faithfulness: podobna nazwa, inna reguła

Wierność odpowiedzi bada związek jej twierdzeń z pobranymi fragmentami, a nie zgodność z całą wiedzą o świecie. Definicja Faithfulness w Ragas przewiduje wyodrębnienie twierdzeń z odpowiedzi i sprawdzenie, które z nich można wywnioskować z kontekstu. Wynik jest udziałem twierdzeń mających takie oparcie. W warunkowym przykładzie zdanie „Zamówienie można anulować po wysyłce” nie wynika z pobranej zasady.

Opis Faithfulness w DeepEval również opiera wynik na ocenie twierdzeń, lecz w trybie z modelem językowym określa twierdzenie jako prawdziwe, gdy nie przeczy faktom z „retrieval_context”. Dla szczegółu, którego fragment po prostu nie zawiera, różnica między „wynika ze źródła” a „nie przeczy źródłu” może mieć znaczenie. DeepEval udostępnia też inne tryby oceny tej metryki, dlatego przy porównywaniu wyników trzeba utrzymać ten sam tryb i model oceniający.

Obie definicje uzasadniają obejrzenie pojedynczych odpowiedzi obok wyniku liczbowego. Odpowiedź może poprawnie powtórzyć zasadę anulowania przed wysyłką, a następnie dodać nieudokumentowany wyjątek. Jeden łączny wynik Faithfulness nie pokaże od razu, czy oceniana rozbieżność dotyczy głównej odpowiedzi, czy dopisanego szczegółu. Dla decyzji o wdrożeniu te błędy mogą mieć różną wagę.

Trafność odpowiedzi i jakość wyszukiwania

Trafność odpowiedzi względem pytania to inne kryterium niż wierność wobec źródła. Odpowiedź „Po wysyłce” na pytanie o termin anulowania jest na temat, choć przeczy pobranemu fragmentowi. Dlatego „Response Relevancy” w Ragas i „Answer Relevancy” w DeepEval nie powinny zastępować oceny wierności. Także odpowiedź „Nie mam informacji o anulowaniu po wysyłce” może być właściwa dla użytkownika, choć jest mniej bezpośrednia niż stanowcza odpowiedź wymyślająca zasadę.

Metryki kontekstu dotyczą wcześniejszego etapu: czy wyszukiwarka przekazała materiał przydatny do odpowiedzi. W DeepEval „Contextual Relevancy” można stosować bez odpowiedzi wzorcowej, natomiast „Contextual Precision” i „Contextual Recall” wymagają „expected_output”. W Ragas dobór metryk także zależy od dostępnych pól; przykładowa ewaluacja używa odpowiedzi wzorcowej przy ocenie przypomnienia kontekstu i poprawności faktów. Gdy nie masz wiarygodnego wzorca, wybór metryki trzeba ograniczyć do pytań, na które posiadane dane rzeczywiście pozwalają odpowiedzieć.

Rozdzielenie wyszukiwania od generowania ma praktyczny sens. Jeśli potrzebny fragment nie trafił do kontekstu, nawet ostrożny generator może nie podać pełnej odpowiedzi. Jeśli fragment został pobrany, ale odpowiedź mu przeczy, poprawianie samej wyszukiwarki może nie usunąć błędu. Porównanie obu etapów na tych samych przypadkach wskazuje, gdzie powstała różnica, zamiast sprowadzać ją do jednej oceny całego systemu.

Co zmienia próg w CI

W DeepEval przypadek RAG można zapisać jako test z progiem dla wybranej metryki; wynik poniżej progu powoduje niepowodzenie testu. To pasuje do pytań, na których określony błąd ma zatrzymać zmianę. Ragas również można uruchamiać automatycznie, ale jego zestaw danych i wyniki ewaluacji są wygodne do analizy zmian w wielu pytaniach. Różnica dotyczy więc sposobu użycia wyników, a nie tego, czy jedna z bibliotek potrafi oceniać RAG.

Próg powinien odpowiadać decyzji, którą ma wspierać. W warunkowym przykładzie szczególnie kosztowne może być stanowcze dopisanie zasady anulowania po wysyłce, której nie ma w pobranym materiale. Sama średnia trafność odpowiedzi może ukryć taki przypadek, dlatego obok wyniku zbiorczego potrzebny jest test dla pytań, przy których system powinien przyznać brak danych. Między uruchomieniami zachowaj tę samą wersję zbioru, konfigurację metryki i model oceniający; inaczej zmiana wyniku nie musi pochodzić od ocenianego systemu.

Kalibracja na ocenach dwóch osób

W badaniu metryk RAG na danych biznesowych dwie osoby oceniły odpowiedzi dla 96 przypadków; korelacja między ich ocenami wyniosła 0,85. Autor porównał z tymi ocenami metryki między innymi z Ragas i DeepEval. Część metryk generowania słabo korelowała z oceną całej odpowiedzi, a szerokie przedziały ufności ograniczały interpretację wyników. Badanie obejmowało jeden system RAG, więc nie stanowi rankingu bibliotek dla dowolnego produktu.

Własną kalibrację zacznij od krótkiej rubryki opisującej, co oznacza odpowiedź akceptowalna: zgodność z pobranym materiałem, odpowiedź na pytanie i wymagany zakres informacji. Dwie osoby powinny niezależnie ocenić te same odpowiedzi, w tym przypadki poprawne, częściowe, sprzeczne ze źródłem oraz pytania bez wystarczających danych. Rozbieżności między ludźmi omów przed oceną metryk: niejasna rubryka utrudni interpretację każdej późniejszej korelacji.

Następnie porównaj wyniki obu bibliotek z uzgodnionymi ocenami, zwracając szczególną uwagę na odpowiedzi, które metryka przepuszcza, a ludzie odrzucają. Jeśli celem jest wybór nowej wersji systemu RAG, dodaj pary odpowiedzi na te same pytania wygenerowane przez różne wersje. Sprawdź, czy ludzie i metryka wskazują tę samą lepszą odpowiedź. Sama korelacja na wynikach jednego systemu może bowiem odzwierciedlać łatwość pytań, a nie zdolność metryki do wykrycia poprawy między wersjami. Dopiero takie porównanie daje podstawę do ustawienia progu, który ma zatrzymywać konkretne regresje w CI.

Przeczytaj także:

• AI Act: kontrola człowieka może zwolnić tekst z etykiety
• Fałszywy sklep może wyglądać profesjonalnie — sprawdź go przed płatnością
• Zgoda człowieka w agencie AI: zatrzymaj akcję przed skutkiem ubocznym