Podcast

Dobrý den, moje jméno je Jirka Vešerek a vítám vás u dalšího dílu Datatolku. Dnes zde mám Petera Krajzla, který je Senior Director of Research ve společnosti Amplify. Ahoj Petře.

Ahoj Jirko, děkuji za pozvání.

Petře má v Amplify na starosti umělou inteligenci, a to ještě před příchodem GPT. Má dlouholeté zkušenosti, takže to zahrnuje jak generativní umělou inteligenci, tak tradiční strojové učení. Dnes se budeme dívat na to, jak vlastně funguje AI v produktech Amplify, jak funguje tým, který ji vyvíjí, podle čeho se řídí a co používají.

Petře, než se dostaneme k tvé profesní dráze, myslím si, že bohužel spousta našich posluchačů nezná Amplify a pod tímto názvem si nic nepředstaví, mohl bys prosím Amplify na začátek trochu představit?

Jasně, určitě. My samotní říkáme, že Amplify je platforma pro social engagement, která poskytuje software pro social media marketéry, pro e-commerce a pro zákaznické týmy péče o zákazníky. Možná vám něco spíše řekne Socialbakers, tam proběhla akvizice ze strany americké firmy, ale Socialbakers existovaly v České republice docela dlouho a myslím, že lidé toto jméno stále znají. Celkově máme necelých 800 zaměstnanců, asi 750 lidí, a působíme po celém světě. Co je asi zajímavé, že většina vývoje, ne úplně všechen, ale většina vývoje probíhá právě v České republice, a výzkum téměř výhradně probíhá v České republice. Jsme v Plzni, v Praze, v Brně a pak různě rozmístěni na home officech, například na horách a na Šumavě.

Myslím, že je nutné zmínit i naše zákazníky, protože v Česku není moc firem, které prodávají takto velkým podnikům. Koho tedy máte za klíčové zákazníky?

Za klíčové bych vypíchl například Audi, potom máme docela úspěšné projekty ve sportovní a mediální oblasti, přičemž mezi našimi zákazníky je Paris Saint-Germain a několik dalších sportovních organizací. Když máte rádi jídlo, možná znáte Domino's, což je velký americký řetězec. Pokud jde o zákaznickou péči, pomáháme jim se zvládáním dotazů od zákazníků.

To je podle mě důležité z hlediska škály a velikosti, že budeme mluvit o nějakých systémech apod., že jste opravdu velká firma.

Ano, přesně tak.

Co tě tedy přivedlo do Amplify?

Konkrétně do Amplify mě přivedla velká příležitost a chuť po změně. Ale když začnu od začátku – bydlím v Plzni, vystudoval jsem tam Fakultu aplikovaných věd, obor softwareové inženýrství. Poslední dva roky studia jsem měl štěstí, že jsem mohl pracovat pro malý prázdninový startup, který měl velkého amerického zákazníka. Vlastně to byl exkluzivní projekt pro tuto americkou entitu. Tam jsem se naučil strašně moc. Je pravda, že v té době jako student člověk spoustu věcí neřeší, ale tam jsme zjistili, jak se dá software opravdu dělat, alespoň velmi odlišně od školních projektů. Zjistil jsem i spoustu věcí, jak software dělat nemá.

Bylo to takové moje punkové období v oblasti softwaru, protože jsme například jedno prázdninové období strávili měsíc na koleji, zůstali jsme tam a celý den vyráběli kód. Po nocích jsme hráli World of Warcraft, takže to byly prázdniny, během nichž jsem byl nejméně opálený za celý svůj život, protože jsem nevytáhl paty z koleje. Měl jsem možnost párkrát se podívat do Ameriky a vidět, jak tam funguje zákazník. Jak jsem říkal, naučil jsem se tam mnoho věcí – jak se software plánuje, ale i jak by se software plánovat neměl.

Náš zadavatel byl člověk, který nebyl z byznysu, byl to velmi vzdělaný člověk, profesor na univerzitě, ale z mého pohledu netušil moc o managementu.

Mám mnoho historek z té doby. Všechno bylo pro něj priorita A při plánování. On neuměl říct, že nějakou funkci neuděláme teď, ale až příště. Proto vše bylo označeno jako priorita A. Na konci plánování, když jsme se ho ptali, co tedy budeme dělat, protože vše bylo A, zavedl k prioritě A ještě prioritu A+. Takových věcí tam bylo hodně.

Byli tam i zajímavé situace, například vedoucí nechal pracovat přes den a odpoledne přijel a řekl: „Tak kluci, pojedeme na večeři.“ Bylo to už dávno, ale pokud jste někdo byl ve Spojených státech, víte, že porce jídla v restauracích jsou obrovské. My jako správní Češi nic nenecháme na talíři, takže jsme se vždy přejedli. Pak náš šéf řekl: „Teď, když jsme se najedli, pojedeme do kanceláře a uděláme si ještě jeden menší plánovací meeting.“ V tu chvíli jsme museli odsouhlasit téměř vše, protože už jsme totálně nevěděli, o čem mluvíme. Měl tedy dobrou taktiku.

Naštěstí toto moje období skončilo s koncem školy. Jsou to zkušenosti, které se mi hodily. Poté jsem přišel z Plzně do Prahy do Monsteru, což byla v té době, a myslím, že stále je, jedna z největších platforem pro vyhledávání práce.

Tam byl velký rozdíl mezi tím malým startupem, kde jsme seděli všichni v jedné místnosti a dělali vše sami, a velkou korporací, kde jsem byl najatý do role datového inženýra nebo databázového inženýra. Z pracovního týmu o 20 lidech jsem se ocitl v týmu o několika stovkách zaměstnanců, se striktně odděleným vývojem. Vývojář se neměl šanci dostat do QA prostředí a už vůbec ne do produkce, všechno bylo přísně oddělené s extrémním tlakem na optimalizaci kódu, aby byl co nejrychlejší.

Ti, kteří pamatují práci se serverem Ms SQL, znalí jsou i triky jako vypnutí logování, které mírně zrychluje běh. Bylo to velmi odlišné prostředí.

Takže jsi přišel ze startupu v Plzni pro amerického klienta do Monsteru. To je také mezinárodní firma?

Ano, jedná se o americkou velkou firmu, myslím, že to je jedna z prvních internetových společností, možná jsem našel, že monster.com byla jednou z prvních registrovaných internetových domén na světě, takže určitě patří mezi průkopníky.

Byl to tedy velký rozdíl. Velký rozdíl byl i v té škále – požadavků chodilo opravdu obrovské množství. Jednou jsem potkal kamaráda ze školy, který také pracoval s databázemi. Ptali jsme se na množství požadavků, které řeší. On mi řekl, že má asi pět tisíc. Nevěděl jsem přesně, jestli to bylo za týden nebo měsíc, a já odpověděl, že taky mám asi pět tisíc.

Později jsme zjistili, že on mluvil o pěti tisících za týden či měsíc, zatímco já jsem mluvil o pěti tisících za sekundu.

Byla to opravdu velká škála.

V té době byl vývoj hodně založen na vodopádovém modelu a releasy byly jednou za čtvrtletí. Celá firma během víkendu pracovala na releasu, byla spousta pizzy a jídla a pak releasovali. Dnes už si takový přístup nedokážu představit.

A o jakém roce tedy mluvíme?

Přibližně rok 2006 až 2008, něco takového. I tehdy už byl vidět pokrok.

S mnoha lidmi z Monsteru stále udržuji kontakty a občas chodíme na obědy. Firma sídlí v Karlíně, takže jsem nemusel moc cestovat.

V rámci datového týmu jsem měl na starosti nástroj, který dával dohromady všechny skripty, které měly být spuštěny na produkci, tedy nové tabulky a další změny. Tento nástroj nedělal nic jiného než spojoval všechny skripty od vývojářů dohromady. Jen samotný proces trval 15–20 minut, protože složek bylo opravdu hodně. Pak se to pustilo proti produkčním databázím a doufali jsme, že se nic nepokazí.

Releasy trvaly často celý den a někdy až do druhého dne, ale naštěstí se tento přístup později opustil.

Náročnost škály byla opravdu veliká.

Ke konci svého působení v Monsteru jsem se začal více zajímat o datovou vědu a umělou inteligenci. Zkoušeli jsme tam nasadit několik doporučovacích systémů a trochu rozběhnout data science tým.

Dařilo se to sice trochu, ale pomaleji, než jsem si představoval.

Pak přišla nabídka od Socialbakersu.

Jak dlouho jsi vlastně v Monsteru pracoval?

Celých deset let, což je opravdu dlouho, protože mě práce tam strašně bavila a tým byl skvělý. Měl jsem skvělou šéfku, od které jsem se naučil – tehdy jsem to ještě nevěděl – spoustu manažerských věcí. Byla vystudovaná matematička z Harvardu, myslím, že to byla jedna z nejchytřejších a zároveň velmi laskavých osob, které jsem potkal. Dodnes se s ní setkávám a musím říct, že jsem měl ve své kariéře štěstí na lidi, ať už šéfy, nebo kolegy.

Bavil mě tvůj specifický profil. Říkal jsi, že jsi byl datový inženýr. Dříve se tato pozice jmenovala databázový inženýr, dnes už spíše data inženýr, že?

Ano.

Já myslím, že tehdy jste hodně pracovali s relačními databázemi, Microsoft SQL Serverem a také MySQL.

Dnes data inženýři asi tolik s relačními databázemi nepracují, že?

Ano, teď už je to spíše cloudová infrastruktura a podobně.

Když jsi zmiňoval data science a recommendation systém, to bylo už kolem roku 2015?

Ano, něco takového.

Už jste pracovali se Sparkem?

Ano, v části firmy, kde jsem pracoval, byl stack Microsoft SQL Server, C#, a já si prosadil, což zpětně asi bylo chybou, že recommender budeme dělat v Javě, protože jsem s ní tehdy experimentoval a přišlo mi to zajímavé. Oni na to kývli a stal jsem se součástí týmu, kde jsme vzali dva, tři vývojáře z C# a přeškolili je na Java vývojáře.

Postavili jsme recommender engine, tehdy ještě nad Apache Mahout, což byla ta knihovna. Ve Sparku jsem trénoval model a nasadili jsme ho na hlavní stránce Monsteru, kde jsme měli několik pozic na viditelném místě, kam jsme posílali náš obsah.

Bylo to trochu pirátské období v rámci korporace, ale bylo to super a díky tomu jsem se mohl potkat s CTO a CEO, kteří byli normálně velmi vzdálení.

Když dáváte něco zajímavého velkým korporacím, chodí se na to samozřejmě podívat.

Přesně tak.

Co se pak stalo po 10 letech v Monsteru? Co tě přilákalo zpět do – řekněme – spíše startupového prostředí?

Začal jsem tehdy studovat PhD v Plzni, tentokrát na téma umělá inteligence. Nechci se chlubit, ale nedokončil jsem ho, i když jsem se dostal docela daleko. Měl jsem ale štěstí na svého vedoucího, Petra Steinbergera, a na znalosti, které jsem se naučil. To byl asi největší impuls.

Říkal jsem si, že chci něco zkusit jiného. Sledoval jsem nabídky kolem Socialbakers, myslím, že jsem se o ně zajímal delší dobu, protože jsem z Plzně a tam člověk o tom musí vědět.

Líbil se mi jejich koncept a bylo to také velké posunutí v komfortu, protože nabízejí pozici výzkumníka, ale s JavaScriptem, který jsem nikdy neuměl. Pamatuji si, že jsem Vánoce strávil učením se JavaScriptu, ale nakonec jsem ho téměř nepoužil a dnes se někdy smějeme, že kluci tam raději polovinu kódu přepsali.

Pak jsme rychle přešli k Pythonu a Socialbakers. Tam jsem byl mnohem komfortnější.

Jsem velmi vděčný, že jsem měl štěstí na výzkumný tým, který byl malý – dva lidé, vedení mým současným šéfem Petrem Podružkem. Tam jsem dostal příležitost připojit se k nim.

V té době jsme začínali zavádět Spark a další analytické nástroje, Spark běžel na platformě Databricks. Myslím, že jsme byli jedni z prvních partnerů Databricks v Česku.

Petr to hodně řídil a já jsem díky zkušenostem ze Sparku v Monsteru pomáhal.

Začali jsme budovat tým, a tím i vše kolem.

Do té doby byla Socialbakers hodně analytickou firmou, ačkoli stále tvrdíme, že jsme best in class v analýze, ale strojového učení tam ještě moc nebylo, něco málo fungovalo a začínalo se to rozjíždět.

Byli jsme jako poměrně early adopters Databricks v roce 2018. Kluci měli připravené modely, které predikovaly úspěšnost příspěvků a optimalizovaly, kdy by se měly na sociálních sítích zveřejňovat.

Firma byla stále hodně zaměřena na inženýrství. Výzkumník, který chtěl připravit dataset pro trénování modelů, neměl k dispozici data lake či podobné nástroje, sbíral data přes produkční API, kde bylo nutné dávat pozor, aby nevytížil služby.

Takže říkáme, že člověk si napsal skript, nechal notebook běžet přes noc pod postelí a ráno měl třeba 20 tisíc řádků. Bylo to vtipné, ale dávalo se s tím pracovat.

Velmi rychle jsme však pochopili, že potřebujeme lepší infrastrukturu.

Začali jsme budovat data lake a potřebu data inženýrského týmu.

Získali jsme podporu napříč firmou.

V té době jsem měl štěstí, že jsem byl u začátku, když jsme škálovali výzkumný tým i týmy kolem něj.

Data inženýrský tým byl skvělý a spolupráce s ním fungovala výborně.

Když tě tu zastavím, bavíme se tedy o roce 2018. Jak velká byla firma Socialbakers, když jsi do ní nastupoval?

Už to nebyl startup, to určitě. Mělo to sice stále mnoho znaků startupu, zejména kultura v Plzni, kde byla část vývoje, ale počet zaměstnanců byl asi 300–400.

Sídlo mělo dvě patra ve Foru Karlín, kde náš CEO seděl v prosklené kanceláři a kdykoli měl otevřeno, mohl k němu kdokoli přijít něco probrat.

Bylo to stále velmi přátelské prostředí, lidé se znali, CEO věděl přesně, co kdo dělá.

Můj výzkumný tým byl výrazný navenek, měli jsme pravidelné dvoutýdenní schůzky s CEO a se šéfem produktového týmu, kde se intenzivně řešilo, co výzkum dělá.

Měl jste podporu a prioritu v této oblasti?

Bylo to hodně znát.

Občas byly náročné diskuze, ale vždy faktické a odvíjely se od obsahu – co a jak budeme dělat.

Podpora byla veliká jak pro výzkumný tým, tak pro týmy kolem něj.

Petr Podružek vybudoval datové týmy z několika desítek lidí na násobně větší počet.

Oproti mým začátkům jsme začali škálovat výzkumný tým, ale zároveň rostla i potřeba data inženýrů.

Data inženýrský tým měl potřeby i pro další týmy. Časem se ukázalo, že pro výzkumníky potřebujeme dedikovaný machine learning tým.

Ze data inženýringu se tedy vyčlenili 2–3 lidé, když se vytvořila samostatná…

[poznámka: text končí nedokončeně]

Pokud budete chtít, mohu text zpracovat i dále, případně upravit do formátu vhodného pro publikaci.

Uživatelský support tým nebo pomocný tým pro výzkum se staral o AI pipeline, zatímco data inženýři si ponechali standardní datové pipeline. Když se ještě v tomto bodě zastavím, co znamenalo postavit data lake? Znamenalo to přestat dělat věci nad podporou databáze? Částečně. Social Breakers nebo Amplify v té době zpracovávaly velké množství dat ze sociálních sítí, a to v řádu gigabajtů nebo spíše terabajtů, takže jsme potřebovali data někde ukládat.

Primárně jsme využívali Amazon, tedy AWS, konkrétně S3, a data inženýři na tom začali budovat tooling, který umožnil data do S3 dostávat a zpřístupnit je výzkumníkům. Velmi rychle se ukázalo, jak je to nesmírně komfortní. Pokud si vzpomenu na ty API a notebooky schované pod postelí, najednou jste si jednoduše lusknutím prstu mohli škálovat cluster.

V Sparku jste mohli přečíst miliardu příspěvků nebo komentářů od našich zákazníků a provést na nich určitou analytiku. Bylo to tedy velmi komfortní a dobře se s tím spolupracovalo. Jak jsme měli nové use cases, šlo je vyřešit s inženýry, kteří začali stahovat data a zpracovávat je, a výzkumníci se mohli plně věnovat výzkumu, nemuseli si tolik připravovat data ani řešit, kde je uložit. Bylo to opravdu pohodlné.

V té době jsem vás začal vnímat jako jakési centrum excelence pro data science, AI a machine learning. Spark byl možná silným přídavkem. Co mě baví, je, že na této tradici stavíte. Jaké byly první use cases? Jak jste to celé začali? Obecně byl primární cíl pracovat s nestrukturovanými daty ze sociálních sítí a dalších zdrojů a hledat v nich insighty pro naše zákazníky.

Typický zákazník v marketingu má tisíce či desítky tisíc komentářů pod svými příspěvky na sociálních sítích a není v silách jedince či dokonce týmu v tom mít přehled. Naše insighty tedy pomáhají určit sentiment i témata v komentářích, což pak klienti mohou dále využít.

Prvními klíčovými směry byly i modely na doporučení vhodného času pro zveřejnění příspěvků na sociálních sítích. Díky tomu, že máme data od klientů a známe vývoj jejich postů, můžeme s doporučováním pomoci. Byl to tedy hodně NLP přístup, protože firmami proteče velké množství textu, takže to bylo přirozené využití.

Klienti sledují, co jim kdo píše, jak komunikuje konkurence; my k tomu přidáváme to, co nazýváme enrichment flow – k příchozím komentářům přidáme informace o jazyku, sentimentu a další modely, které jsme vyvinuli.

Samozřejmě z těchto zdrojů přichází i obrazový obsah. Na obrazy je těch modelů méně, protože obsáhnout v takovém objemu data je složitější, přesto hledáme insighty i v obrázcích a videích. Stavíme moduly („krabičky“), které pak dokážeme navzájem propojit. Každý model má svou přesnost a použitelnost závisí na konkrétním use case.

Možná se vrátíme k tvé cestě – z řadového výzkumníka v týmu jste rostli, vznikaly další týmy: data engineering, podpora data science a tak dále. Jak jsi v tom osobně rostl?

Docela rychle, až na můj vkus příliš rychle a trochu nekomfortně. Zvykl jsem si z minulosti, že věci trvají, je třeba je řádně otestovat. Začali jsme první projekt a Petr Mužek mi řekl: „Vezmi si to na starost a rychle to uvolněte.“ Já jsem začal panikařit, protože jsem potřeboval QA a 14 dní testovat, ale ne, nebyl na to čas, neděláme software pro nemocnice nebo letadla, musí to být rychlé.

Nakonec to dopadlo, byť to bylo stresující. Petr pak přišel s nápadem, že bych si měl vzít tým na starost, protože v té době nebyl team lead. On to řídil napřímo, přestože měl další týmy. Velmi jsem chtěl, ale současně jsem těm klukům, kteří tam byli, vzhlížel a učil jsem se od nich mnoho. Musel jsem přijmout, že to přijmou, nebo ne. Doufám, že to dopadlo dobře a stal jsem se tehdy Head of Research, čímž jsme pokračovali dál.

Postupně se nám dařilo přesvědčovat firmu o smyslu našich aktivit a investic do nich. Založili jsme více týmů, v současnosti máme dva inovativní týmy – jeden strojového učení a jeden čerstvě software engineeringový, který pomáhá, aby celý departement byl relativně samostatnou jednotkou. Chceme urychlovat dodávky AI řešení, protože jak firma roste, začne se objevovat byrokracie, která věci zpomaluje. Moje motivace je tlačit věci vpřed co možná nejrychleji.

Petr je stále můj šéf a myslím si, že ostatní ředitelé v Amplify mají výborný tým, takže je možné se domluvit na mnohém. Jsem rád za ten progres.

Jak tedy komunikujete a domlouváte se? Od začátku byla podpora AI, machine learningu a data science, ale vy tomu říkáte innovations a research. Líbí se mi, jak tento pojem vyjadřuje smysl výzkumu a zároveň zaměření na inovace.

Přesně tak. Innovations tým nezastává pouze data science či machine learning, ale jeho poslání je doručovat inovace do produktu. Dnes to je hlavně AI, ale za pár let to být nemusí. Naším úkolem je přinášet nové a zajímavé věci, které řeší problémy. Pokud je to vyřešené knihovnou nebo pár řádky kódu, použijeme to, pokud velkou neuronovou sítí nebo LLM, tak také.

Za deset let to může být třeba quantum computing. Pokud mi bude hlava sloužit, přeškolím se na quantum computingového ředitele a budu vést svůj tým. Možná i zpět na JavaScript.

Zmiňuješ, že máte výborné ředitele, kteří chápou rychlost a styl fungování. To je hezké pro tak velkou firmu. Může ale nastat situace, že někdo bude tlačit zpomalení. Jak přitom prioritizujete, aby jste zůstali inovativní a ne pouze data science týmem? Jak se z modelů stávají inovace?

Trávíme 100 % času v úzkém kontaktu s produktem. Produkt nám přináší nápady a my mu doporučujeme řešení, protože známe technologie. Funguje to obousměrně a rychle prototypujeme, děláme POC.

Vytvořili jsme v produktu sekci „Labs“, kde jsme schopni rychle prezentovat projekty, které jsou v čistém Pythonu, abychom mohli dávat rychlou zpětnou vazbu bez čekání na QA nebo engineering.

Konkrétní příklad? Když se objevil GPT, na podzim před dvěma lety během 14 dnů jsme měli prototyp hotový a mohli jsme ho ukázat produktovému týmu. Reakce byla nadšená, i když pak Vánoce a jiné priority trochu oddálily produktové nasazení. Po dvou a půl třech měsících byl plně nasazen jako feature, přesto jsme byli mezi prvními na trhu. To bylo velké vítězství.

Někdy jsou POC datově náročnější a technicky složitější, vyžadují víc lidí a zdrojů, tam to někdy drhne.

Máte na to nějaký rámec nebo organizaci? Doporučil bys to někomu, kdo nás poslouchá?

Blízko k produktu, komunikovat a vyjasnit zadání. Často dostáváme velmi vágní zadání, 2 věty, a úkolem výzkumníka je zjistit skutečné potřeby produktu.

Je známé, že výzkumníci s dobrými soft skills, kteří umějí komunikovat se všemi stakeholdery – technickými i produktovými – posunou věci velmi efektivně.

Není to jen o tom být excelentním researcherem, ale i komunikačně schopným, schopným mluvit s produktovými manažery i s vývojáři. Proto se snažíme takové lidi najít a rozvíjet.

Historicky jsme měli pravidelné prezentace pro CEO a vedení firmy, což pomohlo. Mě moc těší, když výzkumník prezentuje své projekty sám celé firmě, i když někdy není úplně komfortní mluvit na velké publikum, ale je to pro něj velká satisfakce a pocit vlastnictví.

Chceme, aby lidé byli vlastníky svých projektů a viděli výsledky své práce i v produkci. Nejenže po dodání modelu je přebírají inženýři, ale je důležité, aby výzkumník zkontroloval funkčnost v produkci a ujišťoval se, že se predikce opravdu zobrazují správně v uživatelském rozhraní.

Díky tomu je vždy možné rychle zachytit možné chyby nebo problémy.

Lidé, které máme i hledáme, mají tyto soft skills. Ne každý musí být komunikativní, ale v našem businessu je to klíčové. Osamělí vlci dnes už moc nefungují, možná někde ano, ale ne v mainstreamu.

Vidím posun od starých dob IT – kodér, co dodá kód a skončí – k agilnímu, humans centered design produktových týmů a výzkumu. Je fajn vidět, že se to prosazuje i v datech a data science.

Ukazujete, že jste trendsettery, kteří učinili dobrá rozhodnutí. Nejdete přímo za každým trendem, ale aplikujete to tam, kde má smysl.

Určitě si umím představit firmy, kde není třeba takový přístup, mohou se soustředit na hardcore výzkum. U nás to tak nefunguje, protože portfolio projektů je velmi široké.

Potřebujeme, aby výzkumníci dokázali flexibilně přeskakovat mezi projekty, rychle dokončovat jeden model, zavést ho do produkce, sbírat zpětnou vazbu a mezitím pracovat na jiném.

Nemáme jeden jediný model, který by se neustále vylepšoval o malé procento dokola. Některé modely ano, protože mají smysl a hodnotu, ale většinou se musí rozhodnout, kolik času investovat a co zákazník ocení.

Podíváme-li se pod kapotu – AWS, mnoho věcí běží v cloudu, Databricks od roku 2018, Spark tam funguje. Výzkumníci používají Python, Python Spark, většina modelů se spravuje v MLflow frameworku, který balí modely, aby data inženýři nebo ML inženýři nemuseli řešit jejich vnitřnosti.

Dáváme si záležet, aby knihovny byly stabilní, aby se neobjevovaly chyby či problémy s udržováním. Výzkumníci mají svobodu používat technologii dle potřeby – PyTorch, TensorFlow, Keras – ale nakonec se modely balí do MLflow, což je standard.

Máme desítky modelů, které se trénují i samostatně pro různé zákazníky, takže celkový počet modelů může být vyšší. Většina je textových, ale přibývají i projekty s LLM, které jsou zatím dostupné přes API.

Jeden největší a nejpoužívanější model je sentimentální analýza, která se vyvíjela několik let. Dělá kolem 100 milionů predikcí denně. Pro takovou škálu je potřeba dedikovaný ML tým, který spravuje pipeline, protože výzkumníci to nemohou dělat sami celé.

Chtějí zkoumat, chtějí stavět ty nové modely, nechtějí mít povinnosti být 24 hodin denně a 7 dní v týdnu na telefonu, když se někde něco rozbije nebo když nějaká fronta přeteče. Takže tam to dává smysl.

A teď, když mluvíš o téhle škále, tak mi to také trochu vysvětluje, proč si ty věci stavíte sami. Kdybyste si kupovali nějaké out-of-the-box NLP, tak na tomhle množství požadavků to asi není stavěné na 100 milionů requestů. To by mohlo stát hodně peněz. To je pravděpodobně důvod, proč nemůžeme použít velký LLM úplně na všechno. My se to snažíme používat na vybrané use case a budeme to používat více, protože se to samozřejmě zlevňuje, ale také kvůli bezpečnosti a kvůli objemu nedokážu poslat 100 % z našich věcí na OpenAI, na GPT-3,5 nebo na Anthropic, to je celkově jedno.

Za prvé je to nezvládnutelné a extrémně drahé. Pokud se bavíme například o evoluci těch modelů, dá se to docela dobře ilustrovat na analýze sentimentu. Asi všichni ví, jak predikujeme, jestli je sentiment negativní, pozitivní nebo neutrální, alespoň takové bylo naše zadání. Ta první verze, která byla prakticky před šesti lety, byla velmi naivní, téměř pravidlově orientovaná. Existoval velký slovník slov, kde každé slovo mělo svoji polaritu do plusu nebo do mínusu, pak se vše sečetlo a vzniklo nějaké skóre. Když bylo pozitivní, znamenalo to pozitivní sentiment.

To fungovalo pouze v angličtině. A je to v pohodě, protože první use case byl, aby se neřešil sentiment na úrovni jednotlivých textů, ale aby nám byl poskytnut sentiment jako agregace. Když měl zákazník 10 000 komentářů a my jsme udělali agregaci, tak se ta chybovost tak trochu ztratila. Zákazník dokázal odhadnout, že například 30 % je negativních, 40 % pozitivních. To je nějaké moje standardní číslo. Pokud se model nezmění, může si to zítra zkontrolovat znovu a vidí, zda se něco nepokazilo. Samozřejmě to byla první verze a fungovalo to docela dobře, což pomohlo výzkumu.

Říkám tomu, že jsme si „strčili nohu do dveří“, protože jsme s tímto modelem odpilotovali integraci naší krabičky do celé té velké datové pipeline. V té chvíli už si model řešíme u sebe – engineering a zbytek firmy fungují podle toho, jak to potřebují. My pak můžeme model zlepšit o 5, 10 nebo 15 %, aniž by bylo potřeba dělat místo jiná řešení. Jakmile zákazníci začnou funkci používat, chtějí samozřejmě více, lepší podporu více jazyků. V současné době po několika letech to už není pravidlový systém, ale neuronka nebo neuronky postavené na transformeru. Podporujeme sto jazyků.

Aktuálně řešíme projekt customizace pro jednotlivé klienty, protože jak vnímají sentiment, je velmi subjektivní záležitost a každý zákazník to vnímá jinak. Zatím máme generický model, který se aplikuje na všechny texty, ale spousta zákazníků by chtěla mít svůj vlastní, vlastní definovaný sentiment. To je další stupeň evoluce. To přicházelo postupně s měnícími se use cases.

Z Social Bakersa jsme se změnili na Amplify, došlo k akvizici z Ameriky. Během posledních několika let jsme provedli akvizici dalších firem, které nám rozšířily segment od sociálního marketingu do oblasti customer care a e-commerce. Nyní máme tři velké pilíře a náš výzkumný tým pracuje napříč nimi. Byl to jeden z prvních týmů, ne-li úplně první, kde jsme dokázali integrovat lidi z akvizic. Výzkumníci z akvírovaných firem se spojili a my nyní řešíme věci pro commerce, pro care i pro marketing.

Jak se změnil přístup k time to market? Měl jsem pocit z tvého vyprávění, že je to hodně startupové v tom smyslu, že chcete rychle postavit, vyzkoušet, mít produkt živý, i když není úplně optimalizovaný, abyste věděli, jestli o to je zájem a jak to funguje na jedné i druhé straně. Promiň, že jde o specifickou produktovou funkci, ale už tam vidíš, že to nemá jen jeden use case, ale když by se to udělalo jinak, mohlo by se to zapojit i do jiných věcí.

Určitě. Pro mě je důležité začít velmi rychle sbírat zpětnou vazbu, protože nikdo není vševědoucí. Může se stát, že máme skvělého šéfa produktu, ale třeba všechno nefunguje nebo jak si to vymyslíme, nemusí spolu ladit. Takže ultimátní pravda je, jestli to zákazník používá. Proto je motivace začít být umělou inteligencí.

Vždycky neumí více jazyků, umí jen obrázky, neumí videa, ale pojďme to zkusit, jestli zákazník začne používat, v tom je hodnota. Pak se domény velmi liší. Marketing je trochu progresivnější, ale customer care je hodně konzervativní, má k tomu své důvody. Například v customer care je hodně právních věcí. Říkal jsem dnes lidem, že když přijdu jako marketér za souběžnými týmy a řeknu, že máme generativní AI na tvorbu postů, tak to pro ně je super a chtějí to. Ale když přijdu za týmem customer care, řeknou, že v podstatě nechtějí generovat nic, protože mají 20 let vypracované šablony schválené právníky a nechtějí posílat zákazníkům vygenerované odpovědi, které by model mohl „vymyslet“.

Je to tam jiné, ale obecně se snažíme všechny modely a API stavět tak, aby byly znovu použitelné kdekoliv. Takže to, co odpilotujeme v marketingu, protože tam je to nejrychlejší, jakmile to dává smysl, celý produkt ví, každý produktový manažer na danou funkci řekne: „Toto API je dostupné, máme model na překlad, začněte ho používat.“ Může nastat situace, kdy máte třetí stranu v produktu, můžete to zahoďte nebo otestovat náš model, napojit se na naše API a začít ho používat. Takto to tlačíme do celého produktu a docela to funguje. Time to market se liší, ale myslím, že to funguje.

Jaká je struktura týmu a jak ho řídíš? Jsou specialisté na domény, na přístupy, někdo dělá čistě NLP a jazyk a je v tom nejlepší, na něj padá všechno? Jak tým organizujete? Každý má své oblíbené oblasti, ale není chyba mít člověka, který řeší čistě computer vision. V innovation jsou teď dva čtyřčlenné týmy, každý team lead je zároveň architekt a kóduje. Nemáme dedikovaného manažera jen pro management týmu. Team lead je velmi angažovaný v procesu.

Domluvíme se, který tým si převezme úkol, připravíme roadmapu a musíme být agilní. Na lidech cením, že dokážeme říct, že se něco změnilo, že projekt musí počkat a začneme dělat něco jiného, protože má vyšší prioritu nebo něco jiného. Hodně pracujeme se sociálními sítěmi, asi všichni zaznamenali, co se dělo na Twitteru, spoustu změn. Musíme umět na to rychle reagovat.

Tyto změny se nás netýkají tolik jako týmů, které pracují přímo s API sociálních sítí, ale i my řešíme denní priority, Ať už je to TFI, hlavní téma na květen, nebo retence některých zákazníků, projekty se mění. Jsme v pohodě, výzkumníci jsou zvyklí, že ne všechno jde ihned do produkce, někdy je nápad v šuplíku nebo projekt vypálíme o rok dříve než bylo v plánu. K researchi to patří – fail fast.

To je to, co mě na tom baví. Můžeme si hrát, zkoušet nové věci, nikdo nám neříká, jak přesně to máme vyřešit, jen co chceme vyřešit. To je super. Už vás tedy pustím a pojďme se pustit do „slona v místnosti.“

Říkalo se, že v listopadu přišel GPT, to byl tehdy už? Jo, 3,5 Davinci. A během 13 dnů jste to měli v produkci, nebo během 13 dnů jste měli vyzkoušený nějaký prototyp? Co se od té doby stalo? Jak moc tohle změnilo věci? Tradiční machine learning, machine learning ops, hodně research, a jak vám do toho „hodila vidle“ revoluce?

Velmi hodně. Poslední rok spíše řešíme takzvané low hanging fruit, tedy věci jednoduché k implementaci. Hodně práce je s LLM a dodáním funkčnosti, která dříve nebyla možná. Necítím sentiment vůči starým modelům tak, že dřív, když člověk trénoval obrovskou neuronovou síť 14 dní a dnes stačí prompt, tak bych neměl staré modely používat. To by bylo hloupé, pokud nové fungují stejně dobře nebo lépe.

Teď je to hodně o promptování, což nemusí být úplně oblíbené, je to nový skill. Je to ale mnohem dostupnější i pro zbytek inženýrů. Určitě si nemyslím, že kdokoliv může dělat AI. Je potřeba si s tím hrát. Modely stále někdy lžou a lidé je používají i na věci, které předtím nebyly úplně v pořádku. Najde-li se dobrý use case a hraje se s tím, je proces mnohem rychlejší. Už není třeba stavět masivní datovou pipeline pro API.

Inženýrsky ale začneme řešit jiné věci. GPT někdy místo pozitivního nebo negativního sentimentu odpoví „necítím se v pohodě odpovědět na tuto otázku.“ Proto musí lidé řešit jiný styl práce s modelem. Nedokážeme poslat 100 milionů textů. Stále je třeba přemýšlet, jak to použít. Technologie je ale skvělá. Jestli je to do budoucna AGI, to úplně netvrdím.

Kam jste to zařadili do produktu? Kde vyloženě získalo místo? Hodně se nám to osvědčilo v části, kde se publikují příspěvky, kdy zákazníci si mohou připravit příspěvek, který půjde na sociální sítě, v sekci s kalendářem a plánováním. My jim pomáháme udělat rychle draft. Místo aby psali celý text, napíšou pár klíčových slov, frází, nastaví parametry, zda má být pozitivní, smutný, přidat hashtagy, emoji. My naservírujeme čtyři varianty, zákazník si vybere a dál s nimi pracuje – může parafrázovat, zkracovat, prodlužovat na jedno kliknutí.

Finální tlačítko pro publikování je ale na zákazníkovi. Vědí, že modely občas něco „vymyslí“. Takže rozhodnutí je vždy konečné na zákazníkovi. Toto celý proces značně urychluje.

Přidáváme další funkci, která kromě generování příspěvku podle zadání dokáže vytvořit příspěvek ve stylu firmy. Víme, jaké jsou historické posty na sociálních sítích, umíme vypodobnit jak formát, tak tón – velmi podobně. To je velmi žádaná funkce.

Postupně přidáváme drobné věci, kde používáme LLM, například „změň mi tón“, „udělej mi to kratší nebo delší“. Funguje to téměř kamkoli, kde zákazník pracuje s textem. To jsou pro nás dobré use case. Vidíme to i v mailových klientech a nyní i na sociálních sítích. Na posty to dává smysl.

Co pohání tyto modely? Když jsme začínali, byla OpenAI a GPT jedinou volbou, takže jsme do toho naskočili. Nyní je situace lepší. Z mnoha důvodů – jak jsem zmínil – jsme na AWS. Využíváme modely dostupné přes Amazon, protože Amazon hostuje modely od Meta, tam jsou LLaMY, modely od Mistralu, velké modely od Anthropicu. Pro nás je důležité, že data zůstanou na Amazonu, což je pro nás velké plus, hlavně u social care zákazníků, které slyšíme, že nechtějí posílat svá data cizím firmám.

Je výhodou mít všechno v AWS, ve stejném prostředí, je to transparentnější a bezpečnější. Jako velký zákazník AWS platíme hodně, takže máme lepší podporu i vůči modelům. Máme tam konzultanty a já se teď dopisuji s Anthropicem, protože zkoušíme něco s modelem Claude. Přijde mi to fajn – ne každý si může takové věci vyzkoušet, má někoho na druhé straně.

Dělali jste benchmarking, nebo jak vybíráte modely? Chápu, že bezpečnost a hosting na AWS je silný argument. Nejsem si jistý, jak je to s verzemi, jestli si můžeš provozovat starší verze levnější, nebo máš vždycky nejnovější dražší.

Ano, to je dobré téma. Hodně zápasíme s tím, že i když používáme stejné API, model se pod rukama mění, což není komfortní pro produkční využití. Někdy modely mění verze „pod pokličkou“. Není problém říct, že model za měsíc vypnout nebo nahrát nový, ale pak musíme model otestovat, protože se může chovat jinak. To je důležitá otázka, kterou hodně diskutujeme. Zatím nemáme rigogonózní framework, měli jsme menší workshop, kdy jsme testovali několik modelů na naše use case, ověřovali funkčnost promptů.

V budoucnu bychom se na to chtěli zaměřit lépe, ale protože promptování je stále částečně magie, je to pro výzkumníky někdy frustrující, když nemají matematický důkaz, jak to napsat, takže je to nekomfortní.

Děláte také nějakou QA? Ano, hodně věcí je manuálních. Máme soubor promptů a výsledků, které testujeme a validujeme. Někdy využíváme i jiné LLM na validaci. Musíte si s tím hrát, není to přímočaré, že byste dali všechno do GPT-4 a fungovalo to samo. Pomáhá to, ale inženýr musí práci udělat.

Jaký používáte LLM ops nástroje? Používáte například Langchain nebo další frameworky? Langchain zatím ne. Mám tyto knihovny rád pro experimentování, ukazují možnosti jako Langchain, Llama index a podobné. Ukazují, co j… (text končí).

Doufám, že to budu dělat správně, ale pak si říkám, že nepotřebuji knihovnu na exporty nebo importy z Google Drive, to přece umím napsat sám, nepotřebuji další závislost. Takže ty knihovny jsou super k tomu zjistit, co se s nimi všechno dá dělat.

Jinak zatím jsou přístupy přes API, která zůstávají v oblasti výzkumu, konkrétně u těch LLM. Nepoužívá je zatím náš tým ML Engineering, uvidíme, jak to bude do budoucna. Myslím si, že jak se bude navyšovat finanční náklad na LLM, přejdeme na nějaké 100% in-house modely, kdy poběží například LLaMA nebo Mistral přímo na našem hardwaru, v našem AVS, a pak už bude potřeba tým, který se o to bude starat.

Zatím je to na úrovni API, takže relativně v pohodě. Přidali jsme nějakou podporu, ale není potřeba do toho zatahovat ML Ops. A když mluvíš o těch in-house LLM, že si to budete hostovat sami, jaké je tam vlastně rozhodnutí, nebo jaká jsou pro a proti? Asi je tam cena, protože pokud to nastartuji, tak samozřejmě mluvíme o nějakých jednotkách tisíc dolarů měsíčně za hardware, takže se to musí vyplatit, nebo to někdo musí zaplatit.

Pak je tam ta lidská práce – musíme se postarat o to, aby model běžel, možná i dvakrát, protože potřebujeme vývojové a produkční prostředí. Když se někde něco zasekne, tak to někdo bude muset restartovat. To u API neřešíme, tam to řeší někdo za nás, my platíme za tokeny.

Když už máme model sami, můžeme ho používat, jak se nám zlíbí, a naložit do něj mnohem více provozu. Myslím si, že k tomu směřujeme. A stále mluvíme o generických modelech. Pak je tu spousta možností, jak modely vyladit na use case, které potřebujeme, na data našich zákazníků. To jsou podle mě věci do budoucna s LLM.

A to je vlastně moje další otázka, jak to napojení probíhá. Mluvil jsi o tone of voice, takže je to vlastně čistě inject promptu, že před tím máš nějakou analýzu, která je díky vašemu NLP dlouhodobě, například nějaký tone of voice, a ty mu to jen dáš do promptu?

Jak moc je to dynamické? Tone of voice se obecně moc nemění u firem, ale je pravda, že během roku něco vystřídají, jsou kampaně, Vánoce a podobně. My to proto přepočítáváme po nějaké době, ne každý den, spíše jednou týdně nebo měsíčně. Zanalizujeme nové příspěvky a z této analýzy vznikne nějaký textový popis tone of voice, může to být jedna stránka nebo několik odstavců. To si uložíme.

Takže pak to vypadá například: tone of voice této firmy je optimistický, používají takový a takový formát, hodně emoji a podobně. To si uložíme a aplikujeme na nově vygenerovaný text. Takhle to zatím řešíme.

Do budoucna tam asi bude další vývoj. Už teď vím, že někteří velcí zákazníci mají svůj brand style a tone of voice přímo popsaný v dokumentech. Nedávno jsme například od jednoho velkého zákazníka z cestovního ruchu dostali asi 20stránkový PDF dokument s tím, jak mají příspěvky na sociálních sítích vypadat.

To pak třeba dokážeme importovat, nebo jim to uděláme v rámci nějaké placené služby, protože jsou to velcí zákazníci, a vygenerujeme jim styl přímo pro nás.

Ještě někde, že jste na Machine Learning Prague měli workshop na Ragi? Měli jsme dva workshopy, oba se týkaly LLM. Ten, který zmiňuješ, byl na Ragi, a to bylo super. S kolegou Honzou jsme připravili takové intro do Ragi, něco málo jsme nakódovali, postupně jsme stavěli od úplně obyčejného Ragi, přidávali postupně několik funkcí.

Po těch čtyřech hodinách si myslím, že měli účastníci docela dobrý přehled, jak Ragi fungují. Podle zpětné vazby byl workshop vyprodaný, bylo tam dost otázek. Pak během dalších dvou dnů na konferenci nás na stánku lidé často zastavovali a ptali se, ať už jen proto, že řeší tu samou problematiku, děkovali, že jsme jim to potvrdili, což byl pro nás super feedback a sdílení znalostí, nebo že to chtějí řešit ve firmě a ptali se, na co si dát pozor.

Takže Ragi docela frčí, ale zase nejsou všemocnou zbraní.

Kde je máte nasazené u vás? V produktu už běží několik proof of concept s některými zákazníky, nebo budou běžet. Teď tam máme jedno Ragi, které běží v rámci produktu jako help.

Máme relativně velký tým, který dělá dokumentaci k našemu produktu, protože je to relativně velká věc. Všechny dokumentační stránky jsou nahrány jako knowledge do toho Ragi a slouží jako nápověda.

Pokud uživatel nenajde odpověď na svých stránkách, může se zeptat přímo přirozeným jazykem. My tomu říkáme Librarian.

Librarian chce říct OK (smích). Jo, to je za mě dobrý postup, protože je to dogfooding, jak se tomu říká – testujeme technologii interně.

Současně, pokud Librarian občas zahalucinuje, stále jde o dokumentaci, není to customer care, že by například řekl: „Hele, vypíjí lepidlo,“ nebo něco podobného, co je nyní běžné.

Postupně si můžeme toto vyladit. Ten Ragi je zatím asi non-answering, jedna otázka, jedna odpověď. Začínáme pracovat na konverzační verzi.

Paralelně řešíme několik projektů se zákazníky, kteří by chtěli model na svých datech. Je tam velký překryv se chatbotem, takže to bude určitě téma na příští měsíce.

Někteří lidé si myslí, že Ragi je všemocné a bude fungovat naprosto správně. Což tak není. Upřímně to nechápu, protože i u chatbotů se vždy řešila přesnost.

Možná to je tím, že Ragi umí odpovídat přirozeným jazykem, a i když někdy odpoví nesmyslně, zní to, jako by to bylo správně.

Určitě proto v odpovědi poskytujeme i odkazy na původní dokumentaci, aby si uživatel mohl informace ověřit. To je velmi důležité.

Ještě něco z workshopu? Kromě přidávání odkazů a nedůvěry k všespásným řešením, se mi líbí, že to většinou začíná jako výzkumná záležitost a pak do toho vstupují inženýři, kteří vše ladí.

A to je super, protože obyčejný Ragi je semantické vyhledávání a NLG komponenta. Už to lze dělat fulltextově i semanticky a kombinovat. Pak vymýšlíš chytré způsoby slučování těchto výsledků.

Je tam spousta zajímavých inženýrských výzev, na kterých lze pracovat téměř nekonečně.

Takže Ragi jsou podle mě skvělé. Práce na nich nikdy nekončí, což je jejich přednost.

A co vás čeká v researchi nyní? Předpokládám, že hodně LLM, vlna stále pokračuje. Co je tedy na obzoru?

Budeme pokračovat s LLM, to určitě. Ale doufám, že se to začne trochu měnit, že opadne ten jednoduchý hype a projekty se začnou komplikovat. To by bylo fajn.

Máme mnoho projektů napříč různými vertikálami. Vypadá to, že se budeme více zaměřovat na některé segmenty, například sportovní firmy.

Čekám v brzké době i projekty zaměřené na obrázky, což bude super.

Také si myslím, že se musíme začít víc soustředit na velké zákazníky, především v segmentu customer care, kteří mají jiné požadavky. Tím směrem se budeme posouvat.

Je toho opravdu hodně. Potřeboval bych další několik týmů.

A ani jsme vlastně nezmínili, nebo jen lehce se dotkli, že máme nyní dedikovaný engineeringový tým, který nám pomáhá s funkcemi.

Po prvním měsíci už jsem si říkal, že bych potřeboval ještě jeden, možná dva nebo tři další.

Takže je prostor pro nové lidi do Amplify.

Doufám, že na ně vyděláme, ale když vezmu jen sebe a šéfa produktu, máme tolik nápadů, stejně jako zbytek týmu, takže nápadů je opravdu hodně, co řešit.

Držím moc palce, ať se vám podaří projekt rozběhnout, získat na něj rozpočet a priority.

A pro posluchače – děkuji moc.

Přeji jim, aby více sledovali Amplify. Myslím si, že pozornost od vás trochu upadla.

Lovebrand Social Bakers je teď v podstatě Amplify, ale já osobně tam stále vidím, že děláte práci na globální úrovni a v prvotřídní kvalitě.

Takže držím palce.

Machine Learning Prague je podle mě také ukázkou excelence, že tam stále držíte vysokou úroveň.

Moc držím palce.

Díky moc a kdykoli nás někdo potká, ať se zastaví, rádi zjistíme, jak to dělají jinde, a něco se přiučíme.

Díky moc za pozvání.

Díky.

A to je všechno. Děkujeme, že jste poslouchali až sem.

Děkujeme také našim partnerům: Big Hubu, Intexu, Sazce, Bystreetu, Colors of Data, Revolt BI, Good Data, Kebuli, E-marku.

Pokud vás zajímá více, navštivte naše stránky datatalk.cz a přihlaste se k odběru našeho newsletteru.