Podcast

Dobrý den, moje jméno je Jirka Vicherek.
Ahoj, tady Karol Šmánek. A vítáme vás u dalšího dílu Datatolku. Dneska tady máme Honzu alias Johnnyho Gamce z H2O AI.
Ahoj Honzo.
Ahoj chlapi.

Johnny působí tady v Praze v pobočce H2O AI jako lead software engineer a má za sebou hned několik flagship produktů téhle firmy. Začněme na začátku. Jak ses ty dostal do světa machine learningu a AI a posléze do H2O?

Tak samozřejmě asi jako většina, začal jsem v útlém věku s počítači, ale k samotnému AI a machine learningu jsem se dostal asi jako patnáctiletý až šestnáctiletý, když jsem měl možnost začít brigádovat na univerzitě v Košicích, v laboratoři umělé inteligence u profesora Petra Svinčáka. Vlastně tam jsem měl první možnost vyzkoušet si nějaké AI algoritmy, pracovat s roboty a další věci jako samotný software engineering.

Takže začal jsi v patnácti až šestnácti jako brigádník na univerzitě?

Ano, začal jsem samozřejmě s programováním ještě dříve, řekněme osm až devět let. Moji rodiče oba působili na univerzitě, takže ty možnosti jsem měl. Začínal jsem s tvorbou webových stránek a v patnácti až šestnácti jsem už nějak uměl Python a JavaScript, takže jsem začal dělat nějaké malé věci a učil se.

Co to bylo za rok, když ti bylo patnáct až šestnáct, abychom to přiblížili posluchačům?

To je těžká matematika, myslím, že to mohlo být někdy kolem roku 2008 nebo 2009. Já si vzpomínám, že když mi bylo patnáct až šestnáct, Python podle mě ještě nebyl tak rozšířený, možná ani neexistoval?

Pro mě Python neexistoval velmi dlouho a když si vzpomenu na to, co jsem dělal v patnácti až šestnácti, rozhodně to nebylo nic, co by výrazně podpořilo mou budoucí kariéru.

Takže je ti šestnáct, děláš na univerzitě v Košicích Python a v laboratoři AI, to začínáme dobře.

Ano, tam jsem pokračoval, to byly v podstatě nějaké letní brigády, přičemž po školním roce jsem tam chodil pomáhat po škole. Potom jsem samozřejmě začal studovat obor umělá inteligence. Tak nějak plynule jsem pak přešel z Košic do Prahy, kde jsem skončil na otevřené informatice, což byl vlastně pododbor umělé inteligence.

Potom si mě objevilo vlastně H2O AI. Mimochodem jsem samozřejmě měl ještě jiné práce v oboru, ale H2O AI bylo v podstatě asi to nejvýznamnější. Primárně zaměřené právě na umělou inteligenci, takže to jsou moje začátky.

Když jsi říkal, že jsi tam jako patnáctiletý dělal nějaké roboty, předpokládám dvakrát roboty jako sledování čáry a podobné věci, to jsou klasické začátky. A pak jsi šel na FEL na ČVUT, jak jsi říkal, na tu kybernetiku?

Ne, tam je vlastně obor otevřená informatika a tam byl právě pododbor umělé inteligence.

A když tě přijímali do H2O AI, už jsi firmu znal? To je který rok? A už to byl takový brand, jaký je dnes?

To byl rok 2017. Přiznám se, že firmu jsem zcela neznal, nikdy jsem ji úplně detailně nestudoval. Ale samozřejmě jsem si ji vygooglil. Byl to startup ze Silicon Valley, což pro čerstvého absolventa bylo velmi zajímavé, takže jsem kývl na nabídku. Náš CEO Shree v tom čase přijel do Prahy a já jsem dostal zprávu, jestli mám čas. Potkali jsme se v hotelu Hilton na Florenci a asi za půl hodiny jsme byli dohodnuti, takže to bylo velmi rychlé.

Tehdy už bylo H2O v Praze?

Ne, H2O tehdy v Praze ještě nebylo, ale myslím, že CEO a vedení firmy už nějakou dobu uvažovali o tom, že by mohli v Praze otevřít pobočku. Historicky měli velmi dobré zkušenosti s Čechy a Slováky ve firmě. Dodnes náš VP of Engineering je Čech a v Silicon Valley působí několik Čechů a Čechoslováků. Takže bylo jasné, že Praha by mohla být významným místem. Když mě oslovili, možná to bylo první známkou plánu otevřít tu pobočku.

Když se teď vrátíme zpátky k H2O jako takovému, máš informace, jak dlouho v té době už firma existovala a kolik lidí tam pracovalo?

Ano, byl jsem 65. zaměstnancem H2O, firma vznikla koncem roku 2011 a na přelomu roku 2017–2018 otevřeli pobočku v Praze, kde nás bylo asi pět až šest lidí. Byl to takový regulérní tým.

Prvotní záměr byl otevřít tady novou business line, nebo spíš zajistit engineering, který jsi měl vést, nebo být jeden z tým?

Nešlo o hierarchii, spíš šlo o nábor co nejvíce talentů místních lidí. V té době šlo hlavně o inženýring, ale nakonec se tým rozrostl i o pre-sales a post-sales, takže Praha je centrem H2O pro celý region, pro Evropu.

Když teď uděláme rychlý skok do současnosti, pobočka je celkem významná, můžete o ní něco říct?

Jasně. V současnosti má pobočka asi 30 lidí. H2O má filozofii distribuovanosti po celém světě, takže nikdy nešlo o jeden velký hub, ale v Evropě máme lidi na Slovensku, v Polsku, Rakousku, Anglii atd. Pobočka v Praze je největší, máme přidružené oblasti, chlapi jezdí párkrát do roka na setkání a organizujeme engineering meetupy a podobně.

Na čem jsi začínal pracovat? Co byl tvůj první job?

Můj první job byl v tom čase v podstatě flexibilní produkt, tedy to, s čím H2O začalo a na co získali investice, jejich open source H2O 3. H2O 3 byla v té době inovativní technologie, kdy hodně frčely Big Data a distribuované počítání. H2O mělo know-how, jak to dělat. Měli vlastní implementaci algoritmů a vrstvu řízení dat. Do roku 2017 byla tato část hlavní součástí H2O.

Když jsi přišel, už začínal projekt Driverless AI?

Ano, já jsem nastoupil na open source, ale po asi třech týdnech mě povolali na nový projekt Driverless AI. V té době byla možná verze 0.5.0. Od té doby jsem pracoval primárně na Driverless AI.

Než úplně opustíme open source, chápu, že pro tebe už není tak aktuální. V té době, kdy Big Data frčely, bylo to vlastně jako menší knihovna, která měla distribuovaný machine learning výpočty?

Ano, open source se zaměřoval na Big Data a měl několik variant. H2O 3 se také kombinovalo se Sparkem. Běželo to na MapReduce.

Jak jsi se adaptoval na to programování? Já chápu, že pro některé standardní výpočty je to něco, na co si zvykneš, ale machine learningové úlohy se často těžko převádějí.

Začátek byl těžký. Byl jsem více zaměřený na Python než na Java stack, v jakém byl open source. Byl to kulturní šok, ale pomohli mi kolegové, například Michal Kurka a další Češi v Silicon Valley, díky kterým jsem se do toho dostal. Na začátku jsem dělával jednoduché histogramy nebo binning, ne pokročilé gradient boosting metody.

Když už jsi tam byl, byla firma stále startup? Měl jsi příležitost se zapojit do pilotních projektů pro klienty?

Ano, zákazníci, například Booking s velkými daty, banky nebo pojišťovny, byli pro mě inspirací. Zejména Booking měl obrovské servery na moři a skutečně potřeboval s daty pracovat. Protože jsem byl někde na začátku, větší zákazníci byli nad mé schopnosti, ale bylo vidět, že je potřeba řešit velká data.

Jaká byla a je firemní strategie H2O vůči open source? Měl jsem pocit, že enterprise řešení má část open source a část managed.

Open source byl vždy integrální součástí H2O od úplného začátku a na jeho základě získávali finance. Ta mise firmy je demokratizace AI – tedy snažit se dostat AI technologie a algoritmy do firem, které nemají peníze na velké datové týmy nebo nemají know-how. ΅ H2O se snaží pomáhat praktickými algoritmy, jako je H2O 3, nebo automatizovanými řešeními, jako je Driverless AI, až po cloudové platformy s frameworkem Wave pro tvorbu webových aplikací řešících například know your customer, rozpoznávání obrazu nebo předpovědi časových řad.

Proč je to H2O 3? Je to třetí verze systému? Nebo chemický název?

H2O 3 je opravdu třetí verze. Byl čas, kdy byla verze H2O 1 a 2. Název H2O odkazuje na vodu, která je základem života všude – analogie pro AI produkty, které chtěli vytvořit jako základní prvek.

Pojďme k Driverless AI pro posluchače, kteří to slyší poprvé. Kam to v technologickém stohu zařadíš? Jak to vzniklo?

Driverless AI byl kompletně nový přístup, jak zcela přepsat dosavadní systémy. H2O úzce spolupracovalo s akademiky a lidmi z oblasti výzkumu machine learningu. Už v roce 2016 měli mezi sebou několik Kaggle Grandmasterů, například Dmitry Larko.

V té době Kaggle ještě nebyl takový, jako dnes, soutěže se více zaměřovaly na tabulková data, a každý Grandmaster měl své know-how a pracovní postupy. Potkali jsme většinu z nich v H2O, někteří tam stále jsou. Každý měl své metody – modely, triky v feature engineeringu nebo způsoby, jak kombinovat modely. Dmitry měl také své finty, díky kterým vyhrával soutěže.

Asi si jednou řekl, že to musím nějak automatizovat, když dělám pořád to samé. Pomocí genetického algoritmu zautomatizoval feature engineering a tak vznikla první verze Driverless AI.

Bylo to v USA, když Driverless vznikal?

Ano, Driverless AI začal vznikat v roce 2017 v Kalifornii, kde Dmitry žije. Já jsem nastoupil, když už měl tým funkční dashboard, ale byl to projekt ve fázi před první verzí. Byl jsem tam od úplného začátku a postupně na něm pracoval.

To mi hodně evokuje náš díl s Martinem Hroncem z Albertu, který říkal, že před ním tam byl Kaggle Grandmaster z Ruska. Nemůže to být ten samý člověk?

Ne, Dmitry je už dlouho v Americe. Albert ho asi moc nezajímá, ale nevím.

Co je tou „tajnou ingrediencí“ Driverless AI? Jaký byl unikátní přístup?

Nemyslím si, že to byla jedna věc. Driverless AI chce být jako Kaggle Grandmaster v krabici pro koncového uživatele. UI a produkt řeší celý proces end-to-end – zákazník nahraje data a dostane hotovou předpověď, kterou může nasadit do produkce. Tajemství Grandmasterů s jejich nuancemi a optimalizacemi algoritmů jsou zabaleny do automatizovaného systému, který zvládne řešit komplexní problémy rychle a kvalitně.

Feature engineering, to know-how, řekněme, hyperparameter tuningu a zároveň možná hledání té nejlepší optimalizační funkce pro trénink a tak dále. A vlastně celý Driverless AI byl koncipován, a je koncipován stále jako produkt založený na takzvaných receptech, kde nejen naši interní vývojáři a přispěvatelé, ale také externí uživatelé si mohou napsat vlastní recept – ať už na datové transformace, které provádějí feature engineering, nové typy modelů, nové typy scorerů, metrik, fitness funkcí či jak to chceme nazvat.

A vlastně ten Driverless, ten hnací motor, je stále genetický algoritmus, který se chytrým způsobem snaží najít tu nejlepší kombinaci. Když v datech existuje signál, tak prostě najít tu kombinaci, která signál vyextrahuje a snažit se ho co nejlépe namodelovat. Což je zdařilé?

Protože já možná trošku operuji s Jirkou. Jirka říkal, že Kaggle byl vždy řešením neřešitelných problémů, až jsem to vnímal spíš tak, že kdo tam dosáhne větší úspěšnosti. A ten „secret sauce“ byl opravdu správně namíchat ty fíčury, namíchat modely a pak samozřejmě ty hyperparametry.

A teď vlastně moje otázka, abych to nezakecal: když Driverless AI vznikal, protože jsi říkal, že on vlastně pomocí genetických algoritmů se snažil kombinovat fíčury nějakým způsobem – znamená to, že to bylo to stěžejní? Nešlo ani tak o modely nebo parametry a tak? Já předpokládám, že to taky trochu bylo, ale předpokládám, že to stěžejní bylo alespoň z počátku tohle.

Určitě, určitě. Aspoň co si pamatuji, tak v podstatě ti Grand Masteri mali všechny druhy encodingu a nevím, při timeseries datech zase jiné druhy transformací. My jsme začali dělat time series bez použití neuronových sítí a používali jsme XGBoost a LightGBM a podobně, takže feature engineering byl velmi důležitý. Souhlasím s tím, co říkáš, že co se týká Kaggle, opravdu šlo o ten poslední bod, třeba ta desetina procenta.

Přesně tak, přesně tak. Ale myslím si, že to je věc, která se začala v Kaggle měnit. Ze začátku to možná nebylo nutné, a pak se za roky stalo vysloveně honěním se za desetinami procent, takže ano.

A když se vrátíš k tomu, jak teď produkt vypadá, co si vlastně, když vezmu nějaký úplně triviální případ, třeba chci fitovat nějaký klasifikátor, jednoduchý binární klasifikátor nebo časovou řadu. Co si pod tím Driverless AI teď představit? Co za mě na pozadí udělá? Když pomineme to, co už jsme říkali, že jsou to fíčury.

Jasně. Jak jsem říkal, Driverless AI se snaží řešit problém opravdu end-to-end. Prostě vezme data a prvním krokem je pochopení těch dat. Driverless AI je určený pro uživatele, kteří jsou nějakým způsobem znalí, ne úplně kdokoliv, ale nemusí být extrémní experti na data.

Driverless obsahuje různé moduly, například modul AutoViz, který se zaměřuje na automatické vysvětlení toho, co se v datech nachází, a především identifikuje možné problémy, odchylky a zároveň doporučuje, jak tyto problémy mohou být řešeny či opraveny.

Pokud se bavíme o outliers, či šikmosti dat, anebo jiných škodlivých statistických prvcích – je to taková diagnostika.

Přesně tak, přesně tak. Navíc to také vizualizuje. Poté může následovat samotné modelování, které probíhá iterativním procesem. Není to tak, že nejdříve uděláme feature engineering a pak modelování, ale feature engineering je úzce propojen s výběrem modelu, který funguje na dané feature, a dále s hyperparameter tuningem, což opět závisí na typu modelu.

Celý proces je provázán v několika krocích. Výsledkem je ohromné množství kombinací a genetický algoritmus tam je právě proto, aby navigoval v tomto rozsáhlém prostoru a hledal nějaké suboptimální řešení.

Jaká je potom složitost toho algoritmu? Protože když to vezmu extrémně pro naše posluchače, tolik možných feature parametrů krát tolik modelů krát tolik parametrů – to je opravdu šílenství. Předpokládám, že genetické algoritmy jsou použity k omezení stavového prostoru, nebo jeho obejití?

Ne, nemyslím si, že jde o klasický spočitatelný nebo běžně řešitelný problém. Samozřejmě děláme best effort. Proces je iterativní, člověk ho pustí a čeká, co se stane.

Experimentálně se dá říct, že na většinu problémů, pokud v datech je signál, tak řešení funguje relativně dobře. Když tam signál není, nebo je zašuměný, typickým problémem je, že data jsou koncipována jako tabulka, ale ve skutečnosti jde o time series problém.

Například mám tabulku s platbami za měsíc 1, měsíc 2, 3, 4 a chci klasifikovat nějakou třídu. Tento problém lze transformovat na časovou řadu, a pak algoritmus na time series může pracovat lépe. Najít podobné transformace není vždy jednoduché, a navíc někdy je nutná doménová znalost, která nemusí být…

Ale právě na to jsou recepty – často obsahují doménové znalosti. A co vím, tak dnes existují konkurenční produkty, které v době, kdy jsme my vznikali, pravděpodobně neexistovaly, teď je tam například voting. To znamená, že když predikuješ časovou řadu, většinou nejlépe fungují kombinace třeba gradient boostingu s úplně odlišným jednoduchým modelem.

Nebo třeba kombinace Prophetu a gradient boostingu i přesto, že jednotlivé modely samostatně měly slabý výsledek, dohromady vycházely dobře. To je podle mě to nejsilnější na autoML – ten voting mechanismus na konci. Máte to taky?

Nenazval bych to votingem, od začátku jsme dělali ensembling.

To jsem myslel. Měli jsme nějaké know-how, jak to dělat. Jeden z těch Grand Masterů přišel s technikou, kterou nazval Stagnet.

Ensemble funguje tak, že se vyberou modely, anebo se black-listují modely, které nechci nasadit, pokud mám o nich znalost. Driver se ale snaží fungovat „out of the box“, takže se snaží najít optimální parametry sám.

Výstupem je to, čemu říkáme scoring pipeline, což může být spustitelný fragment kódu, který lze embedovat někam, anebo i hostované řešení, které lze nasadit třeba na AVS a lze s ním pracovat dál.

Máte i neuronové sítě, protože problém byl relativně náročný na výpočet, a když přidáš parametry neuronových sítí, řešení se ještě zkomplikuje?

Ano, určitě. Používáme PyTorch a TensorFlow, protože máme modul i na zpracování obrázků, například rozpoznávání obrazu.

To tam je. Navíc máme něco i na reinforcement learning.

Takže odpovídáš, že to není pouze tabulární problém?

Ne, rozhodně ne. Vývoj postupoval v čase, neuronové sítě nebyly od začátku, ale sledovat trendy bylo a je nutností, zejména u obrázků, zvuku a podobně.

A kdo to používá? Data scientisti? Nebo týmy, které data scientisty nemají? Něco mezi tím? Velké firmy, jaké problémy? Kde bych to našel na trhu?

Výborná otázka, na kterou nemám jednoznačnou odpověď. Myslím si, že se to používá zcela různě a uživatelé si najdou svůj způsob použití.

Může se otevřít kontroverze ohledně celého AutoML a jeho použití.

To čekám, že mne na to Jirka znovu nakopne. Jirka mě drží na uzdě.

Řekl bych, že pro neznalého uživatele, často business usera, ten produkt může fungovat end-to-end. Mám problém predikce salesu nebo potřebu nalézt vhodný nákup surovin, aby se pokryl poptávkový objem.

Produkt vyprodukuje pipeline, která funguje end-to-end.

Pro zkušeného data scientista to může být velmi solidní baseline v modelování.

Máme dokonce vtipnou příhodu s juniorským data scientistou ve Španělsku, který nastoupil do firmy a používal Driverless AI trial verzi pod tajemstvím.

Po pár měsících byl povýšen na seniora, protože jeho modely a řešení byla skvělá.

Později se zjistilo, že používal Driverless AI a díval se na feature engineering, trochu si ladil řešení a splnil cíle.

Ví se, jak to s ním dopadlo? Byli povýšeni? Koupili Driverless?

Myslím, že ano. Myslím, že firma Driverless používala, nevím, jak je to nyní, ale byla to jedna z úspěšných příběhů.

Takže to byla taková vtipná historka. Dobře, tak tě pouštím z řetězu.

Jaké je spojení Driverless AI a AutoML? Z laického pohledu je H2O AI synonymem AutoML. Bylo to jedno z řešení, když se mluvilo o AutoML, Out of the Box, baseliningu a sahalo se po H2O.

Co je AutoML, jaké má spojení s Driverless AI a jaký smysl má v rámci H2O?

Nechci použít silné termíny, ale Driverless AI je AutoML.

AutoML má samozřejmě počátky, vlastně už před Driverless AI vznikla potřeba najít správnou kombinaci parametrů a tvorba feature.

Existovaly předchůdci AutoML v podobě gridsearchů a poloprofesionálních řešení pro hledání parametrů.

Myslím, že Driverless AI to posunul na úplně novou úroveň, byl v oblasti pioniérem.

Přidal feature engineering, nikoliv jen výběr parametrů, ale i hledání modelu samotného, hyperparameter tuning, ale i metaréžii hledání architektury neuronových sítí, které zajistí nejlepší výsledek.

Samozřejmě vede k extrémně sofistikovanému, často nečitelnému výsledku, a proto jsme se zaměřili na vysvětlitelnost.

Velká část našich zákazníků jsou regulované sektory, jako banky, pojišťovny a jiné finanční organizace, které požadují záruky, takže jsme vyvinuli modul MLI (Machine Learning Interpretability).

Tam jsou automatizované algoritmy, které snaží ten složitý model vysvětlit a poskytnout důkazy o jeho fungování.

Než se dostaneme k vysvětlitelnosti, Karle, jak ty používáš AutoML?

Já to používám vždycky jako vtipnou historii na konferencích.

Pamatuji si, když jsem poprvé viděl H2O jako open source. V té době byl Cloudera Spark MLlib dostupný jen se čtyřmi algoritmy – regresí, SVM, základy, a to bylo vše.

Říkal jsem si, H2O je super, nádherná knihovna, která nabízí zdarma dalších dvacet algoritmů. Paráda.

Pak jsem narazil přesně na Driverless AI u několika klientů.

V té době jsem byl stále data scientist, který rád sám tvořil fíčury, věnoval půl dne na zajištění datové kvality.

Říkal jsem si, že Driverless AI je pro blbce, nebudu to používat.

Po pěti, šesti letech jsem si říkal, že to možná jo, ale občas jsem opravdu strávil i pět až šest dní jen hledáním baseline modelů.

Často jsem zjistil, že v datech neexistuje korelace ani kauzalita.

Strávil jsem tak zbytečně tolik času.

To se tu už řešilo – baseline model by měl být rychlý, u časových řad dát naivní odhad z minulého období, a když nedokážeš dát lepší, možná to ani nepoužívej.

AutoML mi poskytne rychlý a kvalitní baseline model.

Viděl jsem, že často je to 50 na 50, jestli výsledek z AutoML bude dobrý, ale někdy je to jasný směr.

Pak si to vezmu a snažím se to dotunit – nemusím být lepší než nějaký GrandMaster.

Často se mi ani to nepovede.

Takže dávám tomu za pravdu.

Jediné, co mi na AutoML vadilo, byla determinističnost.

Pokud to pustíš na jiných datech, nevyjdou ti stejné hyperparametry ani modely.

To může způsobit problémy v nasazení, protože se používají nové knihovny, může to padat, SLA a odezvy mohou být jiné.

A pak jsem…

[Text končí zde]

Nasazení, s tím jako vlastně fakt to souhlasí, když to dáš nějakému APIčku a podobně.

Než to projde skrz Ensemble 20 modelů, tak to nebudou milivteřiny, ale budou to třeba sekundy. Je to tak, je to tak. Jsou zde problémy, které také ten driver se snaží do určité míry řešit. Například ten deployment konkrétně. Ten driver, možná se vrátíme ještě k tomu, co jsem dělal já sám v tom driveru, tak já jsem začal primárně jako full stack a dělal jsem backend a frontend z velké části a ten frontend byl, myslím si, že na tu dobu extrémně sci-fi a extrémně inovativní, nebo prostě byl fakt jiný než cokoli jiné. Když někdo měl možnost vidět driverless, snad bude souhlasit. No a celé to UI toho nastavení modelu se v podstatě odvíjelo od vlastně takových tří koleček, která se nastavují. A tady byla prostě přesnost (accuracy), čas nebo tedy náročnost na výpočet a interpretabilita. A s tím vlastně potom souvisela přesně ta složitost toho modelového výsledku. Když jsem potřeboval něco rychlé, tak jsem musel kompenzovat, řekněme, tyto tři veličiny.

Já v tom vidím strašně, ale promiň, já už v tom vidím takový alibizmus, že prostě si říkáš sakra, to stavové prostředí je strašně těžké, jak to zjednodušit, tak to dáme kolečka. Samozřejmě je to i fíčura, že? Ano, ano, záleží, jak se na to člověk dívá. Já v tom vidím ten projektový trojhran, jak můžete tady – rychle, kvalitně, levně, vyber si dva – tak to asi nejde dokonale rychle a levně udělat. Je to tak, je to přesně tak.

A co se týká spolehlivosti, nebo možná predeterminizmu výsledného řešení, opravdu to není až tak spolehlivé. Prostě jsou problémy, na které to nemůže úplně fungovat. Jak jsem zmínil předtím, prostě možná tam v datech něco chybí, co ten stroj prostě nemá, já už to rozpoznám, ale třeba člověk nějakým logickým myšlením to rozpozná. Na druhou stranu často to funguje extrémně dobře. Máme případy pár kegl soutěží, kde ten driverless prostě docela drsným způsobem porazil konkurenci a prostě se dostal do pásma těch zlatých medailí.

Máte tam nějakého robota, který kouká na to, kdy bude nový kegl challenge a pod H2O profilem to tam rovnou hází? Nesmí. Bylo to vysloveně zakázané, protože vznikl možná i takový střet mezi Googlem a H2O, kdy Google měl dedikovaný tým, který vlastnil a má stále ten Vortex a vlastní AutoML, který se soustředil na to, že když koupili Kegl, aby začali vyhrávat soutěže, tak se řeklo, že s roboty se nebude soutěžit, takže smůla, nesmí se to používat. Takže pořád tradiční šachy.

Ano, ano. Mě možná ještě zajímá jiná téma. My jsme se toho lehce dotkli. To znamená, teď máme model, který je prostě super, vyhrává Kegl challenge, a jak s ním vlastně potom do produkce? A tím myslím všechny ty aspekty – jak vlastně dostat třeba i kód, který je zatím, abys to mohl nasadit, případně upravit a tak dále? Máte třeba nějaké repozitáře, kam si ty modely můžete verzovat, prostě sledovat výsledky, něco jako MLflow v tomto smyslu, registry vlastně, nějakou orchestraci workflow toho modelu, servování?

Máme, máme. Ano, do značné míry je to trochu taková králičí nora, jak H2O. H2O má opravdu obrovský rozsah věcí, které dělá. Jedna z nich je například MLOps. A samozřejmě, jak by to byznys vyžadoval, potřeboval mít odpověď na nějaký MLflow nebo manažment modelů, takže máme MLOps, který řeší samotný deployment, dokonce i monitoring, detekci driftu a takové věci jsou tam. Takže určitě ano. A co se týká samotného kódu, tak Driverless umí vyprodukovat nějaký kód, který se dá použít v notebooku a člověk si může vyzkoušet nějaké produkty toho feature engineeringu a co Driverless dělá, ale samozřejmě nevypustí celé hotové řešení, to je nějaké know-how. Ale máme v podstatě formát, asi bych to nazval, nebo způsob, jakým přenášíme ty modely, jmenuje se to Mojo. Je to v podstatě pomocí nějakého protojazyka přesně popsána struktura těch transformací a modelů, které jsou použité. A ten se pak dá přenést, máme různé runtime, například C++, Java runtime a podobně, které se někde nasadí a vloží se do něj tento balíček.

Jak jsem říkal, architektura je založená na receptech, respektive máme to bring your own recipe a máme open source repozitář, kde je seznam většiny těch receptů, které jsou tam použité. Takže z velké části je to dost transparentní všude.

Když mluvíš o těch receptech, tak to mi zní jako platformizace, marketplace, takže tam dávají ostatní své recepty a já si pro ně mohu sáhnout. Je to open source, takže vlastně zase transparentnost a nějaká spolupráce na tom. A velkou část toho ještě tvoříte uvnitř?

To už jako tvoří komunita. To se povedlo rozjet, že je kolem toho taková komunita, že opravdu přispívají a vy jste opravdu jenom kurátoři?

Řekl bych, že ano. V podstatě, co se týká samotného modelování, ten produkt je hotový a věci, které se musí přidat interně, jsou možná nějaké složitější problémy. Když si nepamatuji, třeba bylo třeba řešit nějaké unsupervised learning, tak samozřejmě to vyžaduje větší architektonické změny v celém produktu, takže to se musí řešit interně. Ale když třeba někdo chce recept na to, aby uměl dělat feature engineering s nějakými časovými řadami, tak se to samozřejmě dá nechat komunitě.

A ještě poslední věc, mírně mě zajímá, jak už Jirka tady trochu naznačil, pro koho ten H2O je vlastně určený? Měli jste na mysli, že je to spíše pro lehce odbornější publikum, ale jak je to třeba designované i z pohledu modulů? Já si dokážu představit, že na trhu existuje spousta věcí, kde si člověk řekne, že by chtěl prodloužit finanční časovou řadu, dostane se k tomu byznysový člověk a řekne, že tohle je vstup, tohle je výstup, což v podstatě kopíruje i to vaše flow, jak jsem pochopil. Dá ten XXX finish, možná ho potkají nějaké nepříjemné technické otázky, na které on nebude schopný odpovědět. Pak mu to dá výstup.

A vy podle mě už nejste úplně daleko od toho, abyste byli schopni to dát těm byznysákům, kteří vlastně o machine learningu vůbec nic nevědí. Jak startujete vlastně v této chvíli?

Výborná otázka, a opravdu je to problém, který řešíme už hodně let. Dá se říct, že úplně od začátku, od toho open source, se řeší problém UX a jak vlastně ty extrémně sofistikované věci vysvětlit laikovi.

V Driverless samotném měl vždycky takový ten sci-fi look, kde jsme se snažili UX prvky uživatele navigovat, kam má kliknout, aby se dostal k dalšímu kroku a nakonec z toho něco vypadlo, co se dá použít. Zkoušeli jsme i koncept wizardů, nebo prostě nějako krokových průvodců. Na to máme dokonce open source řešení, například frameworky v Pythonu, kterými to děláme.

V podstatě šlo o to, že celý proces modelování jsme naplánovali jako formulář, například jako vyplnění daňového přiznání, kde na konci byl výstup.

A samozřejmě úplně nový přístup přišel s nástupem velkých jazykových modelů, které jsme velmi rychle načetli, avšak s tím souvisí nový pohled na uživatelské rozhraní.

Takže myslíš, že to vede k tomu, že ty jazykové modely používáte spíše jako „vehikl“, tedy další model, který máte uvnitř, anebo přesně tak, jak jsi naznačil, že pomocí textového rozhraní se snažíte zjednodušit ten interface?

Je to teď spíše ta druhá možnost. Textové rozhraní může sloužit jako pomocí nějakých agentních systémů a něčeho takového jako nové UI pro interakci laika s extrémně složitým modelem.

Tak jak si to mám představit? Mám si představit, že jsem finanční člověk, přijdu do chatu, tam prostě řeknu, chtěl bych tady prodloužit časovou řadu…

Přesně tak, toto jsou moje Excel tabulky a ono se mě možná zeptá na pár věcí. Většinou člověk řekne „nevím“, když neví, tak dá default a ono se to prostě naučí.

Přesně, a bude předpovídat tolik a tolik do budoucích měsíců. To je idea.

To je zajímavé. I přesto, že tam vidím jako takovou demokratizaci AI, já jsem H2O vnímal jako pro juniory a datové profesionály, kteří nejsou tolik zkušení v modelování a data science. A teď podle toho, co říkáš, se ta cílovka fakt rozšiřuje až na úplné byznysové uživatele, ne technické.

Je to tak, je to tak. Jak jsem říkal, ten cíl byl vždycky demokratizovat, takže řekněme v rámci open source a všech těch variací toho open source cílová skupina byla expertnej uživatel minimálně, kdežto na Driverless už úroveň trochu klesla a GenAI je zase ještě o úroveň níže.

Aha, já si to představím, takovou partu nadšenců, co se snaží vytvořit něco fakt skvělého, něco hodně silného, co dává skvělé výsledky, a pak je to strašně vzdálené od člověka, který to reálně použije, že ano.

To je samozřejmě tak, či tak obejít se to v praxi nedá.

A pak se postupně přibližuješ, přibližuješ, ale pořád nejsi úplně tam.

Ne, ne, myslím, že to je stále trochu vzdálené.

Já vidím toho manažera, co vyhodí celý svůj dataset, protože si naklikal lepší řešení než nad čím pracují dva měsíce v oddělení.

No ale tak GenAI – co pro vás znamenal GenAI?

Takže znamenal změnu UI a nějaký nový přístup po zpřístupnění produktu širší cílovce.

Co pro vás znamenalo z pohledu toho, co děláte, co se děje v data science a v těch problémech, které jste do určité míry řešili?

Třeba interoperabilita byla vždy velké téma – nemít AI jako black box, nebo machine learning jako black box, to do určité míry vyřešíš.

Ale teď přijde LLM a je to brutální black box – které z těch postupů se dají pořád replikovat v GenAI?

Je tam hodně otázek, zkusíme to postupně chronologicky odpovědět.

Samozřejmě rok 2023 je milník a byznys vyžadoval odpověď na otázku, co je LLM.

Začali jsme se tedy dívat na různé aplikace, které už máme, jak jsem zmínil, ale další věc je třeba práce s obrázky, kde máme také zkušenosti, a s dokumenty.

Tak vznikl náš nový vlajkový produkt, který se jmenuje AI Studio. Je to RAG, Retrieval Augmented Generation Tool, který je enterprise, není to open source, ale zaměřuje se na to, aby uživatel mohl extrahovat informace z libovolného typu dokumentů.

Druhá otázka byla právě na transparentnost těchto modelů, což vede k projektu, na kterém právě pracuji, jmenuje se Eval Studio.

Otázka transparentnosti je opravdu těžká, hlavně když mluvíme o chatbotech, kteří nemají žádná omezení a mají sloužit úplně na cokoli, tak ten problém je možná až neriešitelný.

Avšak dá se to nějak omezit a třeba v případě RAGu jsou omezení značná díky kolekci dokumentů, se kterými komunikuji.

A my i když někdy nevíme, jestli něco skutečně funguje spolehlivě, tak často víme s dost dobrou spolehlivostí říct, že něco vůbec nefunguje nebo něco funguje velmi podezřele.

Takže techniky z machine learningu, které jsme se naučili, se dají použít, můžeme mít například disparate impact analýzu, můžeme sledovat, jak je výstup citlivý na vstup.

Například napíšu větu a změním velikost písmen a zjistím, že model odpovídá úplně jinak – to je signál, že mám problém a musím se vrátit a začít ho řešit.

Nebo klasický problém LLM, totiž že model si vymýšlí, halucinuje, nebo doplňuje informace, které v daném kontextu nejsou.

Jasně, ale to jsou typicky batchové vyhodnocení – uděláš tranši dotazů, podíváš se na výsledky a vyhodnotíš, ale nejsi schopnej říct, jak přesná je každá konkrétní odpověď.

To samozřejmě ne, potřebuju zjistit, jak odpovídá, případně mohu sledovat pravděpodobnosti predikovaných tokenů a z toho něco usoudit.

Sledovat model pod lupou je těžké, ale má to vícero aspektů. Jedna věc je odpověď, druhá je u RAGu sledovat, jak vybírá informace z databáze relevantní k dotazu.

Nebo se můžu dívat, jak dobře systém naparzuje informace. Když chyba nastane už při OCR, při rozpoznávání, je to pro mě jako vývojáře, nebo uživatele, signál, s kterým můžu pracovat a nějak opravit výstup.

Říkal jsi, že RAG je čistě enterprise, placený produkt. A Eval Studio? Je to také enterprise?

Je. Předpokládám, že je to použitelné pro velké finanční instituce, globální klienty z Fortune 500, kteří si nemohou dovolit chyby.

Přesně tak. Eval Studio je hodně motivované oblastí risk managementu. Myslím, že i u nás brzy vstoupí v platnost nová legislativa ohledně AI. To samé platí v Americe. Této oblasti se začíná dostávat vysoká priorita.

A poskytovat důkazy a záruky o modelech je nezbytné pro uživatele a společnosti, které chtějí používat modely v produkci.

Jaká je tvoje role tam? Jak stavíš tak velký produkt od začátku? Jak moc používáš existující komponenty? Přepoužíváš kód? Začínáš na zelené louce?

Opět výborná otázka. Samozřejmě se nesnažíme vymýšlet teplou vodu, snažíme se ušetřit inovační úsilí tam, kde to jde, anebo se soustředit na zajímavé oblasti a techniky, jakým způsobem…

Může se dělat evaluace, přibývá opravdu mnoho dat. Když něco dává smysl a je dostatečně stabilní i pro produkci, protože vyvíjíme enterprise software, neděláme jen něco jako knihovnu pro komunitu, tak musíme sledovat kvalitu a snažíme se agregovat kvalitní zdroje. Začíná to ale asi jako každý jiný projekt. Na zelené louce máme nějaké know-how, co se týká – tedy já i můj tým máme určité know-how ohledně vývoje produktu a enterprise softwaru, takže si půjčujeme to, co jsme si už dříve vymysleli, a nějakým způsobem nám to dává startovací pozici.

Dostanete nějaké klienty? Jak moc do jejich procesu vidíte? Určitě. V tomto případě máme celkem štěstí, protože i u nás v H2O působí pár lidí, kteří v této oblasti strávili mnoho let například v bankovním sektoru v Americe, a ti mají kontakty. Samotné Eval Studio má velký dopad, nejen pokud jde o zákazníky; doslova o něm diskutujeme s lidmi, kteří provádějí risk management ve velkých bankách, ptáme se jich, ukázali nám, co a jak dělají, co je v pořádku, kde jsou hranice bezpečnosti, a snažíme se komunikovat a zjišťovat, co je nového.

Něco, co vás překvapilo nebo co jste se naučil? Co bychom mohli poradit lidem, kteří také staví produkty pro enterprise? Jak se ptát, co dělat první, co naopak byly slepé cesty? To je těžká otázka. Samozřejmě si myslím, že klíčové je poslouchat zákazníka, respektive když má člověk možnost hovořit s lidmi, kteří tu danou práci opravdu dělají, tedy skutečně vykonávají tu danou činnost, potom je čas s nimi strávený jako zlato. Současně si ale myslím, že během té cesty je často mnoho rozptýlení v tom smyslu, že existuje mnoho lidí na vysoké úrovni, kteří možná nemají úplně hands on zkušenost, ale přesto něco říkají. Někdy je potřeba to filtrovat a snažit se dostat k těm praktickým věcem.

Ano, přesně tak. Praktické věci jsou prostě za tím vším. Zajímalo by mě, jestli máte zkušenost, že přesně, jak jsme tady popisovali, nějaký super top manažer si řekl: „Tak já si ten váš produkt vyzkouším a dám to pod tým, který s ním pracuje,“ a on to vyzkouší, začne něco ničit, nakliká tam úplné nesmysly a pak začne produkt pomlouvat, že věc nefunguje, nebo podobně. Nezničí vám to trošku reputaci? Mluvili jsme o tom, že se snažíte produkt přiblížit uživatelům, ale zároveň může být mezera, pokud si člověk nastaví systém špatně, takže mu to bude dávat nesmysly. Nevidíte v tom nějakou mezeru třeba v reportovacím riziku a podobně?

Nemyslím si úplně. Tím, že nejde o náš produkt, který přijde s perfektním a kompletně fungujícím řešením, nikdy není tak, že by to bylo úplně perfektní a fungovalo hned na první pokus bez chyb. Je to spíše cesta a proces, kde aplikace má své slabiny a s klienty se snažíme tyto oblasti řešit.

V H2O se můžeme pochlubit tím, že máme mnoho velmi dobrých inženýrů, kteří tento problém vidí a řeší ho. Samozřejmě jde o extrémně ambiciózní projekt a plně konkurovat společnostem jako Meta nebo OpenAI s trénováním opravdu kvalitních modelů je těžké až nemožné. Proto se zaměřujeme primárně na menší modely, které mohou fungovat na edge zařízeních nebo offline. Naše modely, nazývané Danubi, už jsou ve verzi 3. Je to malý model, myslím, že má přibližně 4 biliony parametrů a trénuje se zde v Praze a ve Vídni, takže je to produkt našeho engineeringu.

Chtěl jsem se právě zeptat, protože jsme hovořili o složitosti výpočtů, napadlo mě, že asi probíhají na strojích s grafickými kartami a že je tam hodně paralelismu. Zároveň teď, když se všechno přesouvá do cloudu, zákazníci mají většinu zátěže v cloudu, napadlo mě, jestli vám třeba nezbylo hodně grafických karet a zda jste si proto neřekli, že si natrénujete vlastní model?

Ne úplně, protože trénování vyžaduje mnoho velmi výkonných grafických karet. My si samozřejmě na některé věci grafické karty půjčujeme externě.

Škoda. Mám ale pocit, že H2O má opravdu velké ambice. Jaké jsou tvoje osobní ambice? Jaký je pro tebe další krok? Na čem teď pracuješ a na co se můžeme těšit?

Jak jsem zmínil, já vedu projekt Eval Studio, což zhruba tvoří obsah mé práce. To znamená, že mám méně času na samotné kódování a musím se zaměřovat i na směřování celého projektu. Jedním z problémů, které v Eval Studio stále řeším a které je pro mě velmi zajímavé, je, jak uživatelům vysvětlit, co vlastně funguje a co může být problém nebo slabina modelů, aplikací a systémů, které hodnotíme.

To úzce souvisí také s tím, co jsem na začátku zmínil ve H2O, a to jsou vizualizace. Já jsem se dříve věnoval zejména UI a UX a jeden z lidí, kteří můj profesní život nejvíce ovlivnili, je profesor Leland Wilkinson, se kterým jsem spolupracoval od začátku. Kdo ho nezná, je to profesor, který napsal tzv. Bibli statistické vizualizace, knihu Grammar of Graphics. Jeho odkaz v H2O je například modul AutoViz, který jsem zmínil.

Spolupracovali jsme na statistických věcech, které vizualizace jsou zajímavé, ale také na vizuální stránce – jak prezentovat vizualizace, jak by se měly chovat, aby byly statisticky přesné a současně uživatelsky použitelné. To je pro mě určitě velmi zajímavé vedle celého projektu Eval Studio.

Takže budete pracovat na tom, jak ukázat výsledky Eval Studia i byznysovým uživatelům, aby jim to dávalo smysl?

Určitě. Samozřejmě to je jen jedna část úspěchu projektu. Ten rozhodně nespočívá pouze ve vysvětlení, co nefunguje, ale pro mě osobně je to velmi zajímavé a stále se tomu věnuji, takže to je tak.

Jani, moc děkujeme a držíme palce, abys to ty a pražský tým i tvůj tým bavili a dařilo se vám. Věřím, že se zde ještě uvidíme, protože to, co děláte, by stálo za několik dalších dílů. Děkujeme, že sis na nás udělal čas.

Moc děkuji a těším se na příští díl ohledně vašeho LLM.

Děkujeme za pozvání a těším se do budoucna.

Děkujeme, že jste poslouchali až sem. A děkujeme také našim partnerům, členům Data Talk klubu. Jsou to Intex, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Karl Data Company, Data Mind, Notino a Flow.

Pokud chcete být v obraze o dění na české datové scéně i v globálních datových technologiích, nezapomeňte se přihlásit k odběru našeho týdenního newsletteru na webu datatalk.cz.

Ať vás provází data!