Ewaluacja wyszukiwania w RAG

Ewaluacja wyszukiwania w RAG to pomiar jakości etapu, który wybiera dokumenty lub fragmenty dokumentów przed odpowiedzią modelu. RAG nie odpowiada wyłącznie na podstawie pamięci modelu. Najpierw wyszukuje kontekst w Twojej bazie wiedzy, a dopiero potem przekazuje go do LLM. Jeśli retriever nie znajdzie aktualnego cennika, właściwej procedury lub odpowiedzi na pytanie klienta, nawet bardzo dobry model nie ma z czego stworzyć rzetelnej odpowiedzi. Test wyszukiwania pyta więc: czy dla tego pytania system znalazł potrzebny materiał i czy nie zaśmiecił kontekstu nieistotnymi wynikami.

To inna rzecz niż ocena końcowej odpowiedzi. Odpowiedź może brzmieć dobrze, a mimo to być oparta na złym fragmencie. Może też być słaba mimo dobrych źródeł, bo zawiódł prompt lub model. Rozdzielenie tych etapów skraca diagnozę. Microsoft opisuje ewaluację procesu retrieval jako ocenę trafności pobranych fragmentów, a osobno mierzy ugruntowanie, relewancję i kompletność odpowiedzi. W praktyce najpierw otwierasz listę wyników zwróconych dla pytania, potem oceniasz tekst odpowiedzi. Nie poprawiaj obu warstw naraz, bo nie dowiesz się, co naprawdę zadziałało.

Najprostszy zestaw testowy to lista realnych pytań użytkowników wraz z oczekiwanym dokumentem lub fragmentem. Dla eksperta sprzedającego wiedzę mogą to być pytania o cenę, zakres usługi, termin, sposób współpracy, zwrot lub konkretny moduł kursu. Przy każdym pytaniu zapisz, który dokument musi znaleźć się w pierwszych k wynikach. Ten ręcznie przygotowany zestaw jest bardziej wartościowy niż przypadkowe prompty, bo odzwierciedla decyzje i ryzyko w prawdziwym biznesie. Z czasem dopisuj pytania z rozmów, które chatbot obsłużył źle.

Dwie podstawowe miary to precision i recall. Precision odpowiada, jaka część pobranych wyników jest trafna. Recall pyta, czy system znalazł wszystkie ważne materiały. Wskaźnik z dopiskiem @k odnosi się do pierwszych k wyników, na przykład Recall@5. Wysokie precision przy niskim recall oznacza, że wyniki są czyste, ale brakuje ważnych fragmentów. Wysokie recall przy niskim precision może przeładować kontekst szumem. Nie ma jednej wartości dobrej dla każdego projektu. Pytanie o cenę wymaga zwykle jednego precyzyjnego źródła, a pytanie o strategię może potrzebować kilku uzupełniających fragmentów.

Praktyczny przykład: asystent odpowiada na pytanie „co zawiera wdrożenie AI?”. Zespół oczekuje, że w top-3 znajdą się aktualna strona usługi, zakres prac i FAQ. Jeśli wyszukiwarka podaje stary artykuł zamiast oferty, nie zaczynaj od podnoszenia temperatury modelu. Sprawdź najpierw podział dokumentów na fragmenty, metadane, nazwy usług, aktualność indeksu i liczbę wyników. Potem porównaj warianty, na przykład wyszukiwanie semantyczne z hybrydowym lub inny reranking, na tym samym zestawie pytań. Dopiero wynik testu daje podstawę do zmiany.

Automatyczne metryki są pomocne, ale nie zastępują oceny człowieka. Narzędzia takie jak Ragas oferują miary kontekstu, odpowiedzi i wierności, a LLM jako sędzia może przyspieszyć przegląd dużej próbki. Taki sędzia też popełnia błędy i może źle rozumieć specyfikę oferty albo język polski. Dlatego zachowaj niewielki, ręcznie sprawdzony zestaw kontrolny z pytaniami krytycznymi. Nie optymalizuj systemu wyłącznie pod jeden wynik liczbowy. System, który idealnie odnajduje krótkie FAQ, może nadal przegrywać na pytaniach wymagających połączenia dwóch aktualnych dokumentów.

Ewaluację powtarzaj po zmianie bazy wiedzy, sposobu chunkingu, embeddingów, filtrów, modelu rerankera lub instrukcji wyszukiwania. RAG zmienia się, gdy zmieniają się dokumenty. Dodanie nowej oferty może wyprzeć starą, ale może też sprawić, że agent zacznie zwracać dwa sprzeczne cenniki. Zapisuj datę testu, wersję indeksu, użyte ustawienia i przykłady porażek. Dla małego biznesu wystarczy początkowo 20 do 30 reprezentatywnych pytań i regularne sprawdzanie tych najważniejszych. To daje kontrolę nad systemem bez udawania, że chatbot jest nieomylny.