Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datatalk. Dnes tady mám vzácného hosta, jednu z legend české AI scény, Petra Stanislava, v současnosti CTO startupu Eline AI. Ahoj Petře!
Ahoj, zdravím.
Takhle mě tady ještě nikdo neuvítal, že bych byl legendář. Hrozně se tak necítím.
Já o Petrovi mluvím jako o legendě, protože v českém prostředí je v DU s Honzou Romportlem spojen právě s projekty Machine Learningu a AI v Outučku a Daytaklair. A dnes je to spoluzakladatel a CTO jednoho z nejzajímavějších českých startupů, Eline AI. A o tom všem si budeme s Petrem povídat. Podíváme se, jak se vlastně vyvíjela AI technologie a co to v různých částech jeho kariéry znamenalo. Jak na tom jsou v tuto chvíli LLM, velké jazykové modely a vlna Generativní AI. A co to znamená je implementovat v praxi, protože na tom je postavený jejich startup a produkt Eline AI. Takže to všechno s Petrem dneska projdeme, ale nejprve se podíváme do minulosti, kde to všechno začalo. My jsme tady měli Honzu Romportla, tak to bylo na dlouho, a tvoje cesta je s ním dost spojená, takže jsem zvědavý, jak to všechno vzniklo a kde to začalo.
Tak kde začal tvůj zájem o umělou inteligenci?
Tak v podstatě, abych řekl, už v 90. letech, když jsem začal sledovat sci-fi filmy, protože vždycky jsem miloval technologie, tak jsem si nějak představoval nebo snil o tom, jaký by to bylo cool, kdybychom tady už měli to, co vidím v tom sci-fi. Takže už někdy tehdy a obecně mě technologie vždycky zajímaly.
Potom, když jsem šel na střední, tak jako v jedné reklamě — průmyslovka, automatizace, IT technologie byla jasná volba. Studoval jsem v Chomutově na průmyslovce, protože pocházím z Mostu, stejně jako Honza. Tehdy jsme se tady ještě neznali. Vystudoval jsem automatizaci, regulaci a podobné věci. Prostě mám rád, když věci fungují samy, když něco automaticky dělá to, co chci.
Když jsem dokončil průmyslovku, říkal jsem si, že všichni šli na FEL a podobné fakulty. Ale mě ta standardní regulace tolik nebavila a fakt mě zajímalo něco víc, aby to bylo jako v těch sci-fi filmech. Takže jsem se rozhodl studovat kybernetiku, kde jsem při přijímačkách říkal, že chci dělat umělou inteligenci, ať už na projektech nebo osobně víc spolu interagovat.
A vlastně Honza po nějaké době odešel do O2, jako tehdy seniorní data scientist, a nakonec chief data scientist. Možná mě Honza opraví, ale myslím, že už to byl chief data scientist. A po nějaké době si mě sám přetáhl do O2, protože říkal: „Hele Petře, nechceš to zkusit?“ Já jsem v té době měl nějakou krizi, říkal jsem si, že akademická sféra asi není úplně to pravé pro mě. Psaní článků a podobné věci bylo vždycky velký problém. Takže jsem si říkal, že bych si chtěl sám v sobě dokázat, jestli to zvládnu někde jinde, v něčem trochu náročnějším…

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

Konkurenčnějším prostředí. Takže jsem tu nabídku přijal, vlastně jsem dostal na starost datovou platformu. Ještě tě ale zastavím, než skočíme do útůčka, kam tě Honza vytáhl – říkal jsi, že jsi chtěl studovat umělou inteligenci a nejlepší volba byla kybernetika v Plzni. Co jsi tam vlastně studoval? Co vlastně znamenala ta umělá inteligence?

Pro mladší posluchače nebo pro ty, kteří si myslí, že AI je tady s námi pouze díky chat GPT, vysvětlím: co byla umělá inteligence v letech 2005 až 2010 a co poté tvé doktorandské studium? Když to takhle řeknu, byla dost podobná té původní umělé inteligenci z 60. let. Znamenalo to velmi sofistikovaně aplikované matematické modely, kde se parametry těchto modelů učily podle dat. Umělá inteligence je velmi široký obor, ale to, co vidíme dnes, je stále hlavně strojové učení. To znamená, že předkládáme velké množství dat nějakému modelu – tím modelem může být neuronová síť, GPT svým způsobem – který se učí své vnitřní parametry a na základě toho pak může dělat velmi sofistikované věci.

Co to vlastně bylo dříve? Ve své době to byla doba, kdy neuronové sítě byly považovány vždy za druhý nejlepší model, který jsme mohli na daný problém použít. Často se používaly lineární logistické regrese, support vector machines a další sofistikované techniky. Pokud šlo o učení s učitelem, bylo to takto; pokud ne, používaly se například shlukovací metody, k-means a podobně. Hodně to byla statistika – a stále je.

Takže moje studium bylo zaměřeno na lineární algebru, statistiku a poté jsem přišel k neuronovým sítím. Když jsem byl v pátém ročníku, měl jsem předmět neuronové sítě. Nebylo to jako dnes, kdy si v PyTorch nebo TensorFlow skládáme vrstvy, tehdy jsme se učili základy. Dělali jsme si perceptron model v MATLABu, a víceméně to byly jen maticové operace – a to byly naše neuronové sítě. TensorFlow přišlo až po roce 2012, tedy mnohem později. Ale zlomový moment, kdy neuronová síť opravdu funguje, už známe.

Mozek máme samozřejmě mnohem komplexnější, ale princip je podobný: neuron má axon a dendrit, přijímá informaci, nějak ji zpracuje a pokud je impulz dostatečný, vyšle signál. To nás dělá tím, kým jsme. Architektonicky jsou neuronové sítě rozhodně blíže biologickým neuronům než lineární regrese.

A potom, když jsem šel na doktorandské studium, věnoval jsem se řečovým technologiím. Když jsem nastupoval na doktorát, používaly se skryté Markovovy modely. Skrytý Markovův model je statistický model, ve kterém přesně nevíme, jak vznikají sekvence pozorování. Tyto modely nám umožňují modelovat procesy, kde neznáme mechanismus generování pozorování. Na tomto byl založen například rozpoznávání řeči.

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

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

Po velmi krátké době, řekněme dvou, třech let, v letech 2013, 2014, se vlastně tady začalo řešit rozpoznávání pomocí neuronových sítí. Nejprve standardní feedforward, potom LSTM sítě a samozřejmě ideální na tento úkol jsou rekurentní neuronové sítě, protože mají zpětnou vazbu uvnitř a jsou tak vhodné pro zpracování signálů, jelikož berou v potaz historii. Problém je, že se velmi těžko paralelizují.

V začátcích se všechno pořád řešilo přes různé frameworky, nejdříve HTK, potom Kaldi. Nakonec, a to podle mě platí i dnes, by u moderních LLM bylo možné si klidně napsat vlastní rozpoznávač přímo v TensorFlow, spíš ale v PyTorch, což je možná příjemnější. Abstrakce z tvorby neuronové sítě je taková, že prostě dáte třeba lineární (feedforward) vrstvu, přidáte batch normalizaci a podobně — je to jako skládat stavebnici z lega. Ještě si pamatuju dobu, kdy jsme skutečně psali maticové operace ručně.

Od začátku jsem šel tou cestou machine learningu, nebyly tam žádné pravidlové přístupy.

Ne, ne, ne, pravidlový přístup samozřejmě také znám a přičichnul jsem k němu. Vlastně jsem nezmínil důležitou část EIK, která je teď trochu opomíjená, ale stále je přítomná například v Alphafoldu nebo alespoň v AlphaGo. Spousta problémů může být řešena stromovým přístupem, kdy si představíme šachy nebo jinou hru, kde máme nějaký stav. Z tohoto stavu vedou různé cesty dál — to si můžeme představit jako strom (ne graf, protože ten může být cyklický). Pak hledáme optimální strategii, jak projít tímto stromem od bodu A do bodu B.

Například podúrovňový přístup stále funguje v mapách nebo v autonomním řízení vozidel, kde se často používá reinforcement learning. Představte si, že auto chce zaparkovat — různé možné pohyby auta můžeme opět reprezentovat jako strom a hledáme optimální strategii, jak auto zaparkuje. Toto už je ale trochu jiná problematika.

Toto je jedna z částí, které jsem se taky hodně věnoval, tedy například problém ukládání a vyhledávání ve stromových strukturách, kde klíčovým algoritmem je A* (A-star) a podobné algoritmy, které jsou svým způsobem velmi elegantní a jednoduché, ale dokážou řešit sofistikované úlohy. A* algoritmus například porazil Kasparova v šachu — samozřejmě potřeboval hluboké prohledávání, protože strom byl obrovský, ale technicky je to stále tenhle přístup.

Navíc, možná na to narazíme, až budeme mluvit o výpočetní náročnosti LLM, když vím, že existují třeba tři možné varianty, nemusím prohledávat celou realitu a celé řešení spočítávat, ale mohu vybírat mezi těmito třemi variantami.

Přesně tak. A teď už jde o něco, co není úplně old school, ani úplně nové…

Pokud chceš, mohu text ještě více vyladit nebo rozšířit podle potřeby.

Pomíněnou oblastí se sice téměř nezabýváme, ale je také součástí umělé inteligence – jedná se o expertní systémy. Tam například fungují pravidla opravdu ve formě IF-ELSE, ale nejen to, existuje tam určitá, řekněme, inferenční strategie, díky níž je možné na základě vstupních dat odvodit novou znalost, která na začátku nebyla explicitně daná. To je opravdu stará škola umělé inteligence.

OGs, OGs – přesně tak, tady máme opravdové „OGs“ umělé inteligence, AI ještě dřív, než bylo cool. Než skočíme k otázce komercializace tvé kariéry, jak probíhalo setkání s Honzou Romportlem? Byla Plzeň tak malá, že jste o sobě věděli, a v jednom baru to bylo jednoduché? Pamatuješ si na nějaký moment, který by stálo za to za deset let natočit, nebo to bylo složitější?

Samozřejmě, Honza nezlinčoval, ale nebylo to v hospodě. Když jsem nastupoval na doktorandské studium, seděli jsme docela blízko sebe, takže o sobě rozhodně věděli, ale už samozřejmě v rámci studijních záměrů – už na bakaláři a potom na magisterském studiu. Viděl jsem, že tam Honza je, protože je to přeci jen výrazná osobnost. V té době měl ještě docela dlouhé vlasy, i když si to teď člověk možná nechce představit, ale své „kolečko“ pořád měl, jen s dlouhými vlasy – pro mě Honza. Pamatuji si, že kolovaly různé historky o Honzovi, a pak mi je sám pověděl a uvedl je na pravou míru, přičemž skutečnost byla ještě zajímavější než ty historky.

Ale vzpomínám si, že když jsem nastupoval na doktorandské studium, při otevření dveří – tedy když jsem něco říkal – přišel Honza, usmíval se a naznačil ticho tajemství s tím, že řekl: „Já jsem ještě opilý, budu rovnou do hospody.“ To bylo nezapomenutelné a ten moment se určitě zapsal. Zbytek už je historie. Ano, the rest is history.

Tak pojďme k další kapitole. Honza si totiž akademickou kariéru nevystačí a chce zkusit velký svět. Outučko je tehdy PPP vkou, že? Ano, už byla PPP vkou. Takže tam nastupuje. Respektive, když Honza nastupoval, ještě byla firma pod telefonikou, ale brzy se z ní stala PPP vka. Když jsem tam nastupoval já, už byla součástí PPP.

Když jsi nastoupil do Outučka, v jakém prostředí ses ocitl? V podstatě Honza vedl oddělení datové analýzy, které se tehdy nazývalo Big Data, protože BI jakožto analýza tam ještě byla oddělená. Byl to vlastně začleněný byznysový útvar přímo k Customer Value Managementu, protože výstupy z Big Data byly jedním z největších odběratelů. Cílem bylo dobře pracovat se zákazníkem – vědět, co zákazník chce, co nechce, ideálně mu volat jen když něco potřebuje, a ne obtěžovat ho zbytečně, aby se nepohoršil. Když to hodně zjednodušíme, nastoupil jsem do týmu, který tvořilo asi patnáct lidí, a který Honza vedl a měl nějakou datovou platformu.

Ještě on-premisovou náhodou původně založenou a já jsem vlastně dostal na starost se starat o tu platformu, vést ten tým, který má tu platformu pod sebou, a navíc supportovat ty týmy – řekněme takový platform team. Původně, když jsme se s Honzou bavili, tak ta idea byla spíš taková, že bych byl víc u toho data science týmu, ale nakonec se to prostě vykrystalizovalo takhle.

V Outuvu se vždycky, jak já, tak Honza, nebo obecně lidi v Outuvu, snažíme, aby tam nebyla silo struktura, aby tam nebyly škatulky, a je to hodně takový, řekněme, end-to-end. Já jsem se o to hodně snažil, aby ty týmy byly end-to-end – mají u sebe data engineera, všechny potřebné lidi a jsou schopné, ať už je to produkt nebo řešení nějakého problému, pracovat od začátku do konce, bez zbytečných třecích ploch, s menším počtem bariér. Tak nějak jsem došel do stavu, že na začátku jsem vedl data engineering tým, ale nakonec jsem zůstal primárně za platformu a za rozvoj AI technologií v Outuvu.

Než se podíváme na těch 4–5 let, ještě mě zajímá, jak moc jsi byl připravený a jak velký pro tebe byl šok přejít do komerce z akademie a výzkumu. Teď, když mluvíš o tom, že jsi měl na starosti platformu a hadůk, jak moc jsi měl zkušenosti s datovými technologiemi? Teď to zní jako velký software engineering, DevOps a všechny tyhle kategorie, které jsou, podle mého předpokladu, v akademii hodně odstíněné. Tam si vyšiváš na vlastním modelu, píšeš si nějaký paper, ale produkce a big data jsou úplně něco jiného – zákaznická data v Outuvu v roce 2015 už byla big data. Jak jsi vnímal tu cestu mezi akademií a praxí? Bylo to spíš „same shit, another scale“?

No, teoreticky. Když jsem říkal, že jsem měl nějakou krizi v tom, že akademie není úplně to pravé pro mě, tak to spíš bylo z toho důvodu, že já jsem hodně aplikační člověk. Mám rád, řekněme, praktickou stránku věci, a nejsem úplně typ na základní výzkum, který se zabývá jen teorií. Před lety jsem byl na přednášce Standy Fusta na ML Praha a teď nedávno tam měl druhou přednášku. Ten je přesně ten typ, který řeší multi-dimenzionální prostory a to, jak neuronové sítě transformují ty prostory a tak dále. Já to občas vnímám a chápu, ale říkám si – už na to asi nemám tolik titulů.

Spíš jsem opravdu takový ten typ, který velmi rychle dokáže proniknout do problému, najít to podstatné a aplikovat to do praxe. A samozřejmě, jak jsi přesně řekl, v akademii ty scale'y nejsou tak velké. Samozřejmě znám nějaký software a praktiky, přecházeli jsme ze SVN na Git a podobně, ale třeba CI – automatizované buildy sem tam byly, ale člověk to nemusel mít úplně v krvi, jako třeba já teď.

Tady je opravený text s úpravou pravopisných, gramatických a stylistických chyb:

Že rád automatizuje ty věci, tak si s tím člověk nějak hraje, ale řekněme, že to byl spíš teoretický přístup, teoretické znalosti. Pak ale člověk přišel do O2 a najednou ta srážka – tohle tady je něco jako Hadoop, tady zase něco jako Spark, a Spark jsem do té doby někde možná četl, ale nevěděl jsem přesně, co to vlastně znamená. Ale tady už prostě nebylo důležité se bát skočit do vody a zkusit si to, i kdybych se měl trochu „utopit“. Pamatuju si, když jsem byl první týden v O2, byl jsem na schůzce u jednoho ředitele za network. On tam mluvil o spoustě věcí, že můžeme používat třeba Parquet, nebo Avro, nebo jak to bude chtít, a tak dále. A já si v duchu říkal: „Ty vole, já vůbec nevím, o čem mluví.“ A říkal jsem si: „Ty vole, jsem už v prdeli.“ Hlavně se tvář, že tomu rozumíš. Často se mi stalo, že člověk takhle působí, že tomu rozumí, a pak udělá maximum proto, aby tomu už do druhého dne rozuměl. A v mnoha případech to bylo víc, než jak to dělají jiní lidé. Často se tedy tváříš, že rozumíš, a při tom nevíš vůbec nic. Takže pro mě byl největší rozdíl v tom, že to bylo mnohem víc stresující prostředí, mnohem větší tlak. Člověk si někdy říkal, že na univerzitě je tlak, ale tohle byl oproti akademickému prostředí minimum, minimální tlak. Takže asi největším rozdílem byl ten tlak.

Super. A jaké projekty jste řešili?

Hlavně CVM. Když to vezmeme rychle z gruntu – co na tom běželo, jaké metody jste používali, co bylo tehdy state of the art, jaké technologie? Asi jste nezůstali jen u Hadoopu a Sparku, že?

Když jsem nastoupil, začalo se řešit, že on-premisový systém dožil, protože všechno bylo koupené na pět let – ať už licence nebo hardware. Jednalo se o CAPEX náklady. Navíc v době, kdy jsem nastupoval, bylo v O2 takové vnímání cloudu, že je drahý a nebezpečný – když to přeženu. Bylo to dáno tím, že firma dostala nějaké kredity zdarma, ale neuměla s nimi dobře pracovat – rychle se spálily na Big Data projektech a všichni viděli účet, který přišel, a řekli: „Co je to za hrozně drahou věc?“

Nicméně se situace změnila, když mě Lukáš Vavrla, ředitel CVM, poprosil: „Myslíš, že bychom měli jít do cloudu?“ A já jsem řekl: „Rozhodně ano, dá nám to spoustu možností.“ Díky tomu začalo u spousty lidí ve firmě vnímání cloudu přecházet, a věci začaly rychle nabírat obrátky. Pomohlo i to, že jsme si nechali nacenit nové on-premisové řešení, které bylo dražší než cloudové řešení v pětiletém TCO. To tomu také pomohlo. Nakonec byl vybrán Azure Cloud.

A co se týče technologií, když budeme trochu pokračovat s platformou, ne s konkrétními projekty, …

Pokud chceš, můžu opravit i další část textu, kterou jsi měl v plánu pokračovat.

Jako machine learningových modelech, které se tam používaly, je to postavené zatím na třech základních komponentách, což jsou samozřejmě Data Lake, Azure Machine Learning a Azure Databricks. Kolem toho je samozřejmě ještě systém dalších nástrojů. Já osobně nejsem úplně fanoušek end-to-end řešení, i když jsou super a mají spoustu výhod, vždycky, když jsme nějaké end-to-end řešení používali, narazili jsme na jeho limity. Když jsme totiž potřebovali z nich trošku vybočit, bylo to velmi náročné.

Já jsem spíše zastáncem přístupu, jak já vždycky říkám: „Mám tady nějaké kostičky z LEGO, z kterých stavím řešení.“ Takové řešení je sice pro uživatele možná trochu komplexnější a vyžaduje větší znalosti, protože například Azure Machine Learning vypadá trochu jinak než Azure Databricks, ale plus minus to stále má nějaká tlačítka a vždycky nějaký uživatelský interface. Za chvíli to uživatelé umí. Je zde mnoho nástrojů, ať už je to Keboola nebo jiné, ale vždycky jsme došli k tomu, že nás něco začalo limitovat.

Když jste na úrovni pokročilých uživatelů, tak se limity vždycky objevily. A vy jste určitě byli pokročilí uživatelé. One size doesn't fit them all, a vaše potřeby byly vždycky trochu jiné. Řešení „vše v jednom“ jsou určitě skvělá, ale nám to ne vždy fungovalo optimálně. Takže takhle to je, co se týče nástrojů.

Když mluvíme o modelech, hodně záleží na use case. Například při spolupráci s bankami je to většinou lineární nebo logistická regrese. Česká národní banka musí být schopná přesně říct, na základě jakých vstupních dat k výsledku došla, takže musí být dokonale auditovatelné, což u neurálních sítí často není možné. I když u některých use case se i neurální sítě objevují.

Pak jsou to například random foresty, což je sada rozhodovacích stromů, které klasifikují data, a výsledná predikce se odvíjí od počtu těchto stromů. Dále support vector machines. Jeden z velkých use case u O2 jsou data ze sítě. Přitom O2 nevidí, kde přesně se daný člověk nachází – data jsou na úrovni větších ulic nebo částí města, případně v otevřené krajině v rámci větších čtvrtečních kilometrů, takže identita uživatele není známá.

Ale pokud se podíváme na velká čísla, dá se z nich vytvářet vektory pohybů. To umožňuje zajímavé business use case, například státní správa se může zajímat o počet lidí, kteří dojíždějí z Plzně do Prahy, a na základě toho rozhodovat, jestli nevybudovat více parkovišť u Zličína nebo Nových Butovic. Takové use case se dají řešit, přičemž na začátku byly využívány skryté Markovovy modely.

Dnes se tam hodně používají transformery, protože transformery jsou vlastně novou odpovědí na nevýhody rekurentních neuronových sítí…

Tady je opravený a upravený text:

Ale je to více méně něco jako, když to hodně zjednoduším, a možná komunita to chápe jako transformaci sekvence A na sekvenci B. Dá se to takhle použít, takže si můžeme představit, že nějaká sekvence informací z BTS se dá transformovat na sekvenci křižovatek na dálnici, sjezdů na dálnici nebo podobných věcí. Hodně to zjednodušuji, ale řekněme, že opravdu to byly skryté Markovovy modely, support vector machines.

Po nějaké době, řekněme kolem roku 2014 nebo 2015, reálně možná spíš kolem přelomu 2018, lehce před covidem, se tam začaly zase používat například neuronové sítě a podobné metody, protože to taky souviselo s tím, že na Harupu nebyly grafické karty a podobné věci, takže se těžko trénovaly neuronové sítě. Pamatuju si historku z doby, kdy jsem tam lehce po nástupu slyšel, jak Honza říkal, že potřebuje dvě grafické karty, a teď se pro Kudmene bude nakupovat. Po nějakých tahanicích a velkých diskuzích se nakonec zaplatila kreditka a karty se koupily v Alze. Bylo to prostě nejrychlejší řešení. Měly tam být dva výpočetní stroje se dvěma grafickými kartami, aby se s těmi neuronovými sítěmi mohlo začít hrát.

Když pak přišel cloud, bylo to samozřejmě jednodušší. Člověk si jednoduše nasadil virtuální stroj s grafickou kartou a mohl pokračovat. V té době se už také objevily první experimenty například s reinforcement learningem, kdy jsme si hráli s bandity. Z jednoho pohledu je to vlastně nejjednodušší reinforcement learning. Představte si tři výherní automaty – v Americe s páčkami – kterým my říkáme banditi. Zatáhnete za všechny tři páky a sledujete, jak vám padají výhry nebo prohry. Banditi na základě těchto pozorování začnou preferovat automat, kde máte největší pravděpodobnost výhry.

Často se to používá třeba v marketingu, respektive v cílení reklamy nebo nabídek. Všichni známe A/B testování, kdy uživatelům ukazujeme variantu A nebo B, případně více variant. Problém A/B testování je ten, že po celou dobu testu jsou varianty statické. Můžeme tak například ztrácet peníze na tom, že jedna z variant je výrazně horší než druhá, a přesto celý test běží. Banditi fungují tak, že uživatelům postupně ukazují všechny varianty, ale na základě průběžných výsledků upravují, jak často zobrazují jednotlivé varianty oproti té preferované.

Dále se můžeme bavit o tom, jak moc dovolíme během testu tzv. exploraci jiných variant. Tedy zda například během trvání testu nepřijdou změny v preferencích uživatelů, například kvůli svátkům, Vánocům nebo jiným událostem, a systém by měl být schopen na to reagovat. Takže to byl takový první reinforcement learning, se kterým si například O2 hrálo.

No a teď ještě jedna věc – ty jsi zmínil, že jste začali používat transformery. Transformery, jak je známe dnes z velkých jazykových modelů (LLM)…

Pokud chceš, můžu text přepsat víc formálně, zjednodušit, anebo rozdělit na ještě kratší úseky.

Jasně, tady je opravený text s lepší gramatikou, stylistikou a srozumitelností:

„Attention is all you need.“ A k tomu se chci nejdřív vrátit. Říkal jsi, že transformery jsou odpovědí na nedostatky rekurentních neuronových sítí. Můžeš to vysvětlit?

V podstatě to funguje tak, že rekurentní neuronová síť má v rámci své struktury neuron, který například spočítá sumu vstupů a vygeneruje výstup. K tomu je přidána aktivační funkce, ale to teď neřešme. U rekurentní sítě je výstup zpětně přiveden na vstup toho neuronu, což znamená, že tam existuje zpětná vazba.

To ale znamená, že nemohu snadno dělat maticové operace paralelně, protože potřebuji výstup z kroku jeden, abych spočítal krok dva. U dopředných (feedforward) neuronových sítí tato závislost není, ty fungují jednoduše. Moc to zjednodušuji, ale takhle to lze popsat.

Tahleta zpětná vazba nám dovoluje pamatovat si nebo vybrat z předchozích dat nějaké důležité informace. V případě jazyka to může být například podmět, přísudek a podobně—nějaké klíčové části věty.

Dopředná síť, což transformér vlastně je, tuto zpětnou vazbu nemá. Je to čistý průtok: něco dám na vstup a dostanu něco na výstup, a tím to končí. Pokud bych chtěl do dopředné sítě zohlednit nějaký stav nebo minulou informaci, musel bych ji přidávat jako vstupní data, tedy nějaký vnější stav reprezentující minulost.

A tak chytré hlavy v Googlu řekly: „Rekurentní sítě jsou sice ideální pro zpracování sekvencí, ale jak můžeme sekvence zpracovat dopřednou sítí?“ A právě transformér je v podstatě takový brute force přístup.

Proč řešíme kontextové okno? To je totiž velikost vstupu, který transforméru dáme.

U rekurentní sítě se pokazí tak, že posíláme postupně slova jedno po druhém a síť je zpracovává, protože to je sekvence. Transformér ale ukáže najednou celý odstavec. Prostě celou sekvenci najednou protáhne sítí, jako průtokáč.

Co je ale zajímavé, je mechanismus attention. Attention funguje tak, že z celého tohoto kontextu (který mu dáme) se naučí, co je v textu důležité. Na základě toho má vnitřní stav a ten posílá dál.

A teď—něco z té sítě vyleze a my to zas dáme na vstup…

Pokud chceš, mohu ti to ještě více upravit, aby to bylo plynulejší a více vysvětlující. Stačí říct.

Jasně, tady je opravený a trochu uhlazený text:

Le prostě ne, zpětná vazba, je to v podstatě takhle zpětná vazba, ale prostě vezmu vstup, dám ho do modelu a ty attentions zase zafungují. Znovu si najdou podobné věci a attentions v dřívějších vrstvách hledají jednodušší vazby, zatímco v hlubších vrstvách už třeba mohou opravdu hledat podmět, přísudek nebo jiné složitější vztahy. Je těžké teď přesně říct, co která vrstva v GPT reprezentuje, ale můžeme si to představit jako parafrázi s konvolučními neuronovými sítěmi, které jsou určené pro obrázky. Konvoluce jsou vlastně filtry, které v prvních vrstvách hledají hrany, ve vyšších vrstvách pak objekty jako trojúhelník, čtvereček apod., a v dalších vrstvách složitější věci jako například obličeje. Na základě toho pak dopředná síť rozhodne, jestli je na obrázku kočka, pes nebo něco jiného.

Transformer je v podstatě velmi sofistikovaná dopředná síť, která je naučená z trénovacích dat, že z kontextu, který jí dáme, dokáže odhadnout, které části jsou důležité – například že podmět nebo určitá část věty je důležitá, zatímco spojky nebo jiné části nejsou až tak podstatné, protože neovlivňují výstup. Toto řešení nahrazuje problém rekurentních neuronových sítí. Transformer je feedforward síť, velmi sofistikovaná, kterou lze efektivně paralelizovat – matice lze spočítat najednou na více vrstvách a podobně. Tedy transformer není omezen postupným zpracováním sekvence, ale vezme celou sekvenci najednou a „chytrý“ mechanismus self-attention si z toho vybere tu důležitou informaci.

Skvělé, a kdy jsi se s tímto setkal? Když jsem se bavil s AI odborníky, například v Outlooku, na nějakém projektu jste používali rekurentní neuronovou síť, předpokládám, a naráželi jste na její limity. Najednou přišel někdo a řekl: slyšeli jste o transformerech? Já si to představuju jako takový můj „aha“ moment, kdy jsem pochopil, že je tady nová technologie. Pro mě to bylo spojeno s Honzou, který toho hodně čte a nemá doma televizi – na rozdíl ode mě, já jsem spoustu času trávil u televize a pak u tabletu, ale on si spoustu věcí raději přečte. Já si pamatuju, když jsem neměl televizi ani tablet, tak jsem četl spoustu knih. Ten rok jsem přečetl přes 50 knih, pak jsem si koupil tablet a čtení šlo do kopru.

Honza se hodně zajímá o AI komunitu, GPT modely existují od roku 2017, GPT-3 vyšel v roce 2020. Pamatuju si, jak jsme jeli s Honzou autem, oba jsme bydleli tehdy v Plzni, a poslouchali jsme různé lekce, například Friedmanovy,…

Pokud chceš, mohu ještě text stylisticky lépe upravit, aby byl plynulejší a formálnější. Stačí říct.

Jistě, tady je opravený text:

„Šlo to zvládnout a nemělo to pět hodin, ty podcasty, takže to akorát tak vystačilo na cestu. A nezval jsi tam Putina?“
„Přesně, nezval jsem tam Putina a nebyli jich pět jednou, takže to prostě nešlo. Ale samozřejmě jsme řešili AI věci a tady ty… Tehdy přišel GPT-2, Honza říkal, že je zajímavé, že schopnost modelu být lepší je jen o tom, jak ho odškálujeme – prostě uděláš větší model, dáš mu víc GPU a je to. V té době jsem úplně nechápal, co tím myslí. Říkal jsem si: ‚Když udělají novou verzi, musí přece úplně předělat architekturu nebo ji nějak vylepšit, aby to bylo lepší.‘ Pak jsem samozřejmě zjistil, co je Transformer, a pochopil jsem to. Transformer je totiž taková feedforward verze, kde attention mechanismy v dalších vrstvách dokáží hledat víc a víc komplexních souvislostí. Takže je to hlavně o škálování. Pak ale narazíš na problém, že už nemáš dost dat na další škálování, ale to je jiný příběh.“

„Pro mě to bylo poprvé tak kolem roku 2019–2020, kdy jsem začal vnímat, že je tady něco jako Transformer a začaly vycházet články, že Transformer všechno změní a tak dále. Takže to bylo asi takhle. Většinou je spousta impulzů o tom, že Honza něco řekne a že se něco zajímavého děje, čemu by se mělo věnovat pozornost. Za rok, dva pak ta věc doroste.“
„Přesně tak. Já mám tu výhodu, že to většinou vím třeba rok a půl dopředu, ale často je to právě Honza, kdo mi to řekne. Někdy si to nechám pro sebe, ale většinou ano.“

„A přímo v Outučku jste implementovali nějaké Transformery?“
„Řekněme, že v posledních dvou letech se v Outučku začal implementovat Transformer, například velmi sparse transformer – což znamená, že pracujeme s velmi řídkými daty v nějaké souřadnicové nebo jiné sekvenci, která je mnohem užší. Třeba, jak jsem říkal, sekvence křižovatek ve městě – představ si dvě pozorování: jedno je tady na Václaváku a druhé na Jipáku, teď chceš odhadnout trasu, kudy jsi jel. Funguje to primárně na velkých datech, ne na jednotlivých případech, a k tomu se Transformer dá použít – dáš mu sekvenci a on z toho generuje jinou sekvenci. Takže k tomu se Transformers využívají.“

„Je ještě něco, co chceš zmínit v souvislosti s Outučkem, co tam vzniklo a co se dělo? Podívali jsme se na architekturu, mluvil jsi o modelech, dotkli jsme se use caseů, nebo můžeme skočit do vaší startupové story, jak ta vznikla?“
„Určitě, je tam spousta věcí, co bychom mohli ještě ke Outu říct, ale možná to nechejme na později – třeba co znamenal příchod LLM pro Outu, na to si také něco pamatuju. Možná ještě jedna zastávka – co pro vás znamenal vznik Data…“

Pokud chceš, mohu text ještě více upravit podle stylu (např. formálnější, neformálnější) nebo vysvětlit odborné termíny.

Jasné? To je taky zajímavé, protože já mám předpoklad, že jste byli vysoce specializovaný, jako expertní tým, který byl určený na operátora a na jednotlivé use case. Potom vás najednou někdo vezme a řekne: „Hele, tohle knowledge je na jednu stranu drahé, ale na druhou stranu velmi hodnotné, že ji můžeme využít nejen pro ostatní firmy ve skupině, ale i pro jiné komerční klienty.“ Tak se tady podařilo postavit takové centrum excelence.

Znamenalo to něco i z pohledu technologií? Museli jste najednou používat jiný technologický stack nebo přístup, nebo to byla univerzální cutting-edge data science a jen jste si vybírali, na jaké projekty to dává smysl aplikovat? V tom hraje velkou roli Honza. Možná je to hodně o Honzovi, ale pravda je, že to je tak, a potom ještě o Indri Fremute jako CEO.

Když řekneme, že Honza měl tendence odejít z O2, PPFka/O2 se ho zeptala: „Hele, co by tě tady udrželo?“ A jedna z jeho odpovědí byla: „Chtěl bych dělat medical AI,“ protože ne jen Honza, ale i další měli možná nějaký altruistický přístup – chtěli pomáhat lidstvu, nebylo to jen o penězích. Tak řekl: „Chci dělat medical AI.“ A když parafrázuji Honzu, říkám: „Myslel jsem, že to je podmínka, kterou prostě nikdy nikdo nepřijme.“ A oni ji přijali, protože PPFka měla nebo má stále Sotio, které pracuje na léčbě především rakoviny. Tak se to tam naplánovalo a PPFka/O2 řekla: „Tak jo.“ A tak tomu dali i značku.

Protože jak se dobře říká – data scientisti jsou drahé lidi, často dražší než srovnatelní vývojáři. Musí se zaplatit, takže musíte dokázat, že na to máte, že si vyděláte na provoz a až potom vám dovolí dělat vaše srdcové projekty. To znamenalo začít pracovat víc napříč skupinou, zejména s Telenorama, s dalšími mobilními operátory, kteří byli součástí PPFky. A úplně to neznamenalo přejít na nový technologický stack, ale samozřejmě každý operátor měl trochu jiný stack, takže bylo potřeba se přizpůsobit.

Do toho jsme šli na začátku možná trošku naivně, ale s tím, že metody jsou aplikovatelné kdekoliv, což je pravda, ale tehdy druhá strana nebyla úplně připravená, takže byl odpor. Můžu si představit, že přijde někdo z Prahy a říká: „Tady to děláme jinak.“ Největší, v uvozovkách, „počítači“ byli v Maďarsku, protože tam je obecně větší skepsi, a potom v Srbsku, protože jsou tam velmi nacionalističtí a nikdo nechce slyšet, jak to mají dělat ostatní.

A přitom ta idea byla opravdu taková: „Hele, tady je vidět, že to funguje, Out je klenot v koruně PPFky, vydělává spoustu peněz, tak pojďme to prostě přepoužít.“ Takže s tím se šlo dál. Některé případy šly líp, některé hůř…

Jistě, tady je opravená verze textu:

O něco hůř se to podařilo, ale potom nástup LLM to kompletně změnil. Tady toho a z toho, z toho, jako, hele, pojďme dělat něco vlastní, se začalo prioritizovat, pojďme dělat use casey uvnitř. Když řeknu, že ty vnější use casey pro PNLku DataClear byly v řádu desítek milionů, tak use casey pro Outu jsou pak řádově jinde, zvlášť teď s LLMkami.

Takže vznik DataClear, jak říkám, je to Honzovo dítě, na začátku společně s Jindrou. Znamenalo to hodně, zejména co se týče nabytí lidí, ale z pohledu platformy to v podstatě neznamenalo žádnou změnu.

I přes PPFC, i když jsem tady měl Honzu, tak klobouk dolů před tím přístupem – tvrdí, že je spravedlivý a vidí hodnotu. A když to funguje, tak to podpoříme. To se mi líbí.

Když jste měli takovéhle podmínky, tak kde začíná vznikat Alien AI a startupy? Jak moc jste chtěl být startupistou?

Moc ne, na jednu stranu kvůli nejistotě a riziku. Nejsem nejmladší, mám hypotéku a tak dále. Účty chodí. Na druhou stranu si pamatuju, že to bylo lehce po první vlně covidu, řekněme jaro 2020, kdy se začalo rozvolňovat. Seděli jsme s Honzou kousek od České televize, v nějakém parku, nejsem úplně pražský, tak si teď nevzpomenu na jeho jméno. Povídali jsme si o budoucnosti a já říkám Honzovi: Víš, co je nejhorší? DataClear je v podstatě tvoje dítě, ale není tvoje, je Pepévky. A čest tomu, že Pepévka to podporuje dál, ale je to takový pocit – není to tvoje.

Shodou okolností v té době Honza s Jirkou Horáčkem, panem profesorem, začali mluvit o tom, že svět směřuje někam, kam se nám nelíbí. Když přišel covid, chytil nás – všichni jsme zůstali doma a náš primární kontakt s vnějším světem začal být přes obrazovku, online. Najednou začalo být jasné, že jsme velmi zranitelní, velmi ovlivnitelní dezinformacemi, fake news a dalšími věcmi. A bohužel i po odchodu covidu se tohle nezměnilo, covid to jen akceleroval.

Jirka Horáček to krásně popisuje, co se v tom mozku děje a co to člověku způsobuje. Honza začal přemýšlet, že by se s tím dalo něco dělat. Neříkám, že už tehdy byly na světě LLM, ale začal uvažovat, jak by od fashion AI, jak jsou sofistikované neuronové sítě, šlo něco vytvořit.

Tak se to začalo uvažovat a slovo dalo slovo. Honza zná spoustu lidí, dokázal sehnat i nějaký počáteční funding, řekněme skromný, ale zajímavý na to, aby se začalo zkoumat, jestli se s tím něco dá dělat. A do toho přišla LLM.

Ty to celé postavily na hlavu – zjednodušily na jedné straně, na druhé straně zase zkomplikovaly, ale o tom ještě budeme mluvit. Řekněme, že to bylo kolem roku 2022, kdy to opravdu začalo.

Pokud chcete, můžu text formátovat i pro jiný styl, nebo zkrátit.

Opravený text:

U všechno se to nějak sešlo. Já jsem se zase dostal, ne že do krize, ale spíš jsem dokončil výběr té platformy a začal jsem si klást otázku, co bude ta „next big thing“. Protože jsem sice v podstatě líný člověk, ale když už pracuji, mám radši takový trošku tlak, že se nedodělám. Nejhorší je, když přijdeš do práce a nechce se ti dělat. Já si říkám: „Co budu dneska tvořit?“ Mám velkou tendenci prokrastinovat, a pak zjistíš, že odpoledne jsi skoro nic neudělal a máš z toho špatnou náladu. Radši mám, když je trochu permanentní tlak a něco se děje.

V té době jsem si říkal, že třeba rok budu provozovat tu platformu, o kterou se stará tým, nepředřu se a nikdo mi ani nic neřekne, protože výsledky budou. Furt to jede, je to dost tlačené. Ale já se budu nudit. Tak co s tím? A nebylo nic, co bych měl na radaru, co by se dalo řešit. Tak jsem to nějak odbavil s Honzou. Pak přišla LMK a já ještě než jsem odešel, měl jsem víc práce než kdy předtím. Ale už jsem se rozhodl – chtěl jsem zkusit něco budovat, něco částečně vlastního, zkusit, jestli v tom obstojím nebo jestli to „schodím jak papír“.

Vlastně mám pořád pocit, že trochu „vlajuju jako ADR na holi“, ale dávám do toho maximum, co umím. Ty jsi říkal, že do toho vlítnuli LNK, že to bylo jako dvousečné. Ta jedna strana je ta, že jste nemuseli stavět velký monolitický stroj, obrovskou neuronku, která chápe celý svět a dělá všechno, co potřebujete. Najednou jste tam dali API a nějakou část toho odbavili, což je podle mě ta dobrá věc.

Co byla ta špatná věc? Ze špatných věcí je obecně nevýhoda LNK v tom, že modely jsou obrovské a schopnost je udělat mají jen velmi malé týmy na celém světě. To znamená, že nemáš úplnou kontrolu nad tím, jak byl model vytvořený, a ani když chceš model trochu přizpůsobit, nemáš moc možností. LNK jsou sice mocné, ale často nestačí.

Třeba zkuste se zeptat GPTčka: „Mám chuť zabít.“ To je věc, kterou LNK řeší. GPT vám řekne: „To mě mrzí, nerad to slyším,“ a rychle změní téma, snaží se vás odvrátit. My naopak potřebujeme být pro toho člověka dostupní, umět se s ním o tom bavit a řešit ten problém. Často je totiž řešení už o tom, že někdo je, poslouchá a je přítomný. A zvlášť mladší uživatelé mají problém se svěřovat živému člověku.

A ještě na závěr, LN AI rozhodně není tady od toho, aby nahrazovala rodiče, ne.

Ní tady není proto, aby nahrazovala psychiatry, psychology a terapii obecně. Ale je tady obrovský prostor a já sám mám zkušenost, kdy se mi z nějakých důvodů úplně z dne na den otočil svět vzhůru nohama a potřeboval jsem si to nějak vstřebat, popovídat si o tom s někým. Můj největší problém byl, že mi bylo nejhůř mezi těmi terapiemi. Měl jsem sezení třeba jednou za měsíc nebo jednou za čtrnáct dní a právě mezi nimi mi bylo nejhůř. Potřeboval jsem s někým pokecat nebo to nějak ze sebe dostat. Psycholožka mi řekla, abych si to psal na papír a pak jí to řekl. Když jsem pak na terapii přišel, už mi bylo v pohodě, nějak jsem si s tím sám poradil. A přesně v těch situacích je tu Elin. Protože někdo nemusí být vždycky dostupný nebo nechceš se svědčit. Mladé holky si nejvíc svěřují své kámošce, ale ta většinou vůbec neporadí, jenom následují nějaké rady. Takže Elin řeší právě tyto problémy a je potřeba, aby tam někdo byl a aby modely nevyhýbaly těm důležitým otázkám.

Takže ten problém s Elinkem je v tom, že to je velmi těžké ovládnout. Když jsme s tím začínali, říkali jsme si, že to půjdeme vyřešit. Zaměřili jsme se na psychické problémy uživatelů. Trošku jsme do toho zabrousili a říkali si: „Jseš smutný, jseš veselý.“ Ale pak jsme zjistili, že to je obrovské a velmi široké téma. Takže jsme museli z toho něco vybrat. Vybrali jsme třeba poruchy příjmu potravy (eating disorders) a v tom jsme se zase trochu ztratili, protože to téma je ještě větší a komplikovanější.

Velkou výhodou LLM (large language model) je, že s ním můžeš extrémně rychle prototypovat. Kdykoliv někdo staví produkt, který pracuje s textovou interakcí, je dobré na začátku použít LLM, protože je to velmi rychlý prototypovací nástroj, který nemusíš trénovat. Dřívější postupy v AI byly o tom, že jsi sbíral data, vybíral model, zjednodušoval, trénoval neuronovou síť, což trvalo minuty, hodiny nebo dny, a nakonec jsi měl něco, co buď fungovalo, nebo nefungovalo — přičemž to vyžadovalo velké zdroje a čas. Navíc jsi potřeboval data, která jsi buď musel získat nebo koupit, případně si je sám vymýšlet.

LLM je výborný v tom, že díky mechanismu attention model ví, co po něm chceš. Můžeš mu říct: „Buď tady expert na matematiku nebo na vývoj softwaru, dělej toto a toto,“ pak mu předáš data a on to zpracuje. A trvá to minuty, případně hodiny.

Jistě, tady je opravený text:

Jako hraní si s promptem a dostáváš nějaký výsledek, jo. Takže takhle velmi rychle můžeš iterovat, zároveň je to přístupné i lidem, kteří nevědí, co to je trénovat model, co to je získat data nebo anotovat data. Ono je jedna věc mít data, ale potom je je třeba ještě anotovat, což je druhá disciplína. S tím, že tady to, co já říkám, toho LLMka je taky, ale prostě to dělá úplně někdo jiný – to dělá Anthropic, to dělá Google, to dělá Meta s Lamou, Gwen tamhle, DeepSeek – tyhle týmy, které to dělají, tak ty tady používají klasické AI v trénování toho LLMka.

Co je LLMko? LLMko je jazykový model. Pro ty, co nevědí, co je jazykový model, tak si představte, že na vstupu dám třeba „Emma Mele“ a na výstupu s největší pravděpodobností ten model řekne „maso“, ne „máma“. Když to stáhnu zpátky k O2 Česká republika, tak na výstupu může být „mobilní operátor“, „poskytovatel internetu“. Tohle dělá LLMko. Jo, to je jazykový model a tohle umí LLMko – nic jiného nedělá. Ještě to hodně zjednoduším.

Model je ale tak obrovský, že výstup se ovlivňuje tím, co mu řeknu na začátku – „chovej se takhle“, a tak se aktivují jiné části sítě než třeba u experta na software engineering, který viděl tisíce kódů na GitHubu. Takže tohle nám s LLM hodně pomáhá.

Na začátku jsme díky tomu mohli velmi rychle prototypovat, řekli jsme si: Hele, tady je nějaká oblast, kterou řešíme, co na ní může fungovat. Jirka Horáček přišel s tím, že když člověk leží na křesílku – sedí nebo leží – tak s tím bude pracovat tak, že mu bude klást otázky, protože cílem terapie je takový a makový.

Teď si můžeme udělat buď falešný scénář, nebo začít testovat s uživateli. Řekneme si: OK, když řeší tenhle problém, tak ho vedeme tudy, a tady je zatím v první etapě naprontovaný LLM, který funguje, nebo nefunguje. Když funguje – ano – tak tady jsou tyhle a tyhle problémy.

V daný moment začínáme dělat mnohem komplexnější systém, kde už LLMko nehraje jedinou roli, ale začínáme to dostávat do stavu, že tam jsou i naše vlastní modely a LLMko velké je už jen jako arbitr – třeba jestli jít možností A nebo možností B a podobně. Tohle nám hodně pomohlo.

Kdybychom neměli LLMko a měli jen počáteční funding, tak bychom ho propálili jen na to zjistit, jak do toho zkoušet; nic bychom nevyzkoušeli, protože bychom pořád něco trénovali, zkoušeli a neměli data. Takto jsme schopní velmi rychle začít i když nedokonale reagovat na situace. A pak už to funguje v Elinu, jo.

Ne, počkej, já jen možná předpokládám, že všichni Elin znají – co je teď Elin jako produkt…

Pokud chceš, můžu text ještě uhladit nebo změnit styl.

Co vlastně děláte? Ten osobní robotický terapeut pro mladé?

My se tomu trochu vyhýbáme jako terapeutickému přístupu, ale řekněme, my tomu říkáme „buddy“ – kamarád. Prostě tomu říkáme „buddy“, se kterým můžeš řešit cokoli chceš, například domácí úkoly nebo něco jiného. Síla toho LLM (velkého jazykového modelu) je v tom, že s tebou dokáže cokoli řešit. Ale v momentě, kdy s Elin začneš řešit nějaké, řekněme, bolestivé téma, aktivují se části, které jsou specializované na řešení takových témat.

Mezi taková témata mohou patřit – nebo nemusejí –, například porucha příjmu potravy, osamělost, šikana, FOMO a podobné věci. Postupně tam přidáváme stále více těchto scénářů, protože je otevřeně těch problémů tolik, že i když je LLM mocný, není jednoduché udělat jeden model na všechno. Tady se vracím k tomu, co jsem říkal na začátku – nemyslím si, že jeden model end-to-end je nejlepší na všechny možné scénáře.

Proto se snažíme z dostupných LLM, ať už proprietárních, uzavřených, nebo i otevřených, vybírat ty, které jsou na daný problém nejlepší. Používáme různé sofistikované strategie, protože můžeme mluvit o tom, co nám umožňují změny v promptování (nastavení dotazů). K tomu se dostaneme později.

Teď jsem chtěl shrnout, co je Alien AI jako produkt. Je to „buddy“, který v sobě integruje know-how profesora Horáčka – psychoterapeutické a duševní zdraví a celou tuto práci. Cílovou skupinou jsou primárně mladí lidé. Ano, v tuto chvíli cílovka primárně sílí na Generaci Z, ale to neznamená, že to nemůže používat kdokoliv jiný.

Spíš jde o to, že se komunikace trochu liší – trošku jinak se komunikuje s Gen Z, jinak s Boomery a jinak s Millenialy. A protože nemáme neomezený rozpočet, museli jsme si vybrat – cílíme na Gen Z, ale používat to může kdokoliv.

Super, a k čemu se chci dostat, je k začátku. Řekl jsi, že vám na účet přistály peníze a máte nějakou finanční rezervu (runway). Říkal jsi, že super, že přišly LLM, díky kterým jste mohli postavit prototyp, získávat zpětnou vazbu a zjistit, jestli to dává smysl, že už jste měli produkt, který vás dostal možná k modelu, i když produkt samotný by byl těžší.

Co konkrétně bylo to MVP (minimálně životaschopný produkt)?

Na začátku to bylo trochu jiné. LLM nám sice umožnilo rychle začít prototypovat, ale stejně nám trvalo zhruba rok, než jsme se dostali k něčemu, co nějak fungovalo a dávalo smysl.

Mimochodem, dlouho jsme se rozhodovali, zda použít chatbotový interface nebo ne, protože nechceme být jen dalším chatbotem, protože uvnitř to není chatbot. Ale po několika iteracích jsme dospěli k tomu, že chatbotový interface je pro uživatele nejpřirozenější a když bychom je učili něco jiného, tak na tom ztroskotáme.

To znamená, že když aplikaci otevřeš, tak je tam chat – to je přirozený interface, ale není to čistý chatbot…

Jistě, tady je opravený text s lepší srozumitelností a jazykovou úpravou:

No a na začátku, řekněme po tom roce, to byla webová aplikace, která se přes PWA (Progressive Web App) dala nainstalovat do zařízení, protože jsme nechtěli řešit zvlášť iOS a Android, tedy dvojí vývoj. Přesně tak. Aplikace měla předdefinované scénáře. Například byl scénář, který jsme nazvali Číra – ten měl za cíl trochu uživatele rozveselit. Prostě jsi přišel, a nebylo to tak, že bys mohl cokoli napsat. Eli na základě toho, co o tobě věděla – protože jádrem funkce Eli je to, že permanentně sbírá informace o tom, jak s ní interaguješ; neupravujeme model, ale získává informace – na základě toho určuje, jak s tebou komunikovat.

Příklad je takový, že někomu pomůže polopaticky vysvětlit, že má něco udělat, někdo naopak potřebuje méně detailů a raději říct naprostý základ, a jiný chce problém opravdu rozebrat do detailu. A s tímto Eli pracuje – snaží se přizpůsobit danému uživateli. Tohle už nějak uměla, ale fungovalo to tak, že Číra najednou vygenerovala nějaké možnosti, řekl jsi třeba: „Chci vtip“ nebo „Chci něco milého“, a pak jsi si vybral jednu z možností, ona něco vygenerovala a ty jsi s tím dále nějak interagoval.

Začaly chodit první zpětné vazby: „To je super, ale chtěli bychom se o tom bavit víc do detailu,“ nebo „Mám deprese, potřebuju něco víc podpůrného.“ Pak tam byly předpřipravené scénáře, například: „Mám úkol z matematiky, pomůžeš mi ho vyřešit?“ V té době ale aplikace neměla žádnou paměť, nepamatovala si, co bylo vygenerováno předtím.

Byl to vlastně první základ, ani ne tak MVP, spíš kostra aplikace. Pak se začalo nabalovat další vývoj, a přišlo DMAčko, a Apple oznámil, že omezí PWA aplikace na iOS. My jsme to vlastně vydali, a za měsíc jsem četl zprávu, že Apple skutečně PWA na iOS omezí. Byl jsem docela překvapený, bylo to vlastně startupové „vítání“ do reality.

Startup life, chceš startup, tak ho taky musíš mít – se vším všudy. Tehdy už ve mně krystalizovalo, že té aplikaci se nevyhneme, že budeme muset jít dál. Naštěstí jsme měli slušnou runway a šli jsme velmi efektivně s nízkými náklady. Oproti platům ve velkých firmách jsme šli výrazně níž – to prostě patří ke startup life. Chceš něco budovat, musíš tomu něco obětovat. Super zkušenost.

A teď, když se podíváme na LLM a co to znamená provozovat v produkci, chtěl bych si teď nechat představit, co dnes vlastně LNAI znamená. Když nás provedeš architekturou, všemi těmi krabičkami – říkal jsi, že někde máme LLM, jinde je LLM jen jako „judge“ (rozhodčí), je to víc scénářové, případně tam vstupují naše vlastní modely. Můžeš mě tedy provést tím, když se podívám do vašeho Gitu, co to tam je?

Pokud chceš, můžu i text upravit ještě víc, aby byl plynulejší nebo formálnější. Stačí říct.

Tady je opravený text:

Tam to najdu? Hele, náš Git teď neřeším, to znamená, když půjdeš do našeho Gitu, tak backend je FastAPI aplikace, protože prostě já umím Python, věnuji mu už jako bambilion let a více méně to pořád držím. I když má svoje specifika, velmi rychle se v něm dá vyvíjet a v tom AI světě furt hraje prim, ať si kdo chce říká, co chce. To znamená, že je to FastAPI server, kam pošleš request, vlastně napíšeš něco v aplikaci, to přijde na ten server a ten to předá background workeru, který to přijme. Je to oddělené od toho serveru a tam se děje ta magie.

Tam jsou připravené grafy – vlastně jsou nadefinované grafy, přičemž spousta use caseů není tolik agentních, ale je to nějak rozdělené. Hezký článek je od Anthropiku o tom, co to vlastně workflow je. Workflow znamená, že přijde tvoje zpráva, vytáhne se historie chatu z databáze a je tam něco, čemu říkáme router. Ten router se podívá, o čem zpráva je, jaká je historie, jestli chceš třeba vyřešit domácí úkol, nebo jestli je to něco vážnějšího, a podle toho se zvolí řešení, tedy flow nebo pipeline – ta sekvence kroků, které vygenerují odpověď.

Nejjednodušší (říkejme mu „generik“) třeba vytáhne nějaké „memories“, nějak sofistikovaně dodatečné informace. Pokud třeba Elin už umí dohledávat informace online, tak jestli jsou potřeba další informace ze světa – pokud se třeba ptáš „Hele, dneska Trump zase nahodil nějaká cla nebo si to rozmyslel?“, tak Elin to nemusí vědět, proto si to dotáhne. Pak to předá LLM. V tomto případě, nebudu lhát, to prostě nejdřív posíláme na GPT Cloud nebo Gemini, protože je to nejjednodušší. Odpověď se generuje streamovaně a server posílá události (server-sent events) do aplikace.

Hodně teď koketuju s myšlenkou, jestli tam nedáme WebSockety, aby aplikace mohla mít interaktivní, obousměrnou komunikaci, protože by to vyřešilo spoustu problémů. Při generování se také bere v potaz, jestli třeba hodnotíš zprávy – to se taky zohledňuje. To je taková nejrychlejší smyčka učení: do promptu se vloží poznámka typu „uživateli se ta zpráva v historii nelíbila“, pak se to vezme a inkorporuje do vlastních modelů a tak dále.

Když je to něco vážnějšího, je to už trochu složitější. Hodně záleží na složitosti daného flow, ale i to nejjednodušší může fungovat tak, že pravidlově nebo jiným mechanismem se přidají nějaká metadata – například se podívá do historie, jestli se podobný topic už s uživatelem neřešil, aby se na něj mohlo odkazovat. To je sice ta „memory“, ale pracuje se s tím trochu jinak. Případně se syntetizují dodatečné instrukce podle toho, jak je to na…

Pokud chceš, můžu pomoct s pokračováním nebo jinými úpravami.

Jistě, tady je opravený text s lepší srozumitelností a gramatikou:

Učil jsem se od Jirky, že tam prostě není jen jeden prompt. Nesoustředíme se na jeden master prompt, ale je to sekvence zpráv. Můžeme tak generovat dodatečné informace, které v daný moment nemáme, nebo které nejsou uložené někde v databázi. Jedná se o syntézu několika zdrojů – například z databáze, z historie, z paměti (memories) a také od dalších uživatelů. To pak může být zpracováno buď na open source modelu, nebo na velkém LLM, podle toho, který více performuje. Ten vygeneruje odpověď, která následně jde ke kritikovi.

Můžeme také vygenerovat více variant a kritik se na ně podívá podle nějakého zadání. To zadání může být třeba „hele, prostě…“, protože například se nám stalo, že nám uživatel napsal s konkrétním problémem. Mluvím o tom se souhlasem daného uživatele, protože je součástí skupiny, která pomáhá vyvíjet Elyn, a máme tedy svolení zpracovávat jeho data.

Takže například jedna holčina napsala, že zhubla 25 kilo a má pocit, že má problém. Elyn jí odpověděla, že to je super, že zhubla, a že by měla být ráda. Kritiku pak sleduje, jestli odpověď není nějak mimo. Kritik může být velký LLM nebo menší model, ale doladěný (fine-tuned) speciálně na daný use case. Ten odpověď ohodnotí a pokud je špatná, tak ji přegeneruje.

Vždycky ale hraje roli latence, zejména při práci s LLM. Pokud jsi v use case, kde potřebuješ odpověď rychle, tak si nemůžeš dovolit složité přegenerování. V tom případě je potřeba se s tím vypořádat jinak.

My přistupujeme k tomu tak, že když řešíme nějaký obecný (generický) use case, například generování domácího úkolu, tak latence je důležitější než absolutní kvalita odpovědi. Odpověď chceme co nejrychlejší, takže tam není celý ten složitý flow. Naopak u kritických situací, jako je Sirius (kritické případy), latence není to nejdůležitější. Raději počkat pět sekund, než abychom dali nepřesnou odpověď.

Zpočátku, než jsme měli systém tak sofistikovaný (a možná ho ještě časem vylepšíme), byla latence mnohem nižší, odpovědi se generovaly rychleji, ale uživatelé nám dávali zpětnou vazbu, že by ocenili, kdyby systém trošku víc „přemýšlel“ nebo se věnoval problematice více do hloubky. Například když někdo napíše něco vážného jako „chci se zabít“, nechceme reakci hned ve vteřině. Potřebujeme chvíli uvažovat, jak na to reagovat.

Takže jsme dostali připomínky, že sice odpověď byla rychlá, ale chtěli by více promyšlenou odpověď. Reálně jsme uvažovali o tom, že bychom tam dali „spávač“ (sleeper), tedy nějaké zpoždění, aby se stihla přehrát hlubší logika. Kritik pak opravdu hodnotí odpověď podle těchto kritérií.

Pokud chceš, můžu ti text ještě víc zpřehlednit nebo rozdělit do odstavců.

Jistě, tady je opravený text s lepší gramatikou, interpunkcí a stylistikou, aby byl plynulejší a srozumitelnější:

Už byl LLM, může být pravidlově, tam opravdu záleží. My na začátku, když s tím experimentujeme, vždycky začneme s LLM, napromptovaným velkým modelem, a koukáme, jak funguje. A pak, když si z toho vyprofilujeme nějaké scénáře, začneme aplikovat pravidla. Když už tam je něco očividného, tak zase, abychom šetřili výpočetní sílu LLM, můžeme to třeba ohodnotit buď embeddingy nebo něčím podobným. Případně se opravdu fyzicky podíváme, jestli tam nejsou nějaké vzory v tom textu, a takovéhle pravidla pak můžeme buď zaříznout, nebo říct, že je to OK, a LLM použít třeba až nakonec.

Zatím nepracujeme agentním přístupem, kdy by se to točilo, protože latence je pořád relativně vysoká. Už ale experimentujeme s agentním přístupem. Když si to shrnu, řekl jsem několik věcí. První, půjdu odspodu – ty a Honza jste experti na machine learning a dost svých modelů jste si natrénovali. Máte tam nějaké vlastní neuronové sítě, nebo je to orchestrace LLM? Je v tomto use caseu prostor pro tzv. tradiční machine learning?

Ano, je, zejména pak v analýze. V současné chvíli naše vlastní neuronová síť v generování nefiguruje. Nemyslím tím něco, kde bychom si sami navrhli architekturu – počet vrstev a podobně – ale například dofine-tunovaný vlastní model je něco jiného. Nicméně samotné generování teď probíhá bez naší vlastní neuronové sítě.

Ale Expost ano, protože si pak musíš dělat analytiku – chceš vědět, co se v těch chatech děje. Nejdeme sice tak do hloubky, jako když řešíme bezpečnost dat, ale když pomenu věci otevřeně, data jsou kompletně anonymizovaná. Když se pak něco děje, potřebujeme vědět, co se v těch chatech vlastně děje. Denně proběhne XY chatů, stovky tisíc, a my potřebujeme vybrat ty, které vyžadují nějaký feedback – od terapeutů, psychologů, od Jirky, případně spolupracujeme i s dalšími lidmi. Potřebujeme říct: konkrétní člověk kouká na anonymizovaný chat, kde není Petr Stanislav, ale je tam problém – jsou tam odpovědi Elin – a říct: tady zareagoval Elin dobře, tady špatně, a tady…

Při stovkách tisíc chatů denně to musíme zautomatizovat. Je to vždy otázka poměru cena/výkon – na něco používáme napromptované LLM a na klasifikaci a podobné věci zase NAROK.

A teď k druhé fázi: říkáš, že to fine-tunujete. Častou debatou je, že fine-tuning dává smysl, protože se ti změní generativní model a pak to můžeš dělat znovu. Co pro vás znamená fine-tuning? Co znamená, že jste fine-tunovali? Jde o úroveň promptu, embeddingu, nebo je to mnohem hlubší proces?

Je to všechno dohromady, jako vždycky, když… (text zde končí)

Pokud si přeješ, můžu pomoci i s pokračováním nebo další úpravou.

Jasně, tady je upravená verze tvého textu, aby byl srozumitelnější a plynulejší:

Fine-tuning beru až jako poslední možnost – ve chvíli, kdy už s tím opravdu nejde nic jiného udělat, tak je dobré šáhnout do modelu. Za mě se to vyplatí hlavně u open source modelů, zejména těch menších, protože takový malý model je levný na provozování a zároveň ho můžeš přizpůsobit svému konkrétnímu use case.

Můžu dát příklad z našeho stacku – používáme open source model LLaMA (předpokládám, že víš, o co jde), který je vlastně finetunovaný. V podstatě je to LLaMA a pak i GPT-4, která je taky zajímavá. Upřímně říkáme, že je to spíš experimentální setup. Mluvím o tematice konverzace, kde byly data anotované uživateli – jak by měl model reagovat v určitých situacích. Potom předkládáme modelu chat, říkáme mu „měla by reagovat takto“ a tím si pomáháme ověřit, jestli menší model v daném use case může nahradit větší model.

Je to výhodné i proto, že GPT-4 často vyhýbá citlivým nebo „pain topicům“. V takových případech už klasické prompty moc nepomohou. Musíš začít řešit: „Co s tím?“ A tak místo toho, abys posílal požadavky do GPT-4 na Cloudu, můžeš je nasměrovat na menší model, který se specializuje jen na tuto úzkou oblast a dokáže uživateli pomoci lépe.

V současnosti experimentujeme v testovacím prostředí, zkoušíme to třeba i s psychology, a když to bude dobře fungovat, plánujeme to v dohledné době nasadit do produkce.

Ve skutečnosti jde u fine-tuningu o dolaďování attentions na velmi konkrétní a úzce vymezené úkoly. Je to takové „dotrénování“, které probíhá na hotovém modelu, není to však pre-training, což je dlouhý a extrémně finančně náročný proces. Tuto fázi pre-trainingu už dělají velké týmy, například v Seznamu pod vedením pana Hajiše, a my ji neprovádíme.

Fine-tuning bývá oproti pre-trainingu výrazně rychlejší a levnější. V podstatě vezmeš hotový model a jen ho „přivoníš“ na konkrétní data či use case.

Když to vezmu paralelně s embeddingy – o trénování embeddingů moc lidí nepřemýšlí, ale při použití například RAG (retrieval augmented generation) je to důležité. RAG slouží k tomu, že model odpovídá na základě specifických dat z dané domény (tzv. groundingu). A některé use casy mohou vyžadovat úpravu embeddingů, protože bez toho nemusí být výsledky dostatečně přesné.

Pokud chceš, můžu text ještě víc rozvést, nebo naopak zkrátit. Stačí říct!

Jasně, tady je opravený text s lepší strukturou a gramatikou:

O, ale představ si, že se v Outu ptáš RAG systému, který pracuje přímo z knowledge base Outu, třeba s produktovým portfoliem. Ty se teď ptáš, jaká je cena tohoto tarifu oproti tamtomuto tarifu. Ty tarify se třeba jmenují neobronzový a neoplatinový. Z pohledu embeddingů jsou to kovy, což znamená, že v tom vektorovém prostoru jsou si velmi blízko. Díky tomu RAG vytáhne i nesouvisející informace – třeba zrovna mluví o „bronzovém“ tarifu, ale ty se ptáš na „platinový“.

V takovém případě upravíš embeddingy tak, že se jejich prostor transformuje tak, aby „platinový“ a „bronzový“ byly od sebe vzdálené. Tím se přesnost tvého RAG systému dramaticky zvýší. Navíc je to mnohem levnější než fine-tunovat celý model, protože místo toho, aby ses učil model, upravíš jen embeddingy tak, aby reflektovaly rozdíly mezi tarify.

U RAG systému mám teoreticky tři druhy možnosti, jak reprezentovat data:

1. Embeddingy – vezmeš text, převedeš ho na vektory a počítáš vzdálenost. Tohle dobře chytá konceptuální rozdíly. Například když řešíme eating disorders nebo různá témata, jako mobilní tarif vs. fixní internet, embeddingy to dobře vyřeší.

2. Semantický přístup – v AI search terminologii je to starší, ale sofistikované NLP, které dokáže vyhledat konkrétní hodnoty, třeba „stojí 150 korun“ nebo „včera jsem dostal z matematiky jedničku“. To chytá faktografické informace.

3. Memory – například v Elin máme něco jako paměť. Funguje to tak, že když řekneš „Mám strach ze zkoušky, zítra jdu na zkoušku z matematiky“, Elin s tebou o tom dokáže komunikovat a pak třeba za týden připomene, jak ta zkouška dopadla. Pracujeme se složitějšími mechanismy časové paměti, což umožňuje mnohem lepší interakci.

Někteří říkají, že „to je jen GPT s memory“, ale my our memory pracuje sofistikovaněji, bere v úvahu čas a další faktory. Možná se časem paměť stane běžnou komoditou, fungující podobně jako u nás v Mosku, kde jsme si hodně vzali inspiraci ze semantické memory a podobných řešení.

Velkou inspirací byl Marek Ross, který přišel s konceptem v „Johnny Mnemonicu“. Měli jsme s Markem i Honzou diskuze a díky tomu jsme si od nich vzali spoustu hodnotných nápadů.

Problém RAG však nastane, když chci z naší memory vytáhnout … (text zde končí, ale předpokládám, že půjde o další detail na téma retrieval nebo zpracování informací).

Pokud chceš, můžu ještě více strukturovat text nebo doplnit některé části.

Opravený text:

Ínku pro toho uživatele. To prostě nic nevytáhne, jo. Ty nevíš, co to vytáhne, protože pozitivní vzpomínka, no tak to ti udělá nějaký embedding, ale tam prostě nemáš nic, jo, ale tam je třeba „byl jsem včera v lese“, projel jsem se na kole. To úplně, jako ono to něco vypadne, ale nevíš, co z toho vypadne. To je prostě nesouvisející otázka do té knowledge base, jo.

V ten daný moment se ukazuje, že by mohl fungovat takzvaný graf, jo, že ty data začneš reprezentovat i v grafu a vlastně se ptáš do těch tří, řekněme, reprezentací dat, pak bereš tu, která má největší nějakou metriku, a pak z nich uděláš ensemble. Takže tohle, co říkám, je, že věřím tomu, že tyto tři datové reprezentace pak pokryjí všechny možné use cases.

Ale pointa je, že častokrát, když se embedding natrénuje správně, vyřadí to semantik, protože embedding je dostatečně dobrý na to, aby zastoupil semantické vyhledávání – to znamená ten old fashion NLP, hodně to zjednodušuju. Vlastně je to vyřešené, protože embedding je dost silný a není potřeba zlepšovat, není potřeba silnější LLM. Často slyším, například když se bavím s někým, řeknou: „Ty vole, to je super to LLM, ale potřeboval bych výkonnější, třeba GPT-5, protože objevuji problémy, které tam doteď nebyly.“ Začnou měnit prompt, ale to už nepomáhá, pak řeknou: „Potřebuju lepší LLM, prostě AGI, aby vyřešilo můj problém.“

Jasně, a říkáš, že prompt je ta vrchní vrstva, pod tím jsou embeddingy a pod tím fine tuning. Jo, přesně tak, takhle na to koukám.

Pod tím může být pak někde změna architektury, nemít to jako jednoprůchodové a točit to, třeba řešit kritiky a podobné věci, a nedej bože agentní přístupy, kdy prostě takhle data „otáčíš“. Agentní přístupy se často používají v situacích, kdy máš enormní množství dat, která nezapadnou do jednoho kontextu.

Například nikdo nepochybuje, že LLM je schopné odpovídat na otázky „proč se něco děje“ na základě tvých dat. Ale představ si, že máš interakce, máš chaty – chaty LLM s uživatelem – a chceš zjistit, proč uživatelé přicházejí, co řeší za problémy. Tohle můžeš přenést například na C-level lidi, nebo třeba říct: „Mám interakce se zákazníkem a zajímá mě, proč dnes řeší právě tento problém, proč za námi chodí s tímhle.“

A nemáš na to report, který bys mohl udělat snadno; jeho vytvoření trvá třeba týden. Takže ten sen je se jen tak zeptat LLM a on ti odpoví. Problém ale je, že dat máš tolik, že je nenahraješ do LLM. Takže ten pro---

Pokud chceš, můžu text upravit dál nebo zformátovat pro lepší čitelnost.

Jasně, tady je opravený text s lepší srozumitelností a plynulostí:

Problém je vlastně o tom, jak získat subset těch dat tak, aby sis to mohl předat tomu LLMku a on odpověděl. To znamená, že ten subset obsahuje odpověď na tvou otázku, nebo má nějakou míru jistoty a zároveň odpovídá dobře. A tam potom ty agentní systémy můžou fungovat tak, že si vygenerují nějaké hypotézy, ověřují a filtrují data, dokud nedojdou do bodu, kdy jsou schopny odpovědět na tvou otázku. Třeba se do toho bodu nutně nemusí dojít, ale to je pak i otázka fine tuningu.

Ten fine tuning beru opravdu jako poslední možnost, když už s tím fakt nejsem schopný nic dělat. Třeba v našem případě, kdy modely prostě nechtějí o určitých věcech mluvit. Jsou totiž nastavené tak, že o těch věcech nemluví. Jednou z možností je třeba dostat se k uncensored verzi GPTčka nebo jinému typu modelu. Jsou i open-source modely, jenže tam je zatím trošku problém třeba s češtinou. My samozřejmě pracujeme hlavně s angličtinou, ale máme spoustu českých uživatelů, protože tady to primárně testujeme, zda celý nápad vůbec dává smysl a je životaschopný. U open-source modelů pak často narážíme právě na češtinu, což je asi ten největší problém těchto modelů.

V takových případech už nám pak dává smysl se pustit do fine tuningu, ale fakt až jako poslední krok, když už není kam jinam jít. Před tím je ale spousta možností, jak s tím pracovat.

Když zůstaneme u architektur – mluvil jsi, že máte Python backend, a jsou tam ještě nějaké další technologie. Dále mě zajímá, které verze modelů používáte, kde držíte prompte apod. V architektuře máte třeba Langraph, Langchain nebo něco podobného, co drží vše pohromadě, nebo píšete kouzla sami, protože tomu fakt rozumíte a trénovali jste opravdové modely, takže mezivrstva aplikační není potřeba?

Tady osobně hodně razím, že nemá smysl vymýšlet kolo znovu, protože opravdu potřebujeme být cost effective. Když jsme něco psali sami, trávili jsme tím hrozně času. Proto, když přišel Langchain, zkoušeli jsme ho rovnou používat. Neříkám, že je to nejlepší řešení, ale tehdy to bylo něco, co se dobře používalo. Velmi brzo jsme ale zjistili, že pokud to není jen jednoduchý prompt model s output parserem, tak je to docela složité a psát v tom něco konkrétního může být bolest.

Proto jsme přešli na Langraf. Těch nástrojů je teď ale strašně moc – Crew AI, spousta dalších knihoven a frameworků. Jakmile otevřu Twitter, vidím nový LLM a lidi s nimi dělají úžasné věci. Ale ta spousta novinek je i tak trochu FOMO – tedy strach něco propásnout. Petře, o tom si promluv se svojí kolegyní (nebo někým, kdo tomu rozumí), ona ti to vysvětlí – je to prostě FOMO. Já to s ní právě konzultuju.

Další typ příspěvku je…

Kdybys chtěl, můžu ti to ještě více strukturovat nebo upravit do profesionálnějšího stylu.

Jasně, tady máš opravený text:

Je to super knihovna, mě například docela bavily články třeba na Mediu nebo někde jinde, ty populární v tom oboru. LangChain není úplně dobrý do produkce a existují lepší řešení. Když si to přečteš, má to pravdu, ale podívej se, kdo to píše – autor té knihovny, že jo. Za mě je důležité, že nechtěli znovu vymýšlet kolo, takže používáme LangChain.

Je tam ještě malá abstrakce, abychom byli kompletně nezávislí na konkrétním LLM. Ano, LangChain nebo LangGraph tam mají třeba chat Bedrock a tak dál, ale my v konfiguraci zvolíme, jaké LLM chceme, a graf se postaví dynamicky podle toho. Můžeme tam i zapracovat změny, například když nějaké LLM potřebuje ještě nějaký krok předem – prostě se přidá pre-processing step s daty a tak dále.

Já teď inklinuju k tomu, že mezi backend a LLM dáme něco, co já nazývám LLM-router. V současnosti je to LightLM, který doporučuji, je to open-source projekt. Můžeš ho používat přímo v Pythonu nebo nasadit jako Docker. Oni tomu říkají LLM-proxy a sjednocují API přes všechny modely – je jich tam asi přes 100. Například když jsme si hráli s DeepSeekem (máme ho nasazený v Azure jako serverless v Azure AI Studio), Azure OpenAI, Bedrock – každé má úplně jiné API, takže to musíš v LangChainu řešit zvlášť, předávat klíče a v Google Cloudu třeba posílat JSON se service principem. Je to peklo, zvlášť když máš více prostředí.

LightLM to vyřeší tak, že pro všechny podporované modely vystaví OpenAI-kompatibilní API. Tvojí backend nebo řešení pak komunikuje jenom s tímto API a je jedno, jestli to vzadu teď je OpenAI, Bedrock nebo něco jiného. Navíc LightLM umí dobře řešit load balancing.

My jsme si to dělali samy a primárně jsme řešili load balancing mezi modely, protože nemáme peníze na dedikované trubky na LLM, které bývají dost náročné. Používáme PSU Go, ale někdy, například v Azure ve Švédsku, je business datacentrum hodně zatížené – mají tam většinu enterprise zákazníků a veliké kapacity. V tu chvíli může latence prudce stoupnout, tak když cítíme, že výkon degraduje, přepneme se jinam. Do tohoto jsme investovali hodně práce, protože je to pro nás klíčové, ale nemusí to platit nutně obecně.

Pokud chceš, můžu to ještě víc upravit nebo rozdělit na menší části.

Jasně, tady je opravená a lehce upravená verze textu, aby byla srozumitelnější a plynulejší:

Nějaké volání ohledně AI, že to je opravdu tak, že datacentrum je teď trochu víc vytížené, nebo i ten provoz, takže třeba Azure AI Foundry, AI Studio nebo i například ten typ VMEK je teď nedostupný. Dlouhou dobu ve Studiu v Azure byl totálně přetížený, nic tam nešlo nasadit, takže jsme si to tady nějak vyřešili. Možná to ale nakonec opustíme, protože teď tu řeší light lemma, kde můžeš nadefinovat například, že tady máš model GPT-4 nebo GPT-4.1 a máš pro něj třeba tři až čtyři deploye po Evropě. On mezi nimi pak dělá load balancing.

Zároveň můžeš nastavit, že když dojde k chybě, tak jdi automaticky třeba na Cloud, na Gemini, nebo na nějaký open source model. I když víš, že open source model odpovídá kvalitativně hůř, pořád ale odpovídá, není to, že ti vyhodí třeba 429 nebo jinou chybu a řekne „sorry“. To už za tebe taky řeší.

My jsme na začátku celého procesu hodně řešili věci sami, ta chytrá část je právě v tom, jak vše provozovat v produkci. Ty věci jsme si hodně řešili in-house, teď už vznikají nástroje a infrastruktury, které to umožňují. Ty nástroje vznikají, jsme v době, kdy se spousta standardů, jako jsou MCP nebo agents to agents, teprve rodí, je to hodně živelný. My už jsme samozřejmě v tom nějakou dobu, takže spoustu věcí jsme si museli dělat sami a vůbec za to nelituju, protože jsme se hodně naučili. Ale když teď už to někdo řeší za mě, věnuje tomu třeba 20 lidí vývoji, tak já toho rád využiju a svoje řešení klidně zahodím, protože jejich je lepší, mají větší podporu a já se tak můžu věnovat něčemu jinému.

Na druhou stranu ale máš tu investici – máš domain knowledge, víš, na co se koukat, jsi schopný posoudit, které řešení je lepší, protože jsi to nasazoval do produkce. Když se pak oprostím od nutnosti se tomu věnovat, udržovat to při životě, můžu se třeba věnovat tomu, že do systému přidám naše open source, případně si začnu hrát s agentním přístupem a už nemusím tříštit moje a Honzovy časové zdroje – říkám, kdyby den mohl mít 270 hodin, abych to vše stihl.

Dej si pozor na to, co si přeješ. Chtěl ses nenudit, ale já to beru. Startup je jedna velká nejistota, nevíš, jestli tu budeš i zítra, to je jasné. Ale za těch dva roky jsem se naučil strašně moc. Umíme už všechny tři cloudy, vlastně je nám skoro jedno, ve kterém jsme. Musel jsem začít řešit, jak bezpečně tu naši aplikaci dostat ven. Neříkám, že jsem to neřešil dřív, ale pak jsem si řekl, že potřebuji, aby to skutečně fungovalo…

Pokud chceš, můžu ti text ještě víc zestručnit nebo upravit podle konkrétního stylu, který preferuješ.

Jasně, tady je opravený text s lepší gramatikou a strukturou, ale zachoval jsem neformální styl, aby zůstal autentický:

Neřešili jsme to, museli jsme to dělat a byl to takový píčkový stav, jako kdybychom to dělali narychlo. Prostě to někdo musel udělat. Já jsem řekl, že bych to měl udělat tak a tak, někdo už řešil ty firewally, někdo už řešil, jak správně nastavit DNS. No a teď jsem to musel dělat já. Když jsem to dělal poprvé v Google Cloudu, řekl jsem si: „Ty vole, no tak dobrý,“ a věnoval jsem tomu den, druhý den už to téměř fungovalo. Takže je to jízda, nejhorší je ta nejistota – občas se v noci probudíš a řekneš si: „Do prčic, ještě tohle, ještě tohle.“ Ale to k tomu prostě patří, jo, to k tomu patří. A hrozně si to užívám, takže…

Ale zpátky k tomu. Na úrovni modelů ty říkáš, že to zní hodně agnosticky, že vlastně je jedno, co tam jde na vstupu. To je hrozně těžké, nebo je to výsledkem testování, výsledkem pipeliny a monitoringu nad tím. Že vlastně je jedno, co ti přijde jako vstup, máš tam takový filtr a hlídače, a můžeš zítra změnit model, ale kvalita nikam nespadne. Hele, bez ověření, že ten model skutečně dobře odpovídá, můžeš na začátku předpokládat, že novej model bude fungovat stejně dobře, ne-li líp, než ten současný. A na 90 % to bude pravda. To znamená, že když vyšla verze 4.1, tak s největší pravděpodobností bude lépe performovat než verze 4.0. Co znamená „líp performovat“? Znamená to, že edge casey, které dřív model nepochopil, že nesledoval správně instrukce, teď bude sledovat líp. Nemusí to nutně znamenat, že bude generovat násobně lepší odpovědi, ale v některých případech je to znát. A není to vždy pravda – může přijít verze 4.1 a třeba jsme hodně řešili třeba tu 4.0, která byla třeba květnová verze, a pak někdy v listopadu přišla další. Neberte mě úplně za slovo, ale bylo to tak, že jsme museli zůstat u květnové, protože listopadová prostě performovala hůř. Dneska ale čteme, že 4.0 jako poslední verzi úplně stahují, protože nešlape tak dobře, nebo je moc benevolentní vůči tomu, co dovoluje uživatelům.

Takže je potřeba to testovat pořád, nepřetržitě, a je to iterativní proces. Určitě od stolu člověk nevymyslí, jaké všechny scénáře chce testovat. Začínáš s něčím a pak to postupně rozšiřuješ. Teď jde o to, že sestavíš testovací sadu, kterou posíláš buď do celé pipeline – end-to-end od testování, že ti funguje kritik, router a další komponenty, nebo se zaměříš na jednotlivé části. Když to stáhneme na LLM, můžeš testovat kritika, nebo model, který generuje odpovědi. Připravíš si sadu vstupů – desítky, stovky, třeba tisíce příkladů – a ten model generuje odpovědi.

No a teď je otázka, jak to s tím textem vyhodnotit…

Pokud chceš, můžu text dovést až do konce.

Jasně, tady je opravený a stylisticky upravený text:

Není to jako standardní machine learning v tom smyslu, že tam na konci bylo nějaké číslo, kočka, pes nebo něco, a prostě jsi to mohl vyhodnotit ekvivalentně – například: „funguje mi to na 95 %“ nebo „naopak nefunguje mi to na 95 %“. Protože u strojového učení obecně vždycky platí, že potřebuješ testovací sadu. Nejlépe takovou, která má stejnou, nebo alespoň co možná nejpodobnější distribuci jako tvoje trénovací data. Respektive je to vlastně opačně: tvoje trénovací data by měla mít co nejpodobnější distribuci tomu reálnému testovacímu prostředí.

Nicméně u LLM (velkých jazykových modelů) vůbec nevíš, jak byla data sestavena a neznáš přesně jejich obsah. To znamená, že se to omezuje na konkrétní use case a ty pak tento use case využíváš k hodnocení toho, jestli výsledek je dobrý nebo špatný.

Pokud například víš, že hledáš nějakou faktickou hodnotu, třeba 150 kódů apod., můžeš použít regex, který ti to najde. Nebo když chceš, aby model zmínil něco, co se stalo včera, například ve školním chatu – třeba, že včera nebo minulý týden byl test z matematiky a zajímá tě, jak dopadl – tak tohle můžeš také vychytat pomocí regexu nebo nějakých pravidel, aby ses ujistil, že to model nezapomene zmínit.

Když to takhle neděláš, můžeš použít další LLM jako „judge“ – tedy hodnotitele – který porovná odpovědi A a B, řekne, která je lepší, nebo jestli jsou obě stejné. A takhle pak můžeš vyhodnotit správnost odpovědí.

Celá pointa je dostat se k tomu, že danou odpověď ohodnotíš jako správnou nebo špatnou. Na základě toho pak můžeš dát nějaké číslo, protože, jak víš, je pak přehledné říct, že to funguje na 95 %, 98 %, 70 % a podobně.

Když máš takový pipeline, můžeš také testovat různé verze modelů a sledovat efekt. Například někdy se říká, že určitý model (například ChatGPT) je „živější“ v odpovědích, ale může se stát, že kvůli tomu je méně přesný fakty. Takže můžeš testovat, jestli ta „živelnost“ neovlivňuje faktografickou správnost generovaných odpovědí.

Nebo můžeš sledovat, jak nová verze GPT, například ne jen GPT-4.0 nebo 4.1, ale třeba podzimní revize, začala některé odpovědi odmítat nebo na ně neodpovídat, což pro nás může být problém. Z tohoto důvodu jsme na ni možná dlouho nemohli přejít nebo jsme ji zatím nezačali plně využívat.

Na druhé straně můžeš říct, že chceš používat plnohodnotné GPT, ale kvůli ceně a rychlosti použiješ jednodušší model (například miníčko). I když to o 5 % sníží přesnost, může to být pro tebe přijatelná daň, pokud splňuje kritické požadavky.

Když máš takovou testovací sadu a umíš srovnávat LLM A a LLM B z hlediska funkčnosti, můžeš například říct: „Když mi tu moje hlavní GPT verze nefunguje, přepnu na záložní řešení (fallback) na jiné modely nebo cloudové služby.“ To znamená, že odpovědi mohou být trošku jiné, ale zachová se kontinuita.

Pokud chceš, můžu ti text ještě více zjednodušit nebo rozdělit na odstavce. Dej vědět!

Jasně, tady je opravený text:

Je to živější, ale častokrát se bude vyhýbat, ale prostě pořád generuje odpovědi, to za mě je OK. A mezi tím budeme řešit, jak tam zase zpátky nastavit GPT, takže s tím takhle můžeš opravdu kalkulovat s výkonem. Když potom dojdeš k tomu, že každý ten LLM byl nějak trénovaný, třeba GPT obecně je trénovaný na markdown a JSON, což znamená, že pro mě je dobré psát v markdownu, případně předávat data v JSONu. Naopak Cloud je trénovaný na XML, což znamená, že třeba on markdown taky zvládne, ale primárně… Já chápu, že prompt by měl být čitelný pro člověka, někdy máme taky dost „nešetřící“ prompt, ale vedl jsem zajímavou diskusi s Honzou, který říkal, že XML je víc deskriptivní, lépe ohraničuje úseky s instrukcemi. Takže někdy je dobrá kombinace obojího. Cloud například lépe reaguje na XML – prostě tam vložíš instrukce do špičatých závorek:…. Lepší reakce znamená, že odpovědi jsou kvalitnější a model lépe sleduje instrukce. V kontextu okna výkonu ale už na to není takový rozdíl, to už je spíš něco jiného.

OK, super, pokračuji. Obecně je prompt o tom, respektive ladění promptu je o tom, že začneš řešit situaci, kdy model přestane sledovat instrukce – tedy když mu říkáš „chovej se takhle“, „dělej tohle“ a „tohle nemusíš dělat“, a on to i tak pořád dělá. Hodně řešíme například skloňování v LN. Měl/měla, lomeno A, moc hezky by to mělo tykat, ale znáte to, uživateli to často vadí, protože model začne vykat, a to je pro uživatele nepříjemné. To jsem už řešil, takže tam potom začneš řešit problém, že model nesleduje tvoje instrukce. Může hrát roli i kontextové okno. Docela zajímavý přístup je, že modely obecně kladou větší váhu na systémový prompt. Nevím, jestli to posluchači vědí, ale systémový prompt je základní instrukce, co by model měl dělat. Třeba když komunikujete s ChatGPT, OpenAI tam má systémový prompt, který říká „jsi takový a makový, toto můžeš říkat, toto bys neměl říkat“. Před nějakou dobou byly velmi populární různé jailbreaky, kde se systémový…

My taky máme například zkušenost s tím, že musíme testovat red teaming, aby nám model neřekl, že se máme zabít – to je pro nás kritické. Spolupracujeme s jiným startupem, SPLX z Chorvatska, který dělá automatizovaný red teaming. My máme také vlastní red teaming, spolupracujeme s kluky a studenty ze smíchovské průmyslovky. A říkáš si, že to máš docela ochráněné. A první, co udělali, bylo testování systémového promptu uživatele…

Jestli chceš, můžu ti s tím pomoci ještě víc zpřehlednit, nebo upravit styl.

Tady je opravený a uhlazený text:

Ame, aby prostě vědělo, že jsi Petr Stanislav, nebo něco takového. No a mě napadlo, že prostě do toho pole pro zadání jména, username, prostě dali „ignore all instructions“, bla, bla, bla. My jsme tam měli systémový prompt, takže nám to hned „jebalo“ kry. A prostě tam „líklo“ úplně všechno. Takže nevím, je to třeba v ten daný moment logické, že do zadávacího pole uživatel může zadat cokoli, a když je uživatel zákeřný, tak to zneužije.

Ale teď jsem maličko ztratil nit, takže se vrátím. Jo, prostě začneš řešit ten prompt, když model přestane sledovat tvoje instrukce. A potom opravdu začneš řešit například: „Ok, když mám Clouda, a Cloud líp reaguje na XML, začnu mu dávat XML, protože on je na to natrénovaný.“ Kontextové okno, takový ten základ – proč jsou třeba ragy, nebo když čelím otázce: „Ale ty tady máš ty memories, proč je všechny nedáš do promptu, do kontextového okna a nenecháš LLM vybrat tu správnou informaci?“ No, tak jsou tam dva problémy.

Jeden je cena – to je ta největší překážka. I když jde cena dolů, u velkých modelů to stále stojí dost peněz. Sice Gemini mají milionový kontext, dokonce dvojmilionový, ale reálně, když naplníš dvoumilionový kontext a pošleš dotaz, stojí to docela hodně. Jeden dotaz, a teď tam posíláš znova a znova… Přesně, to není „rák“, to je ten „cák“ – myslím, že se to tak jmenuje, že všechno dáváš do kontextu.

Takže první problém je cena, a druhý je problém ztráty souvislosti – jako „jehla v kupce sena“. Představ si, že máš knížku – třeba Temno, nebo něco podobného – a doprostřed Prahy je 35 stupňů. Ptáš se modelu: „Kolik je stupňů v Praze?“ Některé modely na to reagují líp, jiné hůř. Mám na to test, kde je tabulka, osa x jsou řádky modely, a sloupce jsou délky kontextu a jestli to model našel nebo ne.

Zajímavé je, že to není tak, že od určité délky kontextu model přestane informaci najít. Naopak, v některých variantách kontextu informaci nenajde, a pak ji zase najde, pak zase nenajde. To znamená, že si myslím, že čím větší kontext, tím víc může model být zmatený.

To znamená, že by se měl držet určité délky – neříkám, že mu musíš pokaždé dávat jen jednu zprávu, ale když už se dostáváš přes nějaké množství tokenů instrukcí, třeba 20 tisíc tokenů, za mě už je to moc. Model by měl uvažovat o jiné architektuře – že to není jen průtokový model, ale že to nějak optimalizuje.

Musel by to optimalizovat, přesně tak. Modely rostou, a protože se jedná o feedforward sít, ten kontext tam je proto, že to prostě zpracovává dopředu, všechno najednou. Není to rekurentní síť, kde by se informace držela nějak průběžně…

Pokud chceš, mohu text ještě více upravit, aby měl oficiálnější nebo vhodnější styl na dané použití.

Ona to postupně chroupe, dám tomu všechno na začátku, ale pak je problém, že… respektive takhle: ty kontexty se zvětšují proto, že se zoptimalizovaly attentions. Jo, full attention znamená, že attention není jen nějaká matice, která má nějaká čísla, ta se nějak projevují na výstupu.

Chytrý lidi řekli: OK, full attention je dost paměťově náročná, teď tam těch attentions mám „bambilion“, tak udělám takzvanou flash attention, nemám tu matici celou a použiju nějaké různé chytré triky. Přiznám, že nestíhám studovat do detailu všechny možnosti optimalizace těch attentions, ale je to o tom, že snižuju paměťové nároky, díky tomu můžu zvětšovat to kontextové okno.

A nejdál jsou teď Gemini, kde jsou milionové kontexty. Ano, Lama 4 má desetimilionový, ale Lama 4 má taky dost špatné vnímání, protože podle mě tam spoustu věcí „nafejkovali“, například co se týče Treat Chat arény.

Co já laik chápu, tak oni to udělali na testy. Přetrénovali model na testy, ale reálně ta čtyřka není světoborná — že by zvládala matematické olympiády, ale neumí nakoupit v obchodě, protože počítá blbě. Přesně tak.

Takže za mě je fajn, že kontexty jsou větší — nevěříš jednomu A4, ale můžeš tam narvat víc. Ale pořád to má limity: čím větší kontext, tím víc může být model zmatený a tím vyšší je šance, že nedodrží instrukce a vygeneruje blbost. Proto je důležité neposílat do modelu zbytečné informace.

Mám ještě jednu věc k posuzování modelů: jak moc si hrajete s nastavením modelů, například pravdomluvností, kreativitou, temperature a tak? Hodně záleží. U „serious“ úkolů držíme temperature nízko, protože když je vysoko, může se stát, že model „uteče“ a pošle něco, co nechceme. Takže temperature držíme nízko, ale ne úplně na nule. U routeru třeba ano: ten musí být relativně deterministický, aby rozhodoval konzistentně. Samozřejmě se občas stane, že rozhodne různě.

Jak jsi říkal, variant je mnohem víc než jen LAMA vs. BEDROG nebo DIPSIK verze 3 vs. 3.1, ale také s různými nastaveními OpenAI, třeba temperature 0.5 vs. 0.7. To taky zkoušíme, ale pořád se to dá řídit testy. Může být potřeba dodat další metriky pro hodnocení, je to iterativní proces s testovací sadou. Obecně začínáme selským rozumem: potřebuju, aby byl model kreativní, nebo ne?

Ho začneš. A pak samozřejmě začneš řešit nějaké tweaky, ale to už záleží na tom, jak moc se do toho chceš zabrousit, jak moc to chceš… Super, chápu. A teď ještě prompty. Tak vlastně dvě otázky. Za prvé – je pro tebe prompt nové zvířátko a úplně nová disciplína, nebo ti to dává smysl jako sada instrukcí pro neuronku? To je první. A ta druhá je, jak je vlastně držíte. Teď jsi říkal, že něco posíláte z XML, něco v JSON. Tak jak v tomhle máte pořádek, když je to tak důležitá součást celého toho enginu?

Jo, tak na začátku byl prompt pro mě nové zvířátko v tom smyslu, že jsem musel začít přemýšlet nad tím, jak dobře začít psát, jak se naučit psát instrukce. Neříkám, že jsem nejlepší na světě, ale už mám nějaké zkušenosti, respektive nějaký feeling, co si myslím, že funguje. Jak jsem říkal, já preferuji psát prompty v markdownu. Jestli pak nějaké ještě obalíme, uděláme nějaký hybrid v markdownu – to už je detail. Tam je to o tom, že řešíme opravdu edge cases. To znamená, že za mě je best practice dávat systémové prompty vždycky v angličtině, protože model bude mít vždycky víc dat v angličtině, což znamená, že systemový prompt má větší šanci, že bude dodržovat instrukce, když je v angličtině. Jestli uvnitř bude ještě někde čeština, to už je vedlejší.

Před lety jsem tady byl na meetupu, kde Microsoft prezentoval vyhodnocení toho, kdy byl LLM použitý jako překladač. A podle mě ten závěr stále platí – když LLM používáš jako překladač dvou jazyků, které jsou datově bohaté, tedy existuje dostatek dat na internetu k jejich natrénování, tak je krok do VR překladač. Můžeme vést diskuzi o tom, jestli interně není nějaká univerzální reprezentace jazyka, nehledě na angličtinu a češtinu. Možná ano, možná u některých modelů, v jiných ne. To je taková spíš filozofická otázka…

A mě teď napadlo, že s tím přišel teď Anthropic s postupem studií, že velké nové modely už nepřemýšlí v jednotlivých jazycích, že mají vlastně svůj univerzální jazyk reprezentace a že jim je to jedno. A já osobně si to myslím už delší dobu, protože opravdu, aby překlad fungoval… A teď trochu bařím vody v tom smyslu, že jsem nedělal výzkum, ale moje takové…

…vztahové vnímání a chápání toho, jak to funguje, je, že tam musela být nějaká pseudoreprezentace už delší dobu, aby to dobře fungovalo v multilingvním prostředí. Myslím, že do toho hodně hrálo i to, že se přidaly další modality – obrázky, zvuk, primárně obrázky. A jako hezký – Anthropic – vždycky na začátku mi chvíli trvá, než upustím úvahy fantazie a začnu přemýšlet, jak to asi mohli vyřešit, vždycky mám takové klapky nebo mantinely. Říkám si: „No prčic, jak tam sakra dali ty obrázky? Jak to sakra udělali? Tam má nějaký – nevím, obrázek nějakým způsobem zpracuju nebo co.“ A pak… (pokračování textu).

Jasně, tady máš opravený text:

Blogy od antropiků jsou na to hodně dobrý, tak si říkám: „Ty vole, oni prostě na to koukají tak, že co jako sloupec toho obrázku, to token.“ A pak už když je to token, tak to prostě rvou do LLMka, on si takhle přečte ty sloupečky toho obrázku jako větu a pak s tím pracuje. V podstatě jsou to furt čísla, furt to jsou vektory, a jedno, jestli je to text nebo obrázky.

Jasně, kdokoliv z nás, kdo někdy neměl prohlížeč fotek a otevřel ji v textovém editoru, zjistil, že ta fotka je string. Jsou to RGB hodnoty, tři čísla pro každý pixel, takže to je v podstatě vektor. Oni tedy naučili model, že ty sloupce toho obrázku jsou tokeny, alias slova. Pak už s tím nějak uvnitř pracuje.

Vezmi si například textové embeddingy od OpenAI, mají dimenzi třeba 3000, menší model má 1500, takže to odpovídá třeba obrázku s jednou dimenzí rozlišení 15 000 pixelů.

Všechny fotky jsou vlastně hodně naškálované ASCII hodnoty.

A může to pomoci k tomu, že uvnitř toho LLMka je nějaká pseudoreprezentace jazyka. LLMko je obrovské a naučilo se obecné zákonitosti jazyka, takže možná je to cesta ke star trekovskému univerzálnímu překladači, kde je uvnitř nějaká pseudoreprezentace jazyka a my s ní můžeme pracovat.

Zpátky k promptům: já razím tohoto systému mít prompt v angličtině. Pokud pak uvnitř použiješ češtinu, je to vedlejší – model se s tím popere, ale lepší je mít systémové instrukce v angličtině.

Otázka je, když budeš mít nějaké best practices a budeš sledovat prompty, můžeš využít třeba Anthropic nebo OpenAI k generování promptů – tzv. pseudoprompt. Začneš tím, že řekneš: „Mám takový a takový problém, jak to řešit?“, a oni ti vytvoří třeba dva tři rozdílné prompty.

Pro mě bylo vždycky nejhorší začínat s prázdným papírem. LLMka jsou spásou, protože jim jenom řeknu, co chci, co řešit, a oni mi ušijí kostru. Já pak už s ní pracuji bez LLMka, ale mám aspoň základ, na kterém můžu iterovat.

A teď je otázka, jestli je potřeba to optimalizovat. Já jsem perfekcionista, ale co jsem se naučil v korporátu, je to, že často je „good enough“ nejlepší řešení, to nejrychlejší. Znamená to, že můžu trávit hodiny laděním technického problému nebo promptu a iterovat věčně – ale často je lepší to prostě dostat do použitelné podoby rychle a jít dál.

Pokud chceš, můžu to ještě více uhladit nebo rozdělit do odstavců.

Zde je opravený a upravený text:

Dlouho ladit prostě malinkaté detaily… Bude to mít tu „deltu“ hodnoty? Právě, to je otázka. Znamená to, že na začátku je nejlepší prostě dodržovat nějaké, řekněme, best practices. Nemusíš nutně sledovat to, co jsem já řekl, ale na internetu je spousta skvělých zdrojů. Například série od O'Reillyho, která je rozdělena na tři části a je relativně dlouhá, kde se právě vysvětlují specifika Cloudu, Gemini a tak dále. To je velmi zajímavé, z toho se dá něco nabrat, mít nějaké základní best practices, napsat prompt a začít to používat. A teď řešit, kdy to nefunguje. A pak se podívat, jak to vyřešit.

Je otázka, jestli je to tak velký problém, že ho musím řešit, prostě je to o tom investovat energii a hlavně čas. Je důležité zjistit, zda ten problém nutně řešit musím, a pokud ano, tak první krok je samozřejmě prompt engineering. Například používám Cloud, ok, takže tam dám XML, když vím, že máme docela rozsáhlý systém a snažíme se být LLM agnostičtí.

Jak jsem říkal, přes light limit to můžeš i odfiltrovat, podle toho, na jaký model se to volá. Ale když vím, že na to je dobrý Anthropik, tak třeba udělat nějakou automatickou konverzi. Snažíme se nemít prompt specifické pro konkrétní modely, ale když už víme, že model pochopí systémové instrukce, pak je spíš o tom, jak do toho dáš svoje znalosti. Když máme rákos, tak třeba z dragu vyleze nějaký objekt dokumentu, a je otázka, jestli ten dokument reprezentovat jako XML, nebo jako JSON.

Četl jsem zajímavý článek, který říká, že ideálním formátem může být YAML. JSON je relativně malý, ale problém je množství tokenů, protože tam máš spoustu závorek, které tvoří malé tokeny, ale nejsou to slova. XML naopak bývá ukecanější, má více znaků, a tudíž může zabrat více tokenů. A YAML je někde mezi tím a navíc je docela dobře čitelný pro člověka. JSON je problém v tom, že je sice čitelný, ale XML je asi ještě o kousek víc human readable. YAML je mezi tím a navíc díky slovům místo závorek je docela efektivní z hlediska tokenů. Je to docela zajímavé téma.

Pak začneš řešit, jak reprezentovat data. Představ si, že v Alien máme něco, co nazýváme user model. Jak jsem říkal, Alien se snaží přizpůsobovat uživatelům, takže uživatele musíme nějak popsat. To je téma, na kterém pracují Petr a Stanislav. Já jsem spíš introvert, takže s Jirkou a psychology nebo jinými odborníky řešíme, jak vlastně reprezentovat uživatele – jejich dimenze a vlastnosti.

Když to zjednoduším, všichni víme, co je MBTI, ne? Víme, co je introvert a extrovert a podobné dimenze. A teď tu souvislost vztáhnu k tomu…

Pokud chceš, můžu opravit i zbytek textu, stačí říct.

Jasně, tady je opravený a upravený text, aby byl plynulejší a srozumitelnější:

Tak třeba tam můžeš mít: „Hele, to je spíš introvert,“ jo? Zároveň je asi spíš z generace Z než z jiné generace. My si sice neptáme na věk, ale zároveň se snažíme mluvit řečí tvého „kmene“, když to tak vezmu. To znamená, že ta data nějak musíš v promptu reprezentovat.

Pak řešíš formu toho promptu. Můžeme se bavit o tom, že když máš nějaká tabulární data, tak převod mezi JSON, XML a YAML je relativně jednoduchý. Potom můžeš operovat s tím, že když voláš GPT, tak mu data dáš jako JSON nebo YAML, a když voláš Clouda, tak je tam třeba pošleš jako XML – a to je relativně jednoduchý algoritmický úkol.

Dale řešíš kontextové okno. Já osobně preferuju, aby kontextové okno nebylo příliš dlouhé. Takže začneš řešit situaci, kdy máš nějaký chat, sérii zpráv, a například v Alien jsme omezovali počet zpráv, které můžeš poslat. Spousta uživatelů říká, že to zhruba deset procent uživatelů vnímá jako omezení, i když jsme si chtěli o tom povídat víc. Zároveň to podporuje myšlenku, že v Alien chceš mít „hodinu pro sebe“ – tedy že chat skončí, ale hned se z něj vyextrahují „memories“ a začne nový chat, který zároveň ví, co už v tom předchozím probíhalo.

Takže jsme si tím omezováním trochu usnadnili práci, protože nemusíme dělat sumarizace předchozích zpráv. Nicméně teď, když máme v preview nekonečný chat, můžeš psát do nekonečna, ale dřív nebo později kontextové okno zaplníš. Začneš tedy řešit, že už sice máš nějaké „memories“ a uživatelský model, ale model je většinou ignoruje, protože kontextové okno je tak velké, že na to nedává moc důraz.

Takže začneš řešit, jaká je nejlepší strategie například pro embedování nebo dobré shrnutí předchozí konverzace, aby se zachovaly všechny důležité detaily. To jsou věci, které opravdu řešíš, a možná jsou mnohem důležitější než například ladění samotného promptu ve smyslu: „Hele, použiju markdown, nebo ne?“ Markdown je tam kvůli hierarchické struktuře, i když Honza tvrdí, že to prezentuje věci ještě lépe – ale to už je naše interní diskuze.

Clash of the AI stars: XML versus JSON – to je skvělý, skvělý. A myslím si, že jsme odpověděli.

Za prvé – prompt je opravdu důležitý v celé té architektuře, protože je to základ. A za druhé – prompt verzujete a držíte jeho verze.

Samozřejmě když začneš s LLM, všechny příklady jsou o tom, že máš nějaký těžko spajtný text…

Pokud chceš, můžu to ještě více zkrátit nebo vysvětlit konkrétní části, dej vědět.

Jasně, tady je opravený text s lepší strukturou a gramatikou:

Typescriptu nebo to, a ten prompt máš v tom kódu. To je dobré na začátek, ale v momentě, kdy jsi v té aplikaci, tak to už nefunguje. To znamená, že jedna z prvních věcí, kterou začneš řešit, je, že prompt dáš mimo kód. Začneš tedy řešit, kde bych to měl mít. Jedna z možností je, že to budeš mít v Gitu. U toho projektu to bude prostě soubor vedle, Git to automaticky verzionuje. Problém je, že to pořád nějakým způsobem držíš u kódu.

Pokud dobře máš oddělené environmenty: dev, staging, alpha a produkci, tak v každém z nich máš různé verze. Respektive v daném environmentu je vždy nasazená nějaká verze aplikace, což znamená i relevantní commit message. Jde to, ale pořád je to ve stejném kódu. Blbě se tam dělají rychlé zásahy, pokud například najednou potřebujete rychle zasáhnout – třeba teď nám klekla GPT-4, máme tam bug a víme, že model hůř funguje, tak chceme upravit prompt. V takovém případě ale znamená změna promptu redeploy celé aplikace. To může v lepším případě trvat minuty, v horším případě i hodiny.

Proto jsme my, ještě když nebyly hotové nástroje, udělali řešení, kde jsme si prompt ukládali v databázi – měli jsme u nich nějaké flagy, historii a aplikace, když se ptala a měla sestavit dotaz, prompt si vždy vytáhla z databáze. Neřeším teď cacheování, aby ta databáze nebyla přetěžovaná, ale to byl první krok.

Pak se začaly objevovat nástroje – první, který jsme testovali, byl PromptLayer, nějaký startup z Ameriky. Problém nebyl GDPR, ale všechno bylo v Americe. Z pohledu GDPR to bylo relativně v pořádku, ale my pracujeme s evropskými uživateli, takže raději chceme mít data v Evropě. Proto jsme PromptLayer velmi rychle opustili.

Přišli jsme na Langsmyth, což je nástroj od tvůrců Langchainu. Langsmyth je vlastně forma monetizace celého ekosystému a i do něj my teď trackujeme. Problémem byla opět Amerika, ale nyní už mají i evropské datové centrum, takže data máme v Evropě.

Langsmyth můžeme označit jako git pro LLM. Dá se to tak říci, protože Langsmyth je vlastně platforma pro LLM engineering a LLM ops. To, co řešíš v rámci LLM ops, je jednak prompting – práce s prompty, verzování promptů a další – a potom tracking.

Obecně, když provozuješ jakoukoli machine learningovou aplikaci, musíš sledovat, jak model odpovídá. Protože nejhorší, co se ti může stát, je situace, kdy máš trénovací data, která by měla distribučním rozložením co nejvíc odpovídat realitě, ale v produkci se distribuce mění. Otázka stále je, jak robustní model je a jak moc je citlivý na změnu distribuce.

Pokud chceš, mohu upravit text více do formální podoby nebo naopak do neformálního stylu. Stačí říct.

Tady je opravený text:

Nějaké svátky přijdou, léto přijde a úplně totálně se změní chování uživatelů. To znamená, že se změní distribuce, na kterou musí model reagovat. A on ti ještě v listopadu bude nabízet třeba slunečník, nebo naopak po Vánocích budou nabízené produkty nevhodné, protože model bude špatně vybírat uživatele, kterým by měl něco nabízet. Protože se uživatelé po Vánocích chovají jinak než v průběhu zbytku roku. To znamená, že ta distribuce se změní a model začne produkovat „garbage“ výsledky. Proto je důležité monitorovat a zaznamenávat to, co model vyprodukoval, a vyhodnocovat to podle parametrů distribuce.

Co se týče LLM, je to v tomto ohledu dost podobné. Sice nezaznamenáváš, jestli ti model nabídne šálu nebo slunečník, ale sleduješ, jak odpoví. Když je to LLM engineering nebo LLM ops platforma, vidíš tam nejen nějaké latence a metadata, ale pokud latence rostou, může to být indikátor, jak model funguje. Samozřejmě to nemusí být jen Langsmith nebo něco podobného, jde to měřit i jinak – přes OpenTelemetry, Langchain, LangGraph, které lze napojit na OpenTelemetry a potom to jde do Prometheanu.

Nemluvím teď kvůli Finům, ale třeba pro tebe může být taková platforma jedním místem, kde uvidíš odpovědi, můžeš je různě tagovat, flagovat a vytvářet si tak dataset. Součástí těchto platforem často bývá také „playing ground“ a evaluační nástroje. To znamená, že když si vytvoříš dataset, nemusíš si vytvářet vlastní pipeline. Kdo má technické schopnosti, snadno si ji vyrobí – zavolá LLM nebo celou API několikrát, uloží odpovědi do Excelu nebo databáze a udělá si vyhodnocení. Ale nechceš pořád znovu objevovat kolo, já rozhodně nechci. Když mi platforma už nabízí, že tam nahraju dataset, zvolím modely A, B, C, ona mi to všechno projede a dá souhrn i s metrikami, které sleduje, pak je to otázka, jak flexibilní ta platforma je.

Takže já takhle můžu periodicky sleduju všechno permanentně, aniž bych musel vyvíjet všechno znovu. Platím za to desítky, nebo jako startup to někdy mám zdarma, ale někdo se specializuje na můj problém, má na to armádu lidí. My máme třeba jednotky, což znamená, že ano, mohli bychom si to vyvinout, ale ty peníze musíme pálit někam jinam. Naše know-how je jinde. Přesně tak, přesně tak. Takže tohle je to, co ty platformy dělají. A pak tam máš ještě další věci. Třeba my jako první jsme tam jako s t…

Pokud chcete, mohu pomoci s další částí, stačí dodat.

Opravený text:

O Langsmithu samozřejmě tracking, ale hlavně ty prompty. Jo, zpočátku jsme zápasili s tím, že například Langsmith neuměl přidávat tagy. V Langsmithu je to vlastně takový pseudogit, kdy při změně promptu uděláš takzvaný commit, který má svůj commit hash a tak dále. Verzování tam tedy je, ale když voláš API Langsmithu, musíš buď specifikovat přesný commit hash, nebo pokud ho nespecifikuješ, bere automaticky ten poslední commit. Takže jsme to řešili trochu pseudorešením: v databázi jsme měli ke každému promptu uložený příslušný commit hash a podle toho jsme pak přepínali. I když to bylo trochu operativně náročnější, při nasazení nové verze jsme v produkční databázi změnili commit hash a systém začal používat nový prompt.

Ideální řešení je ale práce s tagy. Prostě řekneš, tady je dev tag, který může být vždy jen u jednoho commitu. Když Langsmith zavedl tagy – promplayer to měl dokonce od začátku – můžeme jednoduše říct: tenhle prompt je v devu, tenhle je ve stagingu a tenhle v produkci. A když potřebujeme novou verzi, jen tag změníme.

My tam máme ještě caching, takže buď cache smažeme, nebo prompt zůstane v cache maximálně hodinu.

Momentálně uvažujeme o Langfuse, což je open source alternativa podobná Langsmithu. Může být SaaS, ale zároveň umožňuje nasazení lokálně, což je pro nás výhodné. Problém s Langsmithem je, že nám mazali data a trasy, což znamená, že je musíme relativně rychle projít a rozhodnout, co půjde do trénovací nebo evaluační sady, než nám data odstraní. Navíc je to provozováno v nějakém datacentru, které nemáme plně pod kontrolou.

Když jsme na začátku nasazovali aplikaci v cloudu, byl to Google Cloud. Jsem zastáncem toho, že pokud nemáš tým na správu infrastruktury, je dobré si operativu co nejvíc zjednodušit a zbavit se starostí, obecně opsu. Proto například velice preferuji Cloud Run, což je serverless kontejnerová platforma, která v pozadí může běžet na Azure Kubernetes, Google Borgu (který není úplně Kubernetes, ale funguje podobně) atd. Řeší ti to škálování a provoz kontejnerů i jejich případné zpřístupnění navenek.

Po diskuzích a kvůli potřebě širšího spektra nástrojů jsme se už posunuli ke Kubernetes, a když už ho mít, můžeme si tam nasadit i Langfuse. Tím pádem budeme mít data uložená v našich storage službách – jako je S3 nebo podobné – a v naší databázi, kde je budeme schopní držet dlouhodobě. Navíc to budeme moci provozovat v „uzavřené“ síti VNeta s přístupem jen přes VPN nebo podobná zabezpečení.

Tady je upravený a opravený text, aby byl srozumitelnější a gramaticky správný:

„Máme to prostě mnohem lepší, bezpečnost je mnohem víc zaručená, bude se nám líbit. Teď testujeme LangFuse a zvažujeme, že bychom odešli z LangSmithu. Těch nástrojů je spousta – OPIC teď hodně na mě všude vyskakuje, samozřejmě MLflow, Neptune, AI, je to zajímavé. MLflow má trochu takovou historickou pozici z dob good old day ML, takže některé věci z pohledu LLM tam ještě nejsou tak dotažené, ale pokud máte MLflow, určitě v něm jde pracovat.

Za mě je klíčové, pokud s něčím pracujete, mít možnost verzovat prompty, pracovat s nimi. To je naprosto zásadní. Když tohle budete mít, můžete začít sledovat výstupy a dělat s nimi další věci.

A stále ještě používáte k tomu LangSmith jako databázi? Posíláte do ní data?
Ne, teď už to máme v naší vlastní databázi. V momentě, kdy tam představili tagy, zmizela tabulka s názvem promptu a komentářem, protože to teď řeší za nás. My jsme si vytvořili abstrakci, kde prompt v základním prostředí automaticky přidává ty tagy, a pokud chce uživatel, může je přebít.

Zatím to nemá uživatelské rozhraní, kde by byl přehled všech flow nebo modelů, jen klikáme na modely. Je to pořád spíš v kódu nebo konfiguraci, která je mimo. Nemůžeme vše udělat user-friendly, jsou důležitější věci. Prompty stejně měním já nebo Honza, takže je to v pohodě.

To mě vlastně navedlo na moji poslední otázku. Věřím, že se brzy zase potkáme s aktualizací vaší architektury a toho, co se děje, protože toto bylo super obsáhlé, praktické a užitečné. Díky za to.

Jak se vlastně díváš na nové nástroje? Začali jste s Langrate, pak Langchaining, přišel Langraf, teď používáte LangSmith, napsali jste si vlastní řešení, a teď přišel další nástroj, který to dělá automaticky.

Moje otázka je: v tomhle dynamickém prostředí, kdy teď přichází LLM Ops a vzniká infrastruktura pro LLM operace, co podle tebe bude další vyřešená věc? A jak se rozhoduješ, co má smysl si postavit sám a na co radši počkat?

Co je takový problém, který budou řešit všichni, a tím pádem na něj nepotřebuješ mít vlastní pipeline – protože to přijde, třeba ne za dva měsíce, ale za půl roku?

Odpověď hodně záleží na tom, jak moc chceš být vpředu, jak moc chceš být před komunitou. Protože u spousty věcí platí, že dřív nebo později přijde vendor nebo toolstack, který to vyřeší end-to-end. Když jsem začínal s Ragem nebo konzultoval implementaci…“

Pokud chceš, mohu text ještě více zjednodušit nebo upravit pro konkrétní použití.

Jasně, tady je opravená verze tvého textu s úpravami pro lepší plynulost a srozumitelnost:

Když se ptáš, jestli má smysl vytvářet Rage do firmy vlastní vývoj, nebo raději počkat na blackbox řešení, tak já říkám, že za nějakou dobu, nevím jestli to bude za měsíc, rok nebo dva, se blackbox stane komoditou. Ty do něj dodáš data, řekneš mu, co má dělat, a ono to udělá. Pro většinu hlavních případů použití to bude dostatečně dobré. Samozřejmě budou i use cases, kdy budeš chtít dosáhnout přesnosti 90 % a víc a řešit nějaká specifika, takže do toolstacku nebo hotového řešení budeš muset zasáhnout a bude ho třeba udržovat dostatečně flexibilní.

Firmy, i my, v momentě, kdy se to stane komoditou, už budeme o krok dál – řešit další věci, třeba jak dostat to celé do podoby agentů, jak zvládnout tisíce až desetitisíce requestů. To hodně záleží na tomhle. Pokud tedy nechceš být na špici, nebo teď řešíš jiný priority a tvůj fokus není na tomhle, klidně si počkej – nakonec bude téměř všechno v podobě end-to-end toolstacku a pravděpodobně přijde vendor, který ti to nasadí.

Co si myslím, že teď bude velmi zajímavé, je umožnit LLM interakci s okolním světem – přechod do agentního světa. Agent není jenom to, že něco jede uvnitř smyčky, ale znamená to mít senzory, tedy schopnost komunikovat s okolím, a zároveň mít akce, které umožňují do okolí zasahovat. V korporátním prostředí to může být komplikované – znám to sám, často jde o nějaké sub-systémy, integrace a spousta komplikovaných cest, to bývá peklo.

Když to shrnu – možnost „vyplnit sešit“ (například sešťák) automaticky – to by bylo skvělé. Za mě, pokud nechceš řešit přesnost nad 90 % a tvůj use case je trochu složitější, nemá smysl to vyvíjet od nuly. Postavíš to jako z kostiček lega. V jakémkoli cloudu je na to dnes spousta vendorů.

Co je teď pro mě zajímavé, jsou MCP servery. Když přišlo OpenAI s THD a function cally, teď i tool cally, tak jsme začali psát řešení. Myslím, že budoucnost bude taková, že hodně aplikací – jak v korporátech, tak jinde – bude mít MCP server jako součást architektury. Momentálně si ty MCP servery musíme psát sami. Máme aplikace (například Elin nebo interní korporátní aplikace) a k nim napíšeme MCP server. Antropic přišel s protokolem, který LLM říká, že jsou dostupné nějaké nástroje, které si může zavolat, což znamená, že může „tahat za táhla“ a zároveň může provádět akce.

Dříve jsme museli LLM explicitně říct, že existuje nějaký tool, který například vrací aktuální počasí nebo v případě Elin poskytuje aktuální data. Když LLM vyhodnotilo, že informace potřebuje, museli jsme vykonat tento krok a získat data ručně.

Pokud chceš, můžu ti s tímhle textem ještě dál pomoci, přepsat ho víc formálně, rozdělit do odstavců nebo upravit styl dle účelu. Stačí říct!

Opravený text:

Z těch informací. Ten MCP server neznamená, že to tam nepíšeš, ale když je tam LLM-ko, tak spolu komunikují a ono to zavolá. V tomhle případě, pokud lidé chtějí integrovat, tak se objevují MCP servery, které řeší PostgreSQL databáze a tak dále, ale pořád je to o tom, že si to nějak musíš napsat, dát tomu trošku víc sádla. A za nějakou dobu se to zase stane komoditou. Zase MCP server API pro LLM-ko? Spíš ani ne tak MCP server pro LLM-ko, ale spíš že automaticky, když budeš dělat aplikaci, ať už in-house, nebo to pro tebe bude dělat někdo jiný, tak přibudou MCP servery. To znamená, že LLM-ko u tebe doma bude schopné interagovat s tvojí aplikací. Vyplněno, dovoleno, cokoliv. A myslím si, že tímhle směrem to dost směřuje.

V některých firmách se to už opravdu řeší – ty otázky… Prostě oni si prošli tím, že byli na špici integrace RAGu, spoustu věcí si psali, ať už to bylo Alien, nebo historické O2. A teď jsou o krok dále. To znamená, ty firmy nebo subjekty, které čekají na to, že to bude komodita, jsou teď na úrovni toho RAGu. A firmy, které byly na začátku opravdu na špici, teď řeší další věci. A tak to je, jo? Ze všeho se dřív nebo později stane komodita, jo? Myslím si, že teď se vyplatí psát především agentní logiku. Jo? Můžeš ji řešit v Langrafu, ale opravdu musí být specifická pro daný use case. Ano, specifická pro use case. Asi se z toho vydestilují některé scénáře, které architektury agentního přístupu dávají smysl na konkrétní použití, ale teď je to trošku víc exploratorní, objevování.

Takže v tuto chvíli se má psát, pokud chceš být na špici. Pokud to teď řešíš jako jinou věc, tak chvíli počkej, zase se to stane komoditou, jo? Stejně jako s kontextovým oknem. Přesně tak. Zase to bude, že… Hodně se řeší „loukou“, no kde vlastně… Já říkám obecně – nejenom v Elin, ale obecně, když mluvím o tom, že někdo by chtěl sám nebo i ve firmě integrovat LLM-ko, tak nejdůležitější je smazat bariéry, jo? Vlastně to, co přineslo GPT. Pro komunitu to nebylo zjevení z nebe, ale to, co přineslo GPT, bylo to, že kdokoliv mohl velmi jednoduše integrovat ten model, jo? Ten nejnovější, nejdražší, nejlepší model. Ano. A jednoduše, maximálně nulová bariéra, dokonce ani se nemuselo vytvářet konto. Proto to všichni chytli, zároveň to dělalo úžasné věci. A teď, když chce někdo integrovat GPT do svého produktu nebo do firmy, musí začít odmazávat tyto bariéry, jo? Neřešme teď nějaké bezpečnostní oprávnění, ale ať je to jednoduché nakliknutí a tím pádem se to stane komoditou.

Jo. Když mluvím o agentech, Satya Nadella řekl, že letošní rok je rokem agentů, protože se začínají objevovat agenti. Tak teď v tuhle chvíli…

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

Jasně, tady je opravený text:

Existují frameworky, které ti dovolí dělat trochu low-code nebo no-code řešení, ale pořád to ještě není úplně ideální. Často je lepší si to začít psát třeba v Langrafu sám. Ne nutně psát celý framework pro agenty, protože je pravda, že to udělá někdo lépe za tebe – třeba kluci v Indii nebo v Číně, protože jsou v tom často rychlejší než my tady. Dokážou to rychleji vymyslet, ale je to dobré.

Jak agenti interagují mezi sebou, to si zatím píšeš sám. Google představil koncept „Agents to Agent“, ale teprve se staví standardy. To znamená, pokud řešíš problém, na který ještě není standard, musíš si to napsat sám. Ale dřív nebo později se to zrychlí a někdo to vyřeší za tebe. Nebude to pro tebe ztracená investice, protože se spoustu věcí naučíš a jakmile přijde hotové řešení, můžeš opustit svoje vlastní a věnovat se dalším krokům, tedy skutečně překonat hranici mezi agenty, což je dlouhodobý zápas.

Někdo mě požádal, abych si připravil nějakou finální zprávu nebo sdělení, co by si z toho lidi měli vzít. A já jsem nad tím přemýšlel a říkal si, že to hlavní je – začněte to používat! Začněte si s tím hrát, ať už jako jednotlivci nebo firmy, a zjistěte, kde a jak to funguje. V tu chvíli vám přijdou nápady a příležitosti, jak to využít. A hned pak přijde otázka, jestli už na to existuje nástroj, který můžete snadno integrovat.

Skvělým příkladem je Open Web UI, open source projekt, který vznikl s Olami – Olama umožňuje hostovat modely lokálně, a k tomu dali frontend. Dřív se to jmenovalo Olama Web UI, teď už to je pod značkou Open Web UI. Je tam spousta vyřešených věcí – individuální přístup pro jednotlivce a tak dále. Když se mě někdo ptal, jak ve firmě snadno zpřístupnit modely zaměstnancům, umožnit jim hledat v dokumentech nebo generovat obrázky, říkal jsem, že si to buď může napsat sám, nebo použít Open Web UI, který to všechno umí: chatování, historii, rychlý RAG (retrieval-augmented generation) a spoustu dalších věcí.

Tedy už to někdo vyřešil. Jakmile začneš s tím hrát a přicházejí ti nové nápady, dojdeš do bodu, kdy se ptáš: je už na to nástroj, nebo to musím napsat? A dřív nebo později na daný problém nástroj bude, lepší nebo horší. Vždycky budou minimálně dva nástroje na jedno řešení. Pak je otázka, jestli je teď ten pravý čas do toho jít a psát si to sám, nebo jestli počkat. Není pravidlo, hodně záleží na tvé situaci.

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

Jasně, tady je opravený a plynulejší text:

Ale to je prostě tak, začne to používat, začne nám to odpadat, Rieri, proto, aby lidi, kreativní lidi u tebe, rodina, jo? Já mám furt na talíři, kdy moje partnerka… já jsem se jí ptal, co dělám, začal jsem jí něco říkat, a to už je třeba tak dva roky. A začal jsem jí říkat… Ne, ne, ne, ne, já jsem řekl, že to je GPT. A ona se zeptala: „Co to je?“ Řekl jsem jí: „Jo, to jde totálně mimo tebe, jo?“ Od té doby to mám teda stále před očima, že jsem něco takového řekl.

Nicméně ona se toho trošku chytila, začala to používat, a teď zjišťuje, na co všechno to může použít. A to je prostě netechnický člověk, jo? Biznisovej, a ráda zapne a vypne počítač, jo? Ale prostě si hraje s tím modelem a zjišťuje, co všechno to umí, a pak přichází na to, co všechno by se s tím dalo řešit. A vlastně potom je to o tom. Já souhlasím, že stále vidím velký rozdíl mezi tím, použít GPT, co všechno umí, a nasadit to do firmy. A myslím, že naše dnešní povídání a tvoje know-how ukazují, že mezi tím, že mi to v produktu odpovídá na e-maily, a tím skutečně nasadit to do firmy, je obrovská práce.

Jé, no. Já jsem velmi vděčný, že jsi poodkryl tu práci a ty zkušenosti, co s tím máš, a chtěl jsem ti za to poděkovat. Taky jsem chtěl poděkovat za to, že u LN.AI jste opět o krok napřed a že z toho postupně vzniká komodita, ale vy do toho šlapete a sdílíte know-how. A chtěl jsem poděkovat hlavně za to, že to hlavní know-how, to poslední, co se z toho stane komoditou, je…

vaše specializace. Ta specializace na duševní zdraví, na to, jak být sám se sebou rád, a ideálně na to, jak pomoci v krizi duševního zdraví u mladých lidí. Za to jsem velmi vděčný a jsem rád, že své zkušenosti a know-how využíváte a budete využívat tímto směrem. Držím moc palce.

Já moc děkuju, moc děkujeme, že jste doposlouchali až sem. A díky taky našim partnerům a členům Data Talk klubu. Těmi jsou: Intex, Saska, Bystreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, DataMind, Notino a Flo.

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

Pokud chceš, mohu text ještě více upravit do formálního stylu nebo naopak zachovat více hovorový tón.