Retrieval-Augmented Generation (RAG) se stal de facto standardem pro enterprise AI aplikace, které potřebují pracovat s interními daty. Ale mezi „funguje v demu” a „funguje v produkci” je propast. Jak ji překonat?
Proč RAG a proč právě teď¶
Fine-tuning LLM modelů na firemní data je drahý, pomalý a obtížně udržovatelný. RAG nabízí elegantní alternativu: ponechte model obecný a dodávejte mu relevantní kontext za běhu. V roce 2026 máme k dispozici vyspělé embedding modely, stabilní vektorové databáze a dostatek produkčních zkušeností, abychom věděli, co funguje.
Typické enterprise use cases zahrnují interní knowledge base (dokumentace, wiki, procesy), zákaznický support nad produktovou dokumentací, compliance — vyhledávání v regulacích a interních předpisech, a analýzu smluv a právních dokumentů.
Architektura RAG pipeline v roce 2026¶
Moderní RAG pipeline má čtyři klíčové fáze:
- Ingestion: Zpracování zdrojových dokumentů — parsování, čištění, chunking
- Indexing: Generování embeddingů a uložení do vektorové databáze
- Retrieval: Vyhledání relevantních chunků na základě dotazu
- Generation: Sestavení promptu s kontextem a generování odpovědi
Každá fáze má své nástrahy. Pojďme se na ně podívat detailně.
Chunking — základ úspěchu¶
Chunking je nejpodceňovanější část RAG pipeline. Špatný chunking = špatné výsledky, bez ohledu na kvalitu modelu. V praxi se osvědčily tyto strategie:
- Sémantický chunking: Místo pevné délky dělíme text podle sémantických hranic — nadpisy, odstavce, tematické celky. Vyžaduje preprocessing, ale dramaticky zlepšuje kvalitu retrievalu.
- Overlap s kontextem: Překryv 10–20 % mezi chunky zajistí, že informace na hranicích se neztratí. Přidáváme také metadata — název dokumentu, sekce, datum.
- Hierarchický chunking: Dva levely — parent chunks (větší kontext) a child chunks (detail). Retrieval hledá na child úrovni, ale do promptu vkládáme parent chunk.
Optimální velikost chunku závisí na use case. Pro faktické Q&A typicky 256–512 tokenů, pro analytické úlohy 512–1024 tokenů. Vždy měřte na reálných datech.
Embedding modely — výběr a trade-offs¶
V roce 2026 máme na výběr z několika kategorií embedding modelů:
- OpenAI text-embedding-3-large: Solidní výkon, jednoduchá integrace, ale data opouštějí perimetr
- Cohere embed-v4: Silný multilingual výkon, vhodný pro česká data
- Open-source (nomic-embed, BGE, E5): Můžete hostovat on-premise, plná kontrola nad daty
- Domain-specific modely: Fine-tuned embeddingy pro konkrétní doménu (legal, medical) — nejlepší výkon, ale vyžadují investici do trénování
Pro české enterprise zákazníky typicky doporučujeme hybridní přístup: open-source model hostovaný on-premise pro citlivá data, komerční API pro méně citlivé use cases.
Retrieval — více než jen cosine similarity¶
Naivní RAG spoléhá na vektorovou podobnost. V praxi to nestačí. Moderní retrieval pipeline kombinuje:
- Hybrid search: Vektorové vyhledávání + BM25 (keyword search). Fusion algoritmem (RRF — Reciprocal Rank Fusion) kombinujeme výsledky obou přístupů.
- Query transformation: Před vyhledáváním transformujeme dotaz — rozšíření o synonyma, dekompozice složitých otázek na sub-queries, HyDE (Hypothetical Document Embeddings).
- Reranking: Cross-encoder model přeřadí top-K výsledků z prvního kola. Pomalejší, ale výrazně přesnější. Cohere Rerank nebo open-source alternatives (BGE-reranker).
- Metadata filtering: Filtrování podle data, oddělení, typu dokumentu — snižuje šum a zrychluje retrieval.
Vektorové databáze — volba technologie¶
Trh vektorových databází se v roce 2026 konsolidoval. Hlavní volby:
- pgvector (PostgreSQL): Pokud už máte Postgres, skvělý start. HNSW indexy zvládnou miliony vektorů. Výhoda: jedna databáze pro vše.
- Qdrant: Rust-based, vysoký výkon, dobré filtrování. Oblíbený v EU díky možnosti on-premise deploymentu.
- Weaviate: Vestavěná vektorizace, GraphQL API, multi-tenancy. Vhodný pro SaaS platformy.
- Managed služby (Pinecone, Azure AI Search): Nejjednodušší provoz, ale data v cloudu poskytovatele.
Pro většinu enterprise projektů doporučujeme pgvector jako startovní bod — minimalizuje operační komplexitu a většina týmů Postgres už zná.
Evaluace — jak měřit kvalitu RAG¶
Bez systematické evaluace nevíte, zda RAG pipeline skutečně funguje. Měříme na třech úrovních:
- Retrieval quality: Precision@K, Recall@K, MRR (Mean Reciprocal Rank) — vrací retriever relevantní dokumenty?
- Generation quality: Faithfulness (odpovídá generace kontextu?), relevance (odpovídá na otázku?), completeness
- End-to-end: Uživatelská spokojenost, správnost odpovědi ověřená doménovým expertem
Frameworky jako RAGAS automatizují evaluaci pomocí LLM-as-judge přístupu. Ale pozor — automatická evaluace je orientační. Pro produkční systémy je nezbytná pravidelná human evaluation na vzorku dat.
Časté chyby a jak se jim vyhnout¶
- Ignorování preprocessing: Garbage in, garbage out. Investujte do čištění dat — odstranění duplicit, parsování tabulek, extrakce z PDF.
- Příliš velký kontext: Více chunků ≠ lepší odpovědi. „Lost in the middle” efekt způsobuje, že model ignoruje relevantní informace uprostřed dlouhého kontextu.
- Chybějící observability: Logujte každý krok pipeline — jaké chunky byly vráceny, jaký byl confidence score, jak vypadal finální prompt.
- Statický pipeline: Data se mění, pipeline musí reflektovat aktualizace. Implementujte inkrementální indexing a verzování.
RAG je inženýrská disciplína, ne magie¶
Kvalitní RAG pipeline vyžaduje stejnou inženýrskou disciplínu jako jakýkoli jiný produkční systém. Chunking, embedding, retrieval, evaluace — každý krok vyžaduje měření, iteraci a optimalizaci na reálných datech.
Náš tip: Začněte jednoduchým pipeline, změřte baseline metriky, pak iterujte. Většina zlepšení přijde z lepšího chunkingu a rerankingu, ne z výměny LLM modelu.