Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Data Talk. Mým dnešním hostem je Samuel Kožuch, Data a AI Team Lead ze společnosti Vortex Cloud. Ahoj Same.
Čau, ahoj.

Sama máme tady jako hosta podruhé. Mohli jste ho slyšet v díle 84 před rokem a půl. My se dneska se Samem podíváme, jak jinak než na agenty, a budeme se hodně věnovat Google Cloudu a tomu, jak se Google Cloud posunul. Typicky se zaměříme na Gemini Enterprise, nový produkt Google, který je zaměřený právě na produktivizaci agentů.

Pro ty posluchače, kteří neslyšeli a neposlouchají každý díl, což určitě pár bude, a neznají díl 84 našeho podcastu, Same, mohl by ses v krátkosti představit a udělat takové opáčko pro naše posluchače, prosím?
Určitě. Tak ahoj, těší mě, že tu znovu můžu být. Jsem momentálně Data and AI Team Lead ve Vortexu. Řídím datový tým o velikosti zhruba čtyři až pět lidí. Náš primární fokus ve Vortexe je implementace datových a AI řešení. Tedy ať už jde o agenty, nebo o stavbu datových skladů pro funkční AI v systémech u klientů. Předtím jsem pracoval jako datar, pracoval jsem v Kabule a také v jedné velké e-shopové firmě v Jirsku, kde jsem stál za výběrem skladových řešení například pro Nike a Victoria's Secret. Pomalu jsem se ale dostal do Vortexu, kde jsem začal s datovými sklady, a za poslední rok a půl jsem se hodně věnoval agentům a Gemini, takže se moje role postupně transformovala spíše do oblasti AI.

Ve Vortexu jsi tedy naskočil na Google stack, protože Vortex je Google Premier partner a jste díky tomu v Google expertíze velmi známi.
Ano, já jsem s Google stackem začal už předtím, u té e-shopové firmy, kterou bohužel jmenovat nemohu. Tam jsem začal pracovat s daty právě na Google stacku, ať už to byly real-time data, batchové pipeline a tak dále. Ve Vortexu jsem v tom pokračoval a postupně si vybudoval expertní znalosti Google Cloudu. Nyní už to nejsou pouze data, ale i AI, Gemini, agenti a prodeje agentů business zákazníkům, protože zákazníci na to slyší a vidí v tom velký přínos, tedy value proposition. Začal jsem s Google Cloudem dříve a postupně jsem svou expertízu rozšiřoval.

Já tam vnímám jako velký posun. Samozřejmě všechny IT firmy se za poslední rok a půl staly AI firmami a ještě před dvěma lety to tak nebylo. Na druhou stranu i Google se hodně posunul. Mám pocit, že před dvěma lety Google neměl tak silnou pozici, a když se podíváme na nějaký tržní podíl – OpenAI, Anthropic, Google –, Google roste raketově a zdá se, že i produktově a v modelech se zlepšuje. Co si myslíš o trhu za ty poslední dva roky? Chodí teď za vámi klienti a chtějí agenty, nebo je to spíše naše technologicko-startupová bublina, která tím žije, zatímco tradiční byznys stále slyší na AI, ale staví především datové sklady?
Já to vidím tak, že máme dva typy klientů. Jeden typ jsou klienti, kteří mají vizi, chtějí agenty používat, přicházejí s tím, že mají představu, co by mohli nejlépe s Google Cloudem udělat v této oblasti. Druhý typ klientů AI agenty znají, ale slyšeli, že jsou drahé, což dnes už úplně pravda není. U těchto klientů potom ukazujeme konkrétní případy využití, které dokážeme realizovat, a mnohdy jsou velmi překvapeni, že jde o AI řešení. Pak jim začíná docházet, že můžeme za relativně malé náklady nahradit různé manuální procesy, které měli doposud. Takže ti dva typy klientů ke nám chodí. Klienta, který by o AI agentech neslyšel nebo by nechtěl AI agenty používat, jsme ještě nepotkali. AI se používá všude, myslím, že je to velký fenomén a velmi rychle se rozvíjející oblast.

Připomínáš mi, že před nástupem Gemini tam vlastně nic nebylo.
Přesně tak. Před příchodem Gemini nebylo nic tak dobrého. Dnes je Gemini 3K jeden z nejlepších modelů, poráží GTT 5 i Klot. Osobně musím přiznat, že jako dlouholetý uživatel GTT jsem si od doby, kdy vyšlo Gemini 3K, zrušil předplatné GTT a přešel na Gemini 3K. Očividně Google ví, co dělá, a myslím, že má jasnou vizi, kam chce dojít.

Za poslední dva roky se všechno velmi zjednodušilo, přístup k agentům a AI je mnohem lepší a celková transparentnost Googlu v oblasti AI se výrazně zlepšila.

Když mluvíme o klientech, v minulé epizodě jsi zmiňoval, že jste měli hodně klientů pod NDA a nemohl jsi je jmenovat. A teď se něco změnilo? Koho máte ve Vertexu ve stáji?
Naši dlouhodobí klienti jsou například Tatum, což je brněnská web 3 blockchain platforma. S nimi spolupracujeme už dva roky. Na počátku jsme jim budovali datové sklady, o kterých jsme mluvili už před rokem a půl v předchozí epizodě. Nyní to postupně posouváme směrem k AI. Všechny běžně používají Cursor a agenty pro různé marketingové účely a podobně, s čímž jim pomáháme.

Další klient je Robi, se kterým se bavíme asi posledních šest měsíců a v posledním měsíci až půl realizujeme implementaci support agenta. Nejedná se však o standardního support agenta, který odpovídá na otázky typu „nefunguje mi XY“, ale o interaktivního agenta, který umožňuje například spravovat fakturaci, pozastavit předplatné, když máš dokončenou jízdu. Robi totiž představuje virtuální trénink, vlastně virtuální jízdu na kole, a když dojde k nějaké situaci během jízdy, můžeš agentovi napsat a on ti vysvětlí, co se stalo, pomůže jízdu opravit nebo upravit podle toho, zda máš dovolenou, či něco podobného.

Při Robi zároveň řešíme zajímavý problém s autorizací, protože agent musí fungovat jak před přihlášením, tak po přihlášení. Nikdo přece nechce, aby někdo z internetu mohl editovat jízdy jiných uživatelů. Proto aktivně řešíme, jak zajistit, aby agent správně pracoval s oprávněními a přístupy uživatele, se kterým komunikuje. Tento problém řešíme poslední měsíc a půl a jde o velmi zajímavý projekt. Asi náš největší projekt momentálně osobně je replatformizace celého Jim Beamu. Zahrnuje infrastrukturu a migraci do Google Cloudu. Jedná se o přesun dat z kombinace on-premise a AWS do Google Cloudu, zároveň Kebula migruje z on-premise na Snowflake do Kebuly na BigQuery. Celá infrastruktura a data budou tedy nakonec běžet v Google Cloudu.

Jen co jsme u migrace, zajímalo by mě, když by nás poslouchal někdo v podobné situaci, jaké jsou hlavní rady, jak se vyvarovat problémům? Všude se totiž říká, že to je super jednoduché, že jde o lift and shift jakéhokoliv řešení, vše je otevřené a neexistuje vendor lock-in. Jaké jsou věci, na které si dát pozor? Které části jsou překvapivě náročnější, než se na první pohled zdá, a co naopak už je vyřešené?
Lift and shift to určitě není. Nelze říct, že migrace databáze z AWS do Google Cloudu je hotová za pár minut. Je tam spousta věcí, které je třeba zkontrolovat a otestovat.

Když používáš třeba stejný MySQL na AWS a na Google Cloudu, implementace je přesto trochu jiná. Máš nějaký konkrétní příklad?
Například permissions – oprávnění. To je věc, kterou jsme řešili. Permissions, které fungovaly na AWS, nefungují v Google Cloudu úplně stejně. Například pokud chceš replikovat databázi pomocí CDC, funguje to trochu jinak na Google Cloudu než na AWS. Jsou to nuance, které člověk nečeká, ale objeví během migrace.

Co nám pomáhá je použití nástrojů, jako je Gemini CLI. Já osobně používám právě agenta na převod například Snowflake dotazů do BigQuery, protože syntax Snowflake a BigQuery je hodně odlišná.

Data samotná se zmigrují jednoduše — dump do storage, avi nebo parquet, a načtení do BigQuery. Horší je, aby dotaz fungoval tak, jak má, to je komplikovanější záležitost.

Proto používáme nástroje jako Gemini CLI a vlastní agenty, které umí databázi migrovat, otestovat, dumpnout i naimportovat data a vše spustit automatizovaně. Ty pak spustíš příkaz a migrace běží třeba šest hodin. Ano, přijde ti za to i faktura, ale máš hotovou migraci bez nutnosti manuální práce a dohledu.

Pro ty, kdo nejsou tak hluboko v Google Cloud, co to je Gemini CLI?
Gemini CLI je konkurent Cloud Code. Funguje na stejném principu, máš CLI rozhraní, přístup k LLM (Large Language Model), dáš mu nějaký prompt nebo si připravíš Gemini MD soubor, kde popisuješ, co chceš dělat. Spustíš to a agent to udělá za tebe. Působí to jako magie, ale ve skutečnosti umíš například nastavit oprávnění, přistupovat do G-Sypy, pokud máš autorizaci, a všechny operace dělá s tvými přístupovými údaji.

Pokud to mám shrnout, je to agent pro vývojáře, který udělá velkou část jejich práce. Řídím se tímto heslem: „udělá vše, co lze“. Samozřejmě jsou omezení a je potřeba iterovat a kontrolovat výsledky.

U takových příkladů je klíčové, že nikdy nefunguje všechno na první pokus. Musíš iterovat a vědět, co dělat dál – není to žádná totální magie, ale může to být obrovská pomoc, když přesně víš, co chceš.

Na co si dát pozor při transformacích tohoto typu?
Nejtěžší bylo správně nadefinovat prompt pro Gemini – ten MD soubor nebo systémový prompt. Spustíš to, něco to udělá, ale často to není úplně přesně to, co chceš, tak to iteruješ a upravuješ.

Pomocí správně definovaného promptu lze nakonec zvládnout vše – migraci databáze i testování správných datových typů a kompletnosti dat. Pokud mu to ale neřekneš, že chceš, aby data ověřil, tak to neudělá. Někdy možná sám napadne, že by mohl něco ověřit, ale v 90 % případů dělá jen přesně to, co mu zadáš.

A totéž platí i u nástrojů typu Cursor, když mu dáš zadání na vytvoření aplikace. Pokud zadání není perfektní, model si může „vymyslet“ něco, co jsi nechtěl. Proto je zásadní být co nejkonkrétnější a nejpřesnější při definici promptu a iterovat ho, dokud není dokonalý.

Jak dlouho trvá, než máš správný prompt?
Náš kolega, který migraci zajišťoval, říkal, že od nuly do správného promptu mu to trvalo jeden až dva dny. Když již měl správný prompt, migrace 10 databází proběhla sama během 8 hodin bez nutnosti jeho dohledu.

Co vnímáš jako nejsilnější výhodu těchto nástrojů?
Pro mě je to, že jsou vestavěné přímo do platformy. U všech řešení musíš dát nástroji odpovídající oprávnění a kontext, ale Gemini CLI je přímo součástí Google Cloudu, kde máš například vestavěný terminál, v něm Gemini CLI a můžeš vše spustit přímo tam jako autentifikovaný uživatel, což je skvělé.

Je to pro mě game changer především pro infra a datové věci. S datovými věcmi jsem to zkoušel, je to zatím trochu neohrabané, protože data často obsahují nedefinované edge případy, které je potřeba zvládnout manuálně.

Pokud se nedostaneme k dotazu, tak to myslím shrnu zde.

Pokud potřebujete ještě, mohu přepsat pokračování, až text dopíšete, případně vše doplním.

Dáš, tak prostě to nevysoše z toho, víš, jako spálcuje tu definici. Čili můžete napsat nějaký základní dotaz (query), ale stále, alespoň z mého pohledu, cítím, že potřebuji mít nějakou zpětnou vazbu na to, jak se vlastně ta věc nasazuje (deployuje), a jak vlastně vypadá ta nasazená věc, která se nasazuje do Google Cloudu z datové stránky.

Není to úplně agentní systém, ale je to velká vlna v marketingovém prostoru a v e-commerce. Kde se takové věci pohybují, došlo například u Jim Beamu ke spuštění virtuálního zrcadla. Funkce je taková, že si u jednotlivých produktů můžeš virtuálně vyzkoušet zboží. Vy jste to už nějakým způsobem zkoušeli také. Možná můžeš představit, co to je, co za tím běží?

Jasně. To virtuální zrcadlo, anglicky „virtual try-on“, je služba v GCP (Google Cloud Platform), kde můžeš nahrát například fotografii sebe sama a fotografii produktu, a ona ti ukáže, jak by ten produkt vypadal na tobě. Není to jediný případ použití. Dalším případem použití této služby „virtual try-on“ je například nahrání fotografie modelky nebo modela a následné nasazení produktů na jejich postavu, čímž můžeš iterovat tisíce produktů, aniž bys je musel fotit.

To jsou tedy některé případy použití „virtual try-on“. My jsme se k tomu dostali tak, že jsme to Jim Beamu ukázali právě v den, kdy to bylo oficiálně spuštěno, a řekli jsme si, že by to mohl být zajímavý případ použití.

Kdy to tedy vyšlo?

Myslím, že to bylo asi před dvěma měsíci, kdy to bylo zveřejněno široké veřejnosti, předtím to bylo asi v nějakém preview. Nejsem úplně jistý, ale řekl bych, že to bylo přibližně před dvěma měsíci.

My jsme se k tomu dostali tak, že jsme řekli: „To by byl super případ použití,“ a pak jsme si řekli, proč to hned nezkusit přímo na stránkách Jim Beamu. Naklonovali jsme si Jim Beam stránku, nahráli si to k sobě a naimplementovali API.

Ukázali jsme jim to a oni byli úplně nadšení: „Wow, to chceme,“ a do dvou týdnů to měli nasazené v produkci. Samozřejmě si to museli otestovat na vývojovém prostředí, nastavili nějaká omezení, aby někdo nemohl například vyzkoušet virtuální zrcadlo třicetkrát za sebou. Ale takhle jednoduše se dá demonstrovat něco, co ukážeš klientovi, on uvidí, že to funguje, a pak to chce.

Když klonoval tu stránku, implementoval to samozřejmě pomocí kódování, ne jen pouhým nahráním HTML a CSS. Takže to lze velmi jednoduše a pěkně prototypovat a prezentovat klientovi a ten si řekne: „Wow, to chceme,“ a do dvou týdnů to má na produkci.

To je super a podle mě je to velký paradigmatický posun. Něco, co v tradičním strojovém učení bylo zdlouhavé, se nyní díky Generativní AI a celé této vlně AI stalo rychlým a jednodušším.

Z mého pohledu ty jsi schopný udělat prototyp a ten největší "aha" moment, kdy klient vidí, že to funguje, je velmi rychlý. Prostě přijdeš, ukážeš mu, že to funguje skvěle, že je to „out of the box“ služba Google. Ano, „virtual try-on“ je tam někde k dispozici, jen stačí přidat API a dát to jako tlačítko na stránce. A hotovo. Přesně tak.

Ale vlastně „hotovo“ není, protože dříve to bylo hodně drahé a složité, vyžadovalo to tým datových vědců, kteří do toho zapojují knihovny a open source nástroje. Nyní to máš jako produktivní službu, lepší a jen na jedno kliknutí.

Ale stále zůstává ta implementační práce, přesně to, o čem jsi mluvil. Není složité klientovi vysvětlit, že i když to na první pohled vypadá snadně, tak když jsi to měl na první zkoušku nasazené, tak ten čas dvou týdnů zní dobře, ale co všechno je třeba udělat, abys to mohl dát na web?

Určitě musíš řešit nějaké náklady. Myslím, že i když například „virtual try-on“ může stát zhruba jeden dolar na jedno vyzkoušení – hovořím jen jako o příkladu.

Když si představíš, že ti přijde tisíc uživatelů, znamená to tisíc dolarů za zkoušení. A pokud přijde jeden „malý“ uživatel, který to spustí padesátkrát za den po celý měsíc, tak ti ty náklady výrazně narostou.

Takže kromě toho, že můžeš rychle prototypovat, je potřeba produktivně řešit věci jako FinOps, aby ti náklady nepřerostly přes hlavu.

Taky je nutné řešit bezpečnost, kde se ty fotografie ukládají. Když klient nahraje svoji fotku, nemůžeš ji prostě uložit na otevřený FTP server nebo na veřejný disk, musíš to bezpečně ukládat a pak dávat modelu přístup. Nejspíš to ani nechceš příliš dlouho uchovávat.

Ano, přesně tak. Je to otázka ochrany soukromí uživatelů. Ty fotky někde musíš zabezpečeně uložit, ne na veřejně přístupném místě, protože nemůžeš držet uživatelské fotografie volně.

Takže tyto bezpečnostní a FinOps záležitosti jsou právě ty věci, které tě trápí, když jdeš do produkce buď s agentem, nebo s nějakou AI službou. A netýká se to jen virtuálního zrcadla, ale úplně stejná pravidla platí třeba pro support boty, agenty, se kterými jsem pracoval, kde řešíme, aby agent dělal, co má, aby viděl jen to, co má vidět, a zároveň aby to nezruinovalo finance firmy.

Ten business case je složitý, ne? Když tě stojí jeden dolar jedno vyzkoušení, tak to je mnohem dražší než normální provoz. Když stojí „virtual try-on“ dolar za jedno použití, znamená to, že cena akvizice klienta na tento produkt je o dolar vyšší, což opět mění celý byznys model e-shopu. Kdybys to dělal přes drahé PPC kampaně, získáš sice klienta, ale nekřehkost marže na tom klientovi radikálně klesá.

Tedy, když si zákazník vyzkouší tričko třikrát, ztratíš na marži za tři dolary. To je něco, co musíš řešit správně a správně nastavit. Existují dva přístupy: buď nasadíš a sleduješ, co se děje, a doufáš, že někdo ti nezaplaví systém 60 tisíci požadavky, nebo nastavíš restriktivní limity už od začátku, například že každý uživatel si může „virtual try-on“ vyzkoušet dvakrát na session nebo na uživatelské ID. Když zjistíš, že to omezuje příliš zákazníků, můžeš postupně zvyšovat limity až do nějaké úrovně, která je pro byznys únosná.

Současně tokeny zdražují nebo zlevňují velmi rychle, takže obchodní případ před rokem byl jiný než je teď. S příchodem škálovatelnosti se to otevírá.

Možná podobný příklad, který jsem viděl u vás a kde jste se také angažovali, je Dine for Fit, kalorické tabulky, a přijde mi to hodně podobné nebo ještě radikálnější – můžeš to představit?

Určitě. S Dine for Fit jsme začali spolupracovat začátkem letošního roku. Oni přišli s požadavkem, že by chtěli mít v aplikaci rozpoznávání jídla podle fotografie.

Uživatel nahraje fotku a aplikace mu rozpozná, co je na té fotce za jídlo, a hned mu to přidá do jídelníčku.

Měli nějaké řešení, které fungovalo do určité míry, a ptali jsme se, jestli se to nedá zlepšit.

Hlavní problém byl, že měli strašně moc produktů – myslím, že to bylo asi 300 tisíc produktů v aplikaci.

Mluvíme o potravinách?

Ano, přesně tak. To byla obrovská databáze potravin, které si můžeš v aplikaci vybrat.

Musím říct, že jsem ani nevěděl, že lze koupit tolik druhů produktů. A já pořád točím kolem pěti jídel.

Přišli k nám a chtěli zjistit, jestli se to dá zlepšit.

Problémem byl právě ten počet produktů.

Čím víc jich je, tím víc model začíná dělat chyby, pokud ho nenecháš vybírat jen z omezeného seznamu.

Řekli jsme si, že se zaměříme asi na 20 tisíc nejčastěji používaných produktů, které uživatelé zadávají.

Měli jsme na to analytiku – nešli jsme do toho naslepo.

Vybrali jsme těch 20 tisíc produktů podle toho, kolikrát byly za celou historii Dine for Fit zvoleny.

20tisící produkt byl použit asi 30krát za celou historii.

Takže tím jsme pokryli asi 97 % všech produktů, které uživatelé v aplikaci uvádějí.

To výrazně zlepšilo výkon modelu.

Také jsme bojovali s latencí – když uživatel fotí jídlo a musí čekat 30 sekund na rozpoznání, není to user-friendly a většina lidí by to radši zadala ručně do aplikace.

Snížením počtu produktů na 20 tisíc jsme také snížili požadavky na model.

Zkrátili jsme čas čekání na výstup na 3–4 sekundy.

Tedy uživatel má během této doby uloženu informaci o tom, co je na fotce.

Jsou tam samozřejmě nějaké „okrajové případy“, například lidé fotí jen omáčku – což model nemůže přesně rozpoznat, protože není konkrétní.

Nemůžeš jednoduše říct: „Řekni mi, jaká je to omáčka,“ protože to nebylo zahrnuto v seznamu produktů.

Není to tedy dokonalé, ale naším cílem bylo zlepšit řešení, aby mělo alespoň nějakou úspěšnost.

Zlepšilo to i motivaci uživatelů dále aplikaci používat.

Jak tedy fungovalo předchozí řešení?

Předtím používali také LLM (velké jazykové modely), například GPT-3 Mini nebo podobné, na GCP.

Ale měli jiný přístup.

Model rozpoznal jídlo, například: „Tohle je maso, tohle je rýže, tohle omáčka.“

Na základě odpovědi hledali přes nějaký vyhledávací nástroj (Open Search nebo podobný) nejbližší produkt v databázi.

Často to dělalo nepředvídatelné věci, např. místo banánu vrátilo dva banány.

A začaly se objevovat nesrovnalosti jako „banánový jogurt“ místo „banán“.

Bylo to velmi citlivé na výstup modelu, což působilo problémy.

Nyní je systém takový, že model má přímo přístup jen k těm vybraným 20 tisíc produktům.

Vždy vybírá ze seznamu nejčastějších produktů, které jsou pak zapsány jako výstup.

Takže došlo k posunu v přístupu, jak model přistupuje k produktům.

Předtím se to odhadovalo a vyhledávalo v externí databázi.

Nyní má model omezený přehled produktů přímo zabudovaný.

Používají také novější model Gemini 2.5. V době této implementace trojka ještě nebyla k dispozici.

Gemini 2.5 má milionové kontextové okno, takže lze do promptu vložit těch 20 tisíc produktů a zároveň to funguje rychle.

Celkově to vyšlo i levněji než dřívější řešení.

Protože při každém promptu posílají v podstatě stejný text s různým obrázkem, 98 % promptu je cacheováno.

Cacheování znamená, že za tento prompt platí o 90 % méně než za nový prompt, což jsou asi desetiny ceny.

Pro Dine for Fit je to proto velmi výhodné a výsledky jsou dobré.

Vidím zajímavé dvě věci na konci.

Cacheování je super.

Jak při návrhu architektury AI řešení počítáš s cacheováním v business modelu?

Záleží to na použití případ od případu.

U support agentů a podobných věcí, kde jsou prompty různé, cacheování nebývá tak efektivní.

Ale pokud máš případ, kde se často opakuje stejný prompt, tak cacheování funguje velmi dobře.

Výhodou v Google stacku je, že cacheování funguje automaticky.

Ty nemusíš nic plánovat.

Stačí poslat podobný prompt a Google podle hashe rozpozná, že už byl tento prompt zpracován, a vrátí zapamatující se výstup, aniž by znovu volal model.

Proto záleží na konkrétním případu.

U Dine for Fit byla cache obrovská, ale jinde je to spíše 5–10 %.

Protože tam je tak malá, tak s cache ani nepočítám, je to jen hezký bonus.

Není to nic, na čem bys stavěl celý byznys model.

Druhá věc, která mě zaujala, je, že teď jste to spojili do jednoho kroku.

Během posledních deseti let v oblasti automatizace jsi spíše dělil proces do malých konkrétních kroků pro monitoring a governance.

Ty říkáš, že díky většímu kontextovému oknu dává smysl udělat jednokrokové řešení a dát veškerý kontext do jednoho promptu.

To zní intuitivně proti tomu, co jsme si říkali o automatizaci.

Co si o tom myslíš?

My jsme tento přístup zkoušeli také.

Snažili jsme se vytvořit agenty, kteří byli například specialisté na...

Detekování zeleniny, ovoce, italské kuchyně a tak dále. Tam nastal ten problém, který se stává, když máš na talíři více věcí. A najednou posíláš prompt do jednoho agenta, do druhého agenta, do třetího agenta a tak dále. Kdybychom měli těch více specializovaných agentů, vlastně by nám náklady vycházely výše. A vlastně ty promptovací tokeny by nám z toho vycházely, řekněme, dvakrát, třikrát více, pokud bychom to posílali separátně do každého agenta. Nakonec se nám tedy více vyplatilo a měli jsme i lepší výsledky, když jsme to všechno dali do jednoho kontextu, do jednoho kontextového okna a posílali jsme to v jednom promptu – obrázek se značením a prostě instrukce. V podstatě bereš, že to je tak obecně, že vlastně jeden superagent nebo jeden prompt, jedno LLM, jedno API do něj narve všechno.

Je to cesta, nebo je to specifické právě pro kalorické tabulky? Určitě to není cesta pro všechny. Myslím si, že toto byl velmi specifický use case. Je to hodně nízký use case, který často nevidíš. My tam potřebovali řešit latenci, ty náklady atd. Takže nám právě toto dávalo nejlepší výsledky.

Momentálně u většiny klientů praktikujeme totiž nejvíc ten přístup pomocí multi-agentové architektury. Máš jednoho orchestrátora, nějakého agenta, který nad vším deleguje, nebo který orchestruje a deleguje práci specializovaným agentům. To je přesně ten přístup, který jsme také zkoušeli třeba pro denní feed. Zkoušeli jsme mít agenty na zeleninu, ale tam se nám to nevyplatilo. Přidávalo to zbytečnou složitost, spoustu latence a tak dále. Takže od toho jsme upustili.

Obecně ale pro produkční use case, které máme pro agenty, je lepší je rozdělit do několika specialistů. Například velmi dobrý use case je, jak jsem zmínil, ten marketingový use case, kdy si taháš data z Google Analytics a na základě toho dochází k nějaké úpravě webové stránky. Měl bys mít orchestrátora, měl bys mít specializovaného agenta, který tahá data z BigQuery, z Google Analytics. Pak bys měl analytika, tedy agenta, který data analyzuje. Dále bys měl mít agenta – specialistu na PPC, který ti navrhne, že na základě zanalyzovaných dat doporučuje tyto změny. Potom může přijít „human in the loop“, který schválí, že ano, tyto změny jsou v pořádku, pojďme je udělat. A nakonec agenta, který ty změny na web implementuje.

Důležité je, že každý agent má svůj separátní toolset. Agent na analýzu má přístup do BigQuery, tedy všechny funkce, aby mohl číst data, vidět metadata, tabulky, schéma a podobně. Další agent má businessové instrukce, podle toho, jak chceš, aby vypadala jeho analýza. Pak dáš speciální instrukce PPC agentovi a zase speciální instrukce a nástroje agentovi, který na stránky ty změny provede.

Chceš to mít v produkci nějak segregované, naškatulkované. Chceš tam mít specialisty, ne jednoho dlouhého promptu, kde bys mu říkal, že máš toolset na BigQuery, udělej toto, pod tím udělej toto, potom tamhleto a tak dále, protože tím promptem se ztratí smysl. Lepší je mít specializovaný prompt pro jednoho agenta a říct mu: „Ty jsi specialista na toto, dělej jenom toto, soustřeď se pouze na toto.“

Protože jinak vzniká kontextové přepínání, začne to halucinovat, dělat chyby a blbosti. Je lepší mít specialisty, kteří se zaměřují jen na svůj obor.

Co z toho slyším je, že když máš agenta, který ti tahá data z GA, jeho funkce je širší než jen přepisování PPC, nebo přepisování tvého webu. A najednou ho můžeš použít na jiné věci. To znamená, že nemusíš stavět agenta jen pro tento use case, ale otevíráš tak další možnosti, protože už máš infrastrukturu a můžeš ji rozšiřovat.

Ano, přesně tak. Agenta můžeš definovat jako „shared agent“, znovu použít jeho kód, jeho prompt jinde. To je jeden use case, druhý může být, že chceš, aby na základě dat z Google Analytics vygeneroval marketingovou kampaň. Opět použiješ stejného agenta na BigQuery, změníš mu prompt, aby třeba místo návrhu keywordů vytvořil celou kampaň.

Je to takhle krásně modulární, můžeš to provázat a je to velmi jednoduché a hlavně přehledné.

Za ten rok a půl, co jsme se neviděli, jak se tohle posunulo přímo v Googlu? Jak bych to shrnul – jednak se posunul open source, předtím jsi mohl používat frameworky jako Langchain, LangGraph, Crew AI, ale Google neměl nic. Potom v dubnu Google od nuly vydal ADK, Agent Development Kit. Přitom Google se nezavřel a pokud chceš vyvíjet agenty na GCP, můžeš i nadále používat Crew AI nebo LangGraph, akorát přidali vlastní knihovnu ADK, ve které můžeš psát agenty.

Výhoda... možná bude znít hloupě, ale A2A versus ADK. A2A je filozofie a framework o fungování komunikace agentů, kdežto ADK je konkrétní komponenta, kterou můžeš použít k definování agenta. ADK ti slouží k nadefinování agenta – dáš tam specializované sub-agenty, tooling a další věci.

A2A definuje, jak agenti komunikují mezi sebou. Například když agent dokončí aktualizaci PPC kampaní, pošle druhému agentovi zprávu, že změnil keywords, a další kampaň by se měla soustředit na tyto nové keywords. To je rozdíl – A2A je unikátní, zatímco ADK konkuruje frameworkům v open source světě, jako Crew a LangGraph, které jsou etablované. ADK je v tomhle novinkou. A2A bylo také oznámeno v dubnu na Cloud Next a zatím je to poměrně unikátní framework bez velké konkurence.

Zůstaneme-li u ADK, je tam nějaké specifikum vůči LangGraphu, který je podle mě šampion v této oblasti? Je to vlastně totéž, jen ADK je googlovský framework, přímo „googlovský“, trénovaný na Google? Více méně ano, více méně ano. Když umím LangGraph, ADK pro mě nebude neznámý. Má velmi podobnou syntaxi, definuješ si agenty, má hezké UI pro vývoj agentů, lokálně nebo přímo na GCP.

Google se hodně inspiroval existujícími frameworky. Google je především ingenýrská firma, chtěli mít něco svého a inspirovali se existujícími řešeními. Pokud znáš LangGraph nebo Crew AI, budeš i s ADK pracovat snadno.

Kromě posunu Gemini modelů, o kterých jsi mluvil na začátku, které vnímám také z LinkedInu a dalších zdrojů, je přechod z OpenAI na Gemini brutální. Dříve to byl coding a cloud, teď mám pocit, že Gemini je pro zvýšení produktivity, pro coding a infrastrukturu. Klobouk dolů Google, myslím, že v tomto závodu favorizuji právě jeho. Na začátku to nevypadalo tak růžově, ale teď klobouk dolů.

Zmínil jsi ještě Google stack a ADK – co dál? Vnímám to zvenku tak, že Cloud AI jde prodávat jako základ pro AI a že proto je potřeba být v cloudu, což je logické. Jak je to uvnitř?

Pokud jsi vývojář na GCP, moc se pro tebe nezměnilo. Stále máš přístup k modelům v platformě Vertex, kde pracuješ s generativními modely, třeba Gemini cloud. To zůstává stejné. Velká změna je v přístupu Googlu k integraci AI pro byznys uživatele i koncové uživatele.

Přišli s superslužbami jako je Agent Engine, což je plně spravovaná služba, kde si nasadíš svého agenta, nemusíš řešit infrastrukturu, prostě ho deployneš a máš to jako kontejnerovanou aplikaci, voláš API a dostáváš odpovědi agenta. Máš tam vestavěnou správu sezení, artefakty a další funkce, takže to celé můžeš spravovat z jednoho místa.

Co se týká byznys přístupu, Google velmi tlačí na Gemini Enterprise. Dříve to bylo Agent Space, což se teď přejmenovalo na Gemini Enterprise. Pokud jste slyšeli o Agent Space, je to prakticky stejné.

Gemini Enterprise se snaží dát byznys uživatelům přístup k agentům a k jejich firemním datům. Místo toho, abys musel stavět svého agenta s RAG (Retrieval-Augmented Generation), řešil integraci dat z Google Drive, PDF, a nasazoval agenta někde jinde a uživatelé k němu komunikovali přes třetí stranu – teď máš všechno na jednom místě. Můžeš si pomocí nástrojů no-code či low-code vytvářet agenty a pak je deployovat jako v Crew AI nebo ADK.

Ti agenti nemusí dělat jen jednoduché věci, ale zvládnou i skutečně složité use case. Navíc za pět minut můžeš postavit jednoduchého Gemini spojeného s RAG, který je postaven na vlastních datech firmy.

Gemini Enterprise velmi řeší také bezpečnost. Často když pracuješ s RAG, nahráváš data do svého úložiště a může nastat situace, kdy někdo nemá mít přístup k určitým informacím, ale zeptá se agenta. Gemini Enterprise to řeší „out-of-the-box“ – používá ACL (Access Control Lists). Například vezmeš stránku z Confluence a pokud se tě HR zeptá na interní architekturu, a ona nemá přístup k dané stránce, agent ji informuje, že přístup nemá nebo dokument nenašel.

To výrazně zjednodušuje práci a řeší bezpečnost. Co se týká přístupu k firemním datům, to je další plus.

Ještě jedna věc, kterou jsem možná zapomněl zmínit v souvislosti s vývojáři – kromě Cursora Google nedávno vydal také Antigravity ID, což je podobné jako Cursor, platforma pro „agent-first“ vývojáře. Za poslední rok a půl se v Googlu opravdu hodně změnilo.

Je to přesně tak, jak jsi říkal – před rokem a půl jsme se smáli Gemini 1 a 1.5, že nebyly na úrovni konkurence. Teď za tu dobu Google do toho opravdu hodně šlápl – po stránce modelů, produktů i byznysu.

Když mluvíš o RAGu a Gemini Enterprise, z toho, co slyším, původní use case, který jsem slyšel od všech od chvíle, kdy přišlo OpenAI – knowledge base, interní knowledge base – byly první zakázky, protože LLM odemkly práci s přirozeným jazykem, takže jsi mohl přidat jakákoliv data a něco z nich získat. Tohle je v GCP teď vlastně vyřešené „out-of-the-box.“

Ano, pokud používáš Gemini Enterprise a zaplatíš si to, máš to opravdu hotové. RAG vytvoříš za pět minut, máš vestavěné konektory, které jsou typicky na pár kliknutí. Definuješ, autorizuješ – například chceš tahat data z Jiry, vytvoříš OAuth aplikaci, vložíš client credentials a je to. O nic jiného se nestaráš. Můžeš si nastavit sync jednou denně, jednou za hodinu, jak chceš.

A když přijdeš do Gemini Enterprise a zeptáš se třeba na Jira tickety, systém ví, k čemu máš přístup, a vrátí ti jen data, ke kterým máš oprávnění. Skvělý use case, který vždy demonstruju, je „ukaž mi moje otevřené tickety“. Podívá se do Jiry, vidí desítky ticketů, ale ty vidíš jen ty, ke kterým máš přístup, nebo které jsou ti přiřazeny, či vidíš jen tickety v projektech, ke kterým máš přístup. Inteligentně vyfiltruje ty tickety a vrátí ti pouze ty relevantní.

Také jsou velmi komunikativní integrace Gmailu, Google Kalendáře, Google Drive – pokud nemáš přístup k PDF v Google Drive, tak ti to Gemini Enterprise ani nepřečte. Je to tedy řešené „out-of-the-box“ a nemusíš se bát, že kolega by četl tvé e-maily.

Když se na to tak podívám, jaké jsou tedy nejběžnější use case? Interní knowledge base je fajn, ale stále to někdy nedosahuje hlubších úrovní, protože firmy mají dojem, že mají v dokumentech hodně informací, ale využitelnost není vždy taková.

Co vy jste schopni, nebo co vaši klienti pomocí Gemini Enterprise staví?

Knowledge use case byl vlastně jeden z prvních, které Gemini Enterprise řešilo. Teď už není tak atraktivní use case právě kvůli agentům. Gemini Enterprise ti umožňuje deployovat agenty a zpřístupnit je business uživatelům.

Mnoho use case, které nyní stavíme na Gemini Enterprise, jsou právě agenti – například agenti na automatizaci byznys procesů, například marketing, který jsem zmiňoval. Pracujeme také na agentovi, který pracuje s komplexnější knowledge base. Nejde jen o jednoduchý retrieval dat z knowledge base, ale také o další procesy.

Knowledge base je taková „třešnička na dortu“, kterou lidé v těchto use casech dobře znají, ale není to jediné, co agenti řeší.

Taková atraktivní. Momentálně skutečně ta atraktivita vlastně spočívá v těch agentech. A tam se, jak jsem zmínil, řeší prostě od A do Z úplně všechno. No, univerzální technologie. Přesně.

A moje oblíbená otázka na firmy, co prodávají agenty, je doxidding. Tak co vy, agenti? Popisoval jsi migraci právě na GCP a to, v čem vám to pomáhá. Jak vy používáte agenty interně, jak se vlastně změnila vaše práce, nejen ty use cases a byznysy a to, co prodáváte, ale tvoje práce a to, co děláš ty sám, jak se proměňovala za poslední rok a půl s tím posunem toho Google stacku?

My vlastně používáme interně Gemini Enterprise, protože máme k tomu přístup jako partner. Samozřejmě, pokud bych si to chtěl vyzkoušet sám, můžeš si zaplatit trial a my to vlastně máme jako partner zdarma. Takže my jsme takové testovací laboratoře i pro naše klienty.

Jeden přístup, který se nám velmi změnil, je právě, a osobně to vnímám tak, že přišli za mnou byznysoví uživatelé, kteří chtěli mít přístup k těm našim například billing datům, která máme třeba v BigQuery. My jsme měli vlastně nějaký Looker dashboard, Look Studio dashboard, který byl dostačující, ale někdy byznysoví uživatelé prostě chtěli vidět něco jiného, chtěli si spočítat něco jiného a já jsem neměl kapacitu to upravovat.

Momentálně to řešíme tak, že máme interního agenta, který má přístup právě například k billing datům, a můžeš za ním přijít jako byznysový uživatel, třeba CFO, a zeptat se ho, jaký byl bill tohoto zákazníka za poslední měsíc, nebo jak vypadal jeho outlook, udělej mi forecast atd. A to se mu vše samo udělá pomocí agenta.

Je to tedy hlavně přístup k těm datům pro byznysové uživatele, kteří nejsou možná tak technicky zdatní.

Další věc, která nám hodně pomáhá, je například automatizace těch procesů. Máme automatizovaný invoicing. Dříve jsme měli nějaký proces, který za nás počítal a tak dál. Momentálně na to máme agenta, který má opět přístup k BigQuery datům a zároveň má i nástroje, díky kterým si dokáže stáhnout z ABRY kontaktní informace agenta, vystavit fakturu, poslat fakturu. To nám velmi pomohlo s automatizací.

Jsme vlastně jako Vortex poměrně malý tým, a kdybych to měl dělat každý měsíc úplně sám… Je to servisní práce, nemá to přidanou hodnotu pro nikoho. Přesně tak, je to hygienický faktor.

Moje využití je lépe investované do jiných věcí než do invoicingu a back office supportu. Přesně tak.

Super. A co se týče tvé developer experience?

Jo, mě to velmi pomohlo například s tou migrací. Máme interního agenta, který ti zmigruje tabulku od A po Z. Právě když jsem vzpomínal migraci ze Snowflake do BigQuery, umí si to vytáhnout tabulku, vyexportovat ji do BigQuery, nastavit všechny typy, aby odpovídaly BigQuery, migrovat i popisy tabulky atd.

Zároveň pak vytáhne query té tabulky a zmigruje ti ji.

Agent tu query opět přeloží LLMčkem a zároveň ji otestuje. Není to jen tak, že ti ji přeloží a vyplivne; on si ji přeloží, otestuje a pokud je tam nějaký problém, vrací ji zpět na review agenta, který ti řekne, že ano, to byla chyba, to musíš změnit, identifikuje chybu.

Potom ten překladač dostane tento feedback, přeloží query znovu a zkouší ji opět.

Jedna zajímavá věc, kterou já mám nastavenou, je, že to opakuji pětkrát. Je to kvůli tomu, že review proces a testing proces děláme pětkrát. Ty máš nastaveno nekonečno, ale zase řešíš problém nákladů.

Třeba model ti pošle 3000 řádků query, pošle ti ji pětkrát na překlad, zároveň pětkrát do BigQuery a testuje obrovská data.

Takže je s tím třeba trochu pracovat, aby to dávalo smysl, abychom neutratili obrovské peníze, ale aby nám to zjednodušovalo práci s migrací.

Osobní výsledky, které mám s tím agentem, jsou takové, že mi dokázal přeložit 98 % query „out of the box“ ze Snowflake do BigQuery, aniž bych musel cokoli dělat.

Zbylých 2 % jsou nějaké obskurnosti, například funkce, které se trochu jinak chovají ve Snowflake a v BigQuery. Je to hlavně práce s JSONy a s nested fields a tak dále. To je věc celkem komplikovaná.

I když to modelu vysvětlíš, já osobně jsem neměl úspěch vysvětlit mu to tak, aby to přeložil správně. Takže to je přístup, který používám momentálně.

Jediné, co model zatím nedokáže, je datová validace.

Zajímavé je, že tuto datovou validaci řešil nedávno Vojta Tumaskebuli a bavili jsme se o tom zhruba před dvěma týdny.

On vlastně vyřešil datovou validaci v určité části, já mám agenta a mohlo by se to spojit dohromady.

Takže mít jednoho super agenta, který ti udělá od A do Z to, že ti tabulku zmigruje, přeloží a potom zvaliduje, jestli data jsou správná.

Moje otázka je, je těch 98 % dost?

98 % je super. Ve chvíli, kdy jsi musel předtím psát ruku nebo kontrolovat jeden po jednom, to je krásný.

Otázka je, jak najdeš těch 2 %? Tedy toho se vždy bojím, protože pokud mluvíme o vibe codingu a podobně, tak ty zmiňuješ bezpečnost. Přesně, když si kód píšeš sám nebo používáš autocomplete v IDE, tak si tam nikdy nedostaneš úplně špatně napsaný kód, pokud jej nekopíruješ bez rozumu.

Když ti ale něco vygeneruje agent, je hrozně těžké to zkontrolovat.

Jak k tomu přistupuješ? Je to pro tebe jako juniorní kolega, kterého musíš kontrolovat?

Nebo jak jsi přišel na těch 98 %?

Jak jsi našel ty edge cases?

Bylo to automatické testování a potom nějaká data kvalita?

Většina chyb, na kterých to failovalo, bylo například, že po pěti loopech se dotyčný query nepodařilo spustit. Byla to syntax error nebo data type error nebo něco podobného.

Samozřejmě jsou i chyby, kdy ti vygeneruje query, která ti nedá ty výsledky, které chceš.

Na to jsem přišel až v momentě, kdy jsem dělal datovou validaci.

Máme předdefinované testy, počítáme metriky a na základě toho jsme odhalili chyby.

Stále je tam nějaký manuální zásah, nějaký human-in-the-loop, ať už z mé nebo jiné strany.

Nemáme to plně automatizované od A do Z.

Je to stále migrace, chceš, aby data byla správná.

Těch 98 % mi však ušetřilo hodně času.

Teď už jen kopíruju, hážu to do Data Gripu, chodím řádek po řádku a kontroluju, jestli je to správně přeložené do BigQuery.

Model mi dává nějaký základ, který se snaží spustit, i když to není vždy správně.

Mám pak nějaké base take query, kde vedle sebe dávám Snowflake query a BigQuery query a hledám potenciální problémy.

Nechodím po řádcích, ale spíš to velmi rychle projdu a spouštím, abych našel, kde by se mohl překlad pokazit.

Dávám si na to velký pozor, protože tam je složitá logika, kterou model neumí vždy pochopit.

A co to znamená pro juniory?

Protože ty jsi senior, experti na GCP, jste v tom hluboko.

Kdybys dnes vyšel ze školy, byla by pro tebe práce taková, že 98 % udělá Gemini CLAI a ty pak potřebuješ sama sebe nebo jiného seniora, který to zkontroluje a ví, co hledat?

Určitě to pro tebe neznamená, že junior nebude mít práci.

Pro migrace jsou to skvělé use case, protože to jen migruješ z bodu A do bodu B.

Ale pokud chceš vyvíjet nové use case, třeba streamingové, batchové, datové, infra use case, dostaneš se do bodu, kdy by sis na AI věnoval víc času laděním, než když to uděláš sám.

Určitě je prostor pro lidi, kteří rozumí byznysu.

Myslím si, že velmi oceňovanou vlastností mezi datovými lidmi bude to, že rozumí byznysu.

Umí psát query, ale také vědí, proč byznys chce to, co chce.

Ptají se, proč chcete toto udělat, jak chcete dosáhnout cíle.

Protože když někomu řekneš, aby udělal něco, AI to udělá, ale nezeptá se, proč to děláš právě tak.

Ty jako člověk, pokud máš to povědomí o byznysu, jsi kritický myslitel a ptáš se správné otázky.

Přesouváš se spíš do konzultantské role, kde jsi překladačem mezi byznysem a technickým světem.

Protože to, že to funguje, neznamená, že to funguje pro tebe a tvůj use case.

Přesně tak.

Nebo jsi architekt, nebo konzultant či architekt.

Někdy ti AI gen nebo i jednoduché LLMčko navrhne architekturu, která je komplikovaná.

Dá se udělat jednodušeji, ale LLM to nechápe nebo nemá ten kontext.

Je to třeba nová funkce, která byla vydána před chvílí.

Například já momentálně mám problém s ADK knihovnou, protože je to celkem nová knihovna.

Modely ji ještě neznají.

JGPT něco o ADK ví, protože byl otevřený v dubnu a Peťka asi používá data s cutoffem po dubnu.

Gemini o tom také něco ví, ale nemá nejnovější funkce.

Proto stále dělám research, ať už pomocí nějakého deep research agenta nebo ručně.

Pak to vložím do promptu, abych modelu dal aktuální informace.

Nebo používám MCPI (Multi-Context Prompt Injection), například Kontakt 7, který je specifický tím, že má nasosané primárně GitHub repozitáře.

Pokud je něco v repozitáři později než má GitHub nebo není tam, model to nezná.

Takže z mé strany stále vnímám potřebu zásahu zejména na konzultační a byznysové úrovni.

A když se podíváme do budoucnosti, tak za poslední rok a půl se GCP a AI schopnosti značně posunuly.

Díky vašemu unikátnímu postavení, díky tomu, že vidíte i věci, které nejsou veřejné, nejsou ještě plně vydané, a díky tomu, že s tím pracuješ, co očekáváš, že uvidíme na GCP v příštích 12 měsících?

Co by podle tebe mohlo být zásadní novinkou a posunem?

Myslím si, že uvidíme velký tlak na Gemini Enterprise, který jsem zmiňoval.

Ten existuje v GCP stacku, ale je mířený pouze na uživatele GCP.

Ty můžeš být Azure zákazník, napojit si Azure data, AVS data ze strojky i tady.

Myslím si, že Google bude hodně tlačit právě Gemini Enterprise, aby získal co nejvíce byznysových zákazníků na svoji platformu.

A pak od toho budou následovat další incentivy.

Myslím, že bude obrovský tlak na agenty.

Momentálně agenti aspoň nějak fungují v Google Cloudu, s nimiž musíš komunikovat nebo jim posílat requesty.

Myslím si, že přijde funkce, která umožní agentům být event-based.

Například nahraješ soubor do bucketu nebo někam a na základě toho souboru spustí agent něco s tím souborem.

Google bude toto velmi pushovat a také budou tlačit Gemini modely.

Souhlasím s tím, že bych nyní velmi vsadil na Google, protože mají data, hardware, vlastní TPUčka.

Myslím, že v Gemini se posuneme dál – inteligentnější model, rychlejší, se kterým budeš moct dělat úplně jiné věci než dnes.

Stále si myslím, že jeden z případů použití, který je zatím mimo dosah modelů, je review codebase.

Protože často je codebase obrovská, zaplníš celé context window a čím víc je to naplněné, tím horší je výkon agenta.

Myslím, že bude ještě větší tlak na AI for developers.

Ten začal už s anti-gravity, o kterém jsme mluvili, že je konkurence ke kurzoru.

Také s ADK, kdy Google chce být v agentickém světě.

Budou se tedy posouvat směrem k AI pro vývojáře, ale i agenty pro business uživatele.

Pro mě bylo příjemným překvapením, jak agenti vstupují do produkce.

Když jsme vymýšleli letošní DataDej, dali jsme tomu téma agenti.

Bylo to spíš futuristické, něco jako AGI, nebo něco trochu futuristického, ale…

Díval jsem se dopředu a čekal jsem, že velká část programu bude klasická datová platforma, nějaké implementace LLM, ale že asi třetina obsahu budou agentní systémy jako takové. Překvapilo mě, že většina byla agentních systémů a bylo to praktické, ukázaná platí.

Na druhou stranu mě hrozně baví a pro mě nejdůležitější rozhovor byl s Andrejem Karpatym, který letos moc hezky říkal: „This is not the year of agents, this is the agents decade,“ tedy že toto není rok agentů, ale desetiletí agentů. Říká, že AGI tlačí OpenAI ze svých důvodů, ale agenti a implementace agentů s námi budou tuhle dekádu a ta infrastruktura bude růst i jejich využitelnost.

Jak se na to díváš ty? Je to tak, že to bude trvat déle a bude to postupně růst, anebo za dva roky tady máme AGI a už singularitu, čau? Myslím si, že agenti tu budou déle. Souvisí to s tím, že byla pro ně připravena základna. Když si vzpomeneš, před rokem byl obrovský haló okolo MCPčka. Všichni prostě museli mít MCPčko.

Napojte si systémy a vlastně to, co MCPčko dovoluje, je napojit se právě na tyto systémy. Tím agentům dovoluje napojit se na ty systémy.

Otázka je, jak moc vzdálené je podle tebe to, že brzy budeš mít někde na stránce agenta, který ti na základě fotky tvé ledničky dá na nákup, podle tvých preferencí do nákupu, a také přidá do košíku věci, které ti v ledničce chybí. Myslím, že to není tak daleko. Máš na to už všechno náčiní. Je to jen o prioritizaci.

Momentálně si myslím, že se soustředíme hlavně na agenty pro byznys, aby se automatizovaly byznysové procesy, protože tam jsou peníze. Ale pomalu se začíná i transformace na agenty pro koncové uživatele, kterým zlepší nebo zjednoduší život tím, že prostě mají agenta, který to za ně udělá.

Myslím, že se tímto směrem pomalu posuneme. Je velmi reálné, že za pár let budeš mít v mobilu pár agentů, kteří ti budou dělat tvou denní rutinu nebo denní úkoly, nebo si je nadefinuješ v aplikaci Gemini, deployment uděláš od OADK, prostě tvého personálního agenta, který ti bude dělat věci.

Myslím, že je to velmi reálná možnost a za chvíli se tam dostaneme.

Co se týká AGI, nejsem expert a nevím, jak daleko od toho jsme. Každopádně si myslím, že nás to nečeká v nějakých následujících 12 měsících nebo něco takového. Stále jsme od toho celkem daleko. Bude to zajímavé, až to přijde, pokud to někdy přijde.

Ale souhlasím s tím tvrzením, že je to dekáda agentů. Je na to velký fokus, je připravená celá základna. Máme skvělé jazykové modely, máme výborné modely a vlastně milion frameworků, které ti to umožňují dělat.

Jak říkáš, infrastruktura se pomalu rozvíjí. Začínáme mít služby na správu těch agentů, nebo umožňujeme uživatelům přistupovat k agentům, což dříve možná nebylo možné nebo vůbec neexistovalo.

Je tedy na to velký fokus a myslím, že se to bude pomalu začínat pronikat i do běžného spotřebitelského světa, stejně jako další funkce.

Když se podíváme na tvou práci za 24 měsíců dopředu, co z ní podle tebe zůstane? Co je těžké automatizovat? Je to byznysová znalost, nějaké konzultační nebo architektonické aspekty? Budeš ještě psát dotazy?

Mám takovou vizi, že za 24 měsíců budu někde ležet na Bahamách a budu spouštět všechny agenty z notebooku. Nevím, jak je to reálné, stále se pohybuji v nějakých okrajových případech.

Stalo se mi vždy, že vždycky se našel nějaký okrajový případ, na který jazykový model nestačil, nebo neměl potřebné znalosti, nebo jsem věděl, že raději to udělám manuálně, než abych se babral s Gemini nebo nějakým jiným LM či agentem.

Myslím, že se to automatizuje, ta část, ale zase stále bude existovat nějaký jedno procentní podíl věcí, které mi budou zabírat čas, protože mám znalosti a zkušenosti, které jsem nashromáždil za roky práce v tomto oboru, nebo mám znalost byznysu, protože znám zákazníka, vím, co chce dělat, jak chce implementovat věci, na co si dávají pozor, jaká je jejich bezpečnost například.

Myslím, že osobně bych nevěřil, že AI v nějaké míře nahradí bezpečnostního inženýra.

Třeba banky mají obrovský fokus na bezpečnost. Bylo velmi těžké dostat cloud do bank, teď jsme ve fázi, kdy se do bank dostává AI, ale pořád tam existuje určitá restrikce ohledně toho, jaká data můžeš dát AI, protože pracuješ s klientskými daty, která jdou do cloudu.

Myslím, že to takhle automatizuje hodně můj život. Už se to vlastně hodně děje, ale nemyslím si, že to bude stoprocentní.

A pro mě je důležité, že tu technologii máme, že se zlevňuje, demokratizuje a zrychluje se čas doručení. Jenom to rozšiřuje koláč firem, které pořád běží na Excele a papírech.

Ve chvíli, kdy bude všechno „prokopnuté“, všichni do toho skočí a zase budou potřebovat pomoc, a ten koláč se tedy zvětšuje s tím, jak se zlevňuje a zrychluje.

Podle mě pořád potřebujeme digitalizovat celý svět.

Byl bych překvapený, kolik firem pořád používá Excel na základní reporting.

Během léta jsem pracoval na vedlejším projektu pro jednu firmu, která stále používala Excel a její lidé chtěli Excel používat i nadále.

Stále existuje určitá skupina lidí, kteří mají blok – nechtějí mít BI, chtějí mít Excel.

Takže narazíš na lidi, kteří nechtějí vidět tento pokrok.

Myslím si, že tito lidé pravděpodobně budou existovat, ale pomalu se dostáváme do fáze, že pokud nepoužíváš AI, vlastně nežiješ v dnešním světě.

AI ti pomůže psát kód, automatizovat věci. Software „jí svět“ a AI „jí software“.

Je to přesně tak.

A mimochodem k tomu, co jsi říkal, Hecker, musíš mít pořádek v datech. Nemůžeš prostě nasypat do Excelu a čekat, že ti to vše vyplivne.

Možná k tomu jednou dojdeme, ale stále potřebuješ mít pořádek v datech, vědět, co s nimi chceš dělat a co z nich chceš získat.

Jsem rád za tuto zprávu nakonec, je to hezké poselství.

Pokud tedy chcete mít pořádek v datech a vědět, co s nimi dělat, poslouchejte Datatalk.

Same, moc děkuji za návštěvu, těším se za dalších 18 měsíců třeba, až nám uděláš další update.

Držím palce, díky moc.

Děkujeme pěkně.

Děkujeme, že jste doposlouchali náš podcast.

Díky také našim partnerům a členům Datatalk klubu. Jsou jimi Intex, Sascha, Bystreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, DataMind, Notino a Flo.

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

Nechť vás provází data.