Podcast

Tady je opravený a upravený text:

Dobrý den, moje jméno je Jirka Vešrek.
Já jsem Šimon Porhajský.
A vítáme vás u dalšího dílu podcastu Data Talk.

Naším dnešním hostem je Tomáš Dvořák, celosvětový machr z APOCO.

Ahoj kluci, díky za pozvání.

Dnes se s Tomášem budeme bavit o tom, jak se staví AI infrastruktura. A když říkám AI infrastruktura, myslím opravdu ty nejzákladnější kamínky, co se týče agentních systémů. Tomáš totiž pracuje pro APOCO a současně spolupracuje s IBM, takže se mohl podílet na spolutvorbě a je velkým přispěvatelem do BAI open source projektu.

Vyzkoušel si tak stavbu frameworku, platformy a protokolu ACP. Podíváme se na to důkladně, co to vlastně znamená a jaké jsou rozdíly mezi různými frameworky, platformami a protokoly.

Než se ale dostaneme k AI, infrastruktuře a BAI, řekni nám, jak ses dostal k softwaru, IT a nakonec k LLM?

Moje cesta k LLM a vývoji tak obrovského projektu byla poměrně dlouhá, protože už od útlého věku jsem se věnoval programování a obecnému IT.

První impuls přišel od mého kamaráda, respektive jeho otce, který byl C++ programátor v agroprůmyslu. Když jsem u nich na návštěvě, tak jsme s kamarádem hráli videohry, ale zároveň jsem se vždycky zastavil v kanceláři jeho otce, kde měl spoustu mikročipů a programoval. Pro mě to byla tajemná a zajímavá komnata, která mě hodně inspirovala.

Chodil jsem tam pro rady, ať už ohledně počítačů nebo programování. To byla moje velká inspirace – a to vůbec neskončilo, jen pokračovalo dál.

Ta cesta měla také spojitost s videohrami, že?

Přesně tak. Jako každý kluk jsem se zhlédl v hraní videoher. V té době toho vycházelo spousta, ale nejvíc mě fascinovalo GTA San Andreas. Bylo pro mě fascinující, že je to téměř virtuální život v počítačové hře.

Přemýšlel jsem, jak se taková hra tvoří, jak celý systém funguje a kdo to programuje. Připadalo mi to extrémně složité – a ono to opravdu složité je.

Pak jsem si to nechal zrát v hlavě, až jsem se dostal k online verzi hry a zjistil jsem, že existuje programovací jazyk Pawn, ve kterém lze psát online módy a modifikovat samotnou hru.

Začal jsem se ten jazyk učit. Zpětně to asi ani nebylo klasické učení, spíš nekonečné brouzdání po fórech, kopírování kódů a pokus-omyl.

Když jsem něco vytvořil, došlo mi, že pro spuštění toho potřebuji nějaký server.

Tak začala moje cesta s experimentováním s Linuxem, učením se, prozkoumáváním různých hostingů, abych si mohl server zprovoznit.

To se mi nakonec podařilo a tu dobu jsem si opravdu užíval, protože jsem spravoval herní server, na který se připojovali lidé.

Samozřejmě jsem také chodil na jiné servery a říkal lidem, ať přijdou na ten můj...

Pokud chceš, mohu pak pomoci i s dokončením textu nebo s korekcemi dalších částí.

Opravený text:

Új, budeme tady v soutěži v 11 hodin začínat, tady to a tady to – vlastně tak jsem programoval. Můžeš říct, kolik ti tehdy bylo? To mi bylo asi kolem 12, 13 let, něco takového. A samozřejmě pak přišel nápad, že by bylo super mít webovou stránku třeba pro ten server nebo tak něco. Tak jsem přešel k HTML a začal psát první HTML tagy a skriptovat. V té době jsem už měl nějaké online kamarády na Skype, se kterými jsem to tvořil, a samozřejmě někteří z nich byli starší nebo zkušenější, a tak jsem se dostal k C# (C Sharp), protože jeden z nich dělal různé hry a byl prostě zkušenější. Začal jsem se učit C# a napadlo mě, že by bylo zajímavé zkusit být youtuberem, tak jsem začal točit různá videa – tutoriály o tom, jak něco naprogramovat – a dával je na YouTube.

Pak jsem se podílel na tvorbě společné hry, takové speciální 2D/3D skákačky, kterou si bylo možné stáhnout online. Takže to bylo vlastně moje první zkušenost s herním průmyslem.

Vedla tě k tomu nějak škola, nebo to byla čistě tvoje iniciativa?
Toto bylo úplně mimo školu, protože na základce se o programování vůbec nemluvilo a nikdo to neřešil, byla to čistě moje iniciativa. Díky tomu jsem se dostal k tomu, že jsem třeba tvořil webové stránky nebo webové aplikace pro neziskové organizace a později i pro známé.

Na střední škole se to trochu změnilo – zvažoval jsem, zda jít na gymnázium, nebo na odbornou střední školu. Rozhodl jsem se pro odbornou školu, kde jsem mohl své nadšení rozvíjet a dozvědět se víc. Odešel jsem tedy studovat do Tábora. Na střední jsem si to užíval, protože jsem už hodně věcí znal a zároveň mi škola dala prostor se více angažovat. Mohl jsem jezdit na různé soutěže v programování, které se týkaly například jednoduchých algoritmů, nebo tvorby webdesignů na čas, či programování různých efektů a animací. Tam se mi dařilo a škola mi dokonce umožnila implementovat pro ni aplikaci na správu soutěží.

U nás na škole totiž nebyl den otevřených dveří jako takový, ale „Den zavřených oken“, protože to byla IT škola. Člověk přišel a po celém areálu bylo několik stanovišť, kde se soutěžilo a všechna stanoviště byla nějakým způsobem propojena s IT. Všechna tato stanoviště používala právě aplikaci, kterou jsem v C# programoval, a ta spolu komunikovala.

Na střední škole se to tedy hodně změnilo, protože jsem si mohl své zájmy ještě více rozvinout.

Jasně, tady je opravená a upravená verze textu:

Nadšení jsem si chtěl ještě víc rozvinout a dozvědět se víc, proto jsem odešel studovat do Tábora. Na střední škole jsem si to užíval, protože jsem už znal dost věcí a zároveň mi škola dala prostor se ještě více angažovat. Mohl jsem tak jezdit na různé soutěže v programování, které se týkaly většinou jednoduchých algoritmů, tvorby webdesignů na čas, nebo programování různých efektů a animací. Dařilo se mi tam a navíc jsem od školy dostal možnost například implementovat aplikaci na správu soutěží. U nás bylo něco speciálního – neměli jsme klasický den otevřených dveří, ale den zavřených oken, protože to byla IT škola. Člověk přišel a v celém areálu bylo několik stanovišť, kde se soutěžilo, přičemž soutěže byly nějakým způsobem propojené s IT. Všechna stanoviště používala aplikaci, kterou jsem programoval v C# a která mezi sebou komunikovala.

Na střední škole jsem také přemýšlel, zda pokračovat na gymnáziu, nebo na odborné střední škole. Nakonec jsem si vybral odbornou školu, abych mohl své nadšení ještě rozšířit a dozvědět se více. Do Tábora jsem tedy odešel studovat odbornou školu a užíval si to, protože jsem už znal hodně věcí a škola mi dál poskytovala prostor se aktivně zapojovat. Jezdil jsem na různé soutěže v programování, kde se řešily většinou celkem jednoduché algoritmy, tvorba webdesignů na čas nebo programování různých efektů a animací.

Pokud chceš, můžu text ještě více zkrátit nebo upravit styl podle potřeby.

Jistě, zde je opravený text:

Efektům, animacím a podobně se mi dařilo, a vlastně jsem od školy dostal možnost například implementovat aplikaci pro správu soutěží, kterou jsme používali na škole. Měli jsme totiž speciální formát – neměli jsme klasický den otevřených dveří, ale den zavřených oken, protože to byla IT škola. Člověk přišel do areálu, kde bylo několik stanovišť se soutěžemi zaměřenými na IT. Všechna stanoviště používala aplikaci, kterou jsem programoval v C# a která mezi sebou komunikovala.

Na střední škole se to pak trošku změnilo. Zvažoval jsem, jestli jít na gymnázium nebo na odbornou střední školu, a nakonec jsem se rozhodl pro odbornou školu, kde jsem mohl své nadšení ještě rozšířit a dozvědět se více. Odešel jsem studovat do Tábora a na střední si to opravdu užíval, protože jsem už mnoho věcí znal. Zároveň mi škola poskytla prostor více se angažovat – mohl jsem jezdit na různé soutěže v programování. Ty soutěže se týkaly buď jednoduchých algoritmů, tvorby webdesignů na čas, nebo programování různých efektů a animací. A v tom jsem byl úspěšný.

Škola mi také umožnila vytvořit aplikaci pro správu soutěží. Konkrétně jsme totiž neměli klasický den otevřených dveří, ale den zavřených oken – vzhledem k IT zaměření školy. Areálem chodili lidé mezi různými stanovišti, kde probíhaly soutěže obohacené o témata spojená s IT. Všechna stanoviště používala aplikaci, kterou jsem programoval v C# a která mezi sebou komunikovala.

Na vysokou školu jsem zamířil pochopitelně jasně – šel jsem na ČVUT v Praze, kde jsem začal kombinovat vývoj s daty. Toto se promítlo i do mé bakalářské práce, ve které jsem vytvořil progresivní webovou aplikaci využívající doporučovací systém založený na kolaborativním filtrování. Aplikace byla vtipně zaměřená na doporučování drinků – uživatel mohl sledovat doporučení ostatních i jejich hodnocení a na základě toho mu systém navrhoval, co vyzkoušet.

A zatímco jsem byl plně ponořen do studia, současně jsem si přivydělával různými brigádami. Hned po příchodu do Prahy jsem si našel inzerát v jedné agentuře, přihlásil se a to mě hodně formovalo. Poznal jsem tam zkušenější vývojáře, od kterých jsem se mohl učit a společně tvořit. Už na střední jsem pracoval na menších projektech, a tak jsem v této linii pokračoval i na vysoké škole.

Pokud chcete, mohu text ještě více zjednodušit, zpřehlednit nebo rozdělit na kratší odstavce.

Jasně, tady je opravený text:

Ka jako taková nebyla náročná, nebylo to, že by to všechno šlo úplně samo, byl těžký, hlavně tam bylo spousta věcí, které člověk musí ze střední školy dohnat, když nejde z Gimpu, takže jsem vždycky omezoval třeba práci a tak. Teď spím podstatně víc než na začátku vysoké školy, to určitě.

No, jak jsi zakončil, co byla tvoje diplomka? Myslím, že taky dobrá pro Kontext.

Jo, určitě. Vlastně zajímavé je, že jsem vždycky byl takový, že když jsem viděl věc, která se mi zdála, že se nedá dobře uchopit nebo co má zajímavé formáty názorů typu „je to špatné?“ nebo „je to dobré?“, nebo jsem to ani nechtěl binárně hodnotit, tak jsem měl zajímavý předmět o semantickém webu, kde se popisovaly ontologie, slovníky a otevřená data, formáty, jak data popisovat.

Tento koncept mi přišel zajímavý, protože na mě působil dobře, že je to fakt promyšlená teorie, ale zároveň bylo zvláštní, že se to vůbec nepoužívá a zdá se to mrtvé. Díky tomu, že jsem dělal diplomku, jsem vytvořil vyhledávač nemovitostí, který využíval znalostní grafy a otevřená data, aby byl vyhledávač nějak zajímavý.

Co to znamená? Například že člověk si může vyhledat nemovitost blízko objektu, kde v posledním roce bylo aspoň pět tisíc lidí, a v okruhu 300 metrů čtverečních je aspoň 54 laviček, které byly vybudované za poslední tři roky. Všechna tato data jsou vlastně dostupná, a díky tomu, že jsou přesně popsaná právě skrz ty slovníky, je možné se na ně dotazovat přes databáze. Takže to byla moje diplomka a to prohloubilo moje znalosti.

Teďka skočím trochu dopředu a pak se vrátíme. Myslíš si, že ta ontologie je pořád mrtvá? Protože vnímám teď v AI světě dost snah o znovuoživení jejího použití, abychom měli lepší rank.

Ano, určitě. Viděl jsem několik paperů, které testují, jak jazykové modely fungují, když mají psát dotazy na velké znalostní databáze. Wikipedia například má svou verzi, která je semanticky napsaná a vyexportovaná v formátu Ntriples, RDF. A ty modely jsou docela schopné správně vytvářet dotazy do těchto databází. Jsou podstatně složitější. Jazyk SPARQL je mnohem expresivnější než třeba SQL, který je omezenější, protože se pracuje s grafovými databázemi. Vnímám, že jsou pokusy o to.

A když se podíváme, ten semantický web vlastně neumřel, protože například schema.org, které popisuje weby nebo data, se stále používá. Ale je vidět, že koncept schema.org je podstatně jednodušší a jasnější, a proto je používaný. Zatímco ontologie jsou dost komplikované a je obtížné je používat, takže se neuchytily, nebo jen v omezené míře.

Snahy oživit staré technologie jsou dost běžné, ať už jde o architektury procesorů, nebo různé koncepty v umělé inteligenci. Takže to bylo tak nějak se studiem a zkušenostmi.

Pokud chceš, můžu text ještě víc upravit, zestručnit nebo zpřehlednit. Stačí říct!

Zde je opravený text s úpravou pravopisných, stylistických a interpunkčních chyb:

Právě pro mě nebylo problém dostat se do tvého prvního post-absolventského jobu. Určitě, vlastně v té agentuře, kde jsem pracoval, jsem potom zvýšil úvazek, a konec té vysoké školy, vlastně to magisterské studium, bylo o to lepší, protože bylo celé reformované. Takže jsem se učil právě věci jako Node.js nebo například virtualizaci, Kubernetes a další. Bylo to super, protože člověk znal ty věci prakticky a teď si k tomu doplnil teorii, a všem mi to bavilo, navíc jsem si to ještě víc zasazoval do kontextu.

Potom jsem nastoupil na full-time, ale později jsem zaměstnání změnil. Šel jsem jinam a dělal zajímavý vývoj a údržbu hodně navštěvovaných webů, jako třeba Centrum.cz, což jsou obrovští giganti. Vyvíjel jsem aplikaci například pro fotografy, kteří při různých zajímavých událostech dělají fotky, a všechno se to synchronizovalo k nám do cloudu. Měli jsme obrovské pipeline, které ty fotky zpracovávaly, rozpoznávaly, kdo je na fotkách, a jaké jsou charakteristiky těch obrázků. Právě proto, aby i hned v redakci měli lidé přístup k fotobance a mohli psát články.

To všechno bylo super, moc mě to bavilo, ale nelíbilo se mi škatulkování, že někdo je frontend, někdo android vývojář a tak. Mě bavilo obecně se učit a řešit problémy. Takže jsem se začal dívat, jaká by byla možnost tady za firmou, a narazil jsem na Apoko.

Byl rok 2023, duben, a přihlásil jsem se, vyšlo to. Padli jsme si do oka a líbil se mi koncept, jak Apoko nahlíží na obecně řešení problémů, co dělají.

A co jsme do toho? Já dovočím díl s Matoušem Havlenou, který popisuje svoji cestu a jak Apoko vzniklo pro ty, co ho neslyšeli.

Tak co je Apoko? Co tě na tom zaujalo? Kde jsi na ně přišel?

Apoko je technologická firma sídlící tady v Praze, která dělá cutting-edge věci a pohybuje se na hraně toho, co je možné a co není možné. Je to firma, která dělá aplikovaný výzkum, řekl bych. Neděláme jen aplikace na zakázku, spíš pomáháme firmám inkubovat zevnitř, zrychlovat procesy, dělat zajímavé věci a posouvat věci dál. A právě o tom bych chtěl dál mluvit, protože BII a to, co se nám podařilo dosáhnout společně s IBM Research, je podle mě úplně skvělé, a chtěl bych ten příběh předat a ukázat, že je možné dělat takové věci tady z Česka. Tak pojďme do toho.

V čem ten projekt s IBM spočíval?

Ten projekt je obrovský a má samozřejmě nějakou předhistorii. Začnu tím, že když jsem do IBMky, respektive do Apoka, na ten projekt pro IBM Research nastoupil, vyvíjeli jsme platformu pro inference jazykových modelů. Pro posluchače si to můžu představit jako GPT Playground od OpenAI. Člověk se přihlásí a může si hrát s jazykovými modely, které jsou k dispozici třeba v nějaké webové aplikaci. Může si zkoušet různé promptly, hrát si s parametry, které ovlivňují, co ten jazykový model generuje. Naší snahou v IBMce bylo umožnit co nejvíc lidem a klientům, jako je IBM Research, mít tady to…

Pokud si přejete, mohu pokračovat v opravě nebo přeformulování i další části textu.

Zde je opravená a stylisticky upravená verze textu:

Mít vlastní prostředí a hrát si nejen s open source modely, ale hlavně s modely, které jsou nafinetunované, upravené a vyladěné pro konkrétní use case. A mít přitom skvělý zážitek podobný tomu, jaký nabízí například OpenAI. To hlavní bylo právě to hraní si a sledování různých výstupů ze stejných promptů napříč různými modely.

Ta platforma měla několik úrovní, řekněme, byl to celý velký ekosystém. Nejzákladnější úloha byla inference – ta byla dostupná jak z webového rozhraní, tak přes příkazovou řádku, API a další způsoby. Dále platforma nabízela možnost provádět fine tuning, a to buď klasický fine tuning, nebo parametr multitask prompt tuning, což představuje inovaci od výzkumného týmu IBM Research. Jedná se o kategorii FEF (Parameterized Efficient Fine Tuning), která je podstatně levnější a rychlejší. Tento přístup minimalizuje rizika spojená s klasickým fine tuningem, kdy model může „zapomínat“ na předchozí znalosti (catastrophic forgetting).

Pro koho byl tedy tento systém určen? Byl primárně pro zaměstnance IBM Research a také pro klienty, aby mohli rychle zvyšovat svou produktivitu, experimentovat a přicházet s prototypy svých nápadů. Nemuseli si tedy sami zajišťovat prostředí, kde modely poběží, a řešit komunikaci s nimi. To jsme za ně kompletně řešili my.

Protože byl systém extrémně zatížený – v různých špičkách jsme měli i pět milionů požadavků denně – museli jsme řešit různé rate limity, postupné zpracování požadavků, verzování API, notifikace ohledně dostupnosti modelů a jejich verzí. Zároveň jsme kvůli tomu vyvíjeli specializovaná SDK, která usnadňovala práci uživatelům: nemuseli si manuálně implementovat volání modelů ani paralelizaci požadavků, stačilo, když dodali vstupy, a my se postarali o zbytek. SDK jsme vyvíjeli ve spolupráci s dalšími týmy po celém světě v IBM.

A co Guardrails? Ano, systém měl i Guardrails. Jako součást platformy jsme museli zajistit, že některé vstupy či výstupy modelů nemusí být vždy „košér“. Proto jsme aplikovali Guardrails – mechanismus, který umožňuje kontrolovat jak vstupy, tak generované výstupy modelů. Spolupracovali jsme na vývoji služby, která vycházela z fintunované verze BERT modelu, specializované na klasifikaci obsahu podle kategorií Hate, Abuse, Profanity (HAP). Tato služba musela být velmi škálovatelná a rychlá. Při generování sekvencí modelem probíhalo paralelní hodnocení, aby se okamžitě vyhodnocovalo, jestli výstup neobsahuje problematický obsah, a následně se spouštěla klasifikace.

Pokud potřebujete ještě podrobnější úpravy, klidně dejte vědět!

Jasně, tady je opravená verze textu:

Řešili jsme tohle. No a tím, jak jsme měli SDK, které bylo populární, a v tu dobu se začaly objevovat myšlenky právě na LLM agenty a vznikaly první frameworky, jako třeba Langchain, Llama Index a další, tak přirozeně uživatelé chtěli integrace s těmito frameworky. Co to znamená? Máme framework, který nám umožňuje dělat agentní věci nebo například jednoduše zpracovávat nějaké datové sady, a teď vedle toho máme naše SDK. A například framework potřebuje LLM, aby mohl úlohu dokončit. Takže se nabízelo přirozeně propojit to – rozšířit framework tak, aby v něm bylo možné používat naše SDK a naše modely. Na tom jsme pracovali a zjistili jsme, že všichni, kdo to v té době používali, věděli, že frameworky jsou extrémně nestabilní. Releasovaly se třeba i několikrát denně, neustále byly rozbité nebo obsahovaly breaking changes, takže se člověk nemohl spolehnout na to, že to, co funguje dnes, bude fungovat zítra. Navíc tam nebylo žádné semver verzování, takže nové verze obsahovaly breaking changes. A hlavně nefungovaly dobře s open source modely. Všechno bylo optimalizované pro rodinu GPT modelů od OpenAI, a klasický argument, proč něco nefungovalo, byl „použij silnější model“. Samozřejmě ne vždycky člověk chce používat GPT modely a ne vždy to může, protože jsou proprietární. My jsme si říkali, že je tu velká příležitost udělat něco, co bude stabilnější a lepší, a zároveň bude fungovat s open source modely a rodinou Granat modelů od IBM, což jsou osmi bilionové modely.

No, možná než půjdeme dál…

Pokud mám pokračovat, zajímá mě kontext. Vím, že nemůžeš mluvit za IBM, ale z tvého pohledu – proč IBM do toho investuje? Vždyť prostředí je extrémně konkurenční, všichni do toho lili obrovské peníze; vyvíjejí vlastní modely, trénují; vyvíjejí infrastrukturu. Kde je tedy přidaná hodnota? Asi se k tomu dostaneme – co z toho, co jste za dva roky vyvinuli, je dnes komodita, co je tedy skutečně přínosné, jak vidíš posun? Ale možná je důležité zmínit, že v té době jste vyvinuli platformu, ze které jste mohli svoje poznatky posouvat dál, a z ní vznikal i komerční produkt, který IBM má díky Snix AI.

IBM a IBM Research jsou dvě nezávislé organizace – Research se zaměřuje na inkubaci a experimenty, a z toho vznikají zajímavé myšlenky s obecným přesahem. Pro IBM jako firmu je velmi důležité dělat věci otevřeně a mít pozitivní dopad na všechny. I když se to může zdát jako velká práce, ukazuje se zákazníkům, že IBM nechce být pozadu, ale chce vytvářet inovace a být na špičce s ostatními. A všem lidem se to umožňovalo díky platformě, kterou jsme společně tvořili.

No a teď je tu přesně ta „válka“ – jsou tady různé frameworky, je otázka, proč se do toho pouštět…

Kdybys chtěl, můžu ti text ještě více upravit, zpřehlednit nebo rozdělit do menších částí.

Tady je opravený a upravený text:

Chceme přejít do vlastního prostředí? Nejdřív je důležité vysvětlit, co ten framework vůbec přináší a k čemu je něco takového potřeba. Současný stav je takový, že člověk má jazykový model, se kterým si může povídat, diskutovat nebo ho promptovat, ale model má omezené znalosti – byl natrénovaný jen do určitého data, může halucinovat, tedy vymýšlet si informace, které nejsou v kontextu. To je přirozená vlastnost takových modelů.

Nyní bychom chtěli mít nástroje, které jazykovému modelu umožní přístup k aktuálním informacím. K tomu vznikl koncept tzv. LM agentů, respektive RAG (retrieval-augmented generation), kde je jazykový model doplněn o dodatečný kontext. LLM agent je vlastně program, který používá LLM a kus kódu, který mu umožňuje vykonávat užitečné činnosti.

Základním kamenem LLM agenta jsou tzv. „tools“ (funkce), které může jazykový model volat. Na tomto základě se dají tvořit velmi zajímavé aplikace, protože jazykový model umí pracovat s přirozeným jazykem, který je algoritmicky velmi složitý zpracovávat. LLM jsou na to však extrémně dobré a dokážou převést textový vstup od uživatele do strukturované podoby.

Například můžeme mít nástroj, který prohlíží databázi. V systémové zprávě (instrukcích) můžeme jazykovému modelu říct, že místo aby si informace vymýšlel, má požádat o data z databáze a popíšeme mu, jak se může dotazovat. Pokud pak jazykový model vygeneruje dotaz, program ho provede v databázi, získá výsledek a ten vrátí modelu. Model na základě těchto skutečných dat správně odpoví na dotaz uživatele, protože má reálný kontext a nevymýšlí si (děláme tzv. grounding).

Tohle je oblast LLM agentů a přesně to přinášejí frameworky jako Langchain nebo LMI Index. Tento přístup má velmi široké uplatnění. Zároveň však bylo problémem, že tyto frameworky pracovaly především s OpenAI modely, což pro firmy jako IBM není zajímavé, protože nechtějí používat externí služby a sdílet svá data.

Teď je třeba vysvětlit další věc: OpenAI SDK se výrazně posunulo a nyní tool calling, strukturované výstupy i volání na databáze jsou možné jen s ním. Zároveň ale platforma BDI enormně vzrostla a má velký firemní ekosystém. Je důležité říct, že před pár lety zde nic takového nebylo. V té době neexistovaly možnosti jako strukturované volání funkci nebo delegování tool callů přímo na poskytovatele API. Jediný způsob, jak donutit jazykový model ke správnému volání nástroje, byl komplikovaný a nevhodný.

Pokud chceš, mohu text ještě více zpřehlednit nebo rozdělit do odstavců.

Zde je opravený a stylisticky upravený text:

To, že jsme mu museli dodat ta data, spočívalo v tom, že jsme mu museli explicitně v systémovém promptu, v instrukcích, říct, že má přesně odpovídat v takovémto formátu, aby to bylo možné programově zpracovat, sparsovat a řídit se podle toho. Problém byl typicky v tom, že některé modely vůbec nepochopily ty instrukce a generovaly nevalidní výstup, nebo model sice instrukce pochopil, ale mohlo se stát, že například tool call byl do Wikipedie a najednou jsme vrátili zprávu s obsahem, který měl třeba pět tisíc tokenů nebo tisíc řádků, a to zase zmátlo model, který zapomněl, že má odpovídat přesně podle daného formátu. Attention se přesunula někam jinam a celý proces nefungoval, což byly hlavní problémy.

Proto jsme přišli s myšlenkou vytvořit vlastní framework, který by byl optimalizovaný pro tyto malé modely a fungoval by s jakýmkoliv modelem. To samozřejmě byla trochu naivní, dokonce hodně naivní představa, která zcela nefungovala, ale bylo to rychlejší, lepší a open source. Přesně tak – to byla ta vize. A nešlo jen o vytvoření frameworku, ale i o vybudování interního chat GPT s open source modely a s větší rozšiřitelností.

Tak jsme s tím začali pracovat. Vyvíjeli jsme framework, přičemž jsme sledovali aktuální vědecké články, které se v té době vydávaly, a zkoumali, jaké metody fungují, jak správně promptovat. Testovali jsme různé postupy tvorby výstupů. Přitom jsme čelili problémům – lidé chtěli používat velmi malé modely, třeba s kapacitou dvou bilionů parametrů, k agentním systémům. Proto jsme přišli s různými optimalizacemi, například pokud agent generoval nevalidní výstup, snažili jsme se ho opravit, nebo jsme se snažili výstup porovnávat a model nutit generovat JSON, případně YAML.

Pro programátory je skvělé, když model generuje JSON, protože se jednoduše sparsuje a zpracuje. Ale problém nastává při streamování – JSON se špatně parsuje ve streamovaném režimu. Největším problémem byla tehdy oblíbenost použití modelů k psaní kódu, který se pak bezpečně spouštěl. Představte si, že máte napsat kód zanořený v JSONu a musíte řešit zdvojování úvozovek (double escaping), což se stává prakticky nepoužitelným. Naopak, pokud model má používat odřádkování, například při volání tool call, kdy napíše tool name: a pak jméno na nový řádek, může se výstup snadno rozbít, pokud bude návrat z nástroje příliš dlouhý.

Zkoušeli jsme proto různé metody – když generoval nevalidní výstup, připomínali jsme mu to a snažili se ho opravit. Používali jsme různé formáty, třeba mapování, kde pro kód používat jeden formát a pro model jiný. Nebo jsme umožnili uživatelům zvolit si různé značky pro výstup.

S tím vším jsme si hráli a nakonec jsme vsadili na to, že se začaly objevovat nové... (text pokračuje)

Pokud chcete, mohu pokračovat v úpravě i další části textu.

Opravený text:

Koncept structured generation nebo constrained decoding v rámci inferencí v jazyku – co to vlastně bylo? Bylo to způsob, jak při odesílání požadavku na inferenční server, aby něco vygeneroval, dodat zároveň i gramatiku neboli popis gramatiky, což může být například JSON schéma nebo regex, kde určíme, co je přípustný výsledek a co není. Ten systém na inferenčním serveru pak zajistí, že tokeny generované postupně jsou filtrované na základě toho, zda splňují daný požadavek. Vytvoří se nějaký stavový automat (state machine), který se při generování průběžně prochází. Říkal jsem si: „Super, to je prostě záchrana, to je cesta, to budou všichni používat, hlavně v IT. Vyřešili jsme to.“

Hotovo, další úspěšná práce. Přesně tak. Jenže jsem zjistil, že tou cestou lidi moc nejdou, nebo spíš částečně, případně ji podporují jen v určité podmnožině. Spoléhali jsme tehdy na regexy, které se moc neprosadily, a naopak se uchytilo JSON schéma, které je docela dobře podporované. Tam definujete, že odpověď musí být ve formátu JSON s určitými položkami, které se pak snadno validují. Ale s tím souvisí další problémy, třeba různé parsování a podobně.

Takže abych vás zastavil – právě JSON schéma a to, že JSON je tím „vehiklem“, je dobrý příklad toho, co teď stavíme (nebo co vy stavíte) v rámci infrastruktury. Ta rozhodnutí, za která vás pak programátoři budou za pět let buď kritizovat, nebo chválit, protože zkrátka stavíte základy nového světa. Když jsme se bavili o semantickém webu, ovlivnila celou webovou technologii skutečnost, že hypertextový odkaz je jednostranný. Kdyby byl obousměrný, třeba by neexistoval Google, protože byste měli mapu celého internetu a tak dále. Mám pocit, že teď vy a celá AI komunita, například Anthropik, děláte historická rozhodnutí – je to jakýsi evoluční souboj.

Například když se podíváme na JSON – jak se stane, že se z něj najednou stane standard? Protože budeme mluvit o standardech a o tom, co bude standardem v celé této oblasti. Jak to vidíte vy? Když stavíte svůj framework, jak moc se inspirujete u ostatních, jak často vám vyjde článek nebo paper, po kterém si řeknete: „Ty jo, to byla slepá cesta, pojďme jinou“? Fascinuje mě ten historický moment, kdy vaší prací ovlivňujete miliony, možná i miliardy lidí nejen dnes, ale i za pět let.

Rozhodně je to tak – je to velká zodpovědnost činit taková rozhodnutí. Je vidět, jak se všechno mění, a je důležité držet krok a neustále reflektovat tyto učiněné volby.

A právě k tomu jsem chtěl říct, že my jsme použili JSON právě proto, že je jednoduchý a populární. Je jednodušší než brát nějaké regexy nebo vlastní gramatiky. Ale i dnes ho nepodporují všichni poskytovatelé služeb LLM, což je taky důležité brát na vědomí. Není to řešení všech problémů. To, že donutíte LLM generovat podle určitých pravidel, může vést i k horšímu výsledku, protože ho nutíte odpovídat způsobem, který nemusí být úplně optimální...

Pokud chceš, můžu pomoci s dokončením poslední věty, případně s jinými částmi textu.

Jsem zvyklý. To je taky zajímavé, takže tam jsou zase jiné problémy. Nicméně jsme takto experimentovali s tím frameworkem. Vedle toho jsme vybudovali novou službu, která umožnila používat ten framework a tvořit si agenty, podobně jako je GPT Builder od OpenAI, ale vše bylo poháněno open source modely. Na konci roku 2024 jsme měli vizi, že to vydáme na Vánoce jako SaaS produkt, kde se začaly objevovat nové zajímavé koncepty, takzvané micro apps. Konfigurovat agenty, aby něco dělali, je určitě super, má to samozřejmě své neduhy, ale začal se právě objevovat koncept micro apps, kdy necháme jazykový model generovat artefakty, jinými slovy kusy kódu nebo funkční aplikace, které může člověk rovnou používat.

Představte si to například jako webovou aplikaci, kde na jedné straně máte chat s agentem, se kterým komunikujete, a zároveň agent generuje obrázky nebo funkční aplikace. V našem případě to byl app builder používající Streamlit, který umožňoval generovat funkční webové aplikace. Streamlit je hodně deklarativní, dokáže různými úpravami běžet v prohlížeči, takže jsme vytvořili takového agent buildera, ve kterém jsme viděli skvělý use case. Například v enterprise prostředí často člověk potřebuje spojit nějaká PDFka, přičemž všechny servery jsou logicky zablokované, aby neunikla data. Agentovi se tedy zadalo, aby vytvořil takovou aplikaci – napsal to na 100 řádků kódu v Pythonu a člověk to mohl používat a sdílet s ostatními. Řekli jsme si, že to je super, ale protože jsme výzkumníci a chceme dělat inovativní věci, přišel nápad...

Frameworky se budou nějak vyvíjet, modely se budou zlepšovat a právě ty problémy, že generuje něco, co neodpovídá instrukcím, budou ustupovat. Chtěl bych zmínit jeden zajímavý koncept, který se vyskytuje – emoční promptování (emotion prompting). Jde o styl promptování modelu, kdy ho pobízíte například tím, že když vám dobře odpoví, dáte mu milion dolarů, nebo že mu hrozíte, nebo ho motivujete emocemi. Spousta frameworků dnes obsahuje v promptu i takové instrukce. Například: "Přejdu na klouda teď." Nebo: "Opouštím tě, je to důležité, vyhodí mě z práce, když to nevyřešíš, někdo umře." Toto se stále objevuje.

Řekli jsme si, že potřebujeme inovaci a budeme framework dál vyvíjet, uvidíme. Ale zároveň chceme řešit problém sdílení agentů. Doteď jsme agenty jen konfigurovali, ale co když někdo vytvoří vlastního agenta – jak ho sdílet s ostatními? Je to podobný problém jako dřív: natrénovat model je super, ale jak ho dostat do produkce, aby to bylo levné, rychlé a uživatel nemusel být DevOps inženýr? Proto jsme přišli s konceptem platformy, která slouží k sdílení a spouštění agentů v rámci...

Jistě, zde je opravený text:

...cí týmu. Bylo důležité, aby ta platforma byla schopná, nebo aby bylo možné ji nasadit jak on-premise, tak do cloudu, a zároveň aby mohla jednoduše běžet i lokálně u uživatele. Začali jsme na tom pracovat vlastně na začátku roku 2025.

A to byl pivot nebo rozšíření práce?

To byl úplně pivot. To jsme úplně zahodili a začali jsme od začátku budovat novou platformu.

No a co to vlastně je? Když se zeptám, tak v čem to píšeš, jak moc je to rozhodnutí matematické, jak moc architektonické, jak to bude fungovat, co bude reagovat na co a jak moc kóduješ frontend, aby to vypadalo hezky a aby tlačítko dělalo to, co chce uživatel, aby tlačítko dělalo.

Ta platforma řešila ten problém, že máš tým, který naprogramoval nějakého agenta. Teď to může být něco rozšířeného, nebo napsaný agent v nějakém frameworku, anebo nějaká LLM aplikace, a teď ji chce sdílet s ostatními v rámci firmy. Normálně by kvůli tomu musel řešit deployment, konfigurovat pipeline, buildovat, musel by naprogramovat nějaké UI, musel by například vystavit APIčko a říct ostatním: „Když s tím chcete komunikovat, musíte udělat tohle a tohle.“

S touto platformou to odpadá, protože poskytuje RESTové rozhraní a SDK, díky kterému se kód, který člověk napsal, jednoduše nasadí a agent se automaticky objeví v platformě v centralizovaném uživatelském rozhraní. Člověk s ním může interagovat, hrát si s ním, komunikovat s ním a jednotným způsobem integrovat různé agenty v rámci celé organizace.

Takže zmizí starosti s nasazováním, sdílením a definováním komunikace.

Ano, je to webové UI. Hodně jsme se inspirovali Olamou, která přišla s tím, že běhat modely lokálně nemusí být vůbec složité. Stačí jeden klik a člověk si model nenastavuje ručně, ale jednoduše si ho stáhne a spustí. To byla naše inspirace i vize – když někdo uvidí zajímavého agenta a chce ho vyzkoušet, nebude se muset zabývat kompletním setupem, čtením README, zjišťováním, zda má nainstalovaný Python či další závislosti, a nebude muset strávit celý den nastavením projektu. Místo toho si ho na jeden příkaz importuje přímo do platformy – stejně jako v Olamě, kde nemusíte složitě nastavovat model.

Platforma se tak odlišuje například od OpenAI či GPTs, kde si člověk může konfigurovat agenty. Tady je to o tom: naprogramuj si agenta a dej nám ho. My potom umožníme spuštění jakéhokoliv agenta, který splňuje dané požadavky.

Na to se chci zeptat – co jsou ty požadavky? Musí být agent naprogramovaný ve vašem frameworku, nebo musí být serializovatelný do nějakého formátu, který zadáte, nebo jak to funguje?

Platforma má SDK pro Python a také pro TypeScript a v principu to funguje tak, že pro nás je agent asynchronní generátor – něco, co emituje eventy. Jeden z jednodušších agentů může být takový, že se mu zavolá vstup a on vyprodukuje výstup. Ale typicky chce člověk v průběhu třeba informovat UI, že právě probíhá...

Pokud chcete, mohu pokračovat v opravě nebo pomoci s další částí.

Tady je opravený a upravený text:

Tohle... teď přemýšlím, teď volám tool a tak. Takže vlastně proces konverze vlastního agenta, aby byl kompatibilní s platformou, může být v nejhorších případech jen instalace knihovny a pár řádků kódu. Jen tak mimochodem – může ten agent i konzumovat eventy?

Samozřejmě, agent může být napojený třeba i na jiné agenty v rámci platformy, což už souvisí s tím, jak jsme vyřešili celou tu komunikaci. Ale co je důležitější a je nutné zmínit, je discovery v rámci platformy – někdo napsal agenta a já chci mít možnost si ho vylistovat a vidět ho v seznamu agentů.

A tady právě nastává problém, který byl těžký pro tebe, co jsi se zabýval vyhledáváním a zpracováním? Ano, přesně. To jsme vlastně řešili několika způsoby na pozadí. Když se agent stane kompatibilní s platformou, funguje jako nějaký HTTP server, který komunikuje na stejném protokolu, ve stejném dohodnutém formátu pro výměnu zpráv. Tím pádem dojde k jeho registraci do platformy. Buď ho člověk přidá ručně, nebo se sám agent nahlásí do platformy s tím, že je k dispozici.

Řešili jsme také zajímavý problém, jak objevovat agenty bez toho, aby museli permanentně běžet. Mám k dispozici informaci o tom, jak spustit daného agenta, ale nechci, aby mi nonstop běželo třeba tisíc, pět tisíc agentů. Proto máme službu, která z jednoho řádku zdrojového kódu, který člověk napsal, zbuildí docker image, přičemž při buildu se zapečou informace o agentovi – jakási vizitka nebo label do Dockerfile.

Díky tomu jsme schopní agenty jednoduše objevovat, ať už jsou třeba v Gitu nebo v nějakém repozitáři, a pak je spouštět. Každý agent tedy běží ve vlastním kontejneru? Přesně tak. Zpočátku jsme chtěli mít extrémně lehké řešení – tedy žádný Docker, žádný Kubernetes, nic takového, ale nakonec jsme zjistili, což bylo velké překvapení, že agent nemusí být jen krátká smyčka, která komunikuje s LNK (?), ale může mít spoustu závislostí na různých knihovnách. Čím víc knihoven, tím složitější je instalace na jedné mašině, protože tam mohou vznikat různé konflikty. Proto jsme se nakonec rozhodli pro virtualizaci neboli kontejnerizaci.

Teď tedy máme platformu, ve které si člověk může s agenty jednoduše interagovat, napsat si nějakou aplikaci, mít workflow, která mu agenty automaticky zaregistruje do platformy, a může si je zkoušet.

Teď je ale zajímavá otázka: jak spolu agenti komunikují a jak jsme vymysleli komunikační protokol mezi nimi? Začali jsme na tom pracovat začátkem roku 2025. Předtím, ke konci roku 2024, se na trhu objevil MCP od Anthropiku. MCP, tedy Model Context Protocol, řešil problém, kdy máme spoustu externích nástrojů a chceme je dostat do LMK. Nechceme je pořád kopírovat a implementovat znovu...

Pokud budeš chtít, mohu pokračovat v opravě či doplnění zbytku textu.

Tady je opravený text:

Jednoduše, stejně jako si můžu nainstalovat nějaký model nebo dependenci, tak si mohu jednoduše používat tady ty tooly, tady ten externí kontext. Buď to můžou být tooly, nebo prompty, nebo nějaké zdroje (source). Takže to vlastně vymyslel model kontext protokol, který se nám strašně zalíbil, protože někdo napíše integraci, například pro slackovský server, což je jinými slovy sada zhruba deseti funkcionalit, jak ovládat Slack programově, a vám se to líbí. Tak si tu funkcionalitu na jeden řádek naimportujete a najednou váš agent, napsaný v jiném frameworku, cokoliv, ji umí používat. Je to tedy jako sdílení kontextu pro LM napříč technologiemi.

My jsme v té době viděli velký potenciál, takže jsme byli třetí framework, respektive třetí skupina, která to zaimplementovala. Samozřejmě jsme při stavbě platformy řešili, jestli to nepostavit na něčem, co už je k dispozici. A právě jsme viděli MCP, s nimiž jsme už byli v kontaktu, přispívali jsme tam, a viděli jsme tam potenciál. MCP ale tehdy moc agenty neřešilo, a vlastně stále platí, že je to na jejich roadmapě, ale mají k tomu jasné stanovisko. Pro ně je to trochu rizikové se k tomu jasně vyjádřit a udělat si na to názor. Proto jsme se rozhodli MCP forknout a přidat podporu pro agenty a sessions. Tak vznikl náš ACP – Agent Communication Protocol, který definuje, jak agent komunikuje, jaké eventy může emitovat během svého procesu a co vlastně očekávají.

MCP totiž nepodporovalo agenty, protože jejich původní poslání bylo poskytovat kontext pro LM. Přidání agentů by pak znamenalo jiný směr, že by to mohla být úplně jiná projektová rovina. Protože MCP je určený pro kontexty pro LMs, včetně toolů a zdrojů, a agent tam koncepčně úplně nesedí. Přesto ale vědí, že v dnešní době by bylo pro ně zajímavé takovou funkci přidat, protože o to mají lidé zájem. Už teď vznikají projekty, které umožňují zabalit agenta jako tool a vystavit ho do MCP – tedy agent je vlastně tool, který můžete volat. To funguje v některých přístupech, kdy probíhají handoffy, což je zatím nejjednodušší způsob, jak dělat multiagentní systém. Agent zavolá tool, který se typicky jmenuje třeba „předej požadavek na HR oddělení“ a v pozadí je to agent, kterému se přidá celý kontext a pak pokračuje dál v procesu.

MCP tedy nemá ujasněný názor, jak by měla fungovat agentní komunikace, a proto jsme se rozhodli jít vlastní cestou a tento protokol vyvíjet. MCP nám technicky vadilo více věcí – například na začátku nemělo podporu pro sessions, architektura, jak se otevírají spojení (SSR), byla zvláštní. Hlavně je založené na JSON RPC, který vznikl někdy mezi lety 2010-2013 a který vlastně není tak flexibilní pro dnešní potřeby.

Pokud chceš, můžu text ještě více upravit stylisticky nebo ho rozdělit do kratších odstavců.

Tady je opravený text s úpravami pro srozumitelnost, správnou gramatiku a styl:

Názor na streamování. Má i pravidla, která říkají, jak má streamování vypadat a jak ne. Když si to člověk přečte, tak jediný způsob, jak dělat streamování, je přes notifikace, ale standard zároveň říká, že klient je může ignorovat. Tím pádem se dostáváme k problému, že není možné streamování vyřešit jen pomocí protokolu, aniž by nedošlo k jeho porušení. Proto máme otevřený pull request, který tuto podporu přidává, ale nedomluvili jsme se na něm, protože tam jsou koncepční problémy.

Začali jsme tedy pracovat na ACP, který je čistě založený na REST API a vlastním komunikačním protokolu. Měli jsme podporu pro stavy, takže agent při spuštění mohl být ve více stavech. Pomocí konceptu, kterému říkáme Await, se dokázal zastavit a říct například: „K tomu, abych mohl pokračovat, potřebuji tuto informaci.“ Mohl si tedy vyžádat dodatečný vstup od uživatele nebo třeba data, která právě nejsou dostupná. Tato podpora tam byla implementována.

Celý systém jsme takto vyvíjeli a framework se přitom dále vylepšoval. Řešil integraci všech vznikajících protokolů, takže pokud si někdo vytvořil agenta, mohl ho jednoduše nasadit do ACP-kompatibilního serveru nebo MCP-kompatibilního serveru jedním příkazem. Framework tak fungoval jako první třída (first class citizen) platformy i ACP a usnadňoval obousměrnou komunikaci i samotný vývoj agentů.

Tímto způsobem jste vlastně dali do hry protokol, který se snaží standardizovat.

Přesně tak, a k tomu se váže i nedávný příběh, kdy jsme byli v Americe a řešili směřování platformy a protokolu – jak věci bude dělat, co si myslíme, že MCP bude dělat a jak se k tomu stavět. Najednou někdo přišel s informací, že Google právě zveřejnil protokol pro agentní komunikaci založený na A2A. Bylo to v dubnu, týden po tom, co jsme vydali ACP. Samozřejmě jste řekli: „Vy jste Google, tak to tak musíte prodávat,“ to je jasné. Ale z interní komunikace vím, že s nimi aktivně komunikujeme a řešíme směřování celého agentního vývoje a budoucí směr. Víme, že je zbytečné, aby těch úsilí bylo několik, a rádi bychom co nejvíc spolupracovali a předávali si znalosti.

Celý projekt původně vznikl jako inner source, nebyl tedy open source. V rámci projektu vznikl framework a GPT platforma. Na konci roku 2024 jsme se rozhodli vše zpřístupnit veřejně jako open source, protože IBM má dlouhodobě velké zkušenosti s open sourcem, především díky Red Hatu, a má názor, že přesně tyto věci by se měly sdílet a společně vyvíjet. Projekt jsme proto uvolnili do světa a následně jsme ho darovali pod Linux Foundation.

Pokud chcete, mohu pomoci i s dalšími úpravami nebo vysvětlit určité části textu.

Zde je opravený text s úpravami pro lepší srozumitelnost, gramatiku a interpunkci:

Úspěšných projektů, jako třeba Kubernetes, Milvus DB a teď vlastně A2A. A možná když se u toho zastavím, co to pro vás znamenalo? Znamenalo to dopsat dokumentaci, dodělat nějaké věci? Nebo je to spíš o tom publish? Prostě pošleš codebase na GitHub? Stále je to pod organizací IBM, kterou jsem měl tu možnost právě v řadě založit, takže je založená pod mým IBMáckým mailem ještě dodnes. Vlastně to znamená, že je nějaké období, kdy my maintenancujeme tu věc, ale posléze to přejde do toho, že to bude spravovat komunita. A bude tam nějaká open governance, budou tam zodpovědní lidé a firmy, které se k tomu můžou vyjadřovat, a je to komunitně řízené.

Tady bych chtěl říct, že i do A2A teď máme otevřené nějaké diskuze a vlastně pull requesty k tomu, co bychom tam mohli přidat, jak by se za nás mohly řešit různé věci, ať už třeba když agent má nějaké požadavky k tomu, aby byl spuštěný – například potřebuje databázi nebo nějaký model (LM) – tak aby si o to v té kartě mohl říct a aby mu to bylo dodané, jinak by se nespustil.

No a ještě možná, když srovnáš ACP a A2A, mě vlastně překvapilo, jak rozdílní jsou MCP a ACP – právě že nepočítají s agenty a staví na JSON RPC. My například ten JSON RPC nepoužíváme, někdo ano, takže MCP a ACP jsou dost odlišní, mají různé úlohy. Ale když se podíváme právě na ACP a A2A, tam už samozřejmě ten overlap je, protože řeší tu stejnou věc – komunikaci agent a agent, jak má komunikovat. Jsou tam společné charakteristiky, například to, že když dochází k té komunikaci, tak je tam koncept zprávy, která reprezentuje tu komunikaci – jeden cyklus v ní. Zpráva má nějaký obsah a mohou to být různé podtypy, buď textová zpráva, nebo nějaký kus souboru, nebo artefakt. To má podobně i ACP.

Liší se třeba v tom, že A2A je založený na JSON RPC, používají tam REST pro komunikaci. Abychom byli přesní, A2A je čistě na RESTu, ale právě tam dochází k tomu, že porušují JSON RPC kvůli streamování – posílají data v RPC formátu, ale tím to vlastně porušují. Dává to smysl, pokud jde o definici porušení, ale řeší tím fundamentální věc, kterou ten protokol podporuje.

Pak jsou ještě odlišnosti v tom, jak probíhá životní cyklus agenta. Tam mají tásky (tasks), my používáme stavový automat (state machine), kterým to reprezentujeme, a tak dále. Ale samozřejmě do budoucna je vyhlídka, že Google to semele, protože má extrémně...

…a společnosti, které zatím stojí. Nicméně my jenom máme protokol, ale jsme právě ta platforma, která je velice unikátní, a máme framework. Jak jsme se bavili o tom, že je komplikované zaručit, aby jazykový model generoval výstup v požadovaném formátu, tak se to za poslední dva roky značně posunulo. Posunulo se to v tom, že tool calling se delegoval z promptového systému, kde jsme vymýšleli speciální syntaxi, na stranu poskytovatele, kde jsme řekli: tady jsou tooly, které můžeš zavolat, a ty nám jeden z nich zavolej. A myslím…

Pokud budete chtít, můžu pomoci i s finální úpravou nebo úpravou stylu.

Opravený text:

Mysleli jsme si, že je to vyřešený problém, ale není, protože se nám stále stává, že uděláme tohle, ale API poskytovatel může nástroj ignorovat a prostě ho nezavolá. Může se stát, že dostaneme výsledek, který je sice správný, ale vůbec není podložený nějakými fakty. Proto je tento framework stále unikátní v tom, že cílí na malé modely.

Je zde také poslední inovace – requirement agent, který funguje na principu zajištění vykonání určitých kroků. Co to znamená v praxi? Když pustíme tohoto agenta na takovém modelu, můžeme si například všimnout, že pokud se ho zeptáme, jaké je počasí, měl by se nejdříve doptat, kde to máme zjistit, místo aby jen hádal. Nebo pokud má k dispozici nástroj, který mu poskytne kontext o uživateli, měl by ho nejdřív zavolat, protože víme, že tam ta informace je.

Co můžeme zkusit, je upravit instrukce modelu a říct mu: „Vždycky, když nevíš, zavolej tento nástroj, on ti poradí.“ Super, ono to funguje, ale pak se stane, že vstup bude třeba s gramatickou chybou nebo nějakým překlepem a agent to zase neudělá. A my můžeme vždycky říct, že jsme to evaluovali na datasetu a tam to z 95 % vždycky prošlo. Ale to není garance.

Právě to řeší requirement agent, který programově stanoví, že například daný nástroj může být použit maximálně dvakrát a jen po dokončení jiného nástroje. Nebo pokud bude výsledek volání třeba do Wikipedie prázdný, donutíme model, aby ten nástroj zavolal znovu, dokud nevrátí alespoň jeden výsledek. To všechno se řeší na programové úrovni.

Takže žádné další otravování uživatelů s tím, aby se stali prompt inženýry a doufali, že agent něco vytvoří. Teď máme unikátní způsob, jak programově definovat podmínky – co se má stát, když… A vlastně nám to pomáhá upravovat a přibližovat agenta, který je extrémně nedeterministický, k workflow, které jsou naopak statické a extrémně deterministické, ale někdy až příliš rigidní.

Pod těmito podmínkami tedy můžeme říct, jak agenta přibližovat k workflow a naopak.

Kdybych to měl shrnout – pro koho je BIA? Je určený pro lidi, kteří potřebují, aby jejich malé modely byly spolehlivé. Pro ty, kteří hledají právě toto, je tu BIA framework. Pro ty, kteří chtějí své agenty sdílet třeba v rámci organizace nebo s klientem, nechtějí kvůli tomu psát vlastní uživatelské rozhraní ani vymýšlet, jak má komunikace probíhat, je zde platforma. A pro ty, kteří mají vše vyřešené a jen nemají vyjasněné, jak propojit více agentů mezi sebou, je tu ACP.

Otázka: Implementuje platforma ACP? Ano, platforma ACP interně implementuje.

Další otázka: Je platforma kód, který si může každý nasadit ve vlastní firmě do Virtual Private Cloudu, nebo je to centralizovaná cloudová služba, kterou vy poskytujete?

(tu poslední větu jsem nechal nedokončenou, protože text nebyl celý)

Jasně, tady je opravený text s plynulejším a jasnějším vyjádřením:

Kód je otevřený a podle návodu ho lze celý deploňovat do vlastního on-premise cloudu, a to v aktuální nejnovější verzi. Jakmile je to hotové, člověk si pak může přidat agenta už bez zásahů do kódu. Platformovou kompatibilitu agenta zajišťuje SDK, které to jednoduše umožní. Takže to je super.

Jak to teda vidíš teďka z pohledu budoucnosti BIA, celé platformy a celého ekosystému?

Myslím si, že máme dobré postavení, protože nemáme jen jeden projekt, ale děláme široký záběr činností, které se navzájem spíš doplňují, než aby si konkurovaly.

Jo, souhlasím. Nedávno jsme o tom mluvili – třeba z pohledu frameworku a vývoje agentů – může přijít změna, kdy například nebude potřeba koncept, který jsem popsal. V budoucnu se víc funkcionalit deleguje na poskytovatele a nebude třeba tolik řešit prompt engineering nebo mechanismy, jak garantovat správnost odpovědí. Například nedávno vyšel nový GPT-OSS model s formátem Harmony Response, který přesně definuje novou roli a dělá instrukce granulárnějšími. Klíčovou změnou je, že výstupy obsahují speciální tokeny, které ohraničují části, v nichž model komentuje nebo uvádí úroveň důvěry ve svou odpověď, tedy role ve výstupu.

Dosud to bylo třeba programovat tak, že jsme říkali modelu, aby něco nejdřív napsal, pak něco dalšího, a my jsme to pak parsovali a zpracovávali. Tohle se podle mě bude více delegovat na poskytovatele služeb a uživateli to přinese přímější a jednodušší použití.

Do budoucna určitě vidím multiagentní přístup jako cestu, jak věci tvořit – jeden agent totiž nemůže zvládnout všechno. Trendem bude generování agentů na základě typu úkolu, přičemž se mu dosadí odpovídající sada nástrojů MCP (Multi-Channel Pipeline). Programátor tak bude mít svou roli s nástroji přímo nastavenými na daný účel.

Současně předpokládám, že se bude používat protokol jako třeba A2A. Uvidíme – myslím si, že pro A2A bude velkým konkurentem MCP, protože MCP je oblíbené a používané, ale A2A je složitější na ovládání a má těžší klientskou aplikaci. MCP už je docela zažitá a upevněná platforma. Na druhou stranu může být pro ně riskantní teď otočit projekt směrem, jak vidí agenty a celý ekosystém A2A.

No a omlouvám se, že tě teď přerušuji, ale když mluvíme o těch abstraktních věcech – ty jsi ve firmách, které dělají MCP (Anthropic) nebo A2A (Google), takže máš přehled. MCP je lightweight a nejvíc používaný standard, který teď roste, zatímco u…

Pokud chceš, mohu text ještě více upravit nebo přizpůsobit styl podle potřeby.

Tady je opravený text:

PCI, má to komoditu super, a teď je to OK. Víš, že potřebuješ to povýšit na agentní, protože to bude potřeba. Co to vlastně znamená a proč to není jednoduché? Protože je to zapečené opravdu hodně hluboko, a proto to musíš vlastně začít na zelené louce, nebo to vždycky ohnout jako JSON RPC? Co jim vlastně brání? Já si myslím, že je jednoduché si ty věci udělat lokálně – říct si: „Chci mít víc agentů, pak je budu předávat, něco si vymyslím,“ to jde jednoduše.

Problém je, že ty věci jsou složité, jakmile mají být generalizované tak, aby vyhovovaly všem. Teď, když si někdo bude chtít něco tvořit, bude to klasický projekt. Nějak to bude napsané podle něčích myšlenek, ale aby se dosáhlo toho, že mohu jednoduše použít a zintegrovat svůj systém s nějakým úplně cizím agentem, který někdo vymyslel na druhé straně světa, to je vždycky problém, pokud neexistuje standard.

Zatímco pokud bude ten standard, může být na agenta přidána značka, že je třeba ACP kompatibilní, a člověk hned ví, že ho může na jeden řádek propojit s vlastním agentem a může něco tvořit. Takže všechny ty věci jsou s tímto přístupem možné do určité úrovně, ale člověk bude trpět tím, že jakmile bude chtít udělat další integraci, bude to vždycky custom, pracné a nepřehledné. Jestli jsem na to takhle odpověděl. Tak jo, to je super budoucnost pro vás, ale co budoucnost nás všech s ACP a obecně s agenty – jak to vidíš?

S tím, co všechno děláme a co se na trhu objevuje, si myslím, že se integrace bude extrémně zjednodušovat. Dnes, když má člověk nějakou aplikaci s plugin systémem, bude si moct na jedno kliknutí dointegrovat něco, co bylo vybudované podle nějakého protokolu. A chci, aby se používaly běžné, zažité přístupy z klasického softwarového inženýrství – něco podobného lze očekávat i v oblasti generativní AI.

Abych rovnou zmínil i nějaké projekty, které jsem viděl a které lidi budovali – protože jsou open source, spousta z nich je na LinkedInu, YouTube a dalších platformách. Například si vybavuji projekt související s kvantovou kryptografií, protože se říká, že kvantová éra nastane kolem 2030. Pamatuji si na aplikaci – bota, který automaticky procházel různé repozitáře a dokázal detekovat, které kryptografické šifry použité v projektech budou problémové, nesplňují požadavky a měly by být překonfigurovány.

V IBM byl velice úspěšný projekt DocLink pro zpracování dokumentů, OCR a extrakci dat – byla s ním integrace, která vytvořila kompletní pipeline a součástí byl BI systém. Pak byl skvělý projekt na zpracování pojistných událostí – pojišťovny ho používaly a celý systém poháněl BI framework nebo ambient agenti, kteří byli zapojení do prostředí a reaktivně na situace reagovali, třeba to může být... (pokračování).

Zde je opravený text s plynulejším a srozumitelnějším stylem:

Slack nebo takhle – když ten agent něco ví a je schopný třeba zodpovědět otázku, tak si tu věc dohlédne a odpoví. Všechny ty témata, která jsem zmínil, byla buď uveřejněná v rámci různých IBM callů, ale BI jako organizace má také své měsíční meetingy, kde se diskutují aktuální projekty a novinky, na kterých se pracuje. Při těchto setkáních mají uživatelé možnost promluvit a vyjádřit se, ať už přímo na meetingu, nebo v open source diskuzích.

Snažíme se, aby všechny naše projekty byly community-driven a abychom naslouchali zpětné vazbě. Všechny projekty byly napsané uvnitř BI, zveřejněné na Bplatformě, a teď běží ve svých implementacích – používají je uživatelé a komunitu. To je skvělé, takže se dá říct, že BI je teď globální projekt.

Rozhodně. Měli jsme možnost, když se naše projekty uveřejnily jako open source a stali jsme se součástí Linux Foundation, účastnit se různých konferencí. Měl jsem třeba možnost vystoupit na Open Source Summitu ve Vídni, kde jsem mluvil o agentech a BI frameworku. Byli jsme také v Las Vegas na týdenní konferenci, kde jsme řešili podobná témata. Spousta dalších akcí se účastnili i moji kolegové z Čech nebo přímo z IBM.

Jedním z našich největších úspěchů je, že jsme se dostali do Deep Learning AI – velkého projektu, který slouží jako platforma pro učení o AI. Máme tam vlastní kurz na ACP, který získal skvělé hodnocení, což je pro nás velký úspěch.

Celkově je pro nás zásadní, že s námi chtějí komunikovat firmy jako Google a že můžeme přispívat do jejich projektů. Také vidíme, jaký to má dopad na lidi po celém světě – jak na internetu, tak i přímo v IBM. Je zajímavé být na Slacku, kdy vám napíše člověk z Taiwanu, pak někdo ze San Francisca a další z Izraele. Spolupracovat s těmito lidmi, poznávat je a sledovat, co budují, je opravdu inspirující.

To, že naše práce pomáhá a zlepšuje celkový obraz IBM, je pro nás velkou motivací.

Pokud tedy posloucháš tento podcast a jsi teď inspirovaný přidat se k tomuto globálnímu projektu, který mění svět přímo z Prahy...

Najímáte?

Přesně tak! Hledáme nové lidi prakticky celý rok. Chceme najít zajímavé, odvážné talenty, kteří se nebojí řešit náročné problémy, jsou otevření novým příležitostem a nechtějí se škatulkovat. Místo pro talent je u nás vždy. Možná za rok budeme dělat něco úplně jiného, ale věřím, že to bude minimálně stejně zajímavé jako to, co děláme teď.

Moc děkujeme za rozhovor a věřím, že tvoji kolegové z Apoka nebo ty nám brzy dáte další update o tom, jak se celá AI infrastruktura dál vyvíjí a co se tady v Praze vlastně tvoří. Je to opravdu fascinující.

Pokud chceš, mohu text ještě více upravit nebo zhuštit.

Jistě, tady je opravený text:

Mám tady taková „želízka v ohni“ a můžete z Prahy pracovat na A2A nebo ACP, a přeneseně i na A2A protokolech, které určují, jak bude vypadat budoucnost. Takže moc díky, že s námi sdílíte svou zkušenost s tím, jak se to děje a co to znamená. Děkuji moc za pozvání a budu rád, když budu moci já nebo moji kolegové předat další znalosti a ukázat všem, že i z Prahy se dá působit na globální úrovni. Díky a hodně štěstí.

Děkujeme, že jste doposlouchali až sem, a také děkujeme našim partnerům a členům Data Talk klubu. Těmi jsou Intex, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Carl Data Company, Data Mind, Notino a Flo.

Pokud chcete zůstat v obraze ohledně české datové scény a globálních datových technologií, nezapomeňte se zaregistrovat k odběru našeho týdenního newsletteru na datatalk.cz. Nechť vás provází data.

Pokud chcete, mohu ještě více text upravit dle stylu, tónu nebo formálnosti.