Poprawa odpowiedzi RAG poprzez wprowadzanie jednej zmierzonej modyfikacji na raz
Proces pracy oparty na pomiarach w celu poprawy słabych odpowiedzi RAG: dostosowywanie krok po kroku podziału na fragmenty, parametru top_k, ponownego sortowania, wyszukiwania hybrydowego oraz przepisywania zapytań, przy jednoczesnym monitorowaniu metryk pozyskiwania informacji.
Pierwszy pipeline RAG jest łatwy do skonstruowania: należy załadować dokumenty, włączyć je do modelu, przechować wektory, pobrać kilka fragmentów i przekazać je modelowi LLM. System działa, ale odpowiedzi są często błędne, nawet gdy dokument zawiera wyraźnie prawidłowe informacje. W większości takich przypadków winowajcą nie jest model – krok pobierania danych nigdy nie dostarczył mu właściwego kontekstu. Ten przewodnik omawia elementy procesu pobierania danych, które zazwyczaj mają największe znaczenie, a co ważniejsze, przedstawia metodyczny sposób na sprawdzenie, które z nich faktycznie pomagają twojemu systemowi.
Najpierw traktuj błędne odpowiedzi jako problemy z pobieraniem danych
Zanim zmienisz prompty lub modele, sprawdź, jakie dane zostały pobraane w przypadku błędnej pytania. Jeśli odpowiedni fragment brakuje w kontekście, żadna modyfikacja promptu nie poprawi odpowiedzi.
Dziel na fragmenty według sensownych granic
Rozmiar fragmentów ma zaskakująco duży wpływ na jakość wydobywania informacji. Zbyt duże fragmenty łączą kilka tematów, przez co ich reprezentacje stają się niejasne i przyciągają teksty niespowiązane. Zbyt małe fragmenty oddzielają zdania od kontekstu, który nadaje im znaczenie. Zamiast ślepo dzielić tekst co 500 znaków, trzymaj ze sobą powiązane akapity lub całe sekcje, a jako naturalne punkty podziału używaj nagłówków i przerw między akapitami.
Dostosuj wartość top_k zamiast zgadywać ją
Wiele systemów pobiera pięć najbardziej podobnych fragmentów po prostu dlatego, że pięć jest powszechnym standardem. Jednak właściwy fragment może znajdować się na pozycji szóstej lub siódmej. Zwiększenie wartości top_k może poprawić dokładność wyników, ale każdy dodatkowy fragment wprowadza również szum i tokeny do zapytania. Traktuj top_k jako parametr do testowania w oparciu o własne pytania, a nie jako stałą do kopiowania. Inną opcją są progi istotności, o których mowa w przekraczanie ograniczeń top-k za pomocą progów, hybrydowego wyszukiwania i ponownego sortowania.
Dodanie etapu ponownego sortowania
Poszukiwanie wektorowe jest szybkie, ale ma niską dokładność: dobrze radzi sobie z znajdowaniem prawdopodobnych kandydatów, ale gorzej decyduje, który z nich jest naprawdę najlepszy. Model ponownego rankowania przeprowadza drugą analizę – najpierw poszukiwanie wektorowe zwraca szerszy zbiór wyników, na przykład dziesięć fragmentów, a następnie model rankowania, zazwyczaj kodownik krzyżowy, który łączy zapytanie z każdym fragmentem, ocenia je i zachowuje trzy lub cztery najlepsze. Model otrzymuje bardziej klarowny kontekst, ale za to występuje większy opóźnienie i wyższy koszt na zapytanie.
Łączenie poszukiwania semantycznego i słów kluczowych
Embeddingi dobrze oddają znaczenie, ale czasami dokładne tokeny są ważniejsze niż sens. Zapytanie takie jak ERROR_CODE_4291 ma niewiele treści semantycznej, więc poszukiwanie podobieństwa może pominąć dokument, w którym ono występuje. Rankowanie słów kluczowych, np. BM25, dobrze radzi sobie z takimi przypadkami. Dlatego wiele systemów wykorzystuje zarówno poszukiwanie wektorowe, jak i oparte na słowach kluczowych, a następnie łączy wyniki – taka metoda nazywana jest poszukiwaniem hybrydowym.
Zamknij luki w słownictwie w zapytaniach
Użytkownicy rzadko formułują pytania w taki sposób, jak napisane są dokumenty. Ktoś może zapytać, dlaczego transakcja nie udaje się sfinalizować, podczas gdy odpowiednia strona mówi o błędzie w autoryzacji karty. Przerabianie zapytań, MultiQuery (tworzenie kilku wariantów sformułowania i wyszukiwanie dla każdego z nich) oraz HyDE (tworzenie hipotetycznej odpowiedzi i wyszukiwanie jej za pomocą embeddingu) mogą pomóc w zamknięciu tej luki. Jednakże zwiększają one liczbę wywołań LLM oraz stopień złożoności, więc należy je stosować dopiero po wypróbowaniu prostszych rozwiązań.
Mierz każdą zmianę w odniesieniu do punktu wyjścia
Najważniejszym nawykiem jest unikanie domysłów. „Dodaliśmy ponowne sortowanie, więc wyniki wyszukiwania są lepsze” to hipoteza, dopóki nie zostanie zweryfikowana. Stwórz małą kolekcję rzeczywistych pytań z znanych, relevantnych fragmentów tekstu, a następnie śledź takie wskaźniki jak:
- Recall@K: czy prawidłowe informacje pojawiają się w pierwszych K zidentyfikowanych fragmentach.
Najpierw zapisz wartość bazową. W przykładowym przeprowadzeniu może to wyglądać w ten sposób:
Baseline Recall@5: 68%
Następnie wprowadzaj jedną zmianę naraz, ponownie zadawaj te same pytania i zapisuj każdy wynik. Sekwencja ulepszeń może wyglądać w ten sposób:
Better chunking: 74%
Hybrid search: 82%
Reranking: 89%
Te wartości są przykładem, a nie punktem odniesienia; twoje własne dane będą się zachowywać inaczej. Chodzi o to, że dziennik zmian pokazuje, który krok był przyczyną wzrostu złożoności, a który nie. Aby dowiedzieć się więcej na temat identyfikacji błędów, zapoznaj się z oceną RAG według etapu błędu.
Podsumowanie
Zacznij od najprostszego procesu: od zapytania, przez wyszukiwanie danych, aż po kontekst i model językowy, i poprawiaj jeden etap po drugim: wprowadź zmianę, ją zmierz, oceni jej opóźnienie i koszt, a następnie powtórz proces. Skromny system RAG, którego rozumiesz i możesz zmierzyć, zazwyczaj jest cenniejszy niż rozbudowany system pełen technik, których nikt nie potrafi uzasadnić liczbami.