Claude RAG v praxi: AI asistent nad firemními dokumenty

Hledáte v PDF smlouvách konkrétní klauzuli. Čtete stostránkový interní manuál. Píšete kolegům, 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 vám 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, modely a cenami platnými na podzim 2026, které zvládnete o víkendu.

01Co vlastně RAG řeší

Klasický LLM má dvě základní omezení. Nezná vaše 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 vašich dokumentů. Model tak odpovídá na základě reálných zdrojů, ne své paměti — a dokáže citovat, odkud informaci má.

Výsledek? AI asistent, který přesně ví, co je ve vašich smlouvách, manuálech, interní wiki nebo technické dokumentaci.

02Architektura v kostce

Než se pustíme do kódu, rozdělte si celý systém na čtyři logické bloky:

1. Ingestace — načtení dokumentů, rozdělení na menší kousky (chunky), vytvoření embeddings
2. Ukládání — vektorová databáze, která umí hledat podle významu
3. Retrieval — vyhledání relevantních chunků pro konkrétní dotaz
4. 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.

03Krok 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čněte tím, že si rozdělíte dokumenty podle typu. Smlouvy se zpracovávají jinak než technický manuál. U smluv dávejte 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žijte 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 se text neřízl uprostřed myšlenky
• Metadata: ke každému chunku přidejte zdroj (název souboru), stránku, sekci a datum

Zajímavou novinku přináší Voyage AI: model voyage-context-4 umí tzv. kontextualizované embeddings — vytvoří vektor pro chunk v kontextu celého dokumentu (zvládne až 120 tisíc tokenů na doklad), takže nemusíte metadata ručně vypisovat do textu. U heterogenní firemní dokumentace to reálné zlepšení relevance přináší.

04Krok 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ůžete hledat podle obsahu, ne podle klíčových slov.

Důležitý fakt, který v mnoha starších návodech chybí: Anthropic nemá vlastní embeddings API. Oficiální doporučení je Voyage AI (dnes součást MongoDB). Aktuální řada voyage-4 funguje dobře i s českými texty:

• voyage-4 — $0,06 za milion tokenů, univerzální volba, 32K kontext, výchozích 1024 dimenzí
• voyage-4-lite — $0,02/MTok pro levné hromadné indexování
• voyage-4-large — $0,12/MTok pro nejvyšší přesnost
• voyage-context-4 — $0,12/MTok, kontextualizované chunk embeddings zmíněné výše

Kdybyste chtěli open-source alternativu, zvažte multilingual-e5-large, který pro češtinu dlouhodobě drží dobré výsledky.

Co se týče vektorové databáze, máte tři rozumné cesty:

• pgvector (aktuálně verze 0.8.7) — ideální, pokud už PostgreSQL používáte. Nepřidáváte novou infrastrukturu, SQL dotazy znáte a od verze 0.8 fungují iterativní index scany, které řeší starý problém filtrovaného vektorového hledání (kdy filtr s ANN indexem vrátil málo výsledků).
• Qdrant (verze 1.19) — rychlá, lehká, dobře se nasazuje v Dockeru. Nově umí vestavěné BM25 fulltextové vyhledávání přímo na serveru, což se hodí pro hybridní search. Pozor: výchozí tokenizace BM25 je nastavená na angličtinu — pro české texty si musíte stemming a stop-slova nakonfigurovat sami.
• Pinecone — managed služba, pokud nechcete spravovat infrastrukturu. Dražší, ale bezstarostná.

Pro většinu firemních projektů doporučuji pgvector. Už pravděpodobně máte databázi a přidat vektorové sloupce je otázka jedné migrace.

05Krok 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 dostanete průměrné výsledky. V produkci potřebujete víc.

Hybridní vyhledávání kombinuje sémantické (vektorové) hledání s klasickým fulltextem (BM25). V praxi to znamená, že najdete jak dokumenty podle významu, tak ty, které obsahují přesné termíny — třeba specifické číslo smlouvy nebo kód produktu. V pgvectoru sáhněte po spojení s PostgreSQL fulltextem, v Qdrantu po Query API s prefetchem a fúzí výsledků (RRF).

Reranking je druhý trik. Vezmete prvních 20–30 výsledků z vektorového hledání a necháte je přerovnat specializovaným modelem. Voyage AI pro to koncem září 2026 vydala modely rerank-3 ($0,05/MTok) a levnější rerank-3-lite ($0,02/MTok). Reranker porozumí kontextu lépe než čistá vektorová podobnost a vybere opravdu ty nejlepší 3–5 chunků.

Tento dvoustupňový přístup zvýší relevanci odpovědí drasticky. Měřítkem budiž: pokud váš asistent cituje nesprávnou smlouvu, selhal retrieval, ne model.

06Krok 4: Generace s Claude

Teď přijde ta zábavná část. Máte relevantní chunky, teď z nich potřebujete dostat srozumitelnou odpověď.

Aktuální nabídka modelů Claude (podzim 2026) je postavená na řadě 5.5 se kontextovým oknem 1 milion tokenů u všech modelů:

• claude-opus-5-5 — $4 za vstup a $20 za výstup na milion tokenů; oficiální doporučení pro většinu workloadů, když si nejste jistí
• claude-sonnet-5-5 — $2/$10 za MTok, nejlepší poměr rychlosti a inteligence; pro RAG asistenty obvykle ta správná volba
• claude-haiku-5-5 — $0,10/$0,50 za MTok u promptů do 100 tisíc tokenů; ideální pro levné předzpracování dotazů, klasifikaci nebo extrakci v pipeline

Pokud někde ještě vidíte doporučení na claude-sonnet-4-5, vězte, že tento model byl 30. 9. 2026 označen za deprecated a 30. 11. 2026 se vypíná.

Prompt pro Claude by měl obsahovat tři věci:

1. Jasnou roli — „Jsi interní asistent, který odpovídá pouze na základě poskytnutých dokumentů."
2. Kontext — nalezené chunky, přehledně označené zdrojem
3. Pravidla — pokud informace v kontextu není, řekněte to, nevymýšlejte. Citujte zdroj.

Pro produkční použití nastavte teplotu na 0 nebo velmi nízkou hodnotu. Chcete konzistenci, ne kreativitu — u firemních dokumentů je kreativita na škodu.

Využijte prompt caching. Klauzule s rolí, pravidly i opakovaně používané chunky uložte do cache: zápis stojí 1,25násobek ceny vstupu (5minutová TTL), ale čtení z cache u Sonnet 5.5 jen $0,10 za milion tokenů — tedy dvacetinu plné vstupní ceny. U asistenta, který dostává stovky dotazů denně nad stejnou znalostní bází, to řádově snižuje účet. Nově podporuje API i automatické cachování jedním parametrem, které breakpoint posouvá samo.

07Novinka 2026: Files API a citations jako mini-RAG

Od srpna 2026 je Files API obecně dostupná: nahrajete dokumenty (až 500 MB na soubor, 1 TB na organizaci, PDF i prostý text) a v Messages API se na ně odkážete přes file_id. A k tomu aktivujete citations — Claude pak u odpovědi vrací přesné citace s pozicemi v dokumentu, přičemž citovaný text se nepočítá do výstupních tokenů, takže citace jsou „zadarmo".

Pro menší znalostní báze (desítky až nízké stovky dokumentů) tak můžete postavit funkční asistenta bez vektorové databáze — dokumenty jednou nahrajete, necháte cachovat a Claude si v nich najde sám. Je to méně škálovatelné než plný RAG, ale zvládnete to za odpoledne. Klasický RAG s embeddings zůstává lepší, když máte tisíce dokumentů, potřebujete přístupová práva na úrovni chunků nebo chcete hybridní vyhledávání.

08Produkční nasazení: co vám v prototypu chybí

Funkční prototyp je polovina úspěchu. Do produkce potřebujete ještě:

Sledování a logování. Každý dotaz, nalezené chunky a finální odpověď si logujte. Až vám uživatelé nahlásí špatnou odpověď, musíte mít možnost dohledat, co se stalo. 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řebujete proces, jak inkrementálně aktualizovat vektorovou databázi — bez nutnosti vše přepočítávat. Řešením jsou hashe 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áte citlivé materiály (mzdové pásky, obchodní podmínky pro konkrétní klienty), musíte retrieval omezit podle identity uživatele — metadata chunků a filtr při vyhledávání jsou vaši přátelé. (Poznámka k Files API: soubory jsou sdílené na úrovni workspace, ne uživatele — pro více tenantů potřebujete workspace pro každého zvlášť.)

Hodnocení odpovědí. Než systém nasadíte, otestujte ho na sadě reálných dotazů s očekávanými odpověďmi. Vytvořte si sadu 30–50 dotazů a měřte, 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 odpovědí by mělo být pod 5 %.

09Kolik to stojí

Pojďme si to spočítat pro střední firemní znalostní bázi — řekněme 500 dokumentů, průměrně 20 stran, česky.

• Embeddings (jednorázově): přibližně 5 milionů tokenů × $0,06/MTok (voyage-4) = kolem $0,30. Směšně málo i s opakovanou rein dexací.
• Vektorová databáze: pgvector zdarma, Qdrant self-hosted zdarma, Pinecone od cca $70 měsíčně.
• Dotazy (Claude API): při 1 000 dotazech denně, Sonnet 5.5, zhruba 3 tisíce vstupních tokenů (chunky z cache) a 500 výstupních tokenů na dotaz se dostanete na cca $0,01 na dotaz → cca $300 měsíčně; s důsledným cachováním a předřazeným Haiku 5.5 pro rutinní dotazy to jde výrazně dolů.

Celkově se pohybujeme v řádech stovek dolarů měsíčně, což je zanedbatelné proti hodinám, které vaši kolegové ušetří nehledáním v dokumentech. Detailní přehled cen Claude najdete v aktuálním ceníku Claude API.

10Kdy RAG nepoužívat

Abych byl upřímný — RAG není stříbrná kulka. Někdy je lepší jít jinou cestou.

Máte-li málo dokumentů (do 20 krátkých textů), dlouho stačilo „naházet" celý obsah do kontextu. Dnes, kdy všechny aktuální modely Claude mají kontextové okno 1 milion tokenů (zhruba 550 tisíc slov), se tento stuffing pattern hodí i pro rozsáhlejší báze — klíčové je zkombinovat ho s prompt cachingem, aby se znalostní báze platila jednou za 5 minut, ne při každém dotazu. Pokud jsou vaše dokumenty silně strukturované (tabulky, ceníky), často vyjde lépe klasická databáze s SQL dotazy. A pokud potřebujete 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řebujete agenta s nástroji.

11Shrnutí: víkendový plán

1. Sobota dopoledne: rozdělte dokumenty podle typu, nastavte chunkování (500–800 tokenů, overlap 10–15 %, metadata).
2. Sobota odpoledne: vyberte embeddings (voyage-4) a vektorovou databázi (pgvector, pokud už PostgreSQL máte).
3. Neděle dopoledne: postavte hybridní retrieval s rerankingem (rerank-3-lite pro start).
4. Neděle odpoledne: postavte prompt pro claude-sonnet-5-5 s teplotou 0, zapněte citations a prompt caching, otestujte na 30 reálných dotazech.

A když chcete začít ještě menším krokem: nahrajte dvacet nejdůležitějších PDF přes Files API, zapněte citations a mějte funkčního asistenta ještě dnes večer. Plný RAG si přidejte, až když mu přeroste kontext a cache.