Postavíme RAG (retrieval-augmented generation) nad vašimi dokumenty a strukturovanými daty — s citacemi, audit logem a hlídáním halucinací. Ne AI demo z konference, ale produkční nasazení: guardraily proti prompt injection, cost gate proti utíkajícím nákladům a observabilita každého LLM volání.
Prototyp RAG postavíte za odpoledne s tutoriálem z YouTube. Produkční nasazení, které nehalucinuje, nevynáší cizí data a neutíká v ceně, je jiná disciplína — a tam většina dodavatelů končí.
Na pěti testovacích otázkách odpověď sedí. Ve produkčním provozu s tisíci reálných dotazů model začne domýšlet, co v datech není, nebo odpoví sebejistě špatně — a nikdo to nezachytí, protože chybí audit log a hlídání confidence.
Prompt injection z uživatelského vstupu nebo z indexovaného dokumentu dokáže obejít instrukce a vytáhnout data, ke kterým by se odpověď neměla dostat. Bez explicitních guardrailů a nízké teploty na faktické dotazy to není otázka jestli, ale kdy.
Bez cost gate a bez rozmyslu nad tím, kdy volat drahý model a kdy stačí levnější, náklady na LLM volání rostou lineárně s provozem a nikdo je nehlídá — dokud nepřijde faktura, co bolí.
Retrieval, generování a provoz řešíme jako produkční systém od prvního řádku — ne jako proof-of-concept, který se pak musí předělat, aby vůbec šel nasadit.
Kombinace sémantického vyhledávání (embeddings + vektorová databáze) a klasického keyword matchingu, aby odpověď našla i to, co čistě sémanticky nesedí — přesná čísla, kódy, jména.
Kde jsou data strukturovaná (databáze, tabulky), generujeme dotazy přímo, s automatickou opravou, když dotaz selže nebo vrátí prázdný výsledek — místo aby asistent jen "hádal" z textového popisu dat.
Nízká teplota pro faktickou přesnost, explicitní hranice mezi instrukcemi a daty, a human-in-the-loop na hraničních případech, kde si systém není jistý — stejný princip jako u naší AI extrakce dat z faktur.
Každé LLM volání je zalogované — co šlo dovnitř, co přišlo ven, z jakého zdroje odpověď čerpala. Uživatel vidí citaci, vy vidíte auditní stopu, když je potřeba zpětně dohledat, proč asistent odpověděl, jak odpověděl.
Volíme model podle náročnosti dotazu, používáme prompt caching (Anthropic) na opakující se kontext, a hlídáme náklady, aby neutíkaly s rostoucím provozem — místo jednoho draze naúčtovaného modelu na všechno.
U komplexnějších multi-agentních systémů (jako municipální chatbot pro Zlín) jsou flow a agenti definovaní jako řádky v databázi, ne v kódu — logiku lze upravit bez redeploy, což zkracuje iterační cyklus na týdny místo měsíců.
Pro město Zlín jsme postavili multi-agentní swarm engine s self-healing text-to-SQL dotazy — jeden z prvních živých občanských AI chatbotů svého druhu v Česku, který vyhrál regionální AI hackathon. Pro zpracování faktur jsme nasadili AI extrakci dat s human-in-the-loop kontrolou na hraničních případech. Pro Continero (Robootec) jsme postavili vlastní vektorové vyhledávání nad OpenAI embeddings a pgvector, multi-provider LLM orchestraci (Claude/OpenAI/Gemini/Grok) s Anthropic prompt cachingem, vlastní MCP server a lokální ONNX inferenci — když se cloud nehodí.
Řekněte nám, jaká data má asistent znát a k čemu má sloužit — podpora, interní znalostní báze, nebo něco jako občanský chatbot. Navrhneme architekturu (retrieval, guardraily, cost gate) a řekneme upřímně, co je reálné za jaký čas a rozpočet.
Poptat RAG asistenta →