Podcast

Dobrý den, moje jméno je Jirka Vecherek a vítám vás u dalšího dílu podcastu Datatalk. Mým dnešním hostem je Matouš Havlena, zakladatel a Head of Engineering společnosti Apoco. Ahoj, Matouši.
Ahoj, Jirko.

Dneska se s Matoušem podíváme na jeho cestu a kariéru, která ho vedla až k založení vlastní firmy Apoco. Povíme si také, co Apoco dělá, protože děláte opravdu zajímavé a cutting edge věci. A přestože to spousta firem tvrdí, vy to skutečně žijete. Budeme se bavit i o tom, jak vypadá současný prostor s agentní infrastrukturou, což je také oblast, na které pracujete. Matouši, možná začněme od začátku. Jak začala tvoje cesta? Jaký je to story of my life?
Já bych začal úplně od začátku, stručně. Začalo to asi v třinácti letech, kdy jsme doma měli počítač – myslím, že to byla 486 nebo 386, už si to přesně nepamatuji. Vždycky mě lákalo, co všechno ty počítače umí. V té době jsem je spíš rozbíjel a konfiguroval, což rodiče moc neocenili, protože často něco přestalo fungovat.

Jeden zásadní moment si stále pamatuji: když mi bylo třináct, šel jsem s mamkou do knihkupectví koupit nějaké časopisy. V té době jsem byl nadšený z Kačera Donalda a podobně. Nakonec jsem si ale místo časopisu koupil knihu s názvem „PHP – tvorba interaktivních webových aplikací“ od Jirky Koska. Tu knihu mám dodnes v kanceláři a občas se do ní podívám. Z nějakého důvodu jsem přesvědčil mamku, aby mi tuhle poměrně drahou knihu koupila místo časopisu. A právě tím vlastně začala moje kariéra programátora. Od té doby programuji, tedy už od třinácti let.

To byl opravdu silný start. Předpokládám, že tu knihu stále vlastně máš.
Ano, mám ji dodnes. V té době mamka vůbec netušila, co je programování. Já sám také moc ne, ale měl jsem pocit, že konečně počítač mohu ovládat a dělat s ním víc než ho jen rozbíjet. Mohu mu říkat, co má dělat, automatizovat nějaké úkoly a podobně.
Já vůbec nechápu, jak jsi mamku tehdy přesvědčil, ale podařilo se – to byla asi zásadní chvíle pro mojí kariéru.

Co následovalo potom?
Když jsi v třinácti začal díky té PHP knize programovat, začal jsi dělat i nějaké brigády nebo weby kamarádům?
Přesně tak. Začínal jsem dělat webové stránky pro školy a nějaké neziskové organizace, tedy spíš nekomerční projekty.
Pak přišly první projekty, které už přinášely peníze. Myslím, že mi bylo asi šestnáct, když jsem dostal první placenou práci jako PHP programátor, i když se to tehdy ještě označovalo za JavaScript vývoj. Dělal jsem jednoduché weby. Takže od šestnácti jsem kombinoval práci se studiem.
A pro jakou firmu jsi tehdy pracoval?
Jo, byla to lokální firma… (pokračování v původním textu)

Bydleli jsme kousek od nich. A většina těch věcí byla samozřejmě po večerech, a odpoledne jsem měl volný čas. No, tak jsem dokončil střední školu a asi šel na nějakou informatiku, předpokládám.

Jo, jo, přesně. Já jsem šel na Masarykovu univerzitu, na Fakultu informatiky.

A proč právě Masarykovu univerzitu?

Já jsem vůbec nezvažoval Prahu z nějakého důvodu. Jsem z východních Čech a Brno bylo blízko, takže kvůli tomu, abych byl blízko rodině. Dal jsem si přihlášku primárně tam, chtěl jsem se tam dostat, a také jsem se tam dostal. Začala ta moje akademická zkušenost s univerzitou, což byla úplná pecka. Strašně se mi to líbilo a užíval jsem si studijní věci, protože konečně mi lidi dávali ty informace. Už jsem nemusel číst knížky a snažit se pochopit věci sám, protože tam jsem měl člověka, který mi dával životní zkušenosti. Měli jsme tam předměty, jejichž vyučující prošli velkými korporáty či zajímavými projekty. To bylo pro mě obrovské otevření očí a moje vzpomínky na univerzitní roky jsou jen pozitivní.

Co byla opravdu velká změna pro mě. To dělá to Brno, podle mé vlastní zkušenosti – vysoká škola v Brně je nejlepší možností.

Co se dělo pak?

No, pak přišel magisterský studijní program a během něj jsem stále pracoval jako programátor v nějaké společnosti. Při magisterském studiu jsem přišel na to, že bych se mohl přihlásit na stáž do IBM, na nějaký board. Na Masarykově univerzitě to bylo vypsané. Říkal jsem si, že to zní zajímavě, přihlásil jsem se a dostal jsem se na stáž do IBM v Praze. Začal jsem tam pracovat na pozici technického pre-sale. Přiznávám, že zpočátku to nebylo úplně ideální vůči mým dovednostem, ale na konci dne to asi bylo fajn, protože to bylo trochu náročné. Možná se k tomu ještě vrátíme, jsem totiž trošku i businessově orientovaný člověk. Tam jsem měl první kontakt s byznysem, s korporátem, a hlavně s IBM, protože jak uvidíš později, IBM hraje v mé kariéře obrovskou roli. Takže přišla tahle stáž.

Současně přišel i Erasmus – tak jsem jel studovat na semestr do Anglie. Současně jsem se rozhodl… Mám bráchu, identického dvojčete, a o tom se zřejmě ještě zmíníme podrobněji. Studovali jsme spolu na Masarykově univerzitě – on ekonomiku, takže není úplně technický člověk jako já, který studoval informatiku. Hecli jsme se, že si při studiu přidáme ještě něco dalšího. Já jsem začal studovat i ekonomiku, on si vybral práva. Možná to odráží vzorec mého života – že dělám hodně věcí souběžně. A možná to souvisí s tím, co nakonec dělá Apoko jako společnost, protože to mé fungování se tam odráží.

Pro kontext – Apoko jste založili s bráchou, takže o něm mluvíme vlastně docela brzy.

Jo, přesně tak.

Takže jsi si k tomu přidal ekonomiku a zároveň stážuješ v IBM v Praze.

Jo, přesně tak. Hektický život, ale všechno jsem se snažil nějak zkombinovat.

Co jsem…

Se vrátil jsem po Erasmu a říkal jsem si, že to byla super zkušenost – vycestovat ven, opustit komfortní zónu, když to tak řeknu, protože já jsem docela introvertní člověk. To bylo první kroky, kdy jsem žil sám někde, staral se sám o sebe a bavil se s ostatními lidmi. Pak jsem se vrátil a říkal si: „Tyjo... A být bez bráchy.“ Jo, přesně tak. To bylo těžké, být bez bráchy. Ale já jsem byl vlastně ten první a on potom následoval mou cestu a taky někam vycestoval. Myslím, že on pak vycestoval do Kanady. Já si říkal, že to byla super zkušenost a chtěl jsem to ještě jednou, ale možná na vyšší úrovni. Říkal jsem si, že se chci podívat do Ameriky, a tak jsem šel studovat do Ameriky. Co to bylo za rok? Jestli si dobře pamatuju, tak 2012. Takže v roce 2012 jsi šel do Ameriky studovat? Jo. Přes nějaký program masarykovy univerzity. Přesně tak, studoval jsem informatiku. Přijel jsem do Ameriky na univerzitu v Tennessee, tak žádná špičková škola samozřejmě – průměrná státní univerzita. Co bych asi řekl – informatika tam byla strašná nuda. Učitelé nebyli vůbec na špičkové úrovni, a ve srovnání s Masarykovou univerzitou to byl fakt krok zpět. Drastický docela. To mě trochu vadilo, ale souběžně měla ta škola MBA program, velice dobrý, nějak akreditovaný a byla v top 10 % MBA škol na světě. Tak jsem si řekl, že když už tu studuju ekonomiku, zkusím si dělat MBA. A to byl další velký milník mého života, protože jsem vystudoval MBA a tam jsem potkal i svoji manželku během studií.

Ještě jedna věc, jak jsem říkal, dělám hodně věcí souběžně. To se projevilo i zde. Měl jsem stáž v IBM v Čechách a když jsem přišel do Ameriky, zkusil jsem zajít do lokálního kanceláře, zaklepat na dveře a zeptat se, jestli náhodou nemají nějakou práci. A vyšlo mi to. Počkej, mně se líbí ta vizuálnost, ta fyzičnost – úplně si tě představuju, jak v Tennessee hledáš kancelář, na recepci, která tam má vše pod kontrolou a říká IBM, proč jsi neposlal e-mail? Nebo jsi poslal e-mail a neodpověděli, tak jsi šel tam osobně? Ne, poslal jsem e-mail, ale ne do té kanceláře, hledal jsem nějakého akademického zástupce v IBM, který by mi řekl...

Ale stále jsem hledal, byl jsem v Americe a ten člověk mě doporučil, abych prostě zkusil přijít do té kanceláře osobně. Takže tam nebylo žádné předchozí domluvení. Opravdu jsem přišel, zaklepal na dveře, řekl, kdo jsem a co dělám. Poslali mě za správným člověkem, který mě dostal k dalšímu, což byla strašná náhoda, samozřejmě – tohle se podle mě moc nestává – a potkal jsem svého budoucího manažera, který byl jeden z nejlepších manažerů, které jsem kdy měl. Člověka, který mi nabídl příležitost a věřil ve mně. A to jsem přišel jako člověk z východní Evropy, který měl ještě samozřejmě, ne špatnou angličtinu, ale bylo jasné, že nemám úplně nejlepší americkou výslovnost a tak podobně. Věřil mi a dal mi ty možnosti. A zpočátku jsem jim samozřejmě pomáhal zadarmo...

Opravený text:

O, měl jsem nějaké zkušenosti s IBM, takže to nebylo, že bych jim neměl co nabídnout. A oni zjistili, že jsem docela technicky zdatný a že jim můžu pomoct, takže jsme spolupracovali. Já jsem tam byl opět technický pre-sales, takže jsem odpovídal na různé RFI (Request for Information) a RFP (Request for Proposal). Třeba jsme dělali pro Bank of America, která chtěla nakoupit nějaký software od IBM, nebo napojit nějaký software na řešení svého problému, a IBM byl jeden z uchazečů. My jsme prostě dělali odpovědi na otázky typu, jak řešíte toto nebo tamto, jak ten produkt pracuje s těmito věcmi. Byl to můj první kontakt s americkým byznysem a hlavně i se způsobem, jakým IBM funguje v Americe, což je trochu jiné než v Evropě, i když je to mezinárodní společnost. Souběžně mě můj manažer vždy dával příležitosti dělat něco víc, takže mě poslal na technické konference, což bylo úplně super. Díky tomu jsem se podíval do několika měst, letěl jsem na Floridu a už si nepamatuju, kde všude jsem měl možnost být, a seděl jsem na těch konferencích, naslouchal lidem, co prezentovali produkty. V té době hodně běželo Big Data, takže se řešilo hodně věcí kolem Hadoopu a podobně. Za mě to byla úplná pecka, že jsem měl takovou možnost díky svému manažerovi. A říkám si, že jsem potkal manažera, který není běžný a opravdu mi dal tyto příležitosti.

Ohledně IBM, je to velká firma s mnoha divizemi a projekty. V jaké části jsi byl ty nebo čeho se to týkalo?
Hele, to byl Rational, který podle mě dnes už neexistuje. Byly to všechny nástroje týkající se vývoje softwaru, od projektového managementu, přes nástroje podobné Gitu nebo alternativy ke Gitu, správu zdrojových kódů, správu úkolů, sbírání požadavků a podobně. Těch nástrojů tam bylo hodně. Něco jako IBM Atlassian.
Ano, přesně tak.

Jak dlouho jsi byl v Americe? Potkal jsi tam svoji ženu a začali jste spolu podnikat, takže asi na dlouho, ne?
Byl jsem tam rok a půl a studoval MBA, což normálně trvá dva roky, ale já jsem to zvládnul rychleji, protože mi uznali nějaké kredity z Čech, z ekonomky. Takže v roce 2013 jsem promovál a ještě než jsem promovál, přemýšlel jsem o tom, co dál. V té době mě samozřejmě technologie a technické věci zajímaly, ale to samo o sobě mi nestačilo. Jsem programátor, mezi tím jsem furt něco programoval a...

A jaký jsi měl tech stack? Bylo to ještě PHP, nebo spíš JavaScript?
Byl to mix, jo. PHP už moc ne. Předtím jsem v nějaké společnosti dělal v C# (C Sharp), takže jsem měl zkušenosti s C# a .NETem. JavaScript byl samozřejmě hojně používaný, to nelze popřít. V té době se také hodně používala Java.

Tady je opravený text s úpravami gramatiky, interpunkce a stylu pro lepší srozumitelnost:

Takže já jsem zkusil dost programovacích jazyků. Ale už si teď ani zpětně nepamatuji, který byl asi ten nejdůležitější. No, ale byl jsi programátor, ne? Jo, jo, určitě. A technický přísah byl pro tebe důležitý? Nebo technický obor? Ne, ne, úplně ne. To pro mě nebylo až tak zajímavé, a proto vlastně další můj milník bylo rozhodnutí, kam dál. A to bylo IBM Research. Říkal jsem si: jsem programátor, zajímají mě technologie a chci dělat věci na cutting edge, tedy to, co je dneska možné. A Research mi připadal právě jako to správné místo. Navíc jsem si říkal, že by bylo pěkné získat nějaký patent. To mě pak ale brzo přešlo, i když nějaký patent mám dodnes.

Přihlásil jsem se na stáž do IBM Research v New Yorku a náhodou mě z nějakého důvodu vzali. Po promoci jsem se tedy přestěhoval z Tennessee do New Yorku a začal tam pracovat. Takže o IBM Research budeme ještě hodně mluvit. A pokud s nimi spolupracujete, že jsou pro vás nejdůležitějším klientem, možná by vás zajímalo, jakou roli IBM Research má, co vlastně je, jak je to velké a co je na něm zajímavé. Člověk si může představit New York City, mrakodrapy a tisíc programátorů, z nichž pět set je chytřejších než vy. Tak ale IBM Research vůbec nevypadá takhle.

Objasním to. Když říkám, že jsem se přestěhoval do New Yorku, myslím stát New York, ne město New York. IBM Research má hlavní centrum ve městě Yorktown Heights, což je kousek, asi hodinu jízdy od New York City. Je to research centrum uprostřed ničeho, uprostřed lesa, což se mi moc líbilo. Je to ideální prostor, kde člověk má klid na práci. Když se podíváte na typ lidí, které tam potkáte, neřekl bych, že jsou to jen programátoři. Spíš vědci, nerdové, programátoři samozřejmě také, ale všechno to jde ruku v ruce. Centrum je třípodlažní budova, žádný mrakodrap. Tak začal můj vztah s IBM Research, který trvá dodnes.

Jakou roli má IBM Research v rámci IBM? Je to taková společnost ve společnosti, hodně nezávislá vůči zbytku IBM, což je skvělé. Myslím, že má 5 000 až 6 000 zaměstnanců po celém světě. Nechci se mýlit, ale myslím, že má kolem 12 až 13 laboratoří na téměř všech kontinentech. V Evropě jsou údajně dva laby, v Anglii a ve Švýcarsku. Jejich mandát je "what's next" – tedy zkoumat a vyvíjet průlomové technologie, které se objeví za rok, dva, pět, deset či dvacet let. Klasický výzkum.

A v době, kdy jsi tam nastoupil – bylo to 2014, že? Jo, 2014. Tak co bylo v roce 2014 "next"? Určitě AI bylo jedna z důležitých oblastí, ale AI, o kterém mluvíme dnes, ještě nepoužívalo transformery, kterých je dnes tolik. Šlo spíš o tradiční machine learning, jak se dnes označuje. Ale myslím, že to bylo p---

Pokud chceš, mohu pokračovat nebo text dále upravit.

O té době, kdy IBM Watson vyhrál Jeopardy, tu americkou soutěž, se pořád jezdilo na této vlně. A samozřejmě se tehdy vyvíjely kvantové počítače, o kterých si dneska najdu víc informací a možná o nich potom můžeme taky rychle mluvit. Bylo toho tehdy hodně – polovodiče (semiconductors) a různé fyzické technologie, ke kterým jsem já osobně neměl takový vztah, protože jsem byl především software engineer. Byl jsem blíž spíš k AI, k oblastem jako computer vision, dělali jsme nějaké kognitivní dialogové systémy, což je vlastně zase zpátky k AI. A samozřejmě velkým tématem byly i big data a IoT, což tehdy taky hodně frčelo.

Co se týče stacku nebo mandátu, na čem jsem vlastně pracoval – mám pocit, že IBM Watson je opravdu světoznámý a byl ten průlomový projekt IBM. Ale jinak jsem měl pocit, že IBM trochu hrálo druhé housle – měli podobné technologie jako ostatní, ale nikdy to nebylo úplně to nej, nejlepší nejlepší.

Jo, to je určitě validní pozorování, řekl bych. Těžko říct, úplně si nepamatuju detaily té doby, protože jsem byl stážista, takže jsem se určitě nedostal k top projektům, nepodílel jsem se na těch nejdůležitějších algoritmech. Spíš jsem se většinou pohyboval na úrovni aplikovaného výzkumu (applied research) – vzít výsledky výzkumu a zkusit je nějak aplikovat. Vytvořit důkaz koncepce (proof of concept) se zákazníkem, posunout to dál a získat nějaké poznatky.

Hodně jsem se točil kolem kognitivních dialogových systémů. To znamenalo například chytré místnosti, kde člověk vstoupil, udělal se computer vision – rozpoznání obličeje, zjistilo se, kdo to je, načetly se o něm informace, a před ním byla obrovská obrazovka, na které se zobrazovala nějaká data. Ten člověk s nimi mohl interagovat buď dotykem na obrazovce, nebo hlasem. Dělali jsme tedy spoustu věcí v konceptech chytrých místností.

To byla jedna z mých oblastí. Pak jsem se díky tomu, že to byla stáž, dostal i k jiným věcem – například k implementaci serverless cloudových služeb. Kdo zná AVS nebo AWS Lambda, tak IBM se v té době snažila vytvořit vlastní alternativu k AWS Lambda, takže na tom jsem chvíli pracoval.

Potom jsem se dostal k projektům s geograficko-prostorovými (GeoSpatial) analytickými službami, které sbíraly data z různých zdrojů, hlavně ze satelitů, a poskytovaly je jako vrstvy, které bylo možné dotazovat a kombinovat. Tohle mi přijde zajímavé i teď, viděl jsem toho teď v Česku startup SpaceNow, který dělá hodně podobnou věc. Byl to opravdu analytický systém, kde uživatel mohl přijít a detailně si tato data prohlížet.

Tady je opravený text s důrazem na srozumitelnost, gramatiku a interpunkci:

Tak třeba zjednoduším – podívejme se na New York. Řekněme, že tam byly k dispozici data typu teplot nebo předpovědí počasí a třeba informace o pohybu lidí z mobilních zařízení. Na základě toho si mohl určit, kde se lidi v těch teplých dnech pohybují nejvíc, a podle toho si třeba postavit stánek se zmrzlinou. Tak zjednodušeně.

Samozřejmě tam byly i další, zajímavější use case, protože satelitních dat je hodně. Například když se použijí LiDAR technologie, můžeš si namapovat 3D terén. To se například využívalo v energetice k tomu, že se zjišťovalo, kde vedou elektrické kabely a kde zarůstají stromy. Amerika je obrovská země, takže díky tomu se dá ušetřit hodně peněz – ze satelitu zjistíš, kde je potřeba někoho poslat a pokácet stromy, aby nespadly na elektrické vedení.

Nebo se používaly informace o tom, co který farmář zasadil. Z těch satelitních snímků, respektive ze spektra světla, které naše oko nevidí, se dá zjistit, co a kde roste – například zda jde o pšenici nebo kukuřici. Na základě toho lze dělat různé predikce, například jaké plodiny farmář pravděpodobně zasadí na příští rok, a pak na základě toho předpovídat dění na komoditním trhu.

To zní fascinujícím způsobem. Takže jsi v New Yorku, hodinu od New Yorku si zkoušíš zajímavé věci. Logickým pokračováním této cesty je stát se zaměstnancem IBM a stoupat v korporátním žebříčku, ne?

Jo, přesně tak. Ale já jsem v té době byl ještě stážista. Některé z těch projektů, co jsem zmínil, možná později přešly do mojí práce jako full-time zaměstnance. Ale jako stážista jsem si říkal, že mě projekty úplně nenaplňovaly. Možná jsem ani neměl silný tým vedle sebe, který by mě podporoval. Proto jsem se přihlásil na jinou stáž v IBM Research, tentokrát do Švýcarska. Když mě tam přijali, řekl jsem si, že to zkusím a otestuju si vody někde jinde.

A do Švýcarska ses hlásil kvůli pracovní náplni, nebo také proto, že jsi chtěl být blíž domovu?

Hele, motivace byla převážně pracovní. Samozřejmě trochu i to, že jsem byl blíž, ale v tu dobu to nebylo klíčové, protože stáže mají omezenou dobu a člověk ví, že po pár měsících musí udělat rozhodnutí, co dál. Švýcarská divize IBM Research je navíc hodně známá tím, že dělá velmi zajímavé vědecké projekty. Je to jedna z předních poboček IBM Research, takže to byla velká motivace tu možnost vyzkoušet.

Nakonec jsem se tam také dostal a přestěhoval jsem se na asi půl roku, pokud se nepletu, možná na devět měsíců do Švýcarska, kde jsem opět pracoval na platformách pro Big Data.

No a ty jsi předtím říkal, že americká IBM se trochu liší od českých, respektive evropských poboček. Tak tedy, jsme ve Švýcarsku v IBM Research, která je specificky mezi těmi nejlepšími z těch 12 poboček...

Pokud chceš, mohu opravit i pokračování nebo upravit text ještě víc pro specifické použití.

Jistě, zde je opravený text:

Aha. Tak když to porovnáš, ty různé IBM, jsou tam nějaké inside informace? Hele, kdybych to měl upřímně říct, tak si myslím, že ta švýcarská IBM, z toho, co jsem měl možnost potkat ty lidi, byla trošku na vyšší úrovni než ta americká. V americké to možná bylo jednodušší – dalo se snáze prosadit v tom korporátním systému. Když tam člověk vydržel dostatečně dlouho, mohl se dostat na vyšší pozici a nemusel být úplně světový talent, řekl bych. To se mi ve Švýcarsku až tak často nestávalo, možná to bylo tím, že jsem byl spíš mezi mladými lidmi v týmech. Jinak ale obě dvě ta místa dělají špičkový výzkum, což je bez debat.

A ve Švýcarsku jsi měl nobelisty a geny, že? Co přesně znamená, že jste tam dělali big data? Hele, samozřejmě to byla stáž, takže jsme byli studenti na Ravešnavici (poznámka: pravděpodobně se jedná o nějaký výraz, pokud jde o praxi nebo stáž), kteří nebyli úplně nejdůležitější pro ty projekty. Vyloženě zajímavé věci jsem tam nedělal, když na to teď zpětně koukám, dělal jsem API vrstvy nad jejich big data platformou – nebo ano, pojďme říct platformou, která vlastně poskytuje 360° pohled na společnosti. Sbírá a zpracovává data o firmách, dělá analýzy a poskytuje tyto informace zpět svým zákazníkům, kteří pak mohou sledovat finanční reporty, jak je firma zdravá, kdo jsou její konkurenti, kdo je vedení a tak dál. Bylo to hodně o sbírání dat a jejich transformaci do standardních formátů, pak opět o validaci dat a zpětné vazbě. Ale jak říkám, já jsem primárně dělal API pro zákazníky, takže jsem nepracoval na algoritmických věcech.

Kam pokračovala tvá cesta dál? Ještě nějaká další IBM, kam jsi mohl postoupit? Nebo jsi mezitím dělal něco jiného? Ne, ne, ne. Jak jsem říkal, ještě jsem stále studoval magisterské studium informatiky. Masarykova univerzita byla úplně super, byla flexibilní, mohl jsem hodně věcí dělat na dálku. Ale nastal ten moment, kdy jsem už potřeboval nebo chtěl školu dokončit. Po skončení stáže se mi ozvala zase americká IBM, že jim asi trochu chybím, spíš jsme se pořád bavili s lidmi, se kterými jsem tam dělal.

A už si jim chyběl? Přesně, a dostal jsem nabídku na full-time pozici v researchu jako klasický zaměstnanec IBM. Říkal jsem si, že je to životní příležitost, asi ji vezmu, a vzal jsem ji. Přistihl jsem se zpátky v Americe. Zpátky v New Yorku. Přesně tak, kde jsem strávil následující čtyři, možná pět let.

Mezitím jsi pak dokončil Masarykovu univerzitu? Jo, dokončil jsem vzdáleně, jezdil jsem tam a zpět, ale školu jsem úspěšně zakončil – dokonce s červeným diplomem, což bylo super.

A na co jsi psal závěrečnou práci? Ježiši, to jsi mě možná úplně zaskočil. Určitě to byla...

Pokud byste chtěl pokračovat, rád text opravím dál.

Jasně, tady je opravený text s lepší formou a interpunkcí:

Myslím si, že to byla triangulace, nebo nějaká mobilní aplikace, která byla schopná se připojit na iBeacon. To bylo asi součástí mojí první stáže v IBM Research – vytváření mobilní aplikace, která dokáže triangulovat zařízení Bluetooth, konkrétně iBeacon zařízení Bluetooth Low Energy v interiéru, a na základě toho spouštět nějaké akce.

Super, takže IoT.

Ano, a v té době, to bylo kolem roku 2014, myslím, že spíš 2013, pokud se nepletu, Apple přišel s iBeacon standardem, který se potom začal implementovat do Bluetooth Low Energy zařízení. My jsme pak dělali POC (proof of concept) projekty se společnostmi jako McDonald's a Vimbleton. Pro McDonald's to fungovalo tak, že když jsi přišel okolo McDonald'su, dostal jsi notifikaci, že tu máš například 20% slevu na hamburger. Takže takové praktické využití. A pro Vimbleton to bylo zaměřené hlavně na navigaci uvnitř vnitřních prostor – kdyby se lidé potřebovali dostat například z budovy A do budovy B v nějakém bludišti, aby jim aplikace pomohla se navigovat.

Super, takže konečně jsi začal mít nějakou práci na konkrétních projektech a vracíš se zpět do New Yorku.

Ano, takže už to nebylo tak přechodné a začal jsem mít i stabilnější projekty. Do jakých jsi naskočil?

Já jsem samozřejmě pokračoval na nějakých kognitivních... Říkejme tomu chatbotům.

Dobře, chatboty.

Nebo nebyly to úplně chatboty. Když říkáš inteligentní, kognitivní, spíš jde o dialogové systémy.

Dialogové systémy? Tak já tam slyším chatboty.

Ano, ale já to trochu zkomplikuju, protože jsem začínal s těmi místnostmi, které jsem už popsal, a pak jsem naskočil na projekt, který byl z mého pohledu hodně zajímavý. Šlo o projekt z oblasti HCI – Human Computer Interaction. Cílem bylo představit si, jak by mohly vypadat místnosti, kde se lidé setkávají v budoucnosti. Jak by tam mohla být integrovaná AI, roboti nebo nějaké sofistikované chápání kontextu toho, co se v té místnosti děje.

A teď možná je těžké to vysvětlit bez názorného příkladu nebo obrázku. Takže si třeba zavři oči a představ si kulatý stůl, který může jezdit nahoru a dolů, abys u něj mohl stát i sedět.

Nad tím stolem jsou projektory, které dokážou promítat různé informace nebo vizuální prvky přímo na jeho povrch. Kolem stolu je v kruhu 15 robotických ramen. Jsou to kolaborativní robotická ramena, takže nejsou zavřená v kleci a nemusíš se jich bát – teoreticky tě ale mohou trochu zranit. Každé rameno má 7 kloubů, takže si můžeš představit, jaké pozice dokážou zaujmout. Na každém ramenu je navíc 4K obrazovka, takže jsou rozmístěné všechny kolem.

Nad tebou jsou v kruhu umístěné reproduktory, které umožňují prostorový (spatial) zvuk. Navíc jsou tam kinecty a různé senzory pro rozpoznávání objektů, lidí nebo třeba hostů.

Takto nějak vypadá ta místnost, na které jsem pracoval, a která byla fakt super,…

Pokud chceš, můžu ti pomoci s dalším pokračováním nebo úpravami.

Zde je opravený text:

Z tvého pohledu tam máš hardware, software, AI, computer vision, opravdu hodně složité softwarové inženýrské věci, včetně orchestrací robotů samých o sobě. Máš tam i use case? To je přesně to, k čemu jsem se chtěl trochu dostat. Je to skvělý projekt, na kterém se můžeš opravdu vyřádit. Je to výzkum, takže tam samozřejmě asi není žádná monetizační nebo exit strategie. Use case byl: pojďme fakt zkusit, co je možné v oblasti HCAI (Human-Centered AI). Je to opodstatněné tou cenou? Nemyslím si. Na druhou stranu tato místnost, kterou jsem ti právě popsal, existuje ve dvou verzích. Jedna je v New Yorku, v tamním výzkumném laboratoři, a druhá je tady v Evropě, v Mnichově. Pokud půjdeš tady v Mnichově do IBM, do té budovy, nevím přesně, jak se ten mrakodrap jmenuje, ale instalovali jsme tam spoustu věcí, byl jsem tam několikrát. A to už se možná dotýká i Applu, protože na tomto projektu jsme pak pokračovali, když jsme založili Apple. Představ si, že jsi v tom mrakodrapu, máš výhled na Mnichov a na místnost, kde u televizoru stojí patnáct robotických ramen a musíš tam dělat tyto věci. IBM to samozřejmě používá jako „wow efekt“ pro své zákazníky, jako ukázku, že jsme inovativní společnost schopná dělat cool věci.

A tvá role? Kterou část jsi dělal nejraději? Kterou jsi zkoumal? Myslím, že jsem dělal skoro všechno. Začínal jsem orkestrací těch robotických ramen, což bylo samo o sobě docela náročné. Už jen kvůli jazyku – používali jsme ROS (Robot Operating System), který byl na každém rameni zvlášť. My jsme na tom dělali abstraktní vrstvu, aby roboti navzájem o sobě nevěděli (anebo naopak věděli), aby se nekolidovali a mohli se společně ovládat a orchestracit – fakt tak, jako by to byl multiplayer, robot multiplayer mód. To jsem primárně navrhoval a implementoval, samozřejmě s dalšími lidmi.

Další výzvou byly 4K obrazovky – bylo jich 15, a bylo potřeba na všech zobrazit něco zajímavého. Museli jsme vytvořit distribuovaný systém vizuální správy, protože to běželo přes několik serverů s více GPU. To nijak normální laptop nerozjede. V té místnosti jsme měli tento objev pixelů a chtěli jsme, aby jeden obraz běžel na těch patnácti robotických ramenech tak, že to působí jako plynulý a bezproblémový zážitek (seamless experience). Ale je to komplexní ekosystém, takže jsme implementovali něco jako virtuální domy, podobně jako později přišel React s konceptem virtuálních DOMů, a synchronizovali jsme různé věci. Takže to byla vizuální část.

Pak jsme dělali i typické věci z oblasti computer vision, například Kinects a rozpoznávání objektů, a i...

Pokud chceš, mohu pokračovat v opravě nebo úpravě další části textu.

Jasně, tady je opravený text:

Integrace těch zařízení do seamless experience – měli jsme zařízení, která jsi mohl postavit na stůl a my jsme rozpoznali, co to je za device. To zařízení mělo nějakou funkci, mohl jsi s ním interagovat, kliknout na něj, šáhnout, otočit s ním a něco se dělo. Mohlo to být opravdu fyzické zařízení, třeba kostka, která něco triggerovala. Samozřejmě to mohlo být i něco chytřejšího, třeba myš, která měla různé funkce jako scrollování nebo zoomování.

Také jsme dělali rozpoznávání gest – když někdo zvedl ruce nad hlavu, robotická ramena zmizela a přijela ke stropu, čímž vznikl prostor. A takových věcí bylo více. Samozřejmě jsme používali i rozpoznávání hlasu.

Teď mi pověz, jak vypadalo pokročilé demo. Když pojedu do Mnichova a IBM chce na mě zapůsobit, je to interaktivní výstava s ukázkami technologií, nebo tam můžu hrát pong, který se točí kolem mě – a podle skóre se něco děje.

My jsme těch demo projektů měli hodně. Jedno z nich bylo reálné průchozí koncepty s Boeingem, kde jsme dělali command center pro jejich výrobní assembly line. Výroba letadel je velmi zdlouhavý, složitý a komplexní proces, takže to bylo jedním ze způsobů, jak vizualizovat data a dát přehled těm, kteří potřebují vidět vysokou úroveň informací o stavu letadla.

Takové proof of concept jsme realizovali. Dále, jak jsem zmínil, měli jsme geospatial data – jedno z dalších demo byla možnost si vybrat oblast světa, zobrazit dostupné datové vrstvy vizuálně a dělat dotazy, kombinovat data a ukládat snapshoty na obrazovky. Představ si, že máš třeba 15 velkých obrazovek a chceš získat insight do problému, který zkoumáš.

Samozřejmě, dvě úzké obrazovky nejsou na takovou práci dostatečné. Já jsem měl v kanceláři obrovskou obrazovku a navíc robotická ramena, na která jsme připevňovali ty velké obrazovky – mohli jsme je otáčet podle potřeby. Bylo to hodně nerdovské. Můj stojan na monitor byl dražší než tvůj.

Bylo to opravdu divoké, ale super nerdovský projekt.

Také jsme spolupracovali s astrofyziky, kteří psali různé články o redshiftu a dalších zajímavých věcech. Implementovali jsme vizualizaci vesmíru, určenou pro běžné lidi, kteří nemají zájem o geospatial data či byznys aplikace, ale chtějí zažít wow efekt a přiblížit si vesmír trochu blíže i z humanitnější perspektivy.

A k tomu jsme vlastně implementovali...

(Tady text skončil, pokud chceš, můžu pomoct s dalším pokračováním.)

Opravím text tak, aby byl srozumitelnější a jazykově správný:

U toho stolu uprostřed jsme měli 3D model toho, jak se vesmír rozpínal v čase. Mohl jsi tak „běžet“ po bilionech let a vidět, jak vesmír vypadal, což bylo strašně cool. A když jsi se dostal do nějakého roku, mohl jsi to vlastně jakoby „zafreezeovat“ a podívat se na jednotlivé objekty. Měli tam zajímavé objekty, třeba různé nebeské tělesa, které vizuálně vypadaly velmi zajímavě. Mohl jsi říct, že máš zájem o určitý objekt – ať už to byla nebula, galaxie nebo hvězda – a my jsme ti poslali request na softwarový server, získali data nebo obrázky z Hubbleova teleskopu, a ty jsi pak mohla vidět ten obrovský obraz na 15 4K obrazovkách. To bylo opravdu skvělé.

Lab byl tmavý, protože jsme vypli všechna světla, takže když ses podíval na nějaké nebule, které jsou fakt krásné, mohl ses úplně ponořit do těch dat. To lidem asi mohlo hodně rezonovat. Na tomhle projektu jsme pracovali čtyři roky a nebyly tam žádné další větší projekty. Jak jsem už říkal, předtím jsem pracoval na jiných věcech, možná jsem to trochu zamíchal, ale myslím, že poslední dva, možná tři roky jsem dělal hlavně na tomhle projektu. Možná se mi to teď i trochu plete s Applekem, protože...

No, teď k tomu – předběhl jsem, když jsi byl stážista, ale teď jsi už full-time zaměstnanec. Když se podívám na kariéru, je jasné, že vlastní firma v Praze rozhodně není ta nejčastější trajektorie. Když bych chtěl něco sledovat, tak je to typicky IBM for life – prostě jedeš, sbíráš zkušenosti, rosteš na kariérním žebříčku. Tak co se stalo po těch čtyřech letech? Měl jsem bratra, který tam nebyl se mnou, a to byla jedna z těch věcí. (Pozn. – jsme jednovaječná dvojčata.) To je pro mě fascinující a možná si o tom někdy uděláme jiný podcast, psychologický nebo vztahový. Máme skvělý vztah, samozřejmě jsme spolu vyrůstali a dělali spolu všechno, ale pak jsme se oba trochu rozprchli do světa. Ten vztah, tedy to, že mi chyběl, na mě opravdu hodně působil – o tom by nejlépe mohl něco říct moje manželka, která věděla, jak to na mě mělo dopad.

Další věc je, jak jsem říkal, že jsem potkal manželku, která není Češka, a proto jsme měli vždycky dilema, kam pojedeme o Vánocích nebo jiných svátcích – za její rodinou nebo mojí. To byla další silná motivace, jestli se nakonec elokovat do jedné z těch lokalit, kde máme rodinu. A možná další faktor byl ten, že jsem úplně neulpěl na americkém stylu života. Vždycky jsem si v pozadí myslel, že to zkusím, naberu zkušenosti, ale nakonec se vrátím. A všechno tohle vedlo k tomu, že jsem se vrátil a IBM jsem řekl, že bohužel odcházím. Není to kvůli nim, prostě mám jiné plány. „Není to o vás, jsem to já.“ Přesně tak. Ale na férovku...

Opravený text:

Rovku samozřejmě, já jsem dával hodně s předstihem vědět, abych jim nenarušil jejich projekty a tak. A ten odchod byl prostě strašně fajn, spolupráce, že oni to chápali a chtěli si mě udržet, takže jsem řekl, že odcházím, a dostal jsem nabídku, abych pokračoval dál v IBM jako IBM zaměstnanec v Čechách, protože IBM korporát má tyto global mobility programy, kdy člověk může fungovat v jiném státě a vlastně pracovat na projektech jinde. Ale já jsem říkal, že tohle úplně nepotřebuji, protože můj management by stejně nebyl tam, a možná ani ten management nechci, protože jsem z toho managementu nikdy necítil nějaký pozitivní progres v mé kariéře. Já ten management úplně tolik nepotřeboval. Takže jsem tohle odmítal a říkal jsem, že pokud si mě chtějí, tak přes nějaký kontrakt, že pro ně budu dělat to řešení těch problémů, prostě ten Applied Research, a budu si svým vlastním pánem. A dáte mi volnost v tom, že vlastně mohu dělat nějaká produktová rozhodnutí víceméně, protože v Applied Research jde hodně často nejen o technickou část, ale i o to vědět, co ti potenciální zákazníci daného produktu chtějí. Je to i trochu o byznysu a díky tomu MBA a ekonomii začalo všechno dávat smysl, že nejsi jen technický člověk, ale jsi schopný pochopit, proč to děláš, strategii, vizi a tak.

Takže jsi byl v kontaktu třeba s Boeingem?
Jo, na ty POC, ano. Pár hodin vždycky přijde, že jo, my se pobavíme, jaké jsou jejich problémy a co zkusíme udělat. A v researchu se dělá hodně těch POC.

A IBM souhlasila?
IBM víceméně souhlasila. Jak jsem říkal, dělal jsem víc věcí, takže souběžně jsem pomáhal tady bráchovi s nějakými projekty, které měli tady v Čechách. Souběžně jsem ještě po večerech dělal svoje vlastní výzkumy a potom typický software engineering.

Náš první projekt, který jsme dělali, byl komunikační protokol, UDP protokol pro nemocniční postele. To byl náš první POC projekt, na kterém jsme ještě pracovali v Americe, a potom jsem pokračoval na něm tady dál, v období, než IBM stihla vyřídit papírování a vlastně jsme byli schopni pracovat na kontrakt pro IBM.

Jaký byl profil bráchy? Jak se dostal k projektu nemocničních lůžek?
To je taky zajímavá, pěkná story. Já byl v IBM v Čechách a potom jsem odešel do Ameriky studovat, a přesně v ten moment přišel brácha do IBM v Čechách. Já mu říkal, že to místo není úplně špatné, tak ať to zkusí. Přišel tam jako projektový manažer, na jednu pozici, ale do stejného offisu. Ze dne na den jsme se asi tak dva týdny úplně minuli, což byla strašná náhoda. Oni z toho asi úplně šíleli, protože znám spoustu dvojčat...

Jste zas tak nerozpoznatelní, protože znám dvojčata, kdy fakt musím hledat jednu nějakou věc a mít to nastudované. U vás nejste jeden člověk, jste rozeznatelní. Bylo to tak i tehdy, anebo jsi si vzal ty samé hadry a ještě tomu trošku přihodil? Hele, tam je jako největší problém...

Ty jsi mu řekl, kdo byl tvůj nejlepší kámoš, on přišel do kuchyňky a říkal: "Čau, Pavle." Hele, tam je jako největší problém, jsme trošku rozeznatelní, s tím souhlasím, a brácha ještě v té době nosil brýle, takže to byla v zásadě pomoc. Usnadnilo to.

Usnadnilo to, ale tam je ten problém, že lidi nevěděli, že máš dvojčata. Takže vznikaly takové zajímavé situace, že je to Matouš a vypadá trošku jinak, jak je to možné, co se s ním stalo. Dva své dny tady nebyl. Úplně makeup, Matouš makeup.

No, takže brácha nastoupil do IBM jako projekťák a potom s tím manažerem po pár letech odešli a založili nějakou menší softwarovou společnost a vlastně takhle se on dostal k tomuhle projektu a řekl: „My tady máme projekt, samozřejmě není to úplně jednoduchý projekt, potřebujeme to vyřešit a potřebujeme přijít s efektivní věcí, jak prostě komunikovat, protože nemocnice mají problém s tím, že nemůžeš nasadit kupu hardwaru, takže potřebuješ mít ideálně jeden server, který je schopný obsluhovat tisíc postelí. Musí to být nějak compliance se standardy ve healthcare, tedy HL7 a takové věci k tomu.“

Já jsem s ním začal pomáhat, protože jsme vlastně udělali celé end-to-end řešení, to znamená dashboard a alerting pro sestřičky, že když se třeba něco stane. Dnešní postele jsou chytré, mají různé senzory – hmotnosti, zábradlí, pozice, detekci vlhkosti – a samozřejmě na to můžeš navázat další zařízení. Všechno tohle může spouštět alarmy, na které musí člověk nějak reagovat.

Takže jsme implementovali UDP protokol, což byla zase taková nerdská věc – opravdu na binární úrovni, jedničky a nuly, což byla skvělá věc. Vzpomněl jsem si na svoje studia na vysoké škole a řekl si: konečně něco fakt nízkoúrovňového. Fakt v binárním kódu? Samozřejmě.

To nemělo žádný jazyk? To je ještě horší než tvůj robotický... Ne, psali jsme to samozřejmě v nějakém programovacím jazyce, ale zprávy, které běžely po síti na vrstvě UDP, jsme řešili fakt jako binární data – jak co nejefektivněji zabít co nejvíce dat do protokolu, aby byl fakt efektivní.

Byla tam i optimalizace, že... A nebo to byla nerdovina? Ne, byla to fakt optimalizace, kterou jsme chtěli hned od začátku udělat. A dávalo to smysl, protože proč bys tam posílal nějaký složitý HTTP REST JSON, když k tomu nebyl důvod? A hlavně zařízení, se kterými komunikuješ, jsou jednoduchá, která mají signály, jak se říká.

A možná to byla i trochu nerdovina.

Opravený text:

No, na druhou stranu tam máš asi nějakou škálu příkazů, tedy... Že nepotřebuješ chatovat mezi postelí a tím, co potřebuješ. A je to jednosměrné? Ne, je to dvousměrné. Ta postel ti dává informace, například alarmy, ale ty si musíš ty informace vyhodnotit, třeba jsou tam alarmy. Ale ty do postele také něco posíláš. Jo, posíláš, měníš konfiguraci postele, například kdy má alarm poslat signál, protože můžeš říct, že teďka 30 minut je to v pohodě, protože tam děláme převlékání.

Máš tam komunikaci, můžeš měnit stavy té postele, více o tom můžeš říct. Super, takže s bráchou děláte první projekt společně, tak? Jo, přesně tak. To bylo první, a potom vznikla spolupráce s IBM, nebo se navázal kontakt s IBM, takže jsem se dostal zpátky k robotickým ramenům. Tohle bylo zase vhodné, protože jsme měli tu „mýchov“ (pozn. možná „mikrořadič“ nebo „systém“), byla tam instance toho, takže jsme v tom pokračovali.

Na začátku to byla vlastně „one man show“, byl jsem jediný já. A když je řeč o roce, myslím, že to bylo 2018 nebo 2019. V roce 2018 jsem už začínal na těch projektech pracovat, v roce 2019 jsem byl v Čechách a už jsem na tom dělal pořádně. Samozřejmě s bráchou, měli jsme to tak, že jsem přijel do Čech a on postupně opustil svoji společnost, pak i další lidé z té společnosti se k nám přidali, a už nás bylo víc, už jsem nebyl jenom já. A vzniká Apoko.

Vzniká Apoko a IBM Research přichází s novým projektem pro nás. Přišli s tím, že IBM nemá velkou digitální prezenci svého IBM Research brandu, a chtěli, abychom jim s tím pomohli. Takže přišli za mnou, že chtějí dělat digitální platformu pro koncového uživatele, což je vlastně jenom webovka. Pokud půjdeš na research.ibm.com dneska, je to ten web, který jsme dělali my, a stále ho děláme. Je to jediný projekt, u kterého vždycky říkám, že v Apoku webovky neděláme, ale tady je výjimka.

Začínali jsme na tomhle projektu, otevřel nám to bránu do IBM Research. Já už na tom projektu přímo nefiguruji, ale první fáze byla zajímavá, protože tam je spousta data miningu – i když vidíš jen web, za tím je spousta věcí, protože tam jsou akademické publikace, které minujeme, a máme integrace do různých IBM systémů. Je to docela sofistikovaný systém a hlavně jsme si na něm zkoušeli multi-region deployment a always-on architektury, což bylo z hlediska škálování velmi zajímavé.

A ten projekt nám otevřel cestu mimo to, co jsem doteďka v IBM dělal. Pak přišlo rozhodnutí, že jdeme stavět firmu v oblasti Professional Services, protože máme kontrakt s IBM, po večerech pomáháš bráchovi s projektem, brácha postupně opouští svoji firmu, přidává se víc lidí, a tak to zkusíme. Nebo to bylo tak přirozené?

Přirozené, všechno bylo přirozené. Ještě jsem se nezmínil, že máme vlastní produkt, který se jmenu...

Jasně, tady je opravená a zřetelnější verze textu:

Je tu Brainio, což je projekt nebo produkt na zachycování poznámek a používání myšlenkových map. To byla naše srdcovka, taková vize, možná trochu i když jsem odcházel. Řekli jsme si: „Založíme něco vlastního, pojďme to zkusit.“ Bylo to takové „pojďme do toho dát startupovou energii“, paralelně s ostatními projekty.

Měli jsme problém, že jsme se pořád vzdělávali a dělali si poznámky. Já osobně jsem hodně používal myšlenkové mapy, protože mi vizuální forma lépe funguje s mým myšlením. A tak jsme si řekli: „Zkusme to zkombinovat – strukturovaná data v poznámkách a myšlenkové mapy – a udělejme něco, co umožní používat různé metody zpracování dat.“ Tak vznikl Brainio.

Na tom jsme pracovali po večerech, protože zároveň přicházely projekty od IBM, takže jsme pomalu rostli. Nejprve jsme to rozjeli v našem malém networku, který nebyl moc velký, protože já jsem byl v Americe a můj network v Čechách nebyl příliš rozsáhlý. Začínali jsme asi v pěti, šesti lidech z našeho okolí, a postupně jsme najímali další lidi na projektech.

Dělali jsme webovou aplikaci s pokročilými funkcemi, programovali jsme za americké peníze, což byl dobrý začátek.

Než se pustíme do dalších projektů: pokud hodně čerpáš ze vztahu s IBM, hlavně IBM Research, zeptám se, jak jste se k takovému kontraktu dostali? Co to vlastně znamená být dodavatelem firmy, která dělá pro IBM Research? Potřebuješ jít na stáž do české IBM, přesunout se do Ameriky, zaklepat na jejich dveře...?

Odpověď byla, že to bylo dlouhý a pomalý – dělat stáž v Česku, potom v New Yorku, následně ve Švýcarsku, potom dostat nabídku pracovat tři roky v IBM v New Yorku na plný úvazek, a až potom se můžeš bavit o tom, že tvoje firma projde procurementem a dostane kontrakt.

Je to těžké, protože přijít s tím, že „my vám to uděláme, najměte nás,“ vyžaduje mít nějaký leverage – zkušenosti z jiných společností nebo projektů, kde jsi ukázal, že umíš odstartovat malé věci a postupně je rozvíjet. Nebo mít velmi talentovaný tým s dobrými jmény, který studoval na špičkových školách a pracoval v renomovaných firmách.

My jsme takový tým neměli, takže to byla jiná cesta, složitější a bez zkratek.

Moje otázka tedy je, co bylo potřeba kromě tvého leverage? Bylo to tak jednoduché, nebo...

Pokud chceš, můžu upravit dál, případně doplnit nebo zkrátit.

Opravený text:

Ono to potom rok trvalo, to znamená sjednat kontrakt, mít americkou entitu a tak dál. Hele, to víceméně, proč se nám tohle podařilo, je to, že jsme prostě dodávali to, co zákazník chtěl, a možná ani nevěděl, že chce, a my jsme byli schopni mu pomoct. Inovovat, když to tak řeknu. A já už teď možná trošku mluvím o těch dalších projektech, protože tohle samozřejmě – webovka a research – nejsou úplně přesně ten projekt, ta naše cílovka, co děláme nebo co bychom chtěli dělat. Ale vždycky to bylo o tom, že jsme překročili očekávání a že jsme byli schopni udělat něco nového, vyšejpovat něco nového, co nám nebylo řečeno, že máme dělat úplně, nebo vlastně nebylo, a IBMka ani nevěděla, jak ty věci řešit. A my jsme pomohli formovat tuto věc. A to potom asi uvidíme i v těch dalších projektech. Tak trochu klišé, ale tady to zní jako pravda, že jste nebyli jen dodavatel, ale byli jste partner. Přesně. Ale to není fakt klišé. Takto to vnímáme my i IBMka. To klišé je žít v tom vztahu. My tento vztah máme od roku 2019 a hlavně jedna z těch důležitějších věcí je ten tým. Samozřejmě ze začátku s Leverage jsem byl já, ale postupně jsme byli schopni poskládat úžasný tým lidí tady a 90 % úspěchu jsou prostě ti lidé, které tu teď máme. Tak pojďme se podívat na ty další projekty. Jo. Hele, tak ten web byl dobrý z toho důvodu, že jsme získávali stik s realitou toho, co se v tom research děje, protože všechny publikace, všechny blogposty, takový ten breakthrough, který v IBMku vzniká, jsme měli na talíři. Víceméně tak trošku hloupě řeknu, že jsme ten web museli udělat, ale bylo to fajn, protože fakt nahlédneš pod tu pokličku, vidíš, že se často dělají různé rozhovory s lidmi, kteří ten breakthrough dělají a o kterém se píše. Další projekt, který jsme dostali, byl zase s IBM Research, tentokrát ve Švýcarsku, který nemá žádnou souvislost s tím, že jsem tam dělal stáž, to přišlo samo o sobě. Ten problém tam byl takový, že tam existuje research na autonomní chemickou laboratoř, můžeš si to představit ve fieldu New Materials Discovery. Prostě máš laboratoř, máš malou laboratorní kostku nebo boxík, dejme tomu, který můžeš ovládat na dálku. Je tam nějaký robotický rameno, jsou tam pumpičky, jsou tam zkumavky a další chemické přístroje pro zjišťování nějakých parametrů látky. K tomu IBM vytvořila cloudové řešení a AI systém, pomocí kterého jako chemik přijdeš a řekneš: „Chtěl bych látku s těmi vlastnostmi.“ Cloudové řešení, nebo AI systém, byl natrénovaný na patentech a publikacích, a většinou udělal nějaké doporučení, jak by molekulární syntéza měla vypadat. Ty jsi mohl na tom cloudu něco nakonfigurovat, kliknout start, a syntéza se pustila na dálku, nemusel jsi být v laboratoři. Samozřejmě jsi musel zajistit, že tam jsou všechny látky, které syntéza potřebuje, ale mohl jsi to pustit vzdáleně a syntéza běžela třeba pět hodin, jindy dva dny, někdy i tři dny. A pak jsi přišel… (text pokračuje).

Tady je opravený text:

To vyprodukovalo něco, co bys mohl ověřit – vlastnosti té látky, jestli ses dostal k tomu, co jsi chtěl. A problém byl v tom, že to běželo tři dny a vlastně jsi neměl žádné informace o tom, co se během toho času dělo, pokud jsi nestál v laboratoři a přímo u zařízení nečetl ty údaje. IBM tedy přišla s tím, že by to chtěla nějak vyřešit, a my jsme naimplementovali řešení, které bylo v podstatě nějaké IoT.

V chemickém laboratoři je spousta zařízení, která posílají data v různých formátech. Ty jsme museli získávat, transformovat a snapshotovat, abychom zjistili stav systému v daném čase. Měli jsme tam 15 kamer, které sledovaly různé věci – bylo to velmi zajímavé – a zároveň jsme zpracovávali data z ostatních systémů a přepínali mezi těmi kamerami.

Používali jsme HLS, což je HTTP Live Streaming Protocol. Myslím, že ho vytvořila společnost Apple, pokud se nepletu. Do tohoto protokolu jsme integrovali informace o jednotlivých snipšotech v čase. Na konci dne tak researcher mohl přijít a podívat se zpětně, v podstatě jako na YouTube – mohl si přehrát vizuální obsah, tedy videostream. Přitom všechno mohlo běžet i jako livestream, ale on měl možnost se vracet do historických záznamů a přitom si prohlížet vizualizovaná data z těch systémů. Viděl například, jaká byla teplota v chemickém reaktoru, tlak a podobně.

Tento projekt byl velmi zajímavý. Navíc jsme se zabývali i hardwarem – chtěli jsme se podívat do chemických reaktorů dovnitř a zjistit, jak vypadá materiál nebo jak moc se něco vypařuje. Dokonce jsme vytvářeli 3D modely reaktoru a navrhli jsme malá okénka, do kterých šlo umístit webkameru, aby bylo možné nahlédnout dovnitř. Bylo to takové nerdovské a zajímavé řešení.

Co bylo ale skutečně „extra mile“? To rozhodně nebylo jen to okénko s kamerou. To bylo spíše něco technicky zajímavého, ale opravdovou přidanou hodnotou bylo propojení snapshotů systému s vizuálním videostreamem. To byl klíčový prvek. Také práce s protokolem pro livestreaming, aby vše vůbec fungovalo, a správa 15 kamer nebyla úplně jednoduchá z hlediska softwarového inženýrství.

A jak dlouho jsi na takovém projektu pracoval? Myslím, že asi dva roky, pokud si to správně pamatuji. Byl to náročný projekt, zvlášť protože IBM tehdy neměla úplně zájem nebo neposkytovala velkou podporu a najímala si jiné lidi, kteří řešili jiné části tématu...

Pokud chceš, můžu text ještě upravit do formálnější nebo stručnější podoby.

Jasně, tady je upravený, plynulejší a stylisticky lepší text:

Nasvětit ty věci tak, aby to vypadalo pěkně a aby to chtěli streamovat, livestreamovat do internetu a tak. Takže jsme tam měli okýnka, kde jsme třeba neměli úplně tolik práce. Ale tím neříkám, že jsme neměli vůbec žádnou práci, prostě byly i jiné projekty pro IBM. A tak to byl jeden z těch momentů, kdy jsme se trochu odklonili jiným směrem a skočili do AI. Pak přišla AI. Potom přišla AI. IBM zjistila, že jsme celkem kompaktní tým.

Když říkáš „kompaktní tým“, jaké role tam tehdy byly, případně jsou i dnes? Z tvého vyprávění mi vychází, že jsi takový „jack of all trades“, full stack. Jak vypadal ten tým? V té době nás bylo podle mě asi 7-8, možná i 10, teď už si přesně nepamatuju. Měli jsme tam lidi — samozřejmě full stack inženýry, ale i kluky, kteří měli vystudovaný ČVUT nebo UT, specializace na machine learning a podobně, takže jsme měli takový ten přechodný tým. Všichni jsme byli seniorní programátoři, což je pro Apoku obecně typické. Všichni jsme schopní psát kód, a nejdeme cestou mít „pure“ data science lidi, kteří neumí programovat, nebo machine learning experty, kteří programovat neumí. Každý z nás má možná šmrnc do nějakého oboru – někdo je víc na výzkumu, dokáže se na věci dívat jinak, „out of the box“, přemýšlet o tom, co bude další krok; někdo je zase víc na tradičním software engineeringu – chce problém pochopit, mít ho přesně zmapovaný, navrhnout řešení a zarchitekturovat systém. Takto nějak vypadal ten tým.

Jak moc se v týmu profilovalo IoT a hardware? Je to zase inženýrství jako každé jiné? Je to podobné, jen někdy máš data v lepší kvalitě a potřebuješ jít hloub do detailu. V našem případě jsme s hardwarem vůbec nepřišli do styku, pracovali jsme jen s daty, která hardware poskytoval. Napojit se a zpracovávat data je něco úplně jiného.

Základ ale je něco jiného. Pocházelo to z různých zařízení v laboratořích Rabina a chemického ústavu. Tam bylo strašné utrpení, protože každý přístroj byl starý a nebyl žádný unifikovaný standard. Takže jsme se při zpracování museli opravdu podívat na ta data, pochopit doménu, co data znamenají, a převést je do podoby, která má smysl pro chemiky. To přesně vystihuje, co se v Apoku snažíme dělat — Applied Research. Nezáleží nám na doméně, pokud je pro nás téma dostatečně zajímavé, ponoříme se do ní. Neříkám, že jsme hlubocí experti — například já nejsem chemik. Polovinu věcí, které tam dělali syntézu, vůbec neznám. Ale jsme schopni pochopit základy…

Pokud chceš, můžu text ještě více upravit nebo zjednodušit. Stačí říct!

Opravený text:

Kladné standardy, co je důležité pro chemika, nasát ty informace a potom zase skočit na jiný projekt a zkusit něco jiného, třeba AI. No, tak pojďme do té AI. Promiň, že jsem tě ještě zastavil u rolí týmu, ale ta velká IBM Research v nějakou chvíli – předpokládám, že spoustu ostatních věcí šlo stranou – a tak jako celý softwarový svět najednou se stala prioritou číslo jedna AI slash Gen AI, velký jazykový model.

Jak jsem říkal, IBM si v té době uvědomila, že jsme celkem schopní, byli jsme docela vysoko v rámci své struktury, tedy vysoko k těm nejvyšším lidem v IBM Research, což nám určitě pomohlo. Byli jsme v organizaci, která byla blízko Applied Research. Nešlo o Deep Research, ale o to, co s tím výzkumem můžeme dělat dneska.

A přišel mandát: „Vy jste schopní, my strategicky potřebujeme, protože IBM nemá vůbec žádné řešení pro LLM nebo Foundation Models. Potřebujeme…“ Tehdy přišel Bloom Model, pokud si nepletu, v roce 2022, který byl jako první velký model, 176 miliard parametrů, pokud si dobře vzpomínám, a otázka byla jednoduchá: „My máme tady research community s 5 000 nebo kolika lidmi, většina lidí v AI fieldu chce mít přístup k tomuto modelu – jak to zajistíme?“

Tak vznikl první projekt, kde jsme se zavřeli s researchery do místnosti. Nedělali jsme to sami, úplně jen na náš tým, ale společně a vytvořili jsme – nechci říkat SaaS platformu, ale prostě cloudové řešení, kde kdokoliv z IBM mohl přijít a dělat inferenci nad Bloom modelem.

To byl obrovský průlom. Začalo to sice v malém, ale rychle se to rozšiřovalo, jak přicházely další modely a přidávali jsme nové funkce. Proč to byl průlom? Konečně si lidi mohli s prvními většími AI modely začít hrát, zjednodušeně řečeno.

Hlavně to ale akcelerovalo další výzkum v IBM. Lidé předtím neměli, kde spustit velké modely, GPU byly omezené. IBM do svých zdrojů investovala, měla pár GPU k dispozici, ale GPU bylo od začátku velkým problémem. Jakmile přibylo více modelů, bylo nutné řešit, jak rozdělovat GPU zdroje mezi researcheři, kteří chtěli zkoušet různé modely.

A ten průlom spočíval nejen v tom, že to bylo užitečné pro samotné researchery – nezapomínejme ani na netechnické lidi, například management – protože jsme k tomu udělali uživatelské rozhraní a v rámci společnosti to demokratizovali.

Jestli si pamatuješ OpenAI Playground, když vznikl, teď nechci mluvit o GPT přímo, ale měli tam něco, kde jsi mohl s modelem experimentovat, nastavovat parametry jako temperature a podobně, my jsme měli v té době něco podobného.

Takže jsme odemkli něco, co oni si nemohli spustit sami a najednou bylo jedno prostředí, kde nemuseli řešit… (text končí).

Opravený text:

Itku dali své loginy a mohli si požádat o kredity. Bylo to zdarma pro kohokoliv v IBM, a ten dopad jsme měli i tady v české IBM. Když například někde něco prezentujeme, co děláme, lidi nám říkají, že si pamatují tenhle projekt, že to byla pecka a že to fakt mělo obrovský dopad interně v IBM a nejenom v IBM, IBMka si uvědomila, že tam je skutečná hodnota, a vlastně se pak dostávali dál k přístupu.

Systémy společností jako SAP a dalších bylo strašně moc, to už si nepamatuji, to bylo potom mimo náš kontakt s realitou. Pomalu jsme měli více než pět milionů requestů za den na inferenční servery, samozřejmě škálovatelnost těch věcí byla složitá. Začínali jsme na Transformers knihovně z Hugging Face, pak jsme přešli na VLN-ko a opět nechci říkat, že jsme dělali všechno sami. Měli jsme kupu výzkumných týmů, kteří řešili trénování modelů, klasický fine tuning, což z našeho pohledu není škálovatelné. Měli jsme ale také tyto fine tuning techniky, kdy jsme mohli jednoduše upravovat modely. Proto se řešil prompt tuning, IBM přišla se svou vlastní prompt tuningovou mechanikou, MPT, teď si nepamatuji přesně, co ta zkratka znamená, která se ale zase úplně neosvědčila, takže pak se od ní upustilo.

Byly tam takové pivotové momenty, jako v klasickém startupu – něco rychle vyzkoušíš, a pokud to nefunguje, opustíš tu myšlenku a jdeš dál. A teď, jaký je to rok? Je to 2022-2023, nějak tak, mně to všechno v AI světě už trochu splývá. Ale asi nejdůležitějším výstupem z tohohle projektu bylo to, že náš mandát – tedy pro IBM nebo pro náš tým v IBM, což nejsme jen my jako Apoko, ale celý širší tým – byl hledat inovace a inkubovat myšlenky z výzkumu.

Jedna věc je, že nemáme monetizační strategii, naším cílem není na konci dne vydělávat peníze pro IBM Research, ale inkubovat produkt, který pak produktové týmy IBM Software či jiné divize mohou převzít a vytvořit z něj finální produkt pro zákazníky. To akceleruje výzkum a možná přinese nové myšlenky, pohledy a informace o oboru zpět do IBM Research.

Všechny tyto tři věci se nám povedly v tomto projektu, který je inkubací IBM offeringu Cynics AI. Měli jsme obrovský vliv na vznik Watson X AI, i když ten nedoporučuji úplně používat, protože Watson X AI musela být nakonec trochu integrovaná do stávajících IBM softwarů.

Co je tedy Watson X AI? Je to inferenční a inovační platforma, která obsahuje spoustu modelů a je takovým LLM providerem, pokud to tak zjednoduším. A proč ji nedoporučuji? Kvůli uživatelské zkušenosti. Museli ji integrovat do celého systému... (poznámka: text dále nebyl dokončen).

Tady je opravená verze vašeho textu:

Eli to chtějí zabalit do nějakých... Prostě celou sadu, jako Adobe – musíš stáhnout celý Adobe Cloud i se vším ostatním, abys to mohl spustit. Ta uživatelská zkušenost není úplně ideální. Acrobat ano, je to takové robustní řešení, ale postupem času se to zlepšuje.

Na IBM to asi nebylo úplně špatné, protože IBM má velká enterprise řešení, a chápu, že nejsou startup, nejsou schopni ty věci stavět od nuly, když to tak řeknu. Pro ně je to samozřejmě složitější. Ale tohle se nám podařilo zinkubovat, což byla velká výhra.

Mimo to jsme měli vliv, protože IBM koupilo Red Hat v roce 2018, pokud se nepletu. Takže jsme měli vliv na to, jak vypadá design inferenčních endpointů v OpenShift AI. Bavili jsme se s lidmi z Red Hatu, seděli jsme u stolů, byli jsme součástí pracovních skupin, co tvořily komunitu mezi ostatními velkými společnostmi, kde se domlouval inferenční standard.

Samozřejmě OpenAI mělo svůj předkompilovaný standard a my jsme diskutovali o některých věcech, jestli jsou správně navržené nebo ne. Bylo to zajímavé, protože jsme měli přístup k té komunitě.

Pokud chvilku počkáme, jaký vlastně ten inferenční standard je a proč je důležitý? Je to prostě pro standardizaci volání LLM – jestli musíš měnit parametry podle toho, jakého máš providera. My jsme tlačili na to, aby byly standardy hodně podobné OpenAI, protože kdybychom pustili IBM s vlastním odlišným standardem, nebylo by to dobré.

Trochu jsme byli kvůli tomu kritizováni, že kopírujeme OpenAI, ale nakonec se ukázalo, že to bylo správné řešení, protože OpenAI vlastně nastavilo standard. Ano, byl to standard, i když samozřejmě lidé o tom přemýšleli a chtěli něco lepšího. V té době nikdo nevěděl, jestli OpenAI vyhraje – standardy jsou vždy složité a komplikované. K tomu se ještě možná dostaneme, protože na standardech děláme i jednu větší věc.

Teď, po tomto projektu, když jsme dělali inferenci nad LLM, které byly vlastně chytřejší LLM, jsme začali přemýšlet o agentních systémech. Opustili jsme pole inferenčních modelů a tunování a přišli jsme do oblasti agentních systémů. První věc, co jsme udělali, bylo zamyslet se nad tím, co vlastně agent znamená – to bylo někdy začátkem roku 2024.

Co jsou agenti a jak je budeme vytvářet? Udělali jsme si vlastní framework. Na trhu zatím není standardní definice agentů – jsme v polovině roku 2025 a stále si nejsem jistý, že existuje standard. Pro mě je to jednoduché – agent je podle mého vše, co má nějakou autonomii. A co to znamená...

Pokud byste chtěli, můžu pokračovat a dokončit poslední myšlenku nebo upravit text ještě víc.

Á, je to velice jednoduché. Do doby, než LLM byla jenom o tom, že zavolalo inferenci, dostalo jsi nějakou odpověď zpátky a tím to končilo, tak to bylo prostě inference LLM. Jakmile jsi tam přidal nějaký loop, například for loop, aby LLM zkoušelo několikrát a rozhodlo se, kdy zastaví a řekne „jo, končím, už nemám co dělat,“ tak tohle je podle mě agent. No a tím pádem jsou reasoning modely agenti? Protože tam jsou loopy. Ano, proč ne? Myslím si, že ano. Přesně ty reasoning modely vycházejí víceméně z prvních paperů, které popisovaly různé architektury agentů.

Když to vezmu zpátky k nám prakticky, tak první, co jsme udělali, bylo zkoušení review agenta, což je nějaký, teď nevím přesně, co ta zkratka znamená, ale je to určitý plánovací agent, který se snaží — ty mu řekneš, co chceš udělat, on si napíše plán a potom ten plán exekuuje krok za krokem. Případně tam můžeš paralelizovat některé věci, ale to je detail. A nakonec přijdeš s nějakou potenciální odpovědí. To funguje dobře, pokud je problém plánovatelný a nezávisí na mezikrocích, tedy když nedostáváš novou informaci, kterou potřebuješ zavést jako základ pro další rozhodování.

Dalším populárním patternem je reaction pattern, který vlastně invokuje reasoning v modelech. To znamená, že model obohacuješ, protože problém s LLM je, že jsou to jazykové modely s určitými znalostmi, ale potřebuješ, aby interagovaly s externím světem a dělaly něco smysluplného. Tedy tooly. Aby interagovaly s externím světem, musí trochu „přemýšlet,“ kdy co použít a jak zavolat jednotlivé nástroje. Reaction pattern tedy funguje tak, že přijdeš ty, řekneš, co máš dělat, agent se zamyslí, rozhodne se například zavolat nějaký tool — třeba tě zajímají informace o Donaldu Trumpovi, k dispozici je Wikipedia tool, takže si ho zavolá, získá informace. Pokud jsou tyto informace dostatečné, odpoví. Pokud ne, zkusí to znovu s jiným dotazem nebo použije jiný tool, třeba web search. Až je spokojený, dá finální odpověď. Tento reaction agent je docela obecný, protože s ním můžeš řešit různé problémy.

Ještě doplním, že „reaction“ neznamená JavaScript React, ale jde o přístup, jak LLM iterují k řešení daného problému.

Nakonec jsme si vytvořili vlastní framework, kde jsme implementovali tyto agenty. Můžeš se ptát, proč další framework, když už existoval LangChain, Autogen (první verze), LangGraph (podle mě ještě nebyl), Baby AGI a další. Ale my jsme to dělali hlavně... (pokračování tvého původního textu, pokud budeš chtít).

Opravený text:

Z toho důvodu, abychom si ty věci vyzkoušeli, naučili se je a získali hluboké znalosti – prostě R&D. Já tam slyším ten R&D a trochu tam slyším i IBM. A IBMka řekla: „Proč ne? My bychom stejně interně chtěli možná mít svůj vlastní framework, ve kterém můžeme mít svůj vlastní názor na to, co má dělat, a doručovat tam nějaké naše funkce,“ už jenom z toho důvodu, že IBMka si vytváří svoje vlastní modely. Takže máš tu flexibilitu přidat tam funkce, které jsou specifické pro tvoje modely.

No a tohle byly první ty ReAct patterny, ale pak jsme samozřejmě přišli nebo přišel ten ReAct agent. O tom se možná můžeme bavit z širšího hlediska, jestli frameworky mají dneska vůbec smysl, protože hodně funkcí, které frameworky umí, už přichází přímo od LLM providerů, jak jsi říkal, nebo přímo do těch modelů – ať už je to reasoning, nebo ne. U toho ReAct agenta je samozřejmě tool calling něco, co už LLM provideři dneska dělají. Nemusíš tedy v systémovém promptu říkat, jak se má chovat, když má nějaké nástroje a kdy má něco zavolat. To už necháš na LM provideru a doufáš, že ti řekne: „Já chci zavolat tenhle tool,“ a že ho třeba za tebe i provozuje.

Tak jsme potom přišli s konceptem tool calling agenta a úplně poslední věcí, kterou jsme nedávno přidali, je koncept requirement agenta. To je taková poměrně inovativní věc z naší strany, uvidíme, jak se to uchytí ve světě. Requirement agent je agent, kterému můžeš omezit nejenom jeho kód, ale také instrukce. Často se totiž dělá, že agentům v instrukcích říkáš, co mají dělat, a doufáš, že to skutečně dělají. My jsme přišli s tím, proč to prostě nenakóduješ.

Víceméně tak řeknu: použiješ věci typu constraint decoding. Nevím, jestli lidé o tom vědí – u těch LLM máš možnost kontrolovat jejich výstup přes constraint decoding. Takže řekneš… například: „Co se stalo na Rudém náměstí Nebeského klidu?“ A můžeš říct, že další token, který má model vygenerovat, musí být třeba právě tenhle. Můžeš to specificky nasměrovat. Často se to používá při generování instruovaných dat: když má model vygenerovat JSON, první token musí být závorka složená. Takže můžeš donutit model, aby vygeneroval přesně to, co chceš a co očekáváš.

Je to fajn, samozřejmě to zní krásně, ale má to vliv na kvalitu – to si musíme říct. Model může vybrat token, který není vůbec pravděpodobný, a výsledkem může být špatná data, halucinace – to už pak záleží. Ale v každém případě u requirement agenta si můžeš říct, že agent musí zavolat třeba tyhle tři nástroje, v tomto pořadí, nebo že vždy jako první musí zavolat právě tento nástroj, protože znáš svůj use case specificky. Víš, že potřebuješ vyřešit daný problém agentními systémy nebo agentem, a víš, že k tomu…

(Tu už text končí.)

Jasně, tady je opravený a upravený text pro lepší srozumitelnost, plynulost a gramatiku:

Ten agent byl schopný zavolat, ale vždycky třeba musí začít s tímto tool callingem, aby získal správný kontext. A když znáš daný případ, můžeš mu jednoduše říct, že vždycky musí zavolat právě tento tool. Pro tento tool musíš vždycky zavolat právě tenhle konkrétní nástroj a zároveň můžeš vytvářet docela komplexní pravidla — jakousi pravidlovou strukturu pro agentní systémy. To se pak propíše do instrukcí, do systému promptu, pokud to takto jednoduše shrnu.

Samozřejmě se pak to vynucuje přes constraint decoding — pokud to model podporuje. Pokud ne, máme i další postupy, jak to enforceovat, třeba dáváme do smyčky (loop), kde agent dostává zpětnou vazbu, že má generovat výstup v určitém formátu. To je jedna z věcí, kterou jsme nedávno vydali v našem frameworku.

Testujeme nové myšlenky a také jsme tam zavedli koncept workflows, protože se na to často lidé ptají. Anthropic má na workflow svůj pohled, ale z mého pohledu jsme tam zavedli koncept workflow podobný landgraphu. Umožňuje přecházet přes jednotlivé kroky, které mění nějaký stav. Ty kroky mohou být agentní, tedy vyvolávající nějaké nástroje, nebo jen volat LLM, tedy modely, které vykonávají úkoly. Workflow tak říká, co se má kdy stát.

U nás je workflow takové, že může obsahovat i agentní kroky — tedy akce, které provádí agenti. Je to všechno připravené, a v rámci frameworku můžeš snadno stavět agenty i multi-agentní systémy.

Když se na to podíváš z pohledu ostatních providerů — jako OpenAI, Anthropic, Google, Gemini — co dělají dobře? Když stavíš podobnou infrastrukturu od základů, tak si často říkáš: „Hele, vlastně jsem si dal prostor to vyřešit sám a dostal jsem se ke stejnému řešení.“ A naopak, co tam vidíš jako rozdíl – co dělají jinak, jaké mají postupy, které ty sám v rámci bottom-up vývoje možná nevidíš?

Co bych chtěl hlavně zmínit je to, že my děláme celé řešení primárně na open source modelech a celá platforma je open source. Cílem je umožnit komukoliv přijít a vyzkoušet si věci sám. Jasně, můžeš dnes používat i Anthropic, ale když půjdeš na GitHub, najdeš tam naši práci kompletně otevřenou. Navíc je to pod Linux Foundation — IBM nebo IBM Research se rozhodli to darovat komunitě, takže je tam steering committee a open governance, tedy otevřený způsob řízení, a kdokoliv může přispívat.

To je tedy důvod, proč to děláme — protože například OpenAI nebo Anthropic mají své vlastní implementace v rámci svého hlubokého výzkumu, kde mají zavedené workflow a další principy, které my se snažíme zpřístupnit komunite jako otevřený standard.

Pokud chceš, mohu text ještě víc formálně upravit nebo naopak ponechat více hovorový styl.

Jasně, tady je opravený text:

Jaký supervisor agent? Řešený. Řešený, přesně. Ale když chceš mít tu kontrolu, chceš mít kontrolu nad těmi modely třeba, chceš používat menší modely, protože nemůžeš utratit tolik peněz, protože by to mělo být rychlejší, chceš to mít on premise všechno, chceš to mít fakt jako postavené, nechceš být jen zákazníkem, když to také zjednoduším, Anthropicu nebo OpenAI, a ještě chceš podporovat tu research komunitu, kterou my samozřejmě furt táhneme za sebou a dáváme jim ten tooling. A oni samozřejmě také přispívají k těm věcem, takže to není tak, že bychom my dělali něco jen pro ně, to je prostě komunitní věc.

Tak tohle je jediná cesta, jak se můžeš učit nové věci, protože Anthropic třeba tyto věci dělá a sám se na tom učí a posouvá ty modely dál, což benefituje jejich společnosti. My se zase snažíme benefitovat IBM Research a celou komunitu okolo. Dělá to ještě někdo jiný? Asi spousta lidí, ale v této velikosti, anebo třeba Facebook s Lamou jde hodně open source. Nemyslím si, že v této velikosti je třeba Lama od Facebooku nebo Meta jen jedna část, ale zase je to hodně pozicováno pro jejich modely, není to open governance, je to pozicováno hlavně pro jejich vlastní produkty.

Máme tam nějaké diskuze s Lamastekem, třeba jak se do toho integrovat, ale, abych se k tomu možná ještě dostal, my dáváme ten framework, ale neděláme jenom framework. Děláme potom ještě něco, čemu říkáme platforma, pak děláme ještě nějaký ten standard na agentní komunikaci a tohle třeba Meta úplně nedělá. Samozřejmě nechci tvrdit, že nevidíme do všech jejich projektů, které Meta dělá, a hlavně nevidím, co dělají interně, takže takhle nechci hodnotit.

Ten framework má název, když ho budu googlit na GitHubu? Všechno, co děláme, se jmenuje BAI – B jako včelička, AI. Máme tedy BAI framework, pak BAI platformu a máme ten protokol, který se jmenuje ACP, něco jako MCP, Model Context Protocol. My se jmenujeme Agent Communication Protocol, ACP. A co to je? Je to standard na komunikaci mezi agenty, a nejenom mezi agenty, ale také mezi agenty a externím světem, například člověkem, dalšími agenty nebo nějakou mikroservisou, když to zjednoduším.

Dostali jsme se k tomu ACP možná trochu obloukem, protože náš problém s frameworkem je, že můžeš postavit agenty jakkoliv, jakoukoliv architekturu, máme tam další cool věci, ale co s tím?

Postavíš si něco, co funguje, vyřeší ti to tvůj produkt, tvoji produktivitu, nějaký problém, ale jak to sdílet s ostatními? Je to pořád osobní nástroj. Jo, je to hodně fragmentované. Takže jsme si řekli: pojďme udělat platformu. Pojďme udělat jednoduché místo, kde podpoříme lokální vývoj, kde si můžeš vzít svůj laptop, vytvořit si agenta a jednoduše toho agenta...

Pokud chceš, mohu pokračovat, stačí říct!

Tady je opravený a stylisticky upravený text:

Ta možnost vzít to a nadeployovat kamkoliv – on-premise, do cloudu, svému partiákovi, a jednoduše to zabezpečit jako nějaký image, který mu dáš a on si to může rozjet u sebe. To je ten druhý projekt. A proč se k tomu zmiňuju, než jsem se chtěl vrhnout do ACPčka? Protože z toho přirozeně vyplývá, že jakmile začneš dělat platformu, kde můžou běžet agenti, tak dalším krokem jsou vícenásobní agenti, agenti, kteří můžou spolupracovat a něco společně dělat.

A aby tohle bylo možné, agenti se musí mezi sebou nějak dorozumět. Tu platformu jsme stavěli už někdy minulý rok a v té době vzniklo MCPčko. Myslím, že na konci roku 2023. Už mě to teď přesně nezní, ale to je jedno. MCPčko vzniklo a nám se to moc líbilo. Dokonce jsme byli asi třetím klientem MCP. Byli jsme zapsáni v jejich seznamu klientů, protože náš framework byl schopný volat MCP servery.

Prvními dvěma klienty byli, pokud si to pamatuju, Anthropic – jejich Claude Desktop aplikace – a druhého si nepamatuju. Takže s MCPčkem jsme narazili na ně relativně brzy a hlavně se nám líbilo, jak to měli vyřešené. Líbila se nám ta specifikace – fakt do detailu – naspecifikovali to tak, že tam nebyly žádné nuance, co se týče účelu, bylo to jasné.

Samozřejmě jsme měli s tím lehké problémy, například kvůli JSON RPC, na kterém to bylo založené. Ale motivace Anthropic byla naprosto jasná.

Chtěli v MCP vyřešit svůj vlastní problém a to se mi na Anthropicu líbí, že se snaží sami sebe posouvat a vždycky vyřešit nějaký reálný problém, a když zjistí, že to má přínos i pro komunitu, uvolní to jako open source. Jejich problém byl Claude Desktop a jak tam integrovat další nástroje lokálně. Pro ně byl zásadní transport přes STDIO a JSON RPC, tedy vzdálené volání funkcí (Remote Procedure Call). To dávalo smysl v daném momentě.

Dneska se ale Anthropik a MCPčko dostávají do situace, kdy například Google Drive chce mít svůj vlastní MCP server nasazený na cloudu, tedy vzdálený MCP server. A na to MCPčko ze začátku úplně nebylo stavěné. Uvidíme, kam se ta cesta MCPčka ubere.

A abych to vrátil k našemu frameworku, tak my jsme vlastně celé to MCPčko použili jako základ, vytvořili jsme si fork a trochu jsme si ho upravili. Bylo tam totiž omezení, že jeden klient = jeden server, což u nás nefungovalo. Potřebovali jsme zavést koncept sessions a přidali jsme koncept agentů. Na pár řádcích kódu jsme vlastně dostali MCPčko do podoby, která vyřešila náš problém: najednou jsme měli agentní systémy, které mezi sebou mohou komunikovat. Komunikovat přes nějaký strukturovaný formát. Tenkrát jsme ještě neřešili, jak přesně vypadá ta samotná komunikace mezi agenty, mohli jsme jim posílat prakticky cokoliv.

Pokud chceš, můžu ještě text upravit do profesionálnějšího nebo méně formálního stylu, dej vědět.

Zde je opravený text s lepší srozumitelností a gramatikou:

S těmi agenty jsme se něco naučili a zjistili jsme, že kdybychom ten problém měli řešit právě pro agenty, zkusili bychom to udělat trochu jinak. Tak jsme začali pracovat na projektu, který se jmenuje ACP — Agent Communication Protocol. Ten jsme releasli asi dva týdny před Googlem a jejich A2A protokolem. Zrovna v okamžiku, kdy Google vydával A2A, jsme byli v Bostonu v IBM kancelářích, a Google byl hned naproti, na druhé straně ulice. Říkali jsme si, že to snad není možné, a nakonec jsme měli i společnou afterparty.

Je vidět, že naše standardy tehdy docela ovlivňovaly situaci, protože A2A je hodně podobný ACP. A2A s velkou pravděpodobností zvítězí nad námi. Teď už je jen otázkou, kdo se stane skutečným standardem. Bohužel si nemyslím, že naše ACPčko má velkou šanci vyhrát, ale uvidíme. Dnes, když to natáčíme, zítra totiž vydáváme kurz Deep Learning AI založený na ACP, takže bude opravdu zajímavé sledovat, co se stane dál.

Co se týče komunit a soupeření mezi Googlem s A2A a Anthropic s MCP, bude zajímavé sledovat, kdo se stane standardem v agentní komunikaci v následujících měsících.

Mám teď dvě otázky z mého laického pohledu. První je – co vlastně znamená „udělat standard“? Co je standard? Kdy už se věc považuje za standard, a kdy za komunikační protokol?

Odpověď: Určitě bych to zatím nenazýval standardem. Standardem se to může stát až postupem času. My tomu teď říkáme open protokol, protože často je to svádí k tomu nazývat to standardem, ale ve skutečnosti to zatím není.

Pro nás bylo potřeba vyřešit interoperabilitu agentů na naší platformě. MCP nám to neřešilo a A2A tehdy ještě neexistovalo. To bylo jednoduché. A co to vlastně znamená? Musíš se podívat na konkrétní uživatelské případy.

Měli jsme obrovskou výhodu, že jsme měli vlastní platformu a několik implementovaných agentů. Agenti byli hodně „wild west“ — ne jen klasické agenti, kteří používají react nebo tool calling, ale měli jsme tam např. ADR, což je programovací agent, dále GPT researchera, každý implementovaný v jiném jazyce, v různých frameworcích nebo i bez nich.

A co opravdu znamená, aby agenti mohli spolupracovat a něco dělat? V jednoduchosti si uvědomíš, že musíš řešit streamování zpráv (messages), které se mohou lišit – není to jen text.

Samozřejmě, že můžeš poslat i text, ale často je potřeba integrovat i něco dalšího. Například chceš, aby agent dostal na vstupu potřebné informace, bez toho, aby bylo třeba zapínat další jazykový model, který by musel rozpoznat, jestli v textu ta informace je, aby následně mohl zavolat nástroj (tool).

Proto je potřeba řešit, jak lze...

Pokud chcete, mohu pomoci i s pokračováním textu.

Tady je opravený text s lepší strukturou a interpunkcí:

Třeba strukturovat nemusíš, ale musíš řešit, že to jsou multimodální stupy často, že model je schopný ti říct text a k tomu ti hodit obrázek, když to tak zjednoduším. Takže si musíš udělat názor na tohle – co potom drátě doopravdy může běžet a co by měl být ten standard, aby ti agenti mohli spolu fakt doopravdy mluvit.

Pak řešíš věci typu long-running joby. Hodně často u těch D-presearchů běží třeba 10 minut ti agenti, a ty potřebuješ, aby ten standard měl vyřešené to, že já nemusím těch 10 minut čekat a mít otevřený connection, ale můžu si odběhnout, dostat nějaké IDčko, přijít později a říct: „Já chci ty výsledky, na kterých jsi dělal, dej mi je zpátky.“ A těch challenge je tam víc.

Ta největší challenge podle nás je ease of use, tedy snadnost používání, nebo ease of integration – jak my tomu říkáme. Já nechci mít... protože ty jsi vznesl mikroservisy a takové věci. V čem je agent rozdílný od mikroservisy? Nad tím se můžeme zapolemizovat, jestli je to dostatečně jinak, ale agent potřebuje přístup k LLM (large language modelu), takže kde máš nějaký ten důvod zpátky, kde je nějaký LLM provider. Většinou má nějaký stav, protože můžeš mít samozřejmě bezstavové agenty, ale taky potřebuješ stavové agenty, které dělají něco složitějšího; nemůžeš třeba úplně jednoduše restaurovat.

A těch věcí je tam asi teďka hodně – nevím, jestli si vzpomenu na všechno, ale hlavně vstup do toho agenta, to je další věc. Fakt to často není JSON, což je trochu rozdílné od mikroservisních architektur. Ale opět, ano, je to kus nějakého procesu, který někde běží a má nějaký vstup a nějaký výstup a možná prostě potřebuje přístup k LLM – je to hodně podobné.

Jak jsem říkal, my jsme šli tou cestou ease of use, hlavně z toho pohledu, aby když to chceš používat, tak abys tam nemusel mít SDKčko, abys ho tam mohl použít bez něj, protože když máš SDKčko k tomu, abys mohl mluvit s agentem, tak SDKčko odsvěrá runtime, což je strašně nepohodlné, když si to vezmeš. Proč by to nemohl být prostě jen HTTP request, který můžu dát tady přes terminál, přes cURL?

Takže my jdeme touhle cestou, a ten zbytek, MCPčko ani A2E vlastně dnes prakticky bez SDK nemůžeš použít. Ale náš protokol stojí za tím, že to můžeš. A můžeš si jednoduše říct, že hlavně máš třeba možnost, že my ti garantujeme, že můžeš s námi komunikovat synchronně i asynchronně. To znamená, pokud řekneš, že je... Protože my chceme podporovat tenké klienty, ne ty tlusté, ty tlusté klienty, které musí mít všechny ty feature, aby mohly s agentem komunikovat. My jdeme cestou, že klient si může říct: „Já chci ten request a já si na něj počkám, dej mi ho.“ Já nechci řešit to, že dostanu IDčko zpátky a budu si pak pollingem (dotazováním) výsledky průběžně dotazovat. Nebo můžeš mít různé alternativy k tomu...

Pokud chceš, mohu pokračovat v úpravě i od konce textu, kde končíš u „nebo můžeš mít různé alternativy k t...“. Dej vědět!

Tady je opravený text s úpravami pro lepší srozumitelnost a plynulost:

Omuto, nebo push notifikace. Co je thin a thick klient? Thin a thick klient jsou v podstatě úzký a široký, tedy více komplexní a více jednoduchý. Karl, když si vezmeš terminál, dokážeš v něm dělat hodně věcí, a samozřejmě je to docela thin klient, protože vůbec nemá povědomí o službě na druhé straně, se kterou komunikuje. Nemá žádné specifické implementace, které by potřeboval nebo mohl konzumovat. Takže z mého pohledu je to thin client.

A pak jsou tady thick klienti, kteří už o tom endpointu na druhé straně něco vědí a na základě toho se přizpůsobují, dovolují ti dělat víc. Například věci typu, kterým my říkáme evade — ty možná znáš heal, human in the loop, někdo tomu říká interrupts. Myslím, že Langrad tomu říká interrupts. A MCP právě v poslední verzi, v minulé nebo této týdnu, tomu říká hallucination. Je to ta stejná věc: agent přestane exekuovat a řekne, že nemá dostatek informací nebo potřebuje nějaké schválení, cokoliv externího, aby mohl pokračovat. Vlastně se exekuce zastaví a čeká na další data.

My tomu říkáme evade a máme svůj koncept, jak to implementovat tak, aby nebylo potřeba nutné nějaké externí zásahy. Super.

A teď poslední část mé otázky byla, co vaše ACPčko, MCPčko a agent-to-agent? Pokud udělám krátkou rekapitulaci, říkal jsi, že MCPčko a agent-to-agent potřebují SDK, takže to není tak snadné na použití, jak jste se snažili vy. Také jsi zmínil, že v Antropiku má MCPčko stále zapouzdřený ten původní desktopový, ne úplně cloudový svět.

Které automatizmy z toho vyplývají, z pohledu flexibility a uživatelské příjemnosti agent-to-agent? Jak se na to díváš z pozice někoho, kdo na tom pracoval? Pro mě i myslím pro spoustu lidí je to marketingová věc, co je teď víc „cool“, a teď je hodně cool MCPčko.

O tomhle bych mohl mluvit dlouho, zkusím k tomu přistoupit jinak. Za prvé, naše akce je přispívat do MCPčka, protože víme, že další standard ACPčko je hloupost — pokud to tak trochu zjednoduším. Samozřejmě nevíme to úplně jistě, máme na to deep learning AI kurz, uvidíme. Pro nás bylo strašně důležité si to osahat, nasát tu znalost a teď jsme připraveni jít do MCPčka a přispívat zpět do té komunity. Už máme otevřené nějaké první pull requesty do MCPčka a budeme na tom teď intenzivně pracovat.

Souběžně jsme v kontaktu s A2A, s Googlem nebo IBM, kde Google je součástí několika jejich interních skupin firem a lidí, kteří mají zájem to posouvat a ovlivňovat. Takže současně se díváme na to, jak bychom mohli přispět do A2A, ale je třeba realisticky si uvědomit, kdo z nich může zvítězit.

Teď to úplně neřeknu, kdo vyhraje, nebo to je můj osobní názor, mimo naše projekty a výzkum. Nejde mi ani tak o to, kdo vyhraje, to je zase... Já se k tomu chci dostat. Vím, co asi chceš slyšet, ale myslím…

Pokud chceš, můžu text ještě více zpracovat nebo upravit do formálnější podoby.

Jasně, tady je opravený text:

Myslím si, že vyhraje MCPčko a to z toho důvodu, že je teďka vidět, že si jsou vědomí toho, že udělali něco super. Mají obrovský ekosystém, vyřešili problém, jak získat kontext do modelu – to byl ten největší pain point, samozřejmě. A teď se to stírá k tomu, že se snaží mít nějaký názor na agentní věci. Neříkají to úplně otevřeně, nebo z mého pohledu to neříkají úplně na férovku, že tam bude koncept agentů, ale přidává se něco, co právě vzniká – pracují na nové verzi. Mají tam OAUTH podporu, nějaký vylepšení v bezpečnosti a takové věci. Na čem teď budou pracovat, jsou koncepty registrů (concept registries), nebo jak sami říkají, zaměří se na koncept asynchronních, dlouhotrvajících úloh (long-running jobs). To všechno je přesně to, co jde trochu proti tradičním agentním systémům.

Doufám, že budou schopní implementovat některé z našich příspěvků, například partial result streaming, což zatím pro agenty nemají podporované. Komunita je aktivní. MCPčko se podle mě bude formovat tak, že přidá tu podporu pro agentní věci. Jediná nevýhoda, kterou trochu sdílí s A2A, je to, že si vybrali JSON-RPC, což podle mě jako standard komunikace nemá vyřešenou spoustu věcí, například streamování a partial results, což je škoda a z mého pohledu by bylo možná lepší tento protokol opustit. Pro Anthropic by to byl velký skok, ale myslím si, že by o tom mohli uvažovat. Mimochodem, A2A nedávno (před týdnem či dvěma) vydalo REST a gRPC jako další verzi, jak komunikovat.

Mě moc baví, že díky tvé cestě jste s bráchou v Praze založili firmu, která řeší takovéto věci, baví se tím, přispívá do MCPčka a je opravdu na špičce vývoje AI agentní infrastruktury, když tam hodím všechny buzzwordy. A přitom vás, kolik je vás teď? Asi 25, plus minus. A to, že vás je v Praze na Pragovce tolik, mi přijde hrozně sympatické.

Co to dál pro vás znamená? Mně to přijde jako obrovský zázrak a štěstí, že jste u něčeho takového. Samozřejmě máme tady skvělé chytré lidi, kteří dělali v Anthropicu a zdravíme Stanford a další, kteří se na těchto věcech podíleli. Ale fascinující je, že to děláte jako firma v rámci IBM Research na takové světové úrovni.

Takže what's next, když se zeptám jako IBM Research? My jedeme dál, nás to taky strašně baví. Tohle je přesně to, co jsem si vždycky přál dělat – zajímavé problémy, které tě nutí ráno vstát z postele a říct si: "Jo, dělám něco zajímavého a možná i trochu impactful." Víme, že ten dopad už teď máme v IBM Research, a doufáme, že budeme mít ještě větší komunitní dopad.

Takže co dál? Jedeme dál, samozřejmě stále řešíme agentní systémy a multiagentní systémy. Myslím, že tohle téma bude aktuální minimálně další půlrok, možná i rok. A kdo ví...

Pokud chceš, mohu text ještě upravit do formálnější či naopak více konverzační podoby.

Opravený text:

Co bude potom? Samozřejmě superinteligence a taky lidi, co se baví o tom, co je blízko. Ale to je jedna věc, to jsou teda ty agentní systémy IBM Research. Jinak jako společnost hajrujeme, bavíme se s dalšími společnostmi, s jednou americkou bankou, se kterou se teďka bavíme, bavíme se s nějakým německým startupem z healthcare, všechno se točí kolem AI, takže explorujeme, kde je pro nás další zajímavý problém, do kterého můžeme krknout. A jak jsem říkal na Pragovce, nedávno jsme se teďka přistěhovali, takže děláme rebranding, zvelebujeme si kancelář. Life is good. Jo, life is good, jo.

Na co se těšíš v blízké době?
Na dovolenou.
Na dovolenou, dobře. Ale já se těším na ten kurz Deep Learning AI, to je pro mě velká srdcovka, protože sice tam neuvidíte nás, nikdo z Apple, všechno je to natáčené IBMáky, ale pro mě je to srdcovka z toho pohledu, protože Andrew N., zakladatel deep learningu a Stanfordu, doufejme, že jednou americký prezident. Mám velký respekt k tomuto člověku, dělal jsem jeho machine learning kurzy před x lety, a pro mě je to obrovská radost, že jsme schopni vytvořit tady kurz, který za ACPčkem, si myslím, že když to řeknu z 95 %, stojí prostě Apollo. Tam ten input z IBM-ky nebyl až tak drastický, protože to není takový research-driven přístup, je to prostě nějaká standardizace problému. A mám z toho strašně velkou pokoru, víceméně, že se nám tohle podařilo. A mám velkou radost, že to tady vzniká, a jsem rád, že jsem tě tady dnes mohl mít a ukázat naší komunitě, že máme na co být hrdí. Držím palce a doufám, že tuhle konverzaci brzo zopakujeme s tím, co nového jste na Pragovce vymysleli a postavili.
Jo, určitě rád znovu přijdu.
Díky moc, Matouši.
Já děkuju.

Děkujeme, že jste doposlouchali až sem. A díky taky našim partnerům, členům Data Talk klubu. Těmi jsou: Index, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Kebula, Emark, Carl Data Company, Data Mind, Notino a Flo. A pokud chcete zůstat v obraze, co se české datové scény a globálních datových technologií týče, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data.