Zbudowałeś swoją pierwszą aplikację RAG (Retrieval-Augmented Generation). Działa. Wprowadzasz zapytanie, a model językowy, wspierany przez Twoją bazę wiedzy, generuje odpowiedź. Sukces! Ale… czy na pewno? Skąd wiesz, że ta odpowiedź jest dobra? Czy jest wierna faktom z Twoich dokumentów? A może to tylko zgrabnie brzmiąca halucynacja?
W świecie, gdzie każdy może postawić prosty system RAG w jedno popołudnie, prawdziwą wartością staje się jego niezawodność i jakość. Kluczem do osiągnięcia tego celu jest systematyczne testowanie i iteracyjne ulepszanie. W tym wpisie przejdziemy krok po kroku przez proces budowania frameworka do oceny Twojej aplikacji RAG, tak abyś mógł z pełnym przekonaniem powiedzieć: „Tak, to działa i wiem, dlaczego”. Zaczynajmy!
Spis treści
- Budowa zestawu testowego: Skąd brać pytania?
- Ręczne i półautomatyczne ocenianie: Witajcie, Faithfulness i Groundedness!
- Scoring, czyli jak zamienić „chyba jest OK” na twarde dane.
- Iteracja to klucz: Jak ulepszać prompty i źródła danych?
- Podsumowanie: Droga do niezawodnego RAG.
Zacznijmy od pytań: Jak zbudować solidny zestaw testowy?
Nie możesz ulepszyć czegoś, czego nie mierzysz. Pierwszym krokiem do oceny systemu RAG jest stworzenie zróżnicowanego zestawu pytań testowych (tzw. „golden dataset”). To Twój benchmark, Twoje lustro, w którym będziesz przeglądać działanie aplikacji. Pytania te powinny symulować realne scenariusze użycia i sprawdzać system pod różnymi kątami.
Skąd czerpać inspirację do pytań?
Dobry zestaw testowy powinien być jak szwedzki stół – różnorodny i obejmujący szerokie spektrum możliwości. Oto kilka źródeł, z których warto skorzystać:
- Prawdziwe zapytania użytkowników: Jeśli masz już wczesnych użytkowników, ich zapytania są złotem. To najbardziej autentyczny materiał do testów.
- Sekcja FAQ i dokumentacja: Przekształć istniejące pytania i odpowiedzi z Twojej bazy wiedzy w zestaw testowy. To świetny sposób na sprawdzenie, czy model potrafi znaleźć proste, jednoznaczne informacje.
- „Red Teaming”: Celowo twórz podchwytliwe pytania. Co się stanie, gdy zadasz pytanie na temat, którego nie ma w bazie? A jeśli pytanie jest niejednoznaczne? Albo wymaga połączenia informacji z dwóch różnych dokumentów? Testowanie przypadków brzegowych to podstawa.
- Pytania syntetyczne: Możesz użyć innego modelu LLM, aby na podstawie Twoich dokumentów wygenerował pary (pytanie, odpowiedź). To świetny sposób na szybkie skalowanie zestawu testowego.
Pamiętaj, aby Twój zestaw zawierał zarówno proste pytania („Jaki jest adres firmy?”), jak i te wymagające syntezy informacji („Porównaj plan A i plan B pod względem kosztów i korzyści dla małej firmy”).
Oceniamy odpowiedzi: Faithfulness i Groundedness na ratunek
Mamy pytania, mamy odpowiedzi. Teraz czas na najtrudniejszą część: ocenę. Samo przeczytanie odpowiedzi i stwierdzenie „wygląda OK” to za mało. W praktyce stosuje się kilka kluczowych metryk, z których dwie najważniejsze to Faithfulness i Groundedness (czasem nazywane też Relevance).
Faithfulness: Czy model nie halucynuje?
Faithfulness (wierność) to metryka, która odpowiada na jedno, fundamentalne pytanie: czy wygenerowana odpowiedź jest w 100% oparta na informacjach z dostarczonego kontekstu (retrieved chunks)? Innymi słowy, czy model nie dodaje nic od siebie, nie wymyśla faktów i nie wprowadza w błąd. To absolutna podstawa zaufania do systemu RAG.
Przykład niskiej wierności: Pytasz o godziny otwarcia biura. Kontekst mówi: „Biuro jest czynne od 9:00 do 17:00 w dni robocze”. Model odpowiada: „Biuro jest czynne od 9:00 do 17:00 od poniedziałku do piątku, a w soboty mamy specjalne dyżury”. Ta druga część to halucynacja.
Groundedness/Relevance: Czy odpowiedź jest na temat?
Groundedness (uziemienie) lub Relevance (trafność) sprawdza, czy odpowiedź faktycznie odnosi się do oryginalnego pytania użytkownika. Może się zdarzyć, że odpowiedź jest w 100% wierna kontekstowi (wysoki Faithfulness), ale kompletnie mija się z intencją pytającego, ponieważ system odnalazł nieprawidłowy fragment dokumentu.
Dobra odpowiedź musi mieć zarówno wysoki Faithfulness, jak i wysoki Groundedness. Jedno bez drugiego jest bezużyteczne. Wierna odpowiedź na inne pytanie jest tak samo zła, jak zmyślona odpowiedź na właściwe pytanie.
Od oceny do akcji: Scoring i iteracyjne ulepszanie
Kiedy już wiesz, czego szukać, musisz zamienić te jakościowe oceny na twarde dane. Najprostszym sposobem jest ręczne ocenianie, gdzie ewaluator (czyli Ty lub Twój zespół) przypisuje każdej odpowiedzi wynik, np. w skali binarnej (0/1) lub 1-5 dla każdej z metryk.
Ręczna ocena jest dokładna, ale czasochłonna. W miarę rozwoju projektu można wdrożyć podejście półautomatyczne, używając do oceny… innego LLM! Można stworzyć specjalny prompt, który prosi model (np. GPT-4) o ocenę odpowiedzi pod kątem wierności i trafności na podstawie pytania i kontekstu. To świetny sposób na skalowanie testów, choć wyniki zawsze warto weryfikować ręcznie.
Cykl iteracyjny: Ulepszanie promptów i źródeł
Zebrane wyniki to Twój panel sterowania. Analizuj, gdzie system najczęściej zawodzi:
- Niski Faithfulness: Najczęstszy problem. Rozwiązaniem jest zazwyczaj modyfikacja systemowego promptu. Spróbuj dodać instrukcje typu: „Odpowiadaj wyłącznie na podstawie dostarczonego kontekstu. Jeśli odpowiedź nie znajduje się w tekście, napisz 'Nie znam odpowiedzi’”.
- Niski Groundedness: To zazwyczaj problem z częścią „Retrieval”. Może Twoje dokumenty są źle podzielone na fragmenty (chunking)? A może model embeddingowy nie radzi sobie z Twoją domeną? Warto poeksperymentować z rozmiarem chunków, overlapem lub nawet spróbować innego modelu embeddingowego.
- Problemy ze źródłami: Czasem okazuje się, że problem leży w samych danych. Jeśli w bazie wiedzy masz sprzeczne lub nieaktualne informacje, żaden model sobie z tym nie poradzi. Regularny audyt i czyszczenie danych to podstawa.
Ten proces – test, analiza, poprawka – to nieustający cykl. Każda zmiana w prompcie, w danych czy w algorytmie retrievalu powinna być zweryfikowana przez ponowne uruchomienie Twojego zestawu testowego. Tylko w ten sposób masz pewność, że wprowadzane zmiany faktycznie ulepszają system, a nie psują coś, co już działało.
Budowa i ewaluacja zaawansowanych systemów opartych o LLM to złożony, ale niezwykle satysfakcjonujący proces. Jeśli potrzebujesz wsparcia w tym zakresie, zapraszam do kontaktu na mojej stronie głównej https://michalzareba.pl/.
Dodaj komentarz