Co je vlastně ten velký jazykový model a proč nestačí
Představte si, že máte geniálního kolegu, který přečetl většinu internetu a tisíce knih. Když se ho na něco zeptáte, dokáže vám odpovědět překvapivě chytře. Ale je tu háček – ten kolega žije zavřený v kanceláři bez telefonu, bez přístupu k firemnímu intranetu a bez možnosti udělat cokoli jiného než mluvit. Přesně takový je velký jazykový model, neboli LLM.
LLM (Large Language Model) je základ, na kterém stojí všechno ostatní v dnešním světě umělé inteligence. Když používáte ChatGPT, Claude nebo Gemini, komunikujete právě s jazykovým modelem. Ale samotný model je jen jedna vrstva z celého ekosystému, který se kolem AI buduje. A pochopení toho, kde končí LLM a začíná něco dalšího, je klíčové pro každého, kdo chce AI skutečně využívat – ne jen zkoušet.
V tomhle článku si projdeme čtyři základní vrstvy moderní umělé inteligence: od samotného jazykového modelu přes RAG, AI agenty až po agentní systémy. Každou vrstvu si vysvětlíme tak, abyste pochopili nejen co dělá, ale hlavně proč existuje a kdy ji potřebujete. A pokud jste někde na cestě mezi začátečníkem a pokročilým uživatelem, slibuju, že se nebudete nudit.
LLM: Mozek bez těla
Velký jazykový model je v jádru statistický systém, který se naučil vzorce lidského jazyka z obrovského množství textových dat. Slovo „velký” v názvu odkazuje na počet parametrů – tedy vnitřních proměnných, které model používá k rozhodování. Moderní modely jich mají desítky až stovky miliard. Díky tomu dokáží neuvěřitelně přesvědčivě generovat text, odpovídat na otázky, překládat, psát kód a řešit logické úlohy.
Jak LLM vlastně funguje
Základem každého moderního LLM je takzvaná architektura Transformer. Tu v roce 2017 představil tým výzkumníků z Googlu a od té doby změnila celý obor zpracování přirozeného jazyka. Klíčovou součástí Transformeru je mechanismus pozornosti (Attention Mechanism), který modelu umožňuje při zpracování textu „věnovat pozornost” různým částem vstupu s různou intenzitou. Když vám model odpovídá na otázku o historii České republiky, mechanismus pozornosti zajistí, že se soustředí na relevantní části kontextu, ne na nesouvisející informace.
Než model text vůbec zpracuje, musí ho rozložit na menší jednotky zvané tokeny (tokenizace). Token není totéž co slovo – může to být celé slovo, část slova, nebo dokonce jeden znak. České slovo „nejneobhospodařovávatelnějšími” by se rozložilo na několik tokenů, zatímco anglické „the” je jeden token. Model pak pracuje s těmito tokeny a na základě naučených vzorců generuje odpověď token po tokenu.
Tohle je důležité pochopit: LLM negeneruje celou odpověď najednou. Vytváří ji slovo po slovu (respektive token po tokenu), přičemž každý další token volí na základě všech předchozích. Je to trochu jako když píšete SMS a telefon vám nabízí další slovo – jen mnohonásobně sofistikovanější.
Co LLM umí (a co si myslí, že umí)
Schopnosti jazykového modelu můžeme rozdělit do několika oblastí. Tou nejzákladnější je generování textu (Text Generation) a porozumění přirozenému jazyku (Natural Language Understanding). Model dokáže nejen produkovat srozumitelný text, ale také pochopit význam toho, co mu napíšete – včetně nuancí, kontextu a implicitních sdělení.
Další silnou stránkou je následování instrukcí (Instruction Following). Moderní modely prošly speciálním tréninkem, který je naučil plnit konkrétní pokyny. Můžete modelu říct „napiš e-mail řediteli, ve kterém zdvořile odmítnu nabídku spolupráce” a on to udělá. Tato schopnost je výsledkem fáze trénování zvané RLHF (učení se ze zpětné vazby od lidí) nebo podobných technik.
Fascinující je pak schopnost učení z mála nebo nula příkladů (Few-shot / Zero-shot Learning). Když modelu dáte dva příklady toho, jak má kategorizovat zákaznické stížnosti, dokáže ten vzor aplikovat na stovky dalších. A v mnoha případech zvládne úlohu i bez jediného příkladu – stačí mu jasný popis toho, co má dělat.
Model také disponuje krátkodobou konverzační pamětí (Conversational Memory). V rámci jedné konverzace si pamatuje, o čem jste mluvili. Ale pozor – tato paměť je omezená velikostí takzvaného kontextového okna. Jakmile konverzace přesáhne určitou délku, starší části se „ztratí”. A po skončení konverzace model zapomene úplně všechno. Nemá trvalou paměť – každý nový chat začíná s čistým štítem.
Prompt engineering: Umění správně se zeptat
Kvalita odpovědi jazykového modelu závisí enormně na tom, jak se zeptáte. Tomuto umění se říká prompt engineering (inženýrství dotazů) a je to dnes jedna z nejcennějších dovedností při práci s AI. Dobře formulovaný prompt může být rozdíl mezi vágní, nepoužitelnou odpovědí a přesným, detailním výstupem, který rovnou použijete v praxi.
Prompt engineering není jen o tom napsat delší instrukci. Jde o pochopení toho, jak model přemýšlí, co potřebuje vědět a jak mu strukturovat zadání. Zahrnuje techniky jako definování role modelu, poskytnutí kontextu, specifikace formátu výstupu a zadání omezujících podmínek. Zkušený uživatel dokáže z modelu dostat výrazně lepší výsledky než začátečník – i když oba používají úplně stejný model.
Nicméně je důležité zmínit, že prompt engineering má své limity. Sebelepší prompt nedonutí model vědět něco, co není v jeho tréninkových datech. A ani ten nejsofistikovanější řetěz instrukcí nevyřeší fundamentální problém halucinací. Proto je prompt engineering mocný nástroj, ale není to řešení všeho – a právě tady přichází ke slovu další vrstvy, o kterých si povíme.
Řetězec úvah: Když model přemýšlí nahlas
Jednou z technik, která výrazně zlepšila schopnosti LLM, je takzvaný řetězec úvah (Chain-of-Thought reasoning). Místo toho, aby model rovnou vyskočil s odpovědí, „přemýšlí” krok za krokem. Když se ho zeptáte, kolik jablek zbude po třech nákupech a dvou prodejích, model si nejprve rozepíše jednotlivé operace a teprve pak dojde k výsledku. Tato technika dramaticky zvyšuje přesnost u složitějších úloh.
Poslední důležitou schopností, o které se tu zmíním, je generování embeddingů (Embedding Generation). Model dokáže převést text na číselnou reprezentaci – vektor – který zachycuje jeho význam. Dva texty s podobným významem budou mít podobné vektory, i když používají úplně jiná slova. Tato schopnost je klíčová pro další vrstvu, o které si povíme za chvíli.
Kde LLM nestačí
A tady se dostáváme k zásadnímu omezení. LLM pracuje pouze s tím, co se naučil během trénování. Jeho znalosti mají konkrétní datum – takzvaný knowledge cutoff. Cokoli se stalo po tomto datu, model jednoduše neví. Nemůže si ověřit fakta, nemá přístup k aktuálním datům a nemá tušení, co je ve vaší firemní databázi nebo interních dokumentech.
Navíc má model tendenci k takzvaným halucinacím – situacím, kdy si s naprostou sebejistotou vymyslí informaci, která není pravdivá. Zeptáte se ho na specifický paragraf zákona a on vám ho „ocituje” – včetně čísla paragrafu, které neexistuje. Model totiž nerozlišuje mezi tím, co ví a co neví. Generuje statisticky pravděpodobný text, a někdy je ta pravděpodobnost zavádějící.
A právě proto vznikla další vrstva – RAG.
RAG: Když model dostane přístup ke znalostem
RAG, neboli Retrieval Augmented Generation (generování rozšířené o vyhledávání), řeší jeden z nejpalčivějších problémů jazykových modelů: omezené a zastaralé znalosti. Princip je elegantně jednoduchý – místo toho, abyste se spoléhali jen na to, co se model naučil při trénování, dáte mu možnost „podívat se” do externích zdrojů dat předtím, než odpoví.
Představte si to jako rozdíl mezi studentem, který píše zkoušku z hlavy, a studentem, který může používat poznámky. Ten druhý má pořád stejný mozek a stejné schopnosti přemýšlet, ale jeho odpovědi budou přesnější a aktuálnější, protože vychází z konkrétních dat.
Jak RAG funguje pod kapotou
Celý proces začíná přípravou dat. Vaše dokumenty – ať už jde o interní wiki, PDF manuály, databázi zákaznických dotazů nebo cokoli jiného – se nejprve rozřežou na menší části. Tomuto procesu se říká rozdělování dokumentů (Document Chunking). Proč? Protože model nemůže zpracovat celou knihu najednou a navíc potřebuje najít přesně tu relevantní pasáž, ne celý dokument.
Každý takový kus textu se pak převede na již zmíněný embedding – číselnou reprezentaci jeho významu. Tyto embeddingy se uloží do speciální databáze zvané vektorová databáze. A právě tady začíná kouzlo vektorového vyhledávání (Vector Search).
Když položíte otázku, systém ji také převede na embedding a porovná ji se všemi uloženými vektory. Hledá ty, které jsou si významově nejbližší – tomu se říká bodování podobnosti (Similarity Scoring). Výsledkem je seznam nejrelevantnějších pasáží z vašich dokumentů, které se pak „vloží” do kontextu pro jazykový model. Model tak dostane k dispozici konkrétní informace, ze kterých může čerpat při formulování odpovědi.
Vyhledávací pipeline a jeho sofistikace
V praxi není RAG jen jednoduché vyhledání a vložení. Moderní systémy používají celé vyhledávací pipeline (Retrieval Pipelines) – sekvence kroků, které zajistí co nejvyšší kvalitu výsledků.
Jedním z důležitých kroků je reformulace dotazu (Query Reformulation). Lidé často formulují otázky vágně nebo používají jiná slova, než jaká jsou v dokumentech. Systém proto může váš dotaz přeformulovat do několika variant, aby pokryl různé způsoby, jakými může být relevantní informace vyjádřena. Když se zeptáte „jak říct zaměstnanci, že končí”, systém může hledat i varianty jako „výpověď”, „ukončení pracovního poměru” nebo „propouštění”.
Dalším důležitým prvkem je hybridní vyhledávání (Hybrid Search), které kombinuje dva přístupy: husté (dense) a řídké (sparse) vyhledávání. Husté vyhledávání pracuje s embeddingy a zachycuje sémantický význam – najde relevantní výsledky, i když se klíčová slova neshodují. Řídké vyhledávání (typicky BM25 nebo TF-IDF) hledá na základě přesné shody slov. Kombinace obou přístupů dává mnohem lepší výsledky než každý zvlášť.
Filtrování metadat (Metadata Filtering) pak umožňuje výsledky dále zpřesnit. Můžete omezit vyhledávání jen na dokumenty z posledního roku, jen na konkrétní oddělení, jen na určitý typ dokumentu. Metadata fungují jako předfiltr, který zúží prostor pro sémantické vyhledávání.
Správa indexů a integrace znalostní báze
Správa indexů (Index Management) je téma, které se řeší hlavně v produkčním nasazení, ale je dobré o něm vědět. Index je v podstatě ta vektorová databáze, ve které jsou uloženy embeddingy vašich dokumentů. Musíte řešit, kdy a jak aktualizovat index, když se dokumenty změní, jak mazat zastaralé verze a jak zajistit, aby index nebyl příliš velký nebo příliš malý.
Integrace vlastní znalostní báze (Custom Knowledge Base Integration) je to, co dělá RAG tak mocným nástrojem pro firmy. Místo generického modelu, který ví všechno o ničem specifickém, máte najednou systém, který zná vaše produkty, vaše procesy, vaši dokumentaci. A to bez nutnosti přetrénovat celý model, což by stálo miliony a trvalo týdny.
Důležitým aspektem je také uvádění zdrojů (Source Attribution). Kvalitní RAG systém nejen že najde relevantní informace, ale také uvede, odkud je vzal. Díky tomu si můžete odpověď ověřit a zjistit, ze kterého konkrétního dokumentu nebo pasáže informace pochází. To je zásadní pro budování důvěry v systém a pro situace, kdy potřebujete odpověď dohledat nebo verifikovat.
Vkládání kontextu: Jak se informace dostanou k modelu
Vkládání kontextu (Context Injection) je mechanismus, kterým se nalezené informace dostanou do promptu pro jazykový model. Zní to jednoduše, ale v praxi jde o sofistikovaný proces. Musíte rozhodnout, kolik kontextu poskytnout (příliš málo = nepřesná odpověď, příliš mnoho = zahlcení modelu), v jakém pořadí informace seřadit a jak je strukturovat, aby model pochopil, co je kontext a co je otázka.
Kvalitní context injection umí také prioritizovat – důležitější pasáže dostanou více prostoru, méně relevantní se zkrátí nebo vynechají. V kombinaci s omezenou velikostí kontextového okna je toto rozhodování klíčové pro kvalitu výsledné odpovědi.
Embedding modely: Tiší hrdinové RAG systémů
Celý RAG stojí a padá s kvalitou embedding modelů. Ty převádějí text na vektory, a pokud to dělají špatně, celý systém selže. Existují desítky embedding modelů s různými vlastnostmi – některé jsou lepší pro krátké dotazy, jiné pro dlouhé dokumenty, některé fungují lépe v češtině, jiné v angličtině.
Zajímavé je, že embedding modely jsou oddělené od generativních modelů. Můžete používat embedding model od jedné firmy a generativní model od druhé. V praxi to znamená, že RAG systém se skládá z více komponent, které spolu musí dobře spolupracovat – od chunkování přes embeddingy a vyhledávání až po samotnou generaci odpovědi.
Kde se LLM a RAG potkávají
Kombinace LLM a RAG není jen součet dvou technologií – vzniká něco kvalitativně nového. Průnik těchto dvou vrstev přináší schopnosti, které ani jedna z nich nemá samostatně.
Snížení halucinací a podložené odpovědi
Nejvýznamnějším přínosem je snížení halucinací (Reduced Hallucination). Když model odpovídá na základě konkrétních dokumentů, má mnohem menší tendenci si vymýšlet. Místo toho, aby generoval „statisticky pravděpodobnou” odpověď z tréninkových dat, čerpá z konkrétních zdrojů. Výsledkem jsou odpovědi založené na znalostech (Knowledge-Grounded Responses), které můžete ověřit.
Vzniká také kontextuální generování (Contextual Generation) – schopnost modelu přizpůsobit odpověď nejen otázce, ale i kontextu načtených dokumentů. Model nebude odpovídat obecně, ale specificky s ohledem na vaše data. Když se zeptáte na reklamační proces, nedostanete obecnou odpověď o reklamacích, ale přesný postup podle vašeho firemního manuálu.
Klíčovým konceptem je fúze promptu a vyhledávání (Prompt + Retrieval Fusion). Váš dotaz a nalezené dokumenty se spojí do jednoho vstupu pro model, který pak musí informace syntézovat a formulovat koherentní odpověď. Tohle je sofistikovanější, než to zní – model musí rozpoznat, které části nalezených dokumentů jsou relevantní, jak je propojit a jak z nich vytvořit srozumitelnou odpověď.
Generování podložených odpovědí (Grounded Answer Generation) je výsledkem celého procesu – odpovědi, které jsou „ukotvené” v konkrétních datech. Na rozdíl od volného generování, kde model může sklouznout k halucinacím, podložené odpovědi mají jasný základ v dodaných dokumentech.
Srovnávání embeddingů (Embedding Comparison) pak hraje roli nejen při vyhledávání, ale i při ověřování – systém může porovnat embedding vygenerované odpovědi s embeddingy zdrojových dokumentů a ověřit, zda odpověď skutečně vychází z nalezených informací.
AI Agent: Když model dostane ruce
Až dosud jsme mluvili o systémech, které umí přemýšlet a vyhledávat informace. Ale co když potřebujete, aby AI nejen odpovídala, ale také jednala? Aby poslala e-mail, aktualizovala tabulku, zavolala API, vyhledala na webu nebo spustila kód? Přesně to je doména AI agentů.
AI agent je systém postavený na jazykovém modelu, který má navíc schopnost používat nástroje (Tool Use & API Calling). Zatímco LLM je mozek a RAG je knihovna, agent je zaměstnanec, který má mozek, přístup do knihovny a navíc může chodit po kanceláři, používat počítač a komunikovat s kolegy.
Plánování a dekompozice úkolů
Aby agent mohl efektivně jednat, musí umět plánovat (Planning & Execution). Když mu řeknete „připrav mi report o prodejích za poslední kvartál a pošli ho týmu”, musí tento úkol rozložit na dílčí kroky. Tomu se říká dekompozice úkolů (Task Decomposition).
Agent si v tomto případě naplánuje: 1) najít data o prodejích, 2) zpracovat je do reportu, 3) najít e-maily členů týmu, 4) odeslat e-mail s reportem. Každý krok může vyžadovat jiný nástroj – databázový dotaz, generování dokumentu, vyhledání kontaktů, odeslání e-mailu.
Jedním z nejpoužívanějších přístupů k plánování je ReAct framework (Reason + Act). Agent střídá fáze uvažování a akce: nejprve přemýšlí o tom, co je potřeba udělat (Reason), pak provede konkrétní akci (Act), pozoruje výsledek, znovu přemýšlí a podle potřeby akci upraví. Tento cyklus se opakuje, dokud není úkol splněn.
Zpětné vazby a sledování stavu
Zpětné vazby (Feedback Loops) jsou to, co odlišuje inteligentního agenta od jednoduchého skriptu. Když agent odešle API požadavek a dostane chybovou odpověď, nezhroutí se. Místo toho analyzuje chybu, upraví svůj přístup a zkusí to znovu. Nebo zjistí, že potřebuje jiný nástroj, a přepne strategii.
S tím souvisí sledování stavu úkolů (Task State Tracking). Agent si musí pamatovat, kde v procesu se nachází, které kroky už dokončil, které čekají a které selhaly. Bez tohoto sledování by se snadno ztratil v komplexnějších úkolech a opakoval by kroky nebo přeskakoval důležité části.
Práce se soubory a spouštění kódu
Dvě schopnosti, které z agentů dělají skutečně praktické nástroje, jsou přístup k souborům (File Access/Interaction) a spouštění kódu (Code Execution).
Agent může číst CSV soubory s daty, upravovat Excel tabulky, procházet PDF dokumenty nebo vytvářet nové soubory. V kombinaci se schopností spouštět kód se otevírají obrovské možnosti – agent může napsat Python skript pro analýzu dat, spustit ho, interpretovat výsledky a prezentovat je ve srozumitelné formě.
Představte si, že máte tabulku s tisíci řádky zákaznických dat a potřebujete zjistit trendy v chování zákazníků. Agent přečte soubor, napíše analytický skript, spustí ho, vygeneruje grafy a shrne klíčové závěry – to všechno bez toho, abyste museli otevřít Excel nebo psát kód.
Integrace paměti: Krátkodobá a dlouhodobá
Na rozdíl od základního LLM, který má jen krátkodobou konverzační paměť, AI agent může mít integraci paměti (Memory Integration) jak krátkodobé, tak dlouhodobé. Krátkodobá paměť mu umožňuje sledovat průběh aktuálního úkolu. Dlouhodobá paměť pak uchovává informace napříč konverzacemi – vaše preference, historii interakcí, naučené postupy.
Díky dlouhodobé paměti se agent může postupně „učit” vaše zvyklosti. Zjistí, že reporty preferujete v určitém formátu, že určité typy úkolů řešíte vždy stejným způsobem, a příště vám rovnou nabídne optimální postup.
Průniky, které dávají celku smysl
Než se posuneme k agentním systémům, je důležité si uvědomit, že jednotlivé vrstvy se vzájemně prolínají. Některé schopnosti žijí na pomezí dvou nebo i více vrstev.
Kde se potkávají RAG a AI Agent
Kombinace RAG a AI agenta vytváří systém, který nejen vyhledává informace, ale také na jejich základě jedná. Klíčovým konceptem je pipeline pro vyhledávání a exekuci (Retrieval & Execution Pipeline). Agent nejprve vyhledá relevantní informace v znalostní bázi a pak na jejich základě provede akci.
Například: zákaznický servis agent obdrží dotaz, vyhledá relevantní informace v produktové dokumentaci (RAG), a pokud zjistí, že jde o reklamaci, rovnou založí ticket v systému (agent). Nebo finanční agent najde relevantní data v interních reportech a na jejich základě vygeneruje a odešle shrnutí.
Plánování dotazů (Query Planning) je sofistikovaná schopnost, kdy agent nepošle do RAG systému jeden dotaz, ale naplánuje sérii dotazů, které postupně zpřesňují hledání. Nejprve se zeptá obecně, na základě výsledků zúží hledání a nakonec získá přesně ty informace, které potřebuje.
Dlouhodobá kontextová paměť (Long-Term Context Memory) na pomezí RAG a agenta umožňuje systému pamatovat si nejen fakta, ale i kontext, ve kterém byly použity. Agent si zapamatuje, že minule jste se ptali na konkrétní projekt, a příště automaticky zahrne do vyhledávání i související informace.
Textová volání specifická pro doménu (Domain-Specific Text Calls) pak představují schopnost agenta komunikovat se specializovanými systémy pomocí přirozeného jazyka – například zadávat dotazy do právní databáze nebo lékařského informačního systému způsobem, který odpovídá terminologii daného oboru.
Na pomezí RAG a agenta také stojí akce rozšířená o externí data (External Data Augmented Action). Agent nejedná naslepo – svá rozhodnutí podkládá daty z externích zdrojů. Než pošle zákazníkovi odpověď, ověří si aktuální stav objednávky v databázi. Než navrhne strategii, podívá se na nejnovější analytická data.
Kde se potkávají všichni tři: LLM, RAG a AI Agent
Existují tři fundamentální schopnosti, které prostupují napříč všemi vrstvami a jsou nezbytné pro fungování celého ekosystému. Toto jsou koncepty, které najdete v samém středu celého schématu – tam, kde se překrývají všechny kruhy:
Kontext (Context) je schopnost pracovat s okolnostmi a souvislostmi. Pro LLM je kontext text v konverzačním okně. Pro RAG jsou kontextem nalezené dokumenty. Pro agenta je kontextem stav úkolu, dostupné nástroje a historie interakcí. Pro agentní systém pak celková situace všech agentů a jejich sdílený stav. Bez kontextu by žádná z těchto vrstev nemohla fungovat smysluplně – a proto kontext prostupuje úplně vším.
Uvažování (Reasoning) je schopnost logicky propojovat informace a vyvozovat závěry. LLM uvažuje při generování odpovědí. RAG systém uvažuje při výběru relevantních dokumentů. Agent uvažuje při plánování kroků. A agentní systém uvažuje při koordinaci celého týmu agentů. Kvalita uvažování je tím, co odlišuje dobrý AI systém od průměrného.
Sémantické porozumění (Semantic Understanding) je schopnost chápat význam, ne jen slova. Když napíšete „mám problém s fakturací”, sémantické porozumění zajistí, že systém pochopí, že jde o platební potíže, ne o problém s PDF souborem. Tato schopnost je základem pro vyhledávání, plánování i generování odpovědí – a proto je sdílená napříč všemi vrstvami.
Tyto tři schopnosti jsou tak fundamentální, že si je často ani neuvědomujeme. Jsou jako vzduch – všudypřítomné a nezbytné. Každá nová vrstva je využívá jiným způsobem, ale žádná se bez nich neobejde.
Agentic AI: Orchestr bez dirigenta
A teď se dostáváme k tomu nejpokročilejšímu, co dnes v AI existuje. Agentní AI (Agentic AI) je vrstva, která stojí nad jednotlivými agenty a umožňuje jim spolupracovat, koordinovat se a řešit komplexní úkoly s vysokou mírou autonomie.
Rozdíl mezi AI agentem a agentním systémem je jako rozdíl mezi jedním zaměstnancem a celým oddělením. Jeden zaměstnanec může být skvělý, ale na velký projekt potřebujete tým. A tým potřebuje koordinaci, rozdělení rolí a komunikační pravidla.
Koordinace více agentů
Koordinace více agentů (Multi-Agent Coordination) je základním stavebním kamenem agentních systémů. Místo jednoho agenta, který se snaží dělat všechno, máte několik specializovaných agentů, kteří spolupracují. Jeden agent může být expert na analýzu dat, druhý na psaní reportů, třetí na komunikaci se zákazníky.
Orchestrace agentů (Agent Orchestration) je pak mechanismus, který zajišťuje, že tito agenti spolupracují efektivně. Orchestrátor rozhoduje, který agent dostane jaký úkol, v jakém pořadí se úkoly provádějí a jak se výstupy jednoho agenta předávají jako vstupy jinému.
V praxi to může vypadat takto: obdržíte komplexní zákaznický dotaz. Orchestrátor ho předá analytickému agentovi, který identifikuje klíčové body. Ten předá výsledky vyhledávacímu agentovi, který najde relevantní informace. Třetí agent pak z toho všeho sestaví koherentní odpověď. A čtvrtý agent zkontroluje kvalitu a soulad s firemními standardy.
Komunikační protokoly: Jak si agenti povídají
Aby spolu agenti mohli komunikovat, potřebují společný jazyk a pravidla. V tom hrají klíčovou roli komunikační protokoly.
MCP (Model Context Protocol) je protokol vyvinutý společností Anthropic, který standardizuje způsob, jakým se modely napojují na externí nástroje a zdroje dat. Představte si ho jako USB konektor pro AI – místo toho, aby každý nástroj potřeboval vlastní integraci, MCP poskytuje jednotné rozhraní. Díky MCP může agent přistupovat k vašemu Google Disku, e-mailu, kalendáři nebo jakémukoli jinému systému přes standardizované „konektory”.
A2A protokol (Agent-to-Agent) řeší komunikaci přímo mezi agenty. Když jeden agent potřebuje výsledek od jiného, A2A definuje, jak si data předávají, jak signalizují dokončení úkolu a jak řeší konflikty. Je to jako interní komunikační systém ve firmě – e-mail pro agenty.
ACP (Agent Communication Protocol) je obecnější komunikační protokol, který může pokrývat širší spektrum interakcí v agentním systému. Zatímco A2A se zaměřuje specificky na komunikaci mezi agenty, ACP může zahrnovat i komunikaci s externími systémy, uživateli a dalšími entitami.
Důležité je pochopit, že tyto protokoly nejsou konkurenční – doplňují se. MCP řeší napojení na nástroje, A2A komunikaci mezi agenty a ACP zastřešuje celkovou komunikační architekturu. Společně vytvářejí infrastrukturu, díky které mohou agentní systémy fungovat spolehlivě a škálovatelně.
Autonomie a plánování cílů
Autonomní plánování cílů (Autonomous Goal Planning) je schopnost, která posunuje agentní systémy na zcela novou úroveň. Místo toho, aby systém dostal přesné instrukce co udělat, dostane cíl – a sám si naplánuje, jak ho dosáhnout. Řeknete „optimalizuj naši zákaznickou podporu” a systém sám identifikuje problémové oblasti, navrhne řešení, implementuje změny a měří výsledky.
To samozřejmě vyžaduje sofistikované přiřazování rolí agentům (Agent Role Assignment). Systém musí rozhodnout, jaké typy agentů potřebuje, jaké kompetence jim přiřadí a jak je nakonfiguruje pro konkrétní úkol. Jeden agent může být „analytik”, jiný „copywriter”, další „kontrolor kvality” – a tyto role se mohou dynamicky měnit podle potřeby.
Správa životního cyklu a dlouhodobá paměť
Správa životního cyklu agentů (Agent Lifecycle Management) řeší praktické otázky: kdy agenta spustit, kdy ho zastavit, jak ho aktualizovat, co dělat, když selže. V produkčním prostředí jsou to kritické otázky, protože špatně spravovaný agent může způsobit problémy – od zbytečného plýtvání výpočetními zdroji až po chybné akce.
Správa dlouhodobé paměti (Long-term Memory Management) je v agentních systémech ještě důležitější než u jednotlivých agentů. Systém si musí pamatovat nejen fakta, ale i strategická rozhodnutí, naučené postupy a kontexty předchozích úkolů. A co víc – musí umět tuto paměť sdílet mezi agenty, aby se nemuseli učit stejné věci znovu a znovu.
Agenti se specifickými rolemi (Role-Specific Agents) jsou specializovaní agenti, kteří excelují v jedné konkrétní oblasti. Místo jednoho „všeumícího” agenta máte tým specialistů. Finanční agent rozumí účetnictví a rozpočtům. HR agent zná pracovní právo a procesy náboru. Marketingový agent rozumí kampaním a analytice. Každý z nich má přístup k relevantním nástrojům a znalostem pro svou doménu.
Průnik AI Agenta a Agentní AI: Kde jednotlivec potkává tým
Na pomezí jednotlivých agentů a plnohodnotných agentních systémů existuje celá řada sdílených schopností, které definují, jak se z jednoduchého agenta stává součást většího celku.
Orchestrace a hierarchie úkolů
Orchestrace úkolů (Task Orchestration) je schopnost řídit sekvenci a paralelizaci úkolů. Některé úkoly musí běžet postupně (nejdřív analyzuj data, pak napiš report), jiné mohou běžet současně (vyhledej v databázi A a současně v databázi B). Kvalitní orchestrace může dramaticky zkrátit čas potřebný k dokončení komplexních úkolů.
Hierarchické vykonávání úkolů (Hierarchical Task Execution) znamená, že složité úkoly se rozkládají do stromové struktury. Hlavní úkol se rozloží na podúkoly, ty na pod-podúkoly a tak dále. Každá úroveň může být přiřazena jinému agentovi s odpovídající specializací.
Delegování rolí (Role Relegation) je dynamický proces, kdy agent může předat část své práce jinému agentovi, pokud zjistí, že ten je pro daný úkol vhodnější. Analytický agent může zjistit, že potřebuje vizualizaci dat, a deleguje tuto část na vizualizačního agenta, místo aby se o ni pokoušel sám.
Stavová paměť a adaptace
Propagace stavové paměti (State Memory Propagation) zajišťuje, že všichni agenti v systému mají přehled o celkovém stavu úkolu. Když jeden agent dokončí svou část, ostatní o tom ví a mohou na to navázat. Bez této propagace by agenti pracovali ve vakuu, nevěděli by o sobě a výsledky by byly nekonzistentní.
Sdílení dlouhodobé paměti (Long-Term Memory Sharing) jde ještě dál – agenti si sdílejí nejen aktuální stav, ale i zkušenosti z minulých úkolů. Když jeden agent zjistí, že určitý postup nefunguje, tuto informaci sdílí s ostatními, aby se stejná chyba neopakovala.
Adaptace řízená zpětnou vazbou (Feedback-driven Adaptation) umožňuje celému systému se učit z výsledků. Pokud se ukazuje, že určitý přístup k úkolům vede k lepším výsledkům, systém ho začne preferovat. Pokud jiný přístup opakovaně selhává, systém ho opustí. Tato schopnost učení na úrovni systému je tím, co dělá agentní AI skutečně inteligentní.
Modulární distribuce úkolů (Modular Task Distribution) a autonomní plánování (Autonomous Planning) pak uzavírají tento průnik – systém dokáže rozdělit práci do modulárních celků, které lze nezávisle přiřadit, sledovat a v případě potřeby přerozdělit.
Praktický průvodce: Kdy co použít a na co si dát pozor
Teď, když rozumíte jednotlivým vrstvám, pojďme se podívat, co to znamená v praxi. Protože nakonec nejde o to, jestli znáte správné termíny, ale jestli víte, co potřebujete pro svůj konkrétní případ.
Samotný LLM stačí, když…
Potřebujete obecné jazykové úkoly – psaní textů, překlady, sumarizace, brainstorming, pomoc s kódem. Pokud vaše otázky nevyžadují aktuální nebo proprietární data a nepotřebujete, aby AI cokoli aktivně dělala, samotný jazykový model bohatě postačí. Většina lidí, kteří dnes používají ChatGPT nebo Claude pro běžnou práci, si vlastně vystačí s touto vrstvou.
Typické scénáře: přepisování e-mailů, generování nápadů, vysvětlení složitých konceptů, pomoc s formulacemi, základní analýza textu. Pro všechny tyto úkoly nepotřebujete nic víc než kvalitní LLM a dobrý prompt.
RAG potřebujete, když…
Chcete, aby AI odpovídala na základě vašich konkrétních dat – firemní dokumentace, produktových katalogů, interních procesů. RAG je ideální pro zákaznickou podporu, interní helpdesky, znalostní portály a všude tam, kde přesnost odpovědí a aktuálnost informací jsou kritické. Pokud vás trápí halucinace modelu nebo zastaralé informace, RAG je odpověď.
Pozor ale na to, že RAG není všelék. Kvalita výstupu závisí na kvalitě vstupních dat. Pokud jsou vaše dokumenty zastaralé, neúplné nebo špatně strukturované, ani nejlepší RAG systém z nich nevyrobí přesné odpovědi. Platí staré pravidlo: odpad dovnitř, odpad ven.
AI Agent je volba, když…
Potřebujete, aby AI nejen odpovídala, ale také konala. Posílala e-maily, aktualizovala databáze, vyhledávala na webu, generovala reporty, spravovala soubory. Agent je jako osobní asistent, který umí nejen poradit, ale i udělat. Typické použití: automatizace pracovních postupů, asistence při výzkumu s více kroky, správa projektů.
Důležité je si uvědomit, že agent potřebuje přístup k nástrojům – a to znamená přiřazení oprávnění. Agent, který může posílat e-maily vaším jménem nebo upravovat data v systému, musí být pečlivě nakonfigurovaný a monitorovaný. Přílišná autonomie bez kontroly může vést k nepříjemným překvapením.
Agentní systém dává smysl, když…
Řešíte komplexní úkoly, které vyžadují koordinaci více specializovaných schopností. Firemní procesy, které zahrnují analýzu, rozhodování, komunikaci a exekuci současně. Nebo situace, kde jeden agent nestačí a potřebujete tým. Dnes jde stále spíše o experimentální nasazení, ale tempo vývoje je rychlé a běžné podnikové využití se blíží.
Realisticky vzato: většina firem dnes nepotřebuje plnohodnotný agentní systém. Ale rozumět tomu, kam se technologie ubírá, vám pomůže lépe plánovat a investovat do AI s předstihem, ne se zpožděním.
Jak jednotlivé vrstvy vypadají v reálném firemním scénáři
Představme si konkrétní situaci: máte e-shop a zákazník vám píše reklamaci. Na úrovni samotného LLM by AI mohla vygenerovat zdvořilou odpověď, ale neznala by vaše konkrétní reklamační podmínky ani historii objednávky. S RAG by AI dohledala přesné podmínky z vašeho reklamačního řádu a odpověděla podle nich. AI agent by navíc mohl zkontrolovat stav objednávky v systému, ověřit záruční dobu a rovnou založit reklamační případ. A agentní systém by mohl celý proces od příjmu reklamace přes komunikaci se zákazníkem, koordinaci se skladem, výběr řešení a odeslání finální odpovědi zvládnout autonomně – s tím, že člověk by jen schválil navržené řešení.
Tohle není sci-fi. Každá z těchto úrovní je dnes technicky realizovatelná. Otázka je, která úroveň dává smysl pro vaši konkrétní situaci – s ohledem na objem dotazů, komplexitu procesů, dostupný rozpočet a technické kapacity.
Kam se celý ekosystém ubírá
Hranice mezi jednotlivými vrstvami se postupně stírají. Moderní AI platformy stále častěji integrují RAG přímo do jazykového modelu, agentní schopnosti se stávají standardní výbavou a komunikační protokoly jako MCP či A2A postupně standardizují, jak spolu agenti mluví.
Zajímavým trendem je demokratizace – to, co bylo ještě před rokem dostupné jen velkým technologickým firmám, dnes může nasadit i menší firma s jedním technicky zdatným člověkem. Nástroje pro budování RAG systémů jsou stále přístupnější, agentní frameworky se zjednodušují a cloudové služby nabízejí „hotová” řešení, která stačí nakonfigurovat.
Dalším zásadním trendem je konvergence. Dnes ještě rozlišujeme mezi „chatbotem s RAG” a „AI agentem”, ale za rok nebo dva tyto pojmy pravděpodobně splynout do jednoho – prostě „AI asistent”, který automaticky vyhledává v datech, plánuje kroky, spolupracuje s dalšími systémy a průběžně se učí z vašich preferencí. Uživatel nebude muset vědět, která vrstva zrovna pracuje – důležité bude jen to, že výsledek bude kvalitní a spolehlivý.
V podnikovém prostředí se otevírá zajímavá otázka governance – tedy řízení a dohledu nad AI systémy. Čím více autonomie agentům dáme, tím důležitější bude mít jasně definované hranice toho, co smí a nesmí dělat, kdo nese odpovědnost za jejich akce a jak se auditují jejich rozhodnutí. Toto téma je zatím na začátku, ale bude nabývat na důležitosti s každým dalším nasazením agentních systémů v praxi.
Pro běžné uživatele to znamená, že technické detaily budou stále více skryté pod kapotou. Nebudete muset vědět, jestli váš chatbot používá RAG nebo ne – prostě bude odpovídat správně. Nebudete muset konfigurovat agenta – prostě mu řeknete, co potřebujete, a on to udělá.
Ale pochopení těchto vrstev vám dává obrovskou výhodu. Víte, co je možné. Víte, kde jsou limity. A hlavně – víte, na co se ptát, když vám někdo nabízí „AI řešení” pro vaši firmu. Protože mezi „nasadíme vám chatbota” a „nasadíme vám agentní systém s RAG nad vašimi daty” je propastný rozdíl – v možnostech, v ceně i v přínosu.
Umělá inteligence není jedna technologie. Je to ekosystém vrstev, které se vzájemně doplňují a posilují. A čím lépe tomuto ekosystému rozumíte, tím lépe ho dokážete využít – ať už jste na začátku své cesty s AI, nebo se v ní už slušně orientujete.
Zdroj: Clare Kitching
