Rizika zavádění GenAI v současné fázi technologického vývoje

Tento článek je závěrečným shrnutím dvou předchozích, zabývajících se využitím generativní umělé inteligence v inovačním procesu. Budu v něm primárně diskutovat to, jak by firma měla reflektovat ve svých úvahách nebo v již probíhajícím nasazení řešení postavených na GenAI, současnou fázi vývojového cyklu těchto technologií. Důvodem proč by společnost vůbec měla o těchto věcech přemýšlet je spojena hlavně s faktem, že současná fáze vývoje představuje větší riziko zmařených investic, tedy nenaplnění ekonomických očekávání. V článku se budu věnovat tomu, jak je toto riziko rozdílné pro různé způsoby využití GenAI. Nemáte li příliš času, na konci článku najdete stručnou sumarizaci.

Na úvod, ale trochu teorie. Podívejme se jak úzce souvisí adopce nových technologií s tím, jak roste jejich výkonnost/schopnosti v čase. Přestože se generativní umělá inteligence prakticky objevila až v roce 2022, neznamená to, že by se s ní objevila všechna řešení, ke kterým ji nyní začínáme využívat. Příkladem může být například sémantické vyhledávání. Již v 90. letech popsal Sir. Tim Berners-Lee vizi Sémantického Webu, tedy koncept, který měl svět World Wide Web učinit více inteligentním a užitečnějším díky umožnění počítačům porozumět významu informací. Ano, ten samý člověk, co "stvořil" WWW. Skok dopředu v čase a Google představuje v roce 2012 Knowledge Graph. Knowledge Graphs reprezentují reálné entity a jejich vztahy a umožňují vyhledávačům porozumět kontextu dotazů. Další skok a v roce 2018 je tady první transformer model BERT od Google, který umí vytvořit z textu významovou reprezentaci popsanou vektorem a umožňuje tak významové hledání díky porovnávání podobnosti vektorů. A pak to jde dál, generativní umělá inteligence velmi významně posune pochopení přirozeného jazyka díky představení LLM a umožní tak např. rozvoj RAG.

S-curve model popisující vývoj výkonnosti technologie ve fázích v čase

V tomto zkráceném příběhu vidíme, že vývoj nových inovací má určitou dynamiku, kterou jsme schopni popsat. Navíc má tento vývoj několik fází, podle toho jak se dynamika mění. Použiji li cyklický model pro technologické změny, který se nazývá Dominantní design (Anderson a Tushman, 1990), mluvíme o čtyřech fázích: Discontinuity, kdy stávající technologické možnosti v našem případě vyhledávání informací dosáhly vrcholu, a dominantní Google již se stávající technologií nedosahuje nějakých zásadních přírůstků ve výkonnosti. Zároveň se již nějakou dobu začínají objevovat nové technologie. Nejdříve Knowledge Graph a později BERT, ne zcela náhodně obě technologie opět od Google, a později LLM od OpenAI. Tyto nové technologie jsou ze začátku marginální, míra adopce je nízká, to platí určitě pro BERT s OpenAI to mělo rychlejší švih, i když ne tak zcela ve firemním prostředí. V další fázi nastupuje raketovým způsobem velké množství dalších firem s jejich produkty a začíná dramatičtější rozvoj schopností nové technologie. Této fázi, ve které nyní jsme, se říká příznačně Ferment. Co je pro tuto fázi charakteristické je zároveň dynamičtěji rostoucí míra adopce. Tato adopce je ovšem stále ještě brzděna tím, že je příliš mnoho různých technologií, není zajištěna interoperabilita, zato je značná nejistota spojená s budoucím vývojem. Jsem li zákazník, mám investovat do technologie A nebo B nebo snad C? A bude firma s technologií A ještě za dva roky vůbec existovat?

Jak asi tušíme z názvu modelu, tím zlomovým okamžikem, který vede k masivnímu rozvoji schopností nové technologie, která podněcuje také mnohem vyšší míru adopce je dosažením konsensu mezi klíčovými stakeholders na tom, jak by měla daná technologie fungovat z pohledu standardů, protokolů a podobně. Ne nadarmo se tato fáze nazývá Dominantní design. Z velké míry je tato změna tlačena také externími hráči. Často se jedná o velké zákazníky nebo jejich vlivové organizace, které chtějí mít jistotu budoucího rozvoje a tím předvídatelnější návratnost vložených investic.

Tak to by bylo k teorii vše. Má li někdo zájem věnovat se tomuto tématu hlouběji a dozvědět se, která je ta čtvrtá fáze, doporučuji článek výše uvedených pánů, Technological Discontinuities and Dominant Designs: A Cyclical Model of Technological Change v publikaci Harvard Business School nebo článek od profesora Christensena The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, který vyšel v MIT Press.

Nyní bych se již dostal k technologiím, které jsem doporučoval využívat v inovačním procesu v předchozích článcích. Čemu by firmy měly věnovat zvýšenou pozornost a kde jsou rizika spojená se současným stavem vývojového cyklu generativního AI menší.

V následujícím výčtu se nejdříve dotknu využití generativní umělé inteligence jako copilot, tedy pomocník integrovaný většinou s kancelářskými aplikacemi, ale nejen. Je logické, že takovéto využití je spojeno s vlastním software/aplikacemi a tudíž přestanu li platit subscription Google zahrnujíc GenAI, tak nebudu již moci používat jejich copilota v rámci Docs nebo mailu. Nějakou funkcionalitu copilotu implementovala do svého software většina výrobců a kdo ještě ne, tak na tom určitě pracuje. Absolutně drtivá většina ovšem používá GenAI jako komplementární technologii. Rizika jsou v této oblasti primárně spojena s proprietárními formáty dat, kdy jednoduchý přechod mezi firmami je téměř nemožný. To ale není způsobeno GenAI. Používám li na prezentace Tome a pak se mi více zalíbila Gamma, tak se holt musím smířit s tím, že mi některé prezentace zůstanou v Tome nebo si je maximálně vyexportuji jako pdf. V dalším možném scénáři tyto firmy někdo převezme a jejich produkty postupně propojí se svými. Jako to Adobe chtělo udělat s Figma nebo to dotáhla Canva s Serif (Affinity). Tady největším rizikem je, že na více konsolidovaném trhu budou růst ceny subscription, případně bezplatné služby se stanou placenými. Znovu ale zopakuji, to se dělo vždy a nyní je to jen zřetelnější. Nových firem, které mají nějakou aplikaci "poháněnou" komplementárním jazykovým modelem vznikají stovky.

S minimálním rizikem můžeme určitě ve firmě zavést používání jazykových modelů ve formě co-intelligence, tedy způsob, kdy umožníme zaměstnancům využívání frontier jazykových modelů pro zvýšení produktivity jejich práce. Ještě před rokem byla schopnost maximálně využít jazykový model dána primárně schopností sestavit prompt, který z modelu dostane to nejlepší. Zároveň se jazykové modely dosti lišily ve způsobu, jakým s nimi pracovat. S nástupem poslední generace reasoning modelů ať již od OpenAI, DeepSeek, Anthropic nebo Google se tyto rozdíly dosti stírají. Schopnosti modelů se posunuly díky tomu, že jsou "dotlačeny do vnitřního přemýšlení", podobně jako to předtím bylo možné jen použitím pokročilých prompt technik typu Chain-of-Thoughts, Few-shots apod. V této chvíli není problém, aby firma používající ChatGPT přešla velmi rychle na využívání třeba modelů z rodiny Gemini, Claude atd.

Co je ale potřeba mít na paměti, že jakékoli využití dlouhodobé paměti LLM, ať již pro analýzu dat nebo chat nad firemními dokumenty, ke kterému se využívají služby s názvy jako GPT u OpenAI nebo Projects od Anthropic, případně to, že si model díky této paměti pamatuje řadu našich dlouhých konverzací nebo můžeme model přizpůsobit svým požadavkům, jsou spojeny pouze se zakoupeným subscription. Tedy, když ukončím subscription, v bezplatné verzi k těmto službám ztratím přístup. Tomuto přizpůsobení jste věnovali nějaký čas a o tuto investici přijdete přechodem na jiný LLM. Zároveň budete muset znovu věnovat čas na přizpůsobení nového modelu. Můžete si alespoň uložit systémové prompty pro opakované použití. Je ovšem potřeba mít na paměti, že zatímco obsahově jsou systémové prompty mezi různými LLM velmi podobné. Pro jejich optimalizaci je potřeba jejich rozdílná struktura. Pro Claude je např. ideální strukturovat prompt pomocí XML značek, které naopak ChatGPT nebo Gemini nepoužívá.

Podobně nízké riziko je, využívá li firma místo webové stránky s chatbot ke komunikaci s modelem API. Změna spojená s přechodem na jiný model není nákladově příliš významná. Naopak využití různých modelů pro různé požadavky, je velmi výhodné. Vzhledem k tomu, že firma platí za spotřebované tokeny, může různé činnosti realizovat s různými LLM. Pro interní chatbot může využívat Claude 3.x Haiku, pro zpracování dokumentů MistralOCR a pro speech-to-text Speechmatics. Případně pro své potřeby specificky upravené otevřené modely provozované v rámci cloudových poskytovatelů jako Google, AWS, Groq, Azure atd. Změna modelu a předělání API je pro zkušeného programátora práce na hodiny.

Nyní bych se zastavil u oblastí, kde stávající ranná (ferment) fáze technologického vývoje již představuje pro společnosti značnější rizika. Jednou z těchto oblastí je právě na začátku záměrně popsaná oblast znalostních bází nebo obecně to, čemu se říká RAG a s ní související sémantické vyhledávání. Tato řešení používají několik technologických komponent, které jsou spojené s vyšším rizikem. Jednou z vždy používaných technologií, jsou transformer modely typu encoder nazývané embedding modely nebo také někdy zkráceně embedders. Jejich účelem je mapovat vstupující text (případně audio/video) do multidimenzionálního vektorového prostoru (1000+ dimenzí), kdy pozice vektoru v tomto prostoru reprezentuje sémantický význam příslušného text. Tedy, když "plníte" RAG/znalostní bázi dokumenty (obrázky, video atd.) a poté když se ptáte chatu a ten váš dotaz opět pošle do embedderu, aby z něj udělal vektor pro vektorové hledání na základě cosine similarity nebo Euclidean distance mezi ním a vektory uloženými ve vektorová databázi.

Různé embedding modely vytváří různé vektorové prostory, které nejsou mezi sebou vzájemně porovnatelné. Začnete li v rámci RAG/znalostní báze využívat nějaký embedder, znamená to, že bez toho, aby jste znovu vektorizovaly všechna uložená data, nejste schopni tento model změnit. To samé platí nejen pro modely od různých výrobců, ale také dost často pro modely od jednoho dodavatele.

Co z toho vyplývá? Důležité je držet si dobře připravená data. Nepoužívejte vestavěné transkripční modely pro audio/video data. Udělejte si transkripci zvlášť a RAG "krmte" až vašimi připravenými textovými daty. Dokumenty v PDF/Office předpřipravte do JSON nebo Markdown a teprve pak pošlete do RAG. To samé platí u obrázků. Udělejte si popisy obrázků v Markdown zvlášť. Podobně nepoužívejte vestavěný web scrapping. Vytvořte si opět data stáhnutá z webu ve formě JSON nebo Markdown. Tento postup vám neušetří peníze spojené s vektorizací pomocí jiného modelu, ale budete mít alespoň co vektorizovat. Výběr vhodného vektorového modelu je tak otázkou velkého významu, zvláště je li v současné době trh značně atomizovaný. Tedy nikdo nemůže vědět, který model tady bude ještě třeba za 3 roky. Zároveň při konsolidaci firem může dojít k omezení interoperability. Nedávno jsem psal, jak firma MongoDB koupila společnost Voyage AI. Voyage AI stojí za technologicky velmi pokročilými embedding modely, které mají menší počet dimenzí, tedy nižší náklady na vektorizaci a rychlejší hledání, oproti konkurenčním modelům. Jejich modely nyní umožňují využít řadu vektorových databází. Bude ovšem tato situace platit za rok, za dva? Umožní společnost poskytující databázi MongoDB propojení nyní již svého embedderu na konkurenční databázové produkty? Těžko říci. Mají společnosti používající Voyage AI embeddery odejít, když nechtějí v budoucnu přejít na MongoDB? Pravděpodobně ano. Nyní budou vektorizovat podstatně méně dat než třeba za rok. A takovýchto konsolidací trhu bude v tomto a následujících letech hodně. My můžeme doufat, že velcí zákazníci dotlačí firmy, aby vytvořili něco, co umožní jednotný "standard" v této oblasti a co nejdříve.

Další technologií, která se u RAG vždy používá jsou vektorové databáze. U nich je situace o něco málo jednodušší. Řada poskytovatelů vektorových databází umožňuje exportovat uložené vektory v JSON nebo CSV formátu. Důležité ovšem je, aby umožnili exportovat také asociovaná metadata, jako originální textové chunks, dokument IDs atd. Navíc každý, kdo se pohybuje ve světě IT delší dobu tuší, že jakákoli datová migrace, zvláště pak u takto mladé technologie není nikdy bez problému. Tady je velkou výhodou provoz v cloudové infrastruktuře, kde ty největší cloudový poskytovatelé nabízí alespoň nástroje pro migraci.

Změna ostatních technologických komponent u RAG, tedy hlavně jazykového modelu, je již zcela bezproblémová. Pakliže používáte Reranking model pro zlepšení výsledků, jsou tam jistá omezení, ale stále je to v porovnání se změnou embedderu nebo migrací vektorové databáze podstatně jednodušší.

Je řada dalších technologií a jejich kombinací v rámci různých framework. Některé tyto framework umožňují postavit například různé agenty. Změnit LLM v rámci agenta je složitější neboť každý LLM kromě jiného API (to nejsnadnější) má hlavně jiné způsob volání funkcí a nástrojů, optimální nastavení modelu, zpracování výstupů z modelu. Vždy po změně bude nutné znovu odladit a optimalizovat agenta. U těchto Agentic řešení jsou ale mnohem zásadnější rizika spojená s business očekáváními a projektová rizika než rizika spojená s vývojovou fázi technologie GenAI jako takové. Tím se již dostávají mimo námět mého článku.

Stručné shrnutí

• Fáze technologického vývoje: Generativní umělá inteligence se nachází v dynamické, neuspořádané fázi vývoje ("Ferment"), která se vyznačuje rychlým růstem schopností, vysokou mírou inovací, ale také rizikem spojeným s absencí dominantního designu a standardů. Můžete jednoduše takzvaně vsadit na špatného koně.

• Nízké riziko spojené se sázkou na technologii konkrétního poskytovatele je při využití jazykových modelů formou co-intelligence, protože případný přechod mezi poskytovateli je velmi snadný. To stejné platí u využití GenAI jako copilot u různého software nebo aplikací.

• Střední riziko je, když využíváte v LLM dlouhodobou paměť a přizpůsobené modely v rámci předplatných (jako OpenAI GPTs, Claude Projects), jelikož při změně poskytovatele dojde ke ztrátě investice do vytvoření uživatelských modifikací.

• Vysoké riziko je u implementace RAG (Retrieval-Augmented Generation) řešení a znalostních bází vzhledem k nutnosti vektorizace dat pomocí embedding modelů, které nejsou mezi sebou kompatibilní a nutnosti datové migrace, je li vůbec možná, při změně vektorové databáze.

• Doporučení pro omezení rizik: Udržujte data v předzpracované podobě nezávisle na poskytovateli (JSON, Markdown), aby bylo možné je v případě potřeby použít s jiným modelem; zvažte export vektorů a metadat pro snazší migraci mezi vektorovými databázemi. Máte li odlazené systémové prompty pro komunikaci s modely ať již v rámci API nebo vyladěných modelů, udržujte si jejich knihovnu, abyste je nemuseli vymýšlet znovu. Pouze počítejte, že každý model lépe reaguje na jinak strukturovaný systémový prompt. Některé pomocí XML značek, některé lépe na text ve struktuře alá JSON.