08 · LLM · 4 min czytania · Interaktywne · aktualizacja
Czym jest RAG (retrieval-augmented generation) i jak działa?
W skrócie
RAG wyszukuje fragmenty dokumentów pasujące do pytania i wkleja je do promptu. Model odpowiada na podstawie źródeł, a nie tylko pamięci z treningu.
Co to jest
RAG (retrieval-augmented generation, generowanie wspomagane wyszukiwaniem) to architektura, w której model językowy przed odpowiedzią dostaje fragmenty dokumentów wyszukane pod kątem pytania. System najpierw przeszukuje bazę wiedzy (wyszukiwarką słów kluczowych, wektorową lub obiema), wybiera kilka najtrafniejszych fragmentów i wstawia je do promptu z poleceniem „odpowiedz na podstawie poniższych źródeł”. Nazwę i pierwszą wersję zaproponowali Lewis i in. (2020).
Intuicja: to różnica między egzaminem z pamięci a egzaminem z otwartą książką. Model wciąż musi rozumieć pytanie i umieć sformułować odpowiedź, ale fakty bierze ze wskazanych stron, a nie z mglistych wspomnień z pretreningu.
RAG to dziś najczęstszy sposób, by „podłączyć” LLM do firmowej dokumentacji, regulaminów, bazy zgłoszeń czy aktualnych wiadomości — bez dostrajania modelu.
Mechanizm — dlaczego tak działa
Dwie pamięci. Wiedza zapisana w wagach modelu (pamięć parametryczna) jest obszerna, ale nieprecyzyjna, zamrożona w dniu zakończenia treningu i niemożliwa do sprawdzenia. Baza dokumentów (pamięć nieparametryczna) jest dokładna, łatwa do aktualizacji i można wskazać, skąd pochodzi zdanie. RAG łączy obie: model wnosi rozumienie języka, a baza — fakty.
Dlaczego to zmniejsza halucynacje. Model generuje to, co jest prawdopodobne w danym kontekście. Gdy w kontekście jest akapit z odpowiedzią, najbardziej prawdopodobną kontynuacją staje się jego treść — model „przepisuje i parafrazuje” zamiast zgadywać. Zmniejsza to zmyślenia, ale ich nie eliminuje: model może źle połączyć fragmenty albo zignorować źródło na rzecz własnej wiedzy.
Potok. (1) Indeksowanie: dokumenty dzieli się na fragmenty (chunki) po kilkaset tokenów, zwykle z zakładką, i zamienia na embeddingi lub indeks słów. (2) Wyszukiwanie: pytanie przechodzi tę samą drogę, a system zwraca k najbliższych fragmentów. (3) Opcjonalny reranking: dokładniejszy, ale wolniejszy model ocenia pary pytanie–fragment i porządkuje wyniki. (4) Generowanie: fragmenty trafiają do promptu, często z prośbą o cytowanie źródeł.
Wyszukiwanie jest wąskim gardłem. Jeśli właściwy fragment nie trafi do kontekstu, nawet najlepszy model nie odpowie poprawnie. Wyszukiwanie leksykalne (BM25, TF-IDF) dobrze łapie nazwy własne i kody, ale nie rozumie synonimów ani odmiany. Wyszukiwanie gęste (embeddingi, Karpukhin i in., 2020) łapie znaczenie, ale bywa słabsze na rzadkich identyfikatorach. Dlatego popularne jest wyszukiwanie hybrydowe.
Ograniczenia. Zły podział na fragmenty rozcina odpowiedź na pół. Zbyt wiele fragmentów rozprasza model, a informacja w środku długiego kontekstu bywa pomijana. RAG słabo radzi sobie z pytaniami wymagającymi zebrania informacji z całego zbioru („ile umów podpisaliśmy w 2023 roku?”) — to zadanie raczej dla bazy danych i zapytań SQL.
Na przykładzie
Baza zawiera cztery zdania z regulaminu firmy: (1) „Urlop wypoczynkowy przysługuje pracownikowi w wymiarze 20 lub 26 dni rocznie.”, (2) „Wniosek o urlop składa się w systemie kadrowym co najmniej tydzień wcześniej.”, (3) o parkingu, (4) o delegacjach. Pytanie: „Jak złożyć wniosek o urlop?”. Wyszukiwanie TF-IDF z podobieństwem cosinusowym daje: zdanie 2 — 0,207, zdanie 1 — 0,084, zdania 3 i 4 — 0. Fragment 2 trafia na szczyt i model odpowie na jego podstawie, że wniosek składa się w systemie kadrowym z tygodniowym wyprzedzeniem.
Ten mały przykład pokazuje też słabość wyszukiwania leksykalnego w polskim: „złożyć” i „składa” to dla TF-IDF różne słowa, więc dopasowanie opiera się tylko na „wniosek” i „urlop”. Model embeddingowy uznałby je za bliskie. Skalę indeksowania łatwo policzyć: podręcznik o długości 100 000 tokenów pocięty na fragmenty po 500 tokenów z zakładką 50 daje 223 fragmenty do zaindeksowania.
W praktyce
- Fragmenty 200–800 tokenów z zakładką 10–20% to rozsądny punkt startu; dziel po strukturze dokumentu (nagłówki, akapity), a nie w połowie zdania.
- Do embeddingów używaj modelu wielojęzycznego, który dobrze radzi sobie z polskim; sprawdzaj go na własnych pytaniach.
- Łącz BM25 z wyszukiwaniem wektorowym i dodaj reranker (cross-encoder) dla kilkudziesięciu najlepszych kandydatów.
- Mierz osobno jakość wyszukiwania (czy właściwy fragment jest w top-k, recall@k) i jakość odpowiedzi (wierność źródłom).
- Typowy błąd: ocena całego systemu tylko po odpowiedziach — gdy coś nie działa, nie wiadomo, czy zawiódł wyszukiwacz, czy model.
Najczęstsze pytania
- RAG czy dostrajanie?
- RAG do faktów, które się zmieniają, które trzeba cytować lub które są poufne i rozproszone w dokumentach. Dostrajanie do stylu, formatu i umiejętności. Często łączy się oba: dostrojony model lepiej korzysta z dostarczonych źródeł.
- Czy RAG eliminuje halucynacje?
- Nie, ale wyraźnie je ogranicza i pozwala je wykryć, bo odpowiedź można porównać ze źródłem. Warto prosić model o cytaty i o odpowiedź „nie wiem”, gdy źródła nie zawierają informacji.
- Czy potrzebuję bazy wektorowej?
- Przy kilku tysiącach fragmentów wystarczy zwykłe przeszukanie wszystkich wektorów w pamięci. Specjalizowana baza lub indeks przybliżony (np. HNSW) opłaca się przy setkach tysięcy i milionach fragmentów.
Źródła
- Lewis P. i in., 2020, „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 2020.
- Karpukhin V. i in., 2020, „Dense Passage Retrieval for Open-Domain Question Answering”, EMNLP 2020.
- Robertson S., Zaragoza H., 2009, „The Probabilistic Relevance Framework: BM25 and Beyond”, Foundations and Trends in Information Retrieval 3(4).
- Liu N. F. i in., 2024, „Lost in the Middle: How Language Models Use Long Contexts”, Transactions of the ACL 12.
- Manning C. D., Raghavan P., Schütze H., 2008, „Introduction to Information Retrieval”, Cambridge University Press, rozdz. 6 (TF-IDF i model wektorowy).