Hledáš v PDF smlouvách konkrétní klauzuli. Čteš stostránkový interní manuál. Ptáš se kolegů, jestli někdo neví, jak se řeší ten jeden edge case v procesu. Zní to povědomě? Většina firem sedí na stovkách dokumentů, které jsou plné cenných informací — a zároveň prakticky nevyužitých, protože do nich nikdo nemá čas jezdit.
Řešení se jmenuje RAG (Retrieval-Augmented Generation). V tomto článku ti ukážu, jak postavit AI asistenta nad vlastními firemními dokumenty pomocí Claude — od prvního návrhu po produkční nasazení. Bez marketingových frází, s konkrétními kroky, které zvládneš za víkend.
Co vlastně RAG řeší
Klasický LLM má dvě základní omezení. Nezná tvá firemní data a občas si věci vymýšlí (halucinuje). RAG to řeší jednoduchým trikem: před samotnou odpovědí do modelu pošleme relevantní úryvky z tvých dokumentů. Model tak odpovídá na základě reálných zdrojů, ne své paměti.
Výsledek? AI asistent, který přesně ví, co je ve tvých smlouvách, manuálech, interní wiki nebo technické dokumentaci. A dokáže citovat, odkud informaci má.
Architektura v kostce
Než se pustíme do kódu, pojďme si rozdělit celý systém na čtyři logické bloky:
- Ingestace — načtení dokumentů, rozdělení na menší kousky (chunky), vytvoření embeddings
- Ukládání — vektorová databáze, která umí hledat podle významu
- Retrieval — vyhledání relevantních chunků pro konkrétní dotaz
- Generace — sestavení kontextu a odeslání do Claude pro finální odpověď
Každý z těchto bloků má svá úskalí. Pojďme si je projít.
Krok 1: Ingestace a chunkování
Tady padne 80 % projektů. Ne proto, že by to bylo technicky těžké, ale proto, že lidé podceňují přípravu dat.
Začni tím, že si rozdělíš dokumenty podle typu. Smlouvy se zpracovávají jinak než technický manuál. U smluv dávej pozor na paragrafy a články — jeden chunk by měl obsahovat celý logický celek (např. jeden článek smlouvy), ne náhodných 500 znaků uprostřed věty.
Pro chunkování použij knihovnu jako LangChain nebo LlamaIndex, ale se smysluplnou konfigurací:
- Velikost chunku: 500–800 tokenů pro běžné texty, menší (300–400) pro husté právní dokumenty
- Překryv (overlap): 10–15 % velikosti chunku, aby ses neřízl uprostřed myšlenky
- Metadata: ke každému chunku přidej zdroj (název souboru), stránku, sekci a datum
Ta metadata pak zachráníš život, až budeš ladit, proč asistent tvrdí nesmysly. Vždycky totiž víš, z jakého dokumentu odpověď pochází.
Krok 2: Embeddings a vektorová databáze
Embeddings jsou vektorová reprezentace textu — čísla, které zachycují význam. Podobné texty mají podobné vektory, a proto je můžeš hledat podle obsahu, ne podle klíčových slov.
Pro češtinu doporučuji modely jako text-embedding-3-large od OpenAI nebo voyage-3 od Voyage AI. Oboje funguje dobře i s českými texty, i když primárně jsou trénované na angličtině. Pokud máš hodně česky specifický obsah, zvaž multilingual-e5-large jako open-source alternativu.
Co se týče vektorové databáze, máš tři rozumné cesty:
- pgvector (PostgreSQL rozšíření) — ideální, pokud už PostgreSQL používáš. Nepřidáváš novou infrastrukturu a SQL dotazy znáš.
- Qdrant — rychlá, lehká, dobře se nasazuje v Dockeru. Skvělá pro střední projekty.
- Pinecone — managed služba, pokud nechceš spravovat infrastrukturu. Dražší, ale bezstarostná.
Pro většinu firemních projektů bych šel do pgvector. Už pravděpodobně máš databázi, přidat vektorové sloupce je otázka jedné migrace.
Krok 3: Retrieval — tady se rozhoduje o kvalitě
Naivní RAG vezme dotaz uživatele, převede ho na embedding a najde nejpodobnější chunky. Funguje to, ale často dostaneš průměrné výsledky. Produčně potřebuješ víc.
Hybridní vyhledávání kombinuje sémantické (vektorové) hledání s klasickým fulltextem (BM25). V praxi to znamená, že najdeš jak dokumenty podle významu, tak ty, které obsahují přesné termíny — třeba specifické číslo smlouvy nebo kód produktu.
Reranking je druhý trik. Vezmeš prvních 20–30 výsledků z vektorového hledání a necháš je přerovnat specializovaným modelem (Cohere Rerank, nebo dokonce Claude na jeden rychlý call). Reranker porozumí kontextu líp než čistá vektorová podobnost a vybere opravdu ty nejlepší 3–5 chunky.
Tento dvoustupňový přístup zvýší relevanci odpovědí drasticky. Měřítkem budiž: pokud tvůj asistent cituje nesprávnou smlouvu, retrieval selhal, ne model.
Krok 4: Generace s Claude
Teď přijde ta zábavná část. Máš relevantní chunky, teď z nich potřebuješ dostat srozumitelnou odpověď.
Prompt pro Claude by měl obsahovat tři věci:
- Jasnou roli — „Jsi interní asistent, který odpovídá pouze na základě poskytnutých dokumentů."
- Kontext — nalezené chunky, přehledně označené zdrojem
- Pravidla — pokud informace v kontextu není, řekni to, nevymýšlej si. Cituj zdroj.
Důležité: Claude má štědrou velikost kontextového okna, ale to neznamená, že tam máš házet všechno. Víš víc kontextu než je potřeba model spomalí a zhorší přesnost. Posílej jen relevantních 3–5 chunků.
Pro produkční použití nastav teplotu na 0 nebo velmi nízkou hodnotu. Chceš konzistenci, ne kreativitu. U firemních dokumentů je kreativita na škodu.
Produkční nasazení: co ti chybí
Funkční prototyp je polovina úspěchu. Producky potřebuješ ještě:
Sledování a logování. Každý dotaz, nalezené chunky a finální odpověď si loguj. Až ti uživatelé nahlásí špatnou odpověď, musíš mít možnost dohledat, co se stalo. Nástroje jako LangSmith nebo vlastní jednoduchá tabulka v databázi udělají svou práci.
Aktualizace dokumentů. Dokumenty se mění. Smlouvy se doplňují, manuály aktualizují. Potřebuješ proces, jak inkrementálně aktualizovat vektorovou databázi — bez nutnosti vše přepočítávat. Řešením jsou hash-e dokumentů a verzování chunků.
Přístupová práva. Tohle je bod, na který se často zapomíná. Ne každý zaměstnanec by měl vidět všechny dokumenty. Pokud máš citlivé materiály (např. mzdové pásky, obchodní podmínky pro konkrétní klienty), musíš retrieval omezit podle identity uživatele. Metadata chunků (kdo smí vidět) a filter při vyhledávání jsou tvoji přátelé.
Hodnocení odpovědí. Než systém nasadíš, otestuj ho na sadě reálných dotazů s očekávanými odpověďmi. Vytvoř si sadu 30–50 dotazů a měř, kolikrát asistent odpoví správně. Cílová metrika: alespoň 85 % správných odpovědí, zbytek jsou „nevím" nebo částečné odpovědi. Neplatných (nesprávných) odpovědí by mělo být pod 5 %.
Kolik to stojí
Pojďme si to rychle spočítat pro střední firemní znalostní bázi — řekněme 500 dokumentů, průměrně 20 stran, česky.
- Embeddings (jednorázově): cca 200 tisíc chunků × $0,13 / milion tokenů = zhruba $0,03. Směšně málo.
- Vektorová databáze: pgvector zdarma, Qdrant self-hosted zdarma, Pinecone od $70 měsíčně.
- Dotazy (Claude API): při 1 000 dotazech denně a průměrné ceně $0,01 na dotaz přijdeš na $300 měsíčně.
Celkově se pohybujeme v řádech stovek dolarů měsíčně, což je zanedbatelné proti hodinám, které tvoji kolegové ušetří nehledáním v dokumentech.
Kdy RAG nepoužívat
Abych byl upřímný — RAG není stříbrná kulka. Někdy je lepší jít jinou cestou.
Pokud máš málo dokumentů (do 20 krátkých textů), často stačí hodnat celou obsah do kontextu Claude a RAG vůbec nepotřebovat. Pokud jsou tvé dokumenty silně strukturované (tabulky, ceníky), často vyjde líp klasická databáze s SQL dotazy. A pokud potřebuješ odpovídat na otázky vyžadující uvažování nad více kroky (analýza trendů napříč časem), čistý RAG nebude stačit — potřebuješ agenta s nástroji.
Shrnutí: tvůj víkendový plán
- Vyber 10–20 klíčových firemních dokumentů a naimportuj je do pgvector s rozumným chunkováním
- Postav jednoduchý retrieval s hybridním vyhledáváním
- Napoj Claude s jasným promptem a citacemi zdrojů
- Otestuj na 20 reálných dotazech
- Nasad interně, sbírej zpětnou vazbu, iteruj
Začni malě. Nejdřív deset dokumentů, ne pět set. Uvidíš, kde to bolí, a podle toho postupuj. RAG projekty umírají nejčastěji na to, že se někdo pokusí nasát celou firemní wiki najednou a výsledek je nepoužitelný.
Postupuj inkrementálně, měř kvalitu odpovědí a pamatuj — nejvíc času strávíš na přípravě dat, ne na AI. To je dobře. Znamená to, že tvůj projekt dává smysl i tehdy, když si vyměníš model za jiný.
