Podcast

Dobrý den, moje jméno je Jirka Vešerek a vítám vás u dalšího dílu DataTalku. Dneska je mým hostem Honza Helcl. Ahoj, Honzo.
Ahoj.

Honza je Lead Data Scientist ve Vodafonu. Dneska se budeme bavit o tom, jak stavěli jejich Recommendation Engine a jak vlastně Data Science ve Vodafonu funguje a jak ji aplikují. Předtím, než se dostaneme k tvé misi ve Vodafonu a k týmu, jehož jsi součástí, řekl bys nám, Honzo, prosím, jak ses vlastně dostal k Data Science, k datům, jaká byla tvoje cesta?

Tak já jsem se k Data Science dostal takovou menší oklikou. Studoval jsem na VŠE něco, čemu se říká finanční inženýrství, což je v podstatě statistika aplikovaná na finance. Většina lidí z tohoto oboru končí někde v bankách na risk managementu, typicky dělají takové ty modely kreditního rizika, které v podstatě říkají, jaká je pravděpodobnost, že budeš nebo nebudeš splácet, a podle toho ti banka dá nebo nedá úvěr a podle toho také zakalkulují podmínky. Zároveň už při škole mě zajímaly vlastně nějaké modernější způsoby modelování a moderní přístupy. Navíc jsme si volili vedlejší specializaci, takže já jsem ke studiu přidal i datové inženýrství, takže jsem měl ten background jak v klasické statistice, tak trochu i v inženýrské části kolem dat.

No a když jsi po škole přemýšlel, co budeš dál dělat?

Když jsem si po škole říkal, co budu dál dělat, tak vlastně už během studia jsem si to říkal. První opravdový job v oboru jsem začínal jako intern, potom jsem tam nějakou dobu pokračoval. Potom následovalo PWC, kde jsme dělali Advanced Analytics a Data Science konzultace. Do velké míry to bylo právě pro banky a podobné subjekty, takže se mi tam tenhle background hodil. Ale nebylo to jen na banky, dělali jsme modely napříč různými odvětvími, což bylo fajn, protože jsem se tak podíval na data v různých firmách z různých oborů.

Jak dlouho jsi pak byl v PWC?
Něco přes dva roky.

A potom přišel Vodafon?
Ano, to už bylo přibližně před dvěma a půl lety. Bylo to vtipné, protože jsem nastupoval první den úplně prvního covidového lockdownu, 15. března 2020. To si budu pamatovat, protože to byly opravdu apokalyptické podmínky – vzkazovali mi, že dneska určitě nemám vůbec chodit do kanceláře, smlouvu mi podávali někde u dveří, jako kdybych byl nějaký megakaranténovaný, což bylo vlastně docela vtipné. Nicméně jsem to zvládl a od té doby jsem zaměstnancem Vodafonu.

No, tvoje pozice, Honzo, je Lead Data Scientist, nebo oficiálně Big Data Lead. Co to vlastně znamená? V jakém kontextu ve Vodafonu působíte, jak velký je tvůj tým a co máte na starosti?

Jo, ten můj oficiální titul je trochu zvláštní, protože ve Vodafonu se často používá pojem Big Data pro to, čemu by se dneska běžně říkalo Data Science, Data Engineering apod. (pokračuj...)

Jistě, tady je opravený text:

Někdy se to asi říkalo Data Science nebo Advanced Analytics. Je to taková ta sranda, že si sebou prostě táhneme nějaký název, který byl aktuální buzzword, když tyto iniciativy ve Vodafonu vznikaly. Oficiálně se náš tým jmenuje Big Data, přestože naše data na dnešní poměry nejsou zas tak extrémně big, i když je to vždycky relativní, podle toho, jak se na to díváš. Já bych řekl, že u vás najdeme hodně velké datové sady, ne? Asi se to dá obhájit, jde o to, na jaké use cases. Takové ty věci, co se týkají logů ze sítě a nějakých lokačních dat – ty jsou určitě veliké. Naopak věci, které používáme pro marketing, by se reálně daly řešit i klasickým stackem. Ale jo, je to obhajitelné, můžeme říkat, že děláme Big Data.

Rozumím. A co máte reálně na starost?

Organizačně jsme pod CVM, tedy Customer Value Managementem, což znamená, že podporujeme marketing, zejména ten, který cílí na naši stávající zákaznickou bázi – ne jedná se třeba o akvizici, ale o klasické cross-selly, upsely, anti-churn, tedy snahu, aby zákazníci neodcházeli. Predikujeme, kteří zákazníci budou odcházet, co s nimi dělat a co jim nabízet jiného.

A jak velký tým jste?

Jsme deset analytiků, tedy analytiků i data scientistů. Background a skillset se tam samozřejmě trochu liší, ale v našem týmu nás celkem je deset.

Vy jste tedy součástí CVM a budeme mluvit o velkém projektu, který jste řešili poslední dva roky. Je to tak?

Ano, skoro od začátku, co tam jsem, tedy zhruba před dvěma lety to začalo.

Vy tomu říkáte Offer Priority Matrix, ale jak chápu, je to recommendation engine?

Přesně tak. Je to náš recommendation engine, který jednoduše řečeno rozhoduje, kterému klientovi nabídnout kterou z našich marketingových nabídek v danou chvíli.

A proč to pro vás byl tak důležitý a velký projekt? Z mého pohledu by takových iniciativ mohlo být ve Vodafonu více.

Tento projekt byl ale naším ústředním velkým projektem, který dodnes podporujeme a udržujeme. Před asi dvěma a půl lety tým prošel velkou změnou, kdy se změnil šéf celého CVM. Do té doby byl tým maličký, spíše kostra, na které se stavěla platforma. Jeho význam v rámci firmy i CVM nebyl velký. Když přišel náš současný šéf Marek Nekvasil, který má hluboký background v data science, pozice týmu se výrazně změnila. Najali jsme většinu současných lidí a začaly se řešit větší věci.

Do té doby tam fungovaly jednotlivé modely postavené na spolupráci jednoho konkrétního data scientista s konkrétním business vlastníkem nějaké kampaně. Ty modely byly velmi různorodé, každý si je dělal po svém, nebylo to koordinované.

Pokud chcete, mohu provést další úpravy.

u úplně... Už prostě tím, jak se ten tým zvětšil a zvýšil se náš dosah, tento styl fungování postupně přestal stačit a bylo potřeba přijít s něčím, co bude univerzálnější, jednotnější a co bude problém řešit systematicky do budoucna. Mám pocit, že tato situace není jen ve Vodafonu, ale napříč celou scénou, že z jednotlivých malých use caseů najednou vznikají celá data analytics oddělení, která mají všechny problémy v této oblasti řešit, takže v tom asi nejste sami.

Proč zrovna tento problém byl ústřední pro všechny ostatní? Tento problém vlastně řeší celou problematiku upsellu a cross-sellu, churn řešíme zvlášť, a máme ještě některé další projekty, ale zde bylo potřeba systematicky vyřešit právě toto. Náš přístup je takový, že jednotlivé oslovení daného klienta je vzácný zdroj, který musíš racionálně využívat a optimalizovat, protože nemůžeš lidi zahlcovat nesmyslně často, protože by to bylo otravné. Máme tedy kontaktní politiku, což je matice určující, jaký druh oslovení může následovat po předchozím, s cílem lidi neotravovat víc, než je únosné.

To je jeden důvod, proč je oslovení vzácné. Kromě toho existují i globální limity na počet SMS a emailů, které můžeme denně poslat. Některé z těchto limitů jsou technické – ty nejsou velký problém, ale jsou i byznysové důvody, například nechceme přetížit zákaznickou linku. Protože určité procento lidí zavolá, pokud něčemu nerozumí, nebo mají otázky k detailům. Každá akce tedy vyvolává reakce a má důsledky, takže musíme řešit i celkový globální denní limit komunikace, kterou posíláme.

To vyvolává dvě otázky: z pohledu klienta, když má na výběr z několika nabídek, které jsou pro něj v danou chvíli relevantní, kterou vybrat? A pak globálně: které klienty ten konkrétní den oslovit, aby to mělo co nejlepší profitabilní efekt?

Jak se takhle velký projekt rozbíhal? Co mu předcházelo, než jste vůbec začali modelovat? Nejdříve musíš pochopit samotný systém. U nás to bylo relativně složité, protože tým byl nový a navíc přecházeli z jednoho marketingového systému na druhý. V době, kdy jsme začínali, probíhal přechod z CMTčka na Pegu, což je systém pro zasílání marketingových komunikací. To bylo celkem náročné a přinášelo to určité problémy.

Nicméně první, co je třeba vždy udělat, je pochopit data, jak vypadají, jaký mají formát a strukturu, t... (pokračuje)

Jasně, tady je opravený text, upravený pro lepší srozumitelnost a plynulost, přičemž jsem zachoval co nejvíce původní význam:

Ten systém, jak funguje – pochopit prostě, co znamenají ty jednotlivé IDčka, jak ty kampaně vypadají. Což na začátku pro nás bylo dost složité, protože v tom novém systému jich fungovalo málo, takže náš začátek byl opravdu hodně divoký. Bylo to divoké, ale nakonec jste se s tím poprali? Jasně. Tvorba těch prvotních datasetů byla zajímavá, protože struktura dat byla dost jiná, než jsme čekali, a bylo to opravdu zajímavé.

Dost času jsme strávili i u bílé tabule, jak ten systém vůbec bude vypadat. Původní plán byl takový, že by bylo víc menších modelů, které by každý předpovídaly nějaký propensity, například pro jednotlivé produkty nebo kampaně. Nicméně postupně jsme se rozhodli tímhle směrem nepůjdeme, protože kampaně vznikají a zanikají poměrně rychle a mění se podle podmínek.

Jedním z nejdůležitějších aspektů bylo to, že potřebujeme být schopni oskorovat i úplně novou kampaň, kterou jsme nikdy předtím neviděli. Čekat u každé nové kampaně na dostatek pozorování, než pro ni budeme moct vyvinout model, nepřichází v úvahu.

Zároveň ty kampaně nejsou v drtivé většině případů radikálně nové. Z určitého úhlu pohledu prodáváme vlastně pár věcí: voice, SMS, data, fixní internet a televizi. Tyto služby mají různé parametry – kolik stojí, jaké mají vlastnosti. Nové nabídky jsou vždy nějaká variace na něco, co už existuje, tedy nové parametry něčeho stávajícího. Není to něco úplně nového, věci se dají dobře parametrizovat.

Když máš novou nabídku, která je někde mezi – stojí víc než tato, míň než tamta, má nějaký jiný datový limit – dá se relativně dobře odhadnout, jak bude fungovat, protože už v datech vidíš něco velmi podobného.

V tom, jak vypadá layout dat, jsme se inspirovali klasickými recommendation engines, zejména paperem od Googlu o tom, jak funguje Google Play. Logika je taková, že jeden řádek v datasetu je kombinace aplikace a uživatele. To znamená, že máš vlastnosti té aplikace, vlastnosti člověka, dáš je do jednoho řádku jako vstupní vektor a model ti predikuje pravděpodobnost, že si tu appku stáhneš, klikneš na ni nebo ne – v podstatě nějakou interakci.

My jsme se tedy dostali k layoutu, kde model není jen jeden propenzitní model na televizi, propensity pro tento tarif a další pro tenhle tarif, ale má tuhle strukturu: jedno pozorování v datasetu je jedna kombinace kampaně, která odešla, a klienta, na kterého ta kampaň byla cílená.

Jaká by byla jiná možnost tu strukturu navrhnout? A proč by byla horší? Někteří, co dělají podobné věci, volí jiný přístup…

Pokud chceš, mohu pomoct i s pokračováním a ještě lépe upravit text. Stačí říct!

Opravený text:

Výhodou marketů Vodáči je, že mají nějaké propensitivní modely pro jednotlivé produkty. To znamená, že mají propensitivní model na takovýhle tarif, na jiný tarif, na další tarif. A ty pak nějak kombinují pomocí další logiky do finálního rozhodnutí. Tyhle věci ale nezohledňují některé jiné vlastnosti té nabídky.

My tady máme vložené v tom modelu dva vstupy. Jedním vstupem je zákazník, nebo jak my říkáme subscriber. To znamená, že víš, kolik platí, jak ten tarif využívá, kolik vyplýtval dat, kolik telefonoval, kolik posílal SMS a tak dále. Víš, jaké řešení aktuálně má, takže znáš jeho limity, víš, které jsou ty hezké fíčury, poměr limitů vůči tomu, co vyplácel, a tak dál. Také víš nějaké další věci o tom, jak se v poslední době choval – například jestli byl na nějakém webu, jestli na něj chodila nějaká komunikace a podobně. To je to, co víš o tom klientovi.

Druhý vstup je nabídka, to znamená, že víš, co ta nabídka nabízí – tedy produkt, který má své limity, cenu, slevu. Produkt jde přes určitý kanál, má svoji historii, například jakou měl response rate, jak lidé na něj v minulosti reagovali. Díky tomu do modelu dostaneš širší škálu různých parametrů. Zajímavé.

Ještě bych rád zůstal u toho uživatele, nebo subscribera, jak mu říkáte. Všechna tato data jste měli jako na stříbrném podnosu, nebo přišla ta těžká práce s krumpáčem a lopatou, abyste všechna tato data dostali do jednoho řádku „co já jsem za zákazníka“? Na druhou stranu, předpokládám, že v roce 2020 u operátora by tohle s těmi propensitivními modely už měli vyřešené, že jste měli tuhle práci trochu ulehčenou.

Přesně tak. Krumpáče a lopaty už byly v dávnější historii, takže ta práce, kdy lidi chodili po firmě a hledali, kde která data jsou, se dělala dříve. Já jsem se na tom už tolik nepodílel, sice to do jisté míry probíhá vždycky, ale intro procesu jsem se nezúčastnil. Co se týče těch fíčur ohledně klienta nebo subscribera, bylo to relativně jednoduché, protože všechna data u nás nejenže máme, ale vlastně si z nich napočítáváme takzvaný feature store – databázi připravených fíčur přímo pro modely. Ta slouží jako jednotný zdroj pravdy, aby stejná fíčura znamenala to samé napříč modely. Data jsou tedy ve formě, která se dá rovnou dát do modelů – například přeškálované, spojené fíčury s aplikovanými standardními úpravami.

A kde to držíte?

Ale to jsou normálně tabulky v Hive.

Ok, super, zpátky k druhé straně – té nabídkové?

Ta druhá strana byla složitější.

Pokud chcete, můžu text upravit ještě víc do formální podoby nebo jej zkrátit.

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

Ší, protože to bylo nové, to jsou ty nabídky (ofry). Znamená to, že jsme potřebovali dostat data z PEGy, z toho systému, který posílá SMSky, maily a podobně. Je tam něco, čemu se říká offer katalog, což je vlastně takový číselník, který říká, které nabídky v danou chvíli existují a jaké mají parametry. Je to zároveň trochu slabé místo, protože je udržovaný víceméně manuálně, takže s tím je vždycky trochu problém, nicméně v zásadě to funguje.

Na začátku trvalo nějakou dobu vysvětlovat, že vlastnosti nabídky, která není v offer katalogu, pro nás neexistují. Tím pádem, pokud offer katalog není vyplněný, predikce pro danou nabídku nebudou moc kvalitní. Nicméně už máme tuhle část za sebou, ale přesně tato práce byla naší starostí.

Takže říkáš, že bylo třeba použít krumpáč a lopaty, abychom dostali data k nám. Vysvětlit lidem, proč je to důležité, co do toho mají vůbec zadávat a tak dále. Tam toho bylo hodně.

Na začátku, co všechno jste měli napsané na té bílé tabuli? Jaké byly ty velké problémy, které jste řešili?

Hele, na té bílé tabuli zabíral nejvíc místa data layout. Bylo potřeba rozhodnout, jestli půjdeme stylem hodně malých modelů, které budeme nějak kombinovat, nebo jestli půjdeme stylem jednoho většího recommendation engine, popřípadě několik málo větších modelů do budoucna.

Druhý velký problém byl, co bude náš target (cílová metrika), kterou budeme optimalizovat. Klasicky, například na webu, se optimalizuje click-through rate, tedy míra prokliku. Například u Google Play je jasné, že cílem je, jestli si aplikaci stáhneš nebo ne, okamžitá zpětná vazba „cvak, je tam nebo není“.

S tímto ale máme několik problémů. Kampaně, které potřebujeme mezi sebou prioritizovat, totiž nabízejí dost rozdílné produkty, které mají velmi rozdílnou hodnotu. Jestli někomu pošleš kampaň „dokup si kilo dat navíc“, nebo kampaň „kup si velký balíček televize, za který budeš měsíčně platit paušál“, je to něco úplně jiného. Museli jsme do toho dostat finanční rozměr, protože nemůžeme lidem cpát jen malé věci. Navíc menší věci mají přirozeně vyšší response rate, protože se snadněji prodávají.

Další problém je, že response rate nejde definovat jednoznačně a stejně u všech produktů, protože znamená něco jiného u každé nabídky – například aktivace balíčku na jedno kliknutí není stejné jako instalace pevného internetu, která je složitější. Aby to bylo nějak sjednocené a platilo pro všechny kampaně, ať už cílí na jakoukoliv aktivitu klienta, finálním cílem je vždycky vydělat peníze. Takže tímto způsobem jsme se vlastně dostali...

Pokud chceš, mohu text i doplnit nebo rozšířit dle potřeby.

Tady je opravený text s úpravami gramatiky, interpunkce a stylu, aby byl čitelnější a plynulejší:

Ta myšlenka je, že optimalizujeme prostě to revenue, které od zákazníka v nějakých příštích dvou měsících dostaneme. A to má zároveň svoje nevýhody, protože regrese je složitější problém než binární klasifikace. To znamená, že ty modely jsou náročnější – celý proces modelování je složitější, včetně nějaké evaluace a tak dále. Zároveň, když pak třeba koukáš na to, jak ty věci performují, ať už ten model jako takový, nebo ty kampaně, tak ta spojitá veličina má větší rozptyl, tedy potřebuješ víc pozorování, abys měl výsledky statisticky významné. Takže to má své nevýhody, ale prostě jdeme touto cestou.

V jakém případě bys to teda doporučil a kdy naopak ne? Kdy si udělat to jednodušší a jít prostě na data, která máš přímo v tom kanálu? Nepředpokládám, že modelování customer lifetime value musí být super složité napříč všemi touchpointy a vším možným, že?

Hele, já jsem vlastně velký vyznavač Occamovy břitvy, takže mám rád, když jsou věci jednoduché. I na začátku jsem byl dlouho ten, kdo tomu revenuu vzdoroval – ne nutně vzdoroval, ale minimálně jsem byl jakoby „ďáblův advokát“ a říkal, že co kdybychom to dělal normálně jednoduše a nějakým post-processingem do toho pak nacpali to fíčko. Nicméně můžeš říct, že jsem tuhle debatu prohrál, byť si nepřipadám jako poražený. Dva roky poté...

Že konvertovali zpátky na svoji stranu?

Jo, už jsem konvertovaný na správnou víru. Každopádně si myslím, že je dobré začít tím nejjednodušším, minimálně jako prvním pilotem nebo nějakým baseline modelem. Kdybychom řešili třeba jenom jeden konkrétní produkt, tak bych určitě šel na nějaké kliky nebo aktivace a nějaký fíčko nebo něco takového.

Určitě.

Ale vím, že měl být model, který vládne všem.

Přesně, jeden vládne všem, jako „One ring to rule them all“, takže jo, takhle.

No, takže jste si vybrali revenue, takže to bylo na té bílé tabuli.

Přesně tak.

Našel bys tam ještě něco – nějaké další velké diskuze, které ovlivnily to, jak to dneska vypadá?

Našel bys tam spoustu malých, ale myslím, že tyhle dvě hlavní asi stačí – to jsou ty velké otázky: jak vypadají data a jak vypadá ten target, což si myslím, že je klíčové. Pak už to bylo jenom o tom to udělat.

Pak už to stačilo jenom udělat, no, přesně. A tím se zabýváme zbylé dva roky. Vlastně náš přístup od začátku byl takový, že jsme těch variant měli víc – první iterace například stavěla vedle sebe XGBoost a neuronovou síť. Zároveň tam byly dva další kontrolní soupeři – nějaká businessová heuristika, což v tomto případě bylo číslo přicházející od byznysu, které prioritizovalo kampaně na úrovni celé té kampaně. To znamená, že naše číslo je personalizované na klienta, zatímco tam bylo jasně dané, že když se kampaně setnou...

Pokud chcete, upravím ještě dál nebo rozdělím rozhovor do přehlednějších částí.

Jasně, tady je upravený text s opravami, aby byl srozumitelnější a stylisticky lepší:

Kampaň s vyšším číslem prostě půjde dřív. Takže je to v podstatě úplně jednoduché. Každá kampaň má něco, čemu říkáme "offer rate". Čím větší váha, tím důležitější, tím silnější kampaň se odešle. Tyhle offer rate fungovaly do dneška jako fallback scénář – kdyby naše hlavní řešení selhalo, pega by pokračovala v komunikaci dál na základě těchto jednoduchých priorit. A nese si s sebou tzv. peset, pokud by naše komponenta vyhořela.

Vedle toho byla klasická random kontrola, což znamená náhodně vygenerované číslo přeškálované na nějaké rozdělení, aby to vypadalo jako skóre z modelů, ale byla to prostě náhoda. Takže toto byla první iterace.

Výsledky byly docela překvapivé. Sázeli jsme na XGBoost, což je obvykle tabulkový off-the-shelf model, který funguje, ale tentokrát to úplně nepřineslo očekávaný efekt. Výsledek byl takový, že byznysová heuristika dopadla stejně jako náhoda. Bylo pro nás příjemné, že ani jedno z toho nás výrazně nepřekonalo.

Nicméně dlouho nebyl statisticky významný ani výkon XGBoostu, jeho výkon byl nepřesvědčivý. Samozřejmě záleželo na části dat, na které se člověk díval, ale celkově to nefungovalo. Chápu, že problém je složitější a komplexnější.

Obecně tedy nemám nějaké vyšší očekávání od XGBoostu kvůli tomu retestu, spíš jde o tento konkrétní kontext.

Neurónové sítě jsou složitější – jak jsme se před chvílí bavili o Okamově břitvě, u nich je nekonečné množství parametrů, které můžeš zvolit – kolik vrstev, jakých, a tak dále. XGBoost naopak většinou prostě „požere“ data a něco ti z nich dá. Samozřejmě máš i u něj hyperparametry, které můžeš ladit, ale většinou tím moc nezměníš.

Takže je to skvělý model na benchmarky s tabulkovými daty – protože ty data obvykle dobře zvládne a něco užitečného ti ukáže. Nicméně tady data nebyla ideální, protože stromy nemají rády řídké vstupní matice – a ty naše vstupy jsou hodně řídké.

Mnoho našich indikátorů jsou binární hodnoty, které znamenají například, že klient má nějaký produkt nebo vykonal určitou akci. Tyto indikátory jsou řídce zaplněné, tedy každá konkrétní hodnota „1“ nastává jen u malého procenta případů, a u spousty z nich je to podobné.

Navíc se spousta těchto indikátorů vždy týká jen části datasetu. Když se například podíváš na nabídky, tak podle toho, co nabízíš, některé indikátory vůbec nejsou definované pro určitou nabídku. Například když nabízíš televizi, tak tam…

Pokud chceš, můžu pokračovat dál s opravami nebo doplnit zbytek.

Tady je opravený text:

Jsou jiné parametry, než když prostě nabízíš mobilní tarif. Takže tam máš, jako u spousty těch funkcí, vždycky nuly a máš relativně široký dataset. A to těm rozhodovacím stromům úplně nesedí. Chápu. A tím pádem, jak vypadala ta vaše neurónka, kterou jste testovali?

Ta neurónka byla relativně jednoduchá, relativně mělká, nebylo tam tolik vrstev. Vlastně měla dva vstupy – subscriber a offer, kde nejdřív byla nějaká redukce dimenzionality, to znamená, že tam byly vrstvy, které schlukly tyhle dvě věci do užších vektorů, ty se pak daly k sobě a nad tím byly další vrstvy, myslím dvě dense vrstvy, které nakonec předpovídaly revenue.

A jak dlouho jste ji vyvíjeli, než jste ji pustili do testu?

Realita vývoje té neurónky byla taková, že běžela paralelně s tím XGBoostem, takže se pod tím iterovalo na datech, takže se to těžko odděluje, ale než to šlo do produkce, trvalo to několik měsíců. Ale zároveň byla spousta práce na straně dat, zejména na feature engineeringu.

Takže neurónka vyhrála váš ABCD test?

Ano, náš ABCD test vyhrála. Businessová heuristika a náhodný model skončili poslední, dlouhou dobu nic, pak XGBoost, zase dlouho nic, a potom vaše nová neurónka?

Ne, mezi business heuristikou, random modelem a XGBoostem nebylo tolik mezery, jak by se nám líbilo. Nicméně v zásadě ano.

Takže to byl váš šampion.

Ano, vývoj pokračoval dál tak, že jsme ještě nějakou dobu nechávali business heuristiku a random model jako další testy. Teď už tam nejsou, ale byly tam dlouho. Teprve nedávno jsme je úplně eliminovali.

A testovali jste to na historických anonymizovaných datech, nebo přímo v produkci?

Tohle už byl AB test normálně z produkce, kde jedna část báze skórovala jeden model, druhá část druhý model, další část byla random a další business heuristiky. Ty se pak odfiltrovaly.

A teď pokračujete v režimu champion-challenger?

Přesně tak, máme vždy champion model, kterého challengeujeme novým slibným přístupem.

Kolik challengers už porazilo šampiony? Kolikátou verzi modelu máte?

To je zajímavé, championem je pořád v zásadě ta samá neurónka s drobnými triky, žádný radikální challenger ji zatím neporazil. Teď máme jednoho slibného, ale zatím neuspěl v prvním testu.

A jaké jsou základy té neurónky teď?

Momentálně se snažíme přidat o jednu dimenzi navíc – snažíme se modelovat uplift, tedy říct, o kolik víc peněz dostaneme, když...

(Tady text končí nedokončený.)

Opravený text:

Oslovit versus kdybychom ji neposlali. Do toho dává další nějakou komplexitu, nicméně byznysově je to přesně ten objektiv, který chceš maximalizovat. Protože když máš model, který v našem případě předpovídá revenue, ale je jednodušší si to představit na nějakém binárním klasifikátoru – dejme tomu, že máš nějaký binární klasifikátor, který ti říká, jaká je pravděpodobnost, že zákazník odejde od Vodafonu. Tak vlastně, když nemodeluješ tenhle rozdíl oproti kontrole, tak prostě říkáš: „Jaká je pravděpodobnost, že odejde?“ Což není optimální, protože když si to představíš, nakreslil bys dvě dimenze a udělal takové kvadranty. Na jedné ose bys měl pravděpodobnost, že odejdeš ve světě, kde ho neoslovíme, a na druhou osu pravděpodobnost, že odejde v alternativním vesmíru, kde ho oslovíme. Prostě porovnáváš dva alternativní vesmíry mezi sebou. To dělám často a rád. Jo, já to mám taky rád.

A tak tady budeš mít asi čtyři kvadranty (reálně to nebude spojité, ale můžeš si to představit jako čtyři kvadranty). Budeš mít lidi, kteří mají vysokou pravděpodobnost odejít ve obou těchto scénářích. Ty oslovovat nechceš, protože proč? Prostě odejdou tak jako tak, je to vyhozená investice. Dále tam bude část, která ti tak jako tak zůstane. Když to shrneme, proč bys zachraňoval zbytečně někoho slevou, kdo ji nepotřebuje v tom smyslu, že stejně zůstane? A pak máš ty dva zajímavé kvadranty. Jeden je ten cílový – tam jsou lidi, kteří mají vysokou pravděpodobnost odejít, když jim nepošleš nabídku, ale nízkou pravděpodobnost, když jim ji pošleš. A pak je tam ještě ten teoreticky poslední, kde je to obráceně – kdy bys tím, že jim nabídku pošleš, třeba naštval zákazníka, a ten by proto odešel, případně si vzpomněl, že může odejít, a to udělal. To je tak trošku okrajové.

Ale prostě jde o to, že když tuhle druhou dimenzi nemáš a koukáš jenom na to, jak vysoká je pravděpodobnost, že zákazník odejde, tak budeš oslovovat i spoustu lidí, kteří jsou v tom kvadrantu „odejdu tak jako tak“. A vlastně takto dáváš potenciál někomu, z čehož nemáš nic. Plýtváš. Plýtváš tím, co jsme na začátku říkali, že je to omezený zdroj, tedy kontakty, a prostě plýtváš kontakty. Oslovuješ lidi, které oslovovat nepotřebuješ.

Podobně je to na tomhle binárním příkladu jednodušší, ale obdobně to funguje s tím revenuem. Ty potřebuješ, chceš získat co největší bonusové revenue oproti scénáři, kdy bys tu akci nedělal. A podle toho si vybíráš, komu posílat nabídky. Přesně tak.

A to tam teď přidáváte další vrstvu – neurónky, která by to ale... Hele, to je reálně jiná loss funkce. Protože tohle je takový, těhletěch vlastně... konceptuálně to znamená, že se s...

Pokud chceš, mohu pomoci s dokončením nebo ještě s lepším stylovým doladěním.

Tady je opravený text s úpravami pro lepší srozumitelnost a plynulost, přičemž jsem se snažil zachovat neformální styl:

Snažíš se nějakým způsobem modelovat kauzální vztah, prostě. Už to není jenom taková ta korelace, ale jde o to, že opravdu chceš vědět, co se stane, když uděláš tuhle konkrétní akci. Což je dost tricky business, že jo. Jednak na to potřebuješ kontrolu, kterou ne každý má, nebo ne každý má dostatečně velkou. Ale OK, to my máme, to není problém. Ale samotné modelování je prostě složitější.

Existují metody, které se zabývají tím, jak vlastně modelovat kauzální vztahy, dokonce i z observačních dat, ne jen z experimentů. Většina těchto metod je ale taková akademická a opravdu složitá. Spočívají třeba v tom, že nafituješ tři různé modely, které každý predikují trochu jinak upravený target nebo nějaká rezidua jiného modelu, a pak to nějak zkombinuješ. Je to opravdu složité. Teoreticky hezké, ale ta komplexita je z mého pohledu prakticky neunanageovatelná v produkčním prostředí, kdy se něco rozbije a tvoje skóre je kombinace tří silných skóre z black-box modelů. Když to budeš debugovat, úplně se v tom ztratíš.

Nicméně my jsme přišli na docela vtipný trik, který spočívá v tom, že u kauzalit je těžké přijít na to, jak to vlastně měřit, protože vždy vidíš jen jeden z těch dvou vesmírů.

Samozřejmě, takže prostě nejsi schopný použít klasické metriky jako mean squared error, protože u každého pozorování máš ground truth a předpověď a uděláš si průměrný rozdíl nebo průměr čtverců. Tady to nefunguje, protože vždycky potřebuješ tu kontrolu, která musí být náhodná. Nemůžeš vědět dopředu, jestli konkrétní klient je nebo není v kontrolní skupině, a musíš porovnávat průměry mezi nimi.

A tady je ta zajímavá metrika, která vypadá podobně jako křivky AUC u binárních klasifikátorů. V podstatě si na osu X nanášíš postupně nějaký modelový score, podle kterého řadíš data, a na osu X si značíš procento oslovených z báze. Na osu Y pak nanášíš rozdíl mezi průměrem těch, co jsou oslovení, a průměrem těch, co jsou v kontrolní skupině, kumulativně.

Protože kontrola je náhodná, model nemá způsob, jak zjistit, jestli jsi v kontrolní nebo cílové skupině, takže poměr těchto skupin by měl být víceméně konstantní. Model by měl stejným způsobem skórovat data z obou skupin, takže vznikne křivka. Čím je tahle křivka větší – stejné jako u AUC – tím chceš maximalizovat plochu pod křivkou.

Pokud chceš, mohu ti text ještě více zprůhlednit nebo upravit do formálnější podoby.

Tady je opravený text s lepší gramatikou, strukturou vět a trochu uhlazenější formou, ale přitom zachovaný neformální styl:

Touhle křivkou chceš, aby ten rozdíl v tom revenu byl na začátku tam, kde říkáš, že tvůj model predikuje ten největší uplift. My jsme objevili jeden paper, který byl poměrně obskurní, upřímně řečeno, ale přišel s metrikou velmi blízkou této, kterou lze normálně optimalizovat – dá se použít jako loss funkce. Takže můžeš mít tu plochu pod křivkou, nebo něco hodně podobného, přímo jako loss funkci pro neurónku.

V tom paperu to bylo ale udělané pro gradient boosting, takže jsme museli udělat nějaké složitější tweaky, abychom to přetáhli na neurónky a aby to dobře šlapalo i při trénování v minibatchech. Bylo tam tedy něco jako náš vstup k tomu.

Takže odpověď na otázku je, že to je custom loss funkce, není to nějaká vestavěná funkce v neurónce, ale je to vlastně speciální metrika přizpůsobená pro náš model.

Teď to máte už v produkci, nebo to teprve testujete?

Hele, teď jsme to testovali poprvé, a právě na tom je to krásné – testy děláme proto, aby se zjistilo, jestli to opravdu funguje. Můžeš mít model, kterému teoreticky věříš, je to tvůj challenger, něco super, cool a nejlepší na trhu, ale ono to třeba nefunguje.

Musíš zjistit, proč. V současnosti si myslíme, že to už víme. Jak jsem asi čtyřikrát zdůrazňoval, musíš si být opravdu jistý, že nemůžeš předpovědět kontrolku. Problém ale je, že kontrolky u jednotlivých kampaní nejsou stejně velké. U některých je bias – i když velmi nedokonalý, model se naučí, že některé datapointy budou s větší pravděpodobností v kontrolce než ne.

Teď proto experimentujeme s relativně elegantním řešením, kdy víme, jak velké kontrolky jsou, a do loss funkce přidáváme váhy, které to vyrovnají. Zatím ale jen offline.

Takže Champion pořád stojí?

Champion pořád stojí.

Super, uvidíme, jak svůj nový model ještě vyboostíte, aby svrhl krále. Těšíme se na to.

Ty jsi teď několikrát řekl „kontrolky“ a přístup ke kontrolním skupinám je pro mě úplně nové a super zajímavé téma. Můžeš víc vysvětlit, jak řešíš ty kontrolní skupiny? Mám pocit, že je to často brané jen jako „mám nějakou kontrolní skupinu, s tou pracuju“, ale vy k tomu přistupujete dost jinak a sofistikovaně, mám pravdu?

Jo, hele, tohle je hrozně zajímavý téma, které je zároveň snadné podcenit, což se i nám na začátku do velké míry povedlo. Na první pohled to vypadá jednoduše – vyčleníš nějaké klienty stranou, neoslovuješ je a pak porovnáš průměry. Pak si dáš kafe a je to dobrý.

Pokud chceš, mohu text ještě více upravit, zpřehlednit nebo rozdělit na kratší části. Stačí říct!

Tady je opravený text:

Prostě jeden vyjde větší než ten druhý, jenže ono to tak úplně není, protože různé biznesové otázky vyžadují různý design kontrolní skupiny – záleží na tom, kde v tom procesu vzniká náhoda a rozdělení na dvě skupiny.

To znamená, že když to vezmu tak, jak to děláme my, máme vlastně tři úrovně těch kontrolních skupin.

Nejširší nazýváme strategická kontrolka – to je vlastně otázka, která odpovídá na to, co by se stalo, kdyby nás tady všechny vyhodili a žádný CVM prostě nebylo, a Vodafone by fungoval bez nás. Nastoupí biznisheuristika? Nastoupí. Ale tohle je ještě o úroveň níž; to není, kdyby nebyl data science team, ale kdyby nebyly kampaně.

Tedy: kdyby nebyly marketingové kampaně na naší bázi, co by se stalo? Znamená to, že to jsou lidi, které vůbec neoslovujeme žádnou komunikací. Každý měsíc se nějaký podíl té kontrolní skupiny obmění – je to reálně trochu složitější – ale jde hlavně o to, že jsou to lidi, které vůbec neoslovujeme.

Pak jsou tu takzvané taktické kontrolky, které odpovídají na otázku: co kdybychom nevysílali tuhle konkrétní kampaň? Nebo spíše – co kdybychom nevysílali určitý typ kampaní? Naše kampaně mají nějakou hierarchickou strukturu, a tady už začíná ta složitost, protože co vlastně znamená "vypnout kampaň"?

Máme spoustu nabídek, které prezentují velmi podobné produkty, takže když jednu kampaň vyblokuješ, zákazníkovi se jako nejlepší nabídne jiná podobná kampaň – s o pár procent jinou slevou nebo trochu jiným limitem – a zjistíš "pullový efekt", protože stále nabízíš víceméně to samé.

Prvním designovým krokem tedy je promyslet, co všechno vlastně vyblokuješ a na jak dlouho. K tomu se můžeme ještě vrátit, ale každopádně taktické kontrolky u nás znamenají, že určitý typ kampaní – nejčastěji zaměřený na určitý typ produktů, třeba VTV (naše televize) – nebude dotyčný segment dostávat po nějakou dobu, ale ostatní kampaně ano.

Poslední jsou modelové kontrolky, což je to, o čem jsme mluvili před chvílí, když jsme porovnávali jednotlivé modely. Cílem je oddělit vliv modelu od kampaní. Kampaně normálně běží, počítají skóre, ale my vezmeme část těch skóre a nahradíme ji náhodnými čísly. V našem případě to bylo ještě složitější kvůli heuristikám, ale v nejjednodušším případě to znamená, že část databáze dostane místo skóre modelu náhodná čísla – ta mají podobné statistické rozdělení, aby vypadala stejně jako skóre modelu – a z této "náhody" pak kampaně stále nabízí stejný obsah. Všechno ostatní projde normálně, ale máme pravý od...

Můžu ještě s něčím pomoct?

Opravený text:

Dělený ten efekt toho, co do toho dáváme my jako data science tým. No, takže nad těmi třemi vrstvami kontrolních skupin přemýšlíte ve Vodafonu. Proč je to tak důležité? Proč to takto designujete? Protože každá ta vrstva ukazuje na někoho a říká, kolik vydělá nebo nevydělá peněz. Když se na to podíváš vždycky takhle zpátky, tak modelová kontrolka říká, kolik vydělá ten daný model, to znamená, že musí zaplatit data scientisty, kteří na tom pracují. Taktická prostě mluví o celém týmu nebo o dané kampani, nebo jak jsem říkal, o nějaké řadě kampaní. To znamená, že ji typicky má na starosti nějaký kampaněvej manažer, takže říká, zda tohle vydělává peníze. No a ta strategická říká, jestli tedy vůbec

jako zajímavého děláme nebo nehrajeme. Jako divize. Přesně. Skvělé. No a co jste se tam naučili tím pádem, jak s tím pracovat? Hele, těch lekcí tam bylo spousta. Celkově ta hlavní lekce je, že celé tohle téma je výrazně složitější, než jak se to na začátku zdá. Protože jednak si musíš prostě rozhodnout o jednotlivých designech, musíš si udělat ty klasická rozhodnutí, jak mají být ty kontrolky velké, abys měl nějaké rozumné konfidenční intervaly a tak dál. Ale co se nám tady povedlo, byl takový to klasický podcenění té komplexity týkající se implementace, přímo řečeno. Takže to je takové typické téma engineering versus science a celá tahle sranda. Protože vlastně... Jakým způsobem teď vlastně definujete ty kontrolní skupiny? Kdo vypadá? Je to nějaký automatizovaný systém? Jasně, děje se to. Ono je to jiné pro jednotlivé úrovně. Vlastně tu prostřední, tu taktickou, dělá systém, který posílá ty kampaně. Jinak to vlastně být nemůže, protože se rozhoduje v reálném čase, zda teď někdo má vidět nebo nemá vidět nějaký banner. To jinak nejde. Ty modelové kontrolky si děláme my, protože tam naopak jenom máme naše score, které ještě musíme nějak postprocesovat, takže tam náhoda jako funguje. Takže to si děláme my a tu strategickou kontrolku také děláme my. Ta je na první pohled relativně jednoduchá. Každý měsíc vybereš nějaké lidi, které do ní dáš. Naopak z ní vypadne ta nejstarší kohorta a to se taky dělá u nás. Každopádně nejvíc komplexity vzniká právě při předávání práce mezi námi a lidmi z týmu PEGy, kde je logika těch kontrolek poměrně složitá, protože blokuješ různé kampaně na určitou dobu. To znamená, že ve chvíli, kdy jsi v té kontrolce a přijdou další komunikace, musí jít rozhodnutí, které proběhlo před nějakou dobou. Je to poměrně složité. Tam se můžou stát věci, že například člověk přijde na web a vyskočí na něj najednou víc komunikací najednou, dejme tomu z dané kategorie, a musí jít tu samou kontrolku, ale systém v tu chvíli neví, takže to byl jeden z těch nejtěžších bugů, které jsme v tomhle...

Pokud chcete, mohu text ještě dále upravit podle potřeby, například upravit jazyk pro formálnější či neformálnější styl.

Zde je opravená a upravená verze textu pro lepší srozumitelnost a plynulost:

To, co jsme řešili, bylo to, že v jednom časovém okamžiku (timestamp) se jednoduše stalo, že padl jak target, tak i kontrolka. Člověk si totiž někde v aplikaci rozklikl něco, vyšlo na něj víc bannerů — prostě náhoda, že se to stalo přesně v ten samý okamžik. V jednom okamžiku padl target, "dobrý, jdeme dál", a zároveň padla kontrolka, která byla vlastně kontaminovaná nějakým oslovením. Taková věc se ale nedá rozumně vyhodnocovat. To byl velký problém (challenge), kvůli kterému jsme museli přejít k generování kontrolek pomocí hashů. Náhodu jsme generovali jako hash IDčka klienta a data, takže je to unikátní pro daný timestamp. Používáme modulohash, ze kterého vznikne něco jako náhodné číslo, ale náhodné číslo, které je pro daný timestamp vždy stejné. Když se takhle vygeneruje náhoda, tak všechny náhody "padnou" stejně.

Když si teď představím váš engine na tvorbu kontrolních skupin, co v něm všechno máte a jak jste to postavili? Chápu teoreticky problém, říkal jsi, že implementace byla o něco náročnější než plánování, což se ukázalo být tou nejtěžší částí, tak...

Je to vlastně nadstavba nad Pega systémem, do kterého jsme dodávali víceméně spíš logiku než samotnou implementaci té taktické kontrolky. Na naší straně to bylo pak spíš o monitorování a kontrole datové kvality a obecně kvality dodržování té logiky, protože svět kampaní je relativně komplikovaný.

Manuály, procesy a kampaně se naklikávají v systému, a i ti, kdo je spravují, se někdy dostanou do situace, kdy je potřeba kontaktní politiku nebo kontrolku legálně obejít. Některé typy komunikace vyžadují, aby byly legální a musely se dostat ke všem adresátům. Nelze tedy jednoduše nastavit pravidlo, že se vždycky všem něco nějakým způsobem zablokuje. To znamená, že v konfiguraci jsou nevyhnutelně i možnosti, které ignorují kontrolku nebo kontaktní politiku. To je samozřejmě slabé místo kvůli lidským chybám nebo komunikačnímu šumu — může se snadno stát, že si někdo myslí, že něco funguje nějak, a ve skutečnosti to funguje jinak.

Proto bylo velmi důležité nastavit monitoring kvality samotných kontrolek — jestli je dodržovaná daná logika a kdyby nebyla, abychom přesně věděli, ve které kampani můžeme vyhodnocování důvěřovat a kterým ne.

Engineering na naší straně tedy spíš spočívá ve vyhodnocování — dnes je to implementováno velmi paranoidně. Kromě klasických datových kontrol — například jestli existují tabulky nebo jestli obsahují data za požadované časové období — děláme i poměrně složité kontroly v interaction history. Kontrolujeme, jestli bylo dodrženo, že celý interval...

Pokud chceš, mohu pomoci s dokončením další části textu nebo ještě upřesnit stylistické či gramatické drobnosti.

Jasně, tady je opravená verze textu s lepší strukturou a formálnější formou:

Bylo oslovených více lidí a nestalo se, že by došlo k selhání pouze u dvou různých parametrů, ale u několika dalších podobných parametrů. Takže pak máš tabulku, kde na úrovni každého jednotlivého oslovení máš něco, čemu říkáme "hard checky" – tedy ověřujeme, jestli byla splněna všechna byznysová pravidla a zda je zadaná komunikace v pořádku.

Když pak děláš vyhodnocení za určité období, vedle toho, kolik kampaň vydělala (nebo nevydělala) peněz a ke kolika vedla aktivacím, vidíš zároveň i to, jestli jsou data v pořádku, jestli jim můžeš věřit, jestli tam jsou nějaké chyby nebo jestli jsou data zásadně nesprávná.

Navíc nad tím máme ještě další úroveň testů, ne na úrovni jednotlivé komunikace, ale na úrovni celkového vyhodnocení. Třeba máme takový test, který může být z různých důvodů jednoduše pokazitelný – spousta bugů se projevuje tím, že je jiný poměr kontrolky (kontrolní skupiny), která sleduje danou množinu dat, kterou právě vyhodnocuješ. Z Confluence si stáhneš tabulku, kde je napsané, jak velké ty kontrolní skupiny mají být, a otestuješ hypotézu, jestli to odpovídá. Když zjistíš, že ne, systém ti dá alert, že něco není v pořádku.

A k čemu vám to pomohlo? Pomohlo to k lepším rozhodnutím o tom, které kampaně fungují a jak s tím dále pracovat. Důležité je, že se občas stane chyba – jsme přeci jenom lidé – a některá chyba projde. Například když se kontrolka někde oslovuje špatně nebo když kampaně neodpovídají našim očekáváním co do délky sledování. Když si pak vytáhneš výsledky, vidíš, že tam je spousta chyb tohoto typu. V takovém případě ukazujeme výsledky pouze interně a vůbec nepublikujeme falešný výsledek, který by byl založený na nekvalitních datech. Takže vlastně zastavíme vydání informace ven, i když nějaké číslo vždycky existuje – jestli ta kampaň vydělala nebo ne. Varujeme tedy uživatele, aby na to nepohlíželi jako na definitivní výsledek, a jdeme data řešit a debugovat.

Tento test na proporci je takový ještě trochu neúplný – upozorní tě, že něco není v pořádku, ale někdy není hned jasné, co přesně. Právě tak jsme například přišli na bug, o kterém jsem mluvil. Takže tento systém ukládá další vrstvu kontroly kvality dat.

A tato činnost ti často upozornění opět přinese, což chápu. Máte vůbec pocit, že tato vrstva kontrol zasahuje i do samotného učení modelu? Tedy že například kampaně, které jsou výrazně špatné nebo nepřesné, by se měly vyfiltrovat z tréninkového vzorku?

Pokud chceš, mohu text ještě více zjednodušit nebo upravit podle konkrétního účelu.

Opravený text:

Sně, je to jako jeden zdroj pravdy pro ten model i pro to vyhodnocení. No, to, co mě překvapilo na naší diskuzi o kontrolních skupinách, bylo, jak je to vlastně nejenom technické a matematické téma, ale i obchodní téma. Jak si vlastně musíte chránit svoje kontrolní skupiny a obhajovat jejich hodnotu. Jasně, tohle je velmi ošemetné téma. Jednak proto, že říkáte lidem, zda vydělávají peníze, nebo ne, což má samozřejmě své dopady.

Zároveň je potřeba si uvědomit, že každá kontrolní skupina něco stojí, protože představuje opportunity cost. Máte něco, co vám vydělává peníze, ale sám říkáte, že tenhle přístup nebudete na části populace používat. Je tam logická smyčka: kdybyste kontrolní skupinu neměl, ani byste nevěděl, jestli to vydělává, nebo prodělává, a třeba by bylo potřeba něco vypnout, takže je dobré mít tu kontrolku.

Nicméně občas je těžké si obhájit, jak velké kontrolní skupiny by měly být. Musíte mít představu, jak velké by měly být, aby bylo možné statisticky významně změřit očekávaný efekt. Zároveň jsme trochu biasovaní směrem ke co největším kontrolkám, abychom měli co nejjistější měření. Naopak lidé z byznysu chtějí vydělávat co nejvíc peněz, takže by chtěli mít kontrolní skupiny co nejmenší, nebo je vůbec nechtějí. To se nám už podařilo vysvětlit, že i když to zpočátku nebylo jasné všem stakeholderům, kontrolní skupiny potřebujeme.

Lidé mají tendenci být optimističtí a myslí si: jasně, moje kampaň vydělává spoustu peněz, takže to je super. My sami si o modelech myslíme, že jsou skvělé, a nikdo nechce věřit, že by jeho nový model mohl prohrát se starším modelem. Je to psychologická věc, proti které se musíme bránit a poctivě měřit, abychom věděli, zda peníze skutečně vyděláváme.

Takže je to velká diskuze a vyjednávání, osvěta, proč potřebujeme kontrolní skupiny, dobré argumenty, třeba i založené na modelech a upliftových targetech, které nás přibližují k byznysovým cílům. Máme velkou výhodu, že náš šéf CVMka býval data scientist, takže problém tam není. Spíš je potřeba mluvit se stakeholdery, tedy přímými vlastníky jednotlivých kampaní.

Pokud chceš, mohu i dál opravit zbytek textu.

Tady je opravený text:

Už na té nejvyšší úrovni, která nás zajímá, tam ten model je od začátku, což je super. A když se bavíme třeba s lidmi z jiných vodafoních trhů v rámci skupiny, tak ne vždycky to takhle funguje. To gratuluju, vaši kolegové vám musí závidět.

Takže teď váš offer priority matrix běží, je to ústřední algoritmus, který určuje, co zákazníci Vodafonu najdou ve svých telefonech, mailech nebo co se jim zobrazí na webu po přihlášení. Aha, super. A co ještě tam optimalizujete?

Optimalizujeme vlastně všechny direkty, tedy i webovou personalizaci pro přihlášené zákazníky. Přihlášených lidí. Aplikace Lab, NBAčka, co se ti zobrazí, když přijdeš na pobočku – co se tam zobrazí člověku, co tam s tebou mluví. SMSky, e-maily.

Super, a jaká je budoucnost toho systému, kromě toho, že přijdete s lepším Challengerem, který ho konečně porazí? Jaká je jeho budoucnost?

Samozřejmě, že náš příští Challenger už ho konečně porazí. To je ta krátkodobá budoucnost. Věříme tomu a máme kontrolní skupinu, která to potvrzuje.

Dlouhodobější výzva ale bude – a není to jenom pro tento model, ale vlastně pro všechny – že skupina na nás chystá migraci do Google Cloudu. Časem budeme muset všechny tyto věci předělat velmi zásadním způsobem.

A teď máte běžící systém u vás?

Momentálně máme systém běžící on-premise a přechod do cloudu bude zajímavý. V tuto chvíli máme nějaké první malé proof of concept, kde testujeme jednoduchý model, o kterém víme, že nepůjde do produkce, prostě si tam zkoušíme nové věci. Je to zatím v plenkách. Mluvíme o dalších dvou letech, než se to rozjede ve velkém. To je ten dlouhodobější plán.

Kdybychom prošli váš současný datový stack, jaké technologie používáte na jednotlivých částech?

Na začátek je dobré říct, že sdílíme platformu, které říkáme Moreflows, společně s kluky z Network Analytics. Moreflows je super název pro platformu.

S kluky z Network Analytics, což jsou lidi, kteří monitorují kvalitu sítě, jestli jsou někde výpadky a podobně – mají logy přímo z věží. To jsou opravdu big data – timestampy různých událostí, které monitorují, co se se sítí děje.

Tato platforma nás podporuje a je to klastr, kde jsou data uložená na HDFS. Nad tím běží Sparkový klastr, což je náš hlavní stack. Pracujeme v Pythonu, konkrétně v PySparku, používáme JupyterLab pro práci s notebooky, MLflow pro správu modelů, kam si logujeme výsledky experimentů a uložené modely.

Na produkci používáme většinou batchové joby, které jsou zpracovávány přes Airflow. Dokonce máme lehký framework, kde si datoví vědci mohou jednodušší joby velmi jednoduše nakonfigurovat pomocí YAML konfigurací.

Pokud chcete, mohu text ještě více upravit, například zkrátit, rozdělit do odstavců nebo upravit styl. Dejte vědět!

Opravený text:

To znamená, když máš nějaký job, který říká: „Hele, tady natoč nějaké prostředí, pak v něm spusť tenhle skript, pak v něm spusť tenhle skript, pak to prostředí zahoď a pošli někomu mail, že to proběhlo OK,“ tak si člověk nemusí psát ten DAG v Pythonu, ale vyplní někde nějaký relativně jednoduchý YAML a udělá se mu to samo. Ale zároveň prostě velký disclaimer – říkám to na základě toho, že jsem si četl dokumentaci a že jsme v tom dělali maličký POC. Jestli to tak jenom vypadá, nebo to opravdu je takhle super, je ještě hudba budoucnosti. Takže tak.

Mně se na tom líbí a i z dnešního povídání mám ten pocit, že Data Science aplikace je z velké části o inženýrství, že hlavní téma dneska není Machine Learning, ale Machine Learning Ops vlastně. Do velké míry to tak určitě je.

Co to pro tebe znamená jako pro statistika a datového profesionála? Znamená to, že často tady zaznívá Continuous Integration, Continuous Delivery, softwarové přístupy, přístupy software inženýrů.

Vnímáš to tak taky?
Určitě, určitě.
A znamená to, že se statistice musí trochu měnit, postupně dáváme větší důraz na programování, včetně nějakých best practices. Protože takový typický data scientist přicházející z akademického backgroundu – je to trochu klišé, ale v reálu to do velké míry skutečně platí – není tak citlivý na to, aby hezky pojmenovával proměnné, měl kód se strukturou, aby to celé mělo nějakou kulturu a aby git repo nebylo jeden velký bordel. A to je určitý přerod v myšlení, nepochybně.

Kromě dalšího upskillingu lidí a nabírání nových, co vás ve Vodafonu v datovém týmu čeká? V big data týmu nebo v týmu vašich datových vědců?

Co nás čeká? Jak už jsem říkal, velkým tématem je cloud, kde dokončujeme první POC. Teď by se mělo rozjet něco už realističtějšího, kde bude první use case, který by mohl běžet na realisticky velkých datech. Jednoho dne v produkci. Takže to bude zajímavé, i vyzkoušet si, co to bude stát v cloudu. To je další otázka, na kterou se názory různí, jak moc se to vyplatí nebo nevyplatí. O tom si můžeme popovídat až někdy, až budu vědět odpověď, kterou teď nevím, ale cloud je pro nás obrovské téma. Velký přerod.

Zároveň Vodafon migruje – ne my, ale i celý datový sklad. Takže to je větší projekt než jen my sami. A to je prostě velké téma.

Držím moc palce, ať se dobrá věc podaří.
Děkuju moc, že jsi tady sdílel své know-how a ukazoval nám útroby strojového učení ve Vodafonu. Snad brzy nashledanou u nějakého dalšího tématu.
Já děkuju. Nashledanou. Díky, že jste dooslouchali.

Hali Data Talk až sem! Jak se vám tahle epizoda líbila? Co byste na našem podcastu zlepšili? Koho pozvat příště? Dejte mi prosím vědět, co si myslíte. A to můžete buď osobně na příštím Data Mesh Meetupu, nebo hned teď na mail jirka@datatalk.cz.

A pokud se vám tahle epizoda líbila, doporučte ji prosím dál. Klikajte na srdíčka, na hvězdičky, dávejte subscriby. Ať nám svítí dashboardy zeleně, křivky dělají hokejku a všichni stakeholdeři schvalují extra budget.

Ještě jednou vám děkuju. 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, Atakamně a Mantě.

Pokud máte návrhy, nějaké tipy na hosty nebo témata, děláte vlastní event nebo byste chtěli datovou komunitu podpořit jinak, určitě mi dejte vědět. Díky. Nechť vás provází data!