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:

  1. 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
  2. Halucynacje — model „nie wie, czego nie wie" i generuje fałszywe informacje brzmiące wiarygodnie
  3. 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)

  1. Pytanie użytkownika jest zamieniane na embedding (wektor liczbowy) przez model embeddingowy
  2. Baza wiedzy — wcześniej przetworzone dokumenty, również zamienione na embeddingi i zapisane w bazie wektorowej
  3. Wyszukiwanie — system szuka dokumentów (lub fragmentów dokumentów) z embeddingami najbardziej podobnymi do embeddingu pytania (cosine similarity)
  4. Wynik — top-K najbardziej relevantnych fragmentów (typowo 3–10)

Faza 2: Augmented Generation (wzbogacone generowanie)

  1. Odnalezione fragmenty dokumentów są dołączane do promptu jako kontekst
  2. LLM generuje odpowiedź na podstawie dostarczonych fragmentów, nie wyłącznie z własnej pamięci
  3. 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.