Chatbot nad firemními dokumenty: jak odpovídá z vašich dokumentů

Chatbot nad firemními dokumenty odpovídá tak, že k otázce nejdřív vyhledá v předem zpracovaných dokumentech několik úseků textu a tabulek a teprve ty předá jazykovému modelu. Model odpoví jen z nich a ke každému tvrzení přidá odkaz na dokument a stranu, takže si odpověď ověříte jedním kliknutím. Kvalitu odpovědí víc než volba modelu určuje příprava dokumentů a vyhledávání.

Celý postup si můžete vyzkoušet v demu chatbota nad veřejnými dokumenty pro výrobu. Na záložce „Veřejné dokumenty pro výrobu“ odpovídá ze 14 PDF (statistiky ČSÚ, cenové výměry ERÚ, výzvy OP TAK, předpisy o BOZP, závěry BAT), dohromady 860 stran. U každého zdroje ukáže náhled strany, ze které čerpal. Druhá záložka odpovídá z obsahu tohoto webu.

Čísla v článku jsem naměřil na tomto demu a na asistentovi, kterého jsem postavil pro distributora techniky.

Jak chatbot odpovídá z dokumentů

Chatbot nad dokumenty používá postup RAG (retrieval-augmented generation): program vyhledá relevantní text a jazykový model z něj sestaví odpověď. Model tedy odpovídá z úseků, které mu dodáte, a jeho obecné znalosti zůstávají stranou. Postup popsali Lewis a kolegové v roce 2020.

V demu probíhá jedna otázka takto:

1. Embedding otázky. Otázka se převede na číselný vektor (embedding), který zachycuje její význam.
2. Hledání podle významu. Databáze najde úseky s nejpodobnějším vektorem. Používám PostgreSQL s rozšířením pgvector.
3. Hledání podle slov. Fulltext najde úseky se stejnými slovy, typicky název veličiny, číslo předpisu nebo označení výrobku.
4. Spojení výsledků. Obě pořadí se sloučí metodou RRF (reciprocal rank fusion): úsek, který je vysoko v obou seznamech, skončí nahoře. V korpusu dokumentů jde do modelu 8 textových úseků a 4 tabulky.
5. Odpověď s citacemi. Model dostane úseky s čísly a pokyn odpovídat jen z nich. Za tvrzení dá číslo zdroje a stranu, například „540 mil. Kč [1] (s. 1)“.

Když vyhledávání nic použitelného nenajde, chatbot to má říct. Odpověď bez zdroje si uživatel ověřit nemůže, a proto ji chatbot nemá psát.

Příprava dokumentů rozhoduje víc než model

Kvalitu odpovědí z větší části určí to, co se stane s dokumenty před prvním dotazem. Model odpoví dobře jen z úseku, který vyhledávání najde, a vyhledávání najde jen text, který převod z PDF zachoval.

Dokumenty pro demo jsem zpracoval nástrojem Docling. Ten z PDF přečte rozvržení strany, pořadí čtení a strukturu tabulek a uloží výsledek jako markdown. Každá strana nese značku s původním číslem strany, aby chatbot uměl citovat. Převod běží jednou předem na mém počítači, ne na serveru, protože stovky stran trvají desítky minut.

Text dělím po nadpisech na úseky do 2 000 znaků s překryvem 300 znaků. Tabulku nechávám celou až do 6 000 znaků a delší dělím po řádcích, přičemž každý kus dostane záhlaví sloupců. Každý úsek začíná názvem dokumentu a kapitoly. Ze 14 dokumentů vzniklo 2 238 úseků, z toho 857 z tabulek.

Převod jsem kontroloval třemi způsoby:

• Kontrola čísel. Skript porovná čísla z převedených tabulek s textovou vrstvou PDF na téže straně. U ostatních dokumentů vyšla shoda 99,2 až 100 %, u příručky NIST SP 811 jen 97,7 %. Kontrola ukáže poškozené číslo, ale nepozná, že správné číslo stojí ve špatné buňce.
• Ruční kontrola tabulek. 20 tabulek jsem porovnal s vykreslenou stranou PDF buňku po buňce. 17 sedělo, 3 byly chybné a všechny z NIST SP 811: dvě tabulky slité do jednoho řádku, jedna s rozházenou strukturou.
• Zkušební dotazy. Až dotaz do hotového indexu ukázal, že Docling u některých písem vrací jiné znaky, například „spotĜeba“ místo „spotřeba“. Kontrola čísel to nezachytila, čísla byla v pořádku. Opravu jsem udělal pravidly pro konkrétní dokumenty a ověřil porovnáním s textovou vrstvou PDF.

U vašich dokumentů počítejte s podobnými nálezy. Naskenované PDF bez textové vrstvy musí nejdřív projít OCR, jinak je pro chatbota prázdné. Starší verze návodu ve stejné složce chatbot neodliší od platné, pokud mu to neřeknete metadaty nebo výběrem souborů.

Tabulky a čísla: kde chatbot chybuje nejčastěji

Ve výrobě leží odpovědi často v tabulkách: limity, parametry, ceny, alokace dotací. Na tabulkách se chatbot také nejčastěji splete, protože tabulka bez záhlaví ztratí význam čísel a dotaz v běžné řeči se slovům v tabulce podobá málo.

Z demu mám tři konkrétní případy:

Když chcete chatbota nad technickými listy nebo ceníky, ověřte ho na otázkách, jejichž odpověď leží v tabulce. Otázky na souvislý text procházely v demu bez potíží a o tabulkách vám nic neřeknou.

Hledání podle významu i podle slov

Samotné vyhledávání podle významu nestačí. Embedding dobře najde úsek, který říká totéž jinými slovy, ale u přesných označení, čísel norem a zkratek často mine. Fulltext se chová opačně. Proto v demu běží obě hledání a výsledky spojuje RRF.

RRF dá každému úseku body podle jeho pořadí v každém seznamu (1 / (60 + pořadí)) a body sečte. Konstantu 60 používám podle doporučení z dokumentace Microsoftu k hybridnímu vyhledávání. Výhoda: metoda nepotřebuje porovnávat skóre, která mají u fulltextu a u vektorů úplně jiné rozsahy.

Čeština přidává jednu komplikaci: slova se ohýbají. Fulltext proto hledá kmeny slov bez diakritiky a stačí mu shoda v jednom z nich. Dotaz v přirozené větě by se jinak se slovy v dokumentu nepotkal. Když fulltext nenajde nic, nastoupí podobnost podle trojic písmen.

Citace až na stranu dokumentu

Každá odpověď má odkazovat na dokument a stranu, ze které vychází. Bez toho uživatel nepozná, jestli model číslo opsal, nebo si ho domyslel.

V demu se zdroje číslují po stranách, ne po dokumentech. Zdroj je jeden řádek: název dokumentu s odkazem do PDF přímo na danou stranu, číslo strany a vydavatel. Ikona oka otevře náhled strany, takže číslo z odpovědi najdete v originální tabulce bez stahování PDF. Technik pak nemusí chatbotu věřit naslepo, číslo si zkontroluje na straně.

Citace mají ještě jeden účel. Když chatbot cituje špatný dokument nebo starou verzi, uvidíte to hned v odpovědi.

Jak měřím, jestli chatbot odpovídá správně

Kvalitu měřím testovací sadou: seznamem otázek, ke kterým znám správnou odpověď a zdrojový dokument. Chatbot sadu projde přes skutečné API a skript kontroluje, jestli odpověď obsahuje očekávané číslo a jestli cituje správný dokument.

Sada pro dokumenty v demu má 9 otázek. Osm se ptá na číslo z tabulky (podíl podniků používajících AI, alokace výzvy, expoziční limity, spotřeba energie podle BAT, index cen). Devátá je mimo dokumenty („Jaká jsou pravidla stolního fotbálku?“) a chatbot ji musí odmítnout. Na produkci prochází 8 z 9. Neprojde otázka na index cen z ročenky, protože ji vyhledávání nenajde (viz tabulka výše).

Devět otázek je malý vzorek a o přesnosti na tisících dotazů nic neříká. Slouží jako pojistka: po každé změně dělení na úseky, promptu nebo modelu sadu pustím znovu. Změna, po které výsledek klesne, do provozu nejde. U firemního chatbota stavím sadu z otázek, které lidé ve firmě opravdu kladou, a čím víc jich je, tím dřív se ukáže, že úprava pro jeden typ otázek jiný zhoršila.

Varianty: SharePoint, web, ERP

Princip zůstává stejný, liší se zdroj dokumentů a to, kdo smí co vidět.

Stav skladu, otevřené zakázky nebo tržby za měsíc do indexu dokumentů nepatří, protože se mění každý den. Na ně se asistent zeptá ERP přes nástroj, který vrátí aktuální čísla, a dokumenty zůstanou na návody a předpisy.

Co rozhodnout před nasazením

Před stavbou chatbota nad firemními dokumenty rozhodněte čtyři věci:

1. Které dokumenty do indexu patří. Jen schválené verze, bez konceptů a osobních složek. Seznam dokumentů bez textové vrstvy vám ukáže, kde je potřeba OCR.
2. Kdo smí co vidět. Pokud mají různí lidé přístup k různým dokumentům, musí to platit už ve vyhledávání, ne až při zobrazení odpovědi.
3. Kam odcházejí data. V demu počítá embeddingy OpenAI a odpovídá model Claude od Anthropicu. Celé dokumenty projdou službou pro embeddingy jednou při indexaci, do jazykového modelu jde při dotazu jen několik nalezených úseků. Poskytovatele a smluvní podmínky vyberte podle toho, jak citlivé dokumenty jsou.
4. Jak se chatbot brání pokynům v dokumentech. OWASP popisuje nepřímý prompt injection: útočník upraví dokument v úložišti a text v něm se pokusí změnit chování modelu. Prompt v demu proto říká, že úryvky i otázky jsou data, ne pokyny. Úplnou ochranu to nedává, proto do indexu patří jen dokumenty z důvěryhodných zdrojů.

Pro představu o nákladech: embeddingy pro celý korpus 860 stran stály na produkci 0,146 USD. Jedna otázka v demu nad obsahem webu stála při měření 26. 10. 2026 kolem 0,019 USD. U vašich dokumentů bude cena záviset na jejich objemu, zvoleném modelu a délce odpovědí.

Z mé praxe

Pro distributora techniky jsem postavil AI asistenta nad technickou dokumentací: 408 dokumentů rozdělených na 12 489 úseků, hybridní vyhledávání a tabulky prohledávané zvlášť od textu. Demo na tomto webu z jeho kódu vychází, jen bez přihlášení a oprávnění. Regresní sada otázek je tam podmínkou každého nasazení.

Patnáct let jsem pracoval ve výrobě, v kvalitě a ve vývoji procesů. Pracovní postupy, specifikace a protokoly znám z pohledu člověka, který v nich hledá odpověď u linky. Proto u chatbota začínám otázkami, které lidé ve firmě opravdu kladou, a teprve podle nich volím, jak dokumenty zpracovat.

Pokud chcete chatbota nad vlastní dokumentací, nejdřív si vyzkoušejte, jak demo cituje zdroje na stranu, a pak mi napište, kde máte dokumenty uložené a na co se lidé ptají.