Vývoj produktu založeného na generativní umělé inteligenci: Co je třeba vědět na začátku

Úvod

Generativní AI je snadné vyzkoušet, ale podstatně těžší je z ní vytvořit produkt, na který se lidé mohou spolehnout. Tým dokáže během několika dní propojit jazykový model s chatovým rozhraním. Zcela jiná věc je však zajistit, aby toto rozhraní zvládalo skutečné požadavky zákazníků, respektovalo přístupová oprávnění, pracovalo s firemními daty a dokázalo se zotavit z nesprávných odpovědí.

Pro firmy, které zvažují využití generativní AI pro obchodní aplikace, není prvním rozhodnutím to, který model použít. Jde o to, zda daný problém vůbec vyžaduje nový produkt. Hotové AI nástroje mohou pokrýt většinu potřeb, zatímco implementace na míru dává větší smysl v případě, že stávající software nedokáže vyhovět požadovanému pracovnímu toku. Firmy, které zvažují druhou možnost, se mohou obrátit na inženýry generativní AI společnosti SysGears, aby prozkoumali technické požadavky produktu postaveného na jejich konkrétním použití.

Produkt založený na generativní AI zahrnuje mnohem více než pouhé umístění modelu za rozhraní s firemním logem. Model sice může zpracovávat jazyk, ale zbytek aplikace určuje, z jakých informací může čerpat, zda může komunikovat s jiným softwarem a co se stane, když jeho odpověď nebude trefná. Tato rozhodnutí ovlivňují užitečnost produktu stejně jako samotný výběr modelu.

Interní asistent může zaměstnance uvést v omyl, pokud vyhledá zastaralý dokument s firemními zásadami. Pokud mu poskytnete přístup k záznamům o zákaznících, stávají se přístupová oprávnění stejně důležitá jako kvalita odpovědí. Pokud aplikace dokáže také měnit záznamy, mohla by přesvědčivá, ale nesprávná odpověď způsobit skutečné škody.

Nejedná se o detaily, které lze napravit až po uvedení na trh. Ovlivňují architekturu, potřebné inženýrské úsilí a náklady na vývoj AI, včetně toho, co je zapotřebí k udržení produktu v provozu. Podnik by se jimi měl zabývat ještě předtím, než se zaváže k vývoji, dokud je ještě prostor pro zúžení rozsahu nebo rozhodnutí, že by danou úlohu mohl splnit stávající nástroj.

Začněte s problémem, který vyžaduje generativní AI

Přesvědčivá ukázka může zastřít poměrně běžný obchodní problém. Pokud například zaměstnanci tráví příliš mnoho času prohledáváním interní dokumentace, může stačit sémantický vyhledávací systém. Pokud však potřebují interpretovat dlouhé dokumenty, extrahovat konkrétní podrobnosti a navrhovat odpovědi s využitím informací z několika zdrojů, může jazykový model přinést podstatnější přínos.

Toto rozlišení je důležité již od samého začátku. Generativní AI se vyplatí, když software musí porozumět chaotickému, nestrukturovanému materiálu nebo vypracovat návrh, který závisí na kontextu. Pro úkoly řízené pevnými pravidly je však běžný skript často levnější na provoz a snáze se mu dá důvěřovat.

Vezměme si například distributora, který řeší neustálý příliv dotazů na produkty. Zákazníci popisují stejnou položku nejrůznějšími způsoby, takže generativní aplikace umělé inteligence by mohla jejich požadavky pochopit, vyhledat příslušné specifikace a vypracovat odpověď. Stav zásob je však jiná záležitost. Ten musí vycházet z aktuálních záznamů o skladových zásobách, zatímco nabídková cena musí odpovídat cenovým pravidlům společnosti, nikoli libovolné částce, kterou model náhodou vygeneruje.

Toto rozdělení práce je třeba mít jasně na paměti: nechte model pracovat s jazykem a předvídatelné operace ponechte, pokud je to možné, konvenčnímu softwaru.

Než začnete s vývojem, přesně určete, co by se mělo skutečně zlepšit. Prodejní personál možná bude potřebovat méně času na sestavení nabídky; zákazníci možná dostanou odpověď, aniž by museli čekat na pracovníka podpory. Ať tak či onak, zaznamenejte, jak proces funguje nyní. Jinak se může stát, že tým nakonec oslaví zavedení nového rozhraní s umělou inteligencí, aniž by věděl, zda to práci skutečně usnadnilo.

Vytvořit vs. koupit: Kolik kontroly vlastně potřebujete?

Rozhodnutí mezi vlastním vývojem a nákupem hotového řešení se často prezentuje jako volba mezi úplným vlastnictvím a pohodlím. V praxi však existuje několik možností někde uprostřed.

Hotové nástroje s umělou inteligencí jsou rozumným výchozím bodem, když firma potřebuje známé funkce, jako je pomoc při psaní, shrnutí schůzek, analýza dokumentů nebo všeobecný výzkum. Tyto produkty obvykle vyžadují méně vývojářské práce a jejich dodavatelé se starají o velkou část základní infrastruktury. Firma tak může otestovat, zda zaměstnanci danou funkci shledají užitečnou, aniž by nejprve musela financovat specializovaný vývojový projekt.

Problémy začínají, když se generický nástroj musí přizpůsobit procesu, pro který nebyl navržen. Může se například stát, že nebude komunikovat se starší databází nebo že nebude správně uplatňovat přístupová oprávnění v případě, že mají zaměstnanci různé role. Jeho výstup může také vyžadovat úpravu, než jej bude moci využít jiný podnikový systém. API a konfigurační možnosti mohou pomoci tyto mezery překlenout, ale nemusí nutně pokrýt specifika zavedeného pracovního postupu.

Vlastní produkt založený na umělé inteligenci má větší opodstatnění, pokud je samotný pracovní postup konkurenční výhodou, pokud stávající produkty nedokážou splnit podstatný požadavek nebo pokud aplikace vyžaduje těsnou integraci s proprietárními daty a interními systémy.

Třetí možností je vytvořit si vlastní aplikaci založenou na modelu hostovaném externím poskytovatelem. Společnost vyvine rozhraní a logiku, která za ním stojí, propojí systém se svým stávajícím softwarem a nastaví si vlastní způsob testování výsledků. K samotnému modelu se přistupuje prostřednictvím API, takže není třeba trénovat základní model od nuly. To dává podniku prostor pro přizpůsobení produktu jeho pracovním postupům, i když stále závisí na cenách poskytovatele, dostupnosti modelů a omezeních služeb.

Právě tento poslední rozdíl si zaslouží pozornost. Vývoj vlastní aplikace s umělou inteligencí a vývoj nového modelu umělé inteligence jsou dvě odlišné záležitosti. Trénování základního modelu vyžaduje značné výpočetní zdroje, specializované odborné znalosti, vhodná data a neustálé experimentování. Většina firem si tuto zátěž nemusí brát na bedra. Může stačit stávající model, doplněný o vyhledávání v firemních dokumentech nebo pečlivě navržený přístup k nástrojům.

Zvolte architekturu podle pracovních potřeb

Jakmile je obchodní případ jasný, dalším úkolem je rozhodnout, jak bude aplikace fungovat. Model je pouze jednou ze složek a nemusí to být ta, která zabere nejvíce času vývojářům.

U asistenta pro práci s dokumenty často stojí za zvážení technologie RAG (retrieval-augmented generation). Místo toho, aby se aplikace spoléhala výhradně na to, co se model naučil během tréninku, vyhledá relevantní pasáže ze schváleného informačního zdroje a zahrne je do zadání. Model pak na základě tohoto materiálu formuluje odpověď.

Odpovědi založené na interních zásadách nebo aktuálních informacích o produktech mohou být relevantnější, pokud vyhledávání funguje správně. To však není zaručeno. Vyhledávání může najít zastaralý dokument, opomenout zásadní upozornění nebo předat modelu pasáž, kterou ten následně nesprávně interpretuje.

Vyhledávání je třeba testovat samostatně. Způsob, jakým jsou dokumenty rozděleny na části, může ovlivnit to, co systém najde, a i dobrý výsledek vyhledávání je k ničemu, pokud pochází ze zdroje, který by uživatel neměl vidět. Přístupová práva zaměstnance se musí promítnout i do procesu vyhledávání, místo aby byla potlačena jen proto, že vyhledávání náhodou odhalilo materiál s omezeným přístupem. Aplikace sama musí prosazovat autorizaci. Nemělo by se spoléhat na to, že toto rozhodnutí učiní model.

Dolaďování slouží jinému účelu. Může pomoci přizpůsobit chování modelu, formát odpovědi nebo zpracování opakujících se vzorců úkolů, jsou-li k dispozici vhodné trénovací příklady. Nejedná se o přímou náhradu vyhledávání, pokud je hlavním problémem přístup k měnícím se faktům. Model doladěný na loňském produktovém katalogu nebude automaticky vědět, co se dnes ráno změnilo.

Prompt a API modelu mohou být vše, co aplikace s úzkým rozsahem potřebuje, alespoň na začátku. Záleží na tom, jak předvídatelné jsou vstupy a co se od systému očekává, že s výstupem udělá. Pokud je třeba každou odpověď porovnat s rozsáhlou interní dokumentací, může být vyhledávání nezbytné; u jednoduššího úkolu by to mohlo jen zvyšovat zátěž.

První verzi udržujte jednoduchou a vyzkoušejte ji na skutečných požadavcích, ne jen na vyleštěných demo vstupech. Sledujte, jak si poradí s nejasnou otázkou nebo chybějícími informacemi. Pokud raději blafuje, než aby přiznala mezeru ve znalostech, je to něco, co je třeba opravit, než přidáte další proměnné.