Wyszukiwanie i ocena w RAG: Dlaczego proces wydobywania informacji wymaga oddzielnego etapu ponownego rankowania
RAG wymaga funkcji wyszukiwania i oceny: embeddingi znajdują kandydatów, ale nie potrafią ocenić ich istotności. Projekt dwuetapowy z wykorzystaniem RRF, kodowników krzyżowych, ColBERT oraz narzędzi do ponownego rankowania LLM.
Wiele zespołów napotyka te same trudności przy wykorzystaniu generacji wzmocnionej pobieraniem danych. Na tablicy pisarskiej system wygląda schludnie: wprowadza się zapytanie, porównuje wektory, przekazuje najlepsze wyniki modelowi i otrzymuje odpowiedź. W warunkach produkcyjnych szybko pojawiają się problemy. Pomijane są istotne dokumenty, dostają się nieistotne fragmenty, lekko zmienione pytanie zmienia odpowiedź, a halucynacje utrzymują się nawet wtedy, gdy wydaje się, że pobieranie danych zadziałało poprawnie.
Zwykłą reakcją jest zastąpienie modelu embeddingu lepszym, zwiększenie wymiaru wektorów lub dostosowanie parametrów top-k i rozmiaru fragmentów. Takie działania są rozsądne, ale dotyczą niewłaściwego elementu. Głębszy problem ma charakter architektoniczny. Konwencjonalny proces wymaga od jednego mechanizmu – porównywania podobieństwa embeddingów – wykonywania dwóch zupełnie różnych zadań: znajdowania kandydatów oraz decydowania, które z nich są istotne.
Rozwiązaniem jest podzielenie zadań. Można zastosować metodę wyszukiwania wzorców i oceny: projekt dwuetapowy, w którym generowanie kandydatów oraz ocena ich istotności to odrębne problemy inżynieryjne rozwiązywane za pomocą oddzielnych narzędzi.
Dlaczego sama podobieństwo nie wystarcza
Naive RAG przekształca zapytanie na wektor embeddingowy, wybiera K najbliższych fragmentów z bazy wiedzy, umieszcza je obok pytania i pozwala modelowi udzielić odpowiedzi. Nieujawnionym założeniem jest, że bliskość równa się istotności, dlatego lista K najbliższych wyników jest przyjmowana bez żadnej weryfikacji. W tym podejściu występuje cztery problemy.
To, co podobne, nie jest tym samym co istotne. Odległość embeddingowa jest tylko przybliżonym wskaźnikiem bliskości tematycznej. Dwa fragmenty mogą znajdować się blisko siebie, nie odpowiadając jednocześnie na pytanie postawione przez drugi. Tekst dotyczący wytycznych leczenia nadciśnienia tętniczego oraz tekst o metodologii badań klinicznych leków kardiologicznych mogą być umieszczone obok siebie, ale tylko pierwszy może pomóc osobie decydującej o sposobie leczenia pacjenta.
Kolejność jest słaba. Odległość wektorowa jest metodą heurystyczną, a nie funkcją rankingu zaprojektowaną tak, by pozycja odzwierciedlała istotność. Różnica pomiędzy trzecim a siódmym wynikiem w rankingu kosinusowym często stanowi szum.
Kontekst ulega fragmentacji. Dzielenie tekstu na fragmenty niszczy relacje, hierarchię oraz związki przyczynowo-skutkowe. Fragment opisujący dawkowanie może znaleźć się oddzielnie od fragmentu opisującego przeciwwskazania, a żaden z nich sam w sobie nie jest kompletny.
Wyniki są niestabilne. Niewielkie zmiany sformułowania mogą wpłynąć na zbiór top-K. Zadawanie pytań o skutki uboczne metforminy w porównaniu z reakcjami niepożądanymi na metforminę może przynieść różne kandydaty, a ostateczna odpowiedź może ulec zmianie w zależności od nich. To jest wada niepewności, a nie detal dotyczący optymalizacji.
Krótko mówiąc, wyszukiwarka dostarcza kandydatów. Nie gwarantuje jednak poprawności.
Projekt dwuetapowy
Zamiast jednego systemu, który znajduje i ocenia, należy stworzyć dwa etapy, z których każdy jest dostosowany do swojego celu.
Pierwszy etap – wyszukiwanie, polega na celowym rozszerzeniu zakresu poszukiwań. Wybiera się od 50 do 200 kandydatów, znacznie więcej, niż kiedykolwiek pokazałoby się modelowi, ponieważ celem tutaj jest pokrycie. Prawidłowe dokumenty muszą się po prostu znajdować gdzieś w tym zbiorze, nawet jeśli jest on zanieczyszczony.
Druga faza, sędzio, wykorzystuje znacznie bardziej rygorystyczny test. Zazwyczaj chodzi o narzędzie typu cross-encoder reranker, które łączy zapytanie z każdym kandydatem i oblicza rzeczywisty wynik powiązania. Dzięki temu liczba dostępnych fragmentów zmniejsza się do pięciu–dziesięciu o wysokim stopniu wiarygodności. Dopiero wtedy zebrany kontekst trafia do modelu językowego.
Jakie właściwie wpływają embeddingi
Nieprawidłowe rozumienie roli embeddingów sprawia, że zespoły polegają na nich zbyt mocno. Wyobraźmy sobie bibliotekarza, który nie czyta każdej książki, ale oznacza każdą kilkoma kluczowymi tematami. Gdy pojawia się pytanie, bibliotekarz przekształca je na odpowiednie tagi i wybiera książki, których tagi najlepiej do nich pasują. To szybkie i zazwyczaj przynosi coś przydatnego, ale opiera się na powierzchownych tematach, a nie na głębokim zrozumieniu, więc niektóre książki są powiązane, choć nie są tym, czego potrzebujemy.
Skutek: waszym modelem embeddingowym jest wasze zachowanie podczas wyszukiwania. To on decyduje, co zostanie znalezione, a co przeoczone. Nie decyduje on o tym, co jest poprawne – to jest rolą etapu oceny.
Wybór modelu embeddingowego jest zatem decyzją dotyczącą stopnia odzyskiwania informacji. Wybieracie Państwo „soczewkę”, przez którą pierwszy etap postrzega korpus. Należy rozważyć takie wskaźniki jak MTEB i BEIR, zakres obsługi języków, rozmiar modelu w odniesieniu do waszego sprzętu, wymiary wektorów, maksymalną długość danych wejściowych oraz szybkość przetwarzania. Wszystko to dotyczy aspektów związanych z odzyskiwaniem informacji.
Opcje dla etapu oceny i sytuacje, w których są one odpowiednie
Etap oceny to jedna z ról w architekturze. Może go pełnić kilka implementacji, z różnymi kompromisami pod względem dokładności, opóźnienia, złożoności i kosztu.
Fuzja rang recyplikatnych
RRF w ogóle nie ocenia istotności. Łączy uporządkowane listy z kilku źródeł, na przykład wyszukiwanie według słów kluczowych i wyszukiwanie semantyczne, w jedną listę uporządkowań. Dla każdego dokumentu dodaje wartość 1 / (k + rank) we wszystkich listach, gdzie k to stała, zwykle 60, która łagodzi dominację najwyższych pozycji w rankingu. Dokumenty, które plasują się wysoko w kilku listach, awansują.
Metoda ta jest szybka, deterministyczna, nie wymaga inferencji modelu i nie powoduje praktycznie żadnego opóźnienia. Ponieważ wykorzystuje pozycje w rankingu, a nie surowe wyniki, unika niespójności pomiędzy wynikami BM25 a podobieństwem kosinowym, więc nie ma potrzeby normalizacji.
Jego ograniczeniem jest to, że potrafi jedynie rozpoznawać zgodność. Jeśli kilka systemów wyszukiwania uznaje dokument za ważny, RRF zakłada, że zapewne tak jest. To rozsądna heurystyka, ale nadal pozostaje heurystyką. Nie może uratować istotnego dokumentu, który przeoczyły wszystkie systemy wyszukiwania, ani nie może odróżnić dokumentu tematycznie powiązanego od tego, który odpowiada na pytanie.
Wykorzystuj go w wyszukiwaniu hybrydowym, gdy potrzebujesz prostego sposobu na łączenie list. Należy go zastosować na etapie wyszukiwania w celu ulepszenia listy kandydatów, ale nie zastępuje on osoby oceniającej.
Kodery krzyżowe
Kodownik krzyżowy przekazuje zapytanie i jeden z kandydatów do modelu jako jedną połączoną sekwencję i zwraca wynik oceny powiązania. Kodowniki dwukierunkowe embedują zapytanie i dokument oddzielnie od siebie, podczas gdy tutaj każdy token pytania może oddziaływać z każdym tokenem tekstu. Dzięki temu model może analizować, w jaki sposób konkretne frazy w pytaniu odnoszą się do konkretnych fraz w tekście. Typowymi przykładami są modele Sentence Transformers, takie jak cross-encoder/ms-marco-MiniLM-L-12-v2, usługi rerankingu oraz kodowniki krzyżowe dostosowane do danych medycznych, prawniczych lub naukowych.
Ich zaletą jest dokładność. W testach rankingowych zazwyczaj przewyższają inne podejścia, ponieważ potrafią uchwycić drobne interakcje, których nie jest w stanie zrobić tylko porównanie podobieństwa embedów. To najbliższa możliwa metoda sprawdzenia, czy dokument rzeczywiście odpowiada na pytanie, bez konieczności wywoływania pełnego modelu LLM.
Koszt polega na osobnym przetworzeniu każdej pary zapytania i kandydata. Zbiór 100 dokumentów oznacza 100 uruchomień modelu na każde zapytanie, więc opóźnienie rośnie liniowo wraz z rozmiarem zbioru, a większe modele pogarszają tę sytuację.
Są one domyślnym rozwiązaniem tam, gdzie najważniejsza jest jakość odpowiedzi: w ochronie zdrowia, prawie, przestrzeganiu przepisów, analizie finansowej – wszędzie tam, gdzie błędne odnalezienie informacji ma poważne konsekwencje. Jeśli budżet opóźnienia pozwala na ponowne sortowanie trwające około 50 do 200 milisekund, co jest możliwe w większości systemów niereal-time, zacznij od nich.
ColBERT i późna interakcja
ColBERT, skrót od contextualized late interaction over BERT, znajduje się pomiędzy bi-encodery a cross-encodery. Koduje zapytanie i dokument niezależnie na wektory dla każdego tokena, a następnie ocenia je poprzez dopasowywanie tokenów zapytania do tokenów dokumentu. Ponieważ wektory dokumentów mogą być obliczone z góry, ich użycie w momencie wysyłania zapytania jest znacznie tańsze niż w przypadku cross-encodera, przy jednoczesnym zachowaniu większej ilości szczegółów niż w przypadku pojedynczego wektora połączonego. Wadą jest większy rozmiar indeksu, ponieważ każdy token ma swój własny wektor. Nadaje się do systemów, które wymagają lepszej klasyfikacji niż zwykłe embeddingi, a jednocześnie potrzebują wyższej przepustowości niż może zapewnić cross-encoder.
SZU jako sędzia
Model językowy ogólny może bezpośrednio oceniać kandydatów. Potrafi radzić sobie z subtelnymi, wieloetapowymi kryteriami istotności, na przykład rozpoznając, że dokument o interakcjach leków ma związek z pytaniem dotyczącym bezpieczeństwa leczenia, mimo że słownictwo nie pokrywa się. Może również stosować wyraźne kryteria istotności podane w instrukcjach, co sprawia, że jest dostosowywalny do specyficznych dla danej dziedziny definicji istotności.
Jest to również zdecydowanie najdroższa opcja. Jedna operacja ponownego rankingu może trwać od jednej do pięciu sekund i kosztować od dziesięciu do stu razy więcej niż jedna próba przetwarzania za pomocą cross-encodera. Wyniki mogą się różnić pomiędzy poszczególnymi próbami, a modele wykazują stronniczość pozycyjną, faworyzując dokumenty umieszczone wcześniej w instrukcjach. Modele hostowane dodatkowo wprowadzają zewnętrzną zależność.
Ma to sens w dwóch sytuacjach: przy pracy offline lub w zleceniach zbiorczych, gdzie opóźnienie nie ma znaczenia, takich jak tworzenie starannie opracowanych baz wiedzy, ocena procesu wyszukiwania podczas rozwoju lub generowanie danych treningowych dla specjalistycznego narzędzia do ponownego sortowania wyników; oraz w narzędziach o wysokim stopniu zaawansowania, ale niskiej objętości, gdzie wartość prawidłowej odpowiedzi usprawiedliwia koszt za każde zapytanie, jak w przypadku badań medycznych lub prawniczych na poziomie ekspertów.
Wybór modeli dla każdego etapu
Zrozumienie wzorca to jedno, a wybór modeli to coś zupełnie innego. Architektura stawia przed nami dwie decyzje dotyczące wyboru, z których każda jest podyktowana charakterem zadania.
Zacznij od zadania
Odpowiadanie na pytania kliniczne, analiza dokumentów oraz przestrzeganie przepisów regulacyjnych wymagają różnych podejść. Kontrola jakości wymaga wysokiej precyzji przy małej liczbie elementów do sprawdzenia. Analiza dokumentów ceni sobie szerokość i różnorodność. Przestrzeganie przepisów wymaga metody wyszukiwania deterministycznej i poddawalnej audytowi, z minimalną liczbą fałszywie ujemnych wyników. Profil zadania kształtuje każdą późniejszą decyzję.
Model embedding określa górny limit trafności wyników
Określa on, co system może znaleźć przed interwencją osoby oceniającej. Relevancki dokument, który nigdy nie trafia do zbioru danych, nie może zostać odzyskany przez żaden inny algorytm sortujący. Porównuj kandydatów pod kątem następujących czynników:
- Wskaźniki jakości. Sprawdź wyniki MTEB i BEIR dla typu zadania najbliższego twojemu, takiego jak wyszukiwanie fragmentów tekstu lub odpowiadanie na pytania, a nie tylko ogólną ocenę.
- Języki i dziedzina. Modele wielojęzyczne oferują szerszy zakres kosztem częściowej precyzji modeli jednojęzycznych, natomiast modele dostosowane do konkretnej dziedziny robią odwrotnie. Sprawdź, czy model obejmuje wszystkie potrzebne terminy.
- Rozmiar i infrastruktura. Większe modele zazwyczaj zapewniają lepsze wyniki, ale są droższe w skali produkcji. Weź pod uwagę objętość indeksowania, przepustowość zapytań oraz korzyści z użycia GPU w porównaniu z CPU. Model o trzy procent lepszy w teście, który wymaga dwukrotnie większych zasobów obliczeniowych, może okazać się słabym rozwiązaniem.
- Rozmiar wektorowy. Więcej wymiarów pozwala na uchwycenie większej liczby niuansów, ale zwiększa zapotrzebowanie na przechowywanie i opóźnienia. Wiele modeli dostępnych jest w kilku rozmiarach, więc sprawdź, czy różnica między 768 a 1536 wymiarami uzasadnia dodatkowe koszty.
- Maksymalna długość danych wejściowych. To ogranicza możliwość dzielenia danych na fragmenty. Limit 512 tokenów zmusza do tworzenia małych fragmentów, co prowadzi do większej fragmentacji, natomiast 2048 lub 8192 tokenów pozwala zachować więcej kontekstu w każdym fragmencie.
- Szybkość. Opóźnienie przy wgrzaniu danych ma znaczenie zarówno podczas tworzenia indeksu, jak i podczas wyszukiwania. Mniejsze modele mogą zapewnić dobrą dokładność przy znacznie niższym opóźnieniu, gdy wymagania SLA są surowe.
Zasada: należy dostosować model do wgrzania danych pod kątem zakresu pokrycia i szybkości, a nie dokładności. Dokładność to zadanie osoby oceniającej.
Reranker określa ostateczną poprawność
Jest to ostatni filtr przed LLM, więc jego jakość bezpośrednio wpływa na dokładność odpowiedzi. Należy go ocenić pod kątem:
- Dokładności rankingu. Główna miara efektywności. Sprawdź wartości nDCG, MRR i MAP w benchmarkach odpowiadających twojej dziedzinie. Nawet niewielkie ulepszenia mogą znacząco zmniejszyć ilość błędnych informacji w wynikach.
- Opóźnienia. Reranker jest uruchamiany raz na każdą kandydatkę, więc 100 kandydatów oznacza 100 iteracji. Czas na jedną iterację oraz całkowity czas są istotnymi ograniczeniami w produkcji.
- Współgranie z domeną. Ogólne narzędzia do ponownego rankowania radzą sobie dobrze przy szerokim wyszukiwaniu, ale domeny o dużym znaczeniu często czerpią korzyści z narzędzi dostosowanych na podstawie danych dotyczących relevancji w danej domenie. Narzędzie szkolenie na literaturze medycznej będzie lepiej oceniać zapytania kliniczne niż ogólne narzędzie, nawet jeśli to drugie osiąga wyższe wyniki w ogólnych testach.
- Przepustowość. Przy dużym ruchu narzędzie do ponownego rankowania może stać się wąskim gardłem. Rozważ zastosowanie grupowania zapytań, paralelizmu modeli oraz możliwość użycia lżejszej alternatywy, takiej jak skondensowany cross-encoder lub model oparty na późnej interakcji, który zapewnia akceptowalną dokładność przy znacznie wyższej przepustowości.
Inwestuj w oba rozwiązania
Najlepsze systemy nie muszą wybierać między dobrym narzędziem do embedowania a dobrym narzędziem do ponownego rankowania, ponieważ oba pełnią nieprzekrywające się zadania. Silne narzędzie do embedowania w połączeniu z słabym narzędziem do rankowania daje wysoki wskaźnik odnalezienia, ale zanieczyszczone wyniki końcowe. Słabe narzędzie do embedowania w połączeniu z silnym narzędziem do rankowania zapewnia dokładne uporządkowanie wśród niekompletnej bazy kandydatów. Żadne z nich samo w sobie nie jest wystarczające.
Rozwiązanie polega na szybkim wyszukiwaniu o wysokim wskaźniku odnalezienia w połączeniu z dokładną oceną. Dołącz narzędzie do embedowania do swoich potrzeb dotyczących wskaźnika odnalezienia, a narzędzie do rankowania do potrzeb dotyczących precyzji, a następnie dostosuj rozmiar bazy kandydatów pomiędzy poszczególnymi etapami, aby pogodzić zakres wyników z opóźnieniem w ponownym rankowaniu.
Przykład zastosowania
Załóżmy, że asystent kliniczny otrzymuje pytanie, czy pacjent przyjmujący określony lek na cukrzycę może bezpiecznie zażywać drugi lek. Etap wyszukiwania przeprowadza równolegle zapytanie słowne i wektorowe, łączy je za pomocą RRF i zachowuje 100 kandydatów. Wśród nich znajdują się monografia każdego leku, artykuł o projektowaniu badań klinicznych, ogólny ulotnik żywieniowy oraz kilka tabel interakcji. Samo podobieństwo mogłoby umieścić artykuł o badaniach klinicznych i ulotnik powyżej tabel interakcji, ponieważ ich słownictwo jest bliższe pytaniu.
Etap sędziego czyta pytanie obok każdego z stu fragmentów i ocenia, czy fragment rzeczywiście dotyczy wspólnego wykorzystania. Tabela interakcji oraz odpowiedni akapit z przeciwwskazaniami wyrastają na górę, ulotka spada, a model otrzymuje sześć fragmentów zamiast hałaśliwych dziesięciu. To samo korpus, te same embeddingi, inny wynik – ponieważ drugi komponent podjął decyzję, której pierwszy nigdy nie został stworzony do podejmowania.
Dostosowywanie przejścia między etapami
Wielkość zbioru kandydatów jest kluczowym parametrem. Jeśli jest zbyt mała, sędzia nigdy nie zobaczy właściwego fragmentu, co ogranicza skuteczność wyszukiwania w całym systemie. Jeśli jest zbyt duża, opóźnienia i koszty ponownego sortowania rosną bez większych korzyści. Praktycznym sposobem na ustawienie tego parametru jest zapisanie, na oznaczonym przykładzie, rankingu, w którym właściwy fragment pojawia się na pierwszym etapie, a następnie wybranie zbioru obejmującego prawie wszystkie takie przypadki. Jeśli właściwy fragment regularnie znajduje się po rankingu 150, problem prawdopodobnie leży w etapie wyszukiwania – konieczne może być ulepszone narzędzie do embedowania, hybrydowe metody wyszukiwania lub lepsze dzielenie tekstu na fragmenty – a nie większy mechanizm ponownego sortowania.
Inne nawyki również pomagają:
- Oceniaj oba etapy oddzielnie. Mierz skuteczność wyszukiwania w zbiorze kandydatów przed oceną oraz dokładność ostatecznej listy po niej, aby można było zlokalizować źródło problemu w odpowiednim etapie.
- Przechowuj wyniki ponownego sortowania dla często wyszukiwanych zapytań, gdy korpus zmienia się powoli.
- Utrzymuj mały zakres kontekstu końcowego. Lepiej jest użyć pięciu mocnych fragmentów niż dwudziestu mieszanych, ponieważ dodatkowy materiał konkuruje o uwagę.
- Przeglądaj ustawienia ponownie, gdy zmienia się skład korpusu lub zapytania, ponieważ algorytm dostosowany do jednej dziedziny może gwałtownie stracić skuteczność w innej.
Traktuj to jako hipotezę do sprawdzenia na własnych danych, a nie jako gwarancję, ponieważ korzyści różnią się w zależności od dziedziny oraz od tego, jak słaba była baza wyjściowa.
Główny wniosek
Niezawodny RAG nie powstaje dzięki znalezieniu lepszego embeddingu. Wynika on z oddzielenia procesu wyszukiwania od oceny – w jednym etapie maksymalizuje się zakres pokrycia, a w drugim dokładność.
Zmiana ta jest przede wszystkim koncepcyjna, a dopiero potem techniczna. Przestań traktować wyniki top-K jako ostateczną odpowiedź, a raczej jako zbiór kandydatów. Przestań traktować podobieństwo jako prawdę, a raczej jako hipotezę wymagającą weryfikacji. Wyszukuj szeroko, a następnie oceniaj precyzyjnie.
Powiązane materiały
- Zaawansowany RAG w Milvus: wyszukiwanie hybrydowe, HyDE, przepisywanie zapytań i ponowna klasyfikacja — Budowanie pipeline RAG w Milvus krok po kroku: wektory gęste i BM25, hybrydowe wyszukiwanie RRF, filtry metadanych, przepisywanie zapytań, HyDE, dekompozycja oraz ponowna klasyfikacja za pomocą cross-encodera.
- Notatki praktyczne: agenty AI nie potrzebują już wyszukiwania wektorowego: co kryje się za systemem Agentic — Szczegółowy przewodnik po notatkach praktycznych: agenty AI nie potrzebują już wyszukiwania wektorowego: co kryje się za systemem Agentic, w tym zastąpienie RAG w 2026 roku, kontrakty, sprawdzania oraz gotowy kod do wdrożenia.