RAG bez halucinací: enterprise knowledge layer¶

RAG je nejpraktičtější způsob, jak dostat AI do firemního prostředí bezpečně. Pokud chcete výsledky bez halucinací a s dohledatelností, postavte knowledge layer jako produkt — ne jako vedlejší efekt chatbota.

1 Inventura znalostí¶

Než začnete indexovat, musíte vědět, co máte. Kde jsou dokumenty? Kdo je vlastní? Jak poznáte, že dokument je platný — a ne zastaralá verze z roku 2019?

Inventura není technický krok — je to organizační. Mluvte s lidmi, kteří dokumenty tvoří a používají. Zjistěte, kde jsou autoritativní zdroje a kde jsou kopie kopií.

• Zmapujte zdroje: SharePoint, Confluence, Git, interní wiki, e-maily, tickety
• Identifikujte vlastníky: kdo dokument vytváří, kdo schvaluje, kdo aktualizuje
• Definujte kritéria platnosti: datum, verze, status (draft/approved/archived)
• Rozhodněte, co do RAG patří a co ne — ne každý dokument je vhodný

2 Klasifikace a přístupová práva¶

Každý dokument potřebuje metadata. Bez nich je knowledge base jen hromada textu, ze které model čerpá bez kontextu — a to je recept na halucinace a bezpečnostní incidenty.

Metadata umožňují filtrovat retrieval: uživatel z oddělení A nesmí dostat odpověď z dokumentů oddělení B. Citlivost, oddělení, platnost a jazyk jsou minimum.

• Citlivost: veřejné, interní, důvěrné, přísně důvěrné
• Oddělení: HR, finance, legal, product, engineering
• Platnost: aktuální, archivní, draft
• Jazyk: CS, EN, DE — retrieval musí respektovat jazykový kontext
• Přístupová práva v RAG musí odpovídat přístupovým právům ve zdrojovém systému

3 Chunking a kontext¶

Špatný chunking je nejčastější příčina špatných odpovědí. Dělit dokument na 500-tokenové kousky bez ohledu na strukturu je jako stříhat knihu nůžkami a doufat, že úryvky budou dávat smysl.

Dobrý chunk je samonosný — dává smysl i bez okolního textu. Současně potřebuje kontext: z jakého dokumentu pochází, jaká je kapitola, co je nad ním a pod ním.

• Dělit podle struktury dokumentu: nadpisy, sekce, odstavce — ne fixní token count
• Každý chunk musí být srozumitelný samostatně
• Přidejte surrounding context: název dokumentu, nadřazená sekce, datum
• Overlapping chunks: 10–20 % overlap zabrání ztrátě kontextu na hranicích
• Testujte: zobrazte si chunky a ptejte se — „dává tohle smysl bez kontextu?”

4 Indexace a retrieval strategie¶

Samotné vektory nestačí. Vektorový search je silný na sémantickou podobnost, ale slabý na přesné termy, čísla a specifické názvy. Proto potřebujete hybridní přístup.

Kombinace vektorového searche a full-text searche s metadatovými filtry je standard. Váhy mezi nimi ladíte podle typu dotazů vašich uživatelů.

• Vektorový search: sémantická podobnost, dobré pro „jak” a „proč” otázky
• Full-text search: přesné termy, názvy produktů, čísla smluv, kódy
• Metadatové filtry: oddělení, jazyk, platnost — zužují scope retrievalu
• Re-ranking: cross-encoder nebo LLM-based re-ranking top-K výsledků
• Sledujte recall a precision — ne jen „vrátilo to něco”

5 Citace zdrojů a „nevím”¶

Každá odpověď musí mít zdroj. Uživatel musí vidět, z jakého dokumentu AI čerpala — a mít možnost si to ověřit. Odpověď bez citace je tvrzení bez důkazu.

A když retrieval nevrátí relevantní výsledky? Agent musí říct „nevím” nebo „nemám dostatek informací.” Halucinace vznikají, když model odpovídá i bez podkladů — a to je přesně to, čemu chcete zabránit.

• Každá odpověď = text + citace (název dokumentu, sekce, link)
• Confidence score: pokud retrieval vrátí nízké skóre, neodpovídat
• Fallback: „Na tuto otázku nemám dostatek informací. Zkuste kontaktovat [oddělení].”
• Nikdy neodpovídat z „obecných znalostí” modelu — jen ze zdrojů v knowledge base

6 Evals¶

Máte dva druhy evalů: testy retrievalu a testy odpovědí. Oba potřebujete. Retrieval eval měří, jestli systém vrací správné dokumenty. Answer eval měří, jestli model z nich generuje správnou odpověď.

Golden dataset je základ: sada otázek → očekávané zdrojové dokumenty → očekávané odpovědi. Bez něj nevíte, jestli se systém zlepšuje nebo zhoršuje.

• Retrieval evals: „Na tuto otázku musí vrátit tyto dokumenty” (precision, recall, MRR)
• Answer evals: „Odpověď musí obsahovat tyto informace” (faithfulness, relevance)
• Golden dataset: 50–200 párů, pokrývajících klíčové scénáře
• Pouštějte evals po každé změně: nový dokument, změna chunkingu, upgrade modelu
• Automatizujte: evals v CI/CD pipeline, ne ruční testování

7 Provoz¶

Knowledge layer je produkt. A produkty se provozují: monitoring, údržba, optimalizace. Nasadit RAG a „nechat to běžet” je cesta k postupné degradaci kvality.

Sledujte, na co se uživatelé ptají. Identifikujte top dotazy (abyste je optimalizovali), neúspěšné dotazy (abyste přidali zdroje) a náklady (abyste řídili budget).

• Monitoring: response time, retrieval quality score, error rate
• Top dotazy: co uživatelé řeší nejčastěji — optimalizujte tyto cesty
• Neúspěšné dotazy: kde agent říká „nevím” — chybí dokumenty nebo špatný retrieval?
• Náklady: embedding costs, LLM calls, storage — per-request i celkově
• Verzování: knowledge base má release cyklus jako software
• Pravidelný review: jsou dokumenty aktuální? Přibyly nové zdroje?

Závěr¶

RAG bez halucinací není o lepším modelu. Je o lepším systému kolem modelu: čisté zdroje, správná metadata, dobrý chunking, hybridní retrieval, povinné citace a průběžné eval. Postavte knowledge layer jako produkt — s vlastním týmem, metrikami a release procesem.