Podcast

Data Talk #108: Václav Adamec & Jiří Polcar (Gauss Algorithmic)

epizoda#108 |  vyšlo  |  délka  | 780 poslechů |   |  mp3

V dnešním díle se podíváme na to, jak nasazovat AI projekty tak, aby to nebylo jedno velký ajaj. A to hned se dvěma hosty z Gauss Algorithmic – Jirkou Polcarem a Vaškem Adamcem, kteří za 10+ let implementace AI/ML vypilovali proces pro úspěšnou realizaci projektů. Budeme probírat, jak se vyhnout největším pastím a přešlapům, na které narazíte při práci s po AI toužícími zákázníky – od řízení očekávání, analýzu proveditelnosti až po finální rovinku v podobě implementace. Moderuje Barbora Hinnerová.

Strojový přepis

Ahoj všem, moje jméno je Barbara Hinerová a vítám vás u dalšího dílu DataTolku. V dnešním díle se podíváme na to, jak nasazovat AI projekty tak, aby to nebylo jedno velké AI, a to hned se dvěma hosty z Gauss Algorithmic – Jirkou a Vaškem, kteří za roky implementace AI dokázali vypilovat téměř neprůstřelný proces pro úspěšnou realizaci projektů, o který se s námi dneska podělí. Ahoj kluci.
Ahoj.
Ahoj.

Tak než se dostaneme k tomu procesu a k tomu, aby to nebylo AI, nejdřív se podíváme na to, jak byste se dostali k datům, jak jste vlastně skončili v Gaussu. Takže Jirko, asi začneme u tebe třeba. Jinak teda ještě vás představím celým jménem, to jsem neřekla, takže mám tady Jirku Polcaru a Vaška Adamce.

No tak já jsem se k datům dostal relativně přímočaře, když oklikou přes fyziku a astrofyziku, kterou jsem studoval v Brně. Potom jsem pracoval chvíli na astronomickém ústavu, celý kousek od Prahy ve Fondřevě, a už vlastně během diplomky a dizertace jsem zpracovával data. Na diplomce to byly data z naskenovaných fotografických desek, kde se hledali objekty nějakého typu, takže tam bylo spousta programování. A potom v rámci dizertace jsem zpracovával data z družice, takže zase se tam dělalo spousta technických věcí.

A taky rozpoznávání předmětu nějakého typu?
Ano, bylo to tak, ale to bylo při té diplomce, tam se klasifikovaly objekty právě, které se vyčítaly z těch fotografických desek.

Takže dobrý, asi hodně exotický… Stíhačky americké to měly v sobě, takže to bylo pro mě.
Stíhačky a SMSky, to je úžasná kombinace.

Tak to byl 20 let starý produkt. Ta firma poslala první SMSku vůbec, takže to bylo hrozně zajímavé a hlavně tam byla spousta úžasných lidí, od kterých jsem se naučil spoustu věcí. Tam byl ten vývoj v C a pak tam byly nějaké novější části v Perlu. S tím jsem měl nějaké zkušenosti, takže s tím jsem tam pomáhal. Tam jsem byl pět let a potom jsem byl dva roky ve Seznamu, kde jsem dělal softwarový vývoj na jedné komponentě jejich vyhledávače. Zase spousta zajímavých lidí a celý ten proces byl velmi zajímavý, jak ten vyhledávač funguje.

Takže Seznam byl jednička v technologiích tenkrát, že jo?
Byl. To byl rok kolik?
To už bude asi dvanáct, třináct let zpátky.
No, před Kristem.
Před generativní AI.

No a potom tady ze Seznamu už tvoje cesta vedla…?
Ze Seznamu už vedla cesta přímo do Gaussu. Tam jsem se nechal zlákat.

A čím tě zlákali?
Jeden můj kamarád, Honza Anča, který má digitální agenturu, úspěšnou už mnoho let. Začal tam pracovat na jednom projektu a poslouchal tam strojové učení a tak, prostě jsme se párkrát sešli.

Ty jsi tam hodil, že někdo, kdo by předtím posílal SMSky?
Spíš jsme se znali už dřív ze školy, takže věděl, že mě baví takovéhle věci, a to mě zlákalo. A takhle to začalo.

Jasně, to bylo teda před tím, než vznikl Gauss. Ty jsi jeden ze zakládajících členů, že jo?
Přesně tak, byl jsem tam úplně sám s Honzou. One man show.

Dosta

Jsem v krabici zavalený první server. Dáreček. No, takže to byla taková punková dba. A začal jsi teda dělat modely a tak?
Přesně tak. A dneska tedy v Gaussu působíš jako CTO, že jo? Byla to vlastně ta tvoje role od začátku, anebo to tam taky mělo nějaký vývoj?
No, když ono být CTO, když jsi tam ve firmě, tak je to krásný, že jo?
Přesně tak. Na začátku jsem se spíš věnoval strojovému učení a až později, když se firma rozrostla, zjistil jsem, že na světě je mnohem víc chytřejších lidí než já, kteří se tomu rozumí mnohem více, tak jsem přešel spíš do technické části.
Jasně, no, takže „take one for the team“ a vedeš to.
Dobře, no, to je hezké. Ale určitě se k Gaussu ještě dostaneme. A teď, protože je vás tady víc, podíváme se i na Vaška, na Vaška Adamce.
Ty tady aktuálně působíš v Gaussu jako head of sales, ale ta cesta tam byla taky nějak trošku klikatější, že?
Jo, jo, jo, já jsem původem vystudovaný historik, to asi mnohé napovídá, a učitel dějepisu ještě. Ty tituly dva, abych si tady v týmu nepřipadal méněcenný.
Ale proto nepůjde astrofyzika, teda.
Přesně, přesně. Ty dva magistry vedle toho velkého doktorátu nejsou sice takové, jako ono, ale alespoň se necítím úplně slepý. Svůj doktorát jsem loni zahodil, protože na to není čas, byznys je byznys.
Ale vlastně už na škole jsem začal psát pro nějaký hudební magazín a pak jsem zjistil, že mě vlastně baví copywriting, což vedlo někam k obsahové strategii a content marketingu. Pak jsem zjistil, že když člověk dělá obsah a vnímá klienty, dá se to dobře napojit na sales.
A takhle jsem přes několik kroků prošel různými sférami až k AI, kde jsem před šesti lety nastoupil do brněnské firmy Mycroft Mind, která se zabývá AI v energetice. Je to jedna z nejvíce inovativních firem, které znám, snaží se inovovat i energetiku, což je samo o sobě…
Je zajímavý obor pro inovace, ano.
Chtěl jsem říct, že těžko by se hledalo něco konzervativnějšího, a docela se jim to daří, jsou strašně šikovní.
A tam jsem se začal učit, co AI je, jaký je potenciál těch produktů, jak může pomoci. Byla to skvělá škola pro mě a Filip Procházka, zakladatel Mycroftu, byl skvělý učitel. Samozřejmě i Honza Herman, který vedl datový tým v době, kdy jsem tam byl, byli to skvělí borci, od kterých jsem se hodně naučil.
A naučil jsem se tolik, že jsem pro Mycroft napsal projekt IPCEI. Asi jste o tom nikdy neslyšeli, je to taková nišová věc, ale v podstatě Evropská komise se jednou za čas podívá na oblasti, ve kterých svět těžce utíká Evropě, a Evropa se to snaží dohnat. Pak vypíše obrovskou výzvu a řekne: „Hele, prostě nasypeme do toho spoustu peněz a úsilí. Let's make Europe great again.“
Přesně, a zjistili, že polovodiče jsou asi téma. A my jsme v Mycroftu zrovna tenkrát seděli na nápadu, že vlastně dokážeme specializované modely dostat na opravdu nízkovýkonová, levná zařízení. A to je potom samozřejmě extrémně…

Zajímavé je, že v momentě, kdy nemůžeš všechny data v reálném čase zpracovávat přímo v cloudu, tak si je můžeš přechroustat někde na engine, na periferii.

A ta idea je, že nemusíš mít zařízení typu iPhone, které by ti něco vypočítalo, ale zařízení typu prostě meteosenzor za 10 dolarů, který může mít v sobě umělou inteligenci a dokáže něco počítat. To je velký skok, je to hodně zajímavé. Mycroft na to dostal obrovskou dotaci, je to projekt asi za 17 milionů eur, který bude probíhat v následujících čtyřech letech. Už to vlastně začalo a nějakou dobu běží, asi rok. No, to je zajímavý rozpočet. Doplním, že je to jeden z nejmenších rozpočtů v celé té výzvě, protože v ní jsou giganti typu Bosch, NXP, ST Micro, Infineon. Takže je to super prestižní a byla to skvělá zkušenost. Bylo to samozřejmě náročné dva roky jen psát a iterovat podle připomínek komise, ale je to skvělý pocit, že to dopadlo a myslím si, že to zanechá velkou stopu. Omlouvám se, trochu jsem se rozkecal.

Je to rozhodně velmi zajímavé. Nicméně potom jsi opustil jednání s Evropskou komisí, že?

Přesně tak. Pak přišel Johnny, potkali jsme se, ano, Johnny Darkva, CEO Gausu. Potkali jsme se na společné cestě do Ameriky a říká: „Hledám někoho, kdo by u nás převzal vedení v obchodu, nechceš to dělat?“ V té době jsem byl právě v takové fázi, kdy jsem přemýšlel, co dál, tak jsem si řekl, proč ne. Poslední dva roky jsem v Gausu a zjistil jsem, že svět AI je ještě mnohem větší, než co jsme dělali v Mycroftu a co jsme si představovali ve všech těch aplikacích. Strašně mě baví ta různorodost a, jak říká Jirka, lidi v Gausu jsou fakt skvělí. Je to takový dream team, já jsem tam upřímně šťastný, že tam můžu pracovat, strašně mě to baví, a hlavně mě fakt baví, že všichni jsou tam o mnoho úrovní dál než já. Můžu tam sedět, nasávat, co dělají, dívat se jim pod prsty při řešení problémů, o kterých bych nevěřil, že se dají řešit.

Dobře, tak se pojďme podívat na Gaus. Už jsme to zmínili několikrát, tak kluci, jak byste představili Gaus algoritmy? Kdy vůbec vznikly? Pojďme se podívat i na strukturu týmu, kdo tam je, kolik vás tam je a tak dál.

Gaus algoritmy, který sedí vedle mě na židli, se jmenuje Jirka Polcar. Takže Jirka je vlastně Gaus? Jirka je všechno, co Gaus ztělesňuje, ale pro mě je Jirka skutečně centrální mozek Gausu v tom smyslu, že od toho, jak postavil tým a jak ho vede, se odvíjí celá firma. I jeho triatlonové nadšení je nakažlivé, takže já, jehož největší výkony jsou zhruba 20kilometrové přechody Alp, jsem tam výkonnostně vlastně největší loser ve všem.

Přesně, přesně, tak to jsou ti obchodníci teď, musíme si na to zvykat.

Každopádně firma jako taková se od roku 2013 věnuje umělé inteligenci, strojovému učení, datům a datovým infrastrukturám. Protože se k tomu po…

(zdá se, že tady text končí nedokončený)

Tom ještě dostaneme, ale na začátku, když se před těmi deseti lety dělalo AI, pro spoustu lidí to byl ten Skynet. A dost často k těm klientům vedla ta cesta i přesto, že nejdřív se jim vytvořila ta big data. A nikdy ani ne big. Někdy stačí jen data, to je pravda, která se postavila a pak se nad tím dá dělat ta chytristika.

No, Jirko, řekneš mi něco k tomu, jak se to teda postavil ten tým, proč vlastně ten Jirka teďka stělesňuje ten Gauss a všechny hodnoty, které ta firma má? Trošku to je červená. To je samozřejmě práce všech lidí, co tam pracují. Ale ty začátky byly… My jsme vlastně začali s takovým ambiciózním projektem, který měl za nás obchodovat na burze, na finančních trzích. Tomu jsme se věnovali asi dva roky. Ten tým tehdy měl velikost tří lidí. Bylo to strašně zajímavé, ale nakonec se nám to úplně nepovedlo dotáhnout do funkčního konce.

A proč? Fungovalo to dobře, ale já bych řekl, že nám hlavně chyběly znalosti z finančního trhu. Z toho jsme se poučili. Teďka se nám to…

To nastává pořád, že pronikáme do nějakých trhů, které vůbec neznáme. Jasně, že tam získáváte nějaké zkušenosti, například ve výrobních firmách a podobně. Ale teď už si uvědomujeme, že potřebujeme člověka styčného, který nám ta data prostě popíše a vysvětlí.

Myslíš přímo v té firmě? Někoho, kdo má tu doménovou znalost?

Přesně tak. Samozřejmě za tu historii jsme pracovali v různých oborech, jako bankovnictví, telekomunikace, energetika, zdravotnictví. Získali jsme tak velkou znalost, ale přece jenom jakmile dojde na nějaký detail ve výrobě nebo okrajové oblasti, potřebuješ toho odborníka.

Potřebujeme přesně tak.

Jasně, ale teď jsem utekl od otázky, kolik vás je, jaký lidi v Gamsu jsou a jak tým vůbec funguje. Tak nejdříve se pojďme podívat na tohle a pak určitě můžeme skočit i do konkrétních problémů, které řešíte.

Když vezmu lidi, kteří se přímo podílí na řešení těch projektů jako inženýři a data scientisti, tak bych řekl, že nás je 15. Takže 15 lidí, kteří dělají výrobu a R&D.

Tak tak.

A zbytek jsou Vašek, obchodák, nějaký administrativní pracovníci a tak dále: obchod, back office a potom máme ještě nějaké front-end developery. Občas potřebujeme postavit něco „s ksichtem“, v uvozovkách. Poslední dobou je to víc a víc. Takže ano, někdo to dělá tak, aby to i vypadalo, třeba jako terminátor, jenom se tak chová… Ale fakt je, že to využíváme jen na jednom z pěti, šesti projektů. Takže od toho člověka máme externě, není to core tým.

A co ti, kteří dělají tu vývojovou výrobu? Jaký je tam poměr například mezi data scientisty a data analytiky?

No, já bych řekl, že čtyři jsou vyloženě data scientisti. Pak je skupinka čtyř až pěti lidí, kteří mají přesah a jsou schopní dělat v podstatě všechno. A zbytek jsou vyloženě DevOps lidé, kteří se starají o cloud a infrastrukturu. Takže je to hodně důležité, aby vás to úplně nesežralo, když už nějaké projekty děláte, že jo?

No, problém je, že většin…

Jistě, zde je opravený text:


Při řešení toho projektu potom řešíme to konkrétní řešení, jak ho provozujeme my. Máme tedy souběžně desítky různých projektů, které musíme nějak dohlížet. Většinou to tedy žádnou velkou údržbu nevyžaduje, ale přece jenom občas se to musí nějak upgradovat, starat se o to, dohlížet. Občas se samozřejmě v cloudu stávají nějaké nepředvídatelné věci, které se musí řešit. A pak za to chodí faktory, že jo? Tak, tak. A pak těch projektů, co se zrovna dělá, je taky víc, takže většinou mají nějaké demofáze a tak, takže je tam toho hodně, o co je potřeba se starat.

Dobře, co se týče týmu, je třeba někdo nějaký konkrétní rizikový faktor, který člověk, kterého vyloženě hledáte? Nebo musí to být třeba astrofyzik, aby vám do týmu zapadl? Nebo musí běhat maraton, triatlon nebo… To samozřejmě při přijímacím řízení pomůže. Nějaká taková dovednost – to asi ostatním nedošlo – ale za mě nejdůležitější faktor je nadšení. Pokud člověk o to má zájem a baví ho to, tak všechno ostatní je vedlejší a my ho to naučíme. Takže nadšení je klíčové.

Dobře, takže nadšení, možná nějaké algoritmické myšlení nebo něco takového, a potom už se všechno další dodělá. Tak. Já bych řekl, že v tom víc smícháme takovou tu duši českého člověka – je to opravdu o tom, že opravit tank se šroubovákem je taková základní vlastnost: být schopný poradit si v jakýchkoliv situacích. Už jsme toho totiž viděli opravdu hodně a upřímně, máloco nás dostalo někam do záklonu, ale na kolena nás úplně nedostalo. A řekl bych, že dřív bylo mnohem důležitější, aby ten člověk byl schopný postarat se o celý projekt od začátku až do konce – s tím, že si ho nasadí a udržuje. Teď jsme si ale spoustu věcí zjednodušili ve formě nějakých šablon (template) a podobně, takže ty znalosti nemusí být tak široké, a většinou má někdo specializaci v data science.

Ale většinou tam musí být někdo, kdo je prostě T-shaped člověk.

Ano, jasně. To slyšíme hodně často. Mluvili jsme tady o tom, že děláte infrastrukturu, big data, data, cokoliv dalšího, a pak tady jsou AI a ML projekty. Od roku 2013 byste mohli říct, jak se změnily poměry toho, co děláte v AI a v infrastruktuře od té doby? Nebo jestli už nějaká datová zralost ovlivnila to, že klienti jsou na řešení víc připravení?

Jirka mě kdyžtak opraví, ale dřív byl poměr práce na datech a stavění infrastruktury výrazně větší. Byly to větší projekty pro větší klienty. Dneska je to pro nás spíš menší záležitost – řeknu třeba, že 10 % toho, co děláme, jsou datové infrastrukturní projekty, a 90 % je strojové učení. Dřív to tedy nebylo úplně obráceně, ale bylo to například 60 : 40. Takže postupně ta infrastruktura klesla a vlastně i teď, když něco navrhujeme pro klienta, vždy stavíme řešení jako celek, tak často už klient na své straně zvládne dořešit svoji část, když je potřeba. Ale dost často, když to klient řešit nechce, a teď se dostaneme k t…


Pokud bude potřeba, mohu opravit i zbývající část textu.

Opravený text:

Ohledně nasazování těch modelů a jejich provozu jako takových, máme na to vyvinutou vlastní ML platformu, jak tomu říkáme. Je to v podstatě prostředí, díky kterému dokážeme model pro klienta rychle spustit, bezpečně udržovat velmi dlouhou dobu, ve vysoké kvalitě a s velmi dobrou dostupností. Ve většině případů klient ani nechce model převzít k sobě, protože nemá lidi, kteří by tomu rozuměli a byli schopni se o to postarat. Proto to nabízíme jako službu. Ne že bychom se nutně chtěli profilovat jako nějaký ML cloud provider nebo něco podobného, ale… Je to i byznysově výhodné, mít tam servisní smlouvu. Samozřejmě na tom netočíme miliony, je to spíš přídavek, ale pro nás je to důležité, protože takto dokážeme projekt velmi rychle rozjet.

Často se to dělalo tak, že klient nechal model připravovat u nás, vyzkoušel si ho, řekl, že je to dobré, ale nasazení u sebe trvalo půl roku kvůli přípravě serverů, integracím a podobně. Během té doby ale mohl model už běžet u nás. Takže my to rozběhneme hned, klient ihned získává hodnotu a může pak nasazení u sebe řešit v přechodném období — buď si model po nějaké době převede, nebo u nás zůstane. Proces převodu po té náročné přípravě už nebývá složitý. Znám to dobře – než se všechno vytendruje, vybere, nasadí servery, někdy i čtyřikrát přeinstaluje… a mezitím se změní pět lidí, kteří to měli na starosti. Nikdo si nechce řešit tyto komplikace.

My to tedy dokážeme hezky překlenout a klient zjistí, že to funguje hladce. Často mu to ani neziskové a nákladově nedává smysl provozovat u sebe – v drtivé většině případů je výhodnější to nechat u nás. Proč? Protože při dlouhodobé údržbě modelu je potřeba model čas od času přetrénovat. Někdy se to děje jednorázově, kdy nám klient dodá data podobně jako na začátku, ale občas je potřeba tento proces automatizovat. Pak je nutné integrovat nejen samotný model u klienta, ale i feedback o kvalitě modelu a proces jeho obnovování. To znamená především zajistit tok dat od klienta, což může být složitější než samotný vývoj modelu, protože data jsou často někde v recepčním systému nebo jinde.

Takže toto proces občas komplikuje. My jsme vlastně…

(Pokud máte zájem, mohu text upravit i pokračovat podle potřeby.)

Oprav text:


Chtěli jsme se bavit o tom vašem procesu.

Nastavování AI projektů. Trošku jsme se už dostali k provozování, a to je přitom ještě nějaký krok, nevím kolik. Takže možná si pojďme říct, co vás vlastně vedlo k tomu, že takový proces vzniknul, jak vznikal, rozebrat si jednotlivé kroky, které pak zajišťují, že ty AI projekty skutečně fungují jako AI. Tak kdo začne?

Jo, jo, jo, jestli otevřete ten náš cheat sheet na našem webu, máme tam ten proces, který si pamatuju z hlavy i v angličtině – „One Universal Process 10 Years in the Making“. A to je přesně ono. Je to proces, který jsme vyvíjeli 10 let, v podstatě 10 let tvrdých iterací na to, co funguje a co nefunguje. Každý projekt v každém odvětví, kde jsme působili, každý klient byl jiný a každá spolupráce byla jiná iterace toho, jak překonávat problémy. A takhle jsme nakonec přišli na to, že to dokážeme rozdělit do pěti jednoduchých fází.

Zároveň je to trochu klasický případ, jako když porcujete slona. Přijdete, podíváte se na téma, kdy chcete začít řešit AI ve firmě, a teď si říkáte, odkud začít, co dělat, jak to uchopit. „Potřebuji to! Potřebuju to strašně!“ Bort to potřebuje, prostě všichni naposledy dva roky musí mít AI ve všem, i kartáček musí mít AI. A když chcete dostat AI i do kartáčku, musíte začít úplně od začátku, tou první položkou, kterou máme – strategií. Musíte se začít ptát, jestli to vůbec má smysl.

A tohle s klienty opravdu procházíme – spoustu nápadů prostě odkládáme, protože buď ještě nejsme připravení, anebo jsou to úplné blbosti. Ale je naprosto relevantní si to říct hned na začátku – „Tahle cesta není ta správná, pokud chceš řešit tyhle typy problémů.“

Jaké typy? Máš nějaké konkrétní, které nedávají smysl? Chápu, že občas požadavky mohou být takové „Fakt potřebuji, aby mi to snížilo náklady a zároveň předpovídalo budoucnost.“ A že ta iluze kouzelné krabičky s AI musí často zmizet.

Jo, je to jeden z důvodů, proč v oblasti marketingu děláme málo věcí – spousta marketérů si myslí, že nad Google Analytics můžeme vytvořit ještě dokonalejší analytiku pomocí AI. Ten model se ale dá využít spíš tak, že rychle generujete stránky přizpůsobené na míru, hyperpersonalizace stránek. Na to je AI výborná. Ale AI použijete na rychlé přečtení toho, co už máte v systému, ne na nějakou nadpřirozenou inteligenci navíc.

To je jedna z věcí – spousta lidí si myslí, že vezmou Google Analytics a budou z nich dělat super detailní profily. Jednak je to těžký úkol, jednak Analytics už máš, proč bys to pak zbytečně komplikovala, a navíc je tu GDPR, takže v Evropě jsi limitovaná v tom, co můžeš přečíst a používat.

To byla jedna věc. Druhá jsou voiceboti. Všichni jsou nadšení,


Pokud chceš, mohu pokračovat s opravou textu i dál.

Opravený text:

Všichni chtějí všude chatboty a voiceboty. A když se potom podíváš, jak to v reálu funguje, když potřebuješ být prostě, řekněme, T-Mobile nebo banka, jsem z toho vždycky strašně frustrovaná. Když mluvím s nějakým takovým robotem, nejradši bych ten telefon okamžitě vyhodila z okna. Za mě ten robot dává smysl v momentě, kdy třeba v sobotu v noci, ve dvě ráno, potřebuješ něco řešit a prostě ten robot je lepší než nic. Super. Nebo taky, když jsi operátor na lince a přesně v sobotu ve dvě ráno na noční směně se ti porouchá stroj. Je daleko větší šance, že vyřešíš problém během té své směny, když budeš mít nějakého chatbota, který ti napoví, než když si začneš otevírat manuály a hledat, co znamená ta kontrolka, jak to máš dělat, koho máš zavolat ve firmě, když se něco stane, blablabla.

Ale většinou je ten požadavek prostě „hele, tady chcem mít voicebota, aby nám lidi mohli volat a řešit problémy“ a říkáme „super“. A teď si představte, že vám lidi volají z dálnice z auta. A problém není ve voicebotovi, ale v mikrofonu. V mikrofonu.

Taky když jste na dálnici, v jedoucím autě, máte ještě nekvalitní připojení. A tam, kde člověk pochopí, že když mu to na chvilku zamrzne a po půl minutě to zase naskočí, tak je schopný navázat, u robota už to ale fungovat nemusí. A právě to často vysvětlujeme těm lidem. Problém není v technologii jako takové, problém je v reálném světě. V tom, že máš jeden mikrofon, přes který mluví tři lidi, jak to ten robot má vyčíst? To je přesně věc, co teď řešíme s Burger Kingem poslední rok — voicebot na drive-inu. Biznisově to dává naprostý smysl. Dokonalý. Prakticky přijedeš na drive-in, typicky u dálnice, teď tam prší, v autě se ti hádají čtyři děti, kdo chce jaký typ Happy Mealu. A co si z toho vezme ten robot? No, to se pak dozvíš u okénka, ještě to budou dávat. Přesně tak. Plus se dozvíš věci, na které bys nikdy nepomyslel. Třeba: „Doporuč mi písničku, která chutná jako oběd.“ Ježišmarja. Čtyři lidi můžou říct, co chtějí, a tak se prostě zeptají. No jasně. A robota vždycky nachytají. Rozumím.

Takže to je ten krok té strategie. Mám si představit, že je to nějaký workshop s klientem, kde se probírají věci, které jsou teoreticky možný řešit a dávají smysl? Vy tím nějakým způsobem provázíte a snažíte se klienta navést do té…?

Ano, ano. Většinou to trvá tak tři až čtyři hodiny z toho důvodu, že během první dvou hodin si klient sám prochází procesem uvědomění, že ne všechno, co si o tom myslel a o těch možnostech, je pravda. A taky tím, jak ho rozmluvíme a navedeme na nějakou cestu, začne trochu jinak přemýšlet a pak z něj začnou padat skutečné problémy, které potřebuje řešit. A přesně tak dáme jeden, dva workshopy s nějakými iteracemi a potom na základě toho, co nám řekne, řekneme: OK, my vidíme prostě tohle, tohle…

Zde je opravený a upravený text:


Tohle je cesta pro vaši firmu a tady máte pět use caseů, které jsme identifikovali — pět oblastí, kde můžete nasadit AI, aby vám generovala hodnotu. Jak s tím nakládáte, je už na vás. Někteří to jednoduše mají jako report, který si dají do šuplíku, a když přijde vhodná příležitost, vytáhnou ho. Takže je to třeba v PDF — tady jsou moje use casy, které dávají smysl — a co s tím dál, je vaše rozhodnutí.

Zavoláte akcionářům, oni řeknou, že chtějí řešit AI, a vy jim představíte pět možností, co můžeme dělat. Vyberte si. Jako v menu, zvolíte si cestu a jdeme dál.

Další krok je strategie, která zahrnuje workshop nebo konzultaci. Zatím ale nezasahujeme do detailní analýzy současného stavu klienta, jako je datová vyspělost, infrastruktura apod. Samozřejmě na to díváme, ale nejdeme do hloubky. Obvykle přijdeme, podíváme se a zhruba víme, co klient má, protože nám to sám řekne — s čím pracuje.

Vidíme, jaký má lidi, jaký textové systémy používá, jestli má správce ERP systému s týmem IT lidí, nebo třeba jen jednoho systémového inženýra, který se stará o všechno, případně externího dodavatele s vlastními prioritami. To dost variuje a podle možností se díváme, dáváme doporučení a taky odhad náročnosti — procesní, technické nebo jiné.

Používáme hodnocení hvězdičkami od jedné do pěti, podle toho, jak je nasazení jednoduché nebo složité. Takže něco jako pětihvězdičkový rating. Dá se to přirovnat k časové náročnosti. Je důležité si uvědomit, že AI je hodně o výzkumu — neděláme přitom jen statické weby.

Klient je často zvyklý na standardní softwarové projekty, kde mu něco nasadíme a ono to funguje. Ale u AI projektu je tady otazník, jak dobře bude fungovat, jak rychle to bude hotové a jestli vůbec splní požadavky. Proto máme další krok — posuzování proveditelnosti.

Přesně tak — s klientem jdeme hlouběji, díváme se na data, zkoumáme, jestli už existuje nějaký model nebo typy modelů, které můžeme použít, nebo jestli budeme muset něco napsat zcela od nuly. Prohlížíme třeba GitHub — pokud tam něco je, proč bychom to měli vynalézat znovu? Většinou metade půlky práce už někdo odvedl připravením knihoven nebo nástrojů, které můžeme použít.

Pak začínáme iterovat a říkat klientovi…


Pokud chcete, mohu opravit nebo upravit i další část textu.

Jasně, tady už jsou ty parametry, ve kterých se můžeme pohybovat. Už víme, že se můžeme dostat třeba k 90 % přesnosti, nebo k nějaké rychlosti odezvy, pokud chci, aby něco bylo strašně rychlé. To už přehodím tady na Jirku, ať mě doplní. No, toto je těžká diskuze, zvlášť pokud klient má už konkrétnější zadání.

Ta data jsou, řekněme, typická pro daný segment. Můžou to být například technické výkresy. Potřebuje optimalizovat proces technického kreslení, nebo třeba odhadnout cenu, kolik ho to bude stát ve výrobě – nějaké rozpočtování a podobně. Na začátku pro nás ale bývá velká nejistota, jak budeme schopni z dat vyčíst a interpretovat potřebné informace. Výkres je složitá věc. Nejen že my nemáme odborné znalosti, ale taky tam vždycky bývají nějaké normy. Například výrobek je nakreslený z několika stran a tomu je potřeba porozumět. Navíc jsou tam různé zvyklosti – třeba v té firmě mají několik dodavatelů těch výkresů, kteří se navzájem liší. Některé jsou zpracované lépe, jiné hůře.

Snažíme se tedy v tom identifikovat něco, co je z našeho pohledu nejsnadnější, a zároveň to klientovi ušetří velkou část práce. Například část výkresů pochází od jednoho dodavatele, jehož výkresy tvoří třeba 60 % zakázek a jsou dobře zpracovatelný, protože nejsou skeny a dodržují nějaký standard – například jsou v CADu. Takže to je první krok – fokusujeme se právě na to. A víme, že jakmile data dobře přečteme, dál už je to celkem jednoduchý úkol, který jsme už mnohokrát dělali.

V druhém kroku, ve fázi proveditelnosti, už skutečně pracujete nad daty klienta. Přesně tak. Dostaneme nějaký vzorek a někdo si u toho sedne a rozhodne, jak do toho půjde. Udělá research, analyzuje, co bude potřeba. Někdy to může zabrat dost času, a tady je těžké klientovi vysvětlit, že ho to něco bude stát, protože ještě vlastně nic mít nebude. Navíc se může stát, že zjistíme, že to nejde. To se nám ale moc často nestává. Nebo že do něčeho nepůjdeme. Ale klient to na začátku neví.

Čím více projektů máme za sebou, tím snadněji se s klientem komunikuje, protože jsme schopni mu ukázat nějaké případové studie, ideálně z jeho segmentu. Ale někdy se jedná o úplnou novinku a pak skutečně nevíme. Riziko zde tedy existuje. Snažíme se být co nejvíce transparentní, všechno mu vysvětlit a v iteracích s klientem komunikovat, ukazovat, co už se podařilo. Protože se často ukáže, že i vyřešení části problému klientovi hodně pomůže – například mu ušetří 60 % času nebo něčeho podobného, přitom je řešený jen kousek celkového problému, ale je pro něj velmi bolestivý. Takže to se může stát během té…

Jasně, tady je opravený text s úpravou stylistiky a gramatiky pro lepší srozumitelnost:


Leté fáze. A vlastně to změní i rozsah toho dalšího projektu, protože jsme na začátku mysleli, že budeme dělat něco jiného. Já bych tady ještě doplnil, že by mohl být pěkný příklad u těch samoobslužných jídelních automatů, které jsme dělali. Na začátku to bylo vlastně tak, že jsme chtěli engine, který rozpozná jídlo, aby mohly být samoobslužné boxy v závodních jídelnách.

Boxy, jakože? Prostě přijdeš, máš tam samoobslužnou pokladnu a žádného pokladního, položíš tác s polévkou, hlavním jídlem a něčím na tu váhu, vyfotí to a řekne: jasně, svíčková s něčím, rajská s něčím, váží tolik a tolik, tohle je cena, čau.

A tohle byl přesně případ, kdy jsme v úvodním kroku zjistili, že problém jde řešit jinak, než tak, že budeme trénovat model na obecné rozpoznávání jídla. A to je přesně to, že často můžeš postupovat jednodušeji… A neexistovala nějaká knihovna na rajskou, svíčkovou a podobně? Je zajímavé, že svíčková s knedlíky na Googlu není až tak moc featuřovaná. To byl ovšem věrný problém.

Spíš jde o to, že můžeš přijít na to, že problém se dá vyřešit výrazně jednodušeji a levněji, pokud jen mírně upravíš celý proces. A to taky může být cesta. V našem případě to bylo tak, že místo abychom stavěli univerzální síť, která by rozpoznávala všechno, jsme vytvořili síť, na kterou se vždycky ráno nahrají vzorové porce, protože když uvaří, tak udělají ty vzorové porce. Vyfotíš vzorovou porci a pak přesně víš, co se ten den dělá a jak to vypadá.

Je to extrémně efektivní a velmi levné jak na provoz, tak na vývoj. Stačí detekovat talíř a spočítat barevné spektrum, protože guláš a svíčková vypadají jinak. Rajská a guláš – ten má knedlíky. Někdy se nám stává, že… nebo prostě musíš klienta naučit, že ve stejný den nemá mít rajskou i guláš. A hlavně, ať si lidi nepřidávají jiné přílohy k jídlům, pro boha. Svíčková s těstovinami? Co si budeme povídat…

Takže jde o proveditelnost. A tady třeba už přichází ten krok, kdy rozpoznáš, že nebudeme dělat rozpoznávání úplně všeho, ale použijeme tento způsob. Klient pak dostává návrh dalšího postupu.

Přesně. Většinou výsledkem na naší straně je jednoduchý model, který klient sice nevidí, ale dostane report, kde na vzorku dat předvedeme, jak věc funguje. Třeba takové demo, někdy i interaktivní – klient dostane jednoduchou webovku, kam si může nahrávat svoje vzorová jídla, vyfotit je a systém mu něco řekne. Jindy dostane jen report, například „zpracovali jsme 300 vašich dokumentů a z toho jsme vyhodnotili…“. A má tam i informaci o spolehlivosti modelu, aby věděl, co může od systému očekávat. A třeba i predikci, jak lze model vylepšit.

To je často otázka. Ale u těch modelů… A když t…


Pokud potřebujete opravit i pokračování, dejte vědět!

Tady je opravený text s lepší srozumitelností a jazykovou úpravou:


Časová dotace neodpovídá úplně tomu zisku. Snažíme se to lidem vysvětlovat. To, že jsme za 14 dní vyřešili 80 %, neznamená, že za rok vyřešíme 90 %. A když model predikuje spolehlivost 90 %, můžete mu věřit na 100 %? Většinou ne. Často je to kladná otázka, ale my k tomu většinou přidáváme ještě nějaké skóre – confidence score. Když je skóre vysoké, tak můžeme více věřit výsledku, pokud ne, tak víc váháme. A klienti to velmi rychle pochopí.

To byla ta pravidelnost. Klient pak dostane report nebo krátkou ukázku, případně návrh postupu, co se dá dělat, jak to lze provést, s jakou spolehlivostí a jakým confidence scorem. Dostane studii, kde je zpracovaný celý outline dalšího projektu včetně odhadované náročnosti. Tento krok nám umožňuje odkrytí, jak to bude pravděpodobně probíhat a jakou máme míru jistoty.

Na základě toho se klient může rozhodnout, zda do projektu půjde, nebo ne. Někdy zjistíme, že řešení bude dražší než celková hodnota problému, takže nedává smysl pokračovat, ale i to je důležitá informace.

Tento moment navazuje na třetí krok, kterému říkáme „zbavte se rizika“ nebo d-risk. Říkáme tomu také „havarujte levně“ – FilFast. Na začátku lze pomocí jednoduchých věcí zjistit, zda projekt dává smysl a zda funguje. V proveditelnosti ověřujeme, zda to dává smysl a pravděpodobně bude fungovat, a v d-risku se snažíme s co nejmenším úsilím dosáhnout požadovaných funkcí.

Pokud nedojde ke splnění požadavků, řekneme si, že nás to mrzí, že to nedává smysl, a ukončíme projekt dříve, než se propálí další peníze na trénování modelu, který nemáme šanci správně doladit. To se může stát například u ostrých dat, která se liší od testovacího vzorku.

Jak často se stává, že problém je v datech a ne v modelu? Často, dokonce bych řekl, že je to hlavní část problému. Klienti často těžko uvěřit, že data nejsou v pořádku. Tvrdí, že mají nejlepší data – což jim samozřejmě připadá jasné – ale protože jsme to zažili už mnohokrát, klademe na to velký důraz.

Zejména ve výrobních firmách, kde se poslední dobou hodně pohybujeme, jsou firmy v provozu odborníky na určitou část výroby, kterou mají dobře zvládnutou. Když přijedem k zákazníkovi a vidíme, jak dokonale mají výrobu uspořádanou, jsou často nadšení.

Na druhou stranu potřebují pomoc právě s nějakou částí na začátku nebo na konci procesu. A i když tvrdí, že data jsou v perfektní kondici, protože je používají, ukáže se, že pro jejich specifický příklad použití to tolik pravda není. Ta data jsou perfektní pro jejich běžný provoz, ale z pohledu, který potřebujeme zpracovat, nemusí být úplně vhodná.


Pokud chcete, mohu vám text ještě více zkrátit nebo upravit podle konkrétního účelu.

Tady je opravený a trochu upravený text, aby byl plynulejší a čitelnější:


Když potřebujeme jít do nějakého detailu, a oni ho nepotřebují, ukáže se, že v půlce něco chybí, nebo že třeba vyměnili nějaké zařízení a data dva roky stará jsou v jiných jednotkách, a podobně. A to je velmi bolestivý způsob, jak to zjistit, protože už do toho byly investovány peníze. Navíc je toho většinou hodně, my to hned nevidíme a doménu neznáme.

Takže vlastně až když něco nefunguje, jak bychom očekávali, začneme se do toho nořit a zjistíme, že dva roky stará data se prostě nedají použít, protože jsou v jiném formátu. Formát je ještě relativně snadno zjistitelný problém, ale co když je třeba nějaké číslo vynásobené deseti?

A právě tohle často komplikuje a prodražuje celý proces, protože musíme jít za klientem a říct mu: „Tady to máte divné.“ A klient se vrátí a řekne: „Aha, jo, vyměnili jsme tady tu mašinu, teď už to je v pořádku.“ Posuneme se o kousek dál a zase se něco podobného stane. Tohle se těžko odhaduje na začátku, a velmi to komplikuje nacenění.

Zatím jste nepřišli na způsob, jak tento problém odbourat, třeba jak data předem zpracovat, abychom zjistili, jestli někde něco nesedí. Problém je hlavně v neznalosti domény.

Podle mě jediný způsob, jak z toho ven, je být co nejvíc transparentní vůči klientovi, komunikovat s ním od začátku a ukazovat mu, co děláme. Klient si pak sám uvědomí, že nám dali špatná data a že je musí poslat znovu, že práci musíme udělat znovu. Když se dostaneme ke konci rozpočtu, který jsme na to dali, můžeme to s klientem otevřeně řešit.

Když to tak neděláme, a na konci přijdeme a řekneme: „Nepovedlo se,“ nechceme vypadat jako hlupáci, takže pak všechny náklady jdou za námi a celkově na tom tratíme. To vůbec nechceme, navíc poškozujeme i technologii, kterou používáme.

Pokud jde o důvěru – ano, je to takové: dělali jsme tu AI projekt, ale nakonec to nestálo za to, protože jsme třicetkrát něco museli řešit. Když ale od začátku komunikujeme, že je to výzkum, experiment pro nás i pro klienta, že víme, jak to pravděpodobně dopadne, ale může se něco stát, tak je to úplně jiné.

A když máš desítky tisíc cenových nabídek a najdeš, že u padesáti z nich se ceny nepočítaly v korunách, ale v eurech, musíš ty padesát najít – a to je ten problém.

Co se mi líbí, je to, že přemýšlíte o tom takhle – abychom neudělali ostudu celé doméně, ale naopak v ní budovali důvěru už od začátku.

Automatizace mi přijde skvělá a myslím, že by ji měli dělat všichni takhle. Tady na to navážu – hodně investujeme i svůj čas do evangelizace kolem AI, snažíme se chodit na různé profesní setkání, konference a workshopy.


Pokud chceš, můžu ještě více text zkrátit nebo přizpůsobit konkrétnímu stylu.

Tady je opravený text:


A tam vysvětlovat, co to je a co všechno to zahrnuje. Většinou to mají tak, že to redukují na chatboty. Všichni si myslí, že je to chatbot nebo nějaké GPT, zázračné tlačítko – tam já něco nahraju a ono se něco stane. A já jim vždycky říkám: je to sice zázračné tlačítko, ale myslete na to, že to zázračné tlačítko stálo 10 miliard dolarů do vývoje. To je jedna věc – nebylo to vůbec levné, aby to fungovalo tak, jak to funguje. A zároveň, když chcete řešit něco jiného, tak nezaleknete se, protože všechny typy problémů můžete řešit jenom tím GPTčkem.

A teď pro spoustu lidí to znamená otevřít tu mysl. A pro nás to potom funguje velice dobře, protože můžeme být transparentní ohledně toho, jak to funguje, ale i kde jsou ta omezení. Snažíme se co nejvíce komunikovat právě ty limity, aby lidé neměli přehnaná očekávání. Hlavně to hrozně pomohlo v tom, že najednou existují uživatelé něčeho, co je AI, že jo? To dřív nebylo vůbec běžné.

Přesně. Ale dobře, měli jsme tady krok, který spočíval v zbavování se rizik. Tam jsme už vlastně otestovali nějaký model na větším množství dat a zjistili, co s tím dál, nebo jaká je další cesta z tohoto kroku, z řízení či eliminace rizik. Pak se snažíš maximalizovat tu příležitost, která tam je. Snažíš se z toho vytáhnout co nejvíc, za co nejpřiměřenější náklady, aby to dávalo smysl. A zároveň se díváš na další přesahy, které to má. Můžeš něco objevit – vezmu třeba příklad, co jsme teď dělali, predikci cenotvorby. Na to můžeš navázat věcmi v plánování výroby nebo prediktivním naskladňováním materiálu. A to jsou právě ty přesahy.

Velmi často mi právě v těch datech a ve chvíli, kdy se k zákazníkovi dostaneme takhle do hloubky, zjistíme, kam všude ta chapadla dat sahají, co všechno se s nimi dá dělat. Některé věci se dají vyřešit ještě v rámci stávajícího rozpočtu a některé elegantně v navazujících projektech, kdy má klient už velkou část problému vyřešenou a může přidávat další věci.

A tady už se dělá něco konkrétního, nebo je to zkrátka zase nějaká další analýza toho, kde by se to dalo využít dál? Existuje na konci toho nějaký výstup?

Ano, výstupem jsou právě ty další projekty – že například budeme dělat něco dalšího. Přesně tak. Nebo jak jsem říkal, ve chvíli, kdy tam je rozpočet a můžeme to realizovat, tak jsou to i další funkce, které to může mít – další analýzy, které je možné pomocí toho provést.

A potom už přecházíme do poslední fáze, a to je plánování a exekuce.

Ano, ano. Tak co přesně se skrývá pod tou finální fází?

No, hodně záleží na konkrétním stavu klienta, ale většinou je to nasazení do produkce modelu, který jsme vyvinuli v předchozích fázích. A samozřejmě záleží na tom, jestli klient dokáže komunikovat jenom s API toho modelu, což se někdy stává; pak je to jednoduché…


Pokud chcete, mohu vám pomoci i s pokračováním nebo úpravou dalších částí.

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


Anebo potřebuje k tomu vytvořit nějakou frontendovou aplikaci, kterou pak používá, a tam se musí přihlašovat – většinou je potřeba přihlásit se zabezpečeně, přesně nějakým vlastním nástrojem. Proto se řeší integrační záležitosti. To už je v podstatě takový inženýring, takový fine tuning. Samozřejmě je to důležité a musíme se v tom přizpůsobovat klientovi, takže je to vždycky trochu jiné.

Tady máme ty šablony, které pomáhají, když končí data science a hlavní doména, ale přichází další požadavky. Musíme se přizpůsobovat, a když něco děláme podruhé či potřetí, je to pro nás jednodušší, ale složitější klienti, kteří mají vlastní infrastrukturu, do které musíme zasahovat, to může komplikovat věci. Někdy to bývá i pro klienta překvapení – zjistí, že už má něco, co jsme mu ukázali, že funguje, ale teď musí zaplatit další peníze, které s tím přímo nesouvisí, aby to mohl pohodlně používat.

Navíc, když se to začne používat přímo ve firmě a dá se to do rukou jejich lidem, klient zjistí, že ještě potřebuje další věci – třeba workshopy, jak to správně používat. Někdy se nám takový projekt úplně přenese do jiné oblasti. Takže samozřejmě přichází konzultantská činnost. Není to jen o workshopech, ale i o dalších funkcích, které klient chce – například UX, které se řeší velmi intenzivně.

Když vezmeme v potaz vše, o čem jsme mluvili dosud, tvoří náklady na vývoj modelu a výzkum zhruba 30–40 % celého projektu. Zbývající dvě třetiny typicky tvoří nasazení a integrace, včetně veškerých UX řešení, pokud je klient potřebuje.

Myslím, že nejlepší poměr, jaký máme, je asi 50:50, ale u větších firem je to typicky spíš 70 % práce na nasazení a integracích. Nejčastěji se nám stává, že když klient zjistí, co všechno je potřeba udělat, rozhodne se řešit to interně. Dopady jsou různé. Když klient například přestane po třech měsících komunikovat, je to určitě známka pomalé adopce AI řešení. Oni od nás dostanou API a my to samozřejmě monitorujeme – vidíme, jak často ho používají a jestli vůbec. Chápu, že mohou chtít ušetřit nebo mají na to jiný názor, ale já osobně jsem radši, když to děláme my, protože tak máme kontrolu nad tím, jak dobře je to nasazeno a dostupné.

Navíc tím získáme další zkušenosti, protože dotažení tohoto procesu až do konce je hrozně důležité – nakonec to celé korunuje. Když se někomu pohodlně používá, je to asi nejdůležitější pro samotnou adopci. Dlouho jsme se soustředili spíš na předchozí části projektu, protože nás více bavily, ale čím dál víc si uvědomujeme, jak je UX důležité. Je to prostě full stack přístup.


Pokud byste chtěli text ještě více zestručnit nebo upravit stylisticky, dejte vědět!

Tady je upravený a stylisticky vylepšený text:


Dobře to ukazuje a prodává jako use case. Určitě. U nás ukážeš něco, co vypadá spíš jako nějaká aplikace než jen APIčko. Spíš než prezentaci a rozbor toho, co v tom modelu bylo použito. Přesně. A teď ještě k tomu u nás, když to není APIčko za tři a půl milionu. Takže je to tak.

Dobře, máme tady proces, který je spíš hodně o té byznysové stránce – jak vůbec dostat klienta k tomu, co a jak se v tom dá dělat a k čemu to může být užitečné. Třeba i nějaké knihovny, které jste nedávno objevili.

Ano, strašně rádi byste je doporučili našim posluchačům, protože pro vás byly „life changing“. Tak co, Jirko?

No, tady máme základní kostru celého projektu. To, co to drží, je Kubernetes. Používáme ho jak na stagingu, tak v produkci. V produkci máme AKS (Azure Kubernetes Service), na stagingu si spravujeme vlastní Kubernetes na levnějších virtuálních strojích. Výstupem každé komponenty, do které projekt rozbíjíme, je Docker image, který pak nasazujeme do Kubernetes.

Snažíme se machine learningové projekty maximálně izolovat od zbytku a oddělit API. Většinou má ten model jednoduché RESTové API a to je všechno – je to samostatné. Pracujeme prakticky výhradně v Pythonu a používáme FastAPI pro RESTové API.

Máme tam skelet Pythonu, který vygenerujeme pomocí projektového frameworku, a výzkumník tam už jen doplňuje své funkce. Tyto projekty mají obrovské závislosti na spoustě knihoven, často jsou to modely, které zabírají i gigabajty – například jazykové modely. Snažíme se tyto „monstra“ držet co nejvíc odděleně.

Pak je obvykle i backend, který se stará o všechny ostatní věci – například když se klient autentizuje nebo když je potřeba držet status či kontext pro model. Ten backend je také napsaný v Pythonu s FastAPI.

Jako databázi většinou používáme relační Postgres. Celý projekt tedy typicky tvoří tato čtyři hlavní komponenty: model s REST API, backend, databáze a případný frontend, pokud je potřeba.

Někdy řešíme autentizaci pomocí Keycloak.

Zapomněl jsem na něco?

Co je u nás možná netypické, že současně řešíme velké množství projektů, a je třeba mezi nimi přepínat, zejména když lidé pracují na více projektech zároveň. Kvůli bezpečnosti a standardizaci vývojového prostředí na noteboocích používáme Nix Shell. Ten nám pomáhá sjednotit prostředí mezi vývojáři a data scientisty, protože někteří mají Maci, někteří Linuxy s různými verzemi.

Díky Nixu každý pracuje ve stejném prostředí jako ostatní, takže přepínání mezi projekty je bezproblémové – prostředí se vždy překonfiguruje pro daný projekt.

Máte třeba nějaké hardwarové hračky? Něco speciálního?


Pokud chceš, můžu text ještě zkrátit nebo víc přizpůsobit.

Zajímavého v kanclu? Na čem to tam všechno běží? A s čím máte velkou radost, že si s tím můžete hrát? Máme. Tak se pochlubte.

Máme tam několik serverů s grafickými kartami. Snažíme se kupovat nějaké akční herní počítače, co tam právě máme – ty jsou třeba velmi levné. Akční? Jako akční ceny. Většinou ale mají málo paměti, což pro hry není potřeba, ale my to potřebujeme. Pro větší projekty, které už jsou v nějaké pokročilejší fázi, si pronajímáme výpočetní výkon v cloudu.

Nejvýkonnější server momentálně máme u Mendlovky, kterým děkujeme za opatrovnictví, za to, že se o něj ujali, protože u nás v kanceláři by asi nebyl úplně v bezpečí. Navíc bychom ho ani neměli kam dát. A to je nová hračka, máme přístupy pár dní, takže se na to určitě těšíme. Po dlouhé době obrovský hardware. Jsou tam dvě Nvidia A6000 karty, jestli se nepletu. To jsou karty za půl milionu. No nekupte – to nebylo moc akční.

To sice nebylo moc akční, ale potřebujeme to na jazykové modely. Jasně. A s výkonem to potřebujeme na projekt s firmou Clever Maps.

Ano, právě proto se na to ptám.

No nic, nebudeme si přihřívat svou polévčičku, ale ráda bych se ještě podívala do vaší „polévčičky“, a to na úspěšné implementace. Jestli máte vyloženě nějaké „success stories“, což určitě máte. Já taky opravím, tak jestli se na to můžeme podívat?

Určitě, máme jich víc. Sportovci asi budou znát MySasy, respektive Elongu. To je náš dlouhodobě spokojený klient, kde jsme byli od úplného začátku.

A co se tam řešilo?

Je to aplikace, která v podstatě dává personalizovaná doporučení sportovcům.

Jakože dneska máš…

Ne, ne, ne, pracuje to s variabilitou srdečního tepu, což je taky úloha, kterou tam vlastně děláme. Původně, když klient s tím začínal, trvalo to 15 minut, v podstatě si musel být připojený k hrudnímu pásu přes mobil a načítat data. My jsme to stáhli na 3 minuty.

A funguje to s hrudním pásem, nebo nějakým jiným wearable zařízením?

Může to být Apple Watch nebo Garmin.

Tak jo, můžou to být Garmin, Jirko. Oni mají svoje zařízení, ale vyřešili to tak, že je to optický senzor na ruce. Teď ta Elonga, původně MySasy byla aplikace v telefonu, Elonga je zařízení, které si dáváš na paži. Když si představíš hoop, jestli víš, tak něco podobného. Senzor, co nosíš na bicepsu a měří ti tam něco.

Dobře, zajímavé, nevím. Nebo jinde, na předloktí?

Né, kecám. Opravdu, Jirko, řekl jsi to blbě. Teď jsem mluvil o tom, že oni mají nějaké wearables, svoje vlastní, nebo to funguje i s O-Ringem?

Mají MySasy – aplikaci pro profesionální atlety. Ti se pořád můžou měřit i pásy. Tak proto to tolik neznám, jasně.

A Elonga je vlastně podobná věc, ale pro běžnou populaci. Na pásy samozřejmě nemají, tak na MySasy dostanou náramek, který je spojený s jejich aplikací. Nasazují si ho jen na ty tři minuty, co je potřeba měřit.

Aha, OK, zajímavé. No…

Jasně, tady je opravený text s lepší strukturou a srozumitelností:


A co dál, jaké další klienty tam máme? Třeba Vitaadio, další startup, který je v podstatě aplikace pro diabetiky. Je certifikovaná jako zdravotnický software, což znamená, že má ten medtech level – certifikaci pro celý německý trh. Vlastně je to aplikace, pomocí které si diabetici logují jídlo, co snědli. Funguje jako kalorické tabulky pro diabetiky a automaticky rozpoznává, co je na fotce jídla.

To je jeden z příkladů, kdy jsme klientovi doporučili úpravy v UX aplikace, aby uživatelé vždy fotili jídlo standardizovaně – zhora, s viditelným talířem, ne z boku ani zezadu. Protože jinak pak systém špatně rozpoznává obsah. Původní datový set totiž obsahoval fotky, kde pro někoho znamenala „fotka jídla“ třeba jen talíř, pro jiného fotku z McDonald’s, pro dalšího třeba ceduli s názvem produktu – třeba Vincentky. Vše tam bylo smíchané.

Navíc může být problém i s tím, jak je jídlo naservírované – jídlo v restauraci vypadá jinak než doma v miskách. Například těstoviny doma mohou být zalité omáčkou jinak než v restauraci. Ale to není kritický problém, protože v aplikaci si diabetici jídlo potřebují hlavně „odškrtnout“, a když jim nabídneme pravděpodobné možnosti, většinou se trefíme. I pokud ne, není to pro ně katastrofa.

Hlavní funkcí aplikace je například predikce glykemického indexu nebo upozornění, kdy bude třeba si píchnout inzulin. My jsme tam dělali primárně API, které klasifikuje jídlo na fotce a zároveň určuje jeho polohu, aby aplikace uživateli ukázala, kde to jídlo na fotce je.

Hlavní přidanou hodnotou je přesné sledování (tracking) toho, co uživatel snědl a v jakém množství – a celý proces je rychlý a přehledný. To ocení zejména lékaři, kteří pak u pacientů mají skoro kompletní přehled, co a kdy jedli. To je lepší než když pacienti vedou poznámky na papíře, často neúplné nebo nepřesné, protože nemají čas si vše zapisovat průběžně.

Samozřejmě problém zcela vyřešený není, ale i tato úroveň významně pomáhá.


Pokud chceš, můžu ti ještě text zkrátit, zpřehlednit, případně přizpůsobit styl.

Zde je opravený text s lepší gramatikou, interpunkcí a stylistikou:


Alá část je přesně příklad toho, kdy má to obrovský přínos jak pro ty lidi, tak pro zdravotníky. Dobře, rozumím, jasně. No a potom tam máte ještě Capnetics, že jo? Jasně. Herní vývoj her, nějaká automatizace – to je taky zajímavý, o tom jsme tady už měli jeden díl s Johnem, takže to si určitě poslechněte, jestli chcete. A něco, co bys tam ještě vypíchnul na konec, jako nějakou třešínku v těch realizacích?

My teď hodně propagujeme poslední projekt, který jsme dělali právě pro výrobní firmu – společnost Team Obaly, kteří mají velkou fabriku tady ve Všetatech. Je to jedna z dvanácti fabrik, které skupina Team má po celé Evropě. Oni jsou výrobci kartonových krabic. Ty krabice mají různé typy a spoustu variací. Jejich problém byl, že jim zabíralo hodně času nacenění zakázek. Ne, že by na tom někdo seděl 20 hodin, ale typicky ta nabídka musela projít přes tři oddělení, asi sedm lidí, takže to byl klasický příklad toho, kdy to teď zvládne jeden člověk za pár sekund – poměrně přesně – ale hlavně se tím nahradil dlouhý a pro všechny frustrující proces.

Přesně, protože oni dlouhodobě měli úspěšnost jen asi 8 %, což znamená, že 8 % nabídek se proměnilo ve skutečné zakázky. To znamená, že 92 % práce byla práce, která se musela udělat, i když nevíš, která nabídka opravdu dopadne. Prostě 9 z 10 nabídek si zákazník nikdy neobjedná.

Takže to je jedna z těch věcí, a právě teďka v rámci Dnů AI v Brně, 15. října, budeme mít na to samostatnou sekci i se zákazníkem, kde ukážeme nejen z naší strany, jak model funguje a jak jsme řešili ten problém, ale bude tam i pohled ze strany zákazníka – proč to potřebovali řešit, jaké překážky museli překonat, jak se museli nově naučit dívat na svá data a tak dále. Myslím, že tohle je velice cenné, právě proto, že Česko je obecně velmi průmyslová země, ale pokud se podíváš na AI projekty v průmyslu, tak pokud vynecháš robotizaci, kterou vnímám jako samostatnou disciplínu, tak už moc projektů není. A když něco je, tak to často znamená kameru pro kontrolu kvality, jestli někdo nekrade, nebo kontrolu kvality vstupních či výstupních produktů. Ale je tu spousta dalších věcí, které se dají automatizovat.

Přesně tak. Takže vaše prezentace na Dnech AI asi hodně souvisí s evangelizací, které se věnujete. Určitě. To jsme tady už taky trochu zmínili. Tak co jsou ty hlavní aktivity, které v rámci toho děláte?

Jednak jsme aktivní v České asociaci umělé inteligence, a také v rámci nové české národní AI platformy, protože samozřejmě dlouhodobě máme velice dobré vztahy a vazby…


Pokud chceš, mohu text ještě více upravit nebo zkrátit.

Tady je opravená verze textu:


Na Brno AI, Prák AI a vlastně vždycky, když nás oslovovali, jestli bychom něco řekli o AI, tak jsme si řekli, proč ne. A postupem času jsme přišli na to, že nám strašně pomáhá, když představujeme technologii jako takovou a možnosti té technologie, protože… juicy casey, klienty. Přesně, jednak zákazník potřebuje slyšet ty juicy casey, ale my často ten konkrétní juicy case ne vždy dokážeme tolikrát replikovat. Každá firma to má jinak, řeší něco jiného, mají jiná data. Ale přesně – ve chvíli, kdy firma ví, nebo lidé z firmy typicky, jaké jsou limity té technologie, na co se dá použít a jaké typy problémů se tím dají řešit, tak najednou je diskuze úplně jiná.

Začnou o tom přemýšlet jinak, než že „jasně, nechci AI před své chatboty“, „my nepotřebujeme chatbota ve výrobě“ nebo „my tam pro boha nechceme nasazovat chatbota“. Tady jsou věci třeba ve vyčítání výkresů, které můžete dělat, v optimalizaci cenových nabídek, v dynamické tvorbě směn, v logistice je toho samozřejmě taky spousta, ale to je zase jiný obor. To jsou hlavně operativní záležitosti, spíš administrativa a procesy, které předchází nebo navazují na výrobu samotnou. Občas se dá ještě zasáhnout přímo do výroby, ale jak jsem říkal, míra robotizace je velká a automatizace ve výrobě je většinou skvěle zvládnutá. No jasně. Přesně, ale ty věci okolo…

Běžně se nám stává, že dojdeme ke klientovi, který má výrobu opravdu na sekundy top notch, a pak celý sales či back office je ještě tuška-papír. Fakt tuška-papír a sedm rozstříštěných Excelů někde. A tam potom je další věc, co se snažíme lidem říct: Hele, to, že teď nemáte ta data, neznamená, že je nemůžete mít za týden, za měsíc nebo za rok. A snažíme se odbourávat představu, že bez dat je AI nemožná – sběr dat pro vás nemusí být nepřekročitelná bariéra. Když máš proces, co ti trvá týden, a chceš ho automatizovat, potřebuješ týden dat. A už s tím se dá pracovat. Pro lidi je to často wow – „jasně, to jsme nevěděli.“ A vlastně jim odpadá ta bariéra. Rozumím. Jasně.

A co vás teda teď čeká? Na co se těšíte v nejbližší době v Gausu? Plánujete něco nového? Hledáte nové lidi do týmu?

Teď se těšíme na Dny AI a Měsíc AI, protože budeme hodně cestovat, hodně o tom mluvit a těšíme se na diskuze s klienty a lidmi, kteří to zajímá. Daleko nevždy se to konvertuje do klientů, ale to je v pořádku. Hlavně díky tomu zase získáváme přehled o dalších příležitostech, které tam jsou. Hodně se těšíme, že budeme dělat víc projektů ve výrobním průmyslu, protože výroba nás strašně baví a rádi se tam chodíme dívat. Je tam spousta věcí.

Přesně tak, každá výroba je jiná. Je to super. Doporučuji. Sám jsem taky dřív pracoval ve výrobní firmě a je to krásné.

Výsledkem tvojí…


Pokud chcete, mohu text upravit ještě více do formálního stylu nebo naopak do mluveného, neformálního stylu. Stačí říct.

Práce nakonec není jen kód, ale něco hmatatelného. Je krásné se na to dívat, a hlavně ty firmy jsou většinou strašně šikovné. Takže se těšíme na pár návštěv, které máme naplánované teďka ještě na podzim. A myslím si, že Jirka se těší, že postupem času zase přidáme pár lidí do výroby – do vaší kodové výroby.

Ano, letošek byl hodně intenzivní na stážisty. Máte teď třeba hodně diplomek, co vám lidi píšou? Máme, ano, to se děje tak jednou za rok, aby nás to zase úplně nezabilo. Už jsme toho měli moc, ale ti lidé tam často pak zůstanou a něco pro nás dělají, něco vyrábějí. Je to fajn.

Vlastně letos jsme měli poprvé studenta, který k nám přijel v rámci Erasmus Plus z berlínské střední IT školy. Ze střední, jo? Jo, jo, tam se totiž děje to, že lidi vystudují vysokou, a pak zjistí, že si chtějí doplnit nějaké specifické znalosti programování, a jdou zpátky na střední. Ten stážista tady měl 40 let. To je zajímavé.

Takže jsou to zajímavé osudy, ale je super, že máme možnost v omezené míře dát prostor lidem, kteří se chtějí něco naučit. Přijdou k nám, necháme je nahlédnout pod pokličku, Jirka je trochu vycepuje, a oni jsou pak šťastní.

Dobře, děkuju vám za rozhovor.
My moc děkujeme za pozvání. Díky.

Děkujeme, že jste doposlouchali až sem, a díky taky našim partnerům, členům DataTalk klubu. Těmi jsou Intex, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Karl Data Company, Datamind, Notino a Flo. 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.

Odebírejte Data Talk

Apple Podcasts Spotify Deezer Overcast Podcast Index RSS Feed