RAG — Retrieval-Augmented Generation

Zlaté pravidlo: Kvalita RAG systému se rodí v retrievalu, ne v generaci. Model odpoví jen tak dobře, jak dobrý kontext dostane — takže když ladíš odpovědi, nejdřív se podívej, co retrieval skutečně vrátil. Většinou zjistíš, že model nelže, jen dostal špatné podklady.

Kdy tohle potřebuješ

RAG dává smysl, když chceš, aby model odpovídal nad daty, která nezná: firemní wiki, dokumentace produktu, smlouvy, tickety podpory, interní směrnice. A zároveň jsou ta data příliš velká nebo příliš živá na to, aby se dala nacpat do promptu celá. Typický signál: „chatbot nad našimi dokumenty“, „vyhledávání, které odpovídá větou“, „podpora, která zná náš produkt“.

Existuje proto, že LLM mají fixní datum, ke kterému znají svět, tvoje interní data neviděly nikdy, a když nemají na čem stavět, fabulují — plynule a sebevědomě.

Jak to funguje

Dvě fáze. Indexace běží předem: dokumenty rozsekáš na chunky, z každého spočítáš embedding (číselnou reprezentaci významu) a uložíš do indexu — k tomu plnotextový index pro klíčová slova. Dotaz běží za provozu: k otázce najdeš nejpodobnější chunky (vektorově i plnotextem), reranker je přeskóruje podle skutečné relevance a top hrstka jde do promptu spolu s otázkou. Model odpovídá z dodaného kontextu a cituje, odkud čerpal.

Důležitá mentální korekce: RAG není „přidám vektorovou databázi“. Je to vyhledávač, kterému model píše rešerši. Všechno, co víš o kvalitě vyhledávání, tady platí dvojnásob.

Postup: jak to postavit, krok za krokem

1. Nejdřív eval, pak pipeline. Sepiš 30–50 reálných otázek a správných odpovědí (i s tím, ve kterém dokumentu leží). Bez téhle sady nikdy nepoznáš, jestli ti změna chunkingu pomohla, nebo ublížila. Tohle je nejcennější hodina celého projektu.

2. Začni hloupou baseline. Plnotextové vyhledávání (BM25) + vlož top výsledky do promptu. Žádné embeddingy, žádná infrastruktura. Překvapivě často je to 80 % výsledné kvality a máš proti čemu měřit.

3. Chunkuj podle struktury, ne podle počtu znaků. Nadpisy, sekce, odstavce — chunk má být ucelená myšlenka (zhruba 500–1500 tokenů) a má nést metadata: odkud je, z jakého dokumentu, jak starý. Useknutá půlvěta bez kontextu nikomu neodpoví.

4. Přidej embeddingy jako doplněk, ne náhradu. Hybrid (vektory + BM25) porazí obojí samostatně: embeddingy chytají parafráze a synonyma, plnotext chytá přesné termíny, názvy a čísla, na kterých embeddingy selhávají.

5. Přidej reranker. Levné vyhledání vrátí top-50 kandidátů, cross-encoder je přeskóruje a do promptu jde top-5. Tenhle krok mívá nejlepší poměr práce/zlepšení z celé pipeline.

6. Nauč systém říkat „nevím“. Když retrieval nevrátí nic relevantního, model to má říct, a ne si odpověď domyslet. Instruuj ho, ať odpovídá jen z dodaného kontextu a cituje zdroje — citace jsou zároveň tvůj debug nástroj.

7. Měř každý krok zvlášť. Retrieval: je správný dokument v top-k? (recall@k). Generace: odpovídá model správně, když správný kontext dostal? Když se tyhle dvě metriky neměří odděleně, nevíš, kterou půlku systému opravovat.

Časté chyby a jak je opravit

• Ladění promptu, když je rozbitý retrieval → vypiš si, co retrieval vrací pro 10 neúspěšných otázek. Oprava skoro vždycky leží tam.
• Chunking po větách nebo po pevném počtu znaků → respektuj strukturu dokumentu; věta bez okolí ztrácí předmět i smysl.
• Jen embeddingy → hybrid s plnotextem; vektorová podobnost nepozná „verze 2“ od „verze 3“ a ztrácí jména i kódy produktů.
• Žádný reranker → top-k podle podobnosti není top-k podle relevance; cross-encoder to srovná.
• Žádné evaly → bez testovací sady je každá změna jen pocit. A pocit nad miliony chunků fakt nestačí.
• RAG na korpus, který se vejde do kontextu → když máš 50 stránek dokumentace, prostě je vlož do promptu celé. RAG si nech, až budeš mít 5 000.

Kdy to nepoužívat

Na dotazy, které jsou ve skutečnosti databázové („kolik objednávek jsme měli v květnu“) — to je SQL, ne RAG. Na kreativní úlohy bez správné odpovědi. A na malé, stabilní korpusy — dlouhý kontext s cache je jednodušší a často i levnější.

Knihy a zdroje

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020) — původní paper, ze kterého jméno pochází. Dnes se RAG dělá jinak, ale hodí se vědět, odkud pojem přišel.
• Introducing Contextual Retrieval (Anthropic) — praktická technika, jak chunkům přidat kontext dokumentu před zaindexováním, s čísly o tom, o kolik to zlepší retrieval. Přesně ten typ inženýrství, na kterém RAG stojí.
• AI Engineering (Chip Huyen, O'Reilly 2025) — kapitoly o RAG a evaluaci jsou nejlepší ucelený text na tohle téma; vysvětluje i kdy RAG nahradit dlouhým kontextem nebo fine-tuningem.
• OpenAI: Retrieval guide — stručný a střízlivý přehled retrieval patternů z dokumentace; dobrý druhý názor nezávislý na konkrétním vendorovi databáze.

Co si pamatovat

RAG je tooling kolem promptu: neřeší úlohy, které model neumí, řeší úlohy, ke kterým model nemá data. Stavěj ho jako vyhledávač — eval sada první, hloupá baseline druhá, hybrid + rerank třetí. A když odpovědi nesedí, čti, co vrátil retrieval, ne co napsal model.