Retrieval-augmented generation wygląda prosto w tutorialu: zaembeduj dokumenty, uruchom wyszukiwanie podobieństwa, wstaw wyniki do prompta. W produkcji ta naiwna wersja szybko się rozpada - a różnica między demo RAG i systemem RAG, któremu ludzie ufają, leży praktycznie całkowicie w warstwie wyszukiwania, nie w modelu.
01
Dlaczego naiwne top-k retrieval zawodzi w produkcji
Czyste wyszukiwanie podobieństwa wektorowego zwraca to, co semantycznie bliskie, nie zawsze to, co poprawne lub kompletne. Ma problem z dokładnymi terminami - kodami produktów, nazwami, akronimami - gdzie dopasowanie leksykalne wygrałoby jednoznacznie. Nie ma też koncepcji świeżości, autorytetu czy sprzeczności: jeśli baza wiedzy ma trzy wersje dokumentu polityki, top-k podobieństwa z chęcią zwróci najstarszą, jeśli akurat brzmi bardziej podobnie do zapytania.
Ten tryb zawodzenia jest też cichy - system nie zwraca błędu, po prostu odpowiada z przekonaniem, ale z niewłaściwym kontekstem, co jest gorsze niż brak odpowiedzi.
02
Wyszukiwanie hybrydowe (dense + sparse) i kiedy które wygrywa
Wyszukiwanie dense (embeddingi wektorowe) uchwytuje znaczenie semantyczne - synonimy, parafrazy, podobieństwo koncepcyjne. Wyszukiwanie sparse (BM25 i podobne metody leksykalne) uchwytuje sygnał dokładnego dopasowania - konkretny termin, kod czy nazwę, którą użytkownik faktycznie wpisał. Połączenie obu, zwykle przez równoległe uruchomienie i scalenie wyników ważoną punktacją lub reciprocal rank fusion, konsekwentnie bije każde z nich osobno na większości realnych zbiorów dokumentów.
Jako zasada: im więcej w Twojej domenie dokładnych identyfikatorów i żargonu - prawo, dokumentacja techniczna, wewnętrzne bazy kodu - tym więcej wyszukiwanie sparse wnosi względem dense.
03
Reranking jako zmiana o najwyższym wpływie
Wyszukiwanie i rankingowanie to różne zadania, a ich mylenie jest najczęstszym błędem w systemach RAG. Zadaniem wyszukiwania jest recall - zarzuć szeroką sieć, pobierz kandydatów z nadwyżką (np. top 50) tanim kosztem. Zadaniem rerankingu jest precyzja - weź tych kandydatów i oceń ich droższym, dokładniejszym modelem (cross-encoderem lub rerankerem na LLM), który faktycznie czyta zapytanie względem każdego kandydata, a nie tylko porównuje wcześniej wyliczone embeddingi.
W praktyce dodanie etapu rerankingu na istniejący pipeline wyszukiwania to zwykle jedna zmiana o najwyższym wpływie na jakość odpowiedzi - często większy skok niż zmiana modelu embeddingów.
“Warstwa wyszukiwania, nie model językowy, decyduje o większości dokładności systemu RAG.”
04
Ewaluacja: budowa zbioru testowego zanim wdrożysz
Nie możesz poprawić tego, czego nie mierzysz, a "odpowiedzi wyglądają sensownie, gdy próbuję" to nie jest strategia ewaluacji. Zbuduj mały, ale realny zbiór testowy: reprezentatywne zapytania sparowane z dokumentami, które powinny zostać wyszukane dla każdego. Śledź metryki wyszukiwania (recall@k, mean reciprocal rank) osobno od metryk generacji (czy końcowa odpowiedź poprawnie wykorzystuje wyszukany kontekst, czy konfabuluje poza nim).
Ten zbiór testowy staje się Twoim testem regresyjnym - każda zmiana strategii chunkowania, modelu embeddingów czy rerankera jest mierzona względem niego przed wdrożeniem, a nie oceniana na wyczucie w demo.
05
Obserwowalność: co logować i monitorować po wdrożeniu
W produkcji loguj wyszukane fragmenty razem z końcową odpowiedzią dla każdego zapytania - nie tylko odpowiedź. Gdy użytkownik zgłasza błędną lub nieadekwatną odpowiedź, musisz zobaczyć, czy zawiodło wyszukiwanie (zwrócono niewłaściwe fragmenty) czy generacja (właściwe fragmenty, błędna synteza), bo naprawa jest zupełnie inna w każdym przypadku.
Śledź latencję wyszukiwania i hit rate w czasie i uważaj na cichy dryf: gdy dokumenty źródłowe rosną i się zmieniają, jakość wyszukiwania może się degradować nawet bez żadnych zmian w kodzie, bo korpus przesunął się pod indeksem.
System RAG, który działa w demo, i system RAG, któremu ludzie ufają w produkcji, różnią się głównie tym, ile uwagi poświęcono warstwie wyszukiwania - wyszukiwanie hybrydowe zamiast czystych wektorów, etap rerankingu, realny zbiór testowy i logowanie, które pozwala diagnozować przyczyny błędów. Nic z tego nie jest egzotyczne - to po prostu ta część, którą tutoriale pomijają.
Powiązane artykuły