Agentní RAG chatbot, bonus: Případová studie

V deseti dílech tohoto seriálu jsem vám ukázal, jak postavit agentní RAG systém od základů. Teorie, architektura, kód. Ale jedna věc je nakreslit plán mrakodrapu. Druhá je ten mrakodrap postavit, nastěhovat do něj tisíc lidí a přežít první zimu. Dnes vám ukážu, jak vypadá celá ta cesta v praxi. Bez příkras, bez marketingového pozlátka. Reálný projekt, reální uživatelé, reálné problémy.

Než začnu, důležitá poznámka. Z důvodu NDA nemohu uvést konkrétní firmu ani obor. Všechna čísla jsou zaokrouhlená a některé detaily záměrně zobecněné. Ale architektura, problémy a poučení jsou autentické.

Zadání: Tisíc lidí, jeden mozek

Střední firma. Přes 1 000 aktivních uživatelů napříč pobočkami v celé republice. Obchodníci, manažeři, backoffice. Každý den řeší desítky dotazů typu: Jaké jsou aktuální podmínky produktu X? Co říká interní směrnice o situaci Y? Jak se liší náš postup od konkurence?

Odpovědi existovaly. Byly rozesety ve 300+ interních dokumentech, desítkách videí z porad a školení a v hlavách pár klíčových lidí, kteří ve firmě pracovali patnáct let.

Požadavek klienta byl jednoduchý: chceme AI asistenta, který tohle všechno ví. Asistenta, kterému se můžete zeptat normální českou větou a dostanete přesnou odpověď s odkazem na zdroj. Ne vyhledávací pole, wikipedii ani FAQ. Digitálního experta, který rozumí kontextu.

Architektura: Co jsem postavil

Pokud jste četli předchozí díly, poznáte jednotlivé vrstvy. Tady je, jak vypadají v praxi na jednom místě.

Datový pipeline

Klíčem bylo zpracování heterogenních zdrojů. Firma měla data v běžných formátech, ale na různých místech a vzájemně nepropojené vazby.

• Interní dokumenty (PDF, MD, DOC) tvořily jádro znalostní báze
• Videa (YouTube a Zoom záznamy) procházela přes automatickou transkripci a následný chunking
• Data z interního systému se synchronizovala přes API v pravidelných intervalech

Celý pipeline musel fungovat automaticky. Když někdo v interním systému aktualizoval dokument, webhook spustil reimport do databáze. Žádné ruční nahrávání, žádné čekání. Znalostní báze byla vždy aktuální.

Výsledek: přes 3 500 chunků v grafové databázi Neo4j, propojených vztahy na kategorie, produkty a klíčová slova. Ne plochý seznam textů, ale síť znalostí (viz díl o GraphRAG).

Vyhledávání: Pět vrstev hybridního searche

Jednoduchý vektorový search nestačí. V praxi jsem implementoval pětistupňový hybridní search, který kombinuje:

1. Vektorový search na úrovni chunků (nejpřesnější, nejpomalejší)
2. Vektorový search na úrovni sekcí (zachytí širší kontext)
3. Vektorový search na úrovni dokumentů (pro obecné dotazy)
4. Textový fulltext fallback (přesné termíny, které embedding zprůměruje)
5. Fulltext na úrovni sekcí (poslední záchranná síť)

Paralelní vrstvy

Všech pět vrstev běží paralelně. Výsledky se slévají přes boost scoring systém, který zohledňuje shodu v titulku, textu, kategorii a typu dokumentu. Teprve pak nastupuje graph enhanced search, který přes vztahy v Neo4j dohledá související dokumenty, na které se uživatel explicitně neptal, ale které jsou relevantní (princip multi-hop inference z dílu 7).

Multi-agentní systém

Dotaz uživatele nejde rovnou do RAG pipeline. Nejdřív projde přes router agenta (viz díl 8), který klasifikuje záměr.

Většina dotazů jde do knowledge agenta. Ale pozdrav zpracuje konverzační agent. Výpočet zpracuje kalkulátor. A dotaz na novinky z trhu se přesměruje na dedikovaného agenta, který čte data z API interního systému.

Router funguje ve dvou vrstvách. Pattern-based klasifikace (rychlá, deterministická) chytí jednoznačné případy. Pro nejednoznačné dotazy nastupuje LLM fallback s teplotou 0.0, který rozhodne sám.

Paměť

Systém si pamatuje preference uživatele napříč konverzacemi. Pokud vám jednou řeknu, že pracuji na pobočce v Brně a zajímám se o produkt X, příště už vám AI automaticky filtruje odpovědi podle tohoto kontextu.

Důležitý designový princip: paměť ukládá výhradně uživatelské preference, nikdy fakta ze znalostní báze. Znalostní báze se mění, ale vaše preference jsou stabilní. Toto oddělení (popsané v dílu 4) eliminuje celou kategorii halucinací.

Odolnost: Fallback chain přes tři poskytovatele

Produkční systém pro 1 000+ uživatelů nemůže záviset na jednom API. Implementoval jsem automatický fallback chain přes tři nezávislé poskytovatele AI modelů. Pokud primární model selže, systém se transparentně přepne na záložní. Uživatel si ničeho nevšimne.

Za celou dobu provozu nedošlo k jedinému výpadku, který by uživatelé zaregistrovali, přestože jednotliví poskytovatelé měli výpadky opakovaně.

Co nefungovalo: Chyby a poučení

Teď ta zajímavá část. Co se v praxi rozbilo a co mě to naučilo.

Chunking: Největší past celého RAG

V prvním díle jsem psal o tom, jak důležité je správně rozdělit dokumenty na části. V praxi to bylo ještě horší, než jsem čekal.

Problém: Dokumenty obsahovaly tabulky, víceúrovňové nadpisy a vnořené seznamy. Jednoduchý chunking po 500 tokenech tyto struktury rozbil. Tabulka s ceníkem se rozřízla napůl a AI pak odpovídala s cenou z horní poloviny a podmínkami z dolní, které patřily k úplně jinému produktu.

Řešení: Musel jsem přejít na sémantický chunking, který respektuje strukturu dokumentu. Nadpis a jeho obsah drží pohromadě. Tabulka se nikdy nerozdělí. Seznam zůstane celý. Stálo to extra práci při parsování, ale kvalita odpovědí se zvedla dramaticky.

Embedding: Ne všechny modely rozumí češtině stejně

V díle o databázi jsem psal o volbě embedding modelu. V praxi se ukázalo, že i kvalitní modely mají problém s českými odbornými termíny a zkratkami.

Uživatel napsal zkratku, embedding model ji neznal a vektorový search vrátil irelevantní výsledky. Řešením bylo přidat vrstvu expanze zkratek před embedding. Každý dotaz projde přes slovník firemních zkratek a teprve rozexpandovaná verze se embedduje.

Boost scoring: Umění vyvažování

Pětistupňový hybridní search generuje obrovské množství kandidátních výsledků. Naivní přístup (seber vše, seřaď podle similarity score) nefungoval. Proč? Protože krátký chunk s vysokou podobností často vyhrál nad dlouhým, komplexním dokumentem, který obsahoval skutečnou odpověď.

Musel jsem vybudovat sofistikovaný scoring systém s váhami pro shodu v titulku, textu, kategorii a typu dokumentu. A přidat speciální pravidla, třeba penalizaci pro extrémně dlouhé PDF dokumenty (knihy), které měly tendenci být relevantní ke všemu, ale odpověď na nic konkrétního.

Toto ladění bylo iterativní. Týdny testování s reálnými dotazy uživatelů, analýza případů kde systém selhal a postupné dolaďování vah. Žádný model vám tohle nevyřeší za vás. Je to ruční řemeslo (viz díl o ladění).

Halucinace: Když AI ví moc

V díle o system promptu jsem psal o tom, jak instruovat model, aby neprezentoval vlastní znalosti jako firemní fakta. V praxi se halucinace projevovaly zákeřněji.

Model našel správný dokument, správně ho citoval a pak na konci odpovědi přidal vlastní doporučení, které vypadalo autoritativně, ale nemělo oporu v datech. Uživatel neměl šanci poznat rozdíl.

Řešení: striktní post-processing, který filtruje citace a ověřuje, že každé tvrzení v odpovědi má korespondující zdroj. Plus explicitní instrukce v system promptu, aby model jasně oddělil fakta z databáze od svých vlastních úvah.

Co bych udělal jinak

S odstupem deseti dílů a měsíců ostrého provozu vidím čtyři věci, které bych příště udělal od začátku.

1. Automatizované testování kvality od prvního dne

Celé týdny jsem ladil boost scoring a chunking ručně. Projížděl jsem logy, četl dotazy uživatelů, hledal kde systém selhal. Fungovalo to, ale neškálovalo.

Dnes bych od prvního nasazení měl automatický benchmark z 50+ reálných dotazů s očekávanými odpověďmi. Každá změna v pipeline by se automaticky otestovala proti tomuto benchmarku. Ušetřilo by to desítky hodin manuálního ladění.

2. Placený reranker místo ručního scoringu

Celý boost scoring systém, který jsem popisoval výše, je ruční práce. Váhy pro titulky, texty, kategorie, speciální penalizace pro PDF. Funguje to, ale je to křehké a těžko přenositelné na jiný projekt.

Dnes bych nasadil Cohere Rerank 3.5 jako dedikovanou vrstvu mezi hybridní search a finální výběr výsledků. Reranker vezme kandidátní výsledky z všech pěti vrstev searche a seřadí je podle skutečné sémantické relevance k dotazu. Ne podle ručně nastavených vah, ale podle modelu trénovaného přesně na tuto úlohu. Cena za API volání je zanedbatelná oproti času strávenému laděním ručního scoringu. Toto je největší potenciální zlepšení, které v aktuálním systému vidím.

3. Feedback loop do pipeline

Systém sbíral zpětnou vazbu od uživatelů (palec nahoru/dolů). Ale tato data se zpracovávala ručně. Správně by měla automaticky ovlivňovat scoring. Dokument, který uživatelé opakovaně hodnotí jako nerelevantní, by měl dostat penalizaci. Dokument, který dostává samé palce nahoru, by měl dostat boost.

Toto propojení feedback → scoring je na mém TODO listu. V dalším projektu to bude od začátku.

4. Monitoring s alertingem

Sledoval jsem metriky provozu, ale reaktivně. Věděl jsem, že něco nefunguje, až když si uživatel stěžoval.

Správný přístup: proaktivní monitoring s alerty. Pokud průměrný similarity score odpovědí klesne pod threshold, pokud se zvýší počet odpovědí bez citací, pokud začne failovat některý z fallback modelů, chci vědět okamžitě. Ne až z helpdesku.

Čísla: Co to přineslo

Po šesti měsících ostrého provozu:

• 1 000+ aktivních uživatelů napříč všemi pobočkami
• Přes 90 % adopce v cílové skupině, bez jakéhokoliv příkazu od managementu
• Přesnost odpovědí kolem 76,5 % měřená evaluačním pipeline
• Nadprůměrné hodnocení od uživatelů (palec nahoru/dolů feedback)
• Znalostní báze se automaticky aktualizuje, žádná manuální údržba
• Nulový výpadek viditelný pro uživatele díky fallback chain

6 měsíců, jeden člověk

Celý systém jsem postavil v jednom člověku za méně než půl roku, ve spolupráci s interním IT týmem klienta při napojení na stávající systémy. Přesné finanční úspory zatím spočítané nemáme. Na to potřebujete alespoň rok ostrého provozu a čistá data o tom, kolik dotazů by jinak řešili lidé. Ale jedno číslo mluví za vše: 90 % adopce bez donucení. Když lidé něco používají dobrovolně, šetří to čas. A čas jsou peníze.

Závěr: Co si z toho odnést

Pokud jste dočetli až sem a zároveň celý seriál, máte v hlavě kompletní blueprint. Od zpracování dat přes databázi, ladění, prompty, modely, optimalizaci, GraphRAG, agenty, bezpečnost až po reálný provoz.

Pár univerzálních poučení na závěr:

1. 80 % úspěchu je v datech, ne v modelu. Investujte čas do pipeline, ne do výběru nejnovějšího LLM.
2. GraphRAG není luxus, je to nutnost. Bez vztahů mezi dokumenty je váš systém jen lepší fulltext.
3. Hybridní search poráží čistý vektorový search pokaždé. V praxi potřebujete obojí.
4. Testujte s reálnými uživateli co nejdřív. Žádný benchmark nenahradí tisíc dotazů od lidí, kteří systém skutečně potřebují.
5. Počítejte s chybami. Ne jestli se objeví, ale kdy. Stavějte systém tak, aby se z nich uměl zotavit.

Konec seriálu

Tímto dílem seriál Agentní RAG chatbot končí. Děkuji všem, kteří ho sledovali od začátku. Pokud vás zajímá, jak podobný systém postavit pro vaši firmu, nebo pokud řešíte AI projekt a chcete si ušetřit měsíce pokusů a omylů, ozvěte se mi. Rád pomůžu.

Díly seriálu

• Agentní RAG chatbot 1) Strategie zpracování dat pro RAG
• Agentní RAG chatbot 2) Výběr a architektura databáze
• Agentní RAG chatbot 3) Umění relevance a ladění RAG
• Agentní RAG chatbot 4) Jak napsat perfektní system prompt
• Agentní RAG chatbot 5) Výběr správného motoru a strategie
• Agentní RAG chatbot 6) Pokročilá optimalizace výkonu a nákladů
• Agentní RAG chatbot 7) Síla vztahů a průvodce implementací graphRAG
• Agentní RAG chatbot 8) Tým expertů a agentních systémů v LangGraph
• Agentní RAG chatbot 9) Zabezpečení dat v AI aplikacích
• Agentní RAG chatbot 10) Ladění systému v reálném provozu
• Agentní RAG chatbot, bonus: Případová studie (právě čtete)