RAG (Retrieval-Augmented Generation) to jedna z najważniejszych technik stosowanych w praktycznym wdrażaniu dużych modeli językowych (LLM). Rozwiązuje fundamentalny problem: LLM nie wiedzą wszystkiego, a to, co wiedzą, może być nieaktualne. RAG łączy potęgę generowania tekstu z precyzją wyszukiwania w dedykowanej bazie wiedzy.
Problem, który RAG rozwiązuje
LLM — takie jak ChatGPT, Claude czy Gemini — mają trzy fundamentalne ograniczenia:
- Data odcięcia — wiedza modelu kończy się w momencie zakończenia treningu. Model wytrenowany do stycznia 2025 nie wie o wydarzeniach z marca 2025
- Halucynacje — model „nie wie, czego nie wie" i generuje fałszywe informacje brzmiące wiarygodnie
- Brak wiedzy prywatnej — model nie ma dostępu do wewnętrznych dokumentów firmy, baz danych, regulaminów
RAG rozwiązuje wszystkie trzy problemy: model nie musi „pamiętać" informacji — może je wyszukać w zewnętrznej bazie wiedzy i wygenerować odpowiedź na ich podstawie.
Architektura RAG — jak to działa?
System RAG składa się z dwóch faz:
Faza 1: Retrieval (wyszukiwanie)
- Pytanie użytkownika jest zamieniane na embedding (wektor liczbowy) przez model embeddingowy
- Baza wiedzy — wcześniej przetworzone dokumenty, również zamienione na embeddingi i zapisane w bazie wektorowej
- Wyszukiwanie — system szuka dokumentów (lub fragmentów dokumentów) z embeddingami najbardziej podobnymi do embeddingu pytania (cosine similarity)
- Wynik — top-K najbardziej relevantnych fragmentów (typowo 3–10)
Faza 2: Augmented Generation (wzbogacone generowanie)
- Odnalezione fragmenty dokumentów są dołączane do promptu jako kontekst
- LLM generuje odpowiedź na podstawie dostarczonych fragmentów, nie wyłącznie z własnej pamięci
- Idealnie model cytuje źródła i odmawia odpowiedzi, gdy kontekst nie zawiera relevantnych informacji
Prompt RAG — typowa struktura
Kontekst:
[Fragment dokumentu 1]
[Fragment dokumentu 2]
[Fragment dokumentu 3]
Pytanie użytkownika: [pytanie]
Odpowiedz na pytanie WYŁĄCZNIE na podstawie podanego kontekstu.
Jeśli kontekst nie zawiera odpowiedzi, powiedz „Nie znalazłem tej informacji".
Kluczowe komponenty systemu RAG
1. Chunking — dzielenie dokumentów
Dokumenty źródłowe są zbyt długie, żeby podawać je w całości. Dzielimy je na fragmenty (chunki):
- Fixed-size chunks — fragmenty o stałej długości (np. 500 tokenów). Proste, ale mogą przeciąć zdania
- Recursive character splitting — dzielenie na akapity, potem zdania, zachowując granice semantyczne
- Semantic chunking — podział na fragmenty na podstawie zmian tematycznych (wymaga modelu embeddingowego)
- Overlap — nakładanie się fragmentów (np. 50 tokenów) zapobiegające utracie kontekstu na granicach
Rozmiar chunka to kluczowy hiperparametr: za duży = mało precyzyjne wyszukiwanie; za mały = utrata kontekstu.
2. Embeddingi — wektorowa reprezentacja tekstu
Model embeddingowy zamienia tekst na wektory liczbowe w przestrzeni wielowymiarowej (typowo 768–3072 wymiarów). Podobne semantycznie fragmenty mają bliskie wektory.
Popularne modele embeddingowe:
- OpenAI text-embedding-3-large — 3072 wymiary, wielojęzyczny
- Cohere Embed v3 — zoptymalizowany pod RAG
- BGE-M3 — open-source, wielojęzyczny
- E5-mistral-7b — duży, precyzyjny model embeddingowy
3. Baza wektorowa (Vector Database)
Specjalizowana baza danych przechowująca embeddingi i umożliwiająca szybkie wyszukiwanie najbliższych sąsiadów (ANN — Approximate Nearest Neighbors):
- Pinecone — w pełni zarządzana, SaaS
- Weaviate — open-source, hybrydowe wyszukiwanie
- ChromaDB — lekka, idealna do prototypów
- Qdrant — wydajna, open-source, napisana w Rust
- pgvector — rozszerzenie PostgreSQL — RAG bez dodatkowej bazy danych
4. Reranking — poprawianie jakości wyników
Wyszukiwanie embeddingowe (semantic search) to przybliżenie. Reranker — osobny model — ocenia dopasowanie każdego fragmentu do pytania i przesortowuje wyniki. Modele: Cohere Rerank, BGE-reranker, cross-encoder.
Pipeline: embedding search (top-20) → reranker (top-5) → LLM.
Zaawansowane wzorce RAG
RAG Fusion
Zamiast jednego zapytania generuje wiele wariantów pytania (query expansion) i wyszukuje dokumenty dla każdego. Wyniki są łączone (reciprocal rank fusion). Poprawia recall — zmniejsza ryzyko pominięcia relevantnego dokumentu.
Hypothetical Document Embedding (HyDE)
LLM generuje hipotetyczną odpowiedź na pytanie. Embedding tej odpowiedzi jest używany do wyszukiwania — zamiast embeddingu pytania. Intuicja: odpowiedź jest semantycznie bliższa dokumentowi źródłowemu niż pytanie.
Self-RAG
Model sam decyduje, czy potrzebuje zewnętrznej wiedzy. Jeśli pytanie dotyczy wiedzy ogólnej (np. „co to jest DNA?"), model odpowiada z pamięci. Jeśli specjalistycznej — uruchamia retrieval. Zmniejsza latencję i koszty.
Agentic RAG
Agent AI dynamicznie decyduje o strategii wyszukiwania: które źródła odpytać, ile dokumentów pobrać, czy potrzebne jest doprecyzowanie pytania. Korzysta z wielu baz wiedzy, API i narzędzi.
RAG vs. Fine-tuning — kiedy co?
| Kryterium | RAG | Fine-tuning |
|---|---|---|
| Aktualizacja wiedzy | Natychmiastowa (dodaj dokument) | Wymaga ponownego treningu |
| Koszt | Niski (embedding + baza wektorowa) | Wysoki (GPU, dane treningowe) |
| Halucynacje | Zmniejsza (grounding w źródłach) | Nie eliminuje |
| Styl odpowiedzi | Zależy od promptu | Zmienia wewnętrzne zachowanie modelu |
| Wiedza specjalistyczna | Dobra (jeśli jest w dokumentach) | Lepsza dla specjalistycznej terminologii |
| Skalowalność wiedzy | Miliony dokumentów | Ograniczona pojemnością modelu |
Reguła kciuka: RAG do wiedzy (co model powinien wiedzieć), fine-tuning do zachowania (jak model powinien odpowiadać).
Wyzwania i ograniczenia RAG
1. Jakość dokumentów = jakość odpowiedzi
„Garbage in, garbage out". Jeśli baza wiedzy zawiera nieaktualne, sprzeczne lub niekompletne informacje, RAG je powieli.
2. Okno kontekstu
Nawet z RAG kontekst jest ograniczony. Jeśli odpowiedź wymaga informacji rozproszonych po 50 dokumentach, a okno kontekstu mieści 10 fragmentów — model nie zobaczy pełnego obrazu.
3. Lost in the middle
Badania pokazują, że LLM lepiej wykorzystują informacje z początku i końca kontekstu, „gubiąc" informacje ze środka. Kolejność fragmentów w prompcie RAG ma znaczenie.
4. Wielojęzyczność
Wyszukiwanie cross-lingwalne (pytanie po polsku, dokumenty po angielsku) wymaga wielojęzycznych modeli embeddingowych. Jakość spada dla języków niedoreprezentowanych w danych treningowych.
Podsumowanie
RAG to most między potęgą generatywną LLM a precyzją informacji specyficznych dla Twojej organizacji. Zamiast próbować „wpychać" wiedzę do modelu przez fine-tuning, RAG pozwala LLM korzystać z zewnętrznych źródeł w czasie rzeczywistym — jak człowiek korzysta z encyklopedii czy Google.
W praktyce wdrożeniowej RAG to nie „podłącz bazę i gotowe" — to system wymagający starannego doboru chunkingu, modeli embeddingowych, bazy wektorowej i promptów. Ale dobrze zaprojektowany RAG dramatycznie zmniejsza halucynacje, umożliwia aktualizację wiedzy bez ponownego treningu i otwiera drzwi do budowania specjalistycznych asystentów AI na własnych danych.