Podcast

Dobrý den, moje jméno je Jirka Vicherek.
Ahoj všem, moje jméno je Barbara Hinerová.
A vítáme vás u dalšího dílu podcastu Datatolk.
Dneska tady máme Ksenyu Šakurovou, Data Science Team Lead z firmy Notino.
Ahoj.

Než se dostaneme k Data Science a k vašim aktivitám, které pro Notino děláte, pojď nám říct, jak jsi se dostala k datům, jaká je tvoje historie a jak jsi se dostala k tomu, co děláš teď?

Já jsem studovala na FITu, dříve VLT v Praze. Na bakalářském stupni jsem studovala softwarové inženýrství. IT mě zajímalo z různých pohledů – je to pořád se rozvíjející obor s mnoha specializacemi a možnostmi.

Když jsem dokončila bakalářské studium, na FITu vznikal nový obor věnovaný strojovému učení a umělé inteligenci, což mě ještě víc zaujalo, a tak jsem na tento obor přešla a pokračovala ve studiu.

A kdy to bylo?

Bylo to už dávno, školu jsem dokončila v roce 2016. Studovali jsme široké spektrum věcí. FIT se mi tehdy velmi líbil, nevím, jak je to tam dnes, ale v té době to bylo skvělé, protože během studia jsme se naučili asi deset programovacích jazyků, počítačovou vědu, operační systémy a další oblasti.

Museli jsme se alespoň trochu ponořit do všech částí IT, což mi pak hodně pomohlo v budoucí práci. Díky tomu nejsem příliš závislá na jiných specialistech.

Obor strojového učení byl také velmi široký. Tehdy nebyly populární pouze transformery a velké jazykové modely, takže jsme se učili vše od základů strojového učení, statistiky a podobně.

Po škole jsem nastoupila jako výzkumnice do Seznamu. Seznam.cz je velká firma s mnoha odděleními. Jako výzkumný tým jsme pro všechna tato oddělení dělali různé projekty – od textového zpracování pro vyhledávač a relevantnost stránek, přes vyhledávání obrázků až po odstraňování vodoznaků. Prostě všechno, co si lze představit pod pojmem data science a výzkum.

Naše týmy nebyly specializované na konkrétní oddělení Seznamu. Když přišel požadavek od jakéhokoli oddělení, například zboží, šli jsme pomáhat. Díky tomu jsem získala velké množství zkušeností s různými typy úloh. Byla to velmi zajímavá práce.

Časem jsem dostala vlastní tým ke zpracování dat i vedení lidí. V Seznamu jsem pracovala skoro šest let.

Něco z toho, co jsi dělala v Seznamu, tedy v letech 2016 až 2022, tam běží ještě něco v produkci? Nějaké modely? Něco, co pokud půjdu na Zboží.cz nebo Heureku, tak mi tam vyskočí tvůj kód?

Doufám, že ano, ale některé věci je s časem potřeba obměňovat, takže věřím, že zbývající výzkumníci denně vylepšují ty modely. Co se týče technologií, používali jsme různé přístupy – například při určování relevance stránek regresní lesy nebo různé rankovací algoritmy na hledání podobnosti.

Nebo při...

[Text končí zde.]

Jasně, tady je opravený text s plynulejším tokem a opravami gramatiky a stylu:

Je potřeba speciálního refresh robota, který musí obcházet internet, a to nemůžeš dělat pořád, protože je to hodně náročné, takže jsem musela odhadovat, jak často se jednotlivé stránky aktualizují a jestli je vůbec potřeba je navštěvovat. Taky se na to například používaly lesní algoritmy. Byl tam také zajímavý pokus konkrétně na tu úlohu s řešením pomocí genetického algoritmu, což bylo vtipné — odhadoval se obrovský a složitý vzorec, kterým by se to muselo odhadovat. Fungovalo to ale spíš nedokonale, i tak to bylo zajímavé.

Teď se v těchto systémech běžně používají neuronové sítě, ale relevance prošla dlouhou cestou od různých modelů a algoritmů až k využití neuronových sítí. Projekt, který jsem zmiňovala ohledně odstraňování vodotisku, tam se trénovala jednodušší neuronová síť i na tento problém, což bylo opět docela vtipné, protože ten projekt jsme dělali asi kvartál před tím, než Google vydal knihovnu na odstraňování vodotisku, která by nám práci hodně ulehčila, ale bohužel.

Ty mě tím přivádíš k druhému dotazu: přišla jsi do Seznamu, který je v oblasti machine learningu hodně pokročilý, je to center of excellence tady v Česku, a zároveň jsi tam byla šest let během asi největšího boomu machine learningu, datové vědy, frameworků a nástrojů. Jak se podle tebe to, co jsi se naučila ve škole, lišilo od byznysové praxe, zvlášť když každé půl roku vycházely nové knihovny nabízející out-of-the-box řešení, která si dřív musel člověk složitě skládat?

Ano, potvrzovalo to, co jsme dělali. Zároveň šlo ale i o to zjistit, jak něco zlepšit nebo jak to přesně funguje, protože každý algoritmus má své vlastnosti a funguje dobře na určitém typu dat, zatímco na jiných nemusí. Takže je třeba umět vybrat správný nástroj pro konkrétní data. To byl taky velmi zajímavý aspekt výzkumu.

Když jste pak porovnávali výsledky toho, co vydal třeba Google nebo jiní vývojáři, s tím, co jste vyvinuli vy, vyšlo něco lepšího u vás? Nedokážu říct, že by to bylo lepší přímo od nás, a ani jsme neměli mnoho příležitostí dělat přesně to samé, co Google později vydal. Hodně jsme také využívali mix různých metod, například gradient boost, LightGBM a podobně — jsou to cizí nástroje, ale i tak bylo to zajímavé a rozhodně to nebylo frustrující.

Něco, k čemu se asi dostaneme i u Notina, je, že škála problémů i řešení je opravdu široká — jedno řešení nepasuje na vše. Čistě algoritmická nebo matematická řešení versus neuronové sítě — mám pocit, že se to v čase hodně mění a podle use caseů jsou lidé, kteří na všechno nasadí neuronové sítě, a pak někdo řekne, že stroje udělají stejnou práci a navíc se o ně nemusí tolik starat. Jak se na tohle nahlíží?

Hodně často jsme dávali prioritu jednodušším algoritmům, nejen kvůli tomu, že jsou lépe interpretovatelné, ale také...

Pokud chceš, text mohu ještě doplnit či specifikovat podle dalších požadavků.

Jistě, tady je opravený text s lepší plynulostí, gramatikou a stylistikou:

Li tomu, že je to jednodušší na nasazování. Tohle je prostě o tom, co člověk musí myslet, když ten research je vzdálený od vývoje, který to opravdu potom nasazuje. Může jít úplně do strašidelné mašinéry, ale v podstatě potom s tím budeš mít víc práce, než to má přínos. Prostě vždycky je asi otázka takového tradeoffu mezi přínosem modelu a složitostí toho modelu. Když tahle neuronka funguje o procento líp než nějaké lesy, možná to nemá smysl používat. Koukali jsme se na to takhle i v Seznamu, i teď v Notinu. A v Seznamu to bylo asi ještě o to podstatnější mít ta jednoduchá řešení, protože musela být rychlá, ne? Že to bylo víc real-timeová aplikace. Jo, to taky často. Když se to týkalo vyhledávání, tak to určitě.

No, v Seznamu jsi byla teda šest let a potom jsi začala hledat novou misi a potkala Martina Kavříka, našeho starého známého, který postavil Data Office v Notinu. Tak na co tě nalákal, s čím za tebou přišel v roce 2022?

Martin v tu dobu už nebyl úplně na zelené louce s tím Data Office, ale bylo to ještě na počátcích, co se týče Data Science týmu, že oni teprve začínali vznikat. A v podstatě mě asi přilákala svoboda výběru toho, jak co řešit, a fakt tam byl široký prostor na ty úlohy, které můžeme řešit. Můj tým měl vzít na starost logistiku a supply chain, to znamená zlepšit veškeré možné procesy v rámci skladu, v rámci přeskladňování zboží mezi sklady, tak, aby to „střeva“ Notina fungovala správným a optimálním způsobem.

Tehdy tým v podstatě ani neexistoval, když jsem přišla do Notina, byly jsme dvě s mojí kolegyní, teď už máme větší tým – šest lidí – a, jak jsem říkala, staráme se o logistiku, o všechno, co prostě přijde, že jde zlepšit: algoritmy pickování, nějaké výběry produktů na různé typy „rychlech“ a linek. Teď pomalu rozjíždíme projekt o řešení skladování, jak připravovat pickovací galerii lepším způsobem, aby to zase bylo optimální.

No, tým mě přilákal, takového jako Terejko Ignito. A bylo to pro tebe spíš výhodou přejít do něčeho nebo do týmu, který je vlastně už specializovaný na jeden konkrétní department, vzhledem k tomu, že v Seznamu byl ten záběr úloh daleko širší?

No, a na druhou stranu v Seznamu jsi asi prakticky ten fyzický svět a logistiku řešila minimálně, ne? Tam bylo všechno digitální data. Logistika vyhledávání. Logistika vyhledávání? Ano, přesně tak. To je úplně jiný svět a úplně jiný business. V podstatě tady se to týká úplně jiné domény.

Specifikem logistiky je, že nemůžeš provést žádný A/B test. Při měření kvality nějakého modelu ve vakuu totiž nevíš, jaké jiné procesy mohou ovlivnit tvůj model. Tady něco zrychluješ, ale na druhou stranu někde jinde může vzniknout problém, o kterém prostě nevíš. A je to hodně závislé na lidském faktoru, viď?

Ano, je to fakt hodně závislé na lidském faktoru. Jeden z projektů, co jsme řešili, byla optimalizace směn. To znamená, jak správně vybrat lidi na správné datum pracovního nasazení…

Pokud chceš, mohu pokračovat v opravě zbytku textu.

Zde je opravený a upravený text:

… a dostat to do správného departmentu. Ale problém je, že i když to optimalizuješ teoreticky, neznamená to, že lidi budou opravdu pracovat, že nikoho nebude bolet hlava, nebo… Přesně tak. Nebo jednoduše, když lidé vidí, že nějaký proces teď běží rychleji a jednodušeji, neznamená to, že na něm stráví méně času. Znamená to, že budou mít víc času na kafe. To znamená, že vlivy v reálném světě nejsou vůbec stejné, jak je měříš v těch teoretických modelech. U Seznamu to bylo trochu jiné, protože tam zase …

A ten lidský faktor – jak lidi budou klikat, clickbait efekty a všechno to víme, ale to je možná snáz měřitelné teoreticky. Tam je taky větší masa dat. Já bych se ještě chtěl zastavit u vzniku data science týmu. Jste rozdělení podle domén, takže tvůj tým má na starost logistiku a supply chain. Jaké další data science týmy tam tedy jsou?

Jo, máme data science tým, který řeší doporučování – všichni ty reklamní plochy, co vidíte na Notinu. Je tým, který řeší retail a vše s tím spojené. Je tým, který řeší věci například pro nákup a marketing, pomáhají jim předpovídat, které produkty se mají prodávat v jakých objemech a tak dále. Máme taky tým, který řeší spíš statistické věci z webu a z aplikace. Když počítám, tak to jsou všechny data science týmy. Vedle toho v data office máme BI tým, který řeší data, reporting a další podobné věci. A máme ještě jiný tým, který je spíš MLOps tým a stará se o to, aby naše modely fungovaly v produkci a aby bylo vše řádně zastřešené.

A ten MLOps tým tedy řeší vše pro všechny data science týmy?
Přesně tak, mají hodně práce. Takže klasicky Ops.

Ještě bych se rád zastavil u jedné věci, co jsme tady společně řešili. Tím, že vznikla data science doména v Notinu, co to pro tebe a částečně i pro Martina muselo znamenat – jít vysvětlovat, jak data science vlastně funguje? Často narážíme na to, že BI je jiné zvíře, software engineering zase jiné, a data science, to je pro všechny ostatní velmi zvláštní zvířátko. Takže to musela být určitě práce a vybojování si prostoru.

Přesně tak. Data science je specifické v tom, že ne vždycky musí existovat jasné řešení. To je hlavní rozdíl oproti software engineeringu – že prostě ne vždy můžeš opravdu pomoct lidem s tím, s čím přišli. A přínos není vždy tak velký, jak by oni očekávali. To je velké téma. Často se setkávám s tím, že někdo přijde a řekne: „Dejte tam nějaký model, zeptejte se ChatGPT,“ a občas opravdu musím lidem vysvětlovat, že to takhle nelze řešit úkoly, které řešíme my. Dalším velkým tématem je důležitost metrik – často podnikání není úplně tak data-driven, jak si myslí, a je boj vysvětlit, proč je lepší konkrétní metrika než jiná, co to vůbec znamená pro model a pro reálný svět.

Jo, má to svá specifika. Je to taková kombinace na hranici výzkumu a softwarového inženýrství, má to jiné tempo, nefunguje to úplně stejně…

Pokud chceš, mohu text ještě více upravit či zestručnit.

Opravený text:

Je to trochu jako softwarový development ve smyslu sprintů a všech těch věcí, prostě to musí fungovat jiným způsobem. No a jakým způsobem tedy u vás organizujete práci nebo prioritizujete? Jak vypadá plán? Když je to náročné, nemusí to mít výsledek a potřebuje to víc času, takže je to dost hard sell.

Jo, my jsme určitě pod nějakým časovým tlakem, protože Notín je hodně dynamická firma a tým. Ten obor, který teď v Notínu řešíme, je takový čerstvý, máme spoustu nepokrytých témat, jestli se to dá tak říct. Často jsme pod časovým tlakem, prioritizujeme úlohy podle toho, jaký vidíme potenciální přínos a jaké tam vidíme problémy. Například některé výzkumy se prostě musí odložit, protože jsme zjistili, že na to neexistují data, takže to pro nás někdo musí vytvořit a necháváme to v backlogu, že se k tomu vrátíme, až to bude možné.

Snažíme se co nejrychleji vytvářet nějaké POC, které obvykle přináší ten největší skok v přínosu. Když je POC ověřené na dalších datech a mělo by to z krabice fungovat, snažíme se to nasazovat, a až potom se k tomu vracíme s cílem modely zlepšovat.

Nemáme stand-upy jako softwaroví inženýři. V týmu nepracujeme na jednom projektu najednou. Obvykle jsme rozdělení po párech nebo trojicích, které řeší nějaký projekt. Potkáváme se týdně, občas častěji, aby jsme brainstormovali o nápadech, zjišťovali, jak to s modelem vypadá a jestli funguje, nebo proč ne.

Co ale děláme a na co věnujeme hodně času, což věřím, že v budoucnu čas šetří, je průběžná kontrola kvality kódu a vytváření dokumentace. Snažíme se opravdu popisovat kroky, proč jsme některá data nechali, nebo proč jsme některé modely přeskočili. Věřím, že nám to v budoucnu pomůže šetřit čas.

Zkoušeli jsme různé přístupy a už to nemá smysl měnit.

Jo, určitě. To taky chápu. Na druhou stranu to ale prodlužuje time to delivery – trvá déle udělat to správně, než to zpracovat povrchně.

Jak odhaduješ časovou náročnost těchto věcí? Nemáte sice sprinty, ale pravidelně se potkáváte, máš kapacitu, priority – je tam nějaké pravidlo, například když přijde poptávka, zjistíte její hodnotu, dáme ji do backlogu a začneme řešit? Máte nastavený nějaký časový rámec, třeba do dvou týdnů chcete mít data zmapovaná nebo projekt rozdělený?

Když za námi přijde nějaký nápad, nebo jej máme my sami, snažím se vždycky sednout a rozkouskovat, co všechno znamená to dodat. Často největší čas zabere příprava dat nebo zjištění jejich kvality. U firem, které rychle rostou, často data trpí kvalitou – nejsou dobře popsaná, něco s nimi není v pořádku. Proto je důležité vědět, jaké datové zdroje máme k dispozici a co vlastně znamenají.

Opravený text:

Když se mi podaří obdržet ta data, tak je to v pořádku, prostě se snažím nějak nadcenit, kolik by stálo připravit tu práci úplně všechno. Jinak se snažím udělat nějakou rychlou analýzu těch dat, v podstatě během pár hodin se podívat, co vůbec existuje, poptat se lidí a tak dále – taková verifikace. Přesně tak.

Co se týče vytváření modelů, tam záleží na tom, jestli chci zkusit nějakou věc „z krabičky“, nebo jestli to bude něco, co budeme muset psát ručně, nějaký algoritmus, který musíme napsat teď, abychom zkontrolovali PLC. Můj superinterní pravidlo je, kolik by to trvalo mně, a potom to vynásobím podle toho, jak moc je juniorní nebo seniorní člověk, který to bude dělat.

Takže násobíš, nebo dělíš?
Násobím.
Přesně tak. Já tím, jak mám už hodně zkušeností s psaním různých algoritmů, můžu alespoň odhadnout, kolik by to trvalo mně. Největší riziko je, že z nějakého důvodu model nebude fungovat a budeme vymýšlet nějaké alternativy. Ale zase co to může znamenat? Nějaký feature engineering může trvat x hodin nebo dnů. Co to znamená zkusit jiný model? Ok, to zabere zase tolik a tolik času. Já se vždycky snažím mít nějaký rozsah, kolik by to minimálně trvalo, až to…

To můžou být maximálně tak rok, ale to je u jakéhokoliv výzkumu, a to nechci, protože mám plán, že příští kvartál chci mít tři projekty. Tím pádem má tým na jeden projekt zhruba měsíc. A když jsem u tebe, researchere, tak si rozmyslím, jestli budu dělat jeden projekt a budu v něm úplně ponořený, nebo jestli budu mít víc projektů, abych mohla aspoň trochu přepínat, když by mi to z jednoho modelu začalo lézt na nervy.

Projekty střídáme, není nikdo, kdo by pracoval pořád jen na jednom projektu, to tak prostě nechodí. Jak jsem říkala, snažíme se co nejrychleji dodat nějaké proof of concept (POC), a potom to aktualizovat. To znamená, že ti dva nebo tři lidé, kteří dělají POC, ho dotáhnou do produkce, a pak se na nějakou dobu přepnou na jiný projekt, protože chceme něco někde zlepšit nebo dodat další POC. Potom se můžou vrátit na původní projekt, pokud máme nějaký nápad.

S týmem se proto snažím komunikovat, kdo v čem vidí potenciál, kdo má jaké nápady a tak dále. Chci, aby lidi pracovali i na svých vlastních nápadech, nejen na tom, co já řeknu, že by stálo za to zkusit zpracovat. Poměrně často tak přeskakujeme z projektu na projekt. Občas se stane, že jeden člověk řeší současně dva projekty a musí si čas mezi nimi rozdělovat.

Říkáš POC, takže když teda nasadíte nějaké POC do produkce, má to třeba měsíc na otestování, dejte vám zpětnou vazbu a pak se rozhodnete, co s tím dál uděláte, nebo jak to bude dále vypadat?
Možná ještě dřív, než je POC připravené jít do produkce, zkoumáme, jestli vidíme reálný přínos. Například když něco vůbec neexistovalo – mám teď projekt, který by měl pomáhat s uvolňováním prostoru…

Zde je opravený text, upravený pro lepší srozumitelnost, stylistiku a gramatiku:

Na skladě probíhá speciální proces, kterému říkají SIP. Pracovníci procházejí jednotlivými regály, kontrolují, které krabice jsou poloprázdné, sesypávají je a uvolňují tak místo. Tento proces je obzvláště důležitý v době výprodejů, vánoční sezóny a podobně, kdy je potřeba do skladu naskladnit co nejvíce položek. Dělalo se to vždycky tak, že se například od doku sesypávaly poloprázdné krabice.

My jsme ale přišli s tím, že to není úplně efektivní. Některé zboží se totiž vyprodá během několika hodin, takže není potřeba je sesypávat – vyprázdní se samo. Naopak jiné zboží se neprodává, nebo se prodává společně do jedné zakázky, a proto by mělo smysl dávat ho do jedné krabice.

Momentálně jsme v první fázi tohoto procesu a dodali jsme model, který odhaduje, jak dlouho konkrétní box vydrží na skladě. Díky tomu mohou pracovníci řídit sesypávání efektivněji a sesypávat pouze "ležáky", tedy zboží, které se dlouho neprodává. Podle předběžných výpočtů by to mělo ušetřit desítky procent času, který pracovníci nyní na sesypávání tráví — tedy méně práce a zároveň vyšší efektivita.

Tento projekt navíc byl relativně snadno vyčíslitelný, pokud jde o přínos, protože stačilo spočítat možný dopad na čas či náklady. U některých jiných projektů to však tak snadné není, protože přínosy mohou spočívat například v urychlení dodání zakázek, což se obtížně převádí na peníze.

Navíc při optimalizaci procesů se může stát, že zlepší jeden, ale zhorší jiný. Během spolupráce s byznysem jsme proto často intenzivně diskutovali, protože zpočátku nebyla plná důvěra v to, že naše nápady bude možné implementovat v produkčním prostředí.

Nakonec jsme se proto rozhodli vytvořit simulační prostředí. Jak jsem už zmínila, sklad nelze testovat přímo, protože by to bylo velmi nákladné a složité – například by bylo potřeba provozovat dva sklady současně nebo najmout dvě skupiny zaměstnanců se stejnými parametry.

My máme čtyři sklady, a tak jsme vytvořili digitální dvojče skladu. Hodně práce jsme věnovali nejen data science, ale i softwarovému vývoji. Vytvořili jsme dvě simulační prostředí. Jedno se zabývá simulací přepravy mezi našimi distribučními centry (DC), která, jak už jsem říkala, máme čtyři. Druhé simulační prostředí vizualizuje fungování skladu samotného.

Nejnáročnější a nejnákladnější proces na skladě je picking, a proto se v simulačním prostředí nejvíce zaměřujeme právě na něj. Teď již můžeme otestovat, jaký vliv může mít nasazení našeho algoritmu na jiné části skladu a další procesy.

Například jsme vyzkoušeli algoritmus, který sjednocuje zakázky do speciálních pikovacích boxů. Zdálo by se, že je to optimální řešení a průměrná zakázka rychleji dorazí do balírny. Nicméně simulace nám ukázala, že některá patra skladu budou výrazně přetížená nebo se přetíží například fast pick linka – speciální rychlá linka na picking – a stejně tak i balírna může být zaneprázdněná.

Pokud si přejete, mohu text ještě více zkrátit či rozčlenit do odstavců.

Jistě, tady je opravený text:

Je to informace, kterou obchodní tým může použít pro rozhodování. Pokud chceme algoritmus nasadit, musíme přesně vědět, jak ho implementovat a co všechno s tím souvisí, například další opatření. Bude potřeba mít více koordinátorů na patrech, více baličů nebo třeba více pickerů. Tyto aspekty umíme dobře popsat. Teď hodně používáme Streamlit, protože interaktivně vizualizuje data, máme tam spoustu různých grafů, jak to vypadá na jednotlivých patrech, u dopravníků a podobně. Dá se to ukázat obchodnímu týmu, který má rád barevné obrázky. Všem vysvětlíme, co to vlastně udělá, a oni to vidí na vlastní oči.

Co to znamená vytvořit digitální dvojče distribučního centra (DC) a jednotlivého skladu? Je to simulační prostředí? Na začátku to byla hodně byznys-analytická práce. Řekla bych, že to znamená zjistit, jak to tam vůbec funguje, jaké jsou aktuální algoritmy, protože nejde jen o to vymyslet něco nového, ale v produkci ono nějakým způsobem funguje. Tam už jsou algoritmy na všechny ty věci. Museli jsme zjistit, jak to funguje, v některých případech procházet kódy, procesy a udělat vlastní kopii. Například v produkci je to napsáno v C#, tak jsme to museli projít a vytvořit jejich digitální dvojče, které by fungovalo v našem prostředí. Dále jsme museli zjistit byznysová omezení – proč to tak funguje, co můžeme zlepšit, co nemůžeme měnit atd.

Potom, co jsme to všechno sesbírali, jsme implementovali řešení, což trvalo delší dobu. Trochu jsme bojovali s tím, že implementace byla v Pythonu a nebyla vždy úplně rychlá. Spoustu věcí jsme potom museli optimalizovat. A také jsme vymýšleli všechny možné metriky, které tam chceme zobrazit – to je práce nekonečná, stále něco přidáváme, snažíme se to rozšiřovat a upřesňovat.

Když už bylo něco hotové, chtěli jsme si ověřit, jestli to vůbec odpovídá realitě, protože i když se zdá, že je to stejné, nemusí to opravdu být tak. Museli jsme získat všechny logy, které jsou k dispozici ve skladu, a porovnat, jestli za stejných podmínek a stejnými produkčními algoritmy zvládneme odbavit stejné zakázky přibližně ve stejném čase a tak dále. Řekla bych, že jsme docela blízko. V simulaci všechno funguje trochu rychleji, ale už umíme srovnat data tak, že když vidíme například 10% zrychlení pickingu, tak víme, že díky tomu jsme opravdu až o 10% rychlejší.

Určitě. Implementovali jsme také takové hacky – například existuje pravděpodobnost, že dopravník chtěl, aby vše mezi jednotlivými pátrači ve skladu probíhalo jedinou cestou, tak jsme s byznysem odhadli, jak často se to stává. Přidali jsme k tomu různé statistiky a náhodné prvky (randomizaci), ale při ladění (debugování) tyto funkce musíme vypínat, abychom přesně chápali, co se děje. Práce na tom zabralo hodně času, téměř celý tým na tom v různých obdobích pracoval, a za to jsem docela hrdá. Je to opravdu projekt, který se může v budoucnu hodně využívat. A když se na to podíváme...

Přepracovala jsem text tak, aby byl gramaticky správný a lépe plynul, zároveň jsem zachovala původní význam. Pokud chceš dále zkrátit nebo upravit styl, dej vědět.

Jasně, tady je opravený a trochu uhlazený text:

Třeba zpětně, právě k vývoji toho simulačního prostředí, existuje něco, co bys našim posluchačům doporučila, pokud by se rozhodli něco podobného vytvořit pro lepší testování AI modelu? Je nějaká slepá ulička, když stavím digitální dvojče fyzického světa? Určitě není třeba implementovat úplně každý detail. Je důležité zjistit, kdo jsou hlavní uživatelé – třeba business manažeři nebo business analytici – a získat od nich informace o nejzásadnějších a nejdůležitějších věcech z celého procesu. Simulační prostředí totiž nemusí být přesná kopie reality, spíš to musí být zjednodušený pohled na svět.

Pokud neexistuje dokumentace, podle mě je vždycky lepší kouknout přímo do kódu než věřit jenom tomu, co vám někdo řekne, protože paměť není vždycky úplně přesná. Přímo se dívat do toho skladu je taky dobrá varianta. Stávalo se, že někdo z product managerů jezdil na sklad sbírat informace, protože sami nevěděli, jak něco funguje. Ale podle mě by podobné věci měly být ve firmách zaznamenané, protože když jakýkoliv byznys zlepšuje procesy – nemusí to být jen ML – musí tam být pořád aktivní business analýza.

Jak často musíte do simulačního prostředí zasahovat vzhledem k rychlému růstu Notina? Může se stát, že se změna provede, ale neprojeví se v kódu, nebo jak řešíte situace, kdy se něco změní? Nebo je prostředí už natolik robustní a zaměřené na digitalizovanou a důležitou část, že to víte hned? Zatím do toho nemusíme moc zasahovat, protože největší sklad v Rajhradě, který je v Čechách, se robotizuje nejpomaleji ze všech. Tam se změny, jako například nová auta, řeší až jako poslední. Zároveň se momentálně nacházíme v docela stabilní fázi.

I když místo člověka teď v některých skladech, například v Polsku, je robotický picker, algoritmicky je to stejné — jen se změní rychlost pickera z lidské na robotickou. Všechny větší změny opravdu mění paradigma. Randomizace zůstává podobná, ale časem se třeba objeví situace, kdy robot něco zastaví nebo jinak ovlivní proces. To je novinka, takže zatím nevíme, jak moc robustní roboti jsou. Držíme palce naší logistice s tímto.

Simulační prostředí jsme vyvinuli teprve minulý rok, takže zatím spíš řešíme jen nějaké případné nápady od logistiky, například co by se stalo, kdybychom konkrétní patro naskladnili jen určitým druhem zboží a jaký by to mělo vliv na logistiku. Pro nás to znamená, že během pár minut dokážeme udělat drobné změny, jako třeba jiný způsob skladnění, což pomáhá businessu ověřit různé scénáře.

Pokud chceš, můžu ti pomoci i s dalšími úpravami nebo rozdělením textu do menších částí.

Opravený text:

To je super nápad. Je skvělé, že vám to vlastně otevřelo cestu k tomu, že najednou přicházejí s takovými nápady na optimalizaci a vy můžete rychle ověřit, jestli na nich něco je. To je super. Pojďme se podívat dál – vy jste to testovali na simulačním prostředí, abyste měli větší jistotu, že to bude fungovat v praxi, že to bude mít nějaký dopad, že se to vyplatí a že nikde jinde to nezpůsobí nepořádek.

Čím se tedy zabýváte v jednotlivých projektech? Kdybychom se podívali na období poslední doby, říkala jsi, že jste stavěli na zelené louce, máte spoustu projektů. Na co jsi nejvíce hrdá? Co máte za sebou?

Jsem hrdá na každý projekt, protože každý měl své porodní bolesti, a to je prostě vždycky, když byznys není seznámen s tím, jak data science funguje. Řešili jsme například situace, kdy byznys přišel s otázkou: „Máme asi 10 pater, nebo 8 hlavních pater a 2 vedlejší speciální, kde chceme naskladnit zboží, a věříme, že ho můžeme rozdělit do určitých kategorií a nastavit tak, aby to fungovalo co nejlépe.“ Snažili jsme se produkty klastrovat, ale poměrně rychle jsme zjistili, že svět takhle nefunguje – klastrovat produktem nemůžeme, protože data nejsou klastrovatelná. Z lidského pohledu se produkty mohou zdát kategorizovatelné, ale otázka je, jak data uspořádat, aby produkty v zakázkách seděly – a to už je úplně jiná situace, obvykle je to spíš „hvězdný“ systém. Proto jsme úlohu přeformulovali – nemusí být klastrováním, ale jedná se o problém myšlení (mindset problem), který lze řešit evolučními algoritmy, genetikou nebo greedy algoritmy. Je to jiný úkol, než jaký byznys původně přinesl.

Často se stává, že na začátku byznys přijde s něčím, co se zpočátku zdá úplně jinak, než co to ve finále je. Vy jste s tímto taky museli počítat, že jo?

Ano, přesně tak.

Natýno, jak je specifický váš růst, velikost a úroveň automatizace skladů – jak moc jsi se musela doučit doménovou znalost? A jak moc jsou typické kategorizace produktů, například A, AA, A+, jak často používáte tyto frameworky, logistickou logiku, systematiku a know-how, tedy doménovou znalost? A jak moc je pro tebe vlastně ta úloha matematická a jak moc naopak záleží na tomhle „atavismu“?

Tyto frameworky často používáme spíš při zpracování nápadů nebo ověřování myšlenek, ale nepoužíváme je přímo na denní bázi. Spíš všechny věci kolem zboží a bezboží vyvozujeme z prodejních dat, která máme v datech. Nemusíme se držet přesně těch tradičních kategorizací, protože vždy máme svůj vlastní datový pohled. Logistika pro mě byla nový obor z hlediska terminologie a znalostí, ale myslím, že i přes její chaotičnost... (text končí).

Zde je opravený text s úpravami pro lepší srozumitelnost, gramatiku a stylistiku:

Zase prostě člověk to docela rychle pochopí, proč a jak to celé funguje. Určitě tam jsou nějaká specifika, vyloženě jak konkrétní sklad funguje, proč to máme právě takto a ne jinak. Ale když nás například logistika zavčas informuje o nějakých změnách, problémy nejsou. Fakt to nejsou věci, které by člověk, který přišel třeba ze seznamu webových věcí, nemohl zvládnout.

A jaké další věci u vás řeší byznys a logistika? Jedna z nich, jak jsem zmínila, je predikování, jak dlouho box vydrží na skladě. To je taková klasická regresní úloha. Řešili jsme také párování produktů – to nebylo přímo pro logistiku, ale pro vedlejší oddělení. Znamená to zjišťování, který produkt konkurenta odpovídá našemu produktu. Data od konkurenta i od nás jsou skrypovaná a my na základě textové podobnosti snažíme zjistit, zda je to ten samý produkt, nebo jiný. K tomu používáme různé modely, například BERTy.

Zkoušeli jsme také klastrování pro vytváření balíčků objednávek do picking boxu. To souvisí s tím, jak sklad funguje – skladníci pickují několik zakázek najednou, ale musí to dělat co nejoptimálněji z hlediska toho, kolik tras skladník projde, nebo kolik pater jednotlivé zakázky projdou, aby to netrvalo příliš dlouho. Je to tedy klasický úkol klastrování.

Takových věcí je spousta. Teď mluvíš o těch projektech – hodně z nich jsou úplně nové, nové funkce skladu. Jak moc zasahujete do vyšší úrovně? Třeba, jak jsi zmínila, do layoutu celého skladu nebo kam nasadit roboty a kam ne? To je na jiné úrovni, řeší se to jinými metodami a na vás to nespadá? Nebo jste ještě ve fázi, že ukazujete, že to funguje na dílčích projektech a na tyto věci si brousíte zuby, až budete mít 100% důvěru v každý váš model?

Například co se týče layoutu skladu, to je věc, o které nyní s logistikou diskutujeme. Jsou tam takové problémy s tím, jak rychle se všechno mění, a není vždy jasné, zda má smysl teď dělat výzkum, nebo až za dva roky, kdy se nasadí konkrétní robotizace. Protože když uděláš výzkum teď a budeš mít výsledky připravené, ve finále by byla nasazena jen částečně nebo krátkodobě.

To je otázka prioritizace, o které stále diskutujeme. Úloha layoutu na nás už chtěla spadnout, nicméně kvůli tomu, že Notino právě v roce 2025 zahajuje rozsáhlou robotizaci ve skladech, se to zatím odložilo. Musíme zjistit, jak ti roboti budou fungovat, co přesně to znamená a kde budou nejtěžší místa, která zůstanou.

Nicméně pro roboty teď například poskytujeme data a oni budou některé algoritmy od nás používat. Protože roboti jsou různí – někteří jen nahrazují skladníka při pickování, jiní sami rozhodují, jak sklad vybírat, ale přitom používají naše algoritmy, které odhadují například korelace mezi produkty, které se musejí… (text končí).

Jasně, tady je opravený text:

Pikovat na těch rychlých linkách a tak dále zůstává prostě místo lidí. A vy potřebujete říct, co je prioritou. Další projekt, který nás nejspíš čeká, bude právě pomoc robotům při naskladňování. Jeden z typů robotů totiž umí dobře pikovat i z existujících krabic, které jsou někde na skladě, ale my musíme teď nazbírat data o tom, jakým algoritmem ti roboti pikují, abychom jim mohli doporučit, nebo abychom mohli naskladnit správně vůči robotům.

Jak jsi mluvila o tom, jak probíhají sesypy, kdo to žije do těch krabic, to si potom asi dokáže zpracovat. To je jedna věc, která se bude i nadále používat, protože ti roboti umí sesypat, ale neví, co s čím. Tím pádem jim můžeme pomoct a říct, které boxy sesypat a které nesesypat. Algorithmicky to tedy zůstane hodně podobné, jen místo lidí to budou dělat nějaké automatizované ruce, nohy.

Je to hodně projektů, asi hodně POC, tedy v tomto případě, že se ty věci zkouší, validují a tak. Máte tam potom nějaké triggery, abyste se k tomu vraceli zpátky? Jde to do většího detailu?

U všech projektů, co nasazujeme, se snažíme mít hodně široký reporting. Náš Power BI tým, součást Data Office, pro nás vytváří reporty běžně v Power BI, ve kterých se snažíme pokrýt všechny metriky, co by business mohl zajímat, a také nějaké modelové metriky, například kvality a podobně. Snažíme se to v čase sledovat, i business to sleduje. Po nasazení bývá vždy období, kdy není jisté, jestli je to ideální, a tak pomocí těch reportů můžeme vždy obhájit, že business má přehled, ví, co se děje a podobně.

Občas si všimneme, že nějaký model začne neúplně degradovat – například se nepřeučuje nebo nějakým způsobem změní chování metrik. V tu chvíli se můžeme vždy podívat, co se děje, jestli nenastal nějaký jev. Například u fastpick modelů, které odhadují produkty na rychlou pickovací linku, jsme si všimli v jednom skladu, že v jednu chvíli byl značný pokles procentuálního odbavení zakázek na té lince. Bylo to divné, protože se nic zásadního nestalo.

Zjistili jsme, že jedna z robotizací kradla práci té lince, jenže nikdo to nechtěl spojit, a nebylo to proto, že by model nefungoval, ale prostě proto, že tam bylo méně práce – nějaký externí faktor. Díky tomu můžeme i validovat, jestli model nedegraduje. Například u jiného projektu s logistikou máme domluveno, že pokud kvalita spadne pod určitou mez po určitou dobu, tak se model přeučuje a aktualizuje.

Pokud chceš, můžu pomoci i s pokračováním té otázky ohledně Power BI reportu.

Opravený text:

Když jsi říkal ty projekty, tak tam prostě máme nasazený nový model do fastpicku. Takto funguje, toto jsou metriky, které sledujeme, a on je tam takto vidí. Co je pro něj vlastně výročko? Jo, je to v podstatě tak, jak říkáš, je to nějaká časová osa, ve které je vidět reálně odbavené zakázky na fastpicku, a také nějaké teoretické odbavené zakázky, kdyby se náš model používal naplno. Protože například my jim tam doporučujeme určité typy produktů, ale není vždy všechno naskladněné, něco může prostě dojít konkrétně na té lince, nebo z nějakého důvodu tam bylo méně lidí, že nestíhali to odbavovat. Tím pádem jsou tam i nějaké teoretické hodnoty. Zpětně můžeme použít nějaký orákulum, který by viděl přesně do budoucna, a to je spíš poznámka pro nás, protože na základě toho vidíme, jak se lišíme od nějakého možného maxima. Opět je to ale bohužel jen odhad, protože přesně to nenapočítáš, je to složitá úloha, musíme používat nějaké heuristiky. A takto to vidíš v čase. Snažíme se tam vždy mít nějaké filtrovací parametry, například zda se to týká obyčejných produktů nebo vzorku. U některých projektů může být to vyhodnocení opravdu složité a zajímavé, protože jsou to čisté časové řady, řekněme, ale některé hodnoty, které odhadujeme, nejsou přímo časové řady, nebo to neřešíme jako úlohu časových řad, ale i tak tam jsou nějaké jevy.

Můžeš dát příklad něčeho, co vypadá jako časová řada, ale ve skutečnosti to není časová řada? Asi to tak vypadá a zní to jako časová řada, ale je to časová řada, ne? Je to zajímavé. Například jeden z projektů, které jsme řešili, bylo odhadování objemu práce na skladě, což zahrnuje různé typy činností. To znamená, kolik bude expedičních balíků, kolik bude picku, kolik picku na rychlé lince, kolik pro všechny sklady, kolik různých typů balíků a tak dále. Kdybychom odhadovali objem zakázek v čase, tak je to určitě časová řada, ale tento konkrétní jev, nebo ty věci, co odhadujeme, jsou na sebe navzájem závislé. Například když se rozbije automatická balička, tak ta práce přejde na lidské baliče, a podobně. Jsou tam různé vedlejší jevy, které konkrétní věc ovlivňují, třeba zaškrtávání defaultního ekobalení na webu, ve Švýcarsku, pásy ve zepasti – přesně tak. I když tyto záležitosti neřešíme jako časovou řadu, stále děláme cross-validaci jako u časových řad na časových úsecích a podobně. Snažíme se to mít vyhodnocené i pro další období. Nutí nás to zohlednit výprodeje, sezónu, Black Friday, Vánoce, protože v čase fungování skladu se věci mění. A také to, jestli se zapínají i jiné algoritmy, například procesní algoritmy, které mohou ovlivnit výsledky. Tím pádem máte někde switcher: tento model je pro Black Friday a tento model pro zbytek roku, nebo je to už zabudované v modelu, který bere nějaký business switch jako vstup.

Aktuálně teprve docházíme k tomu, že budeme mít takové switchery, zatím všechny modely mají takovou funkcionalitu nativně v sobě, ale ne vždy to funguje perfektně. Ne vždycky jsou Vánoce, chápeš. Musíme se prostě o to starat, my to vyvíjíme... (text pokračuje)

Jistě, tady je opravený text s drobnými úpravami pro lepší srozumitelnost a plynulost:

Jdeme postupně. Jak jsem říkala, teď jsme ve fázi, kdy skoro všude máme spíš ty pseudoverze, prostě první verze modelů, které pokrývají problém, řeší ho lépe než dříve, nebo aspoň stejně dobře, a alespoň měřitelně. A teď jsme ve fázi, že jdeme na druhá kola, aby to všechno bylo ještě chytřejší.

Takže vás čeká zlepšování všeho?
Všeho. Všeho možného. Robotizace na jedné straně a na druhé straně si budete vracet do svého kódu a zlepšovat se. Ptát se Clouda, jak to ještě lépe vylepšit. To nás čeká všechny – ptát se Clouda a dalších nástrojů.

Když měníš toho Clouda, jak na vás narazila vlna generativní AI? Jak změnila vaši práci? Nasazujete někde LLM?
Většina našich úloh jsou spíš matematické. Týká se to spíše jednodušších, lehkých ML modelů. U LLM zatím nevím, jak to bude v budoucnu, moc prostoru není, kromě možná teologie, co jsem zmínila při párování produktu. Ale většina z nás teď používá LLM prostě jako osobního asistenta. V ID-čku mají někteří kolegové zapnutého jistého nejmenovaného asistenta a podobně.

Dobře, tak nejmenovaného asistenta necháme nejmenovaným, abychom ho nechali v anonymitě.

Je někdo nebo něco, co bys ještě chtěla jmenovat?
Já bych asi chtěla moc poděkovat svým kolegům, protože si myslím, že v data office odvádíme velkou práci tím, že fakticky stavíme ten data-driven přístup. Takže děkuju svým kolegům, a vám taky, že jste mě pozvali. Bylo to zajímavé.

My děkujeme tobě a těšíme se, až tě znova uvidíme, buď tady ve studiu, anebo na nějakém tvém koncertu.
Díky.

Děkujeme, že jste doposlouchali až sem. A díky taky našim partnerům a členům Data Talk klubu. Těmi jsou:
Index, Saska, By Street, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Carl Data Company, Data Mind, Notino a A Flow.

A pokud chcete zůstat v obraze ohledně české datové scény a globálních datových technologií, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data.

Pokud chceš, mohu provést ještě další stylistické úpravy nebo zkrácení.