RAG
Jak działa
Zapytanie użytkownika jest zamieniane na wektor osadzenia, następnie przeszukiwana jest baza wektorowa w celu znalezienia najbardziej podobnych fragmentów dokumentów. Pobrane fragmenty są dołączane do promptu, a model generuje odpowiedź na ich podstawie.
Rozwiązany problem
Modele językowe mają wiedzę zamrożoną w czasie treningu i nie znają aktualnych danych ani dokumentów prywatnych. RAG rozwiązuje to przez dynamiczne wzbogacanie kontekstu modelu o pobrane fragmenty dokumentów.
Komponenty
Komponent odpowiedzialny za wyszukiwanie najbardziej relewantnych dokumentów lub fragmentów z zewnętrznej bazy wiedzy, na podstawie zapytania użytkownika. W oryginalnym paperze Lewis et al. jest to Dense Passage Retrieval (DPR) — gęsty dwu-enkoderowy model (jeden enkoder dla zapytania, drugi dla dokumentów). W nowoczesnych pipeline'ach RAG retriever używa wstępnie obliczonych gęstych embeddingów i ANN search (np. FAISS) lub rzadkich metod (BM25), albo kombinacji obu (hybrid search).
Oficjalna
Baza danych przechowująca dokumenty lub ich fragmenty (chunki) wraz z preobliczonymi embeddingami wektorowymi, umożliwiająca efektywne wyszukiwanie przybliżone najbliższego sąsiada (ANN). W oryginalnym RAG indeks to FAISS z embeddingami DPR. W nowoczesnych implementacjach stosowane są wyspecjalizowane bazy wektorowe (np. Pinecone, Weaviate, ChromaDB, Qdrant, pgvector).
Oficjalna
Generatywny model języka kondycjonujący swoje wyjście na podstawie wejściowego zapytania oraz pobranych dokumentów. W oryginalnym RAG jest to BART (seq2seq Transformer). W nowoczesnych pipeline'ach RAG jest to dowolny LLM (GPT-4, Llama, Gemini itp.) z dołączonym kontekstem w prompcie. W oryginalnym RAG generator jest trenowany end-to-end razem z retrieverem; w nowoczesnych zastosowaniach jest zazwyczaj zamrożony.
Oficjalna
Komponent offline odpowiedzialny za podział źródłowych dokumentów na mniejsze fragmenty (chunki), obliczenie ich embeddingów i zaindeksowanie w bazie wektorowej. Jakość chunkoowania (rozmiar chunka, overlap) ma bezpośredni wpływ na jakość retrieval. Nie był wyróżnionym komponentem w oryginalnym RAG (który używał gotowych pasaży Wikipedii), ale jest kluczowym elementem nowoczesnych pipeline'ów RAG.
Oficjalna
Implementacja
Jeśli model embeddingu używa różnych enkoderów lub różnej tokenizacji dla zapytań i dokumentów (asymetryczne modele jak DPR), generowanie embeddingów dokumentów enkoderem zapytań (lub odwrotnie) daje złe wyniki retrieval. Modele symetryczne (np. SBERT) są odporniejsze na ten błąd.
Zbyt duże fragmenty dokumentów w indeksie zawierają dużo tekstu nieistotnego dla zapytania, co 'rozrzedza' sygnał kontekstowy i może prowadzić do halucynacji lub ignorowania istotnych fragmentów przez LLM. Problem znany jako 'lost in the middle' — LLM gorzej korzysta z informacji w środku długich kontekstów.
Przy zmianie modelu embeddingowego (np. aktualizacji do nowszej wersji), istniejące embeddyngi w bazie wektorowej stają się niekompatybilne z nowym modelem. Przeszukiwanie indeksu stworzonego przez stary model za pomocą embeddingów zapytania z nowego modelu daje błędne wyniki.
RAG zakłada, że pobrane dokumenty są wiarygodne i faktycznie trafne. Jeśli baza wiedzy zawiera nieprawdziwe, przestarzałe lub złośliwe dokumenty, retrieval może dostarczyć do LLM kontekst prowadzący do generacji błędnych odpowiedzi, nawet jeśli LLM ma prawidłową parametryczną wiedzę.
LLM może ignorować lub błędnie interpretować pobrany kontekst, bazując zamiast tego na swojej wiedzy parametrycznej. Zjawisko to jest szczególnie problematyczne gdy pobrane dokumenty zawierają informacje sprzeczne z wiedzą treningową modelu.
Ewolucja
Paper 'Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks' wprowadził termin RAG i formalną architekturę łączącą DPR (retriever) z BART (generator) w end-to-end trenowalny system. Zaproponowano dwa warianty: RAG-Sequence i RAG-Token. Osiągnięto state-of-the-art na trzech zadaniach open-domain QA bez użycia bezpośrednich sygnałów nadzorczych dla retrievera.
Izacard & Grave opublikowali Fusion-in-Decoder (FiD), w którym każdy pobrany dokument jest enkodowany osobno przez enkoder T5, a dekoder przeprowadza cross-attention nad wszystkimi enkodowanymi dokumentami jednocześnie. FiD poprawia wydajność retrieval przy dużym k bez kwadratowego wzrostu kosztu self-attention.
Po premierze ChatGPT (grudzień 2022) i rosnącym zainteresowaniu LLM, RAG stał się dominującą techniką wzbogacania LLM o zewnętrzną wiedzę bez re-treningu. Termin 'RAG' zaczął być powszechnie stosowany dla pipeline'ów retrieve-then-read z zamrożonymi LLM i bazami wektorowymi, odbiegając od oryginalnej definicji z paperu Lewis et al.
Opublikowano warianty RAG z adaptacyjnym decydowaniem o potrzebie retrieval: SELF-RAG (Asai et al., arXiv:2310.11511) uczy model generowania tokenów refleksji ('Should I retrieve?', 'Is this relevant?'), Adaptive RAG kondycjonuje retrieval na złożoności zapytania, Corrective RAG weryfikuje jakość pobranych dokumentów przed generacją.
Microsoft Research opublikował GraphRAG (Edge et al., arXiv:2404.16130), rozszerzając RAG o budowę grafów wiedzy z dokumentów i retrieval na poziomie encji i społeczności. GraphRAG poprawia odpowiedzi na złożone pytania globalnej wiedzy, które zwykły RAG obsługuje słabo.
Hiperparametry (konfigurowalne osie)
Liczba dokumentów lub fragmentów pobieranych przez retriever dla każdego zapytania. Wyższe k zwiększa recall retrieval, ale wydłuża prompt i zwiększa koszt LLM. W oryginalnym RAG k=5 było typową wartością.
Długość fragmentów dokumentów wchodzących do indeksu. Wpływa na granularność retrieval i długość kontekstu dołączonego do promptu. Za małe chunki tracą kontekst; za duże chunki spowalniają LLM i mogą zawierać dużo nieistotnego tekstu.
Model używany do konwersji zapytań i dokumentów do reprezentacji wektorowych. Jakość modelu embeddingowego ma bezpośredni wpływ na jakość retrieval. W oryginalnym RAG używano DPR; nowoczesne pipeline'y korzystają z modeli takich jak text-embedding-3 (OpenAI), all-MiniLM (SBERT), e5-large, lub BGE.
Metoda wyszukiwania dokumentów: gęsta (dense, embedding similarity), rzadka (sparse, BM25/TF-IDF) lub hybrydowa. Wpływa na jakość i latencję retrieval.
Wąskie gardło obliczeniowe
Podczas inferencji RAG wprowadza dwa dodatkowe koszty względem standardowego LLM: (1) czas wyszukiwania ANN w bazie wektorowej (typowo dziesiątki milisekund, ale zależny od rozmiaru indeksu i infrastruktury); (2) wydłużenie promptu przez dołączony kontekst pobranych dokumentów, co zwiększa koszt przetwarzania przez LLM proporcjonalnie do liczby i rozmiaru chunków (kwadratowa złożoność self-attention dla długich kontekstów). Przy k=10 chunków po 512 tokenów każdy kontekst może liczyć ~5000 dodatkowych tokenów.
Paradygmat wykonania
RAG jest paradygmatem conditional: retrieval jest wyzwalany przez zapytanie użytkownika i tylko podzbiór dokumentów z całego indeksu jest pobierany i używany do kondycjonowania generacji. Nie wszystkie dokumenty z korpusu są aktywowane przy każdym zapytaniu — jest to warunkowe, zależne od wejścia. W wariantach Adaptive RAG lub Self-RAG, krok retrieval może być opcjonalnie pomijany, co czyni aktywację jeszcze bardziej input-dependent.
Równoległość
Wiele niezależnych zapytań może być przetwarzanych równolegle. Etap indeksowania (offline chunking i embedding computation) jest w pełni zrównolegliwalny. Retrieval z FAISS i podobnych bibliotek ANN może korzystać z wielu wątków CPU lub GPU.
Wymagania sprzętowe
Zarówno model embeddingowy (do generowania embeddingów dokumentów i zapytań), jak i LLM generator używają architektur Transformer akcelerowanych przez GPU Tensor Cores. Dla modeli produkcyjnych o dużej skali (miliony dokumentów, modele LLM 7B+) GPU jest wymagany do utrzymania akceptowalnego opóźnienia inferencji.
Wyszukiwanie ANN w bibliotekach takich jak FAISS (Flat index, HNSW) może być efektywnie wykonywane na CPU z rozszerzeniami AVX/AVX-512 dla wektorowych operacji zmiennoprzecinkowych. Dla indeksów do kilkudziesięciu milionów dokumentów i umiarkowanego obciążenia CPU jest wystarczające dla etapu retrieval.