RAG — Retrieval-Augmented Generation

Co to jest

RAG to wzorzec "znajdź właściwy kontekst → wstaw go do promptu → niech
model odpowiada na podstawie tego". Ani nowa generacja AI, ani magia.
Workflow.

Istnieje dlatego, że LLM:

• mają sztywną datę cutoff,
• nie odpowiadają wiarygodnie na firmowe dane, których nigdy nie widziały,
• halucynują, kiedy nie mają się czego trzymać.

Jak to działa

1. Indeksacja. Dokumenty tnę na chunki (typowo 500–1500 tokenów),
   z każdego liczę embedding i wrzucam do vector store (pgvector, Qdrant,
   LanceDB).
2. Retrieval. Z zapytania liczę embedding, biorę top-K najbliższych
   chunków. Często hybrydowo z BM25 fulltext, bo sam embedding przegrywa
   na słowach kluczowych i liczbach.
3. Reranker (opcjonalny). Cross-encoder przelicza wyniki według
   prawdziwej relewancji. Bez niego top-10 to często "podobnie brzmiące"
   chunki, a nie odpowiedzi.
4. Generacja. Top-N chunków (typowo 4–8) trafia do promptu jako
   kontekst razem z oryginalnym pytaniem.

Kiedy to ma sens (a kiedy nie)

Tak: firmowa knowledge base, dokumentacja, archiwum prawne lub
medyczne, dane, które się zmieniają.

Nie: zadania kreatywne bez ground truth, zapytania rozwiązywalne
jednym SQL JOIN-em, sytuacje, w których wystarczy długi kontekst (modele
z 1M tokenów przesunęły granicę).

Częste błędy

• Chunkowanie po zdaniach. Tracisz kontekst "o czym właściwie to zdanie".
• Sam embedding, bez BM25. Embedding nie rozróżni "GPT-5" od "GPT-4".
• Brak rerankera. Top-K embedding similarity ≠ top-K relewancja.
• Brak evals. Jeśli nie wiesz, czy RAG odpowiada lepiej niż goły model,
  możesz go równie dobrze wyłączyć.

Co zapamiętać

RAG to tooling wokół promptu. Nie rozwiązuje zadań, których model nie
umie. Rozwiązuje zadania, które model umie, ale nie ma do nich danych.