Podcast

Dobrý den, moje jméno je Jirka Vicherek. Dobrý den všem, moje jméno je Hinek Valner a vítáme vás u dalšího dílu Data Talku. Dnes k nám do studia zavítal Tomáš Rokos, Gen AI Tech Lead z jedné neupřesněné české společnosti Big Hub. Ahoj Tomáši, vítáme tě. Čau čau.

Jak už velmi atraktivně znějící název Tomášovy pozice — Gen AI Tech Lead — napovídá, dnes se budeme bavit o generativní umělé inteligenci. Pokusíme se však jít pod povrch klasické diskuse, která je všude dostupná. S Tomášem se podíváme na velké jazykové modely (LLM) do hloubky: jak vlastně vypadá jejich implementace a jaký dopad mají na software engineering a datové profese. To je naše dnešní téma.

Než se však vrhneme do samotného tématu, vždy na úvod otázáme naše hosty na jejich životní příběh. Takže ve zkratce — co tě přivedlo na pozici Gen AI Tech Leadu v Big Hubu? Jaká byla tvá cesta, Tomáši?

Studoval jsem na ČVUT na Fakultě informačních technologií (FIT), kde jsem si zapisoval některé datové předměty, ovšem nikdy jsem se na ně příliš nespecializoval a spíše jsem směřoval softwarovou cestou, kterou jsem začal už na střední škole. Ty datové předměty jsem dělal spíše kvůli kreditům. Zajímalo mě to, protože se o tom všude mluvilo, ale nikdy jsem to nevnímal jako něco, co by mě významně ovlivnilo. Spíše jsem chtěl pochopit, proč je kolem toho takový rozruch.

První firma, do které jsem po absolvování těchto předmětů nastoupil, byla startupová společnost SizeID, kde jsem pracoval jako softwarový inženýr, respektive full stack developer. Řešili jsme tam doporučování velikostí oblečení, což byl poměrně datově orientovaný use case. Potkali jsme se tam s problémem, že jsme doporučovali správnou velikost na základě jednotlivých tělesných rozměrů, například délky předloktí, a měli jsme tisíce různých velikostních tabulek.

Lidé se museli nejprve správně změřit, aby dostali správnou velikost oblečení, což však vedlo k mnoha nedostatkům a chybám. To byl počátek mé datové cesty — chtěl jsem vytvořit model, který by dokázal ze základních informací, které uživatel zná, například výšky, váhy, typu postavy, pohlaví, odhadnout jednotlivé tělesné rozměry a na základě toho doporučit vhodnou velikost oblečení, a to pohodlně z gauče.

To zní jako spíše datový než softwarový problém. Ano, skutečně se to rychle přesunulo na datovou oblast. Na začátku jsem spíše pracoval na podnikové části projektu, konkrétně na uživatelském rozhraní doporučovače velikostí, což bylo rovněž náročné.

Postupně jsem se však věnoval čím dál více datové části projektu než softwarové. Velkým přínosem SizeID bylo, že sbírali údaje o rozměrech lidí, dále výšky a váhy, a na základě tzv. „know your customer“ (poznání zákazníka) bylo možné tvořit anonymizované statistiky.

Můžeš nám o tom datovém řešení říci více? Já si to právě představuju tak, že lidé vám nechtěli posílat přesné měření těla jako předloktí, ale zadali výšku a váhu, a ty jsi se z toho snažil tělesné rozměry odhadnout.

Ano, fascinovalo mě právě to předloktí. Kdybych měl vybrat jednu měrnou veličinu, která nejvíce určuje ostatní rozměry těla, bylo by to právě předloktí. Je to taková obecná rada. Velikostní tabulky byly navíc nestandardizované, což představovalo další problém, který se SizeID snažil řešit. Snažili se standardizovat velikostní tabulky tak, aby se vždy měřily stejným způsobem. Každý výrobce si totiž stanovil vlastní systém měření. Dalším datovým poznatkem bylo, že jsme zavedli převody mezi jednotlivými typy velikostních tabulek na základě průměrných hodnot.

A co technicky? Jak jsi k modelování došel?

Je zde jeden akademický článek, který ukazuje, že mezi výškou, váhou a dalšími atributy existují korelace k jednotlivým tělesným rozměrům. Konkrétně tato studie byla provedena na amerických vojácích, kteří byli detailně měřeni. Zjistilo se, že u některých rozměrů jsou vztahy lineární, což umožnilo jednoduchou a přesnou odvoditelnost.

Model proto nemusel být nijak složitý, ale pomohl mi se dostat do oblasti umělé inteligence. Napsal jsem si několik modelů, vyzkoušel různé přístupy a nakonec se pro jeden rozhodl.

Takže tehdy ses zamiloval do data science, modelování a umělé inteligence. Co následovalo?

Začalo mě to opravdu bavit a rozhodl jsem se prodloužit si studium o jeden rok, abych tyto věci mohl opravdu učit od základů, s důrazem na komplexní pochopení. V tu dobu byl také boom neuronových sítí v různých oblastech, takže mě zajímaly právě neuronové sítě. Hledal jsem vhodný Erasmus program, který by mi umožnil spojit teoretické znalosti a praktické zkušenosti. A našel jsem Milwaukee School of Engineering v USA.

Tam je škola částečně financovaná, nebo alespoň podporovaná přímo firmou NVIDIA, kde také studuje CTO NVIDIA. Škola klade velký důraz na nové AI technologie, mají tam například superpočítač a cluster grafických karet.

Začal jsem tam brát všechny předměty zaměřené na tuto problematiku a za čtyři roky jsem absolvoval bakalářský program ve zrychleném tempu. Tím jsem si doplnil a prohloubil znalosti, které jsem předtím neměl.

Zakončil jsem studium docela úspěšně — získal jsem cenu od NVIDIE, neboť jsem vyvíjel řešení segmentace páteře. Problém byl, že mnoho lidí trpělo bolestí dolní části zad a při prohlížení skenů rentgenem nebo jiných zobrazovacích metod lékaři různě interpretovali stav obratlů.

Náš nástroj dokázal automaticky vysegmentovat části obratlů na základě hloubkových snímků (scanů) a tak vytvořit index, který pomáhal určit, které obratle by mohly být vhodné k operaci.

Gratuluji, a konečně se dostáváme k tomu, jak jsi přišel do Big Hubu, že?

Ano, je to tak. Po návratu do Čech jsem psal diplomovou práci a chtěl jsem pokračovat v datové oblasti úspěšněji než čistě softwarově. Big Hub nabízel příjemnou rovnováhu mezi software engineeringem a datovými profesemi.

Ještě než se pustíme do toho, co konkrétně děláš v Big Hubu, rád bych se zeptal, nezvažoval jsi akademickou kariéru? Podle toho, co jsi popisoval, ti to šlo velmi dobře a zní to i zábavně.

Ano, akademickou dráhu jsem zvažoval, ale nikdy jsem se nedostal k jednoznačnému rozhodnutí, že to dělat chci. Produkční use case se mi zdály mnohdy zajímavější. Nechci to úplně odmítnout, ale zatím jsem to odsunul stranou. Taky bych si rád někdy vyzkoušel žít a pracovat v zahraničí.

Děkujeme moc, Tomáši. Abychom se dostali k hlavnímu tématu, který jsou velké jazykové modely (LLM) do hloubky: Jsi v Big Hubu od loňského roku, takže ještě před příchodem GPT 3.5 a GPT-4. Jak ses vlastně dostal k LLM? Už jste pravděpodobně LLM používali, ale co pro tebe znamenal chat GPT před rokem?

Jakmile jsem něco takového viděl, chtěl jsem to hned vyzkoušet. Jsem aktivní uživatel Twitteru, kde se o tom hodně mluvilo, takže nové technologii jsem dal šanci.

Zdálo se mi, že i v Big Hubu o to mají velký zájem. Chtěli jsme to používat pro uživatele a zkoumat, jak by to mohlo pomoci našim klientům.

Účastnili jsme se hackathonu, kde jsme pracovali s datovou sadou a zkoušeli vytvořit nástroje, které by uměly provádět dotazy do databáze a na základě toho generovat grafy pro koncového uživatele.

Tehdy Langchain ještě nebyl tolik rozšířený, používali jsme přímo OpenAI knihovnu a queryovali API endpointy.

Po několika ukázkách lidem i zákazníkům se začaly objevovat další use case, které jsme chtěli vyzkoušet.

Postupně jsme vždy hledali pro danou firmu vhodné využití GPT pro jejich konkrétní business case a nabízeli jsme hotová řešení, která jsme už vyzkoušeli. To nám pomáhalo odlišit se od konkurence.

To zní zajímavě, Tomáši. Myslím, že většina lidí podobný zážitek má — všichni si hráli s chatem GPT na webu, generovalo mnoho zajímavých a někdy i zvláštních textů, byli ohromeni schopnostmi této technologie.

Ale co je další krok, když si řeknu, že to je super a chci z toho udělat skutečný produkt nebo vyřešit konkrétní problém? Kde začít?

Jakmile jsem začal chat GPT používat a zkoušel různé prompty, přirozeně se nabízelo, jak dostat výsledky, které vidím v chat GPT na webu, do vlastního produktu.

Často je pak otázkou, zda použít přímo API daného modelu, nebo použít framework, který umožňuje vyměňovat modely a přidávat logiku, což je často potřeba pro reálné use case.

Například framework Langchain umožňuje budoucí výměnu modelu bez zásahu do aplikační logiky, což s přímým voláním API jednodušší není.

Používáš tedy při stavbě Langchain jako mezivrstvu, aby byla infrastruktura připravená na škálování?

Často ano, Langchain používám, alespoň pro specifické případy. Někdy využívám i přímo OpenAI API, například u nových funkcí, které OpenAI nabízí.

OpenAI zavádí například OpenAI Functions, kde se nevypisuje pouze text, ale může se volat funkce, která třeba dohledá informace na webu nebo v interních databázích a podle toho odpoví.

Takovéto řešení lze realizovat různými způsoby a záleží na konkrétních požadavcích.

Často potřebuji například strukturovaná data, která chci jako výstup, což znamená, že nechci, aby model halucinoval nebo přidával nežádoucí informace.

Je také důležité ochránit aplikaci před prompt injectingem, kdy uživatel zadá záludný dotaz a změní formát odpovědi.

Na základě takových požadavků se pak rozhoduje, zda použít Langchain a jaký model nasadit, aby odpovědi byly přesné a bezpečné.

Můžeš uvést konkrétní příklady dvou extrémů, kdy nemá smysl používat Langchain, protože je to příliš jednoduché a stačí použít jen API, a kdy je nezbytné už architekturu stavět na Langchainu kvůli škálovatelnosti a rozšiřitelnosti?

Určitě. Například při práci s interní dokumentací je to dobře vidět. OpenAI se v API snaží přidat co nejvíce funkcí, které dříve byly dostupné pouze v Langchain frameworku.

Jde o funkce, které umožňují lépe model ladit a zacílit na konkrétní chování. I přesto je používání Langchainu v některých případech stále jednodušší a přináší lepší výsledky.

Pokud chci vytáhnout kontext například z interní databáze nebo části textu jako základ pro odpověď, OpenAI API nabízí základní možnosti, například dotazovat vektorovou databázi.

Avšak u složitějších případů, kde potřebuji například řídit přístup na úrovni uživatelů k určitým částem dokumentace (role-based access), to přímo v API nedokážu nastavit.

V takovém případě je nutné použít Langchain, který umožňuje implementovat vlastní logiku přístupů a další specifika.

V podstatě vše, co přesahuje jednoduché chatování, je logičtější řešit přes Langchain, protože vyžaduje přizpůsobenou logiku.

Super, teď bychom se mohli chvíli zastavit právě u Langchainu nebo podobných frameworků. Dejme tomu, že potřebuji řešit vlastní logiku a už nestačí jen volat API – jsem už trochu zkušený, tak kde začít? Jaké jsou základní stavební kameny takového frameworku?

Jasně, tam pak záleží na tom, jestli potřebuji znovu získat z toho modelu denormalizovaná data, tedy text, a na základě toho ho odeslat, anebo potřebuji například při nějakém use casu hodnocení recenzí zjistit, zda je recenze pozitivní nebo negativní, třeba na škále od jedné do deseti, a také získat informaci o nějaké konkrétní věci, kterou daný člověk kritizoval. Další věcí, kterou budu chtít, je tedy zjistit, co bylo specificky tou věcí, o níž řekl, že je špatná.

A právě zde začíná ta potřeba dostat GPT do nějakého kontextu tak, aby výstup byl v jistém formátu, který z něj dokážu získat. Typicky mu řeknu, že odpověď má být například: „Score: jedna až deset“ a „Kritizovaná věc: něco“. Potom mohu použít například nějaký regex a na základě toho získat data.

Teď například OpenAI umožňuje vytvoření tzv. OpenAI funkcí, kde oni model upravují (fine-tuningem) tak, aby výstup nebyl přímo textový, ale byl přímo ve specifikovaném formátu, který modelu dám. Tedy například požadovat, aby se vrátil JSON, který bude mít první klíč „score“ a druhý klíč „nejvíce kritizovaná věc“. Model pak dohlédne na to, aby data vždy byla vrácena v této podobě, což je pro mě fantastické, protože už nikdo nemůže napadnout výsledky tak, že by změnil kontext modelu nějakým slovíčkem či jiným způsobem, a model pak nevygeneruje výsledky, které bych programově dokázal získat a dále zpracovat.

Samozřejmě LangChain nad tím podporuje nějaký wrapper, který mi také vrátí JSON jako takový, ale často ho musím trochu upravit, aby byl obecnější. A třeba až přijde Google s nějakými také functions, které budou umět vracet výstupy v nějakém formátu, tak aby to dál fungovalo.

Vlastně nepoužívám přímo OpenAI dokumentaci, která je poměrně jednoduchá a mám přístup ke všem funkcím, ale používám dokumentaci LangChain, která je často užitečnější, protože musí lépe abstraktovat všechny ty věci a fungovat na více modelech, jež mohou mít rozdílné implementace a výstupy. Je tedy třeba počítat s tím, že někdy se člověk dostane do fáze, kdy LangChain už je na něj příliš velkou formou abstrakce, pokud chce pracovat s nějakou novou vlastností, kterou OpenAI vydal. Než se taková funkce dostane do LangChainu, trvá to, a je potřeba s tím trade-offem počítat.

Ten trade-off je tedy takový, že je výhodné mít možnost libovolně měnit model, ale na druhou stranu často musím dohledávat specifické vlastnosti pro jednotlivé modely. Ty jsi zmínil, že člověk občas potřebuje model vyměnit, tak o tom můžeš říct více, protože ta standardní představa je, že existuje GPT-3.5, 4K, což je obecná verze, a někdy jsou situace, kdy potřebuji řešit jiný model, třeba speciálně trénovaný, nebo různé velikosti modelů a podobně.

Když to tedy vztáhnu k službám, které dokážou porovnávat jednotlivé modely, jsou tam různé testy, na kterých může být například GPT-4 výrazně lepší než GPT-3.5 Turbo. Když se podívám na tato porovnání, mohu zjistit, kde se vyplatí který model použít.

Základní scénář však často je takový, že zjistím, že nejlevnější model, který mohu použít jako základ, nevyhovuje výkonem tak, jak bych potřeboval. To mohu řešit různými způsoby podle toho, zda je to custom use case, nebo prostě model neodpovídá na základě jasného textu, který jsem do kontextu vložil, zatímco model to nepochopil.

V takovém případě mohu chtít sáhnout po náročnějším modelu, který se v těchto testech umisťuje lépe, nebo mám velké množství dat a potřebuji do kontextu vložit například 30 stran textu. Některé modely už tak velký kontextový okno nemají.

Pak je otázka, jestli chci zaplatit víc a dostat celý obsah do kontextu, nebo dělat zpracování postupně – rozdělit text na části, nechat je sumarizovat, a poté s tím pracovat dál. Samozřejmě, pokud sumarizuji části textu, ztrácím část detailů informace, ale model mi může odpovědět levněji, a někdy je to plně dostačující. Někdy ale potřebuji, aby se do kontextu vešlo více dat.

Zmínil jsi výměnu modelů, ale co alternativa v podobě fine tuningu modelů? Jak k tomu přistupuji?

Jasně, dostat model do požadovaného kontextu často jde i dobře napsaným promptem. Pokud umím model dobře promptovat, mohu ho přimět dělat přesně to, co chci. Fine tuning byl dříve často používán pro to, aby model vždy odpovídal určitým stylem – například aby vykal, nebo aby odpovídal vždy v nějakém formátu.

Fine tuning může zaručit, že model bude častěji odpovídat ve formátu, který chci, než nějakým jiným způsobem. Toto však ne vždy bývá relevantní, a to zejména kvůli OpenAI functions, které nyní umožňují místo fine tuningu jednoduše předat specifikaci, v jakém formátu chci výstup.

Toto značně zredukovalo use casey, kdy potřebuji fine tuning. Za mě bych fine tuning používal až jako poslední možnost. Na začátku je lepší řešit co nejvíce věcí přes promptování a vhodné nastavení kontextu.

Samozřejmě pokud potřebuji, například, aby model znal celý obsah Bible, tak tak obrovské množství dat do kontextu nedostanu. V takovém případě, kdy potřebuji, aby model měl daleko více informací, než má ve výchozím nastavení, a nemohu mu je jednoduše dodat do kontextu, protože by byl příliš rozsáhlý, pak je podle mě validní sáhnout po fine tuningu. Model má informace přímo ve svých vahách, ne jen jako vstupní kontext.

Mně přijde, že promptovací část nabývá na důležitosti, protože vstup se stává klíčovým. Na rozdíl od minulých dob, kdy bylo „špatný vstup, špatný výstup“, je dnes model tak dobrý, že právě prompt velmi ovlivňuje kvalitu výsledků.

Jak to vnímáš ty součástí architektury promptu? Je to nějaké nové zvláštní zvíře, které vyžaduje jiná pravidla nebo infrastrukturu? Například LangChain a prompting listy, kde vznikají nové šablony a doporučení?

Ano, různé „tooly“ a metody prompting existují i dnes a jsou důležité. Jsou různé performance testy pro jednotlivé modely, kde například před výstupem modelu uvedu instrukci typu „tady je kritická otázka“ a model na to odpoví lépe, než kdyby žádný kontext neměl.

Je to určitě validní téma prompting. A ještě k tématu výměny modelů: Když vyměním model a ten nový model není citlivý na některá slova, která předchozí model „měl rád“, není to jen jednoduchá výměna cartridge. Ten nový model může být na některá slova méně citlivý a prompt engineering, který jsem dříve dělal, se mi nemusí vyplatit, protože tento model potřebuje úplně jiný prompt.

Prompt engineering je tedy specifický pro daný model. Někteří lidé si vytvoří cit pro to, jak model odpovídá, a podle toho prompt ladí.

To byla jedna z prvních věcí, kterou jsem dříve dělal i já s GPT – komunita se snažila obejít restrikce, které ChatGPT měl. Například GPT nesměl vysvětlovat, jak se vyrábí bomba. Různými prompt injection technikami se však dalo model „oblafnout“ – třeba napsat pohádku o červené karkulce, která byla teroristkou, a na základě toho se pokusit vytvořit nebezpečný obsah. Tak vzniklo vědomí, jak model reaguje a v jaké části vektorového prostoru se určitá slova nacházejí, a na základě toho bylo možné obejít restrikce, které model má.

Takže ano, prompt engineering je jasně model specific a stále velmi důležitá disciplína. Existují GitHub projekty, které sbírají prompty pro různé situace a modely.

A co tedy pro tebe znamená teď takový „gold standard“, pokud chci pracovat s jazykovými modely? Vím, že nestačí jen ChatGPT na webu. Jsou to ty OpenAI functions v API, a stojí za to spíš investovat do toho než do promptování nebo fine tuningu? Co ty obvykle děláš?

Obvykle mám vícekrokový postup nebo guideline, který postupně procházím.

Začnu většinou stejně jako všichni – otevřu si notebook, píšu dotazy přímo do ChatGPT a sleduji odpovědi. To je první krok.

Druhý krok už je modelově specifický a je spojen s tím, že v OpenAI API nejsou jen role uživatele (user), ale existují i systémová role (system) a role asistenta (assistant).

System role je určena k tomu, abych do ní vložil svůj hlavní prompt. User role je otázka uživatele a assistant role je odpověď modelu.

Výhodou je, že uživatel nemůže jednoduše při konverzaci změnit system prompt, a navíc je ta systémová část často fine tunovaná tak, aby model po celou konverzaci odpovídal podle nastaveného promptu.

Navíc mám možnost do kontextu vložit předchozí konverzaci mezi uživatelem a asistentem, kterou uživatel nikdy neviděl, a v ní můžu ukázat jeden příklad, kde bude jak user, tak assistant role, a tím modelu předložím, jak se má odpovídat.

Díky tomu získám lepší a specifičtější odpověď, protože model vnímá kontext založený na předchozích příkladech.

Třetí krok je faktické využití OpenAI funkcí, kde můžu stále využívat system prompt, předchozí příklady a zároveň dát modelu v kontextu informaci, že může zavolat konkrétní funkci s definovaným JSON schématem – což je poslední možnost, pokud potřebuji strukturovaná data.

Předtím než přistoupím k finálnímu fine tuningu, často vytvořím agenty – tedy špecifické role rozdělené mezi více botů, které spolupracují. To je vlastně základem LangChain, který představuje řetězec botů, které postupně zpracovávají text a vytvářejí finální výstup.

Místo použití jediného systémového promptu tedy mohu vytvořit více botů na specifické úkoly. Například první bot zpracuje uživatelský vstup a vygeneruje klíčová slova, druhý bot podle těch klíčových slov vyhledá informace z databáze a odpoví, přičemž má odlišný prompt.

Tímto mezikrokem je někdy vhodné použít tzv. agenty, a pokud pak už to nepomáhá, teprve potom se vyplatí sáhnout po fine tuningu modelu.

Fine tuning používám až jako poslední krok, protože je nákladnější, zatímco promptování je efektivní a levnější a většinu věcí lze vyřešit právě jím.

Pokud chci jen demonstrovat, že to může fungovat, použiji promptování a agenty, což mi postačí pro proof of concept (POC).

Když vše bez problémů funguje, až tehdy mohu přistoupit k fine tuningu, který ještě zlepší výsledky.

Což pro mě znamená, že kdokoliv s tímto přístupem přijde, má už v ruce něco validního, vidí, že by to mohlo fungovat, a může dále investovat prostředky.

Zmínil jsi několikrát kvalitu výstupů – jak to dobře hodnotit? Často lidé hodnotí spíš pocitově, jestli odpověď dává smysl, ale jak k tomu přistupovat pragmaticky?

Je to další disciplína. Dříve se říkalo, že každý kód by měl mít unit testy – dnes je to podobné. U LLM bych měl mít stanovené prompty nebo vstupy od uživatelů, u kterých chci znát požadovanou odpověď.

Existuje spousta služeb, které toto umožňují a používají se k hodnocení.

To, co bych já dělal třeba při fine tuningu, kdy podle vstupu očekávám určitý výstup, stejné sady vstupů mohu použít i bez fine tuningu pro hodnocení kvality odpovědí modelu.

Pozoruji tedy, jak mi bot zareagoval, a porovnávám jeho odpověď s očekávanou.

(Tvá věta zde bohužel končí nedokončená, předpokládám, že chtěl jsi říct: „pak porovnám jeho odpověď s očekávanou hodnotou nebo referencí“.)

Pokud je potřeba, mohu pokračovat nebo doplnit, ale zde je celý text přepsaný do spisovné češtiny s plným obsahem a v odstavcích.

Jsem profesionální editor českých podcastů.

Úkol: Přepiš text do spisovné češtiny.

KRITICKÉ:

• Zachovej 100 % obsahu
• NIC nevynechávej
• NIC nezkracuj
• Význam musí zůstat stejný

Pravidla:

• oprav gramatiku
• oprav diakritiku
• rozděl do odstavců
• zachovej všechny informace

TEXT přepsaný do spisovné češtiny:

Jde o to, co vlastně očekávám jako odpověď. A pak můžu vlastně vytvořit takzvaný chain, tedy řetězec – je zde nějaký vstup, agent nebo to, co jsem vyvinul, mi dá nějaký výstup, a pak využiji další LLM model (nějakého jiného agenta), který porovná můj výstup s tím, jaký očekávám.

Obecně to můžu udělat i tak, že využiju LLM model bez nutnosti mít nějaká trénovací nebo validační data. Řeknu mu pouze: zhodnoť, zda byla tahle odpověď stručná a zda obsahovala všechny platné informace, na základě kterých bych mohl provést nějakou operaci. To je vlastně další prompt pro tohoto agenta, který může například dát hodnocení v rozmezí od jedničky do deseti.

Díky tomu mám nějaký porovnávací nástroj, pomocí kterého mohu zjišťovat, jak moc se změnily odpovědi nebo skóre modelu, když ho například vyměním. A zrovna… Jo, asi tak nějak.

Jak dobře toto funguje pro ověřování faktů v odpovědích? Popisuješ to tak, že je asi v pořádku, když chci po validačním agentovi také říct, zda odpověď dává smysl, jestli je správně napsaná, jestli je v ní vykání apod. Ale jak dobře dokáže takový agent bojovat proti halucinacím ve faktech, nebo jestli dokáže poznat, že v odpovědi chybí nějaké očekávané údaje?

Halucinace jsou dalším faktem, velkým problémem, který se do jisté míry dá docela dobře řešit pomocí promptu. Řeknu modelu, že pokud dostal informace přímo do vstupu, tak je může použít, a pokud ne, má říct, že neví. Existuje na to specifický prompt, který si každý trochu drží jako své know-how. Tímto způsobem se dá obejít většina takových případů.

Boj s halucinacemi modelu je nekonečný. Ale právě u validačního modelu mu můžu říct, že jeden agent může odpovídat pouze ano/ne. Když mám určité informace, mohl bych na základě nich odpovědět, a pokud ne, dám odpovědi nižší skóre. Tím pádem poznám, že prompt, který jsem změnil, je horší.

Nebo naopak, když z vektorové databáze vracím například kratší dokumenty z naší interní dokumentace (tam se uplatňují i hyperparametry – ne úplně hyperparametry, ale například kolik dokumentů vrátím) a na základě toho přijde odpověď, mohu tak efektivně testovat, jak dobré odpovědi jsou na základě mých změn.

Není to úplně zadarmo, protože platím za několik agentů, kteří se musí spouštět, ale je to efektivnější cesta než prostě nasadit něco do produkce na základě výsledků nějakých testů.

Pojďme se teď podívat, k čemu tuto infrastrukturu vlastně používáte, v čem je dobrá. Takhle to zní hezky, ale asi to bude stále drahé a pravděpodobně to bude mít využití jen v některých případech, nebude to žádný ultimátní holistický model HGIM, který nasadíme kamkoliv a bude jednoduše fungovat. Co tedy v BigHubu právě tvoříte a jaká jsou rozhodnutí?

Vaše zkušenost se tam opravdu propisuje. Máme to hned na několika use casech, přičemž když to používáme, tak často přijdeme za klienty s tím, že už jsme to otestovali a validovali, že ta myšlenka funguje, a už jim to nabízíme s něčím konkrétním, co máme v ruce.

Mohu se ještě zeptat – když vidíš nějaký projekt, co je pro LLM use case? Jaká jsou kritéria, podle kterých si řekneš: jasně, tady bude LLM stoprocentně. A kde se podíváš a řekneš: ne, tady budeme modelovat něco vlastního a LLM bude jenom na závěrečnou odpověď?

Většinou, když vidím něco, na co není natrénovaný už existující model, třeba jak jsem mluvil o recenzích, kde hodnocení od jedničky do desítky je běžné – pokud nepotřebuji z textu získat číslo, tedy nechci přímo číselný výsledek, tak skoro přemýšlím o tom, zda by se LLM nehodilo.

Současně, pokud potřebuji implementovat věci, na které nejsou modely přímo natrénované, nebo pokud by se LLM měl v různých kontextech chovat různě, podle dat, tak se většinou vyplatí sáhnout po LLM, než komplet natrénovat vlastní super model a sehnat kompletní testovací sady.

Když se teď vrátíme k BigHubu, kde nasazujete vaši řešení?

Jedním z velmi zajímavých use case je chatbot pro velkou cestovní agenturu, kde využíváme něco jako co-pilot model. Vpravo je chatbot, se kterým zákazník komunikuje, a například před tím, než najde konkrétní dovolenou.

Často třeba, když dnes potřebuji sehnat dovolenou, tak mě to hodí na nějakou nepraktickou stránku s nekomfortním výběrem typu “najdi si zemi, kam chceš jet”. Tady je zkušenost mnohem plynulejší, není to takový náraz typu “musíš přesně vědět, kam jedeš”, ale chatbot klade otázky podobné tomu, že například baví mě surfování a chci jet na místo vhodné právě na surf.

Robot například doporučí, že surfovat se dá dobře v Portugalsku nebo na Kostarice. Pak se zeptá na základní informace – kolik lidí pojede, na jak dlouho, od kdy do kdy, preferuješ luxusnější hotely či ne.

Vlevo se zákazníkovi zobrazují hotely, do kterých by mohl letět, včetně zajímavostí o nich. LLM se zde používá právě proto, aby uživatel mohl odpovídat přirozenou řečí.

Přesně – to je ta bariéra, kterou dřív nebylo lehké překonat. Nyní můžeme poměrně levně vytvořit kvalitního chatbota. Vlastně, kdykoliv chci, aby chatbot odpovídal přirozeným jazykem, tak se vyplatí sáhnout po GPT, protože výstup není určen pro další stroj, ale pro člověka.

Myslíš si tedy, že chatbot bez LLM už dnes nevznikne? Nebo spíš nebude mít takový rozsah?

Nechtěl bych to úplně zaklepat, ale myslím, že hodně chatbotů přechází na LLM modely. Už jen proto, že mohu získat jak strukturovaná data, tak i přirozeně zpracovanou odpověď.

Zdá se mi, že je to přesně to, co bych chtěl mít například v bance – protože hodně chatbotů v bankách neumí jasně říct, jaké mají možnosti. Když napíšu, chatbot zjistí, že neumí, ale až poté, co jsem prošel několika operacemi.

Naprostá většina chatbotů neumí jasně říct: tuto službu nemám, udělej to přes internetové bankovnictví, nebo zajdi na pobočku. Tenhle chatbot by toto dokázal. To je skvělý use case.

Máte přístup do databáze zákazníka?

Ano, přesně tak. Data se v reálném čase filtrují podle preferencí. Například pokud napíšu, že můžu jet jen na osm dní (předchozí dovolená byla delší), vlevo se mi zobrazí jen hotely odpovídající délce pobytu.

Když řeknu, že jsou tyto hotely drahé a mám rozpočet do pěti tisíc eur, opět se to automaticky přefiltruje. Filtry jsou velmi užitečné i samy o sobě. Nicméně tento způsob se zákazníkům cestovních agentur líbí, protože je pro ně přirozenější.

Podívejme se na architekturu chatbota pro cestovní kancelář. Běžně to běží na LangChainu?

Ano, běží to na LangChainu. Využíváme i OpenAI Functions, kde se například vrací filtry, které předávám do aplikace, a na základě nich se filtruji hotely.

Poté vezmu výstup od cestovní kanceláře, například informace, že hotel má krásné pláže, je blízko pláže nebo baru, případně města, a toto vstupem posílám dalšímu agentovi.

Ten agent z toho pak udělá něco jako další, prodejně orientovaný výstup: tento hotel je skvělý, protože je blízko pláže i baru. Pokud chcete surfovat, v okolí jsou tři surfovací školy pro začátečníky i pokročilé.

Robot tedy umí vybrat ty informace, které z kontextu pochopil, že uživatel hledá, což normálně člověk dělá očima – otevře hotel a hledá, jestli je pro něj relevantní.

Model to umí už rovnou zkonzumovat a vybrat nejdůležitější věci.

Kolik uzlů (nodů) a agentů v LangChainu v té architektuře je?

Jsou tam minimálně tři. Jeden agent filtruje data, tedy na základě dotazu uživatele dokáže například vyhodnotit, že luxusní znamená pětihvězdičkový hotel, a podle toho vyfiltruje.

Druhý agent vezme jednotlivé hotely a doporučí je na základě parametrů. Třetí agent je úplně prvotní – například když říkám: chci jet surfovat, tak on doporučí destinace vhodné na surfování, případně využije databázi cestovky s pěti doporučenými místy, které jsou momentálně populární.

Takže první agent dělá doporučování podle aktivit či dalších parametrů, druhý agent pracuje s hotely na základě vyfiltrování kritérií a třetí orchestruje celý proces.

Pokud bychom chtěli do systému vložit byznysovou strategii firmy – řekněme, firma chce prodávat více zájezdů do Afriky, potřebuje větší marži a větší příjmy z Afriky, takže by měl chatbot častěji doporučovat Afriku – kam by tato logika ve struktuře patřila? Byl by to prompt pro některého agenta, nebo speciální mezikrok?

Toto je jedna z velkých výhod LLM modelů. Normálně by se tato změna týkala přetrénování několika modelů. Tady to stačí jednoduše změnit v promptu a to je velká výhoda.

V konkrétní implementaci by to bylo v doporučovači – v prvním agentovi by se muselo explicitně říct, že určité oblasti (Afrika) mají vyšší prioritu a to z nějakých důvodů.

Současně je potřeba otestovat, aby doporučování bylo relevantní a aby argumenty byly relevantní. Není to tak, že prostě naliji informaci typu “dávejte větší preference Africe”, ale aby ta Afrika měla smysluplné argumenty, proč jí chatbot doporučuje.

Například pokud nabízím Egypt s nějakou zvýhodněnou akcí, ten systém by měl být schopen toto správně zobrazit a ne generovat nesmyslné výsledky.

Co se týče filtrů hotelů, ty se také rankují podle zadaných kritérií – například podle marže firmy. Firma tak může ovlivnit výsledek vyhledávání přímo na úrovni dotazu do databáze.

Co bylo na celé praxi nejtěžší nebo překvapivě nejtěžší? Chatbot use case se zdá jako nejlogičtější použití LLM, ale co bylo při nasazení nejtěžší?

Hodně jsem bojoval s filtry. Některé věci, které se zdají jednoduché – například počet dětí – nejsou úplně jednoduché na implementaci.

Některé hotely totiž například nepřijímají děti mladší deseti let, takže je potřeba tato pravidla znát a interpretovat.

Je důležité pochopit, jak filtry reálně fungují, abych mohl do promptu předat kontext tak, aby je chatbot využíval správně a relevantně. Například když chci, aby ceny byly co nejnižší, ale nechci, aby mi chatbot nacpal jednohvězdičkové hotely, na to je nutné prompt dobře přizpůsobit.

Celkově trvalo nejdéle nastavit promptování tak, aby tyto operace prováděl správně podle očekávání. Je to časově náročnější, než se zdá, a není to nikde moc vidět.

Můžu změnit jen část textu promptu, není to jako přidání nového stovkového řádku kódu. Zdá se, že jsem byl produktivní, ale většinu času jsem si prostě hrál s modelem a ladil prompt.

I když kolem teď máme dobré výsledky, uchopit to správně a nadefinovat, jak hodnotit výsledky, je složité.

Mám dvě otázky. Zaprvé: co se nejvíce podceňuje v celém procesu? A zadruhé, navazuje to – přijde mi, že tempo vývoje je velmi rychlé, že různé technické problémy, které se před rokem či půl rokem řešily, jsou dnes už vyřešené (například funkce, rozsah zpracovaných tokenů apod.).

Lidé nyní počítají, že výpočetní kapacita poroste podle Mooreova zákona a nebudou ty limity tak kritické. Co jsou podle tebe věci, které jsou zatím těžké proto, že jsou na začátku, a co jsou věci, které budou vždycky těžké, protože jsou vlastností LLM?

Nejvíc se podle mě podceňuje důležitost promptu samotného. A možná také to, že LLM nevyřeší všechny problémy.

Existují specifické typy úloh, na které se nevyplatí LLM využívat.

Naopak někdy se lidé příliš spoléhají na LLM, i tam, kde existují hotová, fungující řešení.

Například pilotovali jste filtraci položek z faktur a zjistili, že existuje spousta již hotových implementací.

Já například pro levnější prototyp můžu využít hotovou implementaci, která už umí extrahovat správné kolony z faktury, a nemusím stavět vlastní řešení na LLM.

Konec přepisu.

Pokud budete chtít, mohu pokračovat v dokončení této části, která byla přerušena, nebo pomoci s dalším textem.

Je to prostě hotové v několika modelech. A třeba GPT mohu už použít v nějakém složitějším kontextu, třeba na základě toho – hele, tenhle má nějakou cenu, rozhodni, jestli je s námi dostatečně dlouho. No, to možná není úplně ideální, to je dobrá věc. Ale když vlastně není něco jasně popsané nějakým jednoduchým kódem nebo logikou, tak tam zase mohu sáhnout po GPT, ale vlastně nemusím po něm sáhnout vždycky.

Nebo třeba ty recenze. Jestli jsou ty recenze pozitivní nebo negativní, GPT sice dává konzistentní výsledky, ale má za tím i nějaké uvažování.

Tím, že i ta recenze ho dostane do nějakého kontextu, protože když mu napíšu třikrát předtím „super“, tak se dostane hned do velmi pozitivního kontextu. A třeba nějaký jiný model by tohle nemusel úplně chápat, protože je od začátku navržený na určitý způsob uvažování. Takže úzké, jasně definované kontexty a use case, kde již existuje nějaké specifické natrénované řešení, jsou ideální.

Jo, celé se to tím posiluje – když mám něco konkrétního, specifické použití a mohu to použít, nevidím potřebu využívat GPT vždy. Naopak, když jsou některé věci, kterých se lidé dneska při používání GPT obávají, právě například BI report.

Když GPT vygeneruje špatný BI report, ten skončí ve všech prezentacích a na základě toho se dělají business rozhodnutí. Hodně těchto problémů se dá efektivně řešit. Neříkám, že to řeším tím, že vylepším LLM model, aby byl vždy perfektní – to málokdy dokážu. Dokážu dosáhnout 99 %, ale ono to procento chyb tam pořád zůstává.

A s tímto se dá bojovat například tím, že vygeneruji specifický design pro grafy, které jsou vytvořené skrz LLM. Všichni tak budou vědět, že to bylo vygenerováno pomocí LLM a pokud má někdo tenhle graf v prezentaci, tak všichni vědí, že tento graf nebyl zkontrolovaný data inženýrem nebo někým podobným.

Často fungují takovéhle pomůcky, které zvládnou procesovat určitou část use case, ale při business rozhodnutích je potřeba mít to zkontrolované člověkem. S tímto se dá bojovat různými způsoby, kdy nemusím mít geniální nejlepší model, ale mohu to vyřešit nějakým procesem.

Například u takového grafu upozornění – „K tomuto grafu nevěřte!!! Pozor.“ Mně se líbí, jak teď jsou deepfaky viditelné s tím, že ukazují, co deepfaky umí, a zároveň jasně označují: „Toto je deepfake.“ Protože se lidé bojí, že někdo vezme jejich práci a rovnou ji zneužije bez kontroly, že to nebude ani generované.

Takže chápu tři vykřičníky a možná s tím pracovat ve dvou režimech nebo nějak procesně.

Když se podíváme ještě na use cases a na čem jsi tedy pracoval vlastníma rukama a vlastními LLM, tak jsi zmínil chatboty a cestovní kanceláře. To je poměrně přímočaré a je to nejčastější. Teď jsi mluvil o nějakém „nadbíjači“ (nábíječ), tak co jste dělali s „nadbíjačem“? Nebo je to váš projekt?

Ano, zatím jsme to měli jako testovací projekty, abychom viděli, jak dobře to funguje s role-based access, tedy jak vlastně přistupovat k tomu, kam toho bota reálně pustíme, kam může koukat. A všechny tyto věci, když potřebuji komunikovat, děláme na vlastních datech, abychom mohli poskytovat relevantní zpětnou vazbu, kdy se to vyplatí použít a kdy ne.

Jiným místem, kde jsme to použili, byla jedna nejmenovaná pojišťovna. Když tam je případ nějakého pacienta, pro pojišťováky je důležité projít dokumenty a seřadit je podle časové osy.

Tam jsme vytvořili vícestupňový proces, kde na začátku byly dokumenty, které pacient zasílal. Prošly OCR, byl z toho text, případně tabulky – což je docela zajímavé – GPT umí docela dobře pracovat s tabulkami.

Na základě těch tabulek se pak řadily jednotlivé dokumenty. Například pacient měl úraz tehdy, šel na kontrolu tehdy, nejdůležitější část kontroly byla, že měl třeba rupturu kolene nebo cokoliv jiného, dvakrát mu to zkontrolovali a nakonec byl vyléčen a operace proběhla úspěšně.

Takto se řadí dokumenty, což mi přijde jako velmi dobrý use case pro GPT.

Zároveň agent, který to řešil, umožňoval uživateli komunikovat s tím systémem. Uživatel se mohl zeptat například: „No a kde se stalo to, že mu doktor navrhl tenhle lék?“ Protože se třeba zjistí, proč lék zvolili.

U každé odpovědi bylo jasně uvedeno, že pokud agent nevrátí data ani odpověď, řekne, že neví. To neznamená, že informace v dokumentech není, ale že ji musí sám najít.

Jakmile vrátí relevantní odpověď, je v ní uvedeno: „Tady je relevantní odpověď, z tohoto jsem citoval“, což znamená, že agent používá to pouze jako zrychlení své práce.

Určitě bych použil LLM tam, kde je potřeba něco, co není zřejmé nebo by vás nenapadlo, kam LLM lze použít a bude to skutečně fungovat.

Možná teď, jak přicházejí multimodální modely, by teoreticky nebyly špatné na obrázky. Nás překvapily právě tabulky.

Když mám nějaký specifický typ dokumentu, kde OCR služba dokáže vytáhnout tabulky, a GPT s nimi umí dobře pracovat, mohu agentovi přidat další nástroje, například kalkulačku, se kterou lze provádět sumarizace nebo spočítat něco navíc.

Mohu mu dát také do kontextu, jak funguje matematická rovnice – třeba korelace – a on na základě toho umí data správně dosadit.

Samozřejmě se na to nedá vždy spolehnout, ale funguje to překvapivě dobře.

U faktur jsme měli faktury za energie. Některé byly zálohy, jiné v nějakém měsíci byly jiné zálohy, a GPT z toho zjistil případný přeplatek, protože někdo zaplatil víc, a teoreticky uměl na to upozornit.

Takže pro tabulky mi to přijde zajímavé, a také u obrázků teď, když vyšel GPT-4V, tak Vision by dokázal například říct, z které strany bylo naražené auto, jak velké je poškození, a to vše bez speciálního natrénování.

To mi přijde jako velmi zajímavý use case.

Tomáši, zmínil jsi multimodální modely – je to další velká exploze, která nás čeká.

V čem to může skutečně pomoci? Když pustíš svou fantazii na plno, jaké business problémy nám to může pomoci řešit?

Přijde mi, že to bude velmi užitečné zejména tam, kde není už nějaký specificky natrénovaný model, který danou věc umí.

Třeba pokud mám klasifikaci věcí na obrázku – vím, že na obrázku je auto.

Dneska se trénuje na velkých databázích obrázků, kde jsou tisíce kategorií a dám jedničku, že tam je auto nebo lampu.

Ale tady mohu pomocí přirozeného jazyka hledat i věci, na kterých model nebyl natrénovaný a neměl je v testovacím datasetu, a přesto rozhodovat, jestli na fotce něco je nebo není.

Takže mi to přijde velmi zajímavé.

Nebo tam, kde chci z denormalizovaných dat, jako je obrázek, získat další informace ve formě textu.

Třeba právě cestovky, kdy vyfotí hotel a na základě toho napíše něco o hotelu a jeho přednostech.

Nebo realitní kancelář, kde vyfotím byt a chci, aby napsal, že má hezký výhled, velkou a prostornou obývací místnost a podobně.

Určitě si myslím, že v tomto směru to bude velmi zajímavé.

Moje poslední otázka je taková futuristická.

Bavíme se tady o halucinacích, emergentních kvalitách, jakési emergentní inteligenci u LLM modelů.

Myslíš si, že s multimodálními modely se objeví další vrstva schopností, které jsme do teď neviděli? Něco, co bychom mohli nazývat inteligencí?

Třeba schopnost prostorově vysvětlovat, i když to bere jenom ze jazyka a neumí počítat?

Obrázky se nabízejí, protože vše, co můžu popsat textem, tedy když mám datovou sadu, mohu z čehokoliv udělat textovou reprezentaci.

Myslím, že to teoreticky možné je.

Nabízí se například copilot pro Blender. Dnes je docela těžké vymodelovat nějaký model.

Takový copilot by mohl popisovat, co je na 3D objektu, a uvést i možné úpravy.

Na konci pipeline by mohla být 3D tiskárna, která to pak vytiskne.

To by mohlo být zajímavé.

Kdybych měl ale říct, co bude příští velká věc, tak musím říct, že nevím.

Obrázky mi přijdou už teď obrovský pokrok a kam to dále povede, na to si netroufám odpovědět.

Moc ti děkuju, to je také osvěžující a super odpověď, že ne všichni vědí, co se bude dít v budoucnu, a když nevědí, dokážou o tom otevřeně mluvit.

Děkuju za tuto odpověď a za všechny předchozí odpovědi, za know-how, které jsi s námi sdílel.

Doufám, že naši posluchači se vrhnou do stavění vlastních langchainů a vytvoří nad nimi skvělé věci.

Díky moc, Tomáši, a přeji, aby všechny další velké věci, které přijdou, byly pro tebe jenom dobré.

Já děkuju moc za pozvání.

A to je všechno.

Děkujeme, že jste poslouchali až sem, a děkujeme také našim partnerům: Big Hub, Rekombi, Intex, Nanoenergies, Life Sport, Sase, Bystrytum, Colors of Data, Revol BI a Gudate.

Pokud vás zajímá více z české datové scény a datových technologií globálně, zanechte nám e-mail na datatalk.cz nebo se přijďte podívat na některý z našich meetupů – je tam i CZ.

Nechť vás provází data.