Velké jazykové modely umí generovat text, ale mají zásadní problém — halucinují. Vymýšlí si fakta, citují neexistující zdroje a s jistotou tvrdí nesmysly. RAG (Retrieval Augmented Generation) tento problém řeší elegantně: místo spoléhání na paměť modelu mu v reálném čase dodáváme relevantní data z vlastních zdrojů. Tady jsou naše zkušenosti z enterprise implementací.
Proč samotný LLM nestačí¶
GPT-4, Claude, Gemini — všechny tyto modely mají knowledge cutoff. Nevědí nic o vašich interních dokumentech, aktuálních cenících ani firemních procesech. Fine-tuning je drahý, pomalý a při každé změně dat ho musíte opakovat. RAG nabízí alternativu: model zůstává obecný, ale při každém dotazu dostane kontext z vaší knowledge base.
V praxi to znamená, že zákaznický chatbot neodpovídá „myslím, že…” ale „podle dokumentu XY z ledna 2024 platí…”. A to je zásadní rozdíl pro enterprise nasazení, kde si halucinace nemůžete dovolit.
Architektura RAG pipeline¶
Základní RAG pipeline má tři fáze: indexace, retrieval a generování.
Indexace: Dokumenty (PDF, Word, Confluence, databáze) se rozčlení na chunky (typicky 500–1000 tokenů), převedou se na embedding vektory pomocí modelu (OpenAI ada-002, Cohere embed, nebo open-source alternativy jako nomic-embed) a uloží do vektorové databáze.
Retrieval: Uživatelský dotaz se převede na embedding stejným modelem. Vektorová databáze najde nejpodobnější chunky (typicky top-k = 5–10). Volitelně se přidá re-ranking model pro přesnější řazení.
Generování: Nalezené chunky se vloží do promptu jako kontext. LLM na základě tohoto kontextu vygeneruje odpověď s referencemi na zdrojové dokumenty.
Volba vektorové databáze¶
Na trhu je v roce 2024 překvapivě mnoho možností. Specializované vector DB jako Pinecone (managed, jednoduchý start), Weaviate (open-source, hybridní search), Qdrant (Rust, výkon) nebo Milvus (enterprise scale). Ale i tradiční databáze přidávají vektorový support — pgvector pro PostgreSQL, Azure AI Search, Elasticsearch kNN.
Naše doporučení: pokud už máte PostgreSQL, začněte s pgvector. Pro větší objemy (miliony dokumentů) a pokročilé filtry sáhněte po dedikovaném řešení. Managed služby (Pinecone, Azure AI Search) jsou ideální, pokud nechcete řešit infrastrukturu.
Chunking — umění rozdělit dokument¶
Kvalita RAG stojí a padá s chunkingem. Příliš malé chunky ztrácí kontext. Příliš velké chunky „zředí” relevantní informaci šumem. V praxi funguje kombinace: semantic chunking (dělení podle sémantických hranic — nadpisy, odstavce) plus overlap (překryv 10–20 % mezi chunky pro zachování kontextu).
Pro strukturované dokumenty (smlouvy, legislativa) používáme hierarchický chunking — metadata o sekci, kapitole a dokumentu se přidají ke každému chunku. Při retrievalu pak můžeme filtrovat: „hledej jen ve smlouvách z roku 2024” nebo „jen v sekci Pricing”.
Pokročilé techniky: beyond naive RAG¶
Základní RAG je dobrý start, ale enterprise nasazení vyžaduje víc:
- Hybrid search: Kombinace vektorového (sémantického) a keyword (BM25) vyhledávání. Sémantika najde synonyma, keyword najde přesné termíny.
- Query transformation: Uživatel se ptá vágně. HyDE (Hypothetical Document Embeddings) nejdřív vygeneruje hypotetickou odpověď a tu použije pro retrieval.
- Multi-step retrieval: Komplexní otázky se rozloží na podotázky, každá se vyhodnotí samostatně, výsledky se agregují.
- Re-ranking: Cross-encoder model (Cohere Rerank, BGE Reranker) přeřadí výsledky podle skutečné relevance k dotazu.
- Agentic RAG: LLM se rozhodne, zda vůbec potřebuje retrieval, jaký zdroj použít a zda má odpověď dostatečnou kvalitu.
Evaluace — jak měřit kvalitu¶
RAG bez evaluace je jako kód bez testů — funguje, dokud nefunguje. Měříme tři dimenze: retrieval quality (našli jsme správné dokumenty?), generation quality (je odpověď správná a grounded?) a end-to-end (je uživatel spokojený?).
Nástroje jako RAGAS, DeepEval nebo vlastní eval sety s golden questions umožňují automatizované testování. Klíčové metriky: faithfulness (odpověď odpovídá kontextu), answer relevancy (odpověď odpovídá otázce) a context precision (nalezené dokumenty jsou relevantní).
Bezpečnost a governance¶
V enterprise prostředí je kritické řešit přístupová práva. Pokud má dokument klasifikaci „confidential”, RAG nesmí jeho obsah vrátit uživateli bez odpovídající autorizace. Implementujeme metadata-based filtering na úrovni vektorové databáze — každý chunk nese ACL metadata a při retrievalu se filtruje podle identity uživatele.
RAG jako základ enterprise AI¶
RAG není silver bullet, ale je to nejpraktičtější způsob, jak dostat LLM do produkce s firemními daty. Začněte jednoduše — pgvector, basic chunking, jeden zdroj dat. Iterujte na základě evaluace. A pamatujte: 80 % úspěchu RAG je v kvalitě dat a chunkingu, ne ve volbě modelu.