Podcast

Dobrý den, jmenuji se Jirka Vicherek.
Ahoj, tady Karel Šmánek. Vítáme vás u dalšího dílu Data Talku. Dneska pro vás máme připravený speciál.

Ano, je to speciál na téma MLOps a máme tady hned tři hosty. Máme tady Petra Stanislava. Ahoj.

Petr Stanislav je příjmení, takže je Head of Technology v O2, respektive v DataClare, a zároveň spoluzakladatel startupu Elin.ai.

Máme tady Martina Hronce, kterého jsme už tady měli. Martin pečlivě dbá na svůj plán a je Head of Data Science ve Falbertu.

A máme tady Michala Marušana, který je Cloud Solution Architekt v Microsoftu. To znamená, že má trošku přesah přes více klientů, ne jenom jednosměrný fokus na jednoho, a doufejme, že se dozvíme možná i něco navíc, než víme všichni my.

První věc, na kterou bych se vás strašně rád zeptal, je to MLOps jako takový. Byla tu před asi rokem éra, kdy se o tom mluvilo všude možné. Bylo to často jedno téma na konferencích, které v tu dobu ještě nebyly, řekl bych, postižené generativní AI, o které samozřejmě také dneska mluvíme.

A mě by zajímalo, jak MLOps vnímáte, protože každý o tom mluví, ale jak se říká, nikdo pořádně neví, co to je. Tak co si pod tím představujete? Můžeme začít pomalinku zleva doprava, tedy začněme asi Martinem.

Já jsem si říkal, že jsme se o tom bavili předtím, že by bylo dobré, abychom si to všichni vygooglili, protože se možná neshodneme. Ale když mám střílet z hlavy, tak bych řekl, že pro mě je to o tom dostat end-to-end data science nebo machine learning projekty do produkce, tedy vlastně řešit celý lifecycle kolem toho, vyvíjet to, nasazovat, monitorovat a dělat to s co nejmenším množstvím tření, které tam je.

Ten samotný tooling a konkrétní implementace jsou pak druhá věc, ale high level to je o tom.

Docela dost souhlasím s Martinem. Já bych k tomu dodal, že z mého pohledu je to hodně o tom automatizovat nebo se zbavovat lidského zásahu v celém pipeline od nápadu až po nasazení.

Aby ten člověk dělal především kreativní část práce a co nejméně té části, která je zaměřená na deployment a kvalitu dat, podobné věci. MLOps má spoustu aspektů. Člověk by se měl soustředit na doručování hodnoty.

Souhlasím s oběma. Pro mě to znamená hlavně dostat model do produkce způsobem, který je opakovatelný, měřitelný a který automatizuje část práce, dělá ji méně manuální, včetně testování a podobných věcí.

Dostat model efektivně do produkce a tam ho provozovat.

Dobře, tohle bylo hodně obecné. Já také tuším trošku, co to znamená, ale pokud mezi námi sedí posluchač, který v této oblasti není příliš zběhlý, mohl by mi někdo třeba Martin od začátku na use case popsat, co všechno se tam děje, co to celé obnáší?

Kde jsou problémové body, jak dostat model do produkce, jak ho nasadit, co všechno se má hlídat, co se může stát a co by se mělo ošetřit?

Proč je téma MLOps vlastně tak důležité? Možná začnu já a Petr, Michal, kdykoliv zkuste doplnit.

Podle mě je to téma, protože dříve tady byl problém se semi- manuálními postupy nasazování modelů do produkce. Ty modely tehdy nebyly ani tak složité, šlo spíš o exponenciální průměry a jednoduché modely, které nebylo těžké natrénovat, jako je tomu dnes. Manuální přístup způsobil mnoho problémů.

A tak když se nad tím zamyslím, co vlastně děláme, potřebujeme nejprve spoustu dat. To je první bod. Ty data musíme spolehlivě získávat, a to ve velkém množství.

Na výstupu pak potřebujeme v závislosti na aplikaci nějakou integraci do konečných systémů a mezi tím trénujeme modely. Po natrénování je třeba je někde systematicky uložit, zvalidovat, zda jsou modely správné a spolehlivé. A nakonec je model někde poskytovat.

Já bych to ještě trochu zjednodušil. Podle mě MLOps znamená různé úrovně automatizace a to, co všechno chceme zachytit. Vzpomínám si, když jsem dělal doktorskou práci na VŠE v oblasti řečových technologií, experimenty jsme si vždy zapisovali do Excelu, včetně výsledků.

MLOps vychází z DevOpsu a když za půl roku přijdu ke svému vlastnímu kódu, často vůbec nevím, co se tam děje. Pokud jste navíc špatně komentovali, strávíte hodiny snahou zjistit, co jste vlastně měli na mysli.

Podobně to bylo i u machine learningových experimentů. Měli jste to v Excelu a často jen výsledky nebo jména experimentů.

Jedna z věcí, kterou by měl každý začínající machine learning specialista v MLOpsu zavést, je trackování experimentů. To znamená mít přesnou evidenci vstupních dat, ve stejném formátu, abychom experimenty mohli kdykoliv zopakovat a zreprodukovat výsledky.

Pak potřebujeme zajistit kvalitu těch dat, což je další aspekt.

Po natrénování modelu ho chceme nasadit, protože model, který nic nepredikuje, je k ničemu.

Při nasazení pak kontrolujeme, jestli model funguje správně, jestli data, která do produkce přicházejí, jsou kvalitní a odpovídají očekáváním. Například zákazníci se chovají jinak v létě a jinak před Vánocemi, což musíme zohlednit.

Následně řešíme automatizaci – jakým způsobem dáváme nový model do produkce, ručně, nebo automaticky.

Problém tedy nabývá na komplexnosti, ale začátek je vždy o trackování experimentů, kvalitě dat a postupném nasazování.

Úplně přesně, v zásadě jde o to, vyřešit ten klíčový problém projektů: dostat věc, kterou někdo vymyslel a naprogramoval s použitím dat, do stabilního produkčního provozu, kde se model využívá pro predikce nebo odhady.

Jde o to udržet model v chodu v produkci, dostat ho tam, neporušit přitom proces, který byl vybudován v oblasti dat, a průběžně kontrolovat jeho stav.

To mě napadá otázka, která tady podle mě ještě nebyla: klasický data scientisti, zejména v korporátním prostředí, všichni používají notebooky a kódují právě v notebooku, což je dobré pro první fáze – exploraci a analýzu dat.

Často je MLOps pro ně jen to, že udělají scheduling a nechají notebooky samovolně běžet. Jak se na to díváte vy? Je to udržitelné, nebo to má své limity? Jak by to mělo vypadat správně?

Podle mě je skvělým lékem na tento přístup nasadit něco do produkce, co musí běžet 24/7. A autora notebooku postavit k helpdesku.

Protože přechod od práce v notebooku k produkčnímu provozu s požadavky na spolehlivost, monitoring a škálovatelnost je obrovský.

Ano, notebook má v machine learningu nezastupitelnou roli, protože vývoj tam není sekvenční, pořád se skáče nahoru a dolů.

Notebook je skvělý nástroj pro explorativní analýzu, možné je i nasazení notebooku v produkčním prostředí, například Netflix používá notebooky při datovém zpracování, kde skrze svůj nástroj Papermill zpracují data za sebou.

Výhodou notebooku je, že v něm vidíte kód i výstupní logy na jednom místě, což je super.

Na druhou stranu nasazení modelů přímo v notebooku do produkce je velmi obtížné, pro provozní spolehlivost notebook není vhodný.

Většina data scientistů umí pracovat s notebookem, ale přechod na produkční kód z hlediska spolehlivosti a udržitelnosti je složitý.

V raných fázích je notebook ideální, je rychlý, ale jakmile se blížíme k produkci, která má SLA a požadavky na spolehlivost, tam notebook už nepatří.

Notebook je spojený s prototypováním – uchovávám tam kód i výsledky pohromadě, což je hezké.

Pokud jde do produkce, běží už jen část kódu, která je efektivní a dělá scoring nebo predikce nad modelem.

Tyto části typicky neběží v notebooku.

Přesto existují platformy a nástroje, které podporují notebookový přístup i v produkčním prostředí a ukazuje se, že to má své místo. Ale intuitivně stále patří do produkce čistý, dobře strukturovaný kód.

Tento přechod notebook-centric workflow do produkčního kódu je často obtížný.

Ano, třeba Netflix využívá notebooky na zpracování dat, protože tam dobře vidí tabulky, grafy a statistiky na jednom místě, což je velmi výhodné.

Naopak si nedokážu představit produkční API, které je založené přímo na notebooku.

Přemýšlel jsem nad tím, že notebook má hlavní přidanou hodnotu v prototypování a v průběhu zpracování, zejména v tvorbě grafů a vizualizací, které běžný skript s loggingem nezachytí tak dobře.

Logování sice může zaznamenat obrázky, ale je to větší práce navíc.

Pokud ale chci vidět při zpracování data vysoké úrovně vizuálně, pak dává smysl mít notebook.

Ano, proto je fajn mít v jednom místě kód i základní statistiky a grafy, nemusím je hledat v logovacím nástroji.

Souhlasím.

Když už jsme u toho, máme na jedné straně notebook, na druhé produkčně připravený kód. Co je potřeba udělat, aby se kód dostal z „prvotní neuklizené fáze“ do produkční podoby? Co chybí, co se má upravit?

Za mě je to spíše o tom, že v produkčním prostředí většinou trenér (training) modelu neběží.

To znamená, už máme trénovaný model – artefakt – a ten potřebujeme spustit na datech, například scoring script. Ten vezme hotový model a pustí ho nad vstupy, které má k dispozici.

Rozdíl často je v tom, že část procesu přípravy modelu už v produkčním kódu neběží.

To bylo dříve oddělené, trénování a produkční běh byly separátní, ale postupem času se i trénování stalo součástí produkčních workflow – například model se trénuje jednou měsíčně nebo jednou za noc.

Trénování je tak sice ve workflow oddělené, ale je součástí produkčního cyklu.

Z mého pohledu je stěžejní zajistit, aby codebase byla co nejvíce identická v prostředí vývoje i produkce, protože často řešíme problémy, že to na mém lokálním počítači funguje, ale v produkci ne.

Pak následuje zdlouhavé hledání chyby.

Jenom k této otázce – hodně záleží na softwarové zralosti týmu. V týmech s vyšší zralostí softwarových dovedností není přechod do produkce tak těžký, protože už znají zdravé návyky psaní kódu.

Pokud softwarový skill chybí, je proces složitější a často je potřeba kód psát úplně znovu.

Ty mi teď připomněl jednu věc – MLOps je DevOps pro Machine Learning. Kolik z metod a principů DevOps, jako continuous delivery, continuous integration a vše as code, přebíráte jedna ku jedné?

Jsou to ty samé principy, jen v jiné oblasti?

V čem je MLOps úplně jiné, když hlavním subjektem není software, ale model machine learningu?

(Téma končí zde.)

Machine Learning, Data Science? Ten rozdíl je podle mě, pokud mohu, v množství kódu, protože kód pro Machine Learning je většinou relativně malý, ale je toho hodně v datech. Primární rozdíl je v tom, že funkci neovlivňuje tolik kód, ale data. Rozdíl je v tom, že já jsem nechtěl být softwarák, takže když tak mi potom nezhejtujte. Když je DevOps u softwaru, tak se tam primárně řeší testy kódu, kvalita, nějaké metriky a podobné věci. Samozřejmě je dobré to mít i u Machine Learningu, ale představte si trénovací a testovací skripty, ty mohou být, pokud máte hodně zkušeností, i v řádech vyšších desítek řádků kódu. To je nula, nula nic, pár testů a tak dále. Ale potom se opravdu drbete, proč to nefunguje, a drbete se v datech. To je ten primární rozdíl, jinak jsou principy stejné, jedna ku jedné. Za mě tedy.

To vidím hodně podobně, v zásadě je to DevOps plus to, že se člověk musí starat o data, o model, který má trošku jiný životní cyklus než aplikace samotná. Už jsme se bavili o tom, že trénink může být průběžný, protože model se může měnit periodicky – jednou za den, jednou za týden, jednou za měsíc, nebo i jednou za rok. Takže je potřeba se starat o data, o model, o to, jak kód funguje a běží i v produkci, tedy v aplikaci či jak tomu chceme říkat. Je potřeba kontinuálně sbírat metriky výkonu, nejen technické, ale třeba i výkonnostní modelu jako celku, abych si byl jistý, že stále funguje stejně dobře jako na začátku. To je trochu odlišné.

U nás je to s daty klíčové i z hlediska, jak data interagují s tréninkovým procesem. To znamená, že můžete mít stejný kód, použít model, který máte někde uložený, ale pokud model byl natrénovaný na neaktuálních datech, bez metainformací o tréninku vlastně z devopsového nebo nasazovacího pohledu nepoznáte, že jste udělali chybu. Nic nezaručuje, že model byl naučený na aktuálních datech a že jde o správná data pro produkci. To je to, co hlavně Michal zmínil s monitorováním a podobně.

Je to tedy tak, že kód může být správný a přesto aplikace nefunguje, protože se změnila data.

To mi krásně navazuje na další téma, což je stack. Zmínili jste, že máte kód, který funguje na mém počítači, ale nefunguje jinde. Máme tu spoustu technologií, které jsou velmi komplexní a je opravdu těžké je spustit jedna ku jedné jinde. Abych možná udělal rychlé kolečko, mám na Michala speciální otázku – jestli byste posluchačům mohl lehce, na vysoké úrovni, popsat, jaký stack používáte a jaké jsou klíčové technologie. Třeba i k těm problematickým věcem, které jste zmiňovali, kde předpokládám máte svá řešení. Michale, mám na tebe otázku, co ty vlastně neděláš, ale vzhledem k tomu, že máš hodně hluboké zkušenosti s tím stackem, mě by zajímalo, kdybys zakládal vlastní startup, jaký stack bys použil. Můžeš třeba postupně…

Dobrý dotaz, ať se na něj můžu připravit, než budeme odpovídat.

Tak začneme Michalem.

Škoda, chvíli jsem se zdržel, ale takhle to vypadá, tak to shrnu. Podle mě je zásadní otázkou, kolik věcí vůbec člověk musí řešit. Kdybych se úplně vzdálil přizemních věcí, jako jsou finance a podobně, tak je to o tom, že člověk a tým startupu by měli řešit to, v čem jsou dobří, co je odlišuje od ostatních, to, co dělá finální produkt tím produktem. Člověk si postaví tu věc a spoustu nutných věcí pro proces prostě outsourcuje technologiemi, které to umožňují. Jen konzumuje službu, která to za něj udělá. V ideálním světě by to třeba sledovalo, co se děje při tréninku modelu, integraci výkonových metrik, zpětnou vazbu zaručující, že se model přetrénuje a podobně.

Chtěl bych se tedy soustředit na to, co dělá startup startupem, tedy řešit konkrétní problém. Snažil bych se maximálně využít věci, které jsou hotové a prověřené, protože svět se vyvíjí hodně rychle a každá technologie má svá pro a proti, proč ji použít.

Je zřejmé, že firmy nezvládají všechny věci jedním nástrojem, který by řešil vše.

Odpovídáš mi krásně politicky, ale neodpověděl jsi na otázku. Když se dostaneme na úroveň Azure stacku, jak bys o něm přemýšlel?

Pro mě je pořád důležité oddělit fázi vývoje od fáze produkce, protože to jsou dvě rozdílné věci, a je potřeba to takto vnímat.

Pokud jde o vývoj, protože jsem už zkušený s Microsoftem, řekl bych, že Azure Machine Learning Service je to nejbližší, co jsem zatím viděl, jak data scientist rád pracuje – spíš code first než code only. Nástroj, který udělá spoustu věcí jako trackování běhu, uchovávání verzí modulů, iterativní proces, kde se často něco mění, než se dospěje k finální verzi modelu.

Současně umí model nasadit.

Pak je tu téma různých proměnných, tzv. features, které vznikají, kde je uchovávat a verzovat.

Je to komplexní problém, ale můj go-to nástroj by byl Azure Machine Learning Service, protože nabízí end-to-end pokrytí ochranou datových operací i vývojem modelu.

Navíc pokud pracujete čistě v Pythonu a nepotřebujete distribuované zpracování jako Spark, Azure ML vám plně dostačuje.

Takže to by byl můj stack.

Skvěle, Petře?

Stack?

Ještě před tím, než popíšu, co máme v O2, je důležité říci, že stack závisí na tom, co potřebujeme dělat.

V O2 máme hodně dat, řádově terabajty denně, které je potřeba zpracovat.

To nám říká, že potřebujeme distribuované zpracování, o kterém mluvil Michal.

Python hraje v Machine Learningu prim, víme o jeho silných a slabých stránkách.

Jedním slabým místem je jednovláknovost, takže velká data nezpracujete nebo bude to trvat dlouho.

Proto přichází na scénu Spark.

Databricks je jeden ze základních stavebních kamenů v O2 jako managed Spark.

Já zastávám názor, že je super, ale primárně pro zpracování dat.

Po zpracování se data ukládají do Data Lake, což je objektové úložiště.

V terminologii Microsoftu je to Blob Storage.

Používáme Deltu pro ukládání a přecházíme pak do Azure Machine Learning, kde máme Python ekosystém.

Jak řekl Michal, je to code-centric, dobře napojený na Git, takže držíme DevOps přístup.

Předtím používáme Azure Data Factory pro orchestraci kopií dat, pipeline a spuštění jobů.

ADF bychom mohli ještě rozebrat.

Toto je základ a pak to upravujeme dle jednotlivých případů použití.

Samozřejmě hrají významnou roli kontejnery Docker při deployi, container registry máme.

Dále používáme různé Azure funkce, které jsou spíše podpůrné služby.

Teď významně roste role Azure OpenAI, který zajišťuje přístup k velkým jazykovým modelům (LLM) pro enterprise zákazníky i další uživatele v Azure.

To je v O2 velmi důležitá oblast.

Hlavní stavební kameny jsou tedy Data Lake pro uložení dat, Databricks pro jejich zpracování, Azure Machine Learning pro vývoj modelů a jejich deployment a Azure Data Factory pro orchestraci.

A pokud jde o inferenci nad velkým množstvím dat, provádíme to obvykle mimo obě prostředí.

Nasadíme Docker kontejner, ve kterém běží kód.

Máme vlastní balíčky a podobné věci, a nejjednodušší je, když model natrénujeme, zabalíme do Docker kontajneru a nasadíme.

To se nyní mění – máme ML registry, odkud lze modely vyzvednout, takže už to není kompletně součást Dockeru.

Docker pak nasazujeme tam, kde je potřeba, například jako container app, kde se to zpracovává.

Pokud inference není real-time, pipeline se stává komplexnější.

Vytahuje se velké množství dat, zpracovává se Databricksem, aby získala podobu, kterou Python zvládne dále zpracovat.

Někdy je potřeba řešit tzv. chunking dat, když škálujeme například na několik milionů zákazníků.

Snažíme se držet v rámci stacku, kde jsou lidé zvyklí vyvíjet.

Pokud Spark není potřeba, nepřidáváme ho do pipeline.

Ano, jsou případy, kdy je potřeba Spark, pak běží pipeline v Databricksu, ale často data zpracujeme natolik, že se to dá v Pythonu zvládnout.

Za nás bych to viděl ze dvou konců, které tam patří.

První je, že potřebujeme dostat většinu dat do data lake.

To je většinou role data inženýrů.

Bez toho nelze pohnout s tréninkem.

K integraci se zdrojovými systémy používáme hlavně Azure Data Factory.

Orchestrujeme ADF s Databricks v rámci standardní data lake architektury.

Data se nahrávají, přespacovávají do společné vrstvy a pak do vrstvy připravené k použití.

To by bylo dobré dále rozvinout.

Uvažovali jsme, zda použít Azure Machine Learning nebo Databricks.

To, co říkáš, dává smysl, pokud není důvod používat distribuované systémy, tak proč za ně platit.

V době, kdy jsme toto rozhodovali, byly dva hlavní pohledy.

První byl ohledně globální architektury, kterou jsme museli dodržovat.

Ale nad ní byla debata, že pro onboarding potřebujeme řešit dva systémy – nasazování do Databricks a do Azure ML.

To by bylo dobré rozebrat později.

Zpracování dat probíhá v Databricks, ML lifecycle u nás probíhá také v Databricks.

Co nezaznělo, je několik dalších služeb.

První je reporting.

Vedlejší tým Business analytiky vytváří vizualizace nejen pro business, ale i pro nás.

Především metriky výkonu modelů.

U velkých aplikací je potřeba dát připravená data, aby se vše nepočítalo v Power BI.

Pro to používáme ADF.

ADF je pro nás primárně integrační nástroj s velice dobře fungujícími konektory.

Ke komunikaci mezi aplikacemi používáme Event Hub pro messaging.

Někdo zmínil, myslím, že to byl Michal, že je dobré vybírat službu, která je co nejjednodušší na provoz.

Petře, myslím, že jsi zmiňoval, že volíš služby, které jsou nejjednodušší na provoz.

Nicméně stále je mnoho firem, které třeba…

Velká část workloadů běží on-premise.

Firmy mají třeba Kubernetes.

Technologií, která podle mě spojuje všechny zmíněné věci, je MLflow.

Nejsem si jistý, ale myslím, že je na pozadí všech těch technologií, jako jsou Databricks i ML Workspace jako model registry.

Mám otázku – hráli jste si někdy s tím, jestli jste komplet v cloudu, nebo vám něco zůstává on-premise?

Jak to vypadá s přesunem a jaké máte ambice?

Druhá věc je, pokud jste museli třeba provozovat MLflow na Kubernetes sami – jak to bylo a kolik času to ušetří používat platformní nebo managed služby?

Alokovat na low-code infrastrukturu a údržbu.

U nás byl postup takový, že jsme šli z on-premise systému do cloudu.

Migrace probíhá doteď, respektive začala teď.

Část projektů běží on-premise, část již v cloudu.

Já jsem k tomu přistoupil pragmaticky.

Věděl jsem, že do cloudu jdeme a věděl jsem, že MLflow je tam dobře zajištěný, takže jsme na on-premise používali MLflow fakt jenom základním způsobem.

Pod tím základním způsobem myslím, že MLflow má hodně modulů, ale my jsme ho použili hlavně na logování experimentů a modelů a to bylo vše.

Veškeré metainformace jsme spravovali on-premise.

My jsme více méně…

Myslím, že každý to zažil, když ke mně přijde …

Takové zkušenosti z enterprise prostředí nebo to bylo on-premise, furt v určitých situacích hrají docela prim. Zrovna přechod, který my nazýváme „big data platformy do Google,“ teda do cloudu, ne přímo do Google. Pro posluchače Michal zde rozpažuje rukama, protože furt vidí pouze Google. Pro posluchače – Jirka má na sobě tričko Google. Grillování u konce.

My jsme také samozřejmě začínali s on-premise a dokonce jsme byli jednou z prvních, nebo přímo první velkou instancí, která přešla do cloudu. Přiznám se, že jsem byl součástí výběrového řízení celého procesu a bylo to tak náročné, že jsem v té firmě chtěl asi desetkrát odejít během jednoho měsíce – prostě to bylo peklo. Ale to jsem odbočil.

V podstatě, pokud máte v týmu člověka, který má zkušenosti nejen s on-premisem, ale i s hardwarem a s Kubernetes – což je v současnosti prakticky to jediné a hraje prim – tak vám Kubernetes poskytne maximální flexibilitu. Můžete tam nasadit cokoliv a provozovat to velmi snadno v cloudu. Nicméně musíte mít patřičné zkušenosti. Tyto systémy mají, zejména Kubernetes, docela netriviální křivku učení a získání zkušeností zabere dost času.

V machine learning světě jsou lidé, kteří tvoří modely excelentní matematici, ale naučit je dobře ovládat tento nástroj je poměrně složitá operace. Proto zastávám názor, že pokud se o to nemusím starat, tak se o to raději nestarám. V tom jsou pasivní služby pro mě skvělé – jednoduše nasadím model, přičemž je to otázka kliknutí tlačítka, nebo v Databricksu chci klastry s určitým počtem nodů, kliknu, namíchám například deset nodů, dám Start a systém vše automaticky spustí. Nemusím řešit síťování, pody ani všechny ostatní věci, takže to prostě nedělám. Je to dovednost, kterou nemusíte mít, ale pokud ji máte, maximálně ji využijete a získáte největší flexibilitu. Ale já osobně raději neřeším něco, co nemusím.

S tím souhlasím. Možná doplním jeden bod: to vše samozřejmě závisí na tom, že služba má dobře udělanou abstrakci. Pokud je abstrakce na správné úrovni, snažím se „natlačit“ fungování do ní, jinak narazím na nějakou konkrétní službu, kterou bych musel řešit přímo. Takže bych ji zvolil podle potřeby a situace. Co ty, Míšo?

Já zatím souhlasím s předchozími plány. Myslím, že se to vrací, a to je dobře. Zpět na úroveň, kdy chci řešit nějaký problém a nechci se zabývat věcmi, kterými bych se zabývat nemusel nebo které nejsou mou kompetencí. Což nahrává dneska cloudu.

Já jsem v Microsoftu sedm let, takže určitě jsem zaujatý. Nicméně pro mě už on-premise není téma, hlavně proto, že zákazníci to s námi většinou nechtějí ani řešit, když to není nutné. Protože i když nic jiného cloud udělá, má tam služby, které umožní rychle něco spustit a rychle to zase zahodit, pokud už to nepotřebuju. A jsem schopný takto rychle realizovat nějaký use case od první představy až po testování na svém datasetu, ve své firmě, za svých podmínek.

To, co potřebuju, je rychle a poctivě provést trénink modelu, dát mu logiku a smysl a nezabývat se přitom vším ostatním, jako je instalace serverů a dalších detailů. Chci mít možnost vždy rychle něco spustit a případně rychle zrušit. To je fail fast přístup, který premiové systémy často postrádaly – například instalace Hadoop platformy trvala půl roku, takže projektů bylo málo.

Cloud, když jsem se účastnil výběrového řízení, mnozí měli otázku, co nám cloud přinese a jestli to nebude drahé. Odpovídal jsem, že drahý to zase tak nebude, ale přinese nám flexibilitu. My jsme měli Hadoop cluster, nejmenší ve střední Evropě, který fungoval skvěle, ale kupuje se na pět až sedm let. A věci se ale mění tak rychle, že když to nastavím dnes, budu to muset držet pět let a budu zaseklej.

Takže největší přidaná hodnota cloudu, ať už stack postavíme jakkoliv, je právě flexibilita. Můžu to postavit na Kubernetes, na servisních službách, ale pořád říkám, že musím vybrat správné „kostičky z Lega“, abych postavil to, co potřebuji. Cloud mi to umožňuje, a pokud někdo zvolí Kubernetes, neudělá špatně, ale má to své „ale“ – musí to umět.

Ještě zmíním jednu věc ohledně stacku. Původně jsme jich zvažovali víc, ale tato konfigurace je podle mě ideální – real time a API. Trochu jste to zmínili, ale zajímalo by mě, zda používáte modely, které pak v režimu real time nebo jako REST aplikace obsluhují nějaký frontend nebo další mikroslužby. Zmiňovali jste snahu co nejvíce používat batch, fronty, například Event Hub, jak zmínil Martin. Jaký máte use cases a jak se to mění s MLOPsem? Předpokládám, že MLOPS u real time zařízení musí být přísnější.

My také nemáme mnoho use cases pro velice restriktivní real time, spíš se tomu vyhýbáme, pokud to jde. Dva hlavní důvody – složitost udržení je řádově náročnější než batch přístup, a pokud to můžeme udělat batchově a zvládneme to před načtením velkého množství dat, je to efektivnější.

S Martinem naprosto souhlasím. Lidé chtějí real time, ale součástí MLOPSu je challengeování use case. Pokud člověk začíná challengeovat real time, často zjistí, že ač je požadavek reálný, například v práci se zákazníkem, kdy data zítěče v síti přicházejí téměř near real time za minutu, co se stalo, přichází problém – co s tím zákazníkem uděláme? Zavoláme mu hned? Pošleme SMS? Reakční doba je často spíše hodinová, což už real time není.

Proč je real time náročný? Postavit ho je jednoduché, ale spravovat, monitorovat a rychle reagovat ve chvíli, kdy nastane problém, je velmi obtížné. Musíme okamžitě řešit špatná data, kdy model začne vyhazovat nesmysly. U real time je třeba reagovat hned, zatímco v batch se provede kontrola například dvě hodiny předem, poté s tím můžeme pracovat. Tato téměř nulová reakční doba je komplexní problém.

Důležitý je klást otázku jen tehdy, je-li reálný přínos a zda benefit real time převyšuje náklady. Pokud ne, není důvod se do toho pouštět. Většina situací může fungovat i s krátkodobým zpožděním patnácti minut. V době budování hybridních řešení jsme vybírali nejlepší z obou světů – něco bylo drahé, vždy tedy nějaký trade-off.

Myslím, že jsme na začátku éry real time, je to drahé a stojí to určitě více, než klasické batch přístupy. Čím více se MLOps stává komoditou a řešení jsou připravena, tím více celý stack zatěžují.

Bude to real time nebo batch? Asi to budou dva režimy.

Přemýšlel jsem o tom, že asi začínám být starší, nebo nevím proč, ale když jsem začínal s datovým světem, real time byl strašák – třikrát dražší a složitější. Real time tehdy znamenal neobnovovat data jednou za den, ale čtyřikrát denně. Byly to hodiny nebo desítky minut.

Někdo dnes real time chápe jako informaci „good enough“ včas, aby bylo možné rozhodnout. To může být i mikrobatch trvající 5 až 15 minut, což pro mě ještě není real time, ale online. Skutečný real time znamená okamžitou reakci, kdy zpráva přijde například přes Kafka frontu, já zareaguji a vracím výsledek zpět.

Skutečný real time je tedy latence v řádu sekund. Tam je výzva – signal přijmout, zkontrolovat, zda náhodou nepřijde dvakrát ta samá zpráva, zpracovat data a v reálném čase reagovat.

Vidím ale evoluci – služby se dnes chovají jako batch i real time zároveň, to je jejich vývoj. Dříve byly technologie odlišné – jiný stack pro batch a jiný pro streaming. Dnes většina umožňuje řešit obojí na jednom místě.

Nemyslím si, že vše bude real time, spíš se architektury jako lambda či kapa budou konvergovat v unifikované řešení, kde jeden systém zvládá batch i streaming.

Já do toho jen vstoupím – toto se hodně diskutuje v Hadoop světě, kde se říká „streaming first architecture.“ Všechno sevtlačí do fronty – ať už batch, nebo stream. Fronta stojí peníze stejně, zasíláte do ní data a zpracováváte dávkově nebo streamem.

Ale pak přichází problém peněz v cloudu. Ukládání dat na blob storage párkrát denně je mnohem levnější než držet data ve frontě. A teď je spojený druhý pohled: co když nastane problém, fronty se začnou plnit, ale fronty nejsou nekonečné.

Ve světě big data mohou být fronty schopné data držet jen 30 minut, protože víc by znamenalo násobně vyšší náklady na prostředky. Pokud se to nevyřeší do 30 minut, data ztratíte, což musíte nějak řešit.

Myslím si, že Hadoop svět, kde vše jde přes frontu, není finální řešení. Nevím, jaké bude, ale jediné, co bude jedno, je, že software bude abstrahovaný tak, aby developer neřešil, jestli je to real time nebo batch.

Developer bude stejným způsobem vyvíjet aplikaci a nebude se zajímat o technologii „v pozadí“. Pokud bude potřeba, technologie se posune na vyšší úroveň – totiž pokud nestihnete použít abstrakci, přejdete k jiné technologii. To je podobné jako u SQL – používá ho každý, dokud to stačí; pokud nestačí, musí jít do nižší úrovně.

Děkuji. Teď bych se rád přesunul na téma lidí a týmů a na to, jak řešíte MLOPS personálně.

Můj přechod bude na Petra. Petře, když jsi mluvil o Hadoop clusteru, který byl nejmenší ve střední Evropě, říkal jsi, že těch pět let tě vyděsilo – že nemůžeš vyměnit technologie tak rychle a že se svět hrozně rychle mění.

Jak do toho vstupují lidé, lidské kapacity, komunita, talent pool na trhu? I kdybys měl úžasnou technologii, ale měla by malou adopci a málo lidí, kteří ji umí, jak to ovlivňuje výběr technologického stacku? Hadoop na pět let, všichni ho umí versus něco úplně nového, co umí málokdo, ale výrazně to zrychlí.

Myslím, že kromě Rustu – což je krásný příklad, protože Rust byl minimálně možná před Rastem velmi sexy a možná lepší než Python – je ale určitě lepší jít cestou: nemám nejlepší řešení, ale mám dobré a umíme ho ovládat. To často stačí, nemusí být excelentní.

A v tom strojovém učení…

V dnešním světě hraje prim Python, takže to je to, co vlastně my hledáme. Co se týče staffing, je to velmi zajímavé téma a možná by to stálo za jeden celý díl.

Z mých vlastních zkušeností – když jsem nastoupil do O2, existoval tam tým data engineeringu, který měl na starosti přesně získávání dat, produkcionalizaci těch řešení, a dostat data zpátky do datového skladu nebo do systémů, kde to bylo potřeba. Vedle toho byly týmy, které dělaly machine learningová řešení. To je fajn, mnoho firem to tak má, dává to smysl z různých pohledů. Nicméně velmi brzy jsme narazili na problém, že tyto dva světy, i když se snažíme mezi nimi bariéru odstranit, tak tam vždycky bude.

Jsou to dvě různé agendy a dřív nebo později dojde ke střetu. Otázka je, kdo má větší pravomoc a ten musí pak rozhodnout, kdo a jak ten problém řeší. My jsme k tomu přistoupili tak, že tým musí být end to end odpovědný. A to end to end opravdu znamená i komunikaci s byznysem.

V O2 vlastně tým představuje nějaký produkt. Jeden můj kolega mi vždycky říká, že to není produkt, protože project manager a product manager jsou dvě rozdílné role, ale většinou to stejně skončí u toho, že je to jedno a to samé – někdo, kdo řídí celý vývoj a hodně komunikuje s byznysem a validuje požadavky. To je první věc, kterou může dělat kdokoliv s potřebnými zkušenostmi.

Potom jsou samozřejmě lidé na machine learning – často absolventi Matematicko-fyzikální fakulty nebo Fakulty aplikovaných věd v Plzni, kteří mají dobrý matematický základ, znalosti statistiky a podobně.

Co jsme ale zjistili, že je zásadní, je softwarový inženýr, který vše propojí a celé řešení postaví. Technicky je tam trochu problém s Pythonem, ale přiznávám, že nejsem fanoušek Javy, která je spíše enterprise peklo. Když s ní někdo přijde, říkám „jdi s tím někam jinam.“

Obecně je důležité při hledání lidí, aby měli chuť učit se nové věci. Protože svět machine learningu se pohybuje velmi rychle. Musíte mít technický základ, ale hlavně vůli a snahu stále zkoušet něco nového. Což pak souvisí s tím, že říkáš, že Python je problém při hledání softwarových inženýrů.

Zda se ti stává, že se snažíš najímat softwaráře, které musíš přimět k programování v Pythonu, a oni to mají problém? Já zatím ne, ale možná jsme je už v hiring procesu odfiltrovali. Věřím, že s tím problém narazíme právě při najímání, kdy začnou říkat „umím Javu“ nebo něco jiného. Říkám, že na to určitě přijdou.

Technologický stack může být hodně široký, a když máte lepší nástroj, který problém řeší líp než ten současný, měli byste ho používat. I když to znamená vyučovat lidi.

Za mě je důležité, aby byl člověk otevřený novým věcem. To platí hlavně i v softwarovém inženýrství, které je těžké přimět, aby přešel třeba na Python. Proto nabízíme career shift – člověk používá stejné principy, ale jiný technologický stack.

A když jsi sám, kdy začínáš hrát s novou technologií? Kdy si myslíš, že by se ti hodila do osobního stacku a kdy začínáš přemýšlet o nahrazení části produkčního stacku?

Když přijde nový use case nebo potřebuji něco nového, tak začnu zkoumat. Platí zásada „don't fix it if it ain't broken“. Máme třeba ADF, která je skvělá a zrychlila migraci do cloudu, ale když něco do toho nepasuje, je problém to nasadit. Takže je těžké třeba přejít na Airflow, protože by to znamenalo kompletně přepsat a předělat.

Já osobně začínám nové věci prozkoumávat záměrně a rád. Za svou kariéru jsem zkoušel hodně věcí – mám vzdělání v umělé inteligenci, ale dělal jsem Android, weby a další. Vždy jsem rád prozkoumal novinky, protože potřebuji vědět, jak co funguje.

Teď se dostávám k LLMK (Large Language Models, Knowledge-based) technologiím, které přinášejí zásadní změny. I když se nebavíme o nasazení vlastního modelu, jde o velké změny v přístupu k datům a nasazení.

Martin, jak se podle tebe díváš na staffing, dlouhodobost technologií a vhodnost technologií v souvislosti s dostupností talentů?

Podle mě je prvořadé, jak velký tým stavíme. A je potřeba zvážit, že firmy, které chtějí postavit data science nebo machine learning týmy, často nemají expertízu a pak mají zkreslenou představu o tom, co požadavky obnášejí.

Je velký rozdíl, jestli stavíte tým o třech lidech, nebo o dvaceti. Záleží na tom, do jaké míry si můžete vybírat specialisty. My konvergujeme k tomu, že tým je end-to-end odpovědný za produkty. To přináší mnoho výhod.

První je, že lidé mají vysoký stupeň ownershipu nad projektem. To je podle mě klíčové, protože když lidem dáte svobodu a zodpovědnost, výsledek je jiný, než když jim řeknete přesně, co mají kódovat.

Myslím si, že v machine learningu je opravdu důležité dát lidem svobodu rozhodování. Nechci to brát jako kritiku korporátních přístupů, kde je někdy nastavené, že musíš používat nějaký konkrétní nástroj, například SAS, a nemůžeš z toho vybočit. To je pro kreativní lidi zabiják.

Člověk chce mít ownership – „tady máš věc, je to na tobě“. A to je zásadní. Na základě rozhovoru s Martinem cítím, že s tím také souvisí, že ten, kdo je za produkt zodpovědný, je zároveň člověk, ke kterému se lidé obracejí, když se něco rozbije.

Souhlasím, i my máme v týmu vtip, že dokud nikdo nemusí držet pohotovost, například v sobotu a nevzdat romantickou procházku, tak všichni jsou vlastníci a tvůrci produktu. To hodně napomáhá k pocitu ownershipu.

Mišo, ty vidíš hodně klientů, co podle tebe funguje a co ne?

Já jsem si vzpomněl, že jsem viděl oba extrémy. Jeden extrém je, že technologie určují lidi – tedy když firma má investované do nějaké technologie, tak nehledají lidi podle schopností, ale podle technologie. Druhý extrém je, že lidi určují technologii a vybírají si to, co jim nejvíce vyhovuje.

Myslím si, že dnes vede ta druhá varianta, kdy se týmy nechají vést lidmi a vybírají si to, co potřebují pro rychlé dodání hodnoty. To je důležité. Mnoho technologií lze dnes hostovat či nasazovat flexibilně, a tak si tým může vybrat ty nástroje, které mu vyhovují.

To mimo jiné podporuje i cloudová řešení, protože umožňují experimentovat s různými frameworky.

Martin, k tomu bych řekl dvě věci. Přestože tento přístup konverguje k otevřenosti, neměla by to být anarchie. V našem případě razíme například Python jako základní nástroj, ale ostatní technologie jsou volné, pokud řeší potřeby projektu, samozřejmě s ohledem na licence.

Tímto směrem se tedy vývoj ubírá a firmy, které takto fungují, jsou flexibilní a rychle reagují na požadavky.

Další věc k velikosti týmu – optimální je mít tým o velikosti 5 až 7 lidí. V takovém týmu je prostor pro ownership produktu, softwarové dovednosti, data engineering a data science.

Pokud je potřeba škálovat, staví se více takových malých týmů, například kolem jednotlivých produktů.

Je potřeba mít dobré rozhraní mezi týmy a softwarové kontrakty mezi produkty. Není to ideální na všechno, ale výrazně to zjednodušuje organizaci.

Samozřejmě tento přístup má své problémy, což jsme diskutovali dříve. Například pokud má být tým end-to-end odpovědný a existuje datový zdroj využívaný všemi týmy, je otázka, kdo je za něj zodpovědný a jak řešit nové datové zdroje.

Často nejde o úplně nové údaje, ale o jejich zlepšení. Jak to zakomponovat do agilního sprintového procesu? To jsou výzvy, které zatím nemáme úplně dobře vyřešené, ale je to lepší než dříve.

Toto spadá i do oblasti data governance, což je obtížné téma, do kterého však nechceme příliš zabíhat.

Jenom bych chtěl dodat, že většina chyb v produkci (~95 %) pochází z problémů s daty, málokdy z infrastruktury. To souhlasí i s tím, co jsme řešili dříve o rozdílu mezi DevOps a DataOps.

Kód bývá často jednoduchý na otestování, chyba je v datech. A jak s tím pracovat?

My jsme například zažili, že vlastník dat v Everhousu změnil formát dat, aniž by dal vědět. Najednou začaly selhávat scoringové modely. A je složité zjistit příčinu, protože se kopou chyby a překrytí může být matoucí.

Je lepší, když chyba jasně padá, než když metriky začnou klesat, protože kód sám o sobě nepadne – on jen pracuje s chybnými daty.

Zbývají data, ano. Možná ještě poslední otázka ohledně talentu a technologie a těch, kteří je používají, Michale. Michale, jak ty vidíš, že se mění uživatelé, tedy lidé, které zajímá machine learning (ML)? Vidíme v tomhle nějakou komoditizaci, že se to dostává více k byznysu? Že například produkty, které řeší machine learning, musí být méně technické, méně „execute“ a více klikací, low-code, no-code, aby i pokročilý business user v nich mohl něco najít? Jak toto vnímáš? Posouvá se to v čase?

Upřímně si myslím, že ano, asi to tíhne k tomu, aby bylo všechno dostupné jako low-code. Samozřejmě, dříve když se dělal nějaký ML projekt, tak ten byznysový člověk v zásadě nechtěl rozebírat, jak to bude udělané a jak. Měl nějaký problém, který popsal, a ML inženýr nebo data scientist si to vyslechl a přišel s nějakou myšlenkou, jak to naprogramovat tak, aby to fungovalo pro daný use case.

Dneska je to už vlastně tak, že ML je jakoby komodita. Patří to do firemního prostředí, aby byli schopni buď něco předpovídat, klasifikovat nebo jinak pracovat s daty a lidmi. Už je to normální režim a samozřejmě i lidé a role, které dříve s tímto neměly dostatečnou zkušenost, dnes už v tom režimu přemýšlejí. Když mají správný nástroj, jsou schopni si některé use case zvládnout sami. K tomu asi směřujeme.

Já zase mám zkušenosti z O2, kde to bylo spojeno s LLM (large language modely). Chtěli tam jednoduše řešit spoustu nápadů a problémů, které by bylo těžké odbavit konečným počtem lidí. Tak řekli: „Tady máte API z OpenAI a PowerAppku.“ Lidé to umí použít místo PowerApps, něco si s tím vytvořili a šlo to zapojit velmi snadno. Takto si udělali jednoduchý use case, pro ně to bylo no-code, klikatelné, a vyřešili velmi zajímavý ML problém.

Na druhou stranu, abych byl procentuálně přesný, původně to má logiku a děje se to, ale problém je v ops světě (provozu). Když koncový uživatel vytvoří aplikaci, která mu dává smysl, ale pak ji udržovat, to přináší všechny problémy, které s tím 100% přicházejí. Ownership toho kódu, té aplikace může být problém. Převzít kód po jiném developerovi je složité, převzít no-code řešení po nedeveloperovi je vstupní brána do pekla. Vždycky jsme říkali: „Sorry, je to vaše, můžete si to tvořit, ale nechceme o tom moc vědět.“

Kluci, vy jste zmínili takový náznak self-service z pohledu machine learningu. Mě velmi zajímá váš názor, možná trochu divergujeme, ale co si myslíte o AutoML?

Já si myslím, že je super na nějaké generické základní věci. Pokud je to nějaký standardní problém, což není úplně vždy, ale řekněme, že jde o problém řešitelný standardními přístupy, pak je AutoML fajn. Machine learning lidi z akademické sféry často míří na co nejvyšší výkon podle metrik, ale byznysově „good is enough“, tedy 80 %, Pareto-pravděpodobnost, je OK. AutoML toho často docílí velmi snadno, takže nemusíte tolik dřít a můžete se soustředit na těžší problémy.

AutoML ale není spása pro všechno. Myslím, že už se nestane, že existuje systém, do kterého prostě vložíte data a na konci dostanete rozhodnutí, které naprosto vyřeší jakýkoliv problém. To ne.

Určitě je super například na vytvoření nějaké baseline, třeba performance modelu, který rychle dosáhne něčeho více než 50 % accuracy, což je super. Na druhou stranu nikdo nepopírá, že musíte data připravit, musíte vědět, jak to udělat, aby to vůbec šlo. To už myslím dnes AutoML umí samo.

Jasně, ale myslím, že je potřeba vědomě kontrolovat, že máte prst na tepu toho, jak data procházejí a co pouštíte dál, aby výsledky dávaly smysl, a neodebrat závěrečnou fázi, tedy vyhodnocení a kontrolu, že model je robustní, nemění se v čase, a podobně. Interpretace výsledků je důležitá.

Já zase říkám, že AutoML je dobrý sluha, ale špatný pán. Je to vhodné pro firmy, které nemají interní data science schopnosti, ale znají dobře svá data. Aby AutoML fungovalo, musíte data znát. Bez toho to nefunguje. Businessový člověk to tam nemůže jen házet a čekat, že mu to něco vyhodí. V opačném případě to může spíše škodit.

AutoML se používá jako částečná náhrada data scientista, což podle mě není pravda. Marketing kolem toho je někdy příliš, jde spíše o zefektivnění práce člověka, který má zkušenosti, protože stroj udělá rutinní části a člověk si vybere to nejlepší.

Ano, AutoML nenahrazuje datové vědce, ale pouze je doplňuje. Vidím v tom odkaz ke komoditizaci, o které jste mluvili – všechno, co lze řešit AutoML, lze komoditizovat. To je jeden bod.

Druhý je, že z pohledu toho, kdo bude nahrazen, to řeší úroveň, kde podle mě není hlavní přidaná hodnota ML řešení. Jde o hyperparametrický search a celkové modelování. To není gro, kde ML řešení přidává hodnotu.

Mám kamaráda, který byl nadšenec do AutoML a dlouho ho testoval, postupně říkal, že to bylo dobré, ale pak narazil na problémy. My AutoML v praxi moc nepoužíváme, protože nám to tolik práce neušetří. Často ale vidíme, že externí konzultanti za půl dne AutoML řešení dokážou spustit a vytvořit baseline. Souhlasím, jako baseline je to dobré.

Máme zkušenosti s Hugojem (pravděpodobně H2O.ai). Používáme ho jako rychlý sanity check baseline u jednodušších problémů. Občas jsme ho použili i na dlouho trvající úzký projekt, kde původní tým už ve firmě nebyl. Místo hluboké analýzy kódu jsme data dodali do AutoML systému a dostali přijatelný výsledek. Tím jsme ušetřili hodně času. To se často stává, že lidé odejdou a kód zůstane.

Ale abychom řekli, že AutoML je primární cesta, myslím, že to ještě nenastal čas.

Když jsem končil školu, už začínaly náznaky nástrojů jako H2O a další, ale já jsem si říkal, že kvůli tomu jsem nestudoval výšku ani matematiku, abych byl nahrazen strojem. Měl jsem proto skepsi.

Pak jsem AutoML vyzkoušel u několika úzkých problémů a zjistil jsem, že to nejen poskytuje výsledky jednotlivých algoritmů přes grid search, ale dělá i ensemble modely, které výkon zvedají o jednotky procent. U feature engineeringu jsou různé přístupy, které AutoML zvládne.

Pro mě je to, jak říkám všude, brutální game changer, pokud je problém triviální a patří do jedné ze tří kategorií přístupů, které AutoML zvládne. Lidé nemusí trávit čas s těmi problémy a mohou se soustředit na složitější věci. To je to, co se snažíme využít.

Vidíme to i u tech LLM. Někteří říkají, že LLM nahradí i profese s vysokou přidanou hodnotou. Já si to nemyslím. Samozřejmě dojde k transformaci, ale LLM bude fungovat dobře na určité problémy a člověk se zaměří na ty, kde to tak dobře nebude fungovat.

To se stane, že k nějaké transformaci dojde, a to je super.

Pokusme se zakončit dvěma tématy, protože lidi nás na Data Day pomlouvají, že jsme delší než Game of Thrones. To byl kompliment, ne pomluva.

Nevím, jestli Broukásik teď nebude nekonečný. Lex Friedman – když poslouchám jeho podcasty, které trvají i šest hodin, to nejde vydržet. To jsme zatím pořád v pohodě. Ale čím dál víc je to o lásce a vesmíru a méně o machine learningu. To je pravda. Možná jsme tímto směrem trochu šli.

Vidím to takhle.

Já vám jenom, když mluvím o technologickém okénku, zakončím tím, co je teď hodně trendy.

První věc, předpokládám, že ji nikdo z vás nepoužil, ale zajímá mě váš názor, je Mojo. Bylo kolem toho velké haló. Co od toho očekáváte? Zkoušeli jste to? Já jsem to nezkoušel, slyšel jsem podcast, kde to představovali, pokud si dobře vzpomínám.

Petře, ty jsi bravurně říkal, že vždy zkoušíš nové věci, když máš čas.

Já jsem asi konzervativnější člověk. Možná si dovolím parafrázovat Michalovu hlášku, že asi jsem už starý nebo co.

Já jsem asi z těch starších, ale baví mě to.

U mě to je tak, že většinou na to prostě nemám čas a nemám chuť, pokud do toho nejsem určitě nadšený nebo to není nějak velký hype, tak raději počkám, až někdo jiný věc otestuje – časový test, Lindy efekt.

Takže si to poslechnu, přijde mi to zajímavé, ale nemám dostatek kontextu ani dovedností posoudit, jestli mi to změní život, ale pokud ano, tak mi to rád někdo předá, a já to rád přenesu dál.

Petře, co ty na to?

Struktura Pythonu, tedy Python s rychlostí C nebo Javy, takhle na papíře to zní skvěle. Ale já jsem to zkoušel jen letmo, taky nemám nekonečný čas, vybírám, co vyzkouším.

V práci je známo, že jsem early adopter a mám rád rychlé ověření, zda to stojí za to.

Zkoušel jsem to letmo, ale pár syntaktických problémů mám a myslím, že adopce bude problém. Bude to jako Julia, pro nadšence ano, bude to lepší než Python, ale Python je dobrý dost a nenahradí ho.

Mojo má velkou přidanou hodnotu v podobnosti syntaxe s Pythonem.

Julia byla kolem mě, snažil jsem se jí vyhýbat, ale byla výkonná, její paradigma bylo jiné než Pythonu. Když jsem měl problém, v Pythonu jsem věděl, jak ho řešit, ale v Julii jsem musel sednout a otevírat Stack Overflow, v době před GPT.

Další problém bylo, že se verze měnily rychle – během měsíce dvakrát. Kód, který před měsícem fungoval, nyní nefungoval.

Co se týká Mojo, o tom moc nevím, ale silný selling point je ta syntaxová příbuznost.

V Pythonu například byla paralelizace přes Dask, což bylo první odparalizování pro Pandas uživatele.

Ale nesouhlasím, že to je to hlavní. V Mojo je pro mě zajímavá blízkost Pythonu.

Jsem early adopter, ale pokud jde o produkční nasazení, jsem opatrný, často čekám.

Já říkám: „Pojďme to zkusit, udělejme kvalifikované rozhodnutí.“ To znamená, musím to vyzkoušet a podle toho rozhodnu, co použijeme.

Když to hodně zjednoduším, tak počet odpovědí na Stack Overflow je celkem dobrá metrika pro to, co se bude používat.

To má ale veliký smysl.

Vracím se k tématu ops – early adopteři jsou dobrá věc, jsou experiment.

Spousta věcí dnes vychází skoro v reálném čase, každý týden, každý měsíc velké releasy, nové hračky.

Je dobré to vyzkoušet, ale pak to „láme“ ops.

Když už máme hodně projektů, potřebujeme nějakou unifikovanou, celistvou strukturu, kterou dokážeme řešit opakovaně, rychle reagovat na problémy.

To samozřejmě znamená mít zoo frameworků, protože každý projekt má svoje specifika a…

(text přerušen)

Každý, kdo si to najde někde na internetu, co zrovna letí, je řádově obtížné pak v nějakém reálném provozu udržet. To znamená, že bych se vrátil zpátky k tomu, jak je to s OPS problémem, a tam se vyplatí být trošku konzervativnější. To je taková klasická debata, já vím, že reinforcement learning teď není v kurzu, ale je to ten klasický problém exploitation versus exploration. Kdyby to bylo na byznysácích, tak by se, dokud nejsou „ocelovaní“ (když to řeknu hovorově), pořád šlo na stejném stacku. A pak je otázka, odkud přichází ten krok vpřed, jestli je to prostě Petr, který si něco zkouší nové.

On prostě přijde s šarmem a řekne: „Ano, vyzkoušejme to.“ Nebo je to tak, že přijde někdo externí, například Microsoft nebo Google, do firmy a pokusí se protlačit nějakou technologii. Dejme tomu, i když ta firma není úplně připravená – ty jsi mluvil o kvalifikovaných rozhodnutích, která se dělají obtížně, protože je tam příliš mnoho neznámých. Ale už jenom to, že se to nějakým způsobem posune, a náhodné rozhodnutí je často docela dobré, dejme tomu.

Jo, jo. Chtěl bych to zakončit tím, že když to funguje, nebo v jedné iteraci, například v Pythonu, když to funguje a jsi schopný to provozovat, bude to takhle. A jestli za deset let bude Python mrtvý a bude tady Mojo, možná. Ale úplně si to nemyslím.

Super. Máme tady poslední téma, a to je samozřejmě generativní AI. Samozřejmě se na to budu dívat z pohledu konkrétních případů užití, protože o tom už tady bylo spoustu podcastů, ale mě spíš zajímá, jak jste říkal, Petře, LLM Ops – tedy jaké s tím máte zkušenosti.

Mě by zajímaly vlastně tři aspekty. První je, jak to nasazovat, jak se o to starat, jaké jsou hlavní aspekty nasazení a provozu. Druhá věc je, jak ty modely využívat, tedy jestli používat třeba OpenAI službu, která je placená za token, nebo používat něco, co finančně může vycházet lépe, anebo to třeba provozovat on-premise nebo na vlastních strojích a tak dále. Jak na to koukáte? Petře, tento problém nemáme v týmu, tak prosím, vysvětli nám to systematicky, a pak půjdu za kolegy a řeknu: „Petře, toto říkal Petr, toto Stanislav.“ Jsou to dva různí lidé.

My to nahráváme, Martine, neboj, to je pointa.

Já bych zašel k Michalovi. Jak se zmínil tvůj job letos? To je dobrá otázka. Hlavně v tomto světě se ukazuje, že nic se neděje příliš rychle, jako se děje okolo generativní AI a všeho toho humbuku, který se kolem toho spustil. Ten humbuk není umělý; je to reálné, a je to dobrý princip, protože ta technologie je skutečně trošku revoluční. O tom tu asi nemusím mluvit.

Nicméně, ohledně LLM ops nebo ML ops – podle mě je to největší výzva, kterou budu muset řešit. Už jen to, že se změnilo paradigma. Já jsem zvyklý pracovat s tradičním kódem, kde to, co naprogramuji, je přesně to, co program dělá, a já mám nad tím kontrolu. Najednou tu mám něco, co neříká, jak to udělat, ale řekne: „Dělej to,“ a ono to za mě tu věc vykoná, přičemž překvapivě dobře, ale nemám úplně kontrolu nad tím, jak to dělá, a jestli to opravdu bude fungovat pro mě dobře, nebo ne. Vždycky je to jinak.

Problém vidím v tom, jak to vlastně v produkci udržet a měřit efektivně, protože už tam nejsou jednoduché metriky, jako třeba přesnost nebo recall, ale je třeba zjistit, jestli je text dostatečně dobrý a popisuje to, co má. Je otázka, jak tyto metriky reálně změřit. To jsou metriky, které jsou těžké pro člověka změřit víc než pouze „dobré“ nebo „špatné“.

Chtěl jsem se tě právě zeptat, jestli znáš nějaký způsob, jak to změřit. My se to zatím jako…

Nejjednodušší přístup, který se nyní hojně používá, je nechat to změřit dalším modelem. LLM, například GPT-4, porovná dvě odpovědi. Funguje to však v okamžiku, kdy model, který kontroluje, je lepší než model, který generuje. Pokud například používáte GPT-3.5 a necháte kontrolovat GPT-4, může to fungovat, ale když porovnáváte GPT-3.5 proti GPT-3.5 nebo GPT-4 proti GPT-4, tak to úplně nefunguje.

Já zatím nevím, jak to lépe vymyslet.

Souhlasím s tebou. V té škále, když nejsi schopný metriky změřit, já mám 20 případů, ale potřebuju porovnat tisíc nebo deset tisíc případů, tak samozřejmě necháš to porovnat někomu manuálně, takže zatím nemáme jiný princip. Někde se to dá dělat lépe, když je výsledek více měřitelný na nějaké škále, ale tohle bude výzva – jak to operovat a mít kontrolu, že to je opravdu dobrý výsledek.

To děláme většinou opačně – dávame NPS přímo do chatů a labelujeme, jestli to bylo dobré nebo špatné. Pak vidíš, že dané téma bylo vyřešeno dobře, jiné špatně. Jasně, ne vždy se to týká jen chatu, používá se to na spoustu jiných věcí. Když chceš například napsat článek, už to nevolá ten koncový uživatel.

Výzvy jsou podle mě v tom, že to otevírá jinou škálu problémů, které řeší velmi dobře, ale už nejsou to jednoduché metriky, na které jsme byli léta zvyklí. Není to triviální věc. Určitě ke mě dostaneš i nějaké nápady, protože ta měřitelnost je největším problémem, co mám.

Pokud vezmeme generativní AI zaměřenou na obrázky, funguje to jinak. LLM je jazykový model, a jeho jediná funkce je předpovídat následující slovo ve větě na základě předchozího textu. Proto ho promptujeme, vstupujeme mu text a on na základě toho transformera predikuje následující slovo. Proto si to někdy vymýšlí a dělá „bullshit“, protože jednoduše plní náš příkaz, žádná další inteligence tam není.

Můžeme filozofovat o inteligenci, ale LLM rozumí základům jazyka, ví, jak jazyk funguje. Pokud ho antropomorfizujeme, chápe jazykovou strukturu. Teoretickou otázkou je, jestli to není už forma umělé inteligence v pravém slova smyslu, protože jazyk chápe, ale pojďme dál.

Trochu odbočuji.

Ty ses ptal na tři otázky – první, jestli provozovat vlastní API nebo volat externí službu a jaké jsou rozdíly.

Jsem milovník open source, ale open source LLM zatím není tak dobrý jako OpenAI. Ani ostatní LLM, které jsem měl možnost vyzkoušet, nejsou tak dobré jako OpenAI. BART je dobrý, ale není lepší než GPT-3.5 podle mých zkušeností. Anthropic Claude v2 je lepší, ale stále nedosahuje GPT-4. Z mé vlastní zkušenosti uživatele, kvalita není konzistentní. Používám to poslední tři měsíce a jsou období, kdy to funguje dobře, snažím se mít konzistentní promptování, ale odpovědi jsou velmi proměnlivé a někdy jsou špatné. Konsistence výstupu je otázka sama o sobě a hodně záleží na use case.

Máš sice do určité míry možnost ovlivnit výsledek nastavením hyperparametrů modelu, ale nelze to nastavit tak, aby bylo výsledky deterministické, tedy abys pokaždé dostal stejný výstup.

Jsou techniky, jak s tím pracovat, záleží na konkrétním použití. Například velmi populární je tzv. virtuální bot, což je nějaká knowledge base, kde se zeptáš na cokoliv, například na produkt, a on ti jednoduše sumarizuje odpověď, ať už interně nebo externě pro zákazníka.

V tom případě pomůže předvýběr pomocí semantické nebo vektorové databáze, která ti vyhledá tři, čtyři odstavce relevantního textu, a pak ten LLM má za úkol to jen shrnout. Neříkám, že je výsledek vždycky identický, ale minimalizuje to chyby a nesmysly.

U konkrétních případů záleží na použití. Když řeším technický problém, zeptám se GPT-4, což bývá mnohem rychlejší než hledat ve workflow. Občas je potřeba kód několikrát zkusit, upravit, ale většinou po dvou až třech dotazech máte výsledky za pět minut, zatímco manuálně by to trvalo hodinu.

Když se vrátím k provozu, obecně jsou problémy se škálovatelností, protože modely jsou obrovské. Když mluvím o OpenAI, tak ta služba silně využívá Azure. Někdy to jde znát.

Pojďme se vrátit k limitům. Když používáte OpenAI přímo nebo přes Azure, máte limity stanovené tokeny – tedy kolik dotazů a jak velké texty můžou být. Funguje to dobře pro desítky až stovky uživatelů.

Ale když chceme používat virtuální bot pro tisíce agentů například na call-centrech, tam může být obrovský objem dotazů za minutu a narážíte na limity.

Microsoft nabízí tzv. PTU (Provisioned Throughput Unit), kde za určitou částku si kupujete šířku pásma jako tarif u operátora. Čím víc zaplatíte, tím víc tokenů získáte na volání API.

Problém je, že do nedávna byla cena za PTU vysoká, takže v Čechách nebylo businessově reálné to využít. Ale nyní jsou tady nové možnosti a škálovatelnost, takže už se o tom začínáme bavit.

PTU se začíná vyplácet při asi 300 a více uživatelích, kteří službu opravdu aktivně využívají, například v komunikaci se zákazníky. Berte to ale jako orientační. Není to tak, že když máte 300 uživatelů, automaticky PTU pořídíte, ale je to otázka matematického vyhodnocení a potřeby.

Michal vždy zdůrazňuje, že s PTU máte i výrazně nižší latenci, řekněme o třetinu, a hlavně konzistentní odezvu. Všichni jste to asi zažili, někdy model odpovídá během okamžiku, jindy čekáte deset sekund, než něco začne generovat. To je proto, že API je vytížené.

Možná se vrátím ještě k otázce hostování doma nebo v cloudu. Budoucnost podle mě spočívá v API, protože chci službu konzumovat, nechci se starat o provozování modelu u sebe v datacentru.

Samozřejmě existují menší open source modely, které lze provozovat i v cloudu, například v Azure, kde je možné během okamžiku spustit model jako službu a testovat ho. Ale mít možnost rychle vyzkoušet více variant je super oproti složitému nasazování.

My vedeme interně debatu, zda používat API, nebo si to nasadit vlastní, protože když se to dostane na vyšší škálu, API může stát hodně a vlastní provoz zase vyžaduje velké náklady.

Problém je, že nasazení modelu s 70 miliardami parametrů nepřinese výraznou úsporu oproti API, protože náklady jsou podobně vysoké.

Velký problém je výkon pro češtinu, protože modely nejsou pro ni tak optimalizované, a modely je třeba dále trénovat.

Já jsem obrovský fanoušek open source, pokud to jde, používám ho, protože mi dává svobodu a nejsem nikde „loknutý“. Ale mám k tomu příběh.

Nešlo to jako narážka na Microsoft, to ne, ale slyším často, že lidé používají open source, aby nebyli „loknutí“, ale podle mě je skutečný „lock-in“ v open source, protože provozování těch modelů je obrovská operace.

My nedávno řešili projekt, kde jsme řešili problém velkého počtu dotazů s vysokým počtem tokenů, a to často s retrieval z vektorových databází. Počítalo se až 800 000 dotazů denně, což stojí miliony korun. To jsou šílené částky.

Pak řekneš: „Ano, koupím vám PTU…“

Když to tehdy vzniklo, způsobilo to obrovský randál, který se nakonec nevyplatil. Doufám, že už s tím něco udělali. Druhá věc je, že jsem si řekl: „Jasně, uděláme i Falcony.“ Falcony ze Spojených arabských emirátů se samozřejmě snaží dělat věci co největší. Pak najdete jejich model s 180 biliony parametrů, nastavíte ho podle standardů – nějaký stroj s grafickou kartou – konečně zmáčknete tlačítko play, pošlete dotaz a čekáte 12 minut, než dostanete odpověď. Pak si říkáte, co jsem udělal špatně. Nakonec se podíváte zpátky do dokumentace.

Můžete tam mít nějakou klapku, že jo? A zjistíte, že odpověď trvá 12 až 18 minut na jeden dotaz. Takže tam ztratíte asi 90 % času hned na začátku. Ano, přesně tak. Souhlasím s Michalem, že to směřuje k API rozhraní. Všechno bude API, ale otázka je samozřejmě, že je asi nebudeme sami hostovat. Jsou případy, kdy se finančně vyplatí model nedeployovat. Pokud vám to však vychází, jděte do API, protože to je v současné době nejlepší varianta.

Pokud se vrátím k MLOps, nasazení open source modelu není o mnoho složitější než nasazení jakéhokoliv jiného modelu, jen je to větší, ale principy jsou stejné. Nový problém vzniká v měření metrik. Jak vůbec měřit, že jde o jazykový model, tedy text? Můžeme se inspirovat NLP, ale například řešíme řeč, kdy často stačí nuance jednoho maličkého slova. NLP metriky jsou často pro takové změny neviditelné. Jak tedy měřit? Jak dostat výsledek do ML flow a podobných systémů, kde máte čísla, grafy a můžete porovnat, že tahle instance a tenhle prompting vycházejí lépe než předchozí?

Druhá věc je, jak pracovat s promptem. Představte si, že v produkci máte nějaký prompt a nyní ho verzujete, měníte, jak s tím máte pracovat? Jak spravovat verze promptu? Pokud je prompt přímo v kódu, při každé změně musíte deployovat celou aplikaci znovu. To jsou nové problémy, které musíte řešit. Není to o mnoho odlišnější než standardní problémy, ale pro člověka je to hůře pochopitelné, protože je to čistě text.

Pokud se vrátíme k diskuzi na začátku o DevOps a MLOps, které jsou si hodně podobné, ale LLMOps? K čemu by se to dalo přirovnat spíše? Je to spíše softwarový vývoj, nebo machine learning vývoj? Spíše machine learning vývoj. Nasazení je standardní vývojářská činnost, ale udržovat model, co mám, to už je spíše machine learning, protože už to nemá tak blízko ke kódu, je to o textu a promptování modelu.

Podle mě je to pěkná ukázka, kde leží dobrá abstrakce. DevOps, MLOps i nyní LLMOps mají společné stavební pilíře. Data jako koncept zůstávají stejná, provedení se liší – jednou jsou to texty, jindy strukturovaná data či tensory. Promptování je v podstatě konfigurace samotného modelu.

Další problém je validace výstupu jazykového modelu. Není to často text jako takový. V našem start-upu řešíme, že nechceme textový výstup, ale například strukturovaný výstup, JSON. Někdy však model není schopen vygenerovat validní JSON. Nebo JSON je validní, ale my používáme Pydantic na validaci objektů a model vygeneruje JSON, kde před klíčem má tři mezery. JSON je validní, ale Pydantic ho nenačte. Jak s tím tedy dál?

Začínáte aplikovat regulární výrazy a jiné fígle, protože model pracuje jako statistika a slovně tokeny jdou podle pravděpodobnosti za sebou, a právě teď mu vyšlo, že před klíčem jsou tři mezery. Když přemýšlím o abstrakci z tvého příkladu, DevOps má deterministický vstup i výstup, MLOps má deterministický vstup (data, infrastrukturní kód) a stochastický výstup, k němuž se přidává nějaké hodnocení. U LLMOps máme stochastický vstup i výstup a potřebujeme to nějak řešit.

Mezitím je tam něco obrovského a neviditelného, co nevíme, co přinese. Vnímám to jako opačný přístup. S API vlastně neřešíte machine learning jako takový, řešíte jen backend s náležitostmi standardního softwarového produktu a většinou i frontend. A to je softwarový vývoj. Proto si myslím, že se to opět posouvá k aplikačnímu vývoji, protože už to nemá nic společného s klasickým machine learningem. Samozřejmě potřebujete nějaké schopnosti a přesahy, ale většinou to sedí spíše firmám, které dělají softwarový vývoj.

Souhlasím, pokud jen voláte API, nemáte trénink modelu, ten je drahý a komplexní a zvládají ho jen dvě tři firmy, nejvíc jedna. Nicméně, když začnete LLM využívat k řešení ML problémů či business caseů, změní se to. Karol to uvedl velmi dobře — LLM se posouvají k aplikačnímu vývoji, kde je většinou frontend nebo aplikace, s nimiž uživatelé komunikují. Týmy dělající AI a ty dělající aplikace se proto hodně přibližují.

Na druhou stranu bych nerad odlupoval ML část, protože je základní a velmi důležitá. Pro životaschopnost projektů je třeba tradičně měřit, že to není jen jeden prompt na jednom příkladu, ale že pustíte dávku (batch) několika příkladů a změříte výkon. Ta ML rutina by měla být tam, aby validovala na testovacím datasetu a poskytovala zpětnou vazbu, jak to funguje a kde může být problém. To bych rozhodně zachoval.

U nás také vidíme, že najednou řešíme frontend, větší integraci do systémů, aby se LLM mohl volat přímo, což jsme dřív tolik neřešili, protože jsme většinou jen nahráli výsledky a někdo je konzumoval třeba reportem. Obsluha MLOps tam tedy proniká. Chci klidně meritokracii, takže k ML-ops mám taky co říct, a myslím, že jsem možná jediný v místnosti, kdo to tak vidí.

Shrnul bych, že LLMka jsou pro vás to, co bylo Data Science – black box. Je to black box, který musíte integrovat. Mnoho lidí se bojí, že know-how, jak ten black box funguje, vlastní jen pár firem, které mohou ovlivňovat byznys nebo i životy ostatních. Open source to snaží dohnat díky transformátorové architektuře, ale nemá takové finanční zázemí. Mistral například má ohromné peníze, ale zatím neperformuje tak dobře. LLM jsou velká změna, obdobně jako AutoML, které funguje skvěle a řeší mnoho problémů zcela automaticky. Pro lidi z našeho oboru jsou to black boxy, s nimiž neumí sami pracovat.

Martin, mě zajímá, jak je to u vás ve firmě. Když přišli s požadavkem, že musíte mít chat a AI, jak jste to zvládli? U nás je to složitější, projekty s využitím LLM jsou vlastně externí, tedy provádí je jiná firma, která využívá OpenAI API. Pilotují to a testují interně, kolegové kolem toho pracují.

Globálně mají ambice a dělají to, a když si s nimi o tom povídám, chápu, že je to především záležitost prodejců třetích stran. My interně tu příležitost zatím nedostali. 

To je takový interní zápas v korporaci: třetí strany se umí lépe prodat než interní vývoj. Segment metrik a observability pak řeší někdo jiný, a pokud tomu nerozumíme, nechceme vyvíjet produkt, který nebudeme schopni reálně provozovat. Proto se snažíme přijít na metriky, aby byl provoz možný.

Chtěl jsem ještě říct jednu věc, ale zapomněl jsem ji. Snad není problém, když to doplním.

Ano, možná je tam část aplikačního vývoje, která musí systém provozovat, což je jasné. Jsme teď na vlně hype, která logicky souvisí s tím, že technologie není stará, je relativně nová, mění se skoro každý den. Sledujeme závody hráčů o velikost a kvalitu případů použití. Z hlediska observability zatím řešíme spíše to „vše umí“, ale inženýrská práce je o udržování toho v chodu a podmínkách. Hlavně jde teď o to použít LLM na nějaký konkrétní případ a dodat hodnotu.

Observabilita se zatím odsouvá, ale dožene nás včas. Bude potřeba mít nástroje pro monitoring a provoz. To vše přijde velmi rychle.

Při implementaci use case víme, že je třeba to měřit a vyhodnocovat.

Osobně doporučuji nepouštět LLM přímo ke zákazníkům, nedejte jim možnost komunikovat přímo s modelem. Mějte mezi tím vrstvu, například řízení dialogů nebo živého agenta. Systém je skvělý, ale není dostatečně dobrý na to, aby nezpůsobil zpětnou vazbu v podobě špatné reputace. Jsou tam i otázky ohledně LM injections a podobně, které bychom mohli příště probrat.

Myslím, že jsme se poměrně dost rozepsali. Gartner teď uvedl, že tyto modely jsou na vrcholu hype křivky, takže se můžeme za půl roku sejít a říct si, jak se to posunulo.

Čas se nám naplnil. Rádi vás tu opět uvidíme v podobném složení, každý samostatně příště. Téma rozhodně nevyčerpalo a moc děkujeme, že jste sdíleli své zkušenosti a názory.

Na úplný závěr, těm, co poslouchají a mají MLOps ve své organizaci na starosti, je něco, co byste ještě chtěli dodat, potvrdit, zopakovat nebo doplnit?

Já osobně říkám: začněte s jednoduchým sledováním experimentů a pak postupně přidávejte. Nemusíte hned mít automatizovaný systém, který nasazení modelu obsluhuje celý. Důležité jsou základy – sledovat, co se dá, automatizovat důležité věci a zbytek jen když je potřeba.

Možná jen dodám, že investice do MLOps opravdu stojí za to. Samozřejmě přináší určitou learning curve pro lidi, protože se bavíme nejen o technologiích, ale i o lidech a týmech. Pokud máte jeden či několik ML případů, investice se zásadně vrátí v automatizaci, jednoduchosti sledování a přechodu do produkce.

Já si myslím, že když někdy potkáte data scientista a začnete s ním mluvit o MLOps, určitě mu změníte život. Ti lidé jsou po škole často nezkušení a MLOps je pro ně velký přínos.

Ještě jednou díky, ať vám běží pipeline a modely se přetrénovávají a přinášejí výsledky. Děkuji, že jste přišli a sdíleli své know-how.

Díky za pozvání, rád jsem tu byl. Přeji krásné svátky.

To je vše.

Děkujeme, že jste doposlouchali až sem, a také děkujeme našim partnerům – Big Hubu, Recombee, Intexu, Nano Energies, Live Sportu, SAS.cz, Bistreetu, Colors of Data, Revolt BI a Gudate. Pokud vás zajímá…

Více z české datové scény a z datových technologií globálně najdete na webu datatalk.cz, kde nám můžete nechat svůj e-mail. Nebo se přijďte podívat na jeden z našich meetupů na dejtemes.cz.

Nechť vás provází data.