Podcast

Dobrý den, jmenuji se Jirka Vicherek a vítám vás u dalšího dílu Datatolku. Dnes zde mám vzácného hosta, Vojtu Kopala, ředitele inženýringu (Director of Engineering) ze společnosti Mňus. Ahoj, Vojto.
Ahoj, Jirko.

Vojto, můžete si vzpomenout, že jsi byl hostem jednoho z prvních podcastů, které jsme tady na Datatolku natáčeli. V listopadu 2022 jsi tady byl poprvé a jak možná tušíte, od té doby se ve společnosti Mňus a tím pádem i ve tvém profesním životě událo mnoho změn. Mňus oznámila, že díky poslední investici získala prestižní status jednorožce, takže Vojta nyní „jezdí na jednorožci“, jak se říká, a za ten rok a půl, co jsme se tady ve studiu neviděli, se stalo mnoho věcí. Dnes si o tom s Vojtou budeme povídat, podíváme se na to, co se povedlo, co si řekli, že by chtěli dělat jinak, a jak to vlastně v Mňus mají s umělou inteligencí (AI), zejména s generativní umělou inteligencí.

Takže, Vojto, ten poslední rok a půl musel být slušná jízda. Když jsme tady mluvili naposledy, Mňus byla slušně našlápnutá firma, měli jste asi 650 zaměstnanců. Jak se změnila velikost vaší organizace za tu dobu? Myslím, že to hezky ukazuje nějaký posun a komplexitu.

Myslím, že od té doby se toho změnilo hodně. Momentálně máme přibližně tisíc lidí v rámci Mňus po celém světě. Narostla také naše základna zákazníků, ze tří tisíc na současných pět tisíc, a to jak díky přirozenému růstu, tak i díky akvizicím, které jsme provedli opět po celém světě, abychom mohli vstoupit do různých regionů a posílili naši pozici. Podobně vyrostla i datová organizace. Od posledního rozhovoru jsme měli kolem 11–12 lidí v Data Tribu, nyní mám pod sebou 25 lidí a počet týmů se zvýšil ze dvou na tři.

Pro posluchače, kteří možná celý ten čas nežili ve vašem světě a o Mňus neslyšeli, je dobré zmínit, že vaši klienti jsou hotely a poskytovatelé služeb v pohostinství. Mňus je systém na řízení a komunikaci s klienty těchto hotelů, tedy s návštěvníky, a data jsou u vás součástí celkového produktu a inženýringu. Můžeš to tedy takto stručně shrnout?

Ano, zhruba tak.

Když jsme tady byli před rokem a půl, dívali jsme se dopředu a říkali si, co se bude dít. V té době bylo chat GPT a generativní AI něco zcela nového. Taky jsme mluvili o změnách v oblasti BI a AI, o kterých se ještě dost pobavíme.

Podíváme-li se na organizační strukturu, říkáš, že jste vyrostli ze dvou na tři týmy. Můžeš popsat, jak to teď máte nastavené, jak ty týmy vypadají a co mají na starost?

Předtím jsme měli tým Data Platform a tým Data Projects. Tým Data Platform má na starosti rozvoj naší datové platformy a poskytování této platformy jako služby ostatním týmům jak v rámci výzkumu a vývoje (R&D), tak i celé společnosti Mňus. Tým Data Projects, který původně byl hodně orientován na dodání end-to-end business projektů, se posunul směrem k Data Science.

Jako třetí tým jsme založili Data Insights, který pokrývá datovou analytiku v rámci produktových týmů. Ten Data Insights tým je jakýsi BI - reportingový tým, o kterém jsme mluvili, že ho plánujete založit minulý rok. Co to přesně znamenalo? Přesunuli jste nějaké lidi z Data Projects do Data Insights, protože nebyli data scientisti, a je to logický? Jak to bylo personálně?

K nějakému přesunu dochází, ale ne tolik přesunu datových analytiků, spíše přechodu některých z nich do Data Science rolí díky personal development plánu. Data Insights tým tvoří jádro analytiků, kteří pracují na větších projektech napříč R&D a celým produktem, ale nově tam patří i produktoví analytici (Product Data Analysts), kteří jsou embedded v produktových týmech a pracují přímo v rámci jednotlivých produktových tribeů.

To je tedy hlavní změna od minula. Rozhodli jsme se totiž dát tyto role blíže produktovému managementu a inženýrům, aby se soustředili na konkrétní domény a vývoj, který ty jednotlivé triby řeší.

Narazili jste pak na to, že jak produktový engineering rostl a vznikly nové triby, datoví analytici zůstali trochu opuštění ve svých rolích. Nechali jste je tam, nebo teď je zase stahujete do nějakého centra?

Nejedná se o centrální řešení, spíše je to krok k maticové organizaci. V rámci Mňus je to téma, o kterém se budeme bavit do budoucna. Zatím na takovou velikost nejsme připraveni, ale v datové organizaci jsme se rozhodli ho aplikovat.

Datoví analytici i data scientisti jsou stále embedded v produktových týmech, ale změnila se jejich reportingová struktura. Nově reportují svým people managerům, a to v Data Insights týmu je Kristýna, která je engineering manažerkou pro Data Insights a zároveň people manažerkou pro embedded datové analytiky.

Podobně to funguje i v Data Science týmu, kde data scientisti embedded v produktových týmech nově reportují manažerovi toho týmu. Mají tedy šéfa, který jim rozumí.

Přesně tak. Manažer může zajistit dobrý personal growth, rozvoj a řešit odborné záležitosti podobné těm, které řeší jejich kolegové. Díky tomu se mohou víc bavit o nejlepších postupech a řešení problémů.

Znamená to nějaké schůzky navíc? Například víc se potkávají embedded analytici a sdílejí know-how?

Určitě přibyly schůzky navíc, ale některé jiné byly přesunuty z produktových týmů. One-to-one schůzky jsou nyní pod novou manažerkou.

Více pak tráví času společně i na teambuildinzích, srazech či workshopech. Minulý týden v Praze proběhl workshop, kde se datoví analytici z produktových týmů poprvé setkali a mohli si naplánovat, co zlepšit ve spolupráci a podpoře produktových týmů.

Mluvíme tedy o úrovni týmu, tribu nebo cross-team spolupráci?

Na úrovni tribu se snažíme nastavit společné cíle a směr, ale regiony jako Data Platform, Data Science a Data Insights fungují většinou jako samostatné jednotky. Pokud je potřeba spolupráce, řeší se to formou týmů, které spolupracují na zadání nebo řešení závislostí.

Kdo by podle tebe z takového nastavení měl mít prospěch? Ty sám jsi říkal, že se připravujete na větší komplexitu a cross-funkčnost tímto stylem, že jste early adopters. Od jaké velikosti organizace má podle tebe smysl takové uspořádání?

Asi prvním faktorem je velikost organizace. U nás také hodně souvisí komplexita produktů, protože nevyvíjíme jen jeden produkt, ale kombinaci B2B částí pro hotelní operace, fintech a guest experience, což jsou samostatné oblasti s minimálním datovým překryvem.

S růstem datových oblastí a měnícími se potřebami produktových týmů bylo potřeba, aby datoví analytici měli lepší možnost adaptovat se na požadavky produktových týmů. Proto jsme je „přizvali zpět domů“, abychom si ujasnili, co je aktuálně potřeba pro produkt a R&D, jaká je role datových analytiků, a aby jim to pomohlo lépe podporovat produkt a R&D.

Původně to fungovalo dobře, protože jsme začínali s centralizovaným týmem, který datové analytiky vychoval, pomohl jim porozumět produktu a městskému prostředí. Když pak přecházeli do produktových tribeů, zvládali to díky této zkušenosti.

S dalším růstem jsme ale začali najímat nové datové analytiky přímo do produktů a ztratili jsme návaznost i znalosti, což způsobilo problémy.

Nyní restartujeme datovou kulturu, abychom analytiky nestavěli do pozice izolace, ale aby byli zapojeni a měli přirozenou vazbu na data drive.

To zní jako šťastnější datoví analytici, kteří ví, kam patří, a mají více podpory v osobním a odborném růstu. V tom vám držím palce.

Jak zvládáte žonglování mezi performance a dodávkami, tedy produktem, a na druhé straně people growth, individuálním kariérním růstem? Probíhá o tom diskuze na úrovni ředitelů? Je to něco, co plánujete, nebo už s tím pracujete? Jsou to dvě odlišné oblasti?

Teď je to zajímavá otázka, protože probíhají další změny v rámci R&D a způsobu, jak plánujeme větší dodávky produktů. Souvisí to se zaváděním „misí“ do R&D – jak jednotlivé tribe spolupracují na větším cíli, který je před námi pro tento a příští rok.

Tyto mise vyžadují užší spolupráci mezi triby, kde potřebujeme inženýry z různých týmů, aby spolupracovali.

Co je typická mise, kterou máte nyní na stole? Jak velká nebo rozčleněná je?

Máme větší mise, které se pak rozpadnou na menší podmise. Spíše je to kampaň – například Severní Amerika je oblast s vlastními specifiky, na které pracujeme.

Jsou zde standardní mise, například systém loajality, který je důležitý vzhledem k posunu směrem k enterprise klientům. Jsou také specifické mise týkající se konkrétních klientů nebo značek, které chceme získat.

Tyto mise jsou tedy hlavním aspektem řízení a prioritizací v R&D?

Ano, je to nástroj, jak komunikujeme, na čem pracujeme, jak získáváme podporu vedení, kam směrujeme kapacity a na co jednotliví lidé budou pracovat.

To se pak samozřejmě odráží i na nasazení datových analytiků a data scientistů v rámci těchto misí.

Děkuji za tento vhled. Myslím, že je velmi cenný a často v diskuzích v oboru o těchto praktických aspektech slyšíme málo, a přitom zásadně ovlivňují výsledky a dopad vaší práce.

Pojďme teď k tomu „slonu v místnosti“. Od našeho posledního rozhovoru v listopadu 2022 se toho v Mňus hodně událo, noví klienti, růst i finance, ale také příchod velkých jazykových modelů (LLMs) a generativní AI. Jak moc vám příchod LLM a Gen AI změnil mise, cíle, priority a produktovou roadmapu během uplynulého roku?

Je na to velký tlak, abychom s něčím takovým pracovali. Máme dva přístupy, jak pracujeme s AI a data science. Jeden je v souladu s hype kolem Gen AI a LLM, ale přistupujeme k tomu pragmaticky – je to nástroj k řešení konkrétních problémů našich zákazníků.

Není cílem nasadit AI a LLM jen proto, abychom mohli tvrdit, že je máme. Paralelně pak máme tradičnější přístup ke strojovému učení a data science pro klasické problémy, jako je dynamické oceňování nebo optimalizace provozních procesů hotelů.

Je všechno toto v kompetenci data science týmu nebo do toho zasahují i data insights nebo data platform týmy?

Spolupracujeme napříč všemi týmy. Většina aktivit je řízena misemi, které směřují k využití data science a machine learningu v produktech. Role z data science a data engineeringu jsou přímo zapojeny do těchto misí vedených příslušnými týmy.

Vedle toho existují projekty v rámci data drive, které podporují tyto mise, například rozšiřování datové platformy, schopnosti kolem MLOps nebo nyní i LLMOps.

Co pro tebe znamenal příchod generativní AI? Jak jste k tomu přistoupili?

Minulý rok jsme byli opatrní, jak zapojit ChatGPT a podobné nástroje do našeho fungování. Měli jsme štěstí na spolupráci s Microsoftem a Azurem, díky čemuž jsme mohli začít pracovat s Azure Open AI v bezpečném izolovaném prostředí, na které jsme zvyklí.

Díky tomu jsme mohli dát zaměstnancům jasný směr, s čím experimentovat, raději než aby používali Open AI přímo s našimi daty a nevěděli, co se s nimi dál děje.

To byl začátek, kdy i v rámci preview Azure…

[Text zde končí].

Pokud budete chtít, mohu text dále rozdělit do kapitol, upravit podcastové popisky nebo připravit shrnutí.

OpenAI jsme začali experimentovat více s našimi interními projekty. Jedním z těchto projektů byla spolupráce s týmem zákaznické podpory a analýza jejich tiketů, případů (caseů), abychom pochopili, jaká nová témata se objevují na podpoře. Chtěli jsme jim také pomoci zredukovat backlog nově příchozích případů, se kterými pracují, a umožnit jim automatizaci v rámci tohoto procesu.

Předpokládám, že u 5000 klientů, kterými jsou hotely používající váš systém, je to skutečně kritická softwarová infrastruktura, na které fungují.

Co to tedy znamenalo? Zní to velmi triviálně, a mám pocit, že to mnozí trivializují – že pustíme na to LLM, máme to ready v Azure, jednoduše přidáme modul a je to vyřešené. Díky Jirkovi Vinárkovi, který se tímto tématem zabýval na DataMeshi, mám tušení, jaká byla evoluce tohoto projektu?

Pro nás byla práce s LLM jen jednou z komponent. Pro mě je to i nyní součástí většího řešení a LLM je jedna z krabiček, které pomáhají v rámci datové vědy a celkové myšlenky. Určitě se snažíme vyhnout názoru, že LLM vyřeší všechno.

Když se podíváme na spolupráci se zákaznickou podporou, konkrétně jsme používali OpenAI GPT pro základní sumarizaci celé konverzace mezi supportem a zákazníkem, abychom následně mohli vytáhnout téma tiketu. K tomu jsme využívali klasické metody, jako je Bertopic, pro zjištění tématu, o kterém tiket je. Dalším krokem bylo hierarchické klastrování pomocí HDBSCAN, abychom zhlukli jednotlivá témata do několika hlavních, na jejichž základě pak stavíme reportování nebo prezentaci zpátky zákaznické podpoře.

Výsledkem je lepší označování tiketů a jejich monitoring – je vidět inflow (příliv) tiketů. Co se změnilo? Otevřelo vám to nové možnosti, jak na to nahlížet? Nebo to zefektivnilo a zoptimalizovalo způsoby, kterými jste tomu dříve přistupovali?

Jsou tam dva výstupy. Prvním je reporting a sledování nových trendů – Když se objeví nové téma v tiketech, je to sledovatelné pomocí reportů. Druhým je přímá integrace do Salesforce, která umožňuje cílit jednotlivé případy a témata zákaznické podpory na experty, kteří rozumějí dané produktové doméně. Tím optimalizujeme čas potřebný k vyřešení případu, protože již od začátku na něm pracuje správný člověk, který tomu nejlépe rozumí. Už se nestává, že by tiket „přepadával“ mezi lidmi – „toto není moje téma, v tomhle ti pomůže kolega lépe“… Obešli jsme tedy triáž, kdy všechny tikety padají do jednoho backlogu a úzce několik lidí rozhoduje, komu daný případ přiřadit. Ten backlog se může v různých momentech značně zvětšit a trvá, než se dostane k výřešení i jednoduchého tématu. To by se podařilo výrazně urychlit, kdyby už od začátku na daném případě pracoval správný odborník.

Jaká je tedy ta role LLM v tomto procesu? Používáte jej čistě pro sumarizaci, nebo uvažujete, zda by LLM mohl nahradit některé další komponenty? Jak na toto obecně nahlížíte? Není to spíš otázka analýzy nákladů a přínosů? LLM jsou stále nákladná technologie a vy je chcete nasadit tam, kde přinášejí nenahraditelnou hodnotu, zatímco jinde by se věc dělala lépe jinak? Je to otázka přesnosti versus nepřesnosti? Protože někde je možné tolerovat generalizace a celkově sledovat trendy nad množstvím tiketů, kde chyba nevadí, zatímco u jednoho e-mailu může chyba ve vyhodnocení sentimentu vést k reputačnímu riziku.

Ve spolupráci se zákaznickou podporou jsme nad tím přemýšleli inkrementálně. Začali jsme sumarizací a tematickou analýzou tiketů. Paralelně jsme se zaměřili na naši knowledge base a způsoby, jak data uložit do vektorové databáze, aby bylo možné kombinovat pochopení tématu případu s doporučenými řešeními.

Myšlenka je, že by to vždycky směřovalo k agentovi zákaznické podpory, který obdrží navrhované řešení, zkontroluje ho a pak odešle zákazníkovi – tedy aby vždy byl prvek lidské kontroly.

Tento přístup jsme aplikovali již od začátku, kdy jsme začali používat OpenAI a přistupovali jsme k projektu jako k gated přístupu s kontrolou výstupů ještě před jejich předáním zákazníkům.

Zmínil jsi téma MLOps a LLMOps, což je odlišná disciplína. Máte v produkci takový systém. Jak jej testujete, jak jej monitorujete? Co bylo třeba udělat na straně platformy, aby to mohlo běžet a bylo možné do systému zařadit cykly CI/CD?

V rámci LLMOps jsme vyvinuli koncept „LLM as a Judge“, kde vyhodnocujeme chování modelu pomocí srovnání s referenční pravdou (ground truth). Tento přístup nám dává kvantitativní skóre, které ukazuje vývoj modelu v čase.

To jsme museli udělat ještě předtím, než jsme začali optimalizovat model, promptovat jej, případně uvažovat o fine tuningu – potřebovali jsme mít metriku a zpětnou vazbu, abychom věděli, že se model skutečně zlepšuje a že investice do času a peněz má smysl, zejména vzhledem k nákladům na provoz.

Můžeš tento koncept „LLM as a Judge“ přiblížit méně zkušeným posluchačům? Není vše tak jednoduché, že jedno LLM skóruje druhé, které je novější generací, a je proto nadřízeným? Narazili jste na nějaká úskalí? Je to opravdu tak jednoduché?

Jednodušeji řečeno, máme základní model GPT-3.5, který sumarizuje, a model GPT-4, který slouží jako „rozhodčí“ (judge) a porovnává chování modelu s referenční pravdou. GPT-4 poskytuje skóre a vyhodnocuje, jak se model vyvíjí.

Vše je zabalené v rámci MLflow, který běží na platformě Databricks a orchestrace probíhá tam.

GPT-4 sleduje všechny odpovědi při testování modelu, není to však živá operace v produkčním prostředí. Model se hodnotí před nasazením na základě manuálně vytvořených datasetů, které slouží k porovnání a vyhodnocení.

Je to tedy taková soutěž mezi modely, kdy porovnáváte vývoj a výhody, nevýhody jednotlivých verzí. Když se trochu upraví prompt nebo nasadí fine tuning, sledujete pomocí skórování, zda došlo ke stabilnímu a dlouhodobému zlepšení chování modelu před tím, než jej pustíte do produkce.

Jaké jste si odnesli poučení (lessons learned)? Něco, co byste před rokem nečekali?

Například, že i malé změny v promptu mohou mít velké dopady – je to neintuitivní a promptování je velmi silná disciplína.

Stále s fine tuningem váháme, protože je zatím velmi drahý. Hledáme cesty, jak se mu vyhnout nebo ho odložit.

Důležitá část conceptu LLM as a Judge je i zajistit, že odpovědi jsou bezpečné a že model nelze snadno „provokovat“ k nevhodným nebo nechtěným odpovědím, například obsahujícím vulgarismy. Hodnotíme nastavení promptu tak, aby modelové odpovědi byly „safe“.

Je to tedy více management rizik halucinací a útoků (např. prompt injection) než hodnocení výkonnosti modelu z hlediska užitečnosti pro uživatele.

Zpětná vazba (feedback loop) je spíše Q&A, tedy ověření, že model funguje, jak má z pohledu kvality odpovědí a že nezpůsobuje problémy v byznysu.

Získávání zpětné vazby od uživatelů pak probíhá v produktu přímo, například formou hlasování či hodnocení kvality odpovědí.

Celý vývoj modelu je spojen s konkrétním cílem a výsledkem, který souvisí s uživatelským „disengagementem“, jak jsme probírali v minulém rozhovoru. Snažíme se totiž, aby uživatelé s naším produktem trávili co nejméně času.

Popiš prosím blíže koncept uživatelského „disengagementu“, to mi byl největší wow moment.

Většina B2C produktů – sociální sítě či jiné platformy – se snaží udržet uživatele co nejdéle a maximalizovat jejich zapojení (engagement). Naopak naše filozofie v Muse je zaměřena na hosta (guest experience), aby měl co nejlepší zážitek.

Role zaměstnanců hotelu je pak zaměřit se na hosty, ne trávit zbytečný čas s naším systémem. Nechceme, aby zaměstnanci byli „data entry specialists“, kteří přepisují údaje z dokladů do počítače a prodlužují fronty při check-inu.

Cílem systému je, aby hotelový provoz byl co nejefektivnější a aby zaměstnanci strávili s naším systémem minimum času.

To je právě to, čemu říkáme uživatelský disengagement – metrika, na kterou se soustředíme v rámci uživatelského zážitku při rozvoji produktu.

Proto vyvíjíme a integrujeme AI do našeho produktu – abychom ušetřili čas zaměstnancům a umožnili jim věnovat se hostům.

Jak daleko jste v této oblasti? Co znamená, že AI integrujete do produktu?

Zatím, když mluvíš o tiketech, je to spíš interní systém nebo back office, který přímo v běžném produktu neběží.

Jaká je první mise integrace LLM přímo do produktu? Kdy umožníte zákazníkům komunikovat s AI? Bude to chatbot?

Nebude to chatbot. Chatboti jsou oblast, kde musíme být velmi opatrní a kde vidíme nebezpečí. Nechceme, aby uživatelé komunikovali přímo s LLM bez kontroly.

Zaměřujeme se spíše na využití LLM například ke zlepšení vyhledávání (search). Například najít relevantní informace v helpu nebo knowledge base, ovládat systém pomocí přirozených jazykových příkazů, nebo dotazovat se na BI produkt a získávat rychlé insighty – ať už pro manažery hotelů nebo frontdesk.

Na jedné straně je to knowledge base a vyhledávání, na druhé výstupy BI.

O BI jsi také mluvil – slyšel jsem, že BI je vyřešené, stačí nasadit chatbota nad data lake house a ptát se, co chcete.

Zdá se, že tomu často lidé nerozumí, jak k tomu přistupujete vy?

Na BI většinou chybí tematická vrstva, znalost o tom, s jakými daty uživatelé pracují.

V rámci spolupráce s GoodData připravujeme nové řešení reportingu v rámci systému.

Důvod volby GoodData je jejich přístup API first a code first definic, který umožňuje jasné nastavení metrik a modelu.

Na tomto základě už lze využít datový model GoodData spolu s přirozeným jazykovým vstupem uživatele k vytvoření konkrétního dotazu. Ten se pak zpracuje přes API GoodData, které vrátí potřebné insighty.

Díky definovanému datovému modelu je jasná struktura, podobně jako u SQL dotazu, ale API dotaz je přitom srozumitelnější a strukturovanější – na rozdíl od velmi obecného SQL, který může být složitý a nejednoznačný.

Text přepsaný do spisovné češtiny:

Je většinou hodně jasně daný, takže je to celkem přímočarý požadavek na to stoprocentně přeložit, proč a v jakém kontextu. Když se zeptám jinak: kdybyste neměli spolupráci s GoodData, bylo by tedy potřeba velmi správně a důsledně nadefinovat datový model nad všemi vašimi sklady a zdroji dat, aby to potom fungovalo? Takže ta mezivrstva, ten překladač, co je co a co to znamená, je ten chybějící prvek, který lidé většinou nevidí?

Přesně tak. Je to něco, s čím nám hodně pomohli, protože nám poskytli kapacitu ze své strany na vybudování toho, a my jsme to nemuseli vyvíjet sami nebo nějakým způsobem řešit na naší straně. Bylo by to celkem přímé, vlastně požadavky na stoprocentní přeložení, proč a v jakém kontextu. A to je pro nás dodnes chybějící článek: to, co zaměstnanci mají v hlavě, to, co implicitně vědí o byznysu, a to, co my reálně zakládáme do naší aplikace. Tam je potom ten chybějící přechod – co vše ještě musíme někam uložit, zaznamenat to, co zaměstnanci mají v hlavě, v rámci nějaké školy, jak ten proces funguje v hotelu, a co my nezakládáme do našeho řešení.

Je s tím nějak spojený Makro, tedy ten jejich analytický jazyk? Jsou to propojené nádoby, nebo je to něco úplně jiného?

To je vrstva níž – Makro je v rámci GoodData, ale potom v rámci API už používáš hodně high-level. Tohle jsou metriky, dimenze, které jsou připravené, a můžeš použít i Makro samozřejmě pro dotazování, ale tam už to není potřeba. Tohle je metrika, tohle jsou dimenze, na které se ptáš, tohle jsou parametry, a tohle potřebuješ vygenerovat pro ten API dotaz z Natural Language.

A vy GoodData používáte vlastně takto jako headless v této části? Jak to máte jinak s datovým stackem? Je tam nějaký posun? Ty jsi teď říkal Databricks, jste na Azure, předpokládám, že vizualizační vrstva v těch insights bude tedy Power BI. Když se podíváš na ten datový stack, co jsou pro tebe důležité části a jak nad tím uvažuješ? Proč je pro vás Databricks tak klíčová technologie?

Databricks od začátku kombinuje všechny části – Data Engineering, Data Platformu, Data Science a Data Insights Analytics. Jak je teď máme v Azure Databricks k dispozici, tak pro každou roli tam je prostor a nástroje, jak dělat jejich práci. Ať už SQL Warehouses, propojení přes Unity katalogy, všechna data, která máme v rámci Data Lakeu a Data Formatů.

Také základní dashboarding pro datovou analýzu a získávání insights. Pracuje se i na integraci AI asistenta do prostředí Databricks, takže tam už nějaký čas máme i nápovědu nebo někoho, s kým si můžeme povídat o tom, proč můj kód nefunguje. Tohle nám dává dostatečné prostředí pro vývoj i v rámci Machine Learningu.

Databricks je nativně propojený s MLflow standardem, takže všechno, co děláme v rámci Databricks, je přenositelné do dalších platforem, včetně Azure ML. Spolupracuje s Hugging Face marketplace – Machine Learning modely i LLM modely jsou k dispozici přímo v Databricks.

Pro interní projekty Databricks využíváme i pro nasazování a model serving. Momentálně, když spolupracujeme na produktových misích, pracujeme i s platform engineeringem na tom, jak nasazovat naše výstupy do produktu. Za poslední rok v rámci naší architektury nastal velký posun, začaly se objevovat samostatné služby, nejen velká monolitická aplikace, monolitická databáze. Hledáme způsoby, jak dostat i nějaké dodatečné modely přímo jako samostatné servisy. To je momentálně to, co řešíme.

Například abychom posunuli vývoj nebo byli schopni využívat LLM přímo v produktech, řešíme to momentálně v rámci .NETu a C# jako samostatnou službu, protože výsledek je na unikátní API klíč pro prostředí Azure OpenAI.

Super. Je tam ještě něco, co bys chtěl zmínit z toho stacku, co je pro vás zásadní, nebo co ti je líto, že jste nepoužívali dříve? Jak se díváš na rozvoj stacku?

Takže říkáš, že model je servis a v té vaší infrastruktuře a prostředí ho povyšujete, vývoj vám velmi nahrává, takže jste spokojení. Moc se netestuješ, nekoukáš na jiné možnosti. Jak se díváš třeba na Microsoft Fabric?

Téma Microsoft Fabric… Když ho představili, říkal jsem si, co mám dělat: jestli to mám celé otočit a začít přesouvat směrem k Microsoft Fabric, protože na první pohled vypadá, že spousta těch problémů, které jsme řešili třeba před třemi roky, je teď vyřešená v rámci jedné platformy. Ale pořád v experimentech vidím prostor. Databricks nabízí víc směrem k Data Science a práci s modely. Vyhovuje nám způsob nasazování změn, který je spíš orientovaný na software engineering.

Finance pořád pracují s Power BI, už je možné připojit Git repository, je tam rozumnější CI/CD lifecycle pro nasazování nových reportů. Je zajímavé, jak každá aplikace chce být platformou, takže se rozšiřují všechny od Snowflake po Power BI, čímž rozšiřují value chain a použití. Dříve to byly komplementární „kostky lega“, co do sebe zapadaly, nyní se požírají navzájem a jsou si konkurenty. A to i uvnitř jednoho stacku a hyperscaler providera.

Co by tě přesvědčilo přesedlat na Fabric? Opět máte brutální investici do Databricks a vlastní implementace, jak to vidíš?

Obecně mám pocit, že spousta lidí má vždycky „trávu zelenější“ na druhé straně plotu. Když s něčím děláš několik let, vidíš všechny chyby. Jak přemýšlím o infrastruktuře – co by mě přimělo zvažovat změnu?

Jde o rozšíření Fabric a jeho spolupráci s Databricks ekosystémem. Fabric má podporu pro datalake a napojení na Databricks, ale pořád tam chybí drobnosti, které by mi komplikovaly život.

My jsme hodně investovali do Unity katalogu v Databricks a One Lake ve Fabricu staví něco podobného, takže mi nechybí přenositelnost. Když jsme investovali do data governance a access managementu v Databricks, potřeboval bych snadný způsob, jak to dostat do Fabricu. To je praktická věc.

I v jednotlivých komponentách Fabricu vzali produkty, které už existují delší dobu, a vylepšili je, ale například Azure Data Factory stále nativně nespolupracuje s Unity katalogem Databricks. Je dost bolestivé použít Data Factory s Databricks a SQL Warehousing v Unity katalogu.

To jsou věci, které tam chybí a nepřesvědčují mě, abych do toho šel. Žijeme v Microsoft prostředí od začátku – 365 Office, Azure Active Directory, všechno máme. Je to východisko, kterým můžeme jít, třeba až Fabric dozraje, ale momentálně to nepovažuji za výrazné zlepšení vůči tomu, co máme. Hodně věcí funguje a bylo by náročné je přesouvat.

Vzpomínám si na debatu v podcastu s Michalem z Microsoftu, kde bylo téma migrací. Azure Data Factory funguje, ale přechod na Airflow by byl bolestivý.

Momentálně používáme Databricks workflows na plánování, Data Engineering pipeline i Machine Learning modely.

Jste „vested“, rozumím.

Ano, jsme tam.

Když se podívám na rok a růst GenAI, ke kterému přistupuješ opatrně a racionálně, považuješ ho za nástroj k automatizaci. Cením si toho, občas mám pocit, že všichni vidí jen chat GPT, ale ne GPT. Jak se díváš na další pokračování, jak GenAI spolkne tradiční AI, jak třeba Mark Andreessen říkal „software is eating the world“, tak „is GenAI eating software development“?

Na začátku jsme se bavili o tom, jak tě to naučilo správně formovat dotazy při práci s GPT. To je směr, kterým se GPT ubírá – jak přeložit model světa nebo dat, aby sloužil účelu.

Už se nejedná jen o textové informace pro LLM mode, ale jak zakódovat složitější struktury, aby byly použitelné pro vyhledávání či dotazování v grafovém světě, když chceme pracovat například s chemickými nebo biologickými daty a mít dataset, na kterém je LLM natrénovaný.

To je směr, kam se vývoj posouvá – abychom se mohli oprostit od toho, že LLM je jen textové, ale aby datová základna byla komplexnější.

Vždy je to jen část širší skládačky AI a machine learningu. Půjde to kombinovat s tradičními postupy.

Také teď o tom přemýšlím s kamarády, jak to vidíme do budoucna. LLM potřebuje získat data, která dokáže dále odvozovat, prezentovat nebo shrnout uživatelům. Mnohá data, na kterých LLM pracuje, je třeba připravit tradičními metodami v machine learningu.

Například časové řady, sledování trendů chování uživatelů, profilování uživatelů, shrnutí jejich chování a preferencí do vektorů, se kterými pak může LLM pracovat, nebo je převést do textové formy, se kterou dokáže LLM pracovat.

Pokud tě správně chápu, říkáš, že čím více budeme mít GenAI a LLM, tím větší bude potřeba data science?

Ano, čím více bude LLM použit pro reálné problémy i v rozhodování, tím víc je nutná příprava dat vědci.

To vede ke kompozitním AI modelům, kde LLM je jedna „krabička“, která kombinuje funkce a schopnosti – například volání dalších funkcí, získávání dat, odvozování informací. Je třeba doplnit kapacity, které LLM nativně neumí, například plánování či scheduling, což jsou již vyřešené problémy, které není potřeba přepisovat do LLM.

Kompozitní AI modely rozkládají problém do několika částí, každá řeší konkrétní část procesu v řízení firmy, LLM pak vše spojuje nebo aktivně používá jako agentní systém.

Pro mě je to něco jako rozpad monolitických aplikací na microservices.

Přesně tak. Servis, který si umí naplánovat, jaké zdroje potřebuje, dostaneme k agentovi, který v nějakém světě dalších služeb komunikuje, získává informace a zadává další požadavky těmto službám.

A co ty jako odborník, když to natáčíme v polovině března a poslední AI hype tvrdí, že programátoři nebudou mít co dělat, jak se díváš na GenAI revoluci, AGI a její dopad do reálného světa a software engineeringu?

Já přemýšlím, co bude za rok, co to znamená. V rámci hospitalety a komunít jsme tady od toho, abychom řekli, co AI znamená pro hospitaletu a kde budeme za rok.

Pokud to hned nepodpoříme a nebudeme tlačit směrem, jak to chceme mít, je nereálné říct, co se objeví.

Máme nějakou vizi, jak moc budeme akceptovat AI asistenci, která nám bude říkat, co máme dělat a jak si usnadnit život.

O tom jsme již mluvili – Spotify nám teď vybírá písničky, později i filmy, a bude vybírat vysoké školy.

Možná budeme plánovat DNA, říkat si, co jíst, a to už probíhá, ale spojí se to do jednotného systému. Budeme mít „kámoše“, který se o nás postará, řekne, jak žít život.

Digitální maminka – řekne, jak žít, dá scoring, jestli se nám daří, a pokud chceme být úspěšní, poví nám cestu. Anebo jestli chceme relaxovat, taky tomu nasměruje.

Vybereme si postavu a kampaň a budeme hrát sami se sebou jako v Sims.

Je to budoucnost, na kterou se těšíš, nebo spíše vidíš obavy?

Spíš se toho bojím, obávám se, že nevím, co s tím a jak připravit příští generaci, jak v tom žít.

Pro mě už teď mladší generace, které chodí do škol, je svět sociálních sítí něčím, čemu moc nerozumím, s čím jsem se odtrhl.

Za pět až deset let, co bude AI znamenat a jak na to budeme nahlížet?

Jsme zvyklí žít určitý život, ale pro příští generace to bude úplně jinak.

Budou mít kamarády v podobě AI asistentů, možná už nebudou existovat aplikace jako takové, ale jen asistenti, s nimiž si budou povídat a které si nakonfigurují.

Pokud byste potřeboval/a ještě něco upravit nebo dodat, dejte prosím vědět.

který bude jednoduše optimálně nadefinovaný pro ně. Jsou to mezilidské vztahy, já tam mám naději a ta moje naděje spočívá v tom, že vás ještě dlouho umělá inteligence neobejme, nevyvolá vám oxytocin a ty chemické reakce v hlavě, v játrech a v hormonech.

Možná jsme teď z určitého pohledu jeli v tomto závodě s dechem (kyslíkem) a snažili jsme se optimalizovat a quantify self, velmi jsme se snažili být co nejvíce robotičtí a co nejvíc matematicky optimální.

A možná narazíme na to, že toto už bude nějaký standard, kdy se technologie budou optimálně starat o věci kolem nás a my můžeme hledat něco víc. Budeme všichni filozofy, jako naši anticko-řečtí předchůdci, zatímco ti naši AI „otroci“ udělají vše potřebné, abychom my mohli posedávat někde na schodech a povídat si o smyslu života.

To by se mi líbilo, přestože je to určitě naivní představa. Asi takto bude fungovat jen pro některé lidi, jak ostatně funguje svět a jak s tím lidé žijí.

A tady už se dostáváme k apokalyptickým scénářům, kdy se společnost rozdělí na ty, kteří budou ochotní žít ve světě, kde technologie fungují takovýmto způsobem a pomáhají, a vlastně jste prakticky volní od všeho, co byste normálně měli dělat.

A pak budou lidé, kteří si řeknou: „Ne, já tady prostě půjdu farmářit někde a odtrhnu se od zbytku světa.“ Kde budete vy? Na farmě?

Já si myslím, že budu na farmě nebo někde na pláži na nějakém ostrově, prostě s minimem věcí, které potřebuji k životu, a budu spokojený.

Tak vám přeji, abyste byli spokojení.

Děkuji moc, že jste sdíleli tu „water ride“, tedy poslední rok a půl, který byl skutečně mazec, a tady jsme ho prolétli takhle hopem a skokem.

Dokážu si představit, že za každou tou jednou větou jsou desítky a stovky hodin práce, rozhodování a spousta kilojoulů energie.

Držím vám strašně palce, jsem hrdý na to, že Mews vzniká tady v Praze, že máme dalšího jednorožce (Unicorna) nebo dalšího hráče na globálním trhu.

O to víc mě baví koncept User Disengagement a hrozně bych si přál, aby se stal mainstreamovým.

Zároveň se trochu bojím, o čem budeme mluvit za rok, za rok a půl a jak to bude vypadat a co z toho, co jsme si dnes řekli, vlastně bude ještě pravda.

Věřím, že to bude stejně zábavné jako dnes.

Děkuji moc.

A to je všechno.

Děkuji, že jste poslouchali až sem.

Děkuji také našim partnerům: BigHubu, Intexu, Sasce, Bystrytu, Colors of Data, Revolt BI, Good Data, Kebule, eMarku, Karl Data Company a Data Mindum.

Pokud vás zajímá víc, navštivte naše stránky datatalk.cz a přihlaste se k odběru našeho newsletteru.