Podcast

Dobrý den, moje jméno je Jirka Vecherek.

Ahoj, tady Karol Šmánek.

A vítáme vás u dalšího dílu Datatolku.

Koho máme dneska za vzácného hosta, Karle?

Dneska tady máme mého kamaráda a data science manažera v Albertu, Martina Hronce.

Ahoj, Martine.

Ahoj, tě.

Martine, můžeš vlastně pro ty lidi, kteří tě neznají, stručně se představit?

Jasně, moje jméno je Martin Hronec, jsem data science manažer v Albertu, vedu tým, myslím, že momentálně nás je šest data scientistů slash data inženýrů slash MLOps inženýrů. Robím při tom PhD v kvantitativních financích na Institutu ekonomických studií na Karlově univerzitě. Předtím jsem pracoval v kvantitativním investičním fondu, v podstatě v podobném data science duchu jako teď.

A jak dlouho jsi v Albertu?

V Albertu budeme brzy dva roky. Nastupoval jsem hluboko za covidu, přebíral jsem věci a rovnou opustil centrálu, takže to byly zajímavé časy.

Jak si mám představit, že vlastně Albert funguje? Já to asi trošičku vím, protože spolupracujeme, ale můžeš vlastně pro naše posluchače říct, co jsou ty hlavní use case, hlavní oblasti působnosti a jestli jsou vlastně lokální nebo mají globální charakter? Jaké projekty spadají na váš tým?

Jasně. V podstatě to funguje tak, že my jako data science oddělení jsme zdrojem expertízy, ale nevybíráme si sami projekty, protože nejsme schopni posoudit, kde je největší přidaná hodnota. Typicky přijde někdo z firmy, z jiného oddělení, nebo můj šéf, vedoucí celého data analysis oddělení, a řekne: „Hele, mohli bychom dělat toto.“ A já na to přijdu a řeknu: „No, možná ne úplně, protože nemáme taková data, nebo naopak povím: OK, to by stálo za to, ale potřebujeme nějakou chvíli času na to, abychom ověřili, jestli je to vůbec možné.“ Následně se o tom bavíme a když se dohodneme, že na tom budeme pracovat, tak se do toho pustíme.

Tyto témata jsou z různých oblastí, takže si představte například náš známý projekt Pečící plán. To je projekt pro operativu, jsou tam projekty pro promoční oddělení, pro komerční oddělení, směrem k zákazníkovi je teď práce na personalizované nabídce v loajální aplikaci Můj Albert. Takže to jsou typické věci, které děláme.

Řešíte tyto problematiky pro místní Albert, nebo i pro jiné země?

Momentálně je řešíme primárně pro místní Albert, ale Albert je součástí Ahold Delhaize Group a v rámci této skupiny je velký důraz na znovupoužitelnost řešení, takže se snažíme spolupracovat i s globálním týmem a brzy budeme dodávat řešení i do jiných zemí, respektive do jiných brandů v těchto zemích.

K těm use case se ještě vrátíme. Můžeš být třeba konkrétnější? Jaké hlavní prvky má váš projekt? Zmiňoval jsi, že na začátku se rozhodujete, zda do toho jít, jestli to má nějaký „bavor“ (prospěch), nebo jak to popsat. Jsou nějaké klíčové věci v rozhodovacím procesu, jak projekt klasifikujete a jak k němu přistupujete při realizaci?

Jasně. Možná první věcí, s níž se setkáváme, je manažování očekávání zadavatelů, aby si nemysleli, že data science je nějaká kouzelná skříňka, která vyřeší jakýkoli jejich problém. Snažíme se tedy vysvětlit: Pojďme se bavit o tom, co by se stalo, kdybychom to úspěšně dodali. Opravdu by vám to pomohlo tolik, kolik si myslíte?

To je první bod, který máme.

Druhý bod, který řešíme, je, zda na to, co od nás chtějí, vůbec máme relevantní data. Albert má velmi dobrá, dlouhodobě zpracovaná a kvalitní data, se kterými je radost pracovat, ale někdy není úplně jednoduché dostat je do podoby, abychom z nich dokázali získat přidanou hodnotu. To je typická druhá výzva.

Třetí bod je, že od začátku se chceme dohodnout, jaké metriky budeme sledovat a co považujeme za úspěch. Toto jsme se hodně naučili na projektech z počátku, kde jsme si toto nespecifikovali dostatečně brzy. Dodali jsme kompletní projekt, mysleli jsme si, že je úspěšně dodaný, a reálně potom, když přišlo na lámání chleba, jsme zjistili, že mluvíme o dvou různých věcech a vyhodnocovalo se spíše na základě intuice nebo pocitů místo reálných čísel.

Můžeš být konkrétnější v kontextu těch use case?

Určitě. Jeden z hlavních projektů je Pečící plán, což je projekt nebo aplikace, která říká, kolik a kdy se má upéct na které prodejně. Mysleli jsme si, že máme dobrý predikční algoritmus a že dobře doporučujeme, ale po nasazení během pilotního provozu přišly reakce z prodejen: „Vy jste se asi zbláznili, je toho strašně málo, opticky vypadá, že máme poloprázdné regály.“ My jsme byli rádi, ale podívali jsme se, co se děje s odpadem a s růstem prodeje. Ta diskuze probíhala tak, až jsme se shodli na tom, jak to budeme vyhodnocovat.

Ty jsi zmiňoval, že děláš PhD v oblasti financí, že jsi pracoval i v oblasti tradingu. Dá se využít znalost finančních ukazatelů, třeba i v tom Pečícím plánu? Řekl bych, že je to úplně jiná oblast, ale myslíš, že je tam nějaká paralela?

S tebou souhlasím. Data science má být podporou rozhodování. V kvantitativních investicích, v tradingu, jde o odlišení signálu od šumu. Ve financích je situace ještě více zašuměná než v Albertu, ale čím více je něco zašuměné, tím důležitější je důvěřovat modelům. V Albertu a u našich use caseů lidé sami dělají dobrá rozhodnutí, proto bývají skeptičtí k modelům, které rozhodnutí přebírají.

Ve financích je běžné, že lidský expert může být horší než náhoda. Jak je to možné? Pokud je člověk tak dobrý jako náhoda, ale každým rozhodnutím platí nějakou provizi, tak dlouhodobě prohrává.

My si musíme respect modelů teprve získat. Na druhou stranu v Albertu se výsledky ukazují rychleji. Ve financích může malý edge trvat dlouho, než se projeví. V retailových use casech, jako u Alberta, víte rychle, jestli je přidaná hodnota.

Když se vrátíme k Pečícímu plánu, jak si to mám představit? Představ si, že jsem babička, co si ráno jde koupit rohlíky, jak se mě to týká?

To je ideální otázka, protože Pečící plán je projekt, na kterém bych mohl vysvětlit babičce, co dělám. Není to vůbec abstraktní, je velmi konkrétní.

Máme přes 300 prodejen, kde se prodává pečivo. Nepredává se jeden druh, ale desítky druhů. Někdo musí rozhodnout, kolik čeho a kdy se upeče.

Cílem je, aby zákazník večer přišel do Alberta a neodešel naštvaný, že si nemohl koupit pečivo nebo že bylo tvrdé. Na druhé straně nechceme vyhazovat tuny pečiva do odpadu, což je důležitá otázka.

To je účel Pečícího plánu a model říká, kolik a jak péct.

My jsme tento model vyvíjeli od základů.

Co je důležitější, protože mám podobný background, vím, že když upeču víc, všichni budou spokojení, splním jednu metriku, ale hodně vyhodím. Naopak, když upeču méně, vyhodím méně, ale zákazníci budou zklamaní.

To je opravdu dobrá otázka. Klíčové je vyvážit ty dva protichůdné efekty.

Na jedné straně, když prodám pečivo, které by se jinak neprodalo, získám tržby a spokojeného zákazníka.

Na straně druhé, pokud pečivo neprodám, mám spojené všechny náklady – nejen nákup, ale logistiku, energii a další.

Tyto dvě strany vyvažujeme explicitně pomocí kvantilové regrese.

Nechci jít moc do detailů, můžeme se k tomu někdy vrátit.

V každém případě používáme kvantilovou regresi, což je ekonometrický přístup založený na ztrátové funkci, která vyvažuje přestřelení a podstřelení, tedy předpovídání více nebo méně.

V našem případě, pokud nám vadí vyhodit dvakrát víc pečiva než nemít dostatek, zvolíme konkrétní kvantil, například 33%, který toto vyjadřuje.

To jsme implementovali a umožnilo nám to kontrolovat dostupnost pečiva po položkách, prodejnách a hodinách.

A ještě pro upřesnění: pečivo se nedopeká najednou za den, ale dva až třikrát denně, aby bylo vždy čerstvé.

Máme predikční modely na hodinové a denní bázi, všechny kvantilové, a podle požadované dostupnosti volíme kvantil a model.

To nám umožňuje zajistit například, že promoční položky mají vyšší dostupnost než nepromečné nebo esenciální položky jako kajzerky, které mají být k dispozici do večera, zatímco u dražších položek můžeme dostupnost snížit.

A co cena? Hraje v tom roli?

V současnosti cenu nepoužíváme, i když bychom to rádi zavedli. Obecně ale cena hraje klíčovou roli.

Z pohledu klasického demand forecast modelu je totiž množství závislé na ceně – čím nižší cena, tím vyšší prodej.

Samozřejmě do toho vstupují i další faktory, jako jestli je víkend, svátek, je zavřená škola v okolí, dostupnost jiných položek atd.

Cena vstupuje do modelu jako standardní feature, například jak atraktivní je cena v aktuálním čase vůči historické ceně dané položky.

Monitoring cen konkurence zatím nemáme; je to datově náročné, plné šumu a chybných dat.

Říkáš kvantilová regrese – jak jste zvolili tento typ modelu?

Byla na začátku nějaká diskuze, že přesně tento typ problémů tak sedí, nebo je to tvoje zkušenost z oblasti asset tradingu?

To musím dát tribut bývalému kolegovi. Když jsem nastupoval do Alberta, vysvětlili mi, že máme ambici vybudovat Data Science tým, budeme mít juniorského kolegu, kterého mám mentorovat.

Na prvním obědě jsem se ho snažil vypáčit, jaké má znalosti z ekonometrie a machine learningu, protože jsem si ho nevybíral.

Mimochodem mi řekl, že je zlatý medailista na Kaggle a má v tom opravdu dobré zkušenosti, což se hned při prvním společném modelování potvrdilo.

Proto při výběru modelu se řídíme state of the art přístupy z Kaggle, což je platforma pro data science soutěže, kde se sledují aktuálně nejlepší metody.

Na tomto základě volíme modely a snažíme se mít benchmark.

Benchmark může být kdokoli…

(rozhovor pokračuje)

Jako prostý historický průměr. Snažíme se mít také nějaký baseline model, tedy jednoduchý model, v tomto případě to byla určitá exponenciální vyhlazování. A takto k tomu přistupujeme, když se snažíme dělat data science projekty u nás. Vlastně cílem, který máme, je dostat se co nejdříve k jednoduchému modelu a podívat se na jeho chyby.

Když se tedy vrátíme k příkladu z pečiva, tak v praxi to vypadá tak, že se na začátku zamyslíme, jaké proměnné by mohly mít vliv na to, kolik se toho prodá. Některé jsme už zmínili, jistě je to cena, dále otázka, zda byl produkt ve slevě, nebo ne, historické prodeje, den v týdnu, případně jak daleko jsou prázdniny od daného dne, pro který předpovídáme. Potom, co si vygenerujeme takovýto seznam proměnných, které by měly mít vliv, si sedneme a řekneme si: „OK, pro tyto máme data a příprava těchto proměnných pro analýzu je otázka deseti minut, pro tyto data nemáme, ale skutečně si myslíme, že by měly být cenné.“

Snažíme se tedy nenechat zastavit tím, že některé cenné vlastnosti (features) nemáme k dispozici. Mnohem cennější je hned na začátku co nejrychleji vytvořit model a podívat se, kde dělá chyby. A na základě těchto chyb pak říct: „OK, evidentně toto je chyba způsobená tím, že model v současnosti nezohledňuje, například v Česku jarní prázdniny, které jsou různé.“ Nebo: „Toto je model,“ teď jsem zvědavý, jak to dopadlo, byly zde volby, zajímá mě, jaký to mělo vliv na jednotlivé prodeje. Lidé hodně cestovali, možná dělali nákupy několik dní před volbami, což model rozhodně nezohledňoval.“

To je takový příklad postupu, jakým pracujeme. Podíváme se na chyby a pak je to vlastně primárně tvorba vlastností (feature engineering).

Co se týče modelů, tak dnes je to tak, že v oblasti tabulárních problémů jsou state of the art modely především stromy. Náš go-to model jsou tedy gradient boosting stromy.

U problémů, kdy máme méně dat, nebo jsou více orientované na časové řady, používáme model Prophet od Meta, případně od Facebooku, což je jakýsi mix ekonometrických modelů, zejména parciální lineární regrese.

Parciální lineární regrese, přesně tak.

Super, já jsem se chtěl právě zeptat – když se vrátíme k tomu baking plánu, zmiňoval jsi, že v první fázi, kdy jste ho dodali, jste dostali opravdu velkou kritiku od lidí, kteří tam buď pracují v operations, nebo přímo na prodejnách. Můžeš být konkrétnější? Jak to dopadlo a jak jste s tím pracovali?

Určitě. Takže z velké části si na sebe beru zodpovědnost za to, že to nebylo dostatečně dobré, protože jsem ještě nebyl dostatečně zkušený v tom, jak to správně komunikovat, co ten model dělá. Fungovalo to tak, že jsme si to samozřejmě vyvinuli, testovali na historických datech, ukazovali našim stakeholderům, jak by to mohlo vypadat, například že pokud zvolíme takový parametr v kvantilové regresi, budeme mít určitou dostupnost a potenciálně se tolik zboží nebude kumulovat.

Snažili jsme se jim to vysvětlit, ale pravděpodobně jsme nebyli dostatečně úspěšní.

Jako tip, jak poznat, že nejste úspěšní, když něco vysvětlujete, je to, že…

když dáte možnost vybrat si ze tří možností a oni zvolí „zlatou střední cestu“. Zlatá střední cesta znamená „nerozumím, nechávám to na tobě, zároveň nechci podstoupit žádné riziko na žádné straně.“

Takže my jsme nakonec zvolili právě tu zlatou střední cestu a začali jsme to pilotovat.

Pilotování znamená, že prodejny se tím budou řídit. Některé byly skeptické, jiné více otevřené.

Co se pak stalo, bylo to, že ony podle toho začaly péci, a my jsme okamžitě začali monitorovat, do jaké míry to funguje, do jaké míry to dodržují nebo nedodržují, jestli to přispívá ke zlepšení, například ke snížení odpisů i ke zlepšení prodeje.

Ale hlavní diskuse po nasazení nebyla o těchto metrikách, o kterých jsem teď mluvil, ale o tom, jak ta prodejna vypadá.

Jak ta prodejna vypadá ve srovnání s tím, na co jsou lidé z prodejny zvyklí, jak to dříve fungovalo.

Pěkný příklad je například ten, že vezmeme si dvě prodejny, které prodávají přibližně stejné množství pečiva, ale jedna má o dvě až tři vitríny (výkladní skříně) více, kde se pečivo prodává.

Na jedné prodejně tak bude vypadat zboží prázdnější než na druhé, přestože prodeje jsou podobné. A jedna prodejna může chtít navýšit dostupnost, protože mají pocit, že zboží není dost.

Nemohli to udělat sami?

Určitě mohli, ale konečné rozhodnutí, kolik zboží se má na prodejně napečet, je přesto na nich.

My chceme, aby dodržovali a monitorujeme, kolik se skutečně upeče.

Protože když máte více než 330 prodejen, některé mají velmi zkušené pekaře, kteří s tím umí dobře pracovat a jsou potenciálně lepší.

Když se podíváme, jak se odchylují od našich návrhů, většina těchto odchylek je přitom dobrá.

Co znamená dobrá odchylka?

Dobrá odchylka znamená, že když upeču více, jsem schopen všechno prodat.

Nebo naopak, když upeču méně, mám dvě možnosti: buď nic nevyhodím večer, což by mohlo znamenat, že to není ideální rozhodnutí, protože přišlo 20 zákazníků, kteří si nemohli koupit, nebo to může znamenat, že naprosto vyprodali vše pár minut před zavírací hodinou a zavřeli na nulu, což je ideální situace.

To všechno umíme vyhodnocovat a snažíme se to komunikovat zpětně prodejnám.

Jak toto změříš? Konkrétně situaci, kdy upečeš méně a vidíš tam 20 naštvaných lidí, kteří si pečivo nekoupí.

Je velmi obtížné změřit do druhého řádu efekty, tedy že zákazník se pohorší a už se nikdy nevrátí.

My se snažíme měřit to nepřímo.

Příkladem je, že když vidím večer odpisy rovné nule, znamená to, že se nic nevyhodilo.

Druhá věc, na kterou se podívám na úrovni daného pečiva, je, kdy se prodal poslední kus.

Bylo to pět minut před zavírací dobou, nebo dvě hodiny před ní, kdy tam byla díra?

To je jedna věc.

Druhá věc je, že pečivo se neprodává izolovaně – je to celý úsek.

Když například vypadne jedna bageta (kajzerka), ale jsou ještě dva další druhy kajzerek, kterých je dost, tak mě to vadí mnohem méně, než když vypadne celý úsek.

Takto na to nahlížíme.

Samozřejmě je tu i finanční přesah, kdy Albert usiluje o určitou úroveň odpisů a růstu prodeje, a toho se musíme držet.

Nemůžeme jít proti tomu úplně.

Musíme cílit na společný cíl.

Přijde mi skvělé, že vlastníte tak propracovaný model přímo na pečivo.

To je proto, že se každý den vyhazuje?

Ano, je to dokonce ještě „fresh“ než „fresh“.

Přesně tak, jak říkáte. Pečivo se večer musí vyhodit. V okamžiku, kdy je rozmrazené, upečené, už ho nemůžeme prodat druhý den.

Je to velmi zajímavý problém z ekonomického i data science hlediska, protože přesnost je klíčová.

Nemohu si dovolit chybovat a prodávat na druhý den.

Čím přesnější jsem, tím méně vyhodím.

U jiných, méně čerstvých kategorií nemusím být tak přesný, protože mám nějaké zásoby.

Když to neprodám dnes, prodám to zítra.

V tomto případě to však nejde.

Martine, ještě mám jeden dotaz.

Vím, že úroveň maturity v oblasti data science a její implementace se liší nejen ve firmách obecně, ale zejména ve velkých firmách.

Jaké jsou podle vás klíčové věci, na které bazírujete, aby byly splněny, a jaké jsou hlavní požadavky, které musí každý projekt splňovat?

Určitě.

To, co jste právě popsal – že úroveň maturity je značně různorodá napříč firmami – je určitě pravda, znám to aspoň z pohovorů s kandidáty, kteří přicházejí z jiných společností.

Na čem my založíme svůj přístup?

Snažíme se být jako engineeringově orientovaný tým, tedy praktikujeme pipeline-first přístup.

Jsme připraveni nasadit projekt, který metodologicky z pohledu data science může být jednoduchý, průměrný.

Důvodem je primárně fakt, že samo o sobě modelování nebo zlepšení přesnosti o pár procent přináší menší přidanou hodnotu než to, že pipeline bude stabilně běžet v produkci a plnit svůj účel.

Děláme tedy pipeline-first přístup.

Co to znamená? Znamená to end-to-end testy, akceptační testy, unit testy, testy kvality dat.

Když se tedy ohlédnu zpět a zamyslím se nad největšími problémy, které máme jako data science oddělení, pak na prvním místě jsou chyby v datech, o kterých jsme předtím nevěděli, že se mohou vyskytnout, a které spustí selhání celé pipeline.

Dobrým příkladem je právě baking plan, protože ten běží každý den na více než 330 prodejnách a když z jakéhokoli důvodu vypadne, máme okamžitě čekající incidenty, které musíme řešit – co se stalo, proč a tak dále.

Takže engineering-first přístup je u nás rozhodně na místě.

Rád bych ještě dodal, že to není úplně jednoduché.

Konkrétně se nám stalo, že jsme zvolili engineering-first přístup, soustředili se na dobrou pipeline, testy, dokumentaci, aby vše běželo – to bylo v pořádku.

Ale dvoutýdenní čas před termínem nasazení je pak příliš krátký na skutečné data science experimenty.

Proto se momentálně snažíme hledat rovnováhu.

Ideální je, když na projektu pracují minimálně dva lidé: jeden, který je více zaměřený na inženýrskou stránku, a druhý, který je více zaměřený na samotné data science.

Pak společně projdou prvotní kola diskusí o vlastnostech dat, metrikách, termínech dodání a co vše chceme experimentovat.

Jeden začne rovnou dělat experimenty, druhý se pustí do stavby pipeline.

Co se týče data engineeringu, většinou je to tak, že mám model, podívám se na chyby, vidím, co se nepokrývá, a potřebuji více dat.

Pak jdu za data engineerem a žádám dodání těchto dat.

Možná jsem to ještě nezmínil, ale my jako data science oddělení jsme součástí většího data & analytics týmu.

V rámci něj jsou tři pododdělení: data engineři, data architekti a business analytici.

My jsme jakoby prostřední kolečko.

Potřebujeme, aby nám data engineři dodali data v určité kvalitě a načas.

Za námi pak často potřebujeme někoho, kdo je kontaktním bodem pro business, aby byl schopný jasně lidsky komunikovat, co modely dělají.

Takže to jsou dva styčné body, a nad tím vším je datová architektura, která se stará o pořádky v datech, koncepci a tak dále.

Dáváte také pozor na MLOps? Například model registries, staging modelů a podobně?

Jistě.

První rok, kdy jsem v Albertu, jsme byli na on-prem linuxových serverech, a museli jsme si všechno řešit sami.

Je důležité říct, že v týmu o třech lidech si musíte pečlivě volit priority, jaké good practices budete schopni pokrýt a jaké ne.

Aktuálně už směřujeme k migraci na data lake house architekturu a na to si hodně potrpíme.

Velkou výhodou je, že Albert je součástí HAL del Haze, kde je velmi otevřená kultura řešení projektů.

Používáme GitHub, kde vidíme a sdílíme práci s kolegy, data scientisty a MLOps inženýry i ze zahraničí.

To je směr, na který se aktuálně zaměřujeme.

Co se týče registrování modelů, poslední projekty to již mají.

Používáme MLflow pro sledování experimentů, model registraci tam, kde to dává smysl (někdy nemá).

Provádíme data quality checky – kontrolu chybějících dat, distribuční kontroly a podobně.

Téma je trochu nevděčné z pohledu businessu, protože nerozumí, proč to trvá a proč to tak funguje.

Já mám tendenci říct, že je snadné napsat pipeline a na začátku ji dát do produkce.

Ale když chtějí dělat změny, když se něco pokazí nebo se změní členové týmu, technologický dluh je takový, že je jednodušší všechno znovu přepsat.

To vysvětlujeme.

Naštěstí v našem týmu máme podporu, nejsme tlačeni do nereálných deadlineů, máme čas na refaktorování.

Na to si potrpíme, vždy říkáme, že je potřeba refaktorizovat.

Když tu mám jednoho hosta, téma feature store je velké téma i pro vás?

Ano, určitě.

Momentálně ho ještě nepoužíváme, ale zatím nepřišla úplná priorita.

Debata je o tom, že když máte více projektů, některé features můžete používat napříč nimi.

Například odhad počtu zákazníků na prodejně po hodinách.

Chci predikovat, kolik zákazníků přijde na určitý mostek, a tato predikce je feature, kterou mohu používat v různých projektech.

Momentálně to děláme tak, že ji generujeme a pokud ji jiný projekt potřebuje, vezmeme si ji tam.

Tímto jsem přepsal váš text do spisovné češtiny, zachoval jsem veškerý obsah, nevynechal ani nezkrátil žádnou informaci a rozdělil jsem text do přehledných odstavců. Pokud budete potřebovat další úpravy, dejte vědět.

Místa, kde je to sice vygenerované, ale není nad tím vytvořen nějaký hezký katalog nebo… Nad tím je ještě vytvořená datová vrstva, je to něco, kam směřujeme. Z těch různých případů, které jsme se snažili pokrýt, k tomuto jsme se zatím ještě nedostali.

Co se týká těch úzkých míst, říkal jsi, že vlastně spolupracujete technologicky napříč touto skupinou. Stává se vám, nebo máte v plánu, že budete vlastně dodávat třeba pro celou skupinu nebo pro část skupiny? Protože ta řešení jsou hodně obdobná. Například, existuje v rámci skupiny zájem o pekařský plán?

To je dobrá otázka, doufám, že ano. Abych to vzal obecně – to, co říkáš, že mnoho problémů je podobných napříč různými značkami, to je rozhodně pravda. A k tomu, abychom mohli znovu využívat řešení, k tomu určitě přispívá dobrá softwarová praxe. Klíčové však je mít k dispozici data ve stejné kvalitě a mít k nim přístup. Takže to, co se momentálně děje, je jistý tlak, ale spíše jsme v etapě, kdy se snažíme sjednotit datové zdroje, názvy sloupců a následně toto všechno realizovat.

Jaké další projekty máte kromě pekařského plánu a zmíněné spolupráce napříč? Jaké další máte představy?

Dalším příkladem představitelného projektu byla analýza průchodnosti samoobslužných pokladen. Co to znamená? Počet samoobslužných prodejen ve světě roste a někdo musí rozhodnout, na kterou prodejnu bude daná samoobslužná pokladna instalována. Je to vlastně optimalizační problém, kdy se hledá taková prodejna, kde bude mít největší přidanou hodnotu. Tedy ta prodejna, na kterou instalujeme samoobslužnou pokladnu, by měla mít větší průchodnost právě těmito pokladnami.

V tomto projektu jsme vycházeli z již existujících samoobslužných pokladen na určitých prodejnách a odhadovali jsme průchodnost. Zkoumali jsme faktory, které na to mají vliv – například typ zboží v košíku. Typicky platí, že zákazník s velkým košíkem na samoobslužnou pokladnu nechodí, zatímco s malým košíkem je ochotnější ji využít. Dále je důležitý stav u pokladny – pokud je volná a jsou u ní čekající zaměstnanci, je to rychlejší cesta. Pokud ne, zákazník má tendenci jít jinam.

Co víte o zákaznících, kteří tyto samoobslužné pokladny využívají?

Samozřejmě máme k dispozici určité informace. Z běžných účtenek však nemáme žádné osobní údaje o zákaznících. Máme zákaznické karty a loajální aplikaci „Můj Albert“. V této aplikaci je údaj o věku, ale data jsou pro nás anonymizovaná, takže nevidíme, že konkrétně ty nakupuješ. Navíc věk je tzv. samohlášený atribut, což znamená, že v datech jsou nepřirozeně velké počty zákazníků ve věku 2 roky nebo přes 100 let. Proto jsme tento ukazatel zatím nezvažovali.

Používáte v rámci loajální aplikace strojové učení nebo Data Science?

Ano, v současnosti pracujeme na personalizovaných nabídkách. To znamená, že když otevřete aplikaci Můj Albert, uvidíte položky, které jsou pro vás opravdu relevantní. Nezobrazují se zde pouze obecné populární položky nebo podle preferencí typu „jsem vegetarián, nechci maso“, ale personalizovaná nabídka má pomoci zákazníkovi vidět věci, které by se mu mohly líbit.

Z hlediska modelů využíváme směs jednoduchých a složitějších metod. Jednoduchý model je založený na historických nákupech zákazníka – položky jsou seřazeny podle frekvence nákupů. Například když často kupuji ananas a je to v nabídce, tak to tu položku doporučíme. Tento algoritmus je dostatečně dobrý, pokud zákazník u nás často nakupuje a produkty, které hledá, jsou dostupné.

Problém nastává u zákazníků, o kterých máme málo údajů, ale i tak jim chceme nabídku personalizovat. Tam používáme faktorizaci matice, doplňování na základě podobnosti produktů nebo podobnosti s ostatními zákazníky.

Co vidíš ty, když jdeš nakoupit do Albertu? Vidíš tam nějaký datový „matrix“, zkoumáš výlohy s pečivem, sleduješ, jak jsou věci uspořádané?

To je dobrá otázka. Já se obecně snažím na to koukat skrz perspektivu rozhodování. Když jdu obchodem, sleduji, jak jsou regály uspořádány. Přemýšlím, kdo rozhodl, že tyto položky budou ve třetím regálu a ty jinde. U zeleniny přemýšlím, proč je tam právě takové množství. Když u pečiva vidím slevu 50 %, hodnotím, zda je opravdu oprávněná.

Když jdu k pokladnám, přemýšlím, proč tu sedí tři pokladní místo jedné, kdo to rozhodl, jaký je ten rozhodovací proces.

Tento přístup neaplikuji jen na Albert, ale i na další místa, nejen konkurenci.

Pokud mluvíme o těchto problémech, protože vy jste určitě řešili jen malou část, existuje v rámci firmy další tým, který se této problematiky analyticky věnuje, nebo jde spíše o expertní přístup?

Mluvíš obecně, nebo konkrétně?

Mluvili jsme o průchodnosti pokladen a technicky řešili téměř počet zaměstnanců u pokladen v danou hodinu.

Jsme typicky samostatný tým řešící daná oddělení, která mají tyto problémy. Řeší je sami velmi dobře a když nemají kapacitu, najímají například externí pomoc pro výpočty. Někdy také samostatně iniciujeme spolupráci.

Klíčové je, že nemáme doménovou expertízu v daných problémech, proto potřebujeme, aby nám někdo z daných oddělení vysvětlil celý reálný proces. Například u samoobslužných pokladen potřebujeme znát počet člověkohodin dostupných na prodejně, počet pokladních, podle čeho se instalace provádí, jestli je to primárně na hypermarketech, a jaký je proces za tím.

U každého problému máme úzký vztah s odpovědným oddělením, které jej řeší.

Je samozřejmě výhodné, když můžeme znovu použít řešení na podobných tématech, protože známe data, lidi a problém. V momentě, kdy přicházejí nové projekty, je náročné pochopit nový problém a vyvinout nové řešení.

Jak ty business oddělení vnímají vaši práci? Stojí na vás fronta, jste přetížení, nebo řešíte věci spíše po svých cestách? Jste hodně známí a všichni vás chtějí, nebo je třeba více osvěty?

To jsou velmi dobré otázky. Za sebe musím dát velký kredit šéfovi Lukášovi Rambovskému, vedoucímu Daytime Analytics oddělení, který pro nás funguje jako kontaktní osoba na vysoké úrovni v rozhodovacím procesu.

Správné by mělo být věnovat se projektům s největší přidanou hodnotou, ale co je to největší přidaná hodnota? Jeden projekt může mít největší přidanou hodnotu v horizontu půl roku, jiný po roce či dvou.

Rozhodování proto probíhá na úrovni nad námi. My máme za úkol dobře komunikovat, co Data Science umí a co ne, ale finální rozhodnutí o prioritě je v rukou těch, kteří rozumějí celému rozpočtování a plánování priorit v rámci Alberta.

Obvykle tedy rozhodují nahoře, podle přidané hodnoty, a my poradíme, když je projekt zajímavý nebo náročný. Často říkáme „pozor, tento projekt si nemyslíme, že je realisticky řešitelný námi“, nebo „i když jej vyřešíme, nebude mít přidanou hodnotu“. To jsou reálné diskuse, které vede tým.

Data Science projekty oproti softwarovým obsahují mnohem větší nejistotu. Abychom věděli, zda bude mít řešení přidanou hodnotu, musíme často zvládnout 80–90 % práce, ale až potom zjistíme, jestli tam ta přidaná hodnota skutečně je. To se velmi těžko komunikuje, zejména pokud se očekávalo, že přidaná hodnota existuje.

Můžeš uvést příklad takového projektu, který na začátku vypadal dobře, ale pak byl komplikovanější, nebo tam nebyla výrazná přidaná hodnota?

Jeden pěkný příklad je projekt odhadu kanibalizace prodejů při propagaci jednoho produktu. Když se propaguje určitá položka, její substituty logicky zaznamenají nižší prodeje.

V rámci jedné kategorie je to relativně jednoduchý problém. Například, pokud propagujeme slané malé pečivo a jednu položku zlevníme, prodeje ostatních klesnou.

Komplikace nastává při řešení napříč kategoriemi. Například, když dám olej do slevy, může to zvýšit prodeje hranolek, protože se jedná o komplement. Odhadnout tento efekt v celém sortimentu Alberta je velký a náročný úkol, ale s potenciálně velkou přidanou hodnotou. Budeme vědět, že se nevyplatí propagovat současně dvě položky, které si kanibalizují zájem zákazníků, a musíme je rozdělit do různých slevových akcí.

Projekt byl náročný metodologicky i datově. Závěry se zdály platné, ale když jsme se podívali, jestli jsou už zohledněny v současných promo akcích, zjistili jsme, že většinou ano. Přidaná hodnota tak nebyla tak velká, jak jsme původně očekávali.

Líbí se mi, jak projekt pilotujete v podobě MVP a testujete přímo v prodejnách. Chodíš se s manažery bavit a sledovat situaci na místě?

Do jisté míry se to děje a může dít. Například u pekařského plánu jsme chodili na místa, měli fotografie, sledovali jsme to a sbírali zpětnou vazbu.

Je důležité nepodlehnout iluzi, že když navštívím jednu prodejnu a konkrétní čas, mohu přisoudit velkou váhu této konkrétní informaci na úkor kvanta dalších údajů, které máme.

To je vlastně debata blízká tomu, co popisují Kahneman a Tversky o našem vnímání zpráv ze světa.

Ano, chodíme se dívat, protože je třeba vidět, jak situace vypadá, ale zároveň jsme velmi opatrní, jak s těmito pozorováními pracujeme, aby nás nepřipravily o objektivitu.

Když už mluvíme o Kahnemanovi a Tverskym, zajímá mě, jak naše interní týmy, pro které dodáváme data a modely, pracují s výsledky a nejistotou. Není to tak jednoduché, že dodáme reporty a oni podle nich udělají rozhodnutí, jak my očekáváme.

Například v případě pekařského plánu, když se model dva dny po sobě netrefí do odhadu míry, kde je zboží málo nebo naopak přebytek, na třetí den si obchod sám model upraví – sníží navržené množství. Ale statisticky je vždy určitá míra nejistoty a tento přístup není úplně správný.

Pokud obchod nepozoruje nějakou chybu modelu – třeba nezohlednění nějaké lokální změny, kterou umí zohlednit on – například když v okolí jsou prezidentské volby a zvýšený zájem zákazníků, tak…

(text v originále končí v polovině věty)

Nemá ho, tak to prostě zohlední a navýší, a je to potenciálně dobré rozhodnutí. Klíčové ale je, že někdy ta prodejna nemá jak vědět, zda ten model to už zohlednil nebo nezohlednil, a vlastně neví, zda to má nebo nemá držet. Když se na to díváme z tohoto úhlu pohledu, z akademického hlediska dat, jde vlastně o úplně jinou situaci. Představte si, že jste manažer na prodejně večer. Je sedm hodin, díváte se na sekci pečiva. Sekce pečiva vypadá prostě tak, dejme tomu, nevábně, že tam není dostatek zboží. Máte tam ještě 2,5 hodiny prakticky do zavírací doby. Takže péct nebo ne? Peču, a pak někdo z centrály, Martin Hronie z centrály, přijde a řekne: „Proč jste tam dopékli těch 40 kusů, když se to pak všechno vyhodilo?“ Já se prostě podíval na tu sekci pečiva a…

Řekl jsem si, že zákazník, když přijde, nebude spokojený, myslel jsem si, že jich přijde více, a tak dále. A toto je rozhodnutí, které oni musí opravdu dělat každý jeden den. Důvěřovat nebo nedůvěřovat tomu modelu. A já, jak přicházím původně z financí, tak tam bylo velmi snadné nechat se oklamat. Velmi snadné nechat se oklamat nějakými narativy, že tomu rozumím, tomu problému, ale ve skutečnosti mu vůbec nerozumím. Takže mám tendenci být spíše na straně modelů, více na straně systematického rozhodování. Ale zároveň musím akceptovat, že ti lidé, kteří používají naše produkty, se na svět nedívají nutně stejným způsobem, jakým se na něj dívám já. A opravdu jsou ti, kteří musí nakonec nést odpovědnost za ta rozhodnutí.

Takže je to určitě proces obou stran, kdy oni se snaží učit, co všechno ten model nebo produkt dokáže, a my se snažíme učit, jak jim ho reálně dodat v takové formě, aby ho opravdu mohli využít a dodat tak přidanou hodnotu. Nakonec samotné modelování je pro nás asi nejzajímavější část, ale je to velmi malá součást celé skládanky od dat, která potřebujeme zpracovat, až po komunikaci směrem k zákazníkovi a nakonec přesvědčení zákazníka, že produkt, který jim dodáváme, má používat a má mu věřit. To všechno musí spolu fungovat, aby ten produkt měl přidanou hodnotu. Myslím, že je to mimochodem jeden z důvodů, proč mnoho Data Science projektů neuspěje – protože není jasné sladění (alignment) mezi tím, co se má stát, co se nemá stát a co je nutné, aby se stalo, aby projekt uspěl. Aplikační vrstva chybí.

Ano, určitě. V laboratorních podmínkách to funguje. Určitě, přesně tak. Backtesting na těchto datech je těžko udělatelný. Ano, backtesting je opravdu složitý, protože když se chcete vrátit a podívat, co by se stalo, kdybych tam prostě napékal víc, tak to úplně říct nejde. Proč jim to nedáváte příkazem? Fungovalo by to lépe bez jejich vlastního rozhodování? Protože měli jsme tady jiný projekt, nevím, nanoenergies, energy trading, tam je jasné, že spojení člověka a stroje je silnější než člověk nebo stroj samostatně. Ale na druhou stranu to jsou energetičtí tradeři, jejich práce je jen mít kontext a zlepšovat intuici. Není to manažer prodejny, který řeší milión věcí. Určitě.

Nakonec to musí být tak, že když něco jde příkazem, plná odpovědnost musí jít za tím, kdo dal příkaz. To je podle mě bez debat otázka, respektive téma. Druhá věc je, jak jsem říkal, ten příkaz s těmi volebními místnostmi nebo situací – typický příklad je festival Colors of Ostrava. Myslím, že jsme ten pilot dělali přímo, když festival probíhal. Prodejny poblíž festivalu nám volaly a psaly, že jim nevadí, ale že tam prostě musí napéct výrazně víc, protože je tam hodně návštěvníků. Aha, tak když je festival, tak je jasné, že ten model to nezohledňuje a je potřeba navýšit produkci.

Takže má tendence by byla držet se modelu. Kdybych pracoval s lidmi, kterým jsem schopný to vysvětlit, řekl bych: držme se modelu, pojďme si jasně říct, co model zohledňuje a co nezohledňuje, a pojďme si říct, kdy je na místě model nedodržet a kdy ho budeme dodržovat, i když to nevypadá správně. Tato debata se momentálně nedeje nebo rozhodně ne v takové míře, jaká by byla potřebná. Důvodů je samozřejmě mnoho – jak prostě vysvětlit to mnoha lidem, kteří s tím pracují, a kteří nemají nutně statistické vzdělání, je to náročné.

Jak to vlastně dopadlo? Protože jsme ještě neřekli závěr. Máte hodně naštvaných manažerů prodejen? Nebo jsou polovina zapojení a polovina nespokojení? Nebo je to drtivá většina? Projekt momentálně běží na supermarketech a brzy by měl expandovat na hypermarkety. Projekt běží. Jeden z hlavních závěrů je, že dobrým prodejnám to v podstatě neublížilo. Dobré prodejny mají stále podobný poměr růstu prodeje a shrinku. Prodejny, které byly do té doby spíše výjimkami v podobě velkého shrinku nebo rychlého růstu prodeje, mají tendenci konvergovat nějakým směrem.

V jaké kohortě? To je klíčový závěr. My samozřejmě stále monitorujeme, jak dodržují plán pečení. Vidíme, že prodejny mají tendenci plán dodržovat. Samozřejmě, jak jsem říkal, pokud nastane chyba z naší nebo modelové strany, mají tendenci model překompenzovat, a pak nastane adaptační období, kdy zase potřebujeme, aby mu začali znovu důvěřovat. Lidé tam mají ještě zajímavé biasy.

Překvapuje mě, že vaši manažeři prodejen spíše chtějí více péct, nechtějí mít prázdné regály. Moje zkušenost, kdy jsme to kdysi řešili se sklizní, je, že retailisté, kteří byli franšízanti, měli větší autonomii, ale spíše jim vadilo vyhazování zboží než to, že neuměli nakupovat. Nepočítali si totiž, že je v marži lepší mít dostupnost než nevyhazovat zboží.

Jasně, nerad bych mluvil za své kolegy na prodejnách, co jim vadí nebo ne. Myslím, že jim vadí obojí – určitě vadí, když toho hodně vyhodí, a určitě jim vadí, když tam je málo. Byli by rádi, kdyby toho bylo přesně tolik. Jenže to není jednoduchý problém.

Zkoušeli jste to třeba jinak vizualizovat? Vyzkoušeli jste různé formy doporučení, a přestože je doporučení objektivně stejné, tak forma, jak jim to napíšete nebo ukážete, výrazně mění jejich chování? Nezkoušeli jsme. Klíč bylo dodat informaci v takové podobě, aby s ní bylo dobře pracováno. Například pokud mám starší paní pekárnu, která je zvyklá vytisknout si papír a jít s ním do mrazáku a udělat práci manuálně, tak jí v tom pomohu – automatickým tiskem v prodejně. To je nejdůležitější prvek; jestli to zobrazíme jako 5 nebo 6 plechů, jsme nezkoušeli a ani jsme neměli ambici.

Ptáme se na to u každého. Máme několik kohort firem, které používají různé technologické stacky. Jak jsou na tom? Momentálně přecházíme na Data Lakehouse. Data Lakehouse je vlastně koncept založený na cloudovém řešení plus Databricks. Co si pod tím můžete představit? Jsou tam nějaké storage účty a vrstvy dat, které zpracovávají raw data ze zdrojových systémů.

Je tam také vrstva zvaná Common, kde jsou přejmenované společné atributy. Potom vrstva business nebo gold, kde jsou finální data, jež mohou být používána. Nad tím používáme Databricks a úzce spjatý MLflow. Některé předchozí projekty stále běží ve on-prem světe, tedy na Linuxových, poměrně výkonných serverech.

Ten stack je typický moderní data science stack založený na Pythonu a PySparku se všemi běžnými knihovnami, které znáte, zaměřený na tabulární metody. Jsou to LightGBM, XGBoost, CatBoost, Scikit-learn. Příklad… PyTorch nebo Keras? PyTorch, určitě PyTorch. Bez váhání.

Dodávám ale, že na tabulárních problémech, se kterými se setkáváme, neuronové sítě většinou nepodávají tak dobrý výkon. Vyžadují hodně energie a investic, aby bylo možné získat rozumná řešení. Stromové modely fungují v podstatě výrazně lépe „out of the box“. Pro personalizaci jsi říkal, že jeden z modelů bude neuronová síť, ne?

Pro personalizaci jsme zvažovali jeden model neuronovou sít, ale nakonec není o tolik lepší, aby to stálo za náklady na výpočetní výkon.

Z mých zkušeností s tabulárními modely mohu říci, že výsledky jsou velmi podobné, protože je důležité si udělat baseline, jak jsi zmínil, a někdy zjistíte, že je dokonce lepší a robustnější.

Určitě, souhlasím. My rozhodně nejsme metodologičtí fanatici. Přestože mnozí z nás mají akademické zázemí, nelpíme na tom, že to musí být nejzajímavější věc, kterou jsme kdy dělali. Snažíme se být spíše inženýři než vězni metodologie; pokud má něco zlepšit výsledek o pár procent, není pro nás zajímavé do toho investovat čas. Máme dost problémů ke zvládnutí a není důvod se hlouběji zabývat jedním problémem, který právě řešíme, když můžeme zkusit jiné.

Zmínil jsi, že je pro vás důležitá udržitelnost a reprodukovatelnost. Určitě. A monitoring, jak to děláte?

To je dobrá věc. Myslím, že jde o jeden z důvodů, proč nemiluji konzultační firmy. Důvod, proč je nemám rád, je ten, že oni nemají „skin in the game“. Já se dívám na práci, kterou dělám, a projekty, které tvoříme, jako na naše projekty, které vyvíjíme a budeme udržovat. Pokud totiž vím, že vyvinu produkt a za rok budu pryč, mám jinou motivaci než člověk, který ví, že ten produkt vyvine a bude ho muset udržovat.

To podle mě znamená, že musím tlačit na to, aby byl čas na refaktorování. Kód se píše na třikrát. Na třikrát ve smyslu, že poprvé napíšu kód a čím lepší jsem inženýr, tím lepší bude, ale pravděpodobně ho budu muset přepsat. To je něco, co se těžko vysvětluje.

Když se zeptáte obchodních lidí, zda chtějí novou funkci nebo refaktor stávajícího zadání, nikdo neřekne „refaktorovat“. Když řeknou „obojí“, reálně to znamená „žádnou novou funkci“.

Když je pohled ten, že to budu udržovat já a budu muset inkorporovat všechny změny, nutí vás to být lepším inženýrem, než kdybyste věděl, že to nebudete dělat.

To souvisí i s monitoringem. Když vám na vaší práci záleží, myslím i svému týmu, musíte se ptát, proč projekt nefunguje, když nastanou problémy. Šlo to předvídat? Šlo to zjistit? Je chyba na naší straně? Kde se stala chyba?

Nemyslím si, že data science aplikace jsou dnes nějakým magickým řešením na všechno. Naopak, myslím, že mají přidanou hodnotu, ale vyžadují hodně koncepční práce, aby fungovaly.

Když se vrátím k monitoringu, souvisí to naprosto. Když mi záleží na projektu, tak z povahy věci – samozřejmě záleží na doméně – v mnoha doménách, pokud modely nepřeškoluji, jejich výkon degraduje. Důvody jsou, že některé vlastnosti ztrácí relevanci, nebo se mění kvalita dat a tak dále.

Jak my to monitorujeme? Vraťme se na začátek – s stakeholdery vždy řešíme metriky. Když je máme, ideálně by měly být dobře kvantifikovatelné, a pak lze měřit. Typicky měření nebo vypočítání těch metrik definujeme my – jak se metrika bude počítat a jak o ní budeme komunikovat. Vizualizaci a komunikaci necháváme obchodním analytikům.

Důvod je, že metrika je úzce svázána s tím, co projekt má dělat. Kdybychom to dali někam jinam, ztratili bychom kontrolu, na co se zaměřovat.

Co se týče textu, typicky metriky jsou předpočítávány a nad nimi běží Power BI vrstva, která nám je zobrazuje.

Dám zde určitě pochvalu kolegům obchodním analytikům, protože množství reportů, které vytvořili, když jsme začínali, bylo skvělé.

Měl jsem tendenci si mírně otevřít Jupyter notebook a rychle se podívat na metriky, ale přesvědčili mě, že je to lepší a pohodlnější v momentě, kdy je to správně vytvořené.

Ty jsou typicky obchodní metriky, ale co technické, pomocné metriky? Máte je někde ve spolupráci s MLflow?

Ano, přesně tak. Tyto metriky logujeme jako součást pipeline, při trénování i v produkci.

Zmiňoval jsi, že používáte GitHub, takže GitHub Actions co se týče CI/CD?

Ano, GitHub Actions. Co se týče nasazení modelů, MLOps stránku pokrýváme interně vyvinutým MLOps frameworkem na úrovni skupiny. Zajišťuje nám například snadnou registraci modelů, monitoring nasazení, cost monitoring…

A tak dále. GitHub Actions vytvářejí a plánují joby v Databricks, které pak nějakým způsobem běží v produkci.

Co se týče testování, to je snad téma na samostatný podcast. Testování je rozhodně klíčová součást, o které podle mě nediskutujeme dostatečně. Technicky je testování Databricks a Spark-oriented věcí samo o sobě komplikované, natož pak další aspekty…

Pokud se na to podíváme o krok zpět, testování Data Science aplikací je podle mého názoru výrazně náročnější než testování softwaru. Nestačí psát pouze Unit testy, ale je nezbytné psát end-to-end testy, akceptační testy a také Data Quality testy. Data Quality testy jsou velmi komplikované téma. Zajímavé je, že existuje balíček s názvem Great Expectations. Tento balíček, respektive koncept za ním, považuji za velmi pěkný. V podstatě říká, že když sepíšu svá očekávání od dat, tedy své „Expectations“, napisu vlastně dokumentaci k datům, která používám. Například když předpokládám, že hodnoty v určitém sloupci budou pouze kladné, nebo že budou rozloženy určitým způsobem, tím v podstatě specifikuji, co tam má být.

Zmiňoval jsem, že v drtivé většině případů jsou náš problém nekvalitní data, která se k nám nějakým způsobem dostanou. Samozřejmě růst těchto dat bývá kvalitní, například transakční data jsou velmi kvalitní a tam se chyby většinou nevyskytují. Častěji jde o doplňková data, například otevírací doby prodejen. Někdo někde něco zapomene přepsat, najednou nám to přijde do modelů, které nám říkají, kdy máme prodejnu otevřít. Některá prodejna může být rekonstruována a informace se k nám nedostane dostatečně rychle. Toto patří k oblasti data governance a myslím, že v tom nejsme špatní, rozhodně nejsme špatní, ale právě toto obvykle způsobuje problémy. Máme sadu testů, kterými takové věci kontrolujeme.

Při rozhodovacím procesu, když dojde k nějakému porušení těchto očekávání, tedy nějakému „violation“, se řeší, zda je dané porušení natolik závažné, že je třeba zastavit celý pipeline a zavolat všechny developery ke společnému řešení, nebo je to jen varování, které si máme všimnout a případně zkontrolovat. To se snažíme dělat.

Chtěl jsem se zeptat, co se stane v případě plánů, které se počítají na jednotlivé hodiny a vyžadují například pauzu o víkendu? Kdo to řeší?

Já to řeším. To je součást mého přístupu k projektům. Nepohlížím na to jako konzultant, ale jako na své projekty a svou odpovědnost, abych dodával spolehlivé řešení. Já a můj tým jsme ty kódy napsali a jsme schopni je opravit. V takovém případě není diskuze o tom, zda to opravíme nebo ne. Samozřejmě typicky chyby přijdou, když jsem na dovolené, ačkoli moc dovolené nedávám, ale když už tam chyba přijde, bývá to právě v době dovolené, což znamená, že si tu dovolenou trochu pokazím. Přiznávám, že mě to nijak nerozhodí a stejně to očekávám od svého týmu. V mém týmu by asi nevydržel člověk, který řekne: „Omlouvám se, že to spadlo, ale opravdu nemohu pomoci, protože mám neděli volno někde jinde.“ Takové nasazení považuji za nutné.

Nevnímáte to jako problém pro budoucí škálování? Protože typicky ve firmách jako jste vy, existují dedikovaná support oddělení, která řeší první a druhou úroveň problémů a třetí úroveň řeší do určité míry. My to samozřejmě máme také, ale řešení třetí úrovně, tedy těch složitějších problémů, není prakticky možné předat mimo expertní oddělení. A myslím si, že to je logické, protože Albert není technologická firma, a pokud existuje nějaké specializované oddělení s odborností, které odpovídá specifikům firmy, nikdo jiný než toto specializované oddělení ty problémy nevyřeší. Tak to já vidím.

A co se týče škálovatelnosti, mám pocit, že to je problém, který se dá řešit jedině tak, že budu psát kvalitnější software, více testovat, budu lepším inženýrem. To je podle mě jediný způsob, jak těmto problémům předcházet.

Děje se to tak, že skoro celý tým zná téměř všechny algoritmy, aby mohl poskytnout podporu? Protože jedna věc je umět to udělat, druhá věc je, aby při neštěstí někdo neměnil lidi v týmu, což by znovu vedlo k podobným problémům.

Ano, přesně tak. Nemyslím si, že už máme takový rozsah, že by jeden člověk nemohl pokrýt všechny projekty. Snažíme se pracovat s překryvy, tedy overlapem. Tematicky tak, že několik lidí má pod palcem podobné projekty, které se do určité míry překrývají. A také co se týče kompetencí, máme členy týmu, které nazývám „vanilla data scientisti“. Vanilla data scientist je podle mě člověk více zaměřený na metodologii, ale možná s průměrnými programátorskými schopnostmi, tedy píše méně kvalitní kód.

Naopak máme člověka, který píše velmi kvalitní kód, ale kdyby byl postaven pouze před samostatné modelování, je možné, že model v takovém případě vytvoří, ale s kódem by mohl být problém. Obvykle kód napsaný vanilla data scientistou neskončí v produkci, stejně jako model vytvořený software engineerem nemusí být vhodný pro produkci.

Tyto překryvy se snažíme rozsáhle dokumentovat a posouvat se směrem, kde máme mezery. Tyto překryvy nejsou jen uvnitř našeho týmu, ale také se prolínají směrem k dalším oddělením – do DevOpsu, data engineeringu, business analýzy či MLOps engineeringu. To je také součástí našeho přístupu.

Všem v týmu jsem jasně řekl, že pokud přestanou růst – nemyslím tím, že by měli sbírat certifikáty nebo si dělat školení jen proto, že to je trend – ale pokud po třech nebo šesti měsících nebude vidět žádný progres oproti výchozímu stavu, budeme o tom vážně hovořit a řešit, co se děje. Nemyslím si, že pokud lidé přestanou profesně růst a začne být jejich práce monotónní, vydrží tam déle než krátkou dobu. A myslím, že by měli být výrazně více motivovaní.

Možná se může zdát, že náš tým je více juniorský, ale určitě máme také seniorní kolegy, někteří mají i doktorát z fyziky a dlouholetou zkušenost s kódováním, a to platí pro všechny členy týmu – pokud přestanou růst, nemají podle mě v týmu místo.

A co tě teď posouvá nejvíce? Co tě táhne a zajímá?

Momentálně mě celkem zajímá práce na nějakých dynamických slevách a podobných věcech. Je pro mě zajímavé, jak navrhnout dobrou architekturu, jestli směřovat víc k streamingové aplikaci, nebo ne. To je z technického hlediska, co mě momentálně zajímá.

Dále se pomalu přesouvám více do role manažera, takže nejvíc zápasím s tím, jak si zorganizovat čas tak, abych stíhal programovat a zároveň být dobrým manažerem. Když mám čtyři schůzky denně rozložené po celém dni a nemám dost velký blok času na soustředění, není možné dobře pracovat.

Také mě zajímá, abychom dělali dobré projekty – tedy co nejtěžší a nejzajímavější. Dobré projekty nejsou jen metodologicky zajímavé, ale také náročné a ideálně přinášejí přidanou hodnotu. Člověk by měl mít pocit, že bylo opravdu těžké je dotáhnout do konce z jakékoliv stránky. Na začátku projektu jsou vždy problémy jako nekvalitní data, nedostatečné vysvětlení doménového prostředí, data scientisti, kteří nemusí znát všechny modely, se kterými mají pracovat.

Pokud se takový projekt podaří dokončit, je to podle mě velké zadosťučinění a tím se snažím vést celý tým.

Jaké velké věci vás čekají v nadcházejícím roce?

Velké věci i malé. Určitě chceme dokončit a spustit personalizovanou nabídku pro Můj Albert. Pracujeme na vylepšení plánů péče a také na opětovném využití klíčových modulů v jiných oblastech, které zatím nebudu specifikovat.

Co se týče interního rozvoje týmu, jak už jsem zmínil, máme oblastí, kde se chceme zlepšit v dobrých praktikách, ke kterým jsme zatím nedošli, a chceme jim dát prostor.

Mluvili jsme třeba o pokročilých věcech v Databricks nebo v konceptu Data Lakes. V oblasti iSizes se objevilo mnoho novinek.

Budeme mít také nějaké projekty spojené s ChatGPT a umělou inteligencí.

Používáte již nějakým způsobem tyto technologie?

Určitě jsme o tom uvažovali, ale ještě není doba, kdy bych to aktivně velmi prosazoval. Každý člen týmu si s těmito nástroji intenzivně hraje a snaží se zjistit, kde jsou přínosy a kde limity. Osobně mě velmi příjemně překvapila schopnost těchto nástrojů pracovat s dokumentací. To mě nepřekvapilo u dobře napsaného kódu, ale výrazně mě překvapilo, že i nechutně napsaný „špagetový“ kód dokázaly pochopit poměrně dobře.

V diskuzích se často řeší, zda lepší je ten kód psát od začátku, nebo jen mírně upravit kód vygenerovaný umělou inteligencí.

Co se týče využití v konkrétních projektech, musím přiznat, že zatím jsem nepřišel na konkrétní scénáře v roli retaileru. Ale pokud máte nějaké dobré nápady, rád se nechám poučit.

To možná někdy uděláme při nějakém setkání u piva.

Určitě, budeme se těšit na pivo s vámi i s ostatními na některém z datameetů.

Moc děkujeme, Martine, že jsi dnes s námi sdílel, jak funguje datová věda v Albertu. Byl to velmi zajímavý a konkrétní rozhovor a až budu příště kupovat croissanty, určitě si na tebe vzpomenu.

Díky, Martine.

Já děkuji. Díky, že jste si poslechli Data Talk až do konce. Jak se vám tato epizoda líbila? Co bychom na našem podcastu mohli zlepšit? Koho bychom mohli příště pozvat? Prosím, dejte mi vědět, co si myslíte – osobně na dalším datameetupu nebo rovnou na mail jirka@data-talk.cz.

A pokud se vám tato epizoda líbila, doporučte ji dál. Klikněte na srdíčka, hvězdičky, přihlaste se k odběru, aby naše dashboardy svítily zeleně, křivky v grafu mířily vzhůru a všichni stakeholdeři schvalovali extra rozpočet.

Ještě jednou děkuji. Poděkování patří také mým kolegům, Nikovi a Iris, stejně jako členům našeho partnerského klubu Big Hubu, Deep Note, Atakamě a Mandě. Pokud máte nějaký tip na hosty, témata, pořádáte vlastní akce nebo byste chtěli datovou komunitu podpořit jinak, určitě mi dejte vědět. Díky.

Ať vás provázejí data!