RAG & Knowledge Base

Co je RAG a proč ho potřebujete¶

Retrieval-Augmented Generation (RAG) je architektonický vzor, který kombinuje vyhledávání v datech s generativní AI. Místo toho, aby se LLM spoléhal pouze na svůj training, při každém dotazu nejdříve vyhledá relevantní informace z vašich zdrojů a pak na jejich základě formuluje odpověď — s citacemi.

Proč ne jen LLM?¶

Samotný LLM (GPT-4, Claude, Llama) má tři fundamentální problémy pro enterprise nasazení:

1. Knowledge cutoff — nezná vaše interní dokumenty, procesy, aktuální data
2. Halucinace — když nezná odpověď, vymyslí ji s přesvědčivou jistotou
3. Neprokazatelnost — nemůžete ověřit, odkud informace pochází

RAG řeší všechny tři: model odpovídá pouze z dodaného kontextu, cituje zdroje a pracuje s aktuálními daty.

Architektura produkčního RAG systému¶

┌──────────────────────────────────────────────────────────────┐
│  INGESTION PIPELINE                                           │
│                                                               │
│  Zdroje (DMS, Wiki, Email, DB)                               │
│       │                                                       │
│       ▼                                                       │
│  Document Processing (OCR, parsing, cleaning)                │
│       │                                                       │
│       ▼                                                       │
│  Semantic Chunking (adaptive, ne fixed-size)                 │
│       │                                                       │
│       ▼                                                       │
│  Embedding + Indexing (vector DB + BM25)                     │
│       │                                                       │
│       ▼                                                       │
│  Metadata Enrichment (autor, datum, verze, kategorie)        │
└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐
│  QUERY PIPELINE                                               │
│                                                               │
│  Uživatelský dotaz                                           │
│       │                                                       │
│       ▼                                                       │
│  Query Expansion (HyDE, multi-query)                         │
│       │                                                       │
│       ▼                                                       │
│  Hybrid Retrieval (dense + sparse, α-blending)               │
│       │                                                       │
│       ▼                                                       │
│  Re-ranking (cross-encoder, domain-tuned)                    │
│       │                                                       │
│       ▼                                                       │
│  Context Assembly (dedup, ordering, token budget)            │
│       │                                                       │
│       ▼                                                       │
│  LLM Generation (s citacemi, s guardrails)                   │
│       │                                                       │
│       ▼                                                       │
│  Output Validation (faithfulness check, PII redaction)       │
└──────────────────────────────────────────────────────────────┘

Chunking — základ, na kterém vše stojí¶

Naivní chunking (rozřezat dokument po 512 tokenech) je nejčastější chyba RAG systémů. Kontext se rozbije uprostřed věty, tabulka se rozdělí, reference ztratí smysl.

Náš přístup: - Semantic chunking — rozdělujeme na základě sémantických hranic (sekce, odstavce, témata) - Hierarchické chunky — parent chunk (celá sekce) + child chunks (odstavce). Retrieval na child, kontext z parent. - Overlap s inteligentním řezem — overlap na hranicích vět, ne uprostřed slov - Tabulky a strukturovaná data — speciální handling, zachování struktury - Metadata propagation — každý chunk nese metadata z dokumentu (název, autor, datum, kapitola)

Pro každý projekt testujeme 3-5 chunk konfigurací na reálných dotazech. Měříme recall@k a volíme optimální nastavení.

Hybridní vyhledávání¶

Samotné vektorové vyhledávání (dense retrieval) má slabiny — špatně zachycuje přesné termíny, ID, čísla. Samotný BM25 (sparse) nerozumí sémantice. Kombinace obou dává konzistentně lepší výsledky.

Reciprocal Rank Fusion (RRF): Standardní metoda pro kombinaci výsledků z více retrieverů. Každý retriever vrátí top-k, výsledky se sloučí a re-rankují. Typicky dense:sparse poměr 0.7:0.3, ale ladíme per doména.

Re-ranking — kde se dělá rozdíl¶

Bi-encoder embeddings jsou rychlé, ale nepřesné pro jemné rozlišení relevance. Cross-encoder re-ranking vezme top-50 výsledků a přeřadí je s plným attention mezi dotazem a dokumentem. Typicky zlepšuje precision@5 o 15-25%.

Používáme Cohere Rerank, BGE-reranker, nebo domain-tuned cross-encodery pro specifické domény.

Evaluace RAG kvality¶

Metriky, které měříme¶

Retrieval kvalita: - Recall@k — kolik relevantních dokumentů je v top-k výsledcích - NDCG — kvalita řazení výsledků - MRR — pozice prvního relevantního výsledku

Generation kvalita: - Faithfulness — je odpověď podložená kontextem? (ne vymyšlená) - Answer relevance — odpovídá odpověď na dotaz? - Completeness — pokrývá odpověď všechny aspekty dotazu? - Hallucination rate — kolik tvrzení v odpovědi nemá oporu v kontextu

Golden dataset¶

Pro každý RAG projekt vytváříme golden dataset — 200-500 párů (dotaz, očekávaná odpověď, relevantní dokumenty). Tento dataset slouží jako: - Benchmark pro měření kvality - Regression test při změnách (nový model, nový chunking, nové dokumenty) - Základ pro kontinuální evaluaci v CI/CD

Časté chyby RAG implementací¶

Za poslední roky jsme auditovali desítky RAG systémů. Nejčastější problémy:

1. Naivní chunking¶

Problém: Fixed-size chunky (512 tokenů) rozbíjejí kontext, tabulky, seznamy. Řešení: Semantic chunking s hierarchickou strukturou.

2. Chybějící re-ranking¶

Problém: Bi-encoder retrieval vrací „přibližně relevantní” výsledky, ale precision je nízká. Řešení: Cross-encoder re-ranking zlepší precision o 15-25%.

3. Žádná evaluace¶

Problém: „Funguje to” na 5 testovacích dotazech ≠ funguje to v produkci. Řešení: Golden dataset, automatické eval suite, kontinuální monitoring.

4. Ignorování metadat¶

Problém: Chunk bez kontextu (který dokument, jaká verze, jaké datum) vede ke špatným odpovědím. Řešení: Rich metadata na každém chunku + metadata filtering v query time.

5. Přehlížení OCR kvality¶

Problém: Garbage in, garbage out. Špatné OCR = špatné chunky = špatné odpovědi. Řešení: OCR quality pipeline s validací, fallback na vision modely pro složité dokumenty.

Produkční nasazení¶

Ingestion pipeline¶

• Sledujeme zdrojové systémy (SharePoint, Confluence, DMS, S3)
• Incremental processing — pouze nové/změněné dokumenty
• Versioning — starší verze chunků archivujeme, nové indexujeme
• Quality gates — dokument s nízkou OCR kvalitou jde na manuální kontrolu

Scaling¶

• Vector DB (Qdrant/Weaviate) horizontálně škáluje na miliony dokumentů
• Embedding computation paralelizujeme (batch processing)
• Caching — frequent queries cachujeme na úrovni retrieval i generation
• CDN pro statické knowledge base (interní dokumentace)

Monitoring¶

• Retrieval quality metrics (denní eval na golden datasetu)
• Query latency (P50/P95/P99)
• Cache hit rate
• Failed queries (no relevant context found)
• User feedback loop (thumbs up/down)

Kdy RAG nestačí¶

RAG není silver bullet. Situace, kdy potřebujete jiný přístup:

• Model nezná doménu vůbec → fine-tuning + RAG
• Potřebujete reasoning přes celou knowledge base → graph RAG nebo agentic RAG
• Data se mění v reálném čase → streaming ingestion + RAG
• Dotazy vyžadují multi-hop reasoning → agentic workflow s RAG jako nástrojem

V těchto případech kombinujeme RAG s dalšími technikami z našeho portfolia.