Největší problém AI agentů v roce 2026 není inteligence. Je kontext.
Zeptej se Claude nebo GPT na cokoliv obecného a dostaneš kvalitní odpověď. Zeptej se jich na tvůj firemní proces, na to, jak přesně funguje tvůj approval workflow, nebo proč tvůj deployment script používá konkrétní flag — a dostaneš buď hádání, nebo "nemám k tomu informace". Model je chytrý, ale neví nic o tvé firmě.
Řešení se jmenuje knowledge base — strukturované úložiště firemních znalostí, ke kterému se AI agent dokáže připojit a dotazovat se na něj. V tomto článku ti ukážu, jak ji postavit krok za krokem, jaké formáty fungují nejlépe a jak vyřešit největší úskalí: aby agent našel skutečně relevantní informaci, ne jen něco, co vypadá relevantně.
Proč prostý upload PDF nefunguje
První instinkt většiny lidí: nahrajeme dokumenty do ChatGPT a hotovo. Funguje to — pro pět dokumentů. Pro padesát už ne. Pro pět set vůbec ne.
Důvody jsou tři:
- Context window má limity. I Claude s kontextem 1M tokenů nedokáže efektivně prohledat 500 dokumentů. Model buď odpoví pomalu, nebo začne halucinovat, protože relevantní informace se ztratí v šumu.
- Cena. Posílat 200 000 tokenů kontextu při každém dotazu tě vyjde na desítky korun za jeden query. Vypiš to na měsíc a dostaneš fakturu, co tě potěší.
- Najde špatnou věc. Model neumí prioritizovat. Když hledáš postup pro restart konkrétní mikroslužby, dostaneš všech 50 dokumentů, co zmíní slovo "restart", včetně toho z roku 2023 o vývoji mobilní aplikace.
Správná knowledge base tento problém řeší dvěma věcmi: chunkingem (rozdělením na malé sémantické bloky) a vektorovým vyhledáváním (hledáním podle významu, ne podle klíčových slov).
Architektura, která skutečně funguje
Schéma je jednoduché, ale každá část rozhoduje:
Dokumenty → Parser → Chunker → Embedding model → Vektorová DB
↓
Uživatelský dotaz → Embedding → Vektorové hledání → Top-K chunků → LLM → Odpověď
Tohle je klasický RAG (Retrieval-Augmented Generation) pipeline. Pojďme si ho rozebrat po komponentách.
1. Parser: čistý text ze všeho
Tvůj Notion export je JSON. Tvoje wiki je Markdown. Tvoje procesní dokumenty jsou PDF nebo DOCX s tabulkami a diagramy. Tvůj CRM exportuje CSV.
První krok je všechno dostat do jednotného formátu. Pokud používáš Python, unstructured knihovna zvládne většinu formátů. Pokud chceš minimum závislostí, prostý Markdown funguje nejlépe — protože LLM mu rozumí nativně a neztrácíš tokeny na formátovací šum.
Důležité: zachovej metadata. Pro každý dokument si ulož název, sekci, datum úpravy a typ. Bez toho se později nedozvíš, odkud odpověď pochází — a to je kritické pro důvěru.
2. Chunker: menší je lepší, ale ne moc
Tohle je místo, kde se 90 % knowledge basí rozpadne. Rozdělíš dokument na příliš velké kusy → model nedostane přesnou informaci. Na příliš malé → ztratíš kontext a dostaneš fragmenty bez souvislosti.
Funkční default v roce 2026: 500–800 tokenů na chunk, s překryvem 100 tokenů. To znamená, že konce chunků se mírně překrývají, aby ses neřízl uprostřed myšlenky.
Pokud máš technickou dokumentaci, použij strukturovaný chunking — děl podle nadpisů (H2, H3), ne podle pevné velikosti. Jedna sekce dokumentace = jeden chunk. Funguje to mnohem líp než slepé dělení.
3. Embedding model: základní kámen
Embedding převádí text na vektor čísel, který zachycuje význam. Když pak uživatel zeptá "jak restartuješ payment service", systém najde chunk, který říká "postup pro redeploy platebního modulu", i když nesdílí jediné slovo.
Výběr modelu se změnil k nepoznání. V červenci 2026 jsou nejlepší volby:
- OpenAI
text-embedding-3-large— univerzální, dvojjazyčný (čeština funguje), 3072 dimenzí, spolehlivý default. - Cohere
embed-v4— výborný pro vícejazyčné znalostní báze, podporuje i obrázky. - Lokální
nomic-embed-text— zdarma, běží na tvém stroji, pro malé báze naprosto dostačující.
Nevyber si model podle benchmarku. Vyber si ho podle toho, jestli umí češtinu. Spousta firem zjistí po třech měsících, že jejich embedding model funguje perfektně na angličtinu — a vrací nesmysly pro české dotazy. Otestuj na deseti reálných dotazech předtím, než commitneš.
4. Vektorová databáze
Potřebuješ místo, kde vektory žijí a kde se rychle hledají. Možností je mnoho:
- Qdrant nebo Weaviate — self-hosted, open source, produkčně ověřené.
- Pinecone — managed, prostě funguje, platíš.
- pgvector (PostgreSQL rozšíření) — pokud už PostgreSQL používáš, nepřidáváš novou infrastrukturu.
Pro tým do 20 lidí a bázi do 10 000 dokumentů je pgvector nejrozumnější volba. Jedna databáze na všechno, žádná nová závislost. Pokud rosteš nad to, Qdrant dává smysl — je rychlejší na velkých objemech a má lepší filtrování (např. "jen dokumenty z posledních 6 měsíců").
Dotazovací pipeline: co se skutečně stále rozbíjí
Máš bázi. Teď přijde část, kterou lidé podceňují: jak se agenta vlastně ptá.
Naivní přístup: uživatel napíše dotaz → embedding → top 5 chunků → LLM. Funguje na demu. V produkci selže ve 30 % případů, protože:
- Uživatel se ptá špatně. "To nefunguje" jako dotaz najde cokoliv o nefunkčnosti. Musíš dotaz přepsat — buď ručně, nebo lépe agentem, který doplní kontext ("co přesně nefunguje, ve které službě").
- Top-5 nestačí. Reálná odpověď je často rozprostřena přes tři chunky z různých dokumentů. Zvýš na top-10 a použij reranker.
- Bez citací je odpověď bezcenná. Agent musí vrátit odkaz na zdroj. Bez toho uživatel neví, jestli si model vymýšlí.
Reranker je tajná zbraň, kterou používá málokdo. Běžné vektorové hledání je rychlé, ale nepřesné — vrátí něco relevantního, ne nejrelevantnější. Reranker (Cohere Rerank, nebo lokální bge-reranker) si vezme top-20 výsledků a seřadí je znovu, tentokrát hloubkově. Rozdíl v kvalitě odpovědí je dramatický — často 30–40 % lepší přesnost podle konkrétních dotazníků.
Praktický příklad: interní IT podpora
Pojďme si ukázat reálný scénář. Malá firma má 200 zaměstnanců a IT oddělení jediného člověka. Polovina dotazů: "jak si nastavím VPN", "kde najdu heslo k firemnímu Google Drive", "proč mi nefunguje tiskárna".
Dřívější stav: ticketing systém, průměrná doba odpovědi 4 hodiny, zavalený admin.
Po nasazení knowledge base:
- Všechny interní návody (Notion, 80 stránek) se nahrají a zchunkují.
- Agent (Claude přes API) dostane kontext: firemní název, tón komunikace, fallback na člověka když si není jistý.
- Zaměstnanec napíše "tiskárna na 3. patře netiskne". Agent najde dva relevantní chunky (postup pro restart tiskárny + známý problém s konkrétním modelem) a odpoví konkrétními kroky.
Výsledek: 70 % dotazů vyřeší agent automaticky. Zbytek jde na člověka — ale s plným kontextem, co už se zkoušelo.
Co dělá většina firem špatně
Nejčastější chyby, které vidím:
- Nasadí knowledge base a pak ji neaktualizují. Dokument z února o deploy procesu je v červenci zastaralý. Potřebuješ pipeline, který se přeparse při každé změně zdroje — denně nebo při git push.
- Nechají jednoho chunk obsahovat celou stránku. Výsledek: agent najde "něco", ale ne přesnou odpověď. Správný chunk = jedna konkrétní myšlenka.
- Ignorují českou diakritiku v embeddingech. Pokud tvůj zdroj mixuje "jak" a "jak" bez háčků, embedding model si s tím poradí špatně. Normalizuj předem.
- Měří úspěch podle počtu dotazů, ne podle spokojenosti. 1000 dotazů denně, z nichž 60 % končí frustrovaným uživatelem, není úspěch. Měř "thumbs up" feedback a sleduj trendy.
Kdy začít
Nemusíš stavět celou infrastrukturu hned. Začni s pgvector, jedním zdrojem (Notion nebo wiki) a 50 dokumenty. Otestuj na 20 reálných dotazech z tvého byznysu. Uvidíš během týdne, jestli ti RAG dává hodnotu — nebo jestli je tvůj problém jinde.
Nástroje jako Hubble, který se v červenci 2026 objevil na předních příčkách technických komunit, ukazují, kam to směřuje: knowledge base už není samostatný projekt, je to vrstva, kterou AI agenti potřebují nativně. Firmy, které ji dnes postaví, budou za rok v náskoku. Ty, které čekají, budou dohánět.
