RAG — Retrieval-Augmented Generation

Złota reguła: Jakość RAG rodzi się w retrievalu, nie w generacji. Model odpowie tylko tak dobrze, jak dobry kontekst dostał. Gdy odpowiedzi padają, najpierw sprawdź, co zwrócił retrieval. Zwykle model nie kłamie. Dostał złe dowody.

Kiedy tego potrzebujesz

RAG ma sens, gdy model ma odpowiadać na danych, których nie zna: firmowe wiki, dokumentacja, umowy, tickety supportu, polityki. I te dane są zbyt duże albo zbyt żywe, by wkładać je w całości do każdego promptu. Typowe sygnały: „chatbot nad naszymi docs”, „wyszukiwarka odpowiadająca zdaniem”, „support znający produkt”.

Istnieje dlatego, że LLM mają cutoff, nigdy nie widziały twojego prywatnego korpusu i płynnie zmyślają, gdy nie mają się czego trzymać.

Długi kontekst (setki tysięcy do miliona tokenów) przesunął granicę. Nie skasował jej. Mały stabilny korpus często da się włożyć cały. Duży, brudny, multi-tenant korpus nadal wymaga selekcji.

Jak to działa

Dwie fazy. Indeksacja z góry: tnij dokumenty na chunki, licz embeddingi, trzymaj indeks wektorowy i full-text na słowa kluczowe. Czas zapytania: znajdź kandydatów (wektor + BM25), przelicz rerankerem, wrzuć mały top do promptu z pytaniem. Model odpowiada z kontekstu i cytuje źródła.

Korekta mentalna: RAG to nie „dodaj vector DB”. To wyszukiwarka, której pisarzem odpowiedzi jest model. Wszystko, co wiesz o jakości searcha, działa tu podwójnie.

Buduj krok po kroku

1. Evals przed pipeline. 30–50 realnych pytań ze złotymi odpowiedziami i lokalizacją źródła. Bez tego nie wiesz, czy zmiana chunkingu pomogła.

2. Zacznij głupio. BM25 + top wyniki w prompcie. Bez embeddingów, bez infra. Często 80 % jakości i baseline do bicia. Przy małym korpusie spróbuj też „włóż wszystko” z prompt cachingiem.

3. Chunkuj po strukturze, nie po liczbie znaków. Nagłówki, sekcje, akapity. Chunk = spójna myśl (~500–1500 tokenów) z metadanymi: dokument, sekcja, wiek. Pół zdania bez podmiotu nie pomaga.

4. Embeddingi jako uzupełnienie, nie zamiennik. Hybryda (wektory + BM25) bije obie strony osobno. Wektory łapią parafrazy; full-text łapie nazwy, kody i liczby.

5. Dodaj reranker. Tani retrieval daje top-50; cross-encoder przelicza; do promptu idzie top-5. Często najlepszy stosunek pracy do zysku w całej pipeline.

6. Naucz „nie wiem”. Gdy retrieval jest pusty lub słaby, model ma odmówić zamiast zmyślać. Odpowiadaj tylko z podanego kontekstu i cytuj źródła. Cytaty to też debugger.

7. Mierz każdą połowę osobno. Retrieval: czy właściwy dokument jest w top-k (recall@k)? Generacja: przy dobrym kontekście czy model odpowiada dobrze? Zmieszane metryki = naprawiasz złą połowę.

RAG vs długi kontekst

Długie okno może zastąpić RAG przy małych stabilnych korpusach, jednorazowej analizie dokumentu i syntezie „przez cały tekst”. RAG wygrywa przy dużych, często zmienianych, multi-tenant danych, gdzie nie chcesz płacić miliona tokenów za każde pytanie i potrzebujesz cytatów z konkretnego źródła.

Praktyczna reguła: zmierz obie baseline na tym samym eval set. Ani marketing „1M context”, ani „enterprise vector DB” nie zdecyduje za ciebie. Często wygrywa hybryda: RAG wybiera kandydatów, długi kontekst trzyma je razem przy multi-hop pytaniach.

Częste błędy

• Strojenie promptu przy zepsutym retrievalu → najpierw wypisz retrieval dla 10 faili.
• Chunking po zdaniach / stałej długości → szanuj strukturę dokumentu.
• Same embeddingi → hybryda z full-text; wektory rozmywają „v2” vs „v3” i kody produktów.
• Brak rerankera → ranking podobieństwa ≠ ranking relewancji.
• Brak evali → każda zmiana to vibe na milionach chunków.
• RAG na korpus, który mieści się w kontekście → włóż 50 stron; RAG zostaw na 5 000.
• Długi kontekst jako wymówka, by nie projektować retrievalu → większe okno drożej pakuje bałagan, nie czyści go.

Kiedy tego nie używać

Pytania bazodanowe („ile zamówień w maju”) chcą SQL, nie RAG. Zadania kreatywne bez ground truth nie potrzebują teatru retrievalu. Małe stabilne korpusy często wolą długi kontekst + cache.

Źródła

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)
• Introducing Contextual Retrieval (Anthropic)
• Effective context engineering for AI agents (Anthropic)
• AI Engineering (Chip Huyen)
• OpenAI: Retrieval guide

Co zapamiętać

RAG to tooling wokół promptu. Nie naprawia zadań, których model nie umie. Naprawia zadania, które model umie, ale nie ma do nich danych. Buduj jak search: eval set pierwszy, głupia baseline druga, hybryda + rerank trzecia. Długi kontekst to alternatywa i partner, nie magiczny zamiennik. Gdy odpowiedzi padają, czytaj retrieved chunki, nie pewność siebie modelu.