Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datatalk. Dnes tady mám dva vzácné hosty: Tomáše Kumheru, IT vedoucího firmy Tým Obaly. Ahoj Tomáši.
Ahoj.
A Jirku Polcara, cofoundera a CTO Gauss Algorithmics. Ahoj.

Dnes se podíváme na AI ve výrobě, konkrétně na spolupráci Gauss Algorithmics s Týmem Obaly při zavádění AI do této výrobní firmy.

Na začátek bych chtěl, abyste se posluchačům představili. Začnu tebou, Jirko. Můžeš nám říct svoji cestu a představit Gauss?

Jsem Jirka Polcar, původně jsem studoval fyziku na Přírodovědecké fakultě Univerzity Karlovy. Nějakou dobu jsem se věnoval astronomii a pracoval jsem na Astronomickém ústavu Akademie věd. Potom jsem ale fyziku opustil.

Hvězdy tě přestaly zajímat?

Mělo to mnoho praktických důvodů, ale nakonec jsem rád. Asi pět let jsem pracoval v telecom průmyslu, ve firmě Logica, dnes Mavenir, kde jsem se podílel na vývoji SMS centra pro mobilní operátory. Potom jsem dva roky pracoval ve společnosti Seznam, kde jsem se věnoval fulltextovému vyhledávání. Od roku 2013 jsem u zrodu Gauss Algorithmics, kde stále působím. Začínali jsme jako malá firmička se dvěma lidmi, dnes nás je lehce přes 20 – máme mix data scientistů, devops inženýrů, vývojářů i obchodní tým. Tak vznikl Gauss Algorithmics.

A co ty, Tomáši? Jaká byla tvoje cesta do Týmu Obaly?

Ještě jednou, já jsem se k IT dostal už na střední škole. Studoval jsem obor Digitální technologie na Střední průmyslové škole v Panské ulici v Praze. Pak jsem pokračoval na Univerzitě Hradec Králové, kde jsem studoval aplikovanou informatiku. Během studia jsem získal první zkušenosti ve výrobní firmě, kde jsem chvíli pracoval jako klasický IT technik. V jednu chvíli se pak firma rozhodla vyměnit ERP systém a nabídli mi, jestli bych se o to nechtěl postarat. Já jsem, i přestože jsem neměl velké zkušenosti, kývl a během roku jsme implementovali kompletní ERP systém do celé firmy.

Podobně začala moje zkušenost i v druhé výrobní firmě, tedy v Týmu Obaly. V roce 2017 jsem tam začínal opět s implementací informačního systému. Už je to osm let a posledních pět let tam mám na starosti IT oddělení.

Díky moc za představení. Možná, Tomáši, se teď budeme bavit o Týmu Obaly a vaší spolupráci. Pověz nám něco o firmě – co to je zač, jak je velká a jak ji můžeme znát?

Tým Obaly patří do rodinné skupiny, firma je stále ve vlastnictví rodiny pana Týma. Náš závod se nachází ve Všetatech, severně od Prahy. Máme zhruba 400 zaměstnanců a obrat kolem 1,7 miliardy korun. Mezi naše zákazníky patří například Procter & Gamble, IKEA, Staropramen a Budvar.

A co vlastně znamenají „obaly“? Když říkáš Procter & Gamble, Budvar, IKEA, tak mám asi nějaké vaše obaly doma, že?

Určitě, určitě. Vyrábíme v podstatě cokoli z kartonu. Naší vstupní surovinou je papír a spotřebujeme ho zhruba 500 000 tun ročně.

500 000 tun ročně?

Ano, 500 000 tun ročně...

[Pokračování textu zde končí.]

Zde je opravený text:

Vyrobí zhruba 135 milionů metrů čtverečních kartonu ročně. Takže náš obal z kartonu jste si určitě drželi v ruce. Super. A asi každý z našich posluchačů. Tak děkuju. Už máme tedy nastavený kontext — tým obaly a každý z nás měl kartony v ruce. Pojďme se teď podívat do vašeho příběhu. Tomáši, kdy jsi vlastně poprvé slyšel o Gauss Algorithmics? Jak začala ta spolupráce? Přišel jsi s poptávkou na ně? Chodil jsi po trhu? Nebo jak to bylo?

Nebylo to tak. Byla to spíše náhoda. Jeden čas jsme se snažili zkrátit proces nabízení zákazníkům, respektive odhadnout, kolik náš produkt bude stát. Měli jsme poměrně zdlouhavý proces, kdy bylo potřeba produkt ocenit zadáním velkého množství informací do našeho ERP systému, a na to bylo potřeba několik lidí z oddělení vývoje, zadávání dat, obchodníků. Když jsme s vedením přemýšleli, jak ten proces zkrátit, pan jednatel položil na stůl krabičku od džusu a řekl: „To je jednoduché – tady je jeden rozměr, druhý rozměr, šáhnu na to, takováhle kvalita, gramáž, a prakticky velmi rychle odhadnu cenu.“ To mě přivedlo k myšlence, že všechny tyto informace už v systému máme.

Systém je podle pana ředitele klíčový. Ano, a já měl štěstí, že jsem na to narazil na jedné přednášce pořádané Německou obchodní komorou. Přednášel tam Johnny z Gauss Algorithmics a řešil velmi podobný problém. Vyprávěl případovou studii, která byla velmi podobná tomu, čeho jsme chtěli dosáhnout. Po přednášce jsme si vyměnili telefonní číslo a e-mail a už jsme společně diskutovali o našich datech.

Jirko, když za vámi takhle přijde klient, ještě k tomu výrobní firma, takže asi ne úplně digital native, jak zpravidla začíná celá spolupráce? Jsou první krokem konzultace a rozmluva, nebo je to hned jasné a rovnou kopete do projektu? Co se vám osvědčilo za těch 12 let?

Klíčová jsou samozřejmě data. Naši zákazníci si většinou myslí, že mají data perfektně uspořádaná – z jejich pohledu to často platí. Ale jakmile začnou data používat jinak, než byla původně navržena, objevují se problémy. Další problém pramení z doménové neznalosti – výrobní firma, v tomto případě Team, má spoustu vnitřních označení, například kvalitu papíru, tloušťku, formát krabic a podobně. Tyto informace jsou v datech reprezentovány způsobem, kterému rozumí oni, ale my ne. Proto je první fáze oťukávací, „ošahávací“. V tomto případě jsme měli možnost firmu navštívit, podívat se na materiály, projít si celý proces. Pro nás je to vždy zážitek, protože obvykle sedíme jen před monitorem, takže to je vždy velká příležitost.

Po několika videokonferencích a analýze tabulek máme čas data vstřebat a začít je zpracovávat s cílem vyvinout první verzi modelu. Pravda je, že jsme měli nahromaděnou velkou sp...

Pokud chcete, mohu pokračovat s opravou či úpravou zbytku textu.

Opravený text:

Máme spoustu dat, protože v týmu jsou stroje do RP systému přímo připojené už velkou řadu let.

Z každého stroje vyčítáme vlastně tři signály, což je až fascinující, co všechno z nich lze spočítat. Nám stačí vědět, jestli stroj jede, nejede, počítá kusy na vstupu a máme signál o tom, jak se změnila zakázka. Pokud jsou tyto tři signály podložené dalšími daty, která jsou uložená v tom RP systému, je možné dopočítat rychlosti, produktivitu, odpady atd. Stačí k tomu potom na konci přidat finance a jsme schopni si spočítat, kolik nás reálně ta výroba stála.

Takže vlastně to, co říkáš, je, že jste měli dat dost, že výroba je do značné míry digitalizovaná a že u těch výrobků, které už opravdu vyrábíte, náklady znáte velmi přesně. Ta predikce nějakého úplně nového produktu byl ten „news case“, který jste řešili. Díky tomu umíme velmi dobře měřit, co nás to stálo. To znamená, že dat z výroby jsme měli nazbíranou velkou spoustu, nicméně pořád jsme měli dlouhý proces počítání nákladů na výrobu.

Dokonce jsme měli spočítáno, že pouze 8 % všech kalkulací, které provedeme pro zákazníka, se potom reálně dostane do výroby. Chápu to správně, že já jsem konkurence IKEA, pošlu vám rozměry nábytku a chci vědět, kolik to bude stát, když mi budete dělat obaly na příští dva roky? Ano, je to tak.

A jak dlouho tento projekt předtím trval? Záleží na tom, pokud jste třeba IKEA, tak nechcete jeden produkt, ale chcete jich 50 v různých mutacích, rozměrech, konstrukcích a potiscích. Tím samozřejmě roste náročnost. Takže to odhadování ceny nebo výpočet nákladů mohl trvat den, dva, tři a zaměstnávalo to tři oddělení. A jenom 8 % se nakonec skutečně koupilo a šlo do výroby. Velký zbytečný čas lidí.

Možná se rovnou zeptám: těch 8 % je dáno trhem, že poptají více variant a je to klasická konverze, nebo se to dá změnit na vaší straně, třeba že když budete kreativnější tvorbou, bude to 15 %? Samozřejmě zákazníkovi chcete nabídnout co nejvíc možností, takže z toho plyne, že nabídek a variant produktů by mělo být co nejvíc. Asi proto je to číslo tak nízké.

Potkali jste se na kolech, povídáte si, Jirka začíná chápat, jak funguje výroba z papíru, doma zkoumá kartony z e-shopu. Kdy vzniká první řádek kódu? Po jaké době, jak dlouho se musíte bavit, abyste začali programovat?

V podstatě hned, jakmile jsme dostali dump asi pěti tabulek z databáze, začali jsme data zpracovávat, orientovat se v nich a naším úkolem bylo spočítat nebo odhadnout výrobní cenu. Jak jsem říkal, tabulek bylo několik. Pro strojové učení potřebujeme celou zakázku reprezentovat nějakým vektorem a celý proces je o tom, jak data správně připravit, aby tento vektor mohl vstoupit do modelu.

Těch zakázek, které… (text končí)

Opravený text:

To, co jsme měli k dispozici, bylo v řádu desítek tisíc, třicet, čtyřicet. Samozřejmě to způsobovalo spoustu problémů.

Ty nejzásadnější spočívaly v tom, že cena, kterou jsme predikovali, nebyla v systému úplně jasně zřejmá. Cen bylo mnoho – postupně, jak se výrobek vyrábí, se cena kumulovala a přibývaly tam i položky, které s výrobou přímo nesouvisely, například různé dodatečné materiály a podobně. Některé ceny byly uvedeny v jiných měnách, což nás zmatlo a nebylo jasné, co která cena obsahuje.

To vedlo k tomu, že model na začátku nedosahoval takové přesnosti, jakou jsme očekávali. Pamatuji si, že jsme si z datového setu dokonce vytvářeli například nové technologie, protože jsme byli instruováni, že pro strojové učení je potřeba relativně hodně dat. U některých nových technologií nebo nových forem byznysu jsme však ještě neměli dostatečné množství nasbíraných dat, takže jsme tyto části dat čistili a vyřazovali.

Zároveň jsme ořezávali extrémy, jako například situaci, kdy někdo nechal zapnutý stroj přes víkend, což znamenalo, že zakázka byla výrazně podražená nebo naopak zlevněná. Všechny tyto kroky jsme museli použít, abychom z celkového množství dat vyextrahovali kvalitní a relevantní vzorek.

Pokud náhodou poslouchá někdo, kdo je v Tomášově kůži a pracuje s výrobními daty, zajímá vás, jestli jsou nějaké „lessons learned“, tedy co vždy nechat v datech, co naopak vynechat, nebo jestli je to vždy závislé na konkrétním případu? Nebo jestli je opravdu těžké něco doporučit, dokud se data nedostanou do modelu?

Podle mě je to spíš to druhé, tedy že je to silně závislé na konkrétním případu. Na celém procesu je totiž nejtěžší to, že každá firma používá data jiným způsobem a má je vyladěné pro svůj vlastní use case, zatímco my potřebujeme něco trošku jiného. Buď to z dat jde nějakou kombinací atributů získat, anebo se někdy musí do systému přidat další datové zdroje či integrace jiných systémů. U nás to nebyl ten případ, ale je to běžný scénář.

Pozitivní bylo, že data byla na jednom místě, nezasahovaly tam žádné legacy systémy. Největší problém jsme měli s tím získat skutečně „čistá“ data, která vystihují skutečnou výrobu. Pro zjištění celkových nákladů je samozřejmě potřeba mít přehled o všem, ale pro predikci jsme potřebovali čistě výrobní data. Tento proces a zpřesňování modelu probíhalo v několika iteracích, jakmile jsme se postupně dostávali ke správným datům.

Další komplikací bylo, že ceny se samozřejmě mění. Tibnám nám vždycky dodával cenové mapy různých papírů, lepidel, pásků a dalších materiálů používaných ve výrobě pro konkrétní časová období. Tyto data jsme museli správně spojit se zakázkami tak, aby tvořily vstup do modelu. Model tak dokázal pracovat i s měnícími se cenovými mapami.

Toto byl pro nás důležitý krok: museli jsme oddělit tu část nákladů, kterou jsme chtěli predikovat, od části, kterou...

Pokud potřebujete, mohu vám pomoci text doplnit nebo upravit dále.

Zde je opravený a upravený text, aby byl gramaticky správný, plynulý a srozumitelný:

Nechtěli jsme, aby byla součástí predikce cen papírů jejich vývoj v průběhu měsíců, protože takový vývoj nechceme predikovat. Nechceme predikovat cenu energií. To znamená, že jsme tuto část dat museli oddělit z datového setu a dodat ji potom zvlášť – přemostit ji jako vstup. Stejně tak bylo pro nás důležité nemíchat hodnoty, které jsou na výstupu, s hodnotami na vstupu.

Zjistili jsme totiž, že pokud to uděláme, model se učí sám od sebe a zkresluje výsledky.

Mně to trochu připadá, že projekt začíná nabývat rozsahu. Možná se ještě vrátím na začátek – když dostanete první dávku dat, třeba pět tabulek, co s nimi děláte? Hodíte je do notebooku, pustíte na ně nejčastější knihovny pro daný use case, použijete nějaké své staré modely, které máte z jiných výrobních firem, nebo tak nějak hands-on přistupujete? Jirko, co děláte vy, když dostanete CSVčka?

Používáme Python jak pro data science, tak v engineeringu. Na zpracování dat používáme framework Kedro. To je framework, který umožňuje definovat pipeline – každý uzel pipeline má vstupy i výstupy. Kedro umí vizualizovat a mapovat pipeline, pracovat se závislostmi, optimalizovat zpracování a paralelizovat, co je možné. Data tak postupně prochází pipeline, kde se čistí, normalizují a předzpracovávají, aby mohla správně vstoupit do modelu. Například některé hodnoty, jako jsou typy krabic, jsou v datech zakódované, a je potřeba je rozluštit a rozložit, aby model rozuměl jejich významu. Také se dopočítávají některé featury, například plochy na základě rozměrů.

Takže vektor pro každou zakázku postupně v pipeline prochází a obohacuje se. Hned na začátku tedy data vložíme do pipeline – tzv. pipeline first přístup. Toto děláme vždy a v podstatě tento proces zůstává během celého vývoje projektu. Pokud to není nutné kvůli výkonu, tuto pipeline používáme i v produkci. Samozřejmě pipeline má určitý overhead, probíhá tam spousta věcí navíc, které nejsou vždy potřeba při reálném výpočtu, takže pokud je potřeba optimalizovat výkon, zkusíme to. Ale pokud to není nutné, pracujeme stále s Kedrem.

Předpokládám, že zde nebylo nutné řešit near real time, protože předtím to trvalo dny, takže cokoli v nižším řádu – což je ve stovkách milisekund – je dobré. Myslel jsem, že kdyby opravdu záleželo na rychlosti odezvy celé pipeline, pak by samozřejmě i jednotlivé části musely být rychlé.

Aha. Jaký byl váš první model, co jste pustili na takto vyčištěná a lehce normalizovaná data? Co bylo zadání – vždycky chtěli, abychom dobře odhadli náklady a tím i cenu pro zákazníka. Tak co jste na to nasadili jako první?

Pokud chcete, můžu pokračovat ve stylu a tónu i do další části rozhovoru.

Opravený text:

O tolik neuronových sítí, nějakou základní konfiguraci, co jsme zvyklí používat. Používáme TPOT framework, což je takový obecný genetický algoritmus, který sám umí kombinovat několik modelů dohromady. Ten většinou nefunguje moc dobře, ale je to takový první pokus, který vždycky prostě vyzkoušíme. V tomto případě jsme zkoušeli několik neuronových sítí a nakonec jsme skončili u rozhodovacích stromů. Měly velmi podobné výsledky jako ty neuronky, ale jsou mnohem rychlejší a levnější. Takže to nakonec skončilo v produkční verzi. Jak jsi to vnímal ty, Tomáši? Co pro tebe bylo zajímavé? Sám jsi říkal, že to byla tvoje první zkušenost.

A v produkci, v tom B, se často říká, nebo je to takzvaně by design, že u data science projektů je nějakou dobu nejistota – dlouho se řeší, jestli to vůbec má smysl, a až potom se ukáže, jak to bude. Jak jsi k tomu přistupoval ty? Co ti dávalo jistotu, že vydržíš? Jak jsi to vnímal, když u softwaru je time to delivery a agilita mnohem větší, už vidíš nějaké MVP a podobně?

To tak, jak říkáš. My jsme s určitou nedůvěrou vstupovali do projektu, což znamená, že ještě než jsme vůbec začali uvažovat o tom, jak to bude vypadat pro uživatele, chtěli jsme vidět, jaký bude výsledek. Začali jsme někdy v druhé polovině roku 2023 a první výstupy, které jsme dostali, měly asi 10% rozpětí a úspěšnost kolem 47 %. Postupným iterativním procesem, jak jsme data čistili, vylepšovali a vysvětlovali si je, jsme se na konci roku 2023 pohybovali kolem 50 % úspěšnosti. Další iterace se držely kolem 40–50 %, a pak najednou během velmi krátké chvíle, konkrétně v březnu 2024, jsme dosáhli 96 % úspěšnosti. Tak jak říkáš, najednou přišel ten skok. Pro mě osobně to bylo znamení, že tohle je projekt, který musíme dotáhnout do konce, protože úspěšnost najednou byla fantastická.

Tak zpátky na tebe, Jirko: když iterativním procesem taháš každý procentický bod nahoru a pak najednou skočíš o 40 %, co se stalo mezi lednem a březnem 2024?

Vzali jsme správný sloupec s reálnou cenou – takto bych to zjednodušil, ale nicméně model zůstal stejný, všechno ostatní je jinak.

Přesně tak, bylo tam velké množství vstupních dat. Mluvíme o stovkách sloupců a bylo tam spousta možností, jak to udělat. Chvíli nám trvalo, než jsme našli správnou kombinaci.

Ten proces, kdy se používá model na odhad něčeho, v lidech vyvolává nedůvěru, protože nevěří věštění budoucnosti. Hlavně dosavadní proces, na který byli zvyklí, vede k tomu, že vidí jen dílčí výsledky. Ví, kolik je stálo energie na tomto či onom stroji, a těžko si představují, že nemáme tyto dílčí informace, ale přesto dokážeme říct výsledek na konci, který je vlastně jen součtem. Často jsme v diskuzi, kde nám říkají, že když bych chtěl předpovídat ty dílčí informace...

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

Zde je opravený text s úpravami gramatiky, interpunkce a stylistiky:

Máme vlastně N modelů nezávisle trénovaných, každý s určitou chybou, která se pak při součtu chyb propaguje do výsledku. A to, co je na strojovém učení úžasné, je právě schopnost zobecnění. Model se naučí ze statisíců příkladů poznávat správné řešení – to je to kouzlo. Nepotřebujeme znát mezivýsledky. Stejně jako váš šéf, který se jen podívá na krabici na stole a řekne cenu, tak i model funguje. Jenže šéf se tím zabývá třeba 30 let, zatímco model vidí historii všech zakázek a má k dispozici obrovské množství příkladů pro trénink. Díky tomu může šéfovi skutečně konkurovat, i když konkrétní krabici v životě neviděl. Máte ještě nějakou radu, nebo jak postupujete?

Abychom našli ten správný sloupeček, věřím, že když něco spustím a vidím, že výsledek je mimo, hledám lepší feature nebo lepší neuronovou síť. Možností je nekonečně mnoho. Jak jsi říkal – genetický algoritmus – spouštíte paralelně mnoho variant a necháte je "bojovat" mezi sebou? Nebo je to fakt jinak?

Ne, tady bychom touto metodou nedospěli dál – kombinací je totiž obrovské množství. Kromě predikce ceny nás v týmu také požádali, abychom našli podobné zakázky. Klienti to často vyžadují, protože mají problém uvěřit výsledku modelu. Když ale vidí, že z desítek tisíc zakázek najdeme tucet velmi podobných a ceny se jim přibližují, více tomu věří. To je vlastně ta vysvětlitelnost, o které jsem mluvil. Pro nás to byl další úkol – vytvořit komponentu, která řeší podobnost zakázek. Ta úloha je podobně náročná jako primární model. Hodně jsme potřebovali poradit, protože když jsme definovali metriku, která měří podobnost dvou zakázek, museli jsme se naučit vážit jednotlivé vstupní hodnoty, kterých je zhruba 10 až 12. Po několika iteracích jsme dospěli k rozumné metrice.

Když model odhadl cenu a našli jsme pět podobných zakázek, ale s rozdílnou cenou, vznikl problém. Řešíme to na velkém množství dat, díky čemuž jsme snadno identifikovali, pro jaké vstupní parametry model dává špatné výsledky. Například když existují velmi podobné zakázky s výrazně odlišnou cenou. To nám hodně pomáhalo v iteracích, protože jsme se soustředili na problémové případy a viděli jsme, kde to nefungovalo. Jednoduchý příklad: odchylky byly velké u zakázek, které byly dlouhodobé...

Pokud chceš, můžu pomoci i s další částí textu nebo udělat úpravy dle konkrétních požadavků.

Jistě, tady je opravený a stylisticky upravený text:

a skladu. Tudíž jsme zjistili, že jsme tam započítali cenu skladu. A tak jsme se postupně probírali těmi nejproblematičtějšími položkami, až nakonec zmizely. Co se týče tvé strany, znamenalo tohle celé něco? Tahle fáze projektu byla velmi důležitá i pro nás. A přestože jsme si mysleli, že dobře víme, co tvoří náklady na výrobu, protože během procesu jsme nemohli získat mezivýpočty, o kterých jsme mluvili, začali jsme se zabývat tím, jak jednotlivé vstupy ovlivňují konečnou cenu.

Došli jsme k zjištění, že jsme byli přesvědčeni, že konstrukce obalu, tedy krabice, je klíčovým faktorem nákladů na výrobu. Analýzy však ukázaly, že konstrukce je důležitá, ale ne tak zásadní, jak jsme si mysleli. Mnohem klíčovějším parametrem je například spotřeba materiálu. Tato fáze byla tedy velmi důležitá i pro nás a analýza dat nám přinesla spoustu poznatků.

To je skvělé, protože jinak to musí být nepříjemná situace – pořád vysvětlovat, neustále odpovídat na otázky a komunikovat, zatímco model dosahuje jen 54 % přesnosti. Ve chvíli, kdy se objeví taková pozitivní externalita, že se zároveň dozvídáte něco nového o svých datech a byznysu a dochází k aha momentům, je to super. Znamená to, že projekt má už sám o sobě nějakou hodnotu, i když by se ukázalo, že nasazení modelu by typicky nedávalo smysl.

To mě přivádí k další otázce. V jaké fázi byste „hodili flintu do žita“? Nebo jak zjistíte, že daný use case není vhodný, nebo že sice je, ale v daném rozsahu není výnosný? To bývá běžná praxe u data science projektů, zvlášť ve velkých firmách. Když už spolupracujete s experty, konzultanty a firmou Gauss, předpokládám, že to riziko vidíte, ale snažíte se ho co nejrychleji minimalizovat, aby klient nepálil peníze.

My máme na to trochu jiný pohled. Když jsme zjistili, že v týmu stačí plus minus 10 % přesnost a že řeší 90 % zakázek a mají k dispozici 30 tisíc střicích dat, hned nám bylo jasné, že jde o řešitelný problém. Mohlo by se zdát, že bychom to nedokázali přesvědčivě vysvětlit, ale protože jsme podobné věci už viděli, neměli jsme pochybnosti.

Když nám však první verze vyšla na 54 %, bylo jasné, že problém je řešitelný, ale na začátku to vypadalo velmi špatně. Ten první výsledek je těžké prezentovat – neznáme se s klientem a je to náročná situace. Máte na to nějaký trik nebo radu? Například hodně komunikovat od začátku a zdůrazňovat, že ten první výsledek ještě nic neznamená?

Přesně tak. Snažíme se být maximálně transparentní. V týdenních schůzkách prezentujeme, co jsme udělali, a sdílíme notebooky s klientem. Někdy je na druhé straně někdo, kdo má buď zájem, nebo už zkušenosti, takže ho do toho dokážeme zapojit, aby to lépe chápal. Přesto je konečné číslo na začátku nízké a vypadá špatně.

Nepochybovali jsme, ale bylo potřeba ten výsledek nějak prodat, aby projekt mohl pokračovat. Naštěstí se situace během chvíle začala...

Pokud chceš, mohu upravit text ještě víc, nebo zkrátit, aby byl srozumitelnější.

Opravený text:

O zlepšování. A tím, že jsme vlastně dodávali ty problémové data, tak na druhé straně se tím někdo zabýval, viděl, že to je stejné, ale my tady máme ceny prostě takové. Vždycky to chvíli trvalo, než jsme dostali odpověď, ale ta byla vždycky taková: ano, to souvisí s tím. A toto nikdo nevyřeší za vás, ani žádný genetický algoritmus, prostě to je kombinace doménových znalostí a dat. Toto je taková kritická fáze projektu, proto se i my snažíme dělat nabídky takové, aby klient měl možnost kdykoliv z této fáze vystoupit, pokud se v tom necítí komfortně. Ale cílíme to na transparentnost a komunikaci, a to je ještě jediná zbraň.

No, než půjdeme do další fáze, Tomáši, jak jsi to vnímal během té doby? Už jsi začínal být nervózní, nebo jsi byl připraven, očekávání byla nastavená a věděl jsi, že to třeba přijde příští měsíc?

Já jsem věděl, že v těch datech to je, když to dokáže nějaký algoritmus spočítat, tak jsem to tak rychle nevzdával. A v té fázi vysvětlování jsem kolem sebe měl naše odborníky z vývoje, z kontrolingu a také z mého týmu databázových specialistů, takže jsem věděl, že to dohromady zvládneme. Nenastala vůbec fáze, kdy bych si říkal, že 50 % je málo, protože jsem přesvědčený, že to půjde nahoru. Nevzdávali jsme to.

No a když se vrátím zpátky do března 2024, tak hurá, v Gausu našli správný sloupec, což zní jako sranda, ale najednou model dosahoval výkonu 96 %, což je úžasné číslo. Co se pak dělo? Tak práce hotová, jdeme domů?

Ne, tady to u nás běží, můžete si zavolat API a zase někde uvidíte? Ne, my jsme v té chvíli věděli, že to bude fungovat, ale potřebovali jsme ten výsledek dostat k uživateli v nějaké podoby, která bude vzhledná. A kdo je uživatel? Nějaký obchodník, dostávající poptávku? Uživatel je v tu chvíli obchodník, ano. Začali jsme se tedy bavit o tom, jak bude vypadat výstup, protože zatím jsme měli statistiky a výsledky v Excelu, a Kaus nám postavil jednoduchou aplikaci, ve které jsme si mohli vyzkoušet, jak to přibližně bude fungovat. Ale bylo potřeba posunout se dál, začít tvořit robustní aplikaci, která bude pro uživatele co nejsnadnější, nejpřehlednější a aby jí co nejvíce věřil. To znamená zahrnout právě procento pravděpodobnosti odhadu, ukázat uživateli seznam nejpodobnějších zakázek nebo produktů spolu s informací, jak moc je produkt podobný něčemu, co už jsme vyráběli, v procentech, jaké to tehdy mělo náklady a také základní vlastnosti produktu.

Zadání bylo vlastně jednoduché. Uživatel dnes zadává ABC rozměr, katalogové číslo konstrukce produktu, formu potisku, pokud nějaká je, a kvalitu papíru ze sortimentu, ze kterého je krabice vyrobená. A jak už zmínil Miška, ve vteřinách nebo řádech milisekund – pro nás je to v reálném čase – uživatel získává odhad nákladů.

Takže já zadám tyto parametry, které mám z nějaké...

Zde je opravený a stylisticky upravený text:

Poptávkový formulář – prostě buď nějaký formulář, nebo mě někdo zatelefonuje a hned se mě ptá, kolik to asi tak bude stát, za kolik to vyrobíme. „Za kolik to vyrobíte?“ „Aha, dobře.“ Takže náklady – podobná zakázka z minulosti, nebo třeba pět podobných zakázek z minulosti. A jak moc je tahle zakázka těm předchozím podobná? Jo, zkrátka jak moc je ten produkt podobný tomu vstupu, který zadal zákazník, plus procento pravděpodobnosti toho odhadu.

Myslím, že to tu ještě nezaznělo, ale důležité je říct, že poslední verze modelu byla přesná na 96 %. Co se mi na tom ale moc líbilo a co je opravdu fantastické, je to, že u zbylých 4 % jsme měli informaci, že odhad není správný. To znamená, že uživatel pokaždé ví, jestli je odhad správný nebo ne. Může se stát, že zadá parametry krabice, která je atypická, kterou jsme buď vyráběli jen v malém množství, nebo ji nikdy nevyráběli. V tu chvíli může pravděpodobnost přesnosti odhadu klesnout a uživatel se musí zamyslet, jestli použije jinou metodu výpočtu, nebo jestli odhad přijme, ale s vědomím, že jde o „nějaký atyp“.

Takže to, co říkal Tomáš, jak si můžeme být tak jistí, že náš model je spolehlivý? To byl pro nás také výzkumný úkol – jak toto vyjádřit. A jak jsem popisoval už dříve, jak strojové učení funguje – snaží se nějak zobecňovat – vstupní vektor tvoří jakýsi mnohorozměrný prostorový bod. Konfidence říká, že když je nový vstupní bod (tedy ta zakázka, se kterou právě pracujeme) blízko ostatním bodům, které známe z tréninku, tak model je jistý. Když ale vstup začíná „ujíždět“ v nějaké dimenzi do oblasti, kterou nezná, ztrácíme jistotu. Toto se vyjádří číslem.

My to interpretujeme jako procento. Ve skutečnosti to není přesné procento, ale přibližuje se tomu a lidé tomu rozumí. Čísla, která nám model vrací, dávají smysl.

Dobře, super. Zůstaňme u té krabičky a modelu, ať to projdeme. Takže tam běží víc modelů současně, nebo jeden model počítá podobnost, cenu, náklady a konfidence?

V podstatě tam jsou tři nezávislé modely: jeden počítá cenu, druhý podobnost a třetí konfidence. A všechny jsou to rozhodovací stromy, že?

Ne, rozhodovací stromy jsou jenom u ceny. Podobnost je metrika, o které jsem mluvil dříve, a konfidence kombinuje ty dvě předchozí hodnoty dohromady. To už je spíše algoritmická záležitost než model – kombinuje ty dvě hodnoty do výsledného čísla, které se dá interpretovat jako procento.

Super, to je z hlediska modelu. Teď jste měli nějakou základní aplikaci, kterou už dávate uživatelům. Jak jste říkal, je to hrozně jednoduché, ne? Mám tři čísla, ukážu jim tři čísla a hotovo. Většinou ale obchodníkovi nestačí jen tři čísla, aby mohl začít nabízet. To znamená, kromě těchto tří hodnot, které jsme teď zmínili, …

Pokud chcete, mohu text dále upravit nebo rozšířit.

Samozřejmě, obchodník a uživatel potřebují spoustu dalších výstupů, které jsme již dokázali řešit tak, že jsme poskytli různé vzorce, výpočty a algoritmy. Například pro zjištění, kolik krabic se vejde na paletu, nebo kolik bude stát doprava v případě, že ke zákazníkovi skladujeme určité množství zboží. Na první pohled se to nezdá, ale těchto výpočtů bylo nakonec relativně dost.

To znamená, že poté, co jsme ověřili, že model funguje, nastala ještě spousta práce s definováním těchto výpočtů a hodnot, které obchodník potřebuje, aby měl ucelenou nabídku. Chtěli jsme, aby pro uživatele bylo pohodlné se k nabídce kdykoli vrátit, například kvůli opětovnému výpočtu těchto hodnot. Samozřejmě nechceme, aby si uživatelé dělali print screeny a ukládali je jako obrázky, ale potřebovali jsme nějakou zprávu přímo v aplikaci, aby si mohli ukládat výsledky, vytisknout dokument nebo nabídku pro zákazníka a správně s nimi pracovat.

Naši obchodníci obvykle pracují v týmech, takže jsou v aplikaci pod svým loginem, jsou přiděleni ke svému týmu a v rámci týmu vidí nabídky navzájem. Kolem tohoto nástroje tak ještě vzniklo hodně další práce tohoto typu.

Jak často je tato práce na vás, na GAUSY? Celou tuto aplikaci jsme vyvíjeli my, takže práce bylo docela dost, ale jedná se už o standardní vývoj, který asi všichni znají – jasné zadání, UX design a pak samotný vývoj aplikace.

Ještě bych dodal, že pokud se zakázka začne realizovat, obchodník do ní může doplnit výrobní číslo zakázky a poté si může exportovat realizované zakázky. Tím si můžeme interně validovat spojení s reálnými výsledky a takto ověřovat celé řešení v postprocesu.

K mé další otázce – jak probíhá evaluace? Kdy nastává předávání?

Trénujete modely, nebo je to spíše statické a jednou za rok změníte vlastnosti (features)? Problém vidím v tom, že při zadávání vstupních hodnot produktu pro odhad ten produkt není nijak jednoznačně identifikovaný. Zatím jsme ho nezaložili v našem ERP systému, nemá žádné ID a nějak ho nazýváme. To se velmi složitě propojuje s produktem, který už výrobou prošel a má své ID. Zatím tedy evaluaci děláme tak, že přiřazujeme číslo ručně a na konci, s pomocí exportu nabídek, ji spojujeme s realizací.

Samozřejmě, jak čas plyne a přibývají nové typy zakázek, je potřeba model jednou za čas přetrénovat. To jsme historicky dělali asi dvakrát. Znamená to získat nový dump dat, spustit pipeline k přetrénování modelu, provést evaluaci a tým dostane report o tom, jak nová verze funguje. Cenové nabídky se aktualizují častěji, ale z našeho pohledu je to podobný proces.

Jasně, tady je opravený text:

Jak jsem říkal, ta cenová nabídka vstupuje do toho modelu, takže vlastně každý řádek v trénovací sadě má svoji cenovou mapu. Pro nás je to tedy velmi podobný proces. Kdybych to abstrahoval, tak moje otázka je, jak často přetrénovávat model? Jak určit, jestli to dělat každý den, každý měsíc, nebo jednou za půl roku? To je obecně těžké zodpovědět. Záleží na tom, jak vypadají zakázky. Pokud začne firma zavádět nějaký nový produkt, tak model ho zatím nezná. Nejprve nasbírá nějaký počet zakázek na tento produkt a pak se to projeví v modelu při další iteraci. Pokud by ale vyráběli pořád dokola to stejné, mění se vlastně jen cenové mapy, a ty se mění v nějakém časovém horizontu. Mám pocit, že vy jedete v měsíčních intervalech, takže… a to je vstup do modelu.

Samotný model má pak své váhy. Jeden z těch zásadních momentů byl i nástup nové technologie. V roce 2023 jsme měli relativně malý podíl například digitálně potištěných papírů na vstupu. K dnešku to procento významně roste a to je přesně ten okamžik, kdy je potřeba model naučit pracovat s tímto novým typem, například s digitálním potiskem. Když se něco výrazně změní v realitě, je potřeba na to model adekvátně reagovat.

Mně na tom přijde zajímavé, že vnímám Gauss jako AI OGs – vy jste mluvili o data science a AI ještě dřív, než to bylo cool, a tak jste to prokopali. Ale teď, když mluvíme o tomhle projektu, tak samotná data science, modelování a ta „chytristika“ mi přijde jako jen malá část – na začátku je totiž velký podíl business consultingu, pochopení domény a čištění dat, a teď zase vytváříte klasické webové aplikace. Jak to vnímáš ty, Jirko? Je to tak vždycky? Byl tady v minulosti větší podíl data science, nebo spíš menší? Je to nějaký trend?

Já bych řekl, že je to trend. Hodně záleží na tom, co je výsledkem. Když jde o takovouhle aplikaci, tak data science tvoří tak čtvrtinu, možná třetinu, pokud budu optimista. Zbytek jsou všechny ostatní věci, co jsi zmiňoval. Problém je, že systémy, které měřicí firmy používají, nejsou schopné zastat úlohu našeho frontendu, což by bylo logické – lidé na nich pracují, máme vyřešené přihlašování a tak dále, takže by to všechno mohlo odpadnout. Pro nás by pak bylo zajímavé nabízet jen API, které by problém řešilo. Ale bohužel to takhle většinou nefunguje.

Takže v této situaci jsme velmi často. Někdy klient chce jen API a integruje si to sám, ale většinou je to takto. A to je pro nás ještě lepší varianta, když provozujeme celou aplikaci my – staráme se o deployment, máme to kompletně pod kontrolou, můžeme sledovat metriky, logy a tak dále. Nejhorší varianta je, když musíme aplikaci nasadit na jeho server. To je pro nás nejhorší – zejména protože to nás stojí daleko víc práce a nemáme to tolik pod kontrolou.

Pokud chceš, můžu ti pomoci s dalším doladěním nebo rozdělením do odstavců.

Jistě, tady je opravená verze textu s úpravami pro lepší srozumitelnost a plynulost:

A pokud jsme tam chtěli přenést celý náš environment, tak to bude stát zejména na devops týmu – vlastně víc než na samotném projektu. Máš pravdu, reálná část práce datového vědce je tam poměrně minoritní, ale na druhou stranu právě na tom to celé stojí – doručit hodnotu, tu „last mile“. Podíval jsi se na to, proč to neskončilo tím, že by se napojil na API, které by s velkou jistotou říkalo cenu a další věci?

My bychom stále chtěli doplnit funkcionalitu, která by uměla predikovat náklady pro větší množství položek. V současnosti ta aplikace odhaduje náklady vždy jen pro jeden výstup. Jak jsem ale na začátku zmiňoval, někdy jsou tendry pro zákazníka obrovské, jsou tam různé varianty a často nejde o desítky položek, ale stovky položek, které zákazník zrovna poptává. Kdybychom tedy uměli náklady predikovat dávkově, byla by to úplná pecka – samozřejmě proto, že tyto větší zakázky jsou i mnohem zajímavější. Ty tendry nám někdy trvají dny i týdny, takže by to znamenalo, že by uživatel v podstatě jen naimportoval Excel se seznamem položek a než by vůbec začal něco manuálně zpracovávat, měl by výsledek.

Na naší straně je implementace dávkového zpracování klasický engineering, protože model máme jako samostatnou službu, která běží někde v pozadí v rámci backendu. V současnosti dávkové zpracování řešíme polomanuálně a krmíme model přes API, takže jde především o to vše integrovat dohromady a zlepšit aplikaci tak, aby bylo možné jednoduše přetáhnout (drag and drop) Excelovský soubor se seznamem položek. Když už je tam hodně dat, bude třeba vyřešit asynchronní zpracování na pozadí.

Zatím ovšem doba zpracování trvá přibližně minutu, což uživatel zvládne počkat a není třeba to komplikovat. Takhle už to běží tři týdny a zatím je to v pohodě.

A co mě na tom všem fascinuje a zajímá, je to, že řešíte cenu pro klienta ve výrobní firmě, kde máte všechny parametry a výroba je komplettně digitalizovaná – každý stroj posílá data. Plánujete tedy další projekt, například optimalizaci výroby?

Jak to, že vlastně nepoužíváte AI na samotnou výrobu, když jste výrobní firma?

Určitě ve výrobě ještě zbývá prostor, kde bychom s AI mohli pomoct, ale jak jsi říkal, naše výroba je už poměrně vysoce digitalizovaná a automatizovaná. Naopak nám rostou kapacity v administrativní části. Máme velmi dobře spočítané, kolik lidí potřebujeme v administrativě na výrobu jednoho metru čtverečního, a rok od roku se ta čísla zvyšují právě v administrativě.

To znamená, že se snažíme co nejvíc pomoct administrativním procesům podobnými technologiemi, aby byla administrativa co nejefektivnější. Cílem je, aby s nezměněným počtem lidí dokázala vyprodukovat mnohem více zakázek, reportů, statistik a byla výrazně agilnější.

Aha, takže to je pro mě hrozně zajímavé – potenciál AI právě v oblasti výro...

Pokud chceš, mohu pokračovat s úpravou další části textu.

Opravený text:

—

Běžně ve výrobních firmách není přímo ve výrobě, protože je to tak dlouhodobě optimalizovaná činnost. U nás to v tuto chvíli platí také, nicméně prostor pro zlepšení existuje. O tom jsme už mluvili i s Gaussem – určitě bychom našli nové případy ve výrobě, ale prioritou pro nás teď je administrativa, protože tam máte úzké hrdlo. Co z tvých zkušeností, Jirko? Tohle není vaše první rodeo s výrobní firmou, viď?

Je to tak, a tato situace se opakuje i jinde. Ty výrobní provozy jsou, když tam jsem, vždycky mě nadchnou – jak je tam málo lidí, jak je všude čisto, jak výrobek rychle prochází firmou. Ale back office a komunikace s klientem jsou úplný pravěk. Lidé si posílají vytisknuté papíry, na kterých něco dopsávají, což vůbec neexistuje v digitální podobě. Je to zanedbané. Porovnávají se tam reporty z různých systémů a podobně. Je to vlastně ten back office, který ty procesy brzdí. Zdaleka to není jen případ T-MU. Mám pocit, že právě optimalizace výroby vede k tomu, že na ní se pracuje, protože tam je všechno jakoby vidět, ale administrativu nikdo neřeší. Když se takhle dlouho neřeší, dopadne to do stavu, ve kterém jsme teď. Na druhou stranu vývoj nových technologií, jazykových modelů, AI asistentů a podobně jde naproti tomuto řešení. Zpracování e-mailů, automatické odpovídání, vyhledávání dodavatelů a podobně lze do velké míry automatizovat, takže optimismus je na místě.

Jak ty, Tomáši, vidíš AI v budoucnu? Jaké budou další AI projekty v týmu Obaly a jak ti chutná AI vlna?

Musím říct, že máme s AI velmi dobrou zkušenost a teď ji budeme rozvíjet ve velkém. Už přemýšlíme, jak zapojit AI agenty do administrativy, jak využít generativní AI například v našem vývoji. Určitě bude prostor i ve výrobě – třeba pro detekci chybných kusů nebo optimalizaci toku materiálu. Plánování je velké téma, a myslím, že klasické přístupy k němu půjdou stranou. Takže toto je cesta, kterou chceme pokračovat.

Když byste měli bilancovat vaši vzájemnou zkušenost – Jirkovu, Gaussovu a Obalů s Gaussem a jejich první implementací – co byste poradili firmám, které s tím ještě nezačaly? Jsou nějaké „lessons learned“, něco, co byste chtěli vědět, než do toho jdou?

Já jsem si do začátku myslel, že AI je jen pro velké korporace s obrovským počtem lidí a týmem data scientistů. A není to pravda. Do AI se může pustit i firma jako ta naše. Myslel jsem, že je to vždy velmi nákladná záležitost, ale teď musím potvrdit to, co zmiňoval Jirka – data science tvoří maximálně jednu třetinu celé práce. Takhle je to i s dalšími aspekty...

Pokud chceš, mohu pokračovat v opravě další části, nebo upravit text pro vyšší srozumitelnost či formální styl.

Základama. Ten quick win, o kterém jsem tady mluvil, že to ta AI dokáže vyřešit náš problém, nebyl vůbec nákladnou záležitostí. Všechno okolo bylo něco, co je v IT notoricky známé. Takže já si z toho dnes beru, že se nemusíme bát tohoto přístupu. Jak jsem řekl, pro nás je to určitě zelená do dalších projektů.

Hmm, a co ty, Jirko? Je nejlepší opravdu sáhnout na výrobek?

No určitě, rád to slyším. Pro nás je to zajímavé v tom, že se objeví nějaké reálné věci. I jako kolegové, když řešíme nějaký projekt takového typu, jsme radši, protože to není žádné šibování s virtuálními marketingovými čísly nebo podobnými věcmi, ale člověk reálně objeví něco, co se děje. Samozřejmě v tom reálném světě se zase objeví jiné výzvy, ale ty máme rádi, takže se těším.

Hmm, já se taky těším a držím vám do budoucna moc palce. Děkuju moc, že jste sdíleli své zkušenosti a cestu, kterou jste společně, tým Obaly a Gauss, prošli. Díky moc.

Děkujeme, že jste doposlouchali až sem. A díky taky našim partnerům a členům Data Talk klubu. Těmi jsou Intex, Saska, Vystreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, Data Mind, Notino a Flow. A pokud chcete zůstat v obraze, co se české datové scény a globálních datových technologií týče, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz. Nechť vás provází data.