Podcast

Dobrý den, jmenuji se Jirka Vichrek a vítám vás u dalšího dílu Datatolku. Mým dnešním hostem je můj kamarád a zakladatel technologické firmy Big Hub, Tomáš Obínek. Ahoj, Tomáši.
Ahoj, Jirko.

Prostě jsme šli svým tempem a chtěli jsme to dělat co nejlépe, jak jsme dokázali. Proto jsme založili BigHub, pak jsme přizvali naše spolužáky z RDRky a díky tomu jsme se dostali tam, kde jsme nyní.
No a kde tedy jste?
V dnešní době realizujeme velké data science projekty pro firmy z oblasti logistiky, financí, retailu a také hodně energetiky. Zde v Česku například pro Pročez, Gasnet a na Slovensku máme několik úzkých zakázek. Naší cílovou skupinou jsou především velké korporace. Je to zajímavé z toho hlediska, že v takové velké firmě má i malá změna velký dopad, takže za to jsme rádi, což je náš typický klient. Na druhou stranu jsme realizovali i projekty pro startupy a v současné době máme rozpracované dva projekty pro menší firmy. Také rozjíždíme spolupráci s ČVUT, kde připravujeme jeden projekt. Takže rozhodně nepracujeme jen pro velké korporace, ale především pro ně.
To zní, že máte plné ruce práce. Jak se vám to tak zdařilo? Je to proto, že poptávka za ty roky mnohonásobně vzrostla, protože to děláte jinak, nebo jste si vybrali dobrý segment?
Poptávka určitě hodně roste. My jsme začínali asi před sedmi lety, v roce 2016. Tehdy jsme museli tyto služby spíše vynucovat firmám, řekněme, protože před sedmi lety byly firmy často uzavřené v drahých systémech, které neumožňovaly příliš analytiky, nebo ji umožňovaly, ale šlo o krabicová řešení na bázi SASu či podobných nástrojů. My jsme přicházeli s něčím, co v našem segmentu znamenalo revoluci.

Jednou z těch revolučních věcí byl open source a související technologie kolem datové analytiky. Tito nástroje postupně zpřístupňovaly firmy jako Google, Yahoo, Facebook a mnoho dalších komunitě. My jsme tyto technologie znali jako první, alespoň v Česku, a pomáhali jsme klientům je přijmout a využít k efektivnímu vývoji a provozu data science řešení.
Když mluvíš o těch technologiích, co konkrétně máš na mysli? Jaké open source nástroje?
Jsou to jak knihovny, tak celé frameworky. Jak jsem říkal, firmu jsme založili v roce 2016. Už v roce 2015 Google otevřel TensorFlow, což je nástroj pro tvorbu deep learningových modelů. O pár let později Google otevřel také Airflow, což je skvělý nástroj pro MLOps, orchestraci pracovních toků, původně z dílen Airbnb a dalších. Můžu zmínit i MLflow, které vzniklo asi v roce 2018. Jak naše firma vznikala a rozvíjela se, tyto open source technologie jsme používali a používáme je dodnes.

Musím ale říct, že jak jsme fungovali před sedmi, šesti, pěti lety na bázi on-premise řešení, kdy jsme stavěli analytické platformy například na Hadoopu nebo Cloudera, a pomáhali jsme klientům nasazovat tyto technologie do produkčních systémů, přinášelo to řadu problémů. Údržba verzí byla náročná, první verze těchto nástrojů nebyly vždy příliš stabilní. My jsme často museli provádět bugfixy a klienti nebyli schopni provoz převzít sami, takže jsme to museli provozovat my.
Mohl bys uvést nějaký konkrétní příklad, kdy dnes by to šlo na pár kliknutí, ale tehdy vám to zabralo celý víkend?
Určitě je jich řada. Například nasazení Airflow na fyzickém serveru tehdy trvalo dost času a nefungovalo příliš spolehlivě. Museli jsme řešit problémy s výkonnostními exekutory a psát vlastní custom kód, což jsou situace, které člověk nechce dělat.
Ty tu mluvíš o on-premise řešeních, ale dnes už vaše řešení funguje čistě v cloudu, že?
Ano, tak to je. Na začátku jsme začínali s on-premise řešeními, protože firmy do cloudu nebyly tolik otevřené a také dostupné technologie ještě neexistovaly. Nasazení on-premise nebo do cloudu, pokud tam nejsou manažované služby, přináší podobné nároky. Před asi pěti lety jsme ale přeskočili na cloud, což je druhý aspekt revoluce.

Cloud výrazně zpřístupnil data science, zjednodušil jeho provoz a odstranil mnoho technických bariér. Díky tomu se nyní můžeme soustředit více na samotná data science řešení a ne tolik na infrastrukturu.
Ještě bych doplnil, že technologie, o kterých mluvím, se postupně začaly objevovat také v cloudu. Například MLflow je integrované v platformě Databricks. Mnoho dalších nástrojů, jako Airflow, je dostupných jako managed services. Pokud nejsou přesně stejné, jsou upravené, ale dělají podobnou práci. Naše znalosti těchto technologií z první ruky nám pomáhají i dnes.
A nyní přejděme k tomu, co děláte nyní, konkrétně k data science v logistice, která je jedním z vašich příkladů. Proč jste zvolili právě tento příklad?
Především proto, že je velmi zajímavý a nechci sem přenášet něco, co by nebylo relevantní. Já se v logistice pohybuji už přes pět let a je to jedna z mých hlavních oblastí, kterou mám na starosti v BigHubu. Use cases, které tam řešíme, mají celosvětový dosah. Když model pak běží v různých zemích a na všech kontinentech, přináší to určitá specifika, což je také důvod výběru tohoto případu do dnešního dílu.
Jaké příležitosti v logistice vidíte? Je to tím, že jde o fyzický svět a tedy komplexní systém?
Ano. V logistice, například při přepravě balíčků napříč kontinenty, funguje mnoho prvků – nákladní automobily, vlaky, lodě, letadla, spousta techniky i lidí. Jsou tam přepravní depa, místa, kde se předává zboží, kde se skladují zásilky a podobně, například v e-commerce. Témata jako prediktivní údržba otevírají mnoho možností v optimalizaci skladových procesů. Dále je tam oblast financí, IT nebo chodu logistické společnosti obecně. Existuje řada tiketů například z customer care či interních systémů, které mohou být analyzovány a zlepšovány. Témat je velmi mnoho, ať už čistě logistických, nebo souvisejících.

Vzpomínám si ještě na jeden zajímavý případ, kdy jsme řešili, jak nejefektivněji naskládat věci podle velikosti a typu do prostoru, třeba do nákladního auta nebo přepravního kontejneru. To byla moc pěkná úloha.
To bych já potřeboval pro kufr svého auta.
Já také, bohužel. Nejsme vlastníci takových řešení. Ale někdy jindy.
A ten use case, o kterém dnes budeme hovořit?
Můžeme klidně mluvit o jakémkoliv z těch, které máme. Aktuálně máme asi 16 aktivních projektů. Loni jsme dodali tři velké use cases týkající se podvodů v mezinárodní přepravě – fraud detection. To je téma, které má zásadní dopad, například pokud se přepravují podezřelé nebo nebezpečné zásilky, což může mít významné důsledky pro firmy – ať už z hlediska reputačního rizika, nebo regulačních požadavků, které stanovují různé státy. Podařilo se nám rozjet zajímavé projekty, které jsme dokončili v lednu a únoru a všechny jsou nyní v produkci.
Co znamená „reputační riziko“? Například že by tam někdo poslal sarin?
To asi také. Kromě toho jsou tu přepravy zbraní a podobných položek, což má různý význam v různých kontextech. Typicky, a na tom jsme přímo pracovali, jde o porušování duševního vlastnictví – například přeprava neoriginálního zboží známých značek, tedy padělků. To sebou nese konkrétní reputační riziko, protože firma se chce od tohoto distancovat a spolupracovat s originálními výrobci.
Takže jste řešili tři projekty, které jsou vzájemně propojené?
Ano, přesně. Jeden se týkal přepravy nebezpečného zboží, druhý porušování duševního vlastnictví a třetí byl zaměřený na cílené podvody, kdy se přeprava deklaruje jako levnější zboží, aby se ušetřilo na clech.
Jako když posílám trička z Ameriky jako dárky?
Může to být i ten případ, ale týká se to spíše firem a jejich klientely, kteří to dělají masově.
Jak se takové podvody řeší? V jaké fázi se do takového projektu zapojujete? Co je předem připraveno, když začnete?
V tomto případě jsme navázali na dlouhodobou spolupráci s analytickým oddělením klienta, které samo pilotovalo různá řešení, případně je řešíme my. Konkrétní projekt už měl návrh modelu a ověřili, že by to na základě dat mohlo fungovat. Na nás bylo zpracování dat z jednoduchých csv souborů, které klient zasílal e-mailem, pak model vylepšit, aby dával relevantnější výsledky, a také nasadit do produkčního systému klienta, aby vše fungovalo automatizovaně. Cílem bylo, aby lidé, kteří přebírají zásilky, dostávali v reálném čase informaci o možném podezření z podvodu. To je u takových problémů klíčové.
Takže se bavíme o projektu, kde modelování datové vědy dělá klient, ale vy řešíte nasazení?
Ano, ale zároveň jsme se hlouběji ponořili i do datové vědy, model jsme upravili, přeskupili a vylepšovali.
Jak takový projekt vypadá z pohledu někoho laického a poměrně komplexního?
V první fázi se provádí pilotní zkouška (proof of concept), jestli data science dává smysl. Probíhá tedy jen samotné modelování. Při přechodu do produkce je třeba řešit mnohem více věcí. Z naší zkušenosti je datová věda, tedy modelování, jen asi 10–15 % celého projektu, protože vstupuje řada dalších faktorů.

Například v případě podvodů jsme se potřebovali napojit na primární systémy, kde tečou surová data v reálném čase z přebírajících stanic. Tato data jsme zpracovávali a odebírali je. Také bylo potřeba přístup k archivovaným datům klienta pro trénink modelu, která jsou uložena na různých platformách. Někdy jsou připravená, jindy je třeba je složitě získat.
Můžeš být konkrétní?
V tomto případě měl klient klasickou Velkou datovou databázi Teradata.
Dobře, a co dál?
Data jsme přenesli na naši Kubernetes platformu, kde aplikace běží. Tam probíhá trénink modelu, běží API, protože pak musíme službu zprostředkovat a napojit na další systémy. Součástí jsou také procesy pro datovou přípravu a další úpravy.
Běží to u vás nebo u klienta?
Všechno běží přímo u klienta. Praktičtí nikdy netaháme data k sobě. Vždy to držíme v jejich prostředí, protože respektujeme jejich kontext. Máme sice preference na technologie, ale když to není potřeba, nevymýšlíme velké změny. Díky tomu můžeme pracovat s mnoha technologiemi a porovnávat je.
Jaký technologický stack používáte? Říkal jsi, že jste se napojovali na Teradatu, co se pak děje?
Data si stáhneme na Kubernetes platformu, kde běží naše aplikace. Probíhá tam trénink modelu, API služby a další datové procesy. Model běží v kontejnerech, v tomto případě jsme používali gradientní rozhodovací stromy, konkrétně XGBoost v Pythonu, což se nejvíce osvědčilo předchozím pilotním testem od klienta.
V jakém prostředí Kubernetes nasazujete?
Tato platforma je určena on-premise, tedy běží přímo u klienta. Mimo on-premise máme některé služby v cloudu, například Azure Cloud. Využíváme Airflow pro orchestraci procesů a MLflow pro správu modelů, verzí a řízení produkce. Vše je plně automatizované i s kontrolou kvality.
Takže trénink modelu běží týdenně?
Ano, data se pravidelně stahují, zpracovávají, model na týdenní bázi trénuje a výsledky se ukládají do MLflow. To umožňuje správu verzí a rozhodování o nasazení jednotlivých modelů do produkce.

Zda ten model splňuje to, co potřebujeme, a potom ho případně nasadíme do produkce, nebo ne. Takže zde existuje určitá kontrola kvality, protože vlastně samotná aplikace je jednou zavedena do produkce, ale je potřeba ji nějakým způsobem provozovat tak, aby dlouhodobě přinášela užitek. Když to bude několik let fungovat, nesmí se stát, že by model začal produkovat nesmysly. Kdyby si toho všiml samotný klient, bylo by to samozřejmě špatné a zároveň by to bylo už pozdě. Proto se snažíme, aby bylo řešení co nejvíce udržitelné. Je to tak.

Nepociťujete velké nároky na první projekt? V rámci pilotního projektu se totiž soustředíme především na datovou vědu. To znamená, že model vyvineme, stáhneme a vypočteme, a výstupy poskytneme klientovi například v Power BI, aby se na ně mohl podívat, nebo dokonce v Excelu, dle jeho preferencí. Automatizace a řešení dlouhodobé kvality již spadá do produkční fáze.

Zmínil jste API, které posílá výstupy z modelu. Co model vlastně vypočítává? Určuje nějakou pravděpodobnost toho, zda je daná zásilka podvodná, nebo co vlastně optimalizujete? Ano, model vypočítává určitou pravděpodobnost. Pro další zpracování těchto výstupů ale klient potřebuje pouze informaci, zda má vydat varování, nebo ne. Protože buď člověk v depu zásilku zkontroluje, nebo nezkontroluje. Na konci tedy převádíme pravděpodobnost na jednoduché rozhodnutí ano/ne.

Toto rozhodnutí je napojeno na další systémy. Klient má nástroje, které umožňují, aby se data dostala do zařízení koncových uživatelů, například na tablety. Proto máme API rozhraní.

Koho vlastně představují tito uživatelé? Jsou to skladníci, celníci, tedy lidé, kteří zásilku přebírají nebo vyřizují záležitosti klienta, například dokumentaci. Mohou si vyžádat další materiály nebo zásilku otevřít a zkontrolovat.

Shrnuto tedy posíláte pravděpodobnost, která se následně převede na příkaz otevřít, zkontrolovat či nekontrolovat? Ano. Do rozhodování ale navíc vstupují další faktory.

Jedním z nich je například kapacita kontrolorů. Kdyby měli zkontrolovat úplně vše, chytali bychom pravděpodobně všechno, ale kapacita lidí to nedovolí. Pro konkrétní stanice máme definovaný limit, kolik kontroly lze denně zvládnout, takže se toto musí při rozhodování zohlednit.

Pro účely klienta, aby si mohl výsledky i později zkontrolovat mimo operativu, ukládáme detailnější výstupy, včetně pravděpodobností a mnoha dalších dat určených pro reporting. Tento reporting využívají spíše manažeři než samotní kontroloři.

Manažeři se tak mohou podívat na výsledky i zpětně, zhodnotit přesnost predikcí a skutečný výskyt problému. A využíváte tyto informace k dalšímu učení modelu? Zatím ne, zpětná vazba je zatím spíše orientační, nicméně v budoucnu plánujeme toto využívat k dalším fázím projektu a zlepšování modelu.

V rámci pilotního projektu jsme také připravili data pro reporting, který si klient již spravuje samostatně.

Když se podíváte na celý projekt, vím, že datová věda tvoří velkou část práce, a hodně z ní je engineering. Jaký byl poměr práce mezi vývojem modelu, API a samotnou aplikací? V tomhle případě to odpovídalo zhruba tak deseti procentům práce na API a aplikaci. Právě jsme dodělali fázi tréninku modelu a připravili API, ale projekt zahrnoval i část real-time odběru dat. Data klient uchovává ve frontách v raw formátu přímo ze stanic a je potřeba je načíst, zpracovat a poslat do rozhodovacího API.

Součástí byla i optimalizace API, protože původní řešení bylo pomalé a vyhodnocování neprobíhalo dostatečně rychle. Museli jsme optimalizovat skripty, aby zvládly globální zátěž, například během čínského nového roku, Vánoc nebo nečekaných událostí, kdy nesmí dojít ke zpoždění odpovědí.

Zmínil jste low-level kódování. Na co konkrétně jste zasahovali? Bylo to na úrovni Pythonu, kde jsme přizpůsobovali kód API. I když se říká, že v Pythonu nemůže být kód nejrychlejší, zvolili jsme tento jazyk i kvůli udržovatelnosti, protože provoz a podporu nakonec zajišťuje klient.

Původně klient používal některé funkce, které byly pomalé, a proto jsme přecházeli k efektivnějším knihovnám. O technických detailech by vám mohl říci více Petr, který byl technickým lídrem projektu a měl s tímto přímý kontakt. Já jsem původně datový vědec a datový inženýr, ale dnešní projekty BigHubu sleduji spíše z pozice, ne že bych přímo zasahoval do kódu.

Proč je pro vás tento use case tak klíčový a zajímavý? Líbí se mi, že odhaluje podvodníky v logistice. Mám rád projekty, které mají reálný přínos, a líbí se mi, když se podaří odhalit někoho, kdo se snaží podvádět. To je určitě jedna z věcí.

Druhá věc je globální rozsah. Systém již nyní funguje přibližně ve dvaceti zemích a v průběhu příštího čtvrtletí plánujeme nasazení v dalších státech. Již během testování jsme zaznamenali velké množství požadavků, aby byl systém připraven na globální provoz. A opravdu mě těší, že modely odhalují podvodníky ve všech sledovaných zemích, odkudkoliv přijde zásilka, když projde našimi modely.

Podařilo se vám s klientem sdílet informace o projektu? Klient se nehovoří přímo jménem, ale podařilo se nám poskytnout některé základní informace, což mě velmi těší.

Co vás tento projekt naučil, Tomáši? Už jsme pro tohoto klienta dělali mnoho globálních use casů, ale tento projekt byl oproti ostatním o úroveň výše, pokud jde o množství požadavků a nároky na rychlou odezvu. Měli jsme několik překvapení zejména při výkonových testech. Snažili jsme se získat data o množství požadavků a jejich charakteru už v raných fázích projektu, ale nepodařilo se nám to a chtěl bych příště být v této oblasti důslednější.

Díky tomu jsme některé věci dělali bez dokonale přesných podkladů, což se při testech ukázalo jako obtížné. Ale jsem rád, že tým situaci zvládl a všechny termíny jsme splnili.

Pro mě byla tato zkušenost velkou lekcí jako delivery managera, že je potřeba mít co nejdříve co nejvíce relevantních informací. Ačkoliv jsme se je snažili získat, realita se mnohdy liší od ideálu.

Říkáte, že nyní systém běží v produkci a zaměstnanci dostávají pokyny, které balíčky kontrolovat, otevírat a co od koho vyžadovat. Máte již nějaké výsledky? Můžete sdělit úspěšnost v odhalování kriminálních skupin?

Ano, všechny modely již běží v produkci. První byl nasazen v listopadu nebo prosinci, a nyní nasazujeme poslední model zaměřený na nebezpečné zboží. Konkrétní výsledky nemohu sdílet, protože stále čekáme na obchodní analýzu a zpětnou vazbu od klienta, která je zatím pozitivní, ale detailnější informace budeme muset ještě nějakou dobu počkat. Je to velmi čerstvé.

Ještě jedna otázka k use case: Ve všech těch třech scénářích – nebezpečné zboží, špatně oceněné zásilky, porušení duševního vlastnictví – máte tři různé systémy nebo jsou architektonicky stejné? Přístup je stejný, ale na úrovni dat či složení modelu jsou rozdíly. Data i samotné modely se liší, ale metodika je podobná. Tento princip pak využíváme i v navazujících projektech.

Jaké další use cases jste řešili, případně na co se chystáte v budoucnu? Jeden zajímavý projekt byl zpracování textových dat, konkrétně klasifikace produktů podle textových popisů do harmonizovaného systému HS codes. To je globální standard pro kategorizaci produktů s některými lokálními odlišnostmi.

Například jsme z popisků produktů jako telefony či jiné elektroniky třídili produkty do příslušných kategorií HS codes. Tento projekt byl velmi zajímavý z hlediska MLOps a nasazení, a dlouhodobě na něm pracujeme.

Co vás ještě čeká? Chystáte další projekty detekce podvodů? Ano, máme připravené projekty na včasnou identifikaci nových potenciálních podvodníků, protože ti stávající si mohou založit nový účet nebo subjekt a začít znovu.

Dalším oblíbeným tématem jsou finanční úzké hrdla a další dlouhodobé aktivity.

Co vás v BigHubu letos kromě logistiky čeká? Mnoho věcí. Máme výborný tým, který chce udržet kontinuální vývoj a přinášet nové projekty.

Chceme se také více zaměřit na vědeckou sféru. Máme například projekt s ČVUT na automatizaci třídění stavebního materiálu – některá část stavebního odpadu se zatím třídí manuálně a cílem je přidat automatizaci na úrovni modelů, které by mohly odhalit a třídit materiály. Tento projekt je aktuálně ve fázi příprav na jarní výzvu Technologické agentury České republiky.

Dále je zde projekt z oblasti medicíny, kde nás oslovili lékaři z fakulty jaderné techniky se snahou detekovat neurologické potíže pomocí senzorů. Těším se, že letos tento projekt posune dál.

Oblasti medicíny a vědeckého výzkumu jsou nám historicky blízké, a těšíme se na další výzvy.

Co se týče lidských zdrojů, máme v plánu letos založit pobočku v Brně, protože tam je mnoho skvělých lidí a chtěli bychom tam sestavit tým jako tu v Praze. Brněnský datameetup ukázal, že tamní komunita je velmi kvalitní.

Děkuji moc, Tomáši, za rozhovor, držím palce a měj se hezky.

Děkuji, Jirko, měj se také hezky. Ahoj.

Děkuji vám, že jste poslouchali Data Talk až do konce. Jak se vám tato epizoda líbila? Co byste na našem podcastu zlepšili? Koho máte zájem pozvat příště? Dejte mi prosím vědět, co si myslíte buď osobně na příštím datameetupu, nebo hned teď na e-mail jirka-datatolk.cz.

Pokud se vám epizoda líbila, doporučte ji prosím dále – klikněte na srdíčka, hvězdičky, přihlaste se k odběru, aby nám svítily dashboardy zeleně, křivky rostly a všichni stakeholdeři schválili 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 – BigHubu, Deep Note, Atakamě a Mantě.

Pokud máte návrhy 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 nechť vás provází data.