Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datotalk.
Mým dnešním hostem je Kuba Švec, Python data engineer, nebo někdy také AI engineer v dnešní hantýrce, ze společnosti Carl Data Company. Ahoj, Kubo.
Ahoj, Jirko.

Dneska se s Kubou podíváme dost trefně do toho IP, do toho, co pohání aplikace od Karla, a to je umělá inteligence, velké jazykové modely, anebo v tomto kontextu spíš multimodální modely, protože často jde o obrazové informace. Podíváme se na nějaké lessons-learned, na slepé cesty a na to, na co si dát pozor, pokud něco takového chcete stavět a produktivizovat.
Řekneme si také, jak monitorovat tyto systémy, a myslím, že dostanete i dobré tipy — pokud jste v Google steku — na různé tricks a způsoby, jak pracovat s těmi modely.

Než půjdeme přímo do středu Karla, tak se podívejme na tvou historii, protože ta cesta je super zajímavá a myslím, že se projevuje i v tom, co děláš.
Jak to u tebe začalo? Jak ses dostal k datům, k Pythonu a k AI?

Já to zkusím vzít hodně stručně. Na střední škole jsem byl strojař, potom jsem na vysoké škole přešel do softwarového oboru a dělal bakaláře na sociální antropologii. Měl jsem zaměření na dokumentaristiku — natáčení dokumentů, jejich střih a tak dál.

Mohli jsme od tebe něco vidět?
Vlastně jsme měli krátký šort jednou na Očku. Byla tam kdysi soutěž krátkých filmů, pochybuji ale, že jste to zahlédli. Byl to žánr detektivka, jednoměsíční vítězství. Každopádně to nepatřilo ke studiu. Tam jsem točil o tom, jak se lidé chovají ke zvířatům — to byla moje bakalářka.

Magistra jsem už měl čistou antropologii, zabýval jsem se lidským vnímáním a hlavně mě zajímalo, jak moc jazyk, který používáme, ovlivňuje naše vnímání světa. To byla moje diplomová práce.
Po škole jsem se krátce věnoval natáčení, ale pak přišel covid, nic se točit nemohlo, byly různé restrikce. Takže jsem hledal obor, který by byl úplně agnostický vůči případným budoucím vlnám, a tak jsem došel k tomu, že zkusím programování. Našel jsem si Python, kterému jsem se sám učil zhruba půl roku. Po půl roce jsem byl přijat do Prahy, do Holešovic, do Sience, kde se Kuba Šiler chystal stavět tým datové žurnalistiky.

Můžu se ještě zeptat, jak jsi naučil Python za půl roku a jaký jsi tehdy měl level? Dnes zpětně, udělal bys to jinak? A pokud nás poslouchá někdo, kdo je třeba v datech na SQL a chtěl by se vrhnout do Pythonu — jak by měl začít? Vstupoval jsi tenkrát do programování s nulovými znalostmi, nebo díky strojárně měl jsi aspoň nějaké programátorské myšlení?

Na strojárenství byla aspoň základní logika postupných kroků a jak něco předat stroji, ale nedá se to srovnat s žádným jazykem, který používáme. Takže do Pythonu jsem šel skoro úplně nasucho, s tabulí prakticky prázdnou.

A jestli bych něco změnil? Asi každý, kdo se chce učit programovací jazyk, ...

Text jsem upravil pro lepší čitelnost, správnou gramatiku a plynulost. Pokud chcete, mohu pokračovat v opravě i další části, stačí říct.

Tak začnu tím, že si člověk začne dělat nějaké kurzy – buď si nějaký zaplatí, nebo sleduje YouTube, nebo něco čte. Já jsem měl tu cestu, že jsem si přečetl pár knížek a studoval nějaké tutoriály od anglických, respektive amerických YouTuberů, kteří to učili. Co bych rozhodně doporučil, je nepříliš dlouho se točit kolem nějaké teorie a učení se, ale co nejdřív si zkusit vlastní projekt, byť malý, zkusit napsat krátký, stručný program, jakkoliv jednoduchý, a iterovat nad tímto, protože můžu klidně pak rok číst o tom, jak se v Pythonu má ideálně programovat, můžu číst o objektově orientovaném programování a o různých složitostech, ale podle mě nemá cenu, dokud člověk nezačne psát ty řádky kódu, nezačne debuggovat kód, nezačne mu to házet error hlášky a tak dále. Takže co nejdřív se do toho pustit.

Tak pojďme do toho. Zase klobouk dolů, že tě takhle Kuba vytáhl – antropologa, filmaře. Před půl rokem jsi začal s Pythonem, s jakou rolí a myšlenkou si vstupoval do CNC?

Takže stavěli jste celé BIko. Já když jsem tam přicházel, tak to BIko už nějakým způsobem existovalo. Jestli to říkám dobře, tak fungovalo zhruba rok. Kuba Schiller měl vizi, že tak velký mediální dům, jako je ČEQ News Center, by měl mít nějaký dedikovaný tým datové žurnalistiky, protože do té doby, když už redakce dělala nějakou infografiku, tak si ji drátovali na koleně po svém. Takže byla potřeba to vůbec nějak centralizovat. Za prvé. Za druhé tam byl i nějaký byznysový potenciál, protože Kuba předpokládal, a asi nejen on, že pokud má článek nějaký vizuál, například infografiku, ideálně interaktivní, tak na ní čtenář déle zůstane, prokliká si to a tak.

Naším úkolem tedy bylo to centralizovat, udělat něco, co bude zastřešovat celé CNC, co se týče infografik a datové žurnalistiky, dodávat to napříč redakcemi, vyrábět nějaké automatizované grafiky a samozřejmě také zajistit, aby redakce mohla kdykoliv ze svých specifických potřeb si takové infografiky sama vyrobit – tedy nějakou demokratizaci přístupu.

Ohledně přijímání lidí musím zmínit, že Kuba Schiller má výborný čich na lidi, kolikrát raději vezme člověka s méně zkušenostmi, ale hlavně hledá lidský fit do týmu, chce, aby tam fungovala dobrá chemie, a chce vidět, že ten člověk má zájem učit se daný stack a řešit problémy. To, jestli mu k tomu ještě něco chybí, už pro něj většinou není takový problém. To ti hrálo do karet.

Co tedy byla tvoje role? V tu chvíli jsi byl Python vývojář, nebo jaký tam byl stack? Co jste vlastně dělali? Automatizovali infografiky? Dělali datovou žurnalistiku obecně?

Konkrétně moje pozice byla pravděpodobně datový žurnalista. V týmu jsme byli tři lidi. Začátek spočíval v příchodu s nějakým řešením – vyřešit, jaký software využívat, v jakém softwaru budou infografiky embedovány do článků, co bude běžet na pozadí...

Tady je opravený text:

Buď se takové vizuály můžou vytvářet jako klikačka, nebo když to chce někdo mít automatizované, musíme programově na všechny ty cesty přijít. Tenkrát jsme zvolili Infogram, zároveň se už v rámci BIka používala Keboola, takže to nebyla naše volba, ale backend, tedy místo, kde běhaly ty kódy, byl v Keboolě.

Můžu říct, že se časem opravdu potvrdilo, že ty články zvyšují čas, jak dlouho čtenář zůstane na článku. Už si nepamatuju přesné číslo, jestli to bylo třeba dvojnásobný čas, každopádně to bylo dostatečné na to, aby datová žurnalistika mohla za prvé přežít jako tým, a hlavně aby se z vrchu víc tlačilo na integraci těchto procesů.

První rok jsme zaváděli procesy, kolem druhého roku jsem převzal vedení mikrotýmu a po dalších dvou letech jsem CNC opouštěl a vedení předal Aleši Ligasovi. Tým tedy pokračuje, datová žurnalistika v CNC dál funguje.

A ty jsi odešel zase za Kubou?
Ano, odešel jsem za Kubou, protože rok předtím, než jsem odešel ze CNC, Kuba přišel z Vize, respektive už tam pravděpodobně delší dobu nosil vizi, že chce stavět aplikaci. Chtěl využít veškeré znalosti, které měl on i kolegové kolem něj – znalosti z Kantaru, Seznamu a mediálního světa obecně. Chtěli vytvořit aplikaci, která bude buddy pro influencery.

Chtěl zkombinovat to, že má tým lidí s odbornými znalostmi z mediálního světa a sociálních sítí, a zároveň možnost složit silný technický tým. Takhle zhruba vznikal Karl. Nejprve odešla část mých kolegů z CNC v čele s Kubou, založili Karl a do roka mě Kuba přetahoval do toho nového týmu.

Pro ty, kteří to ještě neslyšeli, doporučuji epizodu s Kubou Schillerem, kde o celém přerodu, i o tom, co jsme v CNC stavěli, mluví podrobněji. Můžeš teď popsat, co je Karl teď? Jaká je genéza a propozice firmy? Jaké jsou produkty k létu 2025?

Náš core produkt je aplikace na iOS, která funguje jako B2C. Je to aplikace pro influencery, kterou si stáhnou, přihlásí své sítě a začnou dostávat určité insajty. My data zpracujeme, zjistíme, které příspěvky a jaké typy postů mají lepší dosah a sentiment. Na základě toho uživatel dostává doporučení, jaké typy postů tvořit a kterým se vyhnout.

Druhá rovina je B2B, která funguje už delší dobu. Máme webové rozhraní. Obecně to jde s tím, jak se čím dál větší množství kapacit...

Pokud chceš, mohu pokračovat v opravě i dalších částí textu.

Zde je opravený text:

Firmy přesouvají svůj rozpočet z klasické reklamy do toho, že platí influencerům za určitou propagaci své značky nebo nějakého produktu. Problém obecně byl v tom, jak takové kampaně měřit. Hashtag spolupráce. Přesně tak. My jsme naráželi, jednoduše řečeno, i na to, že když taková kampaň probíhala, firma si třeba vzala Google Sheet a vyplnila počet zhlédnutí (views) a počet lajků. Prostě ten influencer, který měl víc zhlédnutí, vycházel lépe.

My jsme do toho zakomponovali AI analýzy, díky kterým například víme, v jakých časech se o dané značce nebo produktu mluví. Například když někdo měl milion zhlédnutí, ale značka byla zmíněna až na konci videa, věděli jsme na základě tvrdých čísel, že ke konci videa už bylo sledovatelů třeba jen 50 tisíc. Naopak někdo, kdo měl celkem 100 tisíc zhlédnutí, ale zmínil značku hned na začátku videa, mohl mít plnou dosledovanost těch 100 tisíc. Tohle nám umožnilo kombinovat nějakou softwarovou analýzu, kterou provádí AI. Ta se podívá na video, ví, co se v něm děje, a my to zkombinujeme s tvrdými metrikami. Firmy na takovéto data hodně slyší, a to je ta druhá větev.

V posledních měsících se nám tyto dvě větve velmi dobře spojily díky Collab Centru. Je to místo, kde se B2C a B2B větev propojují. Influenceri se tam mohou hlásit, pokud mají zájem o nějakou spolupráci, a firmy zase vidí, kdo se jim hlásí, nebo mohou sami aktivně hledat ideálního influencera pro propagaci své značky. Vidí, na jaké oblasti se jednotliví influenceři zaměřují, jaké pravděpodobně mají publikum a podobně. Zároveň chceme udělat prostředí pro influencery transparentnější, protože doteď to bylo takové prostředí, kde influencer často nevěděl, jakou cenu za spolupráci říct. Proto tam vnášíme prvek větší transparentnosti.

Máme zároveň ještě consulting, ale tím už je to více méně uzavřené. Dříve, ještě před rokem, byl Karl hodně rozkročený. Teď se nám to konečně sjednotilo. Dřív jsme měli zvlášť aplikaci, zvlášť business, zvlášť consulting a ještě Karl for Media, který se aktuálně uzavírá. Viděli jsme potenciál ve všem, ale bylo to dlouhodobě neudržitelné. Bylo jasné, že jednoho dne budeme muset odříznout nerentabilní větve, potvrdit si teorie a hypotézy a zaměřit se na ně. Pro mě to dávalo smysl právě s Collab Centrem, kde jsme dokázali spojit B2C a B2B.

Náš fokus do té doby byl hodně rozptýlený a to nám historicky způsobovalo problémy. Je potřeba celý široký tým, který dnes čítá asi 30 lidí, soustředit a koncentrovat na jeden zastřešující produkt. Než ř... (text končí neúplně)

Zde je opravený text s odstraněním gramatických chyb a stylistickou úpravou:

Řekněme, že lítat od jedné větve ke druhé. Já jsem to tam vlastně viděl tak, že jste jako rozstřelení. Chápal jsem, že hledáte správnou aplikaci toho vašeho know-how. Ta B2B větev mi přišla zajímavá nebo logická z toho pohledu, že se tam rychleji dostanou peníze, než když se budete rozšiřovat jako škála influencerů. B2C je jiná hra a potřebuje širší škálu. A B2B? Když budeš mít tři dobré klienty, kteří mají spoustu kampaní... Plus tam bylo něco, o čem mluvil nevím jestli Kuba nebo jiný tvůj kolega, že vlastně šlo o dobrou kampaň na adopci. Díky tomu, že jste měli první značky, které chtěly Karlá jako platformu pro spolupráci s influencery, tak influenceri museli Karlá vyzkoušet pro účely té kampaně. A díky tomu zjistili, že jim to vyhovuje a že to funguje i nad rámec nějakého povinného reportingu svému chlebodárci. Takže tam jsem viděl, že ano, že to sice je rozstřelené, ale synergické efekty jsou veliké, takže teď to konsolidujete do jedné aplikace, do jedné platformy.

Je to tak? Díky, Jirko, to jsem zapomněl dodat, že opravdu v rámci těch byznysů, abychom těm klientům dokázali nějak dobře změřit kampaň, bylo nutné, aby ti influenceři byli napojeni na tu aplikaci. Takže tam už takové návaznosti dřív byly. Roadmapa logicky je na mnoho let dopředu, takže nějaké myšlenky tím směrem už tam různě mohly být, ale konečně jsme se dostali do takového technického stavu, že jsme to dokázali propojit. Pořád je to sice pro byznysové uživatele webové rozhraní a ta aplikace je určená primárně influencerům, ale celý stack a prostředí se kolem té aplikace obalují čím dál těsněji.

Tak se pojďme podívat na ten stack a na platformu. Zase se asi odhlédneme od webového rozhraní na jedné straně a iOS aplikace na straně druhé. Když tam není nic zajímavého ve frontendu, tak to je nějaký vývoj. Ale když se podíváme dovnitř, na architekturu, jak tečou data, jak do pipeline, můžeš nás s tím provést? Těším se, až se dostaneme k té LLM části, ale když vezmeš třeba výstup z mé instagramové kampaně – napojíš se na můj Instagram – co všechno z mého účtu vytáhneš? Co vlastně Instagram nebo YouTube nabízí a jak s tím dál pracujete, jak tečou ta data?

Já přemýšlím, možná to vezmu i víc high-level, jak jsme vlastně poskládaní. Před rokem, když jsem nastupoval do Karla...

Když jsem nastupoval do Karla, tak se mnou nastupoval i Tomáš Strejček, náš CTO. Musím říct, že nastupoval tak říkajíc za pět dvanáct, protože jsme byli chvíli před releasem. Ale do té doby, než přišel Tomáš, tu aplikaci vytvářela externí konzultační firma. A řekněme, že to nebylo úplně připravené na release – fungovalo to, ale neudrželo to škálu. Takže kdyby tu aplikaci používali třeba tři uživatelé, tak by to bylo v pohodě, ale pokud jich chtěli víc, tak to nebylo úplně dobré. Takže dost důležitým bodem bylo, že přišel...

Pokud budete potřebovat pokračování nebo další úpravy, dejte vědět.

Jistě, zde je opravený text:

Tomáš Strejček začal potom hodně tlačit a postavil vlastní vývojový tým, a tak se začaly technické dluhy velmi intenzivně napravovat. To je tedy, co se týká back-endu.

Co se týče naší AI, ta je zasazená v datové vrstvě, kterou má na starosti Vojta Říha. Musím říct, že je velký mág v oblasti dat – jeden z nejlepších lidí na SQL v Česku. Jeho procedury v GCP mají 300 řádků a někdy i víc, což pro mě znamená bolest hlavy. Raději je nečtu, protože SQL mě zase až tak moc nebaví. Víc s nimi musím operovat, takže se mu tam snažím vyhýbat, kde to jde.

Chtěl bych tady ještě zmínit Vojtu Říhu, který je opravdu mistr ve stavbě datových pipeline. Uprostřed těchto datových pipeline máme krabičku s AI, která zpracovává a analyzuje fotky nebo videa. Takže, Jirko, kdybys se přihlásil do naší aplikace, my bychom vlastně analyzovali tvůj Instagram – zkoumali bychom, jaké tam máš fotky, jaké popisy, případně jaká videa.

Ke každé fotce nebo videu vytáhneme přibližně 40 různých metrik – zjistíme, jaký má příspěvek sentiment, co se na něm děje, jestli jde o video, převedeme řeč na text včetně časových značek, zjistíme jazyk, barvy, a také třeba cílovou skupinu. AI modely například odhadnou, jestli daný post cílí na uživatele kolem 20 nebo 40 let, případně na konkrétní gender. Dále určí emoce, objekty na obrázku apod.

Jak říkám, těch kategorií je zhruba 40. Ale to už je věc AI krabičky, která na základě těchto tagů tvoří vaši Magic Box a příslušný model.

Předtím, než se podíváme blíže na tohle, co všechno vlastně Instax poskytuje? Instax ti přes API pošle statistiky – například počty zobrazení a další data. Co přesně ví, předpokládám, že se do detailů nebudu pouštět, protože je to čistě backendová záležitost. Samozřejmě existuje několik druhů API a používáme také Apify, takže přístupů je víc. K detailům se ale moc vyjadřovat nebudu, protože je to opravdu technická oblast.

Tvoje vstupy jsou tedy fotky a videa. Já pak potřebuji mít všechna data dostupná v nějakém vhodném formátu. Už máme k dispozici vše, co potřebujeme, a není to zodpovědnost datového týmu, abychom se vůbec dostali k potřebným souborům a datům. To je celé na backendu, který je nutné nakrmit datovou pipeline.

A protože pracujete v GCP, tak se všechna data rovnou ukládají do databáze BigQuery nebo něčeho podobného? Ano, jsme silně orientováni na GCP. Dříve, když začínal Karel, vedly se u nás technické spory. Jeden názor preferoval Kebolu, jiný GCP. S ohledem na naše současné potřeby, které jsou hodně vývojové a hodně programujeme, jsme se nakonec rozhodli pro...

Jestli chceš, mohu opravit i pokračování, pošli ho.

Jistě, tady je opravený text:

Rostvě. Tak díky bohu, že vyhrála ta větev toho GCP, která vlastně umožňuje pracovat na té nižší úrovni s těmi věcmi. I když CNC byla super, pro naše potřeby by to nebylo dobré řešení.

Co je tedy vstupem? Co ti vstupuje do vašeho blackboxu AI?

Jste v GCP, GCP pri Vailed, hodně si toho píšete sami, tak teď se pojďme podívat na tu magii a jak vznikly třeba černé krabičky, jak stavět černé krabičky. Ale zase asi pro kontext, i to, co jsem zmiňoval, že ne jen jazykové, ale multimodální medley, že zpracováváte zejména obraz.

Co už jsi začal ty kategorie, tak pro tebe jsou tedy vstupem videa a fotky.

Ano, vlastně to je to zásadní. Potřebujeme do toho modelu dostat videa a fotky, které máme analyzovat, případně ještě nějaký caption, to znamená, co je u toho příspěvku napsáno, a pak už to jsou většinou jen nějaké IDčka a další párovací věci.

Alfa a omega je ten soubor jako takový, který potřebujeme analyzovat, a na základě této analýzy teprve vznikne široká granularita toho, co se dozvíme o každém souboru. A tady ty data pak můžeme různě dál párovat, využívat.

Takže ty dostaneš dvouminutové video, víš, že to video vidělo milion lidí, a co řešíš pak? Jak to funguje?

Vlastně tu statistiku už já taky neřeším, jak jsem říkal. To je něco, co se potom spáruje, ale nevstupuje ti to do toho modelu.

Ano, přesně tak. Jak je zavěšená ta krabička s tím AI v datové pavučině, my máme to opravdu co nejvíce modulární. Cílem té krabičky je dostat se k softwarové analýze.

Takže to, co se děje dál s výsledky té softwarové analýzy a párování na tvrdé metriky, to už se děje v té pavučině datových trubek. Říkejme tomu data mesh.

Říkejme tomu data mesh.

No, v té pavučině.

Tak super, pojďme se vrátit k tomu, co všechno tedy vytahujete. Začal jsi říkat, že tam je nějaký sentiment, barvy, nějaké object recognition.

Pojď mě projít čtyřicet kategorií, jak je to možné, že jich je tolik? Co všechno řešíte?

Obecně náš prompt má asi 40 stran A4, máme zvlášť prompt na fotky a videa, zhruba po 20 stranách A4. V základu jsou to hlavně věci jako vůbec popis, co se na fotce nebo videu děje, nějak zkráceně, protože to se třeba používá do insightu ve smyslu, že vidíme, že tady na fotce, kde si někdo hraje s kočkou, se děje to a to. Takže vůbec takové věci, které se dají použít k personalizaci, aby uživatel věděl, že nepřistupujeme k té fotce jako ke kterékoliv jiné, ale že tam je něco osobního.

Takže tady tím to začíná.

Pak jsou tam důležité věci, jako nějaká kategorizace, pod co to patří – jestli je to sport, fitness, ale každá kategorie má ještě subkategorie, což nám zase umožňuje dál si data různě propojovat.

Jak už jsem říkal, je tam nějaký gender, věk, jestli se jedná o nějakou spolupráci, jestli post vykazuje známky toho, že je nějakým způsobem...

Pokud budete chtít, mohu text dále upravit nebo rozšířit.

Jasně, tady je opravený a upravený text:

Reklamní videa mají integrovaný speech-to-text přepis a navíc jsou zde různé kategorie, které vyhodnocují, zda je post a jeho popisek (caption) vůči sobě relevantní. Upřímně řečeno, do dneška se v návazné datové pipeline využívá z těch kategorií přibližně jen deset. Zbytek, tedy zhruba 30 kategorií, zatím jen skladujeme a čekáme, zda se v budoucnu budou nějak využívat.

Klíčové jsou určitě přepisy toho, co se ve videích říká (speech-to-text). Ty se využívají zejména v byznysové větvi, protože tam je kategorií ještě mnohem více. Když totiž přijde businessový klient, například B2B, který má zájem o svou kampaň, nemůžeme mu dát jen základní prompt — to by nestačilo. Klienta zajímá mnohem víc. Může přijít s požadavkem, jestli se v obsahu objeví jeho značka, například Google, pokud jde o Google, případně konkrétní produkty nebo služby.

Takže tam už jde o customizaci, kde si klient může zadat konkrétní brandy, produkty nebo i prodejní argumenty. To znamená, že model musí vracet konkrétní prodejní argumenty, které si klient předem nadefinuje. Například nemusí vůbec padnout přímo zmínka o logu, ale podstatné je, že třeba influencer mluví o výhodách nebo kvalitě dané služby. Model tedy vrací tyto zadané prodejní argumenty.

Proč je těch kategorií 34? Proč není zpracování sekvenční? Je to tedy single shot přístup — pro každý vstup pošlete jeden prompt a dostanete zpět výsledky ze všech 40 kategorií. Proč je prompt tak dlouhý a co v něm vlastně je? To je dobrá otázka. Samozřejmě by to mohl být i nějaký chain, který by z určitých pohledů mohl být lepší. Ale upřímně řečeno, před rokem, když jsme byli na začátku s byznysovými větvemi, respektive když jsem přišel, byly multimodální modely ještě méně vyspělé — měly o něco lehčí úkol než současné, které musí například rozeznávat pixely, což je u videa ještě složitější.

Navíc ty modely v té době ještě nebyly tak dobré. Byznysová větev u nás tehdy fungovala tak, že jsme používali existující machine learning modely od Googlu — zvlášť model na object detection, zvlášť na speech-to-text, případně další modely (což už není podstatné). Všechno se muselo zvlášť zpracovat, pospojovat a vyčistit, což bylo upřímně řečeno docela náročné.

Tedy zpočátku naše řešení bylo založené hlavně na tradičních machine learning modelech od Googlu, které převáděly video na text a příslušné jazykové části pak zpracovával čistě jazykový model s těmito textovými vstupy. V době, o které mluvím, šlo tedy o čistý machine learning, ke kterému jsme programově kombinovali výstupy z více ML modelů, aby se vytvořil výsledný produkt.

Když pak přišly modely, které už zvládaly všechny tyto úkoly samy, tedy že nepotřebovaly samostatný speech-to-text model a zpracování obrazu zvlášť, mohli jsme celý proces výrazně zjednodušit.

Pokud chceš, můžu ti pomoci i s úpravou do formálnějšího či jiného stylu, dej vědět.

Tady je opravený text s úpravami v interpunkci, stylistice a gramatice, aby byl plynulejší a srozumitelnější:

Zvlášť u machine learningu a object detectionu, ale už to začal model všechno zvládat sám, tak jsme dali přednost tomu dělat to single shot, jak říkáš. Mít vlastně jedinou závislost, jediný nestabilní prvek v tom procesu, tedy jediný nestabilní prvek, který může selhat – prostě ten jeden API call. Nezáviset tak na nějakých dalších deseti, pročítat různé dokumentace, ale čistě využívat modely od Google, Gemini, a mezi nimi pak můžeme prohazovat už jenom verze těch modelů. Takto to máme aktuálně postavené. Samozřejmě uvidíme do budoucna, jestli to vzhledem k produktovým potřebám nějak nezměníme nebo nepřestavíme, ale teď je to takhle.

Ty API volání jsou samozřejmě paralelní, takže se na každý post provádí souběžně třeba několik desítek callů. Když se ještě zastavím u promptu – chápu ten single shot přístup, že máš jeden point of contact a že tam řešíš nějakou kombinaci promptu a modelu, což je ta komplexita. Takže když zůstanu u toho promptu, jsou nějaké věci, které jste se naučili „hard way“? Typický prompt bývá asi v angličtině, předpokládám kvůli tokenům, obsahuje základní definice, co má dělat, ukázky, tedy examples. Jsou ještě nějaké další lessons learned, třeba když stavím prompt takhle...

Důležitý je střední prompt, na co si dát pozor a jak to udělat správně? Prompt je v angličtině, ale je tam několik zajímavých aspektů. Co se týče příkladů, ty model dostává – máme různé typy příkladů. U toho business promptu je navíc zajímavé, že se dynamicky mění podle toho, co klient zadává. Když zadá různé brandy nebo USP, model dostává ty příklady přímo nad těmi konkrétními USP, aby ho to nemátlo. Aby tam například nebylo, že klient hledá loga Google, Microsoft, a my tam staticky máme jiné příklady. Takže prompt se dokáže dynamicky měnit podle momentálních potřeb.

Zároveň jsme si v průběhu času všimli, jak je velmi důležité, v jakém pořadí ty promptové kategorie skládáme za sebe. Model totiž dokáže udržovat kontext, což znamená, že se neroztřeluje a nevyvrací napříč kategoriemi. Například pokud jedna kategorie odpoví, že na obrázku je logo, tak další kategorie, která se ptá na lokaci toho loga, odpoví přesně ty pozice a nepopře to. Tohle je typické pro každou kategorii, že model udržuje kontext. Proto je velmi důležité, které otázky jsou první, druhé, a tak dále.

Je ten prompt dlouhý 30 nebo 40 A4? Je to váš „recept na Coca-Colu“? Anebo je to jen část? Když to takhle shrnu, tak ten, kdo by to stavěl, se hodně inspiruje a hodně mu to pomůže, možná narazí i na nějaké slepé uličky. Ale vlastně tam magie není zas tak v promptu – ta magie je spíš v produktu, softwareovém inženýrství a v dané doméně.

Pokud chceš, můžu pomoci i s dalšími úpravami nebo rozpracovat konkrétní části.

Zde je opravená verze textu:

ové znalosti a další. Myslím, že ten prompt je určitě hodně důležitý, přece jenom už se mu věnovalo dost času a iterovalo nad ním víc lidí, takže je to částečně určitý recept. Má v sobě IP, ano, určitě. Má tam už nějaké prvky, nezapomeňme dát odkaz na prompt do popisku, chápu. Na druhou stranu je Kuba dost často otevřený sdílení technologických know-how, takže třeba by mu to ani nevadilo.

Každopádně se vrátím k té otázce. Do značné míry je prompt určitě důležitý, ale z druhé strany ta krabička, její codebase, může mít třeba něco kolem 20 tisíc řádků, což ve výsledku znamená, že prompt je z toho jen nějaká menší část. Takže prompt je důležitý, ale stavění architektury, tedy toho, jak to technicky má fungovat, nám zabralo hodně času. Možná bych řekl, že je to dokonce důležitější, protože iterovat nad promptem dnes už umíme lépe, máme nějaké zkušenosti a víme, jakým směrem to hnát, ale na codebase jsme se určitě zapotili víc.

Vlastně i když děláme AI a zní to, že děláme furt jen prompt engineering, tak to tak vlastně není. Většinu času, řekl bych klidně 90 % času nebo i víc, děláme engineering. Tedy práci na tom, aby to celé šlapalo - jak zpracovávat rozbité odpovědi od modelů, jak to udělat škálovatelné, co dělat, když jsou servery Google přetížené, padají nám a podobně. Tohle je náš každodenní chleba – spíš tedy engineering.

Jednou za čas se vrátíme k promptu, vylepšíme ho, doplníme nějakou kategorii, trošku na něm iterujeme, řešíme, proč model v některých případech odpovídá divně nebo proč to není úplně stabilní. Co se týče AI modelů, nikdy nebudeme mít 100% stabilitu, vždycky tam bude nějaká míra nestability. To je moc důležité říct, protože pokud někdo vstupuje do AI produktu s myšlenkou, že po roce vývoje bude všechno 100% bezchybné, tak se obávám, že tam nikdy nedojde.

Podle mě platí: It's not a bug, it's a feature. Prostě je to vlastnost LLM nebo velkých (foundation) modelů. Je tam určitý stupeň halucinací, špatně se to říká, ale je tady generování a nahodilost a musí se s tím počítat. Nedá se to úplně eliminovat.

Ještě když se naposled zaměřím na prompt a pak se podíváme dál na modely a na celou infrastrukturu kolem, přijde mi logické se zeptat, jak moc je prompt univerzální. Například v GCP stacku - používáte stejný prompt pro různé modely? Nebo je třeba prompt měnit s každou novou verzí či subreleasem a testovat ho? Jak moc se prompt rozbije při změně foundation modelu? Řekl bych, že dnes už je to poměrně dost stabilní a nedochází k zásadním změnám.

Co je důležité vědět, jsou limity jednotlivých modelů. Například u nás, zejména u byznysových klientů, je extrémně důležité znát timestampy, kdy se co ve videu objeví. A tohle třeba, když budu mluvit o modelu…

Pokud chcete, můžu text ještě více zkrátit nebo upravit styl.

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

Google Gemini umí ty modely dobře používat. Flashové modely, Flash nebo Flashlight, se však často zamotávají v sekvencích, zacyklí se a nejsou zcela spolehlivé. Proto je důležité umět si definovat, který model na co stačí. Vždy je totiž lepší použít k danému use case co nejslabší model – ideálně Flashlight nebo Flash. Za prvé totiž dostanete rychlejší odpověď API, je to mnohem levnější, třeba až desetkrát, a zároveň kvalita není desetkrát horší, ale jen mírně horší. Takže je důležité umět rozlišit jednotlivé modely. Jinak se nám ale nestává, že by nasazení nového modelu rozbilo celý prompt.

Otázka má více vrstev. Jeden z parametrů těch modelů je temperature, kterou můžeš nastavovat – jak moc má být model kreativní. Čím nižší hodnotu teploty nastavíš, tím méně je model kreativní. V takovém případě se model sám snaží co nejvíc držet zadaného promptu a omezovat kreativitu na minimum.

Jak moc tedy hrajete s tímto parametrem? Je to tak, že jste pár iterací promptu vyzkoušeli spolu s různými hodnotami temperature? Nebo jste už našli ideální temperature pro váš use case a pak už měníte jen části promptu, zatímco temperature zůstává stejná? Jaký je vztah mezi těmito třemi kategoriemi: model, prompt a temperature?

Z vlastní zkušenosti mohu říct, že za posledních půl roku jsme s hodnotou temperature už ani nehnuli. Máme ji nastavenou blízko nuly, tedy téměř bez kreativity. Jakmile totiž nastavíte teplotu na vysoké hodnoty, model vám často nevrátí souvislou větu, ale objevují se rozbité znaky a nesmyslné výstupy. Proto tuto hodnotu necháváme stabilně nízkou, aby model omezoval svou kreativitu. To je logické, pokud potřebujete analytické a srovnatelné výstupy, například čísla nebo jasně definované hodnoty. Nechcete, aby model generoval obrázky, psal romány nebo se choval jako umělec – chcete, aby fungoval jako analytik.

Mnoho takových případů jsou vlastně binární nebo číselné kategorie, například stupnice od nuly do deseti, případně popis v neutrálním stylu, nebo prostě čistý přepis. Takže, jak říkáte, nechceme…

Pokud chcete, mohu pokračovat a doplnit závěr nebo cokoliv upravit dle přání.

Jasně, tady je opravený text s lepší formální i stylistickou úpravou:

Od něj chceme být výtvarní. Od modelů nechceme názor. Super, díky. Tak pojďme k těm modelům. Ty už vlastně začal sledovat limity těch modelů a místa, kde se mýlí. Jak to máte u vás? Jaká byla cesta k výběru těch správných modelů? Co se u vás stane, když Google oznámí novou verzi Gemini? Jaký proces to interně spustí a tak?

Hezká otázka. Když Google vydá nové řady modelů, tak ano, nejdřív je tam takový „wow efekt“, třeba před pár měsíci vydali řady 2,5. Ale technicky pro nás to na další čtvrtrok nic moc neznamená, protože nové modely jsou většinou v preview verzích – za prvé, a za druhé jsou dostupné pouze z globálního endpointu. My však naše data rotujeme na evropských serverech, takže pro nás to znamená, že když vyjde nový model, tak si s ním občas zahrajeme, podíváme se, kam se to posunulo, ale víme, že máme zhruba tři měsíce na to, než budou produkční modely dostupné na několika endpointech napříč Evropou.

To, co se stalo s modely 2,5, nastalo někdy začátkem či v půlce června, tedy relativně nedávno. Implementace těchto modelů u nás tedy probíhá během července.

Co se týká velikosti modelů, které používáte, nebo rychlosti, jak se na to díváte – říkala jste Flash, Flashlight a Pročko. Jakou úlohu plní jednotlivé modely, co do nich posíláte a jak se rozhodujete, co u vás běží?

Obecně u nás platí, že na analýzu fotek bohatě stačí Flash, takže používáme Flash modely. U videí v rámci aplikace, kde máme pouze základní prompt a nemáme tam byznysové případy, kdy potřebujeme například různé timestampy, také používáme Flash model, který je díky své nízké ceně a přijatelné chybovosti dostatečný. Na biznisové scénáře už typicky používáme lepší modely; na fotky u nich opět stačí Flash, ale na videa máme nasazeny Pro modely.

A je video vstupem natívně, nebo si ho musíte rozsekat v nějaké pipeline na fotky? Jak to funguje?

Vstup je normálně video. Vím, že se to dříve třeba u GPT muselo rozsekávat, ale žádný takový proces už nyní nefunguje.

Firmy, které se zabývají AI, na tom iterují velmi rychle, takže je složité držet krok s novými parametry, které přibývají, a s věcmi, které jsou deprecated a musí se vyřadit ze stacku.

Například nedávno byly dvě Google knihovny – Vertex AI a Google AI Platforms – označeny jako deprecated a Google oznámil, že příští rok budou úplně odstraněny. Takže my teď...

Přecházíme na nové SDK od Google, která nabízí nové funkce. To je u Google ale běžné, ne? Vykopnou spoustu věcí, které se přejmenují nebo dělají to samé, ale jmenují se jinak. Když je spustíš v jiné části...

Pokud chceš, mohu pomoci s pokračováním nebo další úpravou textu.

Jasně, tady je opravený a trochu upravený text, aby byl srozumitelnější:

I v tom cloudu běží třeba ten samý model, ale s jiným pricingem a tak, takže je to fakt takový chaos, nebo jak se tomu říká, euforická revoluce – prostě se toho vypustí hrozně moc, a pak to konsolidují. Někdy je to bolestivé, protože vypínají služby, na kterých už máš postavený řešení, ale z širšího pohledu ta konsolidace potom dává smysl. Já bych řekl, že si teď všichni zkoušejí všechny ty nové modely.

Když se to teď děje třeba u Vertex AI, na který má Google přesunout všechno, bude to pak jeden Gemini AI Studio nebo něco podobného? V podstatě Google doporučuje soustředit se na knihovnu Gen AI. Jak říkáš, nejdřív toho vznikne hodně, pak to různě skonsolidují a některé modely přechází z jednoho modulu do druhého. Typicky to byl Google AI Platforms, který ve svých vnitřnostech měl i Vertex AI. Ten Vertex AI se pak používal samostatně nebo v rámci těchto služeb, ale bylo tam hodně zmatení ohledně dokumentace a co přesně používat.

Určitě je to ale cesta dopředu, protože odpovědi, které API vrací, jsou lepší a lépe se s nimi pracuje, stejně jako třeba pricing je přehlednější. Není to tak dávno, co APIčka vracela tokeny a útratu najednou, a vzhledem k tomu, že používáme různé modality, museli jsme tokeny přepočítávat pro každou modalitu zvlášť a dopočítávat ceny. Naštěstí to Google už narovnal a v API volání teď vrací rozpad tokenů podle jednotlivých modalit přímo v odpovědi. Takže takové detaily jsou důležité.

Navíc modely verze 2.5 jsou už ve výchozím nastavení „thinking“ modely. Ten thinking proces je poměrně drahý, takže je důležité mít možnost nastavovat parametry, které tento proces umožňují zapínat nebo vypínat a podobně. Takže tohle všechno má význam.

Hlavní je být pořád updatovaný. Myslím, že hranice mezi “být updatovaný” a “být zastaralý” je hodně tenká. Co platilo před měsícem, teď už nemusí být pravda. Proto je důležité procesy sledovat. My teď, začátkem července, pořád běžíme na starších modelech – používáme třeba model 1.5 Pro, který je už deprecated a v září bude úplně odstraněný. To je důležité také z hlediska životnosti modelů, která je obvykle kolem jednoho roku. Přesné datum vydání 1.5 modelu si nepamatuju, ale kdyby někdo má ten model stále napojený, Google ho v září buď úplně vypne nebo nasadí výrazně vyšší pricing, což může znamenat vyšší náklady.

Stejně tak pricing modelů, například verze 2.5, která ještě před svým produkčním releasem v květnu stála určitou cenu, se během pár týdnů změnila i dvojnásobně. Takže opravdu je potřeba sledovat celý proces.

No a to mě přivádí zpátky k pricingu, už jsi ho několikrát zmínil. Jak vy si...

Pokud chceš, mohu ti pomoci s opravou a doladěním i další části textu.

Opravím a upravím tvůj text pro lepší srozumitelnost a plynulost:

Řídíte, jaké jsou možnosti, jak snižovat tu cenu, jak k tomu přistupujete, že vlastně s každou fotkou to tam „cinkne“ Google, a jak se rozhodujete, kdy mu „cinknete“ a kolik? Vlastně to, jak můžeme ovlivnit tu cenu, bych řekl, spočívá zejména ve dvou rovinách.

První rovina je, že zkusíme zvolit optimální model. Jak už jsem říkal dřív – nepoužívat zbytečně drahý model tam, kde stačí levnější. To je první krok, který chápu. Na druhou stranu, když ověřuješ ten případ, tak asi začínáš drahým modelem a potom zkoušíš, jak to dostat do levnějšího. Nebo defaultně první vyzkoušíš, jestli ti nevypadne dobrý výsledek z Fleše, a pokud ne, zkoušíš vyšší model. Tak nějak jsme dřív zkoušeli oba přístupy, než jsme to dali do produkce.

Je pravidlem, že na Fleš stačí fotka, ale pokud chceme zobrazit timestampy, potřebujeme lepší modely. To platí například pro model 1.5. Nad tím už dále neiterujeme. Občas si ale vyzkoušíme, jestli by Fleš nepostačil i na ty timestampy, které jsou složitější. Zatím se ukázalo, že spíš ne, takže spíš máme tendenci ty lepší modely používat a nevyhazovat je.

Také jsem zmínil, že na byznysové větvi stále držíme model 1.5 pro oko. Někdo by se mohl ptát, proč, když vyšly modely 2.0 a nyní už 2.5. Je zajímavé, že řada 2.0 neměla pro ten model regulérní náhradu za 1.5, takže pořád jsme museli používat 1.5. Teprve náhrada nastala až s produkční verzí 2.5 pro oko.

Ještě ses mě ptal na ceny a jak je můžeme regulovat. Momentálně pracujeme na takzvaných batch requestech. To znamená nový přístup ke zpracování multimodálních dat, díky kterému se dostaneme na zhruba polovinu ceny, kterou máme teď. Rozdíl je v tom, že současný přístup je často „live“ – data potřebujeme hned, proto posíláme API call, dostaneme výsledek a rovnou ho puškujeme dál do aplikace. Batch requesty naopak znamenají, že vytvoříme požadavek na Google, aby si data zpracoval v průběhu následujících desítek minut, tedy něco jako odložené zpracování. Vzhledem k tomu, že už jsme v fázi optimalizace – tedy produkt máme hotový – hodně se teď zaměřujeme na snižování cen.

Mám spoustu otázek, ale první je k těm batch requestům – je to funkce Gemini, kterou můžeš nastavit jako službu, prostě zaškrtneš checkbox a tím to skončí, nebo je potřeba na straně vašich techniků nějaká inženýrská investice a chytrý přístup? Tedy je to čistě byznysové rozhodnutí, kdy si řeknete, které požadavky nepotřebujeme near real time nebo real time, a ty pak zlevníme? Nebo je to i technologická investice? V podstatě jde o to samé jako s live zpracováním – podle dokumentace je potřeba napsat kód a dobře nakrmít data…

Pokud chceš, můžu to ještě víc upravit nebo zkrátit. Stačí říct.

Opravený text:

Potom ta data potřebujeme vyčistit, takže je to stejné jako u toho live zpracování – máme nějaký kód v GitLabu, který je deployovaný a který to obstarává. Ono je fakt hodně toho lepidla kolem, protože jsou nějaké typické chyby, které ty modely můžou dělat, třeba že neudrží strukturu těch timestampů, nebo se opakují různé typy chyb, třeba zamění čárku za něco jiného, nebo zapomenou nějakou závorku. Na takové typicky se opakující chyby máme různé opravné moduly, které ty nejčastější dokážou zachytit a zase nám to dokáže... A je to jednodušší, než to vychytávat v promptu. Třeba práce s kotátkem, pokud tam nejsou správně čárky, nefunguje, jo? Jo, v podstatě bych řekl, že samozřejmě ideální je mít dobře nastavený prompt, ale pokud víme, že ty modely mají nějaké limity, které se opakují, jsou prostě případy, které se dopromptují velice složitě, a spíš sázíme trošku na to, že to víc vychytávají spíš až ty novější modely. Takže se snažíme na to jít oběma přístupy – samozřejmě by bylo lepší mít data čistá rovnou, než dělat práci pro práci a nechat nějaký vadný prompt a na vadný prompt dělat fixy. Takže k tomu vždycky...

Je-li nějaký problém s vyhodnocením, tak se vždycky nejdřív podíváme na ten prompt, jestli by to nešlo nějakým způsobem opravit. Ale když třeba dlouhodobě vidíme, že tam je nějaký problém a jde ho fixnout programaticky… A ty čárky jsou konkrétně PROBLÉM, který tam vnímáš? Ano. Jaké ty fixy většinou řešíte? Většinou jde o věci týkající se videa, a jsou to právě, řekněme, nějaké ty timestampy. Protože tam je obrovský skok v nárocích na AI. Když analyzuju fotku, i když to dřív nemuselo platit, už nějakou dobu platí, že analýza fotek je pro model relativně triviální. Ale video je pořád trošku vyšší dívčí – je to pořád 25 fotek za vteřinu, je tam prostě hodně informací. Takže typicky jsou to právě timestampy. Zároveň můžu zmínit, že pro nás je důležitý znát reálnou délku videa, protože, jak jsem už zmiňoval, modely můžou halucinovat a mít nějaké své domněnky. Například model může správně identifikovat obsah minutového videa, ale pak třeba dokreslovat timestampy, jako kdyby to video mělo dvě minuty. To se prostě občas stává. A je lepší to vyřešit pravidlově – prostě vychytat tu chybu a zjistit, že se stala, než učit model počítat nebo řešit timestampy u složitých videí.

Přesně tak. V takovém případě skočí opravný modul, který se podívá na duration videa – např. 60 vteřin – a jakýkoliv timestamp, který je vyšší, prostě odmaže. S tím budeme stejně koketovat. Takže to je jeden z příkladů modulů, které tam máme nasazené.

Jak sledujete ty náklady? Sledujete to na základě nějakých API callů, nějakého měsíčního usage? Jak řídíte ty náklady? Na co se díváte? Tak samozřejmě každý ten API call má svoji cenu…

Opravený text:

Ukládáme data v BigQuery a prozatím nám bohatě stačí mít týdenní rozbor cen, které jsme utratili za minulý týden, za každou větev zvlášť. Vidíme tak, kolik jsme utratili za aplikační větev, která je rozdělena na fotky a video, totéž platí pro businessovou větev, a pak je tam ještě collab centrum, což je další větev. Takže máme rozpad na dvě větve, a analýza fotek má relativně stabilní cenu na model, protože vždy máme nějakou fotku, která je pixelově často podobná, a vstupuje do promptu určité velikosti. To je pro nás relativně stabilní cena, klíčovým ukazatelem je hlavně, zda používáme flash model nebo ne.

Naopak video je výrazně nestabilní prvek, protože vždy záleží na průměrné délce analyzovaných videí – každá vteřina navíc znamená vyšší náklady. Například v rámci aplikační větve jsme minulý týden měli průměrnou délku videí zhruba půl minuty. Bylo by velký rozdíl, kdyby videa měla v průměru pět minut, protože náklady by pak velmi rapidně stouply.

Nevím, jestli mám dávat nějaký konkrétní příklad cenový, ale klidně řekni, pokud chceš – asi to bude dost specifické, ale může být užitečné jako benchmark. Když otevřeme naše účetnictví, co se týče aplikační větve, kde jsem zmiňoval, že i na videa používáme flash modely, které jsou pro nás výhodné, protože jsou levné a zároveň toho zvládají hodně, tak jsme za minulý týden za tisíc videí zaplatili přes tři dolary.

Naopak v businessové větvi, kde používáme modely, které lépe zachytávají timestampy a další specifika, jsme za tisíc videí zaplatili přes 24 dolarů. Takže ceny se mohou výrazně lišit, přitom průměrná délka videí je podobná.

Náš FinOps funguje tak, že na týdenní bázi víme, kolik zpracujeme souborů, kolik nás to stojí na tisíc souborů, víme, kolik nás stojí účet, protože víme, kolik zhruba papírů, tedy fotek nebo videí analyzujeme. To vše je velmi důležité pro produkt, kam směřovat další vývoj, jak to analyzovat – jestli analyzovat všechno nebo jen vzorky, a podobně.

Ještě jednou ty ceny: za tisíc videí na flash modelech to bylo něco přes tři dolary, vezměme v potaz, že to jsou tisíc půlminutových videí, což není triviální věc, a k tomu jde dvacetistránkový prompt, což představuje spoustu tokenů pro každý dotaz, takže je to vlastně dobrá cena. Indové nebo všechny ty back office outsourcingy tagování už asi nebudou potřebné – takže bye bye.

A proč jsou modely pro businessovou větev desetkrát dražší? Ano, jsou desetkrát dražší. Obecně si myslím, že minimálně za poslední rok sledujeme trend, že AI korporace a vývojáři tlačí více na flash modely, což je logické – nejsou o tolik horší, i když jsou horší...

Jenom trochu, jsou mnohem levnější na zpracování, nespotřebovávají tolik energie, takže si myslím, že tento trend bude dál pokračovat. Budeme čím dál víc využívat flashové modely, které jsou v podstatě destilátem, nějakým způsobem destilátem těch pročkových modelů. Dokonce u té řady tuším 1.5 byl ten flashový model tak oblíbený, že na základě něho už od řady 2.0 Google rozdělal flashový model na dva – udělal flash a flashlight. Za mě to má ohromný význam, protože opravdu nadprůměrnou většinu věcí flashové modely stačí pokrýt.

Přece jenom dost často implementujeme AI krabičky jen kvůli textům, text-to-text, takže nám všude bohatě stačí nějaké fleše. Říkám, že i ty fotky jsou v pohodě, zvládne 40 kategorií, 20 stránkový prompt a funguje to dobře. Takže opravdu pročkové modely využiju jen na složité komplexní věci a i tady se dá předpokládat, že to bude postupně lepší a budeme víc přecházet na flashové modely.

Jak se vyvíjí cena? Je to tak, že cena zlevňuje v čase? Počítáte s tím? Zase říkáš, že máte roadmapu na dlouho dopředu. Ten předpoklad je, že teď je to nejdražší, co kdy bylo. Na druhou stranu mám pocit, že z té scény přichází něco jako Uber – venture kapitál, který se pálí, aby se získala adopce, a ve chvíli, kdy si všichni zvyknou na Uber a zruší klasické autobusy, tak se přepne režim na ziskovost a Uber zdraží třeba na dvojnásobek. Cítím určitý strach z toho, že ta nízká cena nemusí být dlouhodobě udržitelná a že v budoucnu může dojít ke zdražení.

Jak se na to díváš ty? Vývoj se hodně mění, životnost modelů je zhruba rok, ale v business case a v tom, jak to stavíš, předpokládáš, že dostaneš větší výkon za stejnou nebo lepší cenu v budoucnu, že?

Samozřejmě sledujeme ceny pravidelně. Jak jsem už zmínil, když máš nasazený stejný model, někdy se cena pod rukama nějak pohně, ale za poslední rok bych neřekl, že jde cena dramaticky dolů nebo nahoru. Trochu to rozvedu: ceny pro modelů byly relativně stabilní, možná teď, jak už je jedna půlka deprekovaná, jsou ty starší modely zbytečně drahé, protože v minulosti už byly hodně drahé. U pro modelů tedy vidíme lepší optimalizaci, ale stále jsou asi desetkrát dražší než fleše.

Ten fleš, jak jsem říkal, jeden a půlka fleš Google byla tak oblíbená, že Google z ní udělal dva modely – rozvětvil to na flash a flashlight. Co stál jeden a půlka fleš, tak nyní stojí dvojka flashlight a ten nový flash 2 a 2.5 se dostaly někde mezi light a pročko.

Takže zejména u flashových modelů se cena drží, u proček spíš klesá, ale přibyly nové modality. U těch 2.5 je to například možnost „thinking“, kdy model může více „přemýšlet“, což my aktuálně nevyužíváme.

Jasně, tady je opravený text s lepší srozumitelností a dílčími stylistickými úpravami:

Ehm, ono je to zase něco za něco. Pokud je potřeba využívat thinking modalitu, tak to samozřejmě má smysl, ale my chceme spíš mít takové vyhodnocení a thinking modalita nám už nepřinese nějaký výrazný benefit navíc. Co nám přinese hodně navíc, je cenová přirážka, kterou nepotřebujeme. Zároveň bych možná dodal jednu drobnost – kdyby byl někdo naštvaný, že pořád mluvím jen o Google a Gemini a podobně – my jsme to totiž zkoušeli, když jsme se před rokem a kouskem rozhodovali, v čem multimodální vyhodnocení uděláme, jasně se ukázalo, že Google je v tom prostě nejdál. Například v text-to-text úlohách byl tehdy GPT lepší, dneska už je to srovnané, ale pokud jde o kulturní nuance a obecné uvažování v text-to-text, GPT byl vždycky o ten krůček dál. Avšak právě u multimodality je potřeba brát v úvahu, že Google má dlouhou historii s machine learning modely a silné stroje a nezačínal od nuly, pokud chtěl analyzovat fotky nebo videa. V multimodální rovině byl Google prostě napřed.

Takže jsme se podívali, co vám tam běží a kolik to stojí. Rád bych otevřel ještě jedno téma, a to LLM Ops, tedy tu opsí část, software engineering, monitoring… Už máš na tom postavený produkt, který nějak funguje, potřebuješ ho udržovat, a zároveň jsou to modely, které si sem tam něco „vymyslí“. Mluvil jsi o downtimech a dalších problémech, jaký je nad tím monitoring? Jak moc to připomíná klasický software engineering monitoring a co vlastně máte nastaveno, jak monitorujete?

Monitoring je nutnou součástí těch skriptů, které tam máme postavené, protože pokud chci nad tím rychle iterovat, musíme chyby vědět co nejdřív – failovat co nejrychleji a iterovat co nejrychleji. Hlavní složky našeho monitoringu jsou:

1. Slack, kde dostáváme alerty během toho, co probíhají procesy. Když víme, že třeba Google nestíhá odbavovat API volání, můžeme snížit paralelizaci a rychle reagovat.
2. Monitoring výstupů z modelu – hodnocení kvality máme rozdělené na dvě roviny: tvrdé datové validace a měkké datové validace.

Tvrdé datové validace kontrolují, jestli model vrátil všechny kategorie, na které se ptáme, a jestli odpovědi spadají do nějakých okrajů. Například u binárních kategorií (ano/ne) kontrolujeme, jestli nevrací něco jiného. Tyto validace nám ukazují, jestli model vrací správné typy dat. Jsou velmi důležité – třeba nám říkají, že kategorie „collab“ funguje divně, když někde model říká „collab“, ale pak nedokáže vrátit žádnou značku nebo...

Pokud chceš, mohu pokračovat v opravě nebo doplnit i další části textu.

Opravený text:

Doporučit, s kým by ten collab měl být. A to jsou pro nás všechny signály, kdy do toho můžeme vstupovat prakticky v průběhu celého procesu. Nevím, jestli máš ještě nějaké otázky k těm tvrdým datovým validacím.

Takže to je pravidlové. To je programatické. Ty tvrdé datové validace do nich vůbec nevstupuje model. Co všechno lze vyhodnotit tvrdou datovou validací, čistě kódem, je pro nás preferované. Protože pokud jsou validace napsané dobře a dobře otestované, víme jednoduše, zda chyba je nebo není. Samozřejmě tím neohlídáme měkčí věci, ale co nejde, to máme pokryté právě tvrdými validacemi.

No a jak to vlastně dopadá s chybami, na které přicházíte? Nebo jste seděli a u každé části toho promptu jste si říkali, jak ji vlastně validovat? Jak vznikla tato "krabička", tenhle kód? Tato "krabička" vznikla z nutnosti, že jsme potřebovali co nejrychleji zjistit chyby na byznysových větvích. Tam nás to pálilo prakticky hned. Pokud jsme klientům dodávali nějaký dashboard, kde jsme tvrdili určité věci, ale model je pak vyhodnocoval jinak, bylo to problém.

Takže přibližně před rokem, když vznikal produkt této krabičky, souběžně s ní vznikaly i tvrdé datové validace. Jak to dopadá? Je to poměrně rozsáhlý modul. Bohužel se jen tak nezmenší, protože kromě toho, že hlídá každou kategorii, kontroluje také různé podmínky mezi kategoriemi a zda dávají logický smysl. I když říkám, že model držím v kontextu, což ve většině případů platí, model nikdy není stoprocentní a vždycky se může objevit chyba. Proto se co nejvíc snažíme hlídat všechno programaticky.

Poslední částí jsou soft datové validace, což je místo, kde by měl lepší model hlídat výstupy horšího modelu. Takže LLM jako soudce, vlastně. To jsme měli dříve v pilotní fázi.

A možná začneme tím, co jsou soft validace. Ta kategorie je „softová“, protože se nedá úplně přesně říct. Spíš bych to řekl takhle: tvrdé datové validace dostanou všechny kategorie, které model vyhodnotí, a ověří je z té „hard“ stránky, tedy co lze vyhodnotit kódem. Například jestli odpověď souhlasí s těmi kategoriemi. Když klient napíše USP nebo značky, ověří se, zda opravdu USP a značky vyplnil a jestli si nevymyslel něco jiného.

Tvrdé validace tedy projdou všechny kategorie z exaktního pohledu. A pak by měly nastoupit soft validace, které dostanou výstupy modelu a navrhnou, jestli byly správně vyhodnoceny. Kdybych měl dát nějaký triviální příklad: řekněme, že model tvrdí, že fotka je většinově červená, ale „soudce“ by řekl, že většina je modrá. To bychom…

Zde je opravený text s vylepšenou gramatikou a stylistikou:

Přes tvrdé datové validace jsme mohli dostat jedině určitá data, takže bychom se teď nechtěli zabývat pixely nebo něčím podobným, což v tuto chvíli neděláme. Stejně vždycky budou situace, kdy potřebujeme ty měkčí validace, jako například u obsahu. Když nám model napíše k obrázku, že si holka hraje s kočkou, a jiný model by řekl, že to není pravda, protože se tam holka hraje se psem, tak takové věci tvrdé datové validace jednoduše nezachytí.

Ale správně říkám, že by to tak mělo být. V tuto chvíli máme tento druh validace pozastavený, protože při pilotním režimu byly většinou notifikace spíše o slovíčkaření a neustálém měnění. Často se model snažil být nápomocný, ale zbytečně, až příliš precizní. Přesně tak, a vlastně nás to spíš brzdilo. Tohle teď máme někde na roadmapě, abychom to mohli zase oživit, ale momentálně máme tolik dalších priorit, že jsou důležitější úkoly, které řešíme dřív. Někdy se k tomu ale určitě vrátíme.

To velmi prodražuje proces. V tuto chvíli vybíráš jednu fotografii z tisíce a kontrola jí takto probíhá, že ji nelze jednoduše přehodit někam dál.

U věcí, kde model sám vyhodnotí, jak moc si je jistý nebo podobně, jakým způsobem jsi dělal tu druhou kontrolu? Měl by ji dělat pokročilejší model, který je "rozhodčím" oproti prvnímu, takže v takovém případě můžeme pustit druhou kontrolu, aby prokázala, že je vše v pořádku. To byla vlastně dobrá otázka, protože přesně jak říkáš, softvé validace vždy znamenají navýšení nákladů. Navíc je potřeba, aby to dělal ideálně nejkvalitnější model, tedy zároveň i ten nejdražší.

Když jsme to ještě měli běžně nasazené, fungovalo to tak, že se vybral nějaký náhodný vzorek, aby to mělo smysl a nebylo nutné kontrolovat vše. Takže jsme pracovali s takovým "barometrem" — pokud bylo v promptu něco špatně, měla to později taková kontrola odhalit. Jak jsem ale říkal, model se spíš snažil radit maličkosti, než abychom na základě jeho doporučení něco reálně změnili.

Nejvíc nám nakonec pomohly tvrdé datové validace, díky nimž jsme už upravili spoustu věcí. Kdyby totiž takové validace nebyly, často by nám unikl i nějaký detail. Například doplnění různých znaků do regulárních výrazů, aby se zachycovaly požadované případy. Kdyby tam nebyly detailnější kontroly, které odhalí, že něco není úplně správně — nemusí to být nutně špatně, ale třeba to vyžaduje kontrolu — mohli bychom tam do dneška mít chyby.

Jak tedy říkám, monitoring je naprosto zásadní.

Pokud chcete, můžu text ještě více upravit nebo zjednodušit.

Tady je opravený a stylisticky upravený text:

Je potřeba rychle iterovat nad tím prompstem, nad celým produktem. Aby to šlo dělat efektivně, je potřeba mít relativně kvalitní monitoring. Předpokládám, že pořád funguje ten human-improved loop, tedy že se sem tam podíváte na to video, jestli to sedí nebo padá, případně jestli to už vůbec nefunguje. Ale nyní je to tak stabilní, že už se s těmi videi ani v byznysu vlastně nepotkáváte. Už to máte čistě strojově a věříte tomu. Kontroly, jestli tam fakt byl králíček a zebry ve třetí minutě, už jsou zbytečné. Tato operativa byla dříve častější, dnes nás už tolik času nebere. Občas, když se nám objeví nějaká zpětná vazba z validací nebo vyložená reklamace ze strany byznysu, tak to přímo prověříme. Ale už není běžné, že bychom náhodně procházeli nějaké fotky nebo videa. Děje se to pouze při nasazení nových kategorií – nasadíme testy a podíváme se na vzorek, jestli to funguje. Katalogy, které máme řadu měsíců, už znova nekontrolujeme.

Pro mě je to super feedback, že je to stabilní a že se tomu dá důvěřovat, že na tom lze stavět produkt. Jak jsi říkal, nikdy to nebude 100%, ale je to dostatečně dobré („good enough“), že už nemáš strach nechat to běžet automaticky. Kontroluješ, jestli ti to nepřináší zbytečné náklady, máš monitoring, ale samotná práce si zaslouží důvěru – tady skutečně „pan agent“ odvádí dobrou práci.

Jak říkáš, nikdy to nebude 100%, a proto se snažíme s každou verzí, aby ta krabička byla stabilnější. Nikdy to nebude perfektní, ale doděláváme různé další funkce, alespoň po technické stránce. Aktuálně například doděláváme reverzní pipeline, která zajistí, že pokud se vyhodnotí, že v některých kategoriích je něco špatně, automaticky se takové věci posílají k přepisu. Snažíme se tak co nejvíce člověka z toho loopu odstranit.

A co se týče přepisu konkrétního videa nebo kategorizace napříč kategoriemi – děláte correction i historicky?
Ne, jde spíše o konkrétní situace…

Třeba v rámci pipeline existuje „jeden kůz“ – dám příklad: tvrdá validace nám vyhodnotí, že máme příspěvek, ke kterému AI model vrátil místo očekávaných 40 kategorií pouze 10. V takovém případě se vyhodnocení smaže a pošle se reverzně znova, aby se dopočítaly chybějící odpovědi. Občas se to stane, zejména když video trvá třeba tři čtvrtě hodiny – čím delší video, tím vyšší pravděpodobnost chybovosti, model se může „zaciklit“. Takže toto je typický příklad, kdy se nevyhodnotí všechny kategorie, a v takových případech nasazujeme reverzní pipeline.

Ještě když jsi mluvil o problému s timestampy, tak ten taky…

Pokud chceš, mohu pokračovat nebo text ještě více zestručnit či dolaďovat.

Tady je opravený text s lepší strukturou a gramatikou:

Stoupá náročnost s délkou videa, nebo je to obecné napříč? Říkal jsi to na příkladu minutového videa – je to tedy stejný případ, že náročnost a velikost kontextového okna jsou takové, že se model někde zacucká, ztratí kontext, nebo jsou timestampy jednoduše momentálně pro model těžké, i když jde třeba o 30sekundové video?

Ano, timestampy jsou typickým příkladem, kde s rostoucí délkou videa průběžně narůstá chybovost. Pokud máme nějaké statické kategorie, například zařadit obsah do kategorií, popsat v pěti slovech, co se tam děje, či podobné jednodušší úkoly, problémy obecně bývají menší. Ale u komplexnějších úkolů, které přirozeně vyžadují delší kontext videa, nastávají potíže.

A jde o oblast, kde se modely skutečně posouvají? Historicky bylo klíčové právě kontextové okno – předbíhali jsme a snažili se zjistit, kdo zvládne delší kontext. Mám pocit, že se to teď trochu zastavilo, protože v momentě, kdy je kontextové okno velké jako celá kniha, řeší se spíš jiné problémy, například správa velkých znalostních bází či enterprise řešení, což je úplně jiná disciplína. Takže už se nehoníme za „kdo má větší kontextové okno“.

Je to tedy spíš otázka kontextového okna, nebo historicky tomu, že počítání bylo těžké, protože jazykové modely byly původně trénované na odhadování slov a neměly vestavěnou kalkulačku?

De facto je to tak. Například u fotek nás délka netrápí. Ovšem délka videí byla oblastí, kde bylo jasně vidět, že se modely zásadně vyvíjejí a zlepšují. Nevím přesně, jaká čísla jsme měli, ale myslím, že ještě zhruba před půl rokem jsme z obchodního hlediska garantovali a běžně zpracovávali maximálně asi 20minutová videa, delší jsme automaticky nezpracovávali.

Nevzpomínám si přesně, jak byl ten limit nastavený, ale zásadní bylo, že jste si ho dali vědomě, protože jste věděli...

Ano, museli jsme operovat s nějakým limitem. Aktuálně je tento limit nastaven na 45 minut. Počítáme s tím, že jak se budou modely dál zlepšovat, budeme testovat a podporovat stále delší videa. Ale z multimodálních modalit je video jednoznačně nejnáročnější.

Když jsme například koncem minulého roku spouštěli tu krabičku (zařízení), obsahovala pouze analýzu fotek – byl to tedy první krok. Když jsme o pár měsíců později chtěli implementovat video, byl to obrovský skok, který přinesl řadu technických problémů, jež musíme stále řešit, například s omezením délky dílků videa.

Paradoxně, přestože má ta krabička multimodální požadavky, nemáme v těch procesech nasazený čistě textový model. Multimodální model používáme přímo zde. Ačkoliv některé doplňkové datové pipeline využívají textové modely třeba na tvorbu e-count insightů (insightů nad celým účtem), přímo v této krabičce, která je zavěšená uprostřed datové pipeline, čistý textový model nepoužíváme.

Krabička totiž doposud nedostala plnohodnotnou implementaci čistě textového modelu. Prioritou vždy bylo vytvořit multimodální řešení, a od toho se vše odvíjelo.

Pokud chceš, mohu ti pomoci text ještě více zjednodušit nebo přizpůsobit konkrétnímu stylu.

Tady je opravený text:

Fotky a pak co nejdřív videa. Ale upřímně řečeno, už jsem tady vlastně říkal nějaké průměry, a jestli jsme třeba minulý týden měli průměrnou délku videí půl minuty, tak je vidět, že to není nějaký dominantní problém. Tady ty sítě jsou totiž dost často založené na šortech, na nějakých krátkých sekvencích. Tam, kde začíná být problém s dlouhým videem, je hlavně YouTube, který může být založený i na dvouhodinovém formátu, a tam v tuto chvíli můžeme mít pořád problém, protože ty videa prostě nezpracujeme.

A tady bych se chtěl zeptat – takhle si to představuju – pokud jde o B2C audience, kdo je ten ideální klient? Kdo si má teď instalovat aplikaci Karl na svém iPhonu? Co všechno mi to vlastně udělá?

Vlastně kterýkoliv influencer, který svoji tvorbu myslí vážně a chce ji posouvat dál, by si tu aplikaci měl minimálně vyzkoušet. Co se týče B2B, tak řada našich klientů vyloženě vyžaduje, aby influenceri, kteří s nimi spolupracují, aplikaci používali. Dost často sledujeme, že po vyzkoušení, i když už nemusí, tak aplikaci dál používají.

No a tak tam napojíš svoje účty. Říkal jsi YouTube, Instagram, co tam ještě? Napojíš tam TikTok, Facebook, na roadmapě je LinkedIn a postupně by se to mělo rozšiřovat. Náš CTO by tam chtěl už dávno OnlyFans, ale ten na té roadmapě pořád je.

Takže teď LinkedIn a OnlyFans si musí počkat, ale všichni ostatní – Instagram, YouTube, TikTok hodně, takže to bude hodně obrazové, a Facebook.

OK, tak se tam připojím, dostanu nějakou analytiku svých postů, dostanu nějakej, ty jsi říkal, že text používáte i na nějaká doporučení?

Ano, dostaneš tam analytiku nad celým účtem – tedy slovní analýzu, čemu by ses měl na základě příspěvků vyvarovat, co naopak přitahuje lidi a jejich pozornost k tvému obsahu. Takže jednak nějaký insight nad účtem jako celkem, a pak každý jednotlivý post, který tam publikuješ, dostane taky svůj vlastní insight.

A vlastně ta nová funkce je, že můžeš vstoupit do marketplace, do collab centra, kde si můžeš zažádat o spolupráci s nějakou značkou, která se ti líbí, je ti sympatická. Můžeš jí sama oslovit a ta značka o tobě už ví.

Z pohledu značky, když jsme se bavili o business línii – proč tam máte mnohem vyšší úroveň modelu nutnosti jistoty – co je typický klient, který za vámi přijde? Prostě jdu prodávat jogurty, mám nasmlouvané třeba Mikyře, Čestmíra, Agátu a Ornelu a chci nad tím mít zásahová data a datovou pipeline stejnou, jako v Telce nebo v online?

Pro tyto firmy je nejdůležitější kombinace AI softových dat s těmi tvrdými daty, což je poměrně unikátní produkt, a na základě toho dokážeme doporučit, že i když nějaký influencer nemá třeba...

Pokud chcete, mohu upravit i pokračování textu.

Tady máte opravený text s úpravou pravopisu, interpunkce a stylistiky pro lepší srozumitelnost a plynulost:

Ba tolik followerů, takže i tak se třeba té značce vyplatí si ho nechat, protože doručuje nějakou message mnohem efektivněji než třeba nějakej předražený influencer, který má hlavně followerů, ale tu message někde vzadu v pozadí. Takže kombinace těchto softových metrik s tvrdými čísly výkonu je poměrně unikátní věc. No a tím, že se nám teď tady ty dvě větve spojily...

Potřebujeme mnohem víc iterovat nad nějakým salesem a marketingem, takže zase nutně budeme muset posilovat náš tým právě tady. To znamená, že teď produkt konsolidujete, vzniká platforma, nějaký product-market fit a konečně po několika letech hledání a prototypování máte něco, s čím chcete jít naplno do světa. Řekl bych, že se to konečně povedlo, protože když jsem do Kádla přicházel, tak těch větví, když to řeknu s nadsázkou, bylo skoro víc než lidí na nich. Takže občas to bylo dost náročné vzhledem k objemu práce, která všude byla. A konečně si myslím, že jsme přesně na správné linii. Ty dvě nejdůležitější větve se povedlo sjednotit do jedné, omotat kolem aplikace a věřím, že tady to bude fungovat. Díky.

Pro mě je Kárl příkladem produktu, který by před čtyřmi lety chtěl desetinasobný tým a rozpočet, a dneska staví nový produkt s výbornou propozicí nastávajících technologií, které jsou přes API. Mě fakt baví, jak díky Gen AI vzniká možnost tvořit nové produkty. Tady je to jasně vidět. Díky moc, Kubo. Držím palce, ať najdete správné partnery do marketingu a salesu, a ať se vám daří a ať to používá čím dál víc influencerů a značek. Já popřemýšlím, jestli si teda neotevřít ten TikTok, aby mi i Kárl dával smysl, zatímco jsem spíše LinkedIn influencer.

Díky moc, že jsi tady s námi byl a sdílel své zkušenosti. Díky moc, Jirko. Děkujeme, že jste si nás poslechli až sem. A díky také našim partnerům – členům DataTalk klubu. Těmi jsou Intex, Saska, Bistreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Kárl Data Company, DataMind, Notino a Flow. A pokud chcete zůstat v obraze ohledně české datové scény a globálních datových technologií, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz. Nechť vás provází data.

Pokud chcete ještě něco upravit, dejte vědět!