Data Talk #115: Petr Brzek (Langtail)
epizoda#115 | vyšlo | délka | 602 poslechů | permalink | mp3
V dnešním díle podcastu Data Talk přivítal moderátor Šimon zakladatele nadějného českého startup LangTail, Petra Brzka. Co dělá LangTail a proč ho Petr založil? Jak zapadá LLM testování do standardních vývojových a CI/CD cyklů? A proč je v současné době těžké evangelizovat LLMOps best practices? To vše a víc v tomto díle!
Strojový přepis
Dobrý den, já jsem Šimon Panajský a vítám vás v tomto dílu podcastu Data Talk. V dnešním díle máme hosta, Petra Brska, zakladatele společnosti Langtail, která vytváří platformy pro AI testování a obecně pro elementární infrastrukturu. Vítej, Petře.
Díky moc za pozvání a zdravím posluchače.
Petře, Langtail je už druhý český nadějný startup, který se zabývá elementární infrastrukturou. A jak se říká během zlaté horečky – prodávejte krompáče. Jak se stalo, že jsi odešel z tak dobré pozice?
My jsme vlastně byli… Já jsem byl zaměstnaný po naší akvizici ve firmě Ceros a asi tři měsíce po vydání ChatGPT jsme tam začali budovat vlastního AI asistenta. Zjistili jsme, že nebylo úplně snadné dostat asistenta do stavu, kdy nám odpovídal přesně tak, jak jsme si přáli. Strávili jsme spoustu času manuálním testováním a když jsme to konečně dostali do produkce, přišel feedback, že to stále nefunguje dobře. V ten moment jsem věděl, že musí existovat platforma, která nám pomůže automatizovat testování a dostat AI aplikace do stavu, kdy jim skutečně věříme, ba dokonce máme data, že fungují dostatečně prediktabilně. A pak jsem firmu opustil a založil jsem startup Langtail loni. Oficiálně byl založen v říjnu 2023. Nebylo to tedy tvé první startupové angažmá – usuzuju podle toho, že jsi začal svou větu zmínkou o akvizici. Je to tak?
Ano, první startup jsem založil, když mi bylo 22, teď je mi 33. Byl to startup jménem Avocode, který se v češtině vyslovuje „Avokód“. Byl to startup zaměřený na handoff designů, tedy například přenos designů z Photoshopu od designérů k vývojářům, aby mohli nakódovat web. Po asi deseti letech vývoje se nám podařilo firmu prodat. Pak jsem byl dva roky zaměstnaný ve větší firmě, kde jsem zjistil, jak je vše neuvěřitelně pomalé. V tu dobu se mi také narodily děti, takže jsem ten klid ocenil, ale pak mě to přestalo bavit a chtěl jsem zase něco tvořit. V tu dobu byl velký hype kolem AI. S jazykovými modely jsem začal pracovat už dřív, přibližně od roku 2020, kdy vyšlo GPT-3, a bavilo mě to. Ale obrovský nárůst zájmu nastal po oznámení ChatGPT. A právě tak vznikl Langtail.
Jaké to bylo zakládat startup na takhle zelené louce, když ještě nebyli žádní konkurenti, kteří by to dělali dobře?
Myslel jsem si, že konkurence v té době nebyla téměř žádná. Když jsme v Cerosu vytvářeli AI asistenta, opravdu jsme žádné řešení nenašli. Když jsem začal Langtail, později jsem si uvědomil, že těch konkurentů už je mnohem víc. Většina z nich se ale zaměřovala hlavně na vývojáře. Mně však od začátku přišlo důležité směřovat i na neprogramátory, protože do vývoje AI aplikací, například chatbotů, by měl být zapojen celý tým, nejen vývojáři.
Pokračuj, prosím…
Tady je opravený text:
Ser-facing. A samozřejmě je to zábavné vytvářet od začátku novou firmu, protože je to na zelené louce, takže tam není žádný, řekněme, technical debt, není tam nic, nemusí se dělat zbytečné meetingy, nemusí se dělat perfektní…
performance reviews. Musí se dělat one on one, když jste ve dvou, protože to děláte pořád. Už cítím to trauma z korporátu. Je to tak. Pojďme se tedy vrátit k těm personám. Langtail se liší tím, že je nejen pro vývojáře, ale i pro marketéry a core business a pro koho dalšího? V podstatě pro nějaký tým, který vyvíjí aplikaci — v tom týmu je produktový owner, vývojáři, designer, typicky lidé z QA, nějakí testeři. Moje zkušenost je, že když se vyvíjel asistent, vývojáři dělají kód, ale testují to testeri, kteří neměli žádný nástroj, jak to efektivně dělat, nevěděli, jak k tomu přistoupit. A pak třeba lidé z marketingu, ty mnohem víc zajímá, jestli styl odpovědí odpovídá, zda je to v souladu s tím, jak se firma chce prezentovat, jestli to samozřejmě třeba nelže, jestli to nemluví o konkurenci a tak dále. Produkt ownera zase může víc zajímat nějaký high-level overview, možná třeba náklady, kolik to celé stojí. Myslím si, že je to v podstatě nějaká kolaborace, takže to je takto.
Znamená to tedy, že když chci být uživatel Langtailu, potřebuji už mít QA oddělení a marketing, nebo to cílí i na potenciální jednotlivé vývojáře? Úplně upřímně si myslím, že když je člověk sám a tvoří si nějaký… záleží, co vytváří. Pokud si vytváří nějakou demo aplikaci, kterou prezentuje na sociálních sítích, tak to asi nepotřebuje. Pokud chce dělat něco seriózně a je to vývojář, možná to nepotřebuje, protože si věci udělá všechny v kódu. Ale jakmile tam je tým a ten tým musí spolu komunikovat a spolupracovat i třeba s těmi nevývojáři, tam to řešení dává smysl.
Tak pojďme se podívat, co všechno je v tom cyklu možné dělat. Středobodem je tedy testování. Představuji si, že budu mít spoustu testovacích kontextů, nějaký jeden prompt nebo několik verzí promptů a nějaká kritéria, ať už deterministická — že to má být nějak dlouhé — nebo zajištěná modelem (LLM), že to má mít nějakou náladu, nebo že to má být relevantní a tak dále. Představuji si to správně?
Ano, představuješ si to dobře, a možná můžu začít úplně od začátku. Když se vyvíjí nějaká aplikace s language modelem — můžeme to vždycky říkat například u nějakého chatbota, protože je to velmi jednoduše představitelné — tak může být nejjednodušší varianta, že máme jeden prompt, což je nějaká sada instrukcí, která má něco dělat. Může to být třeba rádce na e-shopu, který radí, jaký si máte koupit telefon. Pokud napíšete nějaké instrukce a neotestujete je, můžete si třeba myslet, že opravdu radí jen s těmi produkty, ale…
Pokud chcete, mohu opravit text i dále podle potřeby.
Jistě, tady je opravená verze textu:
Ale pak tam přijdou uživatelé a oni si z toho mohou udělat v podstatě skoro až jako ChatGPT, že se s tím začnou povídat, jestli jim to nepomůže – například s matematikou nebo třeba napsat nějaký Python skript. A v podstatě tak mají zadarmo nějakého chatbota. Samozřejmě, váš chatbot na to vůbec není určený a není jeho účelem na tohle odpovídat. Měl by to zamítnout, měl by říct, že vám pomůže najít třeba ten telefon, ale matematiku si vyřešíte jinde. A pokud na tohle nemáte testy nebo nemáte z těch výsledků z testů žádnou zpětnou vazbu, abyste věděli, jak se to chová v různých situacích, tak v podstatě jenom věříte, že to funguje správně.
Když se dostaneme k tomu, jak ty testy fungují, můžete si to představit jako takový spreadsheet, kde každý řádek je unikátní vstup do daného promptu. Každý řádek se spustí, má k němu výsledek, a na tom výsledku můžeme kontrolovat různé informace. Mohou být přesně deterministické – to jsou jednodušší případy, kdy například prompt něco klasifikuje, třeba sentiment, a já vím dopředu, že sentiment má být třeba pozitivní nebo negativní, takže to mohu kontrolovat čistě deterministicky.
Pak jsou open-ended odpovědi, kde potřebuji použít jiný jazykový model, říká se mu „LM as a judge“ (jazykový model jako rozhodčí), který musí mít nadefinované kritérium, na které se má dívat, a podle toho klasifikuje, zda odpověď toto kritérium splňuje, nebo nesplňuje. Tohle může mít mnoho různých aspektů, a podle mého názoru je to hodně závislé na konkrétním byznysu.
Když uvedeme nějaké příklady: Velmi typickou aplikací jazykového modelu je napojení na externí data, často se tomu říká RAG (retrieval-augmented generation), tedy na nějakou vektorovou databázi. Myslím, že u tohohle testování dává velký smysl ověřit, jestli data, která se vrací z vektorové databáze, jsou relevantní vůči dotazu, který pokládá uživatel. A pak zda odpověď jazykového modelu odpovídá tomu, co dostane za kontext z vektorové databáze nebo z těch externích dat.
Na toto už potřebujete jiný jazykový model, který vám to vyhodnotí. Samozřejmě se může stát, že i tento jazykový model vyhodnotí odpověď jinak, než byste chtěli, a tak se dostáváme do jakési rekurze – i „LLM as a judge“ by měl být otestovaný, jestli skutečně dělá to, co vy chcete.
Nicméně pokud to takto zjednoduším, tak tohle je v podstatě testování jazykových modelů. Pokud vím, jelikož se o to docela zajímám, zatím není žádný lepší způsob, jak zjistit, jestli jazykový model nebo nějaký prompt či agent funguje stabilněji, než jsou tyto dva přístupy: deterministický a pomocí jiného LLM na otestování výstupu.
A ty tedy spojuješ ten deterministický a nedeterministický přístup do „spreadsheet driven development“, což se mi jako datarovi hrozně líbí. O „spreadsheet driven development“ se tedy aplikace dostane do nějakého deployovatelného stavu.
Pokud chceš, mohu pomoci i s úpravou stylistiky nebo formátování.
Jasně, tady je opravený a trochu uhlazený text:
Už tam tedy long tail nekončí, chápu to správně?
Jo, chápeš to dobře.
Když máš testy a výsledky k nim, můžeš v ten moment říct, že – jak říkáme my i všechny naše konkurence – můžeš deploynout with confidence. V ten moment máš totiž nějaká data, která ukazují, že se systém v určitých situacích chová určitým způsobem.
V long tailu je možné prompty, asistenty nebo agenty deploynout, a z toho pak vzniká API endpoint. Znamená to, že instrukce, tooly a funkce jsou uložené u nás a systém funguje de facto jako proxy. Není to však jediný způsob, jak to používat. Spousta firem nechce používat proxy, a proto je tu alternativní způsob: prompty lze stáhnout do codebase vývojového týmu a spouštět je u nich lokálně. Langtail pak funguje spíš jako vývojové a testovací prostředí. V takovém případě to ale nemusí být využíváno pro produkční provoz.
A teď k monitoringu a logování. Ano, monitoring a logování tam samozřejmě také je. Pokud se to používá přes proxy, je to zcela automatické. Pokud vývojáři používají systém asynchronně u sebe v codebase, pak mají k dispozici logovací endpoint, kam mohou posílat data, aby měly zaznamenané interakce s language modelem uvnitř langtailu.
Cyklus pokračuje tak, že i když máte testy, aplikace má samozřejmě své mouchy – jako každá jiná aplikace – a je potřeba sledovat logy a interakce. To může být částečně automatizované: lze spouštět prompty, které anotují, jestli byla interakce v pořádku, tedy jestli nedošlo k něčemu závadnému. Z toho může vznikat nový dataset špatných nebo naopak dobrých odpovědí, který se dá používat jako few-shot příklady pro language model, třeba v roli „soudce“ v testech.
Pojďme se teď trochu bavit o tom, jak složité je přicházet s těmito evolučními datasety a kritérii. Snažíte se lidem s tím pomáhat?
Jo, snažíme. Víme, že je to pro lidi velký problém – představte si prázdný spreadsheet a nutnost psát příklady vstupů do language modelu. Spousta lidí to nebaví. Super je, když už máte nějaká produkční data, ze kterých lze vytvořit datasety. A pokud ne, dají se vygenerovat syntetické vstupy.
To už v Lengtellu máme – říkáme tomu takové „magic tlačítko“, které se podívá na prompt a pokud jsou tam nějaké vstupy, pošle je zpět a vygeneruje příkladové vstupy do language modelu. Člověk je tak nemusí psát sám.
Myslím, že tento proces lze posunout ještě dál – třeba aby language model automaticky testoval různé typy vstupů, různé edge cases a někdy i zcela nečekané vstupy.
Pokud chceš, mohu text ještě více zformálnit nebo upravit podle tvých představ.
Model je na to úplně perfektní. Mohlo by to samopřicházet s těmi promptami? Určitě. My to zatím teda neumíme, teď počítáme s tím, že ten prompt nějak existuje, ale určitě mi to přijde dost zajímavé – že to je takový test-driven development, kdy se teoreticky dá nejdřív přijít s těmi vstupy a s tím, jak bychom si představovali výstupy, co tam je za funkce, co mají kontrolovat, a definovat ta kritéria. A myslím si, že se takhle zpětně dá synteticky vygenerovat ten prompt, který by vlastně splňoval tady jednotlivé checky. Takže si myslím, že to je cesta. Máme tady i nějaké příklady, jako je DSPY. Takže tak.
Upřímně na to teď asi nemáme žádného uživatele, který by to chtěl, ale mně to přijde zajímavé. Pojďme se chvíli bavit o tom, jak ten test-driven development a to LLM testování zapadá do moderních CI/CD pipeline, protože vzhledem k tomu, že výstup jazykového modelu je nedeterministický, asi to nejde tak, že po každém commitu musí být všechno zelené, a když to není zelené, tak jdeme opravit problém. Nedá se to používat. Je to prostě laxní faze test vždycky. Kam to teda podle tebe zapadá v tom vývojářském cyklu?
Jo, já si myslím, že to může být i nějaký task v rámci CI, akorát se musí velmi citlivě nastavit, co znamená, že to prochází. Nutně to taky nemusí znamenat, že všechno prochází stoprocentně. Může to znamenat, že celý test má mít nějaké skóre a třeba se nesmí dostat pod minimální skóre, které už jednou daný test prošel. Například dostali jsme se na 80% pass rate, změníme prompt a víme stoprocentně, že nechceme být pod 80 %. Myslím si, že ještě hodně záleží na tom, co firma s tím dělá. Dokážu si představit, že pokud je to třeba chatbot, tak to může být teoreticky méně důležité než když je to klasifikační úkol, který by měl fungovat skoro stoprocentně. Takže ano, myslím si, že v CI to dává smysl, akorát je to podle mě něco úplně nového a nejsou na to ještě moc praktické zkušenosti, takže se to teprve začíná objevovat.
Dobře, tím jsme docela hezky pokryli většinu toho, co Lanktejho dělá. Myslíš si, že i za rok bude dělat to stejné? Myslíš si, že jste našli ten product-market fit?
Myslím si, že ještě ne. Kdyby ano, tak neříkám, že ne. Upřímně si myslím, že ho teď hledáme. Právě jsme spustili verzi 1.0 a změnili jsme náš positioning – teď se více fokusujeme na testy a na to, aby aplikace byly otestované a stabilní. Předtím jsme mluvili o tom, že jsme spíš generická platforma na vývoj LM aplikací, což taky mohlo být důvodem, že nikdo přesně nevěděl, co to znamená. Takže doufám, že to teď bude fungovat lépe. Byl to takový soft pivot, větší změna směru. Co máme teď v pipeline a roadmapě? Kromě neustálého zlepšování testů jsou to také orchestrace a nějaké workflows, což je skvělé, protože i samy firmy se nás na to ptají, aniž bychom to někde oznamovali, jestli něco takového plánujeme. V podstatě se dá říct, že to jsou vícero promptů, které můžou být… (text končí).
Tady je opravený text s úpravami gramatiky, interpunkce a stylu pro lepší čitelnost a plynulost:
To je v nějakém grafu. Má to vlastně fungovat jako stavový automat. Asi nejjednodušší příklad je, že jsou tam sekvenčně třeba dva prompty za sebou, kdy jeden prompt vygeneruje velké množství dat a druhý jen něco klasifikuje. To je tedy ten nejjednodušší příklad. Na druhou stranu ten nejtíživější případ je, že může existovat více asistentů nebo třeba chatbotů, a pro koncového zákazníka to vypadá jako jeden chatbot. Například na nějakém e-shopu. Může být asistent, který se specializuje na to, že vám poradí, jaký telefon si koupit, a pak může být jiný asistent, jehož odpovědností je řešit s vámi refundy. Ukazuje se, že když se takto asistenti rozdělí a každý má menší svůj rozsah, vede to k tomu, že jsou aplikace stabilnější, než kdyby se všechny funkce nahromadily do jednoho asistenta. Ono by to nějak fungovalo, ale asistent by pak dělal víc chyb. Takže když je na pozadí taková orchestrace, jak jsem říkal, je to stabilnější a mělo by to být něco, co by se v budoucnu dalo nastavit i v Lenktailu. Paráda.
Všímám si, že jim říkáš asistenti a ne agenti. Předtím jsme se trochu smáli, že se vyhýbáš slovu „agent“, protože je to slovo plné hajpů. Jo, já tomu slovu od začátku moc nerozumím. Přijde mi to jako nějaký blockchain, když se to třeba vysloví. Mám pocit, že mu už trochu rozumím, ale je to takové slovo, které když někdo vysloví, nikdo neví přesně, co znamená. Vždycky se to musí definovat, a v tomhle případě mi přijde, že to slovo moc nevystihuje svůj účel. Někteří chápou agenty jako prompt, který má instrukce a nějaké nástroje, rozhoduje se úplně sám, běží v nějakém loopu a dělá všechno autonomně bez zásahu druhých. Takto někdo definuje agenty. Jiní zase agenty definují jako prompt, který má nástroje, a už tomu říkají agent. Mně přijde, že je to spíš nejednoznačné slovo, a radši proto říkám popisně, že jde o prompt s nástroji, nebo o asistenta, který má nástroje, protože u agentů váhám. Ale myslím, že marketingově to může fungovat.
Právě jsem se chtěl zeptat, jestli se tedy můžu těšit na to, až bude Lanktayo 2.0 platformou pro vývoj AI agentů a multiagentních systémů. Jo, asi se podívám, jestli to lidé vyhledávají, a pokud ano, tak to slovo samozřejmě použiju, jinak asi ne.
Když se řekne asistent, tak pro mě to znamená vlastně stavový prompt, což znamená, že to je prompt, který má nějakou paměť konverzace. Když se řekne čistě jen prompt, znamená to, že je bezstavový, takže si nic nepamatuje. To je typicky případ, když se řeší například sumarizace něčeho.
Pojďme se tady bavit o tom, co s vaším produktem skuteční lidé dělají. Vaším hlavním klientem a ukázkovým příběhem, pokud jsem to správně pochopil, je DeepNote, což je skvělý – DeepNote milujeme. Super. Jo, jsme s DeepNotem kamarádi, vlastně spousta lidí z původního Avokoudu šla do DeepNotu.
Pokud chcete, mohu text také trochu zestručnit nebo upravit do formálnějšího stylu. Stačí říct!
Jasně, tady máš opravený text s lepší srozumitelností a gramatikou:
Takže mám tam spoustu předchozích kolegů. DeepNote ve své aplikaci vyvíjí vlastně AI jako pilota, už ji mají dneska v produkci. Myslím, že ke konci minulého roku jsme začali mluvit o testování a DeepNote byl tehdy ve fázi, kdy hledal nějaké řešení. My jsme zároveň věděli, že chceme testování mít u nás v Langtailu, takže to bylo dobré načasování – dělali jsme to ve spolupráci. Udělali jsme první MVP během asi tří týdnů a DeepNote už mohl reálně používat náš nástroj, který mu přinášel nějakou hodnotu. Pak jsme pokračovali v iteracích.
Chápu správně, že jste jim pomohli v momentě, kdy se snažili dostat z nějakých 60 % funkčnosti na 90 i 95 %?
Ano, myslím, že to byl klasický případ, kdy vývojáři zjistili, že existují různé language modely, třeba od OpenAI, Anthropic a dalších, zkusili s nimi něco udělat. Na první pohled to fungovalo, ale neměli žádný pořádný přehled o datech. DeepNote byl v té fázi, kdy to sice fungovalo, ale ne úplně spolehlivě a potřebovali mít větší jistotu. Potřebovali tedy vyšší úroveň důvěryhodnosti.
Pojďme to shrnout, pokud to nevadí. DeepNote je produkt založený na noteboocích, které generují kód – často SQL – a možná i další nastavení těchto notebooků. To znamená, že jejich tréninková data musí zahrnovat kritéria pro to, jestli je ten kód dobrý nebo špatný. Také tam musí být nějaký red teaming, aby pokud DeepNote „magie“ generuje hezké věci například o Hexu, tak aby odmítl mluvit o konkurentech nebo dělat nesmysly.
Ano, tohle všechno mají. Jak jsi říkal, generují hlavně kód, často SQL, takže testovali generování kódu a zajímalo je, jestli je kód korektní a jestli vůbec lze kód spustit. V jejich případě tedy nestačila ani automatická evaluace LMA (language model assessment), ale potřebovali vzít vygenerovaný kód a opravdu ho zkusit spustit.
Statická analýza? Ne, nebylo to statické, šlo přímo o spuštění. Máme například javascriptovou funkci, která může posílat requesty, takže ty si vlastně posílali později a ve svém DeepNotu měli endpoint, který testoval, jestli ten vygenerovaný kód skutečně funguje. Pro ně to bylo klíčové, protože pokud by copilot vygeneroval špatný kód, ten by v notebooku nešel spustit a neměl by žádnou hodnotu.
Je to zároveň docela náročné, protože výsledky testování se hned spustí a podle toho vyhodnocují, jestli to je dobře, i když ho vygeneroval jazykový model, který může i třeba navrhnout „drop all tables“.
Ano, samozřejmě si ten kód spouštějí, nespouštějí to přímo na produkčních databázích apod. Mají dlouholeté zkušenosti s tím, jak spouštět kód bezpečně v nějakém sandboxu. To už je ale spíš záležitost DeepNote, my jenom poskytujeme možnost to vůbec dělat, a takhle to u nich funguje.
Pokud chceš, můžu ti text ještě víc upravit, případně přeformulovat do profesionálnějšího stylu.
Jasně, tady je opravená verze textu:
Oni to použili a pomohlo jim to stabilizovat ty prompty tak, že jim to skutečně generovalo kód, který je spustitelný. Samozřejmě to asi není vždycky úplně bezchybné, ale jak jsi říkal, z nějakých těch 60 % to dostaneš třeba na těch 90 %. Já předpokládám, že jim to ulehčilo jak testování, tak i vývoj.
Jo, jo, když něco takového nemáš a máš na to jenom… vlastně i kdybychom se nebavili o DeepNote, pokud nemáš způsob, jak to testovat, tak musíš mít obrovský overhead tím, že musíš vymýšlet, jak to vůbec otestovat a jak poznat, že to funguje. A to stojí spoustu času a nákladů. Takže věřím, že jim to dost pomohlo zrychlit jejich způsob vývoje a nemuseli všechno dělat manuálně – párkrát to vyzkoušíš a pak to prostě prohlásíš za funkční. Takto můžete vytvořit datový set stovek vstupů, které spustíte, a pak víte, jestli to funguje, nebo ne. A když nebude fungovat třeba pět z těch vstupů, víte, že se můžete soustředit na těch pět, ale pak můžete spustit všechny testy znova a víte, že tam nejsou regrese.
Je tohle, co zažil DeepNote, charakteristické i pro use case ostatních firem a klientů – že začali vyvíjet nějakou AI feature a pak jim začalo hořet, protože nedokázali postupovat bez současného dělání regresních testů? Přišli vám s tím?
Jo, myslím, že to je naprosto ta hlavní cesta, jak to funguje. Firmám, které s tím nemají zkušenosti, se to špatně prodává, protože nevědí, že budou mít ty problémy. Pro nás je super, když si trošku naberou zkušenosti a pak hledají řešení.
Myslím si, že to takhle je – někdo je v týmu nadšený, udělá něco, prezentuje to, všichni zatleskají, ale pak se zjistí, že to nefunguje dobře, když to začnou používat reální uživatelé, a hledá se řešení.
Myslíš, že se to v brzké době začne měnit a lidé si začnou uvědomovat, že ostatní už minulou fázi mají za sebou, začnou mluvit o LLMs, best practices, a součástí toho bude i testovací platforma?
Určitě tam dojdeme, ale myslím, že tam ještě nejsme. V Česku určitě ne. Když sleduju třeba Twitter, tak mě překvapuje, jak jsme stále na začátku. Dozvídám se o knihách a dalších materiálech, které teprve vznikají. Teď to jde tak rychle, že je všechno hned zastaralé. Lidi, co se o to zajímají každý den, už možná znají současné best practices, ale ty, co bývaly před rokem, už dneska neplatí. Takže podle mě je fajn nebýt zatím moc „opinionated“, protože se to mění každé tři měsíce.
Jasně, těžko dělat evangelizaci, když se pořád vycházejí nové a nové modely. Pojďme se bavit o té nepredikovatelné budoucnosti, která se bude měnit každé tři měsíce. Jak to vidíš? Vidíš to ve větší automatizaci, nebo…?
Pokud chceš, mohu pokračovat v úpravě nebo pomoci s dalším textem.
Jasně, tady je opravený text s lepší srozumitelností a interpunkcí:
Ve větším no-code produktu nebo v jiných věcech? Abych tě úplně nenaváděl… Jo, já myslím, že se ukazuje, že se to všechno vlastně bude automatizovat. Myslím si, že ve výsledku bude psaní promptů vypadat tak, že uživatel prostě sdělí svůj záměr a v podstatě to bude takový postupný vývoj — jako když si dneska zapnu voicebota, říkám mu, co chci, a on mi to postupně vytváří. To si myslím, že bude ten správný přístup. Bude to snažší, než kdybych měl všechno dokonale napsat sám.
Bude to vlastně tak, že bude existovat prompt nebo můžeme říct agent, který už bude mít nadefinované best practices pro prompty. My mu řekneme, co chceme, a on se bude snažit něco sám vytvořit. Teoreticky si k tomu může vytvořit i testovací případy. Určitě mi přijde, že to bude tímto směrem, protože nevidím důvod, proč by to tak nemělo být.
Takže něco jako Dev pro vyvíjení AI aplikací, kde celá aplikace je vlastně jakási forma, do které se se strukturovaným výstupem zadávají konkrétní požadavky? Jo, že to pak bude dělat i koncová aplikace samostatně? To se mi zatím jeví jako vzdálenější budoucnost.
Tady vidíme jen nějaké začátky — typu V0, Boltnew, nebo třeba Claude, který má také způsob, jak generovat jednoduché věci; myslím, že i Artefakty to mají a E2B také mají takovýhle open source nástroje. Ale zatím mi to přijde použitelné jen pro úplně nejzákladnější a nejprimitivnější věci. Nedá se tím například vytvořit něco jako LangTel — to rozhodně ne. Můžu tím vytvořit jednoduchou hru pro svoji čtyřletou dceru, to jo, což je samozřejmě super, ale řekl bych, že jsme zatím na začátku.
Záleží i na tom, o jaké časové ose mluvíme. Pokud se bavíme o tom, kde budeme za dva roky, tak třeba už to může být jinak. Myslím si, že to pak může úplně změnit trh s vývojem softwaru, protože už možná vznikne personalizovaný software na míru a cena tvorby softwaru bude téměř nulová. Pak bych očekával, že spousta SaaSových firem bude nadbytečných a zastaralých, a pokud se to tak stane, bude to asi hodně zajímavé.
A co ten no-code? Nebo tohle je vlastně technicky no-code, ale není to ten typický „šťělovací“ no-code? Jo, asi je možné, že no-code se posune do fáze, kdy nebudeme nic manuálně nastavovat, ale budeme to říkat hlasem. Záleží ale, protože hlas není vždycky všude využitelný. Já třeba osobně, když jsem doma a není nikdo kolem, rád píšu — třeba e-maily — tím, že aktivuju nějakou zkratku, začnu mluvit, nějaký model to přepíše do textu a ještě se na to spustí prompt, který z toho udělá profesionálně znějící mail. A to mi fakt šetří spoustu času, protože to nemusím psát rukou.
Dokážu si představit, že tímto stylem navr…
Pokud chceš, mohu text ještě upravit nebo rozdělit na kratší odstavce. Klidně dej vědět!
Jasně, tady je opravený text:
Už vlastně i testuji aplikaci, protože je to fakt velmi pohodlné, když člověk prostě řekne: „A teď to udělej takovýmhle způsobem,“ a za pár sekund vidí výsledek. Je dost možné, že to půjde tímto stylem. Ale třeba takhle – nechtěl bych sedět v open space, kde všichni nahodile mluví nahlas do počítače. Mimochodem, funguje tohle i na české maily? Jo, skvěle. Parádně.
A potom ještě jedno velké klíčové slovo v diskuzích o budoucnosti je multimodalita. Pochopil jsem, že LangTales v tomhle má už nějaká „živlířská“ umístění v ohni. Jo, my se obecně snažíme podporovat všechny velké poskytovatele jako je OpenAI, Google, Anthropic, Lama, Smetou a pak tam je Mistral, který teď mi přijde, že funguje spíš jako takový okresní přebor. Ale když se podíváme na ty velké, tak třeba Google mi přijde, že je v tomhle možná nejvíc napřed.
Google vlastně jeho Gemini modely umožňují vstup už i ve video, audio, obrázcích, PDFkách, CSV souborech a vlastně to vede k úplně novým zajímavým use casům. Dá se vzít video a zjišťovat, jestli v něm něco zaznělo a kde to zaznělo, takže teoreticky jde „hrát“ nad videem, jestli to tak vezme, nebo dělat nějaké vyhledávání ve videu.
Máme jednoho zákazníka, nemůžu uvést jméno, ale jeho startup dělá to, že vyhledává ve videu a používá naši testovací platformu, aby vše fungovalo co nejstabilněji. Mají spoustu videovstupů a vědí předem, jestli v tom videu něco má být, nebo ne, a testují, jestli to vychází správně.
Co se týká vstupů, ale pak se můžeme bavit i o výstupech. Výstupy jsou dnes často textové, ale u OpenAI už je to i audio. To audio zní velmi dobře, skoro jako člověk, a umí nejen tupě něco říct, ale také odrecitovat, zazpívat, říct to dramaticky, zasmát se. S audiem se pak dají zjišťovat i další věci. Když použijeme audio jako vstup, nemusíme získat jen obsah řeči, ale můžeme se ptát třeba na to, jakým stylem to bylo řečeno – jestli byl člověk naštvaný, veselý a tak. To otevírá úplně novou sadu možností.
Všechno si myslím, že bude potřeba testovat – z podstaty věci – jakým způsobem to funguje.
S obrazy to předpokládám bude podobné? Jo, pokud jde o výstup jako obrázek, tak myslím, že teď nevím, jestli to vůbec dělá nějaký model OpenAI, třeba ten „for all model“, ale reálně ještě ne. Testování obrázku asi bude fungovat tak, že to bude vstup do jiného jazykového modelu, který zjistí, jestli tam něco je, nebo není.
Dobře, takže budoucnost je plná videí, obrázků a multimodality. Řekni mi, co bys rád, aby si posluchač, který si z tohohle podcastu oblíbil LangTail, udělal dál?
Jo, budu rád, když si to vyzkoušíte. Můžete jít na stránku langtail.com, zaregistrovat se úplně zdarma a taky je možnost mě kontaktovat…
Pokud chceš, můžu ještě text trochu zestručnit nebo přeformulovat.
Zde je opravený text:
Kontaktovat nás můžete vlastně na LinkedInu, Twitteru nebo e-mailem petrzavináč@langtail.com. Jelikož jsme ještě malý startup, rádi spolupracujeme už i s firmami na tom, co potřebují, takže budu rád, když mi napíšete a zkusíte to. Petře, díky za přijetí pozvání, držím hodně palců tobě i startupu. Děkuji moc a mějte se hezky.
Děkujeme, že jste doposlouchali až sem, a díky také našim partnerům a členům Data Talk klubu. Jsou to: Index, Saska, Bystreet, Colors of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, Datamind, Notino a Flo.
A pokud chcete zůstat v obraze, co se české datové scény a globálních datových technologií týče, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz.
Nechť vás provází data.