Jak naučit AI pracovat s vlastní dokumentací a know-how 

Interní dokumentace, návody i provozní know-how mají firmy často dobře sepsané – jen se k nim lidé ve správný moment nedokážou rychle dostat. Přístup RAG (Retrieval-Augmented Generation) umožňuje propojit generativní umělou inteligenci (AI) s vlastními daty tak, aby odpovědi vznikaly přímo z firemních dokumentů, a ne z obecného tréninku modelu. V článku si krok za krokem ukážeme, jak takový RAG systém navrhnout, nasadit a bezpečně provozovat v reálné firmě.

1) Kdy RAG dává smysl, a kdy ne

RAG (Retrieval-Augmented Generation) je přístup, kdy generativní AI nejprve vyhledá relevantní informace ve vaší vlastní dokumentaci a teprve z nich sestaví odpověď.

Dává smysl především tehdy, když má AI odpovídat přímo z vaší interní dokumentace a firemního know-how – typicky z wiki, návodů, runbooků nebo produktové dokumentace.

Velkou výhodou je, že obsah lze průběžně aktualizovat bez trénování modelu a zároveň je možné dohledat, z jakých zdrojů odpověď vznikla.

Naopak samotný RAG nestačí, pokud odpovědi vyžadují práci s aktuálními daty ze systémů, výpočty nebo transakční logiku. Nepomůže ani v případě neudržované a roztříštěné dokumentace, pouze zpřístupní existující chaos. Zároveň je nutné počítat s tím, že RAG sám neřeší bezpečnostní rizika a zneužití modelu, píše web Owasp.

RAG je tedy ideální nástroj pro to, aby se generativní umělá inteligence stala spolehlivým rozhraním k firemní dokumentaci a znalostem, nikoliv náhradou databází, analytických nástrojů nebo provozních systémů.

2) Připravte data – inventura, čistota, práva

Než začnete řešit embeddingy a vektorovou databázi, je potřeba udělat základní krok. Ujasnit si, s jakými daty má RAG vůbec pracovat a za jakých podmínek. Kvalita celého řešení je přímo závislá na kvalitě vstupní dokumentace.

Co do RAG patří:

• oficiální interní dokumentace (aktuální postupy),
• často kladené dotazy, knowledge base (znalostní báze),
• provozní příručky, příčiny nehod,
• produktové manuály, technické specifikace.

Co do RAG typicky nepatří (nebo jen po ošetření):

• osobní údaje, citlivé smlouvy, tajemství bez potřeby přístupu,
• duplicity, staré verze bez označení,
• dokumenty bez kontextu (nahodilé exporty bez metadat).

Zároveň si nastavte správu – kdo data spravuje, jak se aktualizují, kdo má přístup. To je přesně duch rámců typu NIST AI RMF (řízení rizik, odpovědnost, dohled).

3) Dělení dokumentů na menší části – klíčový krok pro přesnost RAG

Rozdělení dokumentů na menší části (tzv. chunks) má na kvalitu RAG větší vliv než samotný model nebo databáze. Právě podle těchto úseků se totiž vyhledává kontext pro odpověď.

Pokud jsou tyto části příliš velké, AI sice najde správný dokument, ale nedokáže přesně vytáhnout relevantní pasáž. Pokud jsou naopak příliš malé, ztratí se souvislosti a odpovědi začnou být neúplné nebo zavádějící.

Proto se moc nevyplácí dělit dokumenty jen technicky „po X znacích“. Mnohem lepší je vycházet ze struktury obsahu – tedy z nadpisů, kapitol, odstavců, seznamů nebo sekcí typu FAQ.

V praxi se osvědčuje:

• dělit podle logické struktury dokumentu, ne podle délky,
• hlídat, aby jeden chunk pokrýval jedno téma nebo krok postupu,
• testovat různé velikosti chunků na reálných dotazech a sledovat, zda se vrací správné pasáže.

Právě na nutnost ladění velikosti a struktury chunků upozorňují i nástroje pro stavbu RAG pipeline, například LlamaIndex. Ty mají přímo metody pro vyhodnocování kvality vyhledávání podle použitého dělení dokumentů.

4) Embeddings – převod textu na vektory

Aby RAG dokázal vyhledávat podle významu, a nejen podle shody slov, převádí se jednotlivé části na tzv. embeddingy (číselné vektory, které reprezentují význam textu). Díky tomu pak systém dokáže najít relevantní pasáže i tehdy, když uživatel použije jiné formulace, synonyma nebo zkratky.

V praxi to funguje jednoduše. Každá menší část projde embedding modelem (například od poskytovatelů jako OpenAI nebo otevřených modelů dostupných přes Hugging Face) a výsledný vektor se uloží do vektorového úložiště. Při dotazu se stejným způsobem převede i otázka uživatele a systém vyhledá nejbližší vektory.

Důležité praktické zásady:

• používejte jeden embedding model konzistentně,
• ukládejte k vektorům i metadata (zdroj, sekci, verzi dokumentu),
• kvalitu embeddingů vždy ověřte na reálných firemních dotazech – zejména pokud pracujete s češtinou a interní terminologií.

5) Vector store – kam vektory uložit

Jakmile máte vytvořené embeddingy, potřebujete je uložit do tzv. vector store (úložiště, které umí rychle vyhledávat podle podobnosti vektorů). Volba úložiště má přímý dopad na škálovatelnost, latenci i provozní složitost celého RAG řešení.

Máte tři časté varianty:

• Vektorová databáze (typicky pro větší RAG) – hodí se pro větší objemy dokumentů a vyšší zátěž. Je navržená přímo pro práci s embeddingy, škálování a rychlé vyhledávání podle podobnosti (typicky řešení postavená nad projekty jako Zilliz/Milvus nebo Weaviate).
• Hybridní vyhledávání (vektor + klíčová slova) – kombinuje sémantické hledání s klasickým fulltextem. V praxi je velmi přesné pro firemní dokumentaci, kde potřebujete najít nejen význam, ale i konkrétní názvy, kódy nebo ID (hybridní přístup je typický například pro Weaviate).
• Klasický vyhledávač s vektory (pokud už ho máte) – pokud už provozujete firemní vyhledávání, často se vyplatí jen doplnit vektorové pole a kNN vyhledávání (typicky u řešení od společnosti Elastic). Výhodou je jednodušší provoz a integrace do existující infrastruktury.

Při výběru vector store se také vyplatí sledovat hlavně zda podporuje hybridní vyhledávání, jak pracuje s metadaty a filtrováním podle oprávnění, jak se chová při růstu počtu dokumentů a jak složitý je jeho provoz a správa.

Pro menší RAG stačí jednodušší řešení, ale pro reálný firemní provoz se vyplatí volit úložiště, které zvládne hybridní hledání, práci s právy a dlouhodobé škálování.

6) Retriever – jak vybírat správné pasáže

Retriever je část RAG, která určuje, které úseky dokumentů se pošlou modelu jako kontext. Pokud v tomto kroku projdou špatné nebo nepřesné pasáže, kvalitu odpovědi už později nezachrání ani sebelepší model, píše web Medium.

V praxi se ladí hlavně počet vracených úseků (top-k). Příliš malé číslo znamená chybějící informace, příliš velké naopak zbytečný šum. Velmi dobře se osvědčuje kombinace sémantického (vektorového) a klasického fulltextového vyhledávání, aby se zachytil jak význam dotazu, tak přesné technické výrazy nebo názvy.

U náročnějších použití se přidává ještě re-ranking, tedy dodatečné přeuspořádání nalezených pasáží podle jejich skutečné relevance k dotazu. Tyto mechanismy má hotové například framework LangChain. To umožňuje retriever postupně ladit bez zásahů do zbytku aplikace.

7) Prompt – nastavení pravidel odpovědí

U RAG není cílem napsat dlouhý kreativní prompt, ale jasně vymezit, jak se má model chovat k dodaným dokumentům. Prompt má fungovat spíš jako provozní smlouva než jako zadání slohové práce.

Základ je striktně oddělit instrukce od kontextu. Tedy zvlášť říct, co má model dělat, a zvlášť mu dodat nalezené pasáže z dokumentace. Model by měl mít výslovně řečeno, že smí odpovídat pouze z poskytnutých zdrojů, nikoli z obecné znalosti.

Velmi se osvědčuje nastavit:

• povinnost uvádět zdroje nebo názvy dokumentů, ze kterých odpověď vychází,
• pevný formát odpovědi (např. krátká odpověď + seznam zdrojů),
• jasné pravidlo pro nejistotu – například „pokud v dodaných podkladech odpověď není, řekni, že to v dokumentaci nevidíš“.

Dobře navržený prompt tak výrazně snižuje riziko domýšlení odpovědí a pomáhá udržet RAG systém v roli asistenta nad firemními daty, nikoli obecného chatbota.

8) Vyhodnocení – bez měření nepoznáte, že to funguje

U RAG nestačí sledovat, jestli se to uživatelům líbí. Potřebujete si ověřit, kde přesně vznikají chyby – jestli v samotném vyhledávání, nebo až při generování odpovědi.

V praxi se proto vyhodnocují dvě odlišné vrstvy:

• Kvalita retrievalu – zda systém vůbec dokáže k dotazu najít správné pasáže. Typicky se testuje, jestli se mezi vrácenými chuncky objeví relevantní zdroj (například postup, kapitola nebo konkrétní dokument). Pokud správný zdroj retriever nenajde, model už z principu nemůže odpovědět správně.
• Kvalita odpovědi – sleduje se hlavně, zda odpověď skutečně vychází z dodaných pasáží, zda není zkreslená nebo neúplná a zda správně cituje zdroje.

Důležité je tyto dvě věci nemíchat. Pokud je problém v retrievalu, ladí se chunking, embeddingy nebo nastavení retrieveru. Pokud je retrieval v pořádku, ale odpověď je špatná, řeší se prompt a způsob práce s kontextem.

Pro tento typ testování existují i hotové nástroje. Například framework LlamaIndex umožňuje hodnotit úspěšnost vyhledávání a porovnávat různé varianty retrieveru nebo velikosti chunků na stejných testovacích otázkách.

9) Bezpečnost – RAG je aplikace, ne kouzlo

RAG není jen chytrý prompt, ale plnohodnotná aplikace, která pracuje s interními daty, uživateli a přístupovými právy. Z bezpečnostního pohledu se proto chová stejně jako každá jiná interní služba a má i velmi podobná rizika, píše web Owasp.

Nejčastější problém je, že se ochrana řeší až na úrovni modelu, ale skutečné slabiny vznikají kolem něj – ve vstupních datech, v retrieveru, v napojení na další systémy a ve způsobu, jak se s odpověďmi pracuje v aplikaci.

V praxi je nutné počítat zejména s těmito scénáři:

• Prompt injection – uživatel se snaží přimět model, aby ignoroval pravidla a pracoval s jiným kontextem, než má.
• Únik citlivých informací – pokud retriever nefiltruje výsledky podle oprávnění uživatele, může se do odpovědi dostat dokument, ke kterému by daný uživatel normálně neměl přístup.
• Nezabezpečené zpracování výstupu – odpověď může obsahovat odkazy, kód nebo text, který se dá zneužít v navazujících systémech.
• Nákladové a provozní útoky – extrémně dlouhé dotazy, velké kontexty nebo hromadné požadavky mohou výrazně zvýšit náklady nebo způsobit nedostupnost služby.

Základní bezpečnost RAG řešení proto stojí především na tom, že se přístupová práva uplatňují už při samotném vyhledávání. Tedy tak, aby se do kontextu pro model nikdy nedostaly dokumenty, ke kterým uživatel nemá oprávnění.

Současně je vhodné logovat nejen samotné dotazy, ale i konkrétní zdroje, ze kterých byla odpověď sestavena, aby bylo možné zpětně dohledat její původ.

10) Provoz – aktualizace indexu a know-how

RAG není jednorázový projekt, ale živá služba, která musí průběžně reagovat na změny ve firemní dokumentaci. Základním provozním úkolem je proto pravidelná aktualizace indexu. Tedy zajištění, aby se nové nebo upravené dokumenty promítly do embeddingů a vyhledávání co nejdříve po změně.

Součástí provozu by měl být také jednoduchý proces pro práci s verzemi a duplicitami. Pokud se dokument přepíše nebo nahradí novou verzí, starý obsah by se neměl dál objevovat v odpovědích. Stejně důležité je mít jasně dané, kdo je odpovědný za správnost a aktuálnost jednotlivých zdrojů.

V praxi se vyplatí sledovat i základní provozní metriky – například kolikrát systém odpověděl stylem informaci nemám, kolik dotazů vrací nerelevantní pasáže nebo u kterých témat si uživatelé nejčastěji stěžují. Právě zpětná vazba od uživatelů je nejrychlejší způsob, jak odhalit, že se know-how ve firmě posunulo, ale RAG na to ještě nereaguje.

Rychlý checklist

1) Vyberte use-case (FAQ, podpora, interní postupy)

2) Udělejte inventuru dokumentů + přístupová práva

3) Načtěte dokumenty a očistěte je (struktura, metadata)

4) Nastavte chunking (a změřte ho)

5) Vytvořte embeddings a uložte do vector store

6) Postavte retriever (top-k, hybrid, re-rank)

7) Navrhněte prompt s citacemi a fallbackem

8) Otestujte retrieval i odpovědi (evaluace)

9) Doplňte bezpečnostní vrstvy

10) Zaveďte aktualizace indexu + monitoring

RAG jako reálný nástroj pro každodenní práci s firemním know-how

RAG je dnes nejpraktičtější cesta, jak dostat generativní AI do reálného firemního provozu. Ne jako chytřejší chat, ale jako spolehlivé rozhraní k vlastní dokumentaci a znalostem.

Jak ukazuje celý postup od přípravy dat přes dělení dokumentů, embeddings, retriever až po bezpečnost a provoz, kvalita RAG nestojí na samotném modelu, ale především na datech, architektuře a dobře nastavených procesech.

Pro české firmy navíc dává smysl stavět takové řešení nad lokální a kontrolovatelnou infrastrukturou – například provozovat vlastní RAG a interní LLM na GPU serverech v rámci ZonerCloudu, mít centrální správu domén a přístupů přes CZECHIA.COM a řešit TLS certifikáty a jejich automatizaci pomocí SSLMarketu.

Teprve kombinace správně navrženého RAG a stabilního provozního zázemí z něj dělá nástroj, který firmám skutečně šetří čas, snižuje chybovost a zpřístupňuje jejich vlastní know-how ve chvíli, kdy ho lidé opravdu potřebují.