Mapowanie RAG: etapy procesu, kluczowe komponenty oraz różnorodność wariantów
Zrozum, jak funkcjonuje generacja wzbogacona o wyszukiwanie od początku do końca, jakie komponenty potrzebuje system RAG oraz jak liczne warianty RAG pasują do jednej struktury.
Źródła: The Complete Guide to RAG — Part 1: What It Is, Why It Exists & How It Works
Model językowy potrafi doskonale rozumować, ale nadal może nic nie wiedzieć o twojej wewnętrznej dokumentacji, zmianie zasad sprzed tygodnia czy zgłoszeniu złożonym godzinę temu. Generowanie wzbogacone pozyskiwaniem informacji (RAG) eliminuje tę lukę, umożliwiając modelowi wyszukiwanie danych w zewnętrznym źródle wiedzy przed udzieleniem odpowiedzi. Ten przewodnik omawia problemy, które rozwiązuje RAG, a także te, których nie rozwiązuje, trzy etapy funkcjonowania systemu RAG, komponenty potrzebne do jego stworzenia oraz sposób zrozumienia długiej listy różnych wariantów RAG.
RAG w jednym zdaniu
RAG łączy dwa procesy:
- Pozyskiwanie informacji: znajdowanie istotnych danych w zewnętrznym źródle wiedzy.
- Generowanie: tworzenie odpowiedzi przez model językowy na podstawie pozyskanych informacji.
Prościej mówiąc, RAG dostarcza modelowi bibliotekę referencyjną do przeglądania przed udzieleniem odpowiedzi. Badania wprowadzające ten podejście przedstawiają je jako połączenie pamięci parametrycznej modelu – wiedzy przechowywanej w jego wagach podczas treningu – z pamięcią niparametryczną, czyli zewnętrznym indeksem, który można wyszukiwać i aktualizować niezależnie.
Pomocnym porównaniem jest egzamin z otwartą książką:
- LLM to uczeń.
- Baza wiedzy to podręcznik.
- System wyszukiwania to uczeń przewracający strony w odpowiednich miejscach.
- Ostateczna odpowiedź to odpowiedź ucznia, napisana przy otwartych tych stronach.
Model dostarcza rozumowanie i płynną mowę; system wyszukiwania dostarcza fakty istotne dla danego pytania.
Problemy, które ma rozwiązać RAG
Zależność wyłącznie od wbudowanej w model wiedzy napotyka na kilka praktycznych ograniczeń. Dla każdego z nich RAG oferuje częściowe rozwiązanie.
Wiedza ograniczona do czasu szkolenia
Model nie może znać niczego, co zostało dodane lub zmienione po zebraniu jego danych treningowych. Dzięki RAG aktualne informacje znajdują się w zewnętrznym magazynie, który można aktualizować w dowolnym momencie, bez ingerencji w sam model.
Odpowiedzi niepoparte lub wymyślone
Modele czasami generują stwierdzenia, które są błędne lub pozbawione podstaw. Pobrane dowody dają modelowi coś konkretnego, na czym może się oprzeć, co zmniejsza ilość niepopartych wyników. Nie eliminuje to jednak takich problemów: proces pobierania może zwrócić błędne fragmenty, same źródła mogą być nieprecyzyjne, a model nadal może formułować twierdzenia, których dowody nie potwierdzają.
Dane prywatne, których model nigdy nie widział
Model uniwersalny nie ma dostępu do wewnętrznych dokumentów twojej organizacji, kodu własnego ani poufnej wiedzy. RAG umożliwia aplikacji korzystanie z autoryzowanych, prywatnych źródeł w momencie wysyłania zapytania, bez konieczności ponownego szkolenia modelu na tych danych. Kontrola dostępu nadal ma znaczenie: system powinien zwracać tylko to, co aktualny użytkownik ma prawo przeczytać.
Informacje, które często się zmieniają
Polityki, dokumentacja produktowa i techniczna oraz wewnętrzne zapisy stale ulegają zmianom. Dodawanie lub aktualizowanie wpisów w indeksie wyszukiwania jest znacznie tańsze i szybsze niż ponowne szkolenie modelu językowego za każdym razem, gdy coś się zmienia.
Dokumenty zbyt duże, by wysłać je w całości
wklejanie całych dokumentów do każdego żądania marnuje zasoby i pieniądze. RAG wysyła tylko odpowiednie fragmenty bazy wiedzy, dzięki czemu zapytania są bardziej skoncentrowane i krótsze.
Szum z nieistotnego kontekstu
Zbyt duża ilość luźno powiązanego materiału utrudnia modelowi znalezienie istotnych dowodów. Filtrowanie, ponowne rankowanie oraz kompresja kontekstu służą temu, by poprawić jakość tego, co ostatecznie trafia do modelu.
RAG poprawia powiązanie z rzeczywistością i zmniejsza liczbę halucynacji, ale nie gwarantuje dokładnych ani wolnych od halucynacji odpowiedzi. Traktuj go jako narzędzie do oceny niezawodności, a nie dowód poprawności.
Trzy etapy systemu RAG
Etap 1: indeksowanie
Indeksowanie odbywa się przed tym, jak użytkownik zada pytanie. Materiały źródłowe takie jak pliki PDF, strony internetowe, dokumentacja czy wiersze bazy danych są:
- ładowane do systemu,
- dzielone na mniejsze fragmenty,
Wynikiem jest możliwość wyszukiwania informacji zawartych w twojej wiedzy. Koncepcyjnie tworzysz indeks wyszukiwawczy na podstawie własnych danych.
Etap 2: wydobycie informacji
Gdy pojawia się pytanie:
- zapytanie jest przekształcane w embedding za pomocą tego samego modelu, który był użyty podczas tworzenia indeksu,
- w bazie wiedzy wyszukiwane są najbliższe wektory,
- wybierane są najbardziej istotne fragmenty tekstu,
- opcjonalne filtrowanie lub ponowna sortowanie dopracowuje tę selekcję.
Przebieg procesu od pytania do potencjalnych fragmentów wygląda następująco:
User Query
│
▼
[Embedding Model]
│
▼
[Query Vector]
│
▼
[Vector Database]
│
▼
[Relevant Chunks]
Kluczową cechą jest to, że zapytania i dokumenty znajdują się w tym samym przestrzeni wektorowej. Dlatego model embeddingu używany podczas wysyłania zapytania musi być taki sam jak ten użyty do budowy indeksu; łączenie różnych modeli generuje wektory, których nie można sensownie porównać.
Etap 3: generowanie
Wybrane fragmenty tekstowe są łączone z pytaniem użytkownika w jeden prompt, a model generuje odpowiedź:
User Query
+
Retrieved Context
│
▼
[Prompt / Context]
│
▼
[LLM]
│
▼
Final Answer
Otrzymana odpowiedź opiera się zarówno na ogólnych zdolnościach modelu, jak i na konkretnych dowodach pochodzących z Twojego źródła wiedzy. Sposób, w jaki prompt przedstawia te dowody – na przykład poprzez etykiety źródeł, które model może cytować – ma duży wpływ na to, w jakim stopniu odpowiedź będzie im wierna.
Wewnątrz procesu indeksowania
To właśnie w procesie indeksowania decyduje się o większości jakości systemu RAG. Jego podstawowa struktura:
Raw Data
│
▼
Document Loader
│
▼
Text Chunking
│
▼
Embedding Model
│
▼
Vector Database
Dane surowe
Wiedza może pochodzić niemal skądkolwiek:
- PDF-y
- Strony internetowe
- Dokumentacja
- Dokumenty tekstowe
- Bazy danych
- API
- Wewnętrzne pliki firmy
Ładowarki dokumentów
Ładowarka dokumentów odczytuje źródło i przekształca je w jednolitą strukturę, którą może przetworzyć reszta procesu. W LangChain na przykład ładowarki mają wspólną interfejs, który tworzy obiekty Document, i mogą oferować zarówno metodę load(), jak i lazy_load(). Wersja „lazy” dostarcza dokumenty po jednym, zamiast przechowywać wszystko w pamięci, co jest ważne przy dużych zbiorach. LangChain i LlamaIndex to dwa ekosystemy, od których zazwyczaj zaczynają użytkownicy.
Dzielenie na fragmenty
Dokumenty duże są dzielone na mniejsze części zwane chunkami, ponieważ pobranie odpowiedniej sekcji dokumentu jest zazwyczaj bardziej przydatne niż przekazanie modelowi całego pliku. Dobrą analogią jest przekształcenie książki w stertę kart indeksowych, z których każda przedstawia jedną ideę.
Rozmiar i stopień nakładania się chunków nie mają uniwersalnie poprawnych wartości. Zależą one od sposobu strukturyzacji dokumentów, rodzaju pytań, jakie oczekujesz, modelu embeddingowego, którego używasz, oraz od ilości kontekstu, jaką możesz sobie pozwolić w dalszej obróbce. Chunki zbyt małe tracą otaczający je sens; chunki zbyt duże rozcieńczają informacje zawarte w kluczowym zdaniu. Aby dowiedzieć się więcej na temat tego kompromisu, zapoznaj się z metodą dzielenia na chunki zachowującą dowody.
Modele embeddingowe
Każdy fragment jest przekształcany w embedding, czyli listę liczb reprezentujących jego znaczenie:
"RAG retrieves relevant information"
↓
[0.24, 0.87, 0.11, 0.62, ...]
Embeddingi umożliwiają systemowi ocenę stopnia powiązania dwóch fragmentów treści, co stanowi podstawę wyszukiwania semantycznego i odzyskiwania informacji: teksty o podobnym znaczeniu znajdują się blisko siebie w przestrzeni wektorowej, nawet jeśli mają niewiele wspólnych słów.
W rodzinie modeli text-embedding-3 firmy OpenAI mały model domyślnie generuje wektory o wymiarze 1536, natomiast duży – 3072.
Oba modele przyjmują parametr dimensions, aby uzyskać wektory o mniejszym wymiarze, poświęcając nieco dokładności na rzecz mniejszej ilości pamięci i szybszego wyszukiwania. Lista dostępnych modeli może ulegać zmianom, dlatego należy sprawdzić aktualne opcje w dokumentacji dostawcy.
Bazy danych wektorowych
Embeddingi są przechowywane w bazie danych wektorowych lub indeksach wektorowych zaprojektowanych do szybkiego wyszukiwania podobieństw. Do popularnych rozwiązań należą:
- Qdrant
- Pinecone
- Chroma
- Weaviate
- FAISS
Zapisana rekord zazwyczaj zawiera coś więcej niż sam wektor. Przechowuje ona również oryginalny tekst fragmentu oraz metadane, takie jak źródło, numer strony, identyfikator dokumentu lub data i czas. To właśnie te metadane umożliwiają późniejsze filtrowanie według daty lub typu dokumentu oraz wskazywanie, skąd pochodzi odpowiedź.
Bloki budulcowe aplikacji RAG
Podsumowując, typowa aplikacja RAG składa się z sześciu rodzajów komponentów:
- Źródło wiedzy: dostarcza informacje, na przykład pliki PDF, strony internetowe, bazy danych SQL lub API.
- Dzielnik tekstu: dzieli dokumenty na łatwe do obsługi fragmenty, wykorzystując narzędzia dzielące tekst dostępne w LangChain lub własną logikę.
Mapa rodziny RAG
Gdy podstawowy proces staje się jasny, ekosystem różnych wariantów może wydawać się przytłaczający. Nie istnieje jedna kanoniczna lista typów RAG; artykuły naukowe i blogi inżynierskie używają nakładających się nazw dla architektur, strategii wyszukiwania, technik kontekstowych, źródeł wiedzy oraz specjalistycznych systemów. Grupowanie ich według tego, co zmieniają, ułatwia zrozumienie całej struktury.
Bazowe architektury
- Naive RAG: prosta sekwencja operacji embed, wyszukiwanie i generowanie.
- Advanced RAG: dodaje kroki przed i po pozyskiwaniu danych, takie jak przepisywanie zapytania i ponowna klasyfikacja.
- Modular RAG: traktuje każdy etap jako wymienny moduł, który można ponownie łączyć.
Strategie pozyskiwania danych
- Single-pass RAG: jedno pozyskanie danych na pytanie.
- Multi-Query RAG: generuje kilka wariantów zapytania i wyszukuje dane dla każdego z nich.
- Iterative RAG: pozyskuje dane, analizuje je i ponownie je wyszukuje.
- Multi-Hop RAG: łączy kilka operacji pozyskiwania danych, gdy odpowiedź wymaga połączenia kilku faktów.
- Hybrid RAG: łączy semantyczne wyszukiwanie wektorowe z wyszukiwaniem według słów kluczowych.
- RAG Fusion: łączy wyniki z kilku zapytań w jeden ranking.
- Self-Query RAG: pozwala modelowi przekształcić pytanie w zapytanie wyszukiwawcze wraz z filtrami metadanych.
Podejścia oparte na kontekście i dzieleniu na fragmenty
- Parent-Child RAG: dopasowuje się do małych fragmentów, ale zwraca ich większą sekcję nadrzędną.
- Sentence Window RAG: pobiera zdanie wraz z jego sąsiadami.
- Hierarchical RAG: przeszukuje po różnych poziomach, od dokumentów aż po fragmenty tekstu.
- Contextual RAG: wzbogaca fragmenty o kontekst na poziomie dokumentu przed ich umieszczeniem w embeddingach.
- RAPTOR: buduje drzewo rekurencyjnych streszczeń i przeszukuje je po poszczególnych poziomach.
Podejścia samokorygujące i adaptacyjne
- Self-RAG: model ocenia, czy konieczne jest pozyskiwanie informacji oraz czy jego wynik ma uzasadnienie.
- Corrective RAG (CRAG): analizuje uzyskane wyniki i uruchamia korekty, gdy są one niewystarczające.
- Adaptive RAG: kieruje każde pytanie do strategii odpowiedniej dla jego złożoności.
- Feedback-based RAG: wykorzystuje informacje zwrotne od użytkownika lub oceniającego, aby z czasem poprawiać proces pozyskiwania informacji.
Podejścia agentowe
- Agentic RAG
- Multi-Hop Agentic RAG
- Multi-Agent RAG
W tych podejściach agent decyduje, kiedy i gdzie pozyskać informacje, możliwe jest to za pomocą kilku narzędzi lub współpracujących agentów, zamiast stosować ustaloną sekwencję działań.
Odmiany określone przez źródło wiedzy
Kilka nazw po prostu opisuje źródło dowodów. Vector RAG przeszukuje indeks embeddingów, natomiast SQL RAG i Table RAG wyszukują dane relacyjne lub tablicowe, często poprzez zlecenie modelowi napisania zapytania. GraphRAG pobiera dane z grafu wiedzy zawierającego entity i relacje, Web lub Search RAG czerpie aktualne wyniki z silnika wyszukiwania, a Knowledge-Base RAG korzysta z starannie przygotowanego korpusu, takiego jak centrum pomocy lub wiki.
Różne warianty multimodalne
Inne oznaczenia odnoszą się do rodzaju treści, które są pobierane. Text RAG jest przypadkiem domyślnym; Image, Video i Audio RAG pobierają dane z tych mediów, zazwyczaj za pomocą embeddingów lub transkrypcji, a Multimodal RAG to termin ogólny dla systemów łączących kilka z tych metod.
Specjalistyczne warianty
Ostatnia grupa to systemy nazw dostosowane do konkretnych wymagań: pojedyncze dziedziny, takie jak prawo czy medycyna (specyficzne dla danej dziedziny), pytania wymagające uwzględnienia aktualności (temporalne), odpowiedzi dostosowane do indywidualnego użytkownika (spersonalizowane), zapytania i źródła w więcej niż jednym języku (wielojęzyczne), dane wrażliwe, które muszą pozostać chronione (zapewniające prywatność), oraz indeksy rozproszone między kilkoma stronami lub organizacjami (rozsiane lub zfederowane).
Te grupy mogą się swobodnie nakładać. Rzeczywisty system produkcyjny może być jednocześnie hybrydowy, oparty na agentach i specyficzny dla danej dziedziny; te etykiety opisują wybory projektowe, a nie produkty wzajemnie wykluczające się.
Najprostszy pipeline to linia prosta:
Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
LLM
↓
Answer
To właśnie ma na myśli ludzie, mówiąc o naïwnym lub podstawowym RAG: wgruje się pytanie, wybierze najbliższe k-ch fragmentów i przekaże je modelowi. Jest to rozsądna pierwsza wersja, która często wystarcza do małych, uporządkowanych korpusów.
Zaawansowane systemy dodają dodatkowe etapy przed procesem wyszukiwania:
User Query
↓
Query Rewriting
↓
Query Routing
↓
Hybrid Retrieval
↓
Metadata Filtering
↓
Reranking
↓
Context Compression
↓
LLM
↓
Answer
Każdy etap adresuje konkretną słabość. Przepisywanie zapytań naprawia niejasne lub potoczne pytania, routowanie kieruje pytanie do odpowiedniego indeksu lub narzędzia, hybrydowe wyszukiwanie wykrywa dokładne terminy, których nie dostrzeże czyste wyszukiwanie wektorowe, filtrowanie metadanych usuwa dokumenty poza zakresem tematycznym, ponowne sortowanie przestawia kandydatów za pomocą dokładniejszego modelu, a kompresja skraca to, co pozostało, aby dostosować się do ograniczeń. Dodawaj je tylko wtedy, gdy możesz zmierzyć problem, który rozwiązują; złożoność sama w sobie nie jest celem.
Dlaczego RAG to coś więcej niż baza danych wektorowych plus LLM
Powszechnym błędem początkujących jest przekonanie, że RAG oznacza „przechowywanie embeddingów, wyszukiwanie ich i wywoływanie modelu”. W rzeczywistości proces produkcyjny wygląda raczej w ten sposób:
Document Processing
↓
Chunking
↓
Metadata
↓
Embedding
↓
Vector / Keyword Retrieval
↓
Filtering
↓
Reranking
↓
Context Compression
↓
Prompt Construction
↓
LLM
↓
Validation
↓
Final Answer
Każdy etap tego procesu może pogorszyć ostateczną odpowiedź: błędne parsowanie, nieostrożne dzielenie na fragmenty, brak metadanych, nieodpowiedni model embeddingów, słabe filtrowanie lub źle sformułowany prompt. Dlatego połączenie magazynu wektorowego z modelem to dopiero początek. Bez względu na możliwości modelu, nie może on w pełni nadrobić braku prawidłowych informacji.
Jak ocenić system RAG
Stworzenie odpowiedzi nie jest kluczowym kryterium. Dobry system RAG pozyskuje rzeczywiście przydatne informacje i generuje odpowiedź, którą faktycznie potwierdzają te informacje. Warto mierzyć następujące aspekty:
- Jakość pozyskiwania danych: czy rzeczywiście wracają istotne dokumenty lub fragmenty?
Pomiar każdego etapu osobno umożliwia diagnozowanie awarii; podejście oceny RAG według etapu awarii pokazuje, jak to zorganizować.
Dalej co robić
Kolejnym poziomem złożoności jest sama ścieżka indeksowania: to, jak PDF przekształca się w tekst, różnica pomiędzy ładowaniem, analizowaniem i oczyszczaniem danych, kompromisy pomiędzy dzieleniem na fragmenty według znaków, tokenów, metod rekurencyjnych, kryteriów semantycznych i strukturalnych, to, co faktycznie oznacza nakładanie się fragmentów, jak powinny być zaprojektowane metadane, jak tekst staje się wektorem, w czym różnią się podobieństwo kosinowe, iloczyn skalarny i odległość euklidesowa oraz to, jak baza danych wektorowych przeprowadza wyszukiwanie podobieństw na dużą skalę.
Główne wnioski
- RAG łączy wyuczoną wiedzę modelu z zewnętrznym magazynem dostępnym do wyszukiwania, dzięki czemu odpowiedzi mogą odzwierciedlać prywatne i aktualne informacje bez konieczności ponownego szkolenia modelu.
- Zmniejsza liczbę niepoprawnych odpowiedzi, ale nigdy nie gwarantuje ich dokładności; proces wydobywania informacji, identyfikacja źródeł oraz generowanie treści mogą nadal zawieść.