Vytvorenie produktu založeného na generatívnej umelej inteligencii: Čo je potrebné vedieť na začiatku

Úvod

Generatívnu umelú inteligenciu je ľahké vyskúšať, ale podstatne ťažšie je premeniť ju na produkt, na ktorý sa ľudia môžu spoľahnúť. Tím dokáže za pár dní prepojiť jazykový model s chatovým rozhraním. Zabezpečiť však, aby toto rozhranie spracovávalo skutočné požiadavky zákazníkov, rešpektovalo prístupové oprávnenia, pracovalo s firemnými údajmi a dokázalo sa zotaviť z nesprávnych odpovedí, je už úplne iná záležitosť.

Pre firmy, ktoré zvažujú využitie generatívnej umelej inteligencie v obchodných aplikáciách, nie je prvým rozhodnutím to, ktorý model použiť. Ide o to, či daný problém vôbec vyžaduje nový produkt. Hotové nástroje umelej inteligencie môžu pokryť väčšinu potrieb, zatiaľ čo implementácia na mieru má väčší zmysel vtedy, keď existujúci softvér nedokáže vyhovieť požadovanému pracovnému toku. Firmy, ktoré zvažujú túto druhú možnosť, sa môžu poradiť s inžiniermi generatívnej umelej inteligencie spoločnosti SysGears, aby preskúmali technické požiadavky produktu vyvinutého pre ich konkrétny prípad použitia.

Produkt generatívnej umelej inteligencie zahŕňa podstatne viac než len umiestnenie modelu za rozhranie s firemnou značkou. Model síce môže spracovávať jazyk, ale zvyšná časť aplikácie určuje, z akých informácií môže čerpať, či môže komunikovať s iným softvérom a čo sa stane, keď jeho odpoveď nebude presná. Tieto rozhodnutia ovplyvňujú užitočnosť produktu rovnako ako samotný výber modelu.

Interný asistent môže zavádzať zamestnancov, ak vyhľadá zastaraný dokument s pravidlami. Ak mu poskytnete prístup k záznamom o zákazníkoch, oprávnenia na prístup sa stanú rovnako dôležitými ako kvalita odpovedí. Ak aplikácia dokáže aj meniť záznamy, presvedčivá, ale nesprávna odpoveď by mohla spôsobiť skutočnú škodu.

Toto nie sú detaily, ktoré by sa dali napraviť až po spustení. Ovplyvňujú architektúru, potrebné inžinierske úsilie a náklady na vývoj umelej inteligencie, vrátane nákladov na udržanie produktu v prevádzke. Podnik by sa nimi mal zaoberať ešte predtým, ako sa zaviaže k vývoju, kým je ešte priestor na zúženie rozsahu alebo rozhodnutie, že na danú úlohu postačí existujúci nástroj.

Začnite s problémom, ktorý si vyžaduje generatívnu umelú inteligenciu

Presvedčivá ukážka môže zakryť pomerne bežný obchodný problém. Ak napríklad zamestnanci trávia príliš veľa času vyhľadávaním vo vnútornej dokumentácii, môže stačiť sémantický vyhľadávací systém. Ak však potrebujú interpretovať dlhé dokumenty, extrahovať konkrétne detaily a navrhovať odpovede s využitím informácií z viacerých zdrojov, jazykový model môže priniesť podstatnejší prínos.

Toto rozlíšenie je dôležité už od začiatku. Generatívna umelá inteligencia sa oplatí vtedy, keď musí softvér porozumieť chaotickému, nestruktúrovanému materiálu alebo vypracovať niečo, čo závisí od kontextu. Pre úlohu riadenú pevnými pravidlami je však bežný skript často lacnejší na prevádzku a ľahšie sa mu dá dôverovať.

Vezmime si napríklad distribútora, ktorý rieši neustály prílev dopytov na produkty. Zákazníci opisujú ten istý tovar rôznymi spôsobmi, takže generatívna aplikácia umelej inteligencie by mohla porozumieť ich požiadavkám, vyhľadať príslušné špecifikácie a vypracovať odpoveď. Stav zásob je už iná záležitosť. Ten musí vychádzať z aktuálnych záznamov o zásobách, zatiaľ čo ponúkaná cena musí dodržiavať cenové pravidlá spoločnosti, a nie akúkoľvek sumu, ktorú model náhodou vygeneruje.

Toto rozdelenie práce stojí za to mať jasne na pamäti: nechajte model pracovať s jazykom a predvídateľné operácie zverte konvenčnému softvéru, kdekoľvek je to možné.

Ešte pred začatím akéhokoľvek vývoja si ujasnite, čo by sa malo skutočne zlepšiť. Obchodní zástupcovia by mohli potrebovať menej času na vypracovanie cenovej ponuky; zákazníci by mohli dostať odpoveď bez čakania na pracovníka podpory. V každom prípade si zaznamenajte, ako proces funguje teraz. Inak sa môže stať, že tím bude oslavovať zavedenie nového rozhrania umelej inteligencie bez toho, aby vedel, či to prácu skutočne uľahčilo.

Vytvoriť alebo kúpiť: Koľko kontroly skutočne potrebujete?

Rozhodnutie medzi vlastným vývojom a nákupom sa často prezentuje ako voľba medzi úplným vlastníctvom a pohodlím. V praxi však existuje niekoľko možností, ktoré sa nachádzajú niekde uprostred.

Hotové nástroje umelej inteligencie sú rozumným východiskovým bodom, keď firma potrebuje známe funkcie, ako je pomoc pri písaní, zhrnutia zo schôdzí, analýza dokumentov alebo všeobecný výskum. Tieto produkty zvyčajne vyžadujú menej inžinierskej práce a ich dodávatelia sa starajú o veľkú časť základnej infraštruktúry. Spoločnosť môže otestovať, či zamestnanci považujú danú funkciu za užitočnú, bez toho, aby najskôr financovala špecializovaný vývojový projekt.

Problémy začínajú vtedy, keď sa generický nástroj musí prispôsobiť procesu, pre ktorý nebol navrhnutý. Môže sa napríklad stať, že nebude komunikovať so staršou databázou alebo nebude uplatňovať správne prístupové oprávnenia, ak majú zamestnanci rôzne role. Jeho výstup môže tiež vyžadovať úpravu, aby ho mohol využiť iný podnikový systém. Rozhrania API a konfiguračné možnosti môžu pomôcť preklenúť tieto medzery, ale nemusia nevyhnutne pokryť špecifiká zavedeného pracovného toku.

Vlastný produkt umelej inteligencie je opodstatnenejší vtedy, keď je samotný pracovný postup konkurenčnou výhodou, keď existujúce produkty nedokážu splniť podstatnú požiadavku alebo keď aplikácia vyžaduje úzku integráciu s proprietárnymi údajmi a internými systémami.

Tretia možnosť spočíva vo vytvorení vlastnej aplikácie na základe modelu hosťovaného externým poskytovateľom. Spoločnosť vyvinie rozhranie a logiku, ktorá za ním stojí, prepojí systém so svojím existujúcim softvérom a nastaví si vlastný spôsob testovania výsledkov. K samotnému modelu sa pristupuje prostredníctvom API, takže nie je potrebné trénovať základný model od nuly. To dáva podniku priestor na prispôsobenie produktu svojmu pracovnému toku, hoci stále závisí od cenovej politiky poskytovateľa, dostupnosti modelu a obmedzení služieb.

Tento posledný rozdiel si zaslúži pozornosť. Vývoj vlastnej aplikácie umelej inteligencie a vývoj nového modelu umelej inteligencie sú odlišné úlohy. Trénovanie základného modelu vyžaduje značné výpočtové zdroje, špecializované odborné znalosti, vhodné údaje a neustále experimentovanie. Väčšina firiem si túto záťaž nemusí brať na plecia. Môže stačiť existujúci model, doplnený o vyhľadávanie z firemných dokumentov alebo starostlivo navrhnutý prístup k nástrojom.

Zvoľte architektúru podľa pracovných postupov

Akonáhle je obchodný prípad jasný, ďalšou výzvou je rozhodnutie o tom, ako bude aplikácia fungovať. Model je len jednou zo zložiek a nemusí to byť práve tá zložka, ktorá si vyžiada najviac času na vývoj.

V prípade asistenta pre prácu s dokumentmi sa často oplatí zvážiť generovanie rozšírené o vyhľadávanie (RAG). Namiesto toho, aby sa aplikácia spoliehala výlučne na to, čo sa model naučil počas trénovania, vyhľadáva relevantné úryvky zo schváleného informačného zdroja a zahrnie ich do zadania. Model potom na základe tohto materiálu sformuluje odpoveď.

Odpovede založené na interných politikách alebo aktuálnych informáciách o produkte môžu byť relevantnejšie, pokiaľ vyhľadávanie funguje správne. To však nie je isté. Vyhľadávanie môže vybrať zastaraný dokument, prehliadnuť dôležité upozornenie alebo poskytnúť modelu úryvok, ktorý potom nesprávne interpretuje.

Vyhľadávanie si vyžaduje samostatné testovanie. Spôsob rozdelenia dokumentov na časti môže ovplyvniť to, čo systém nájde, a dokonca aj dobrý výsledok vyhľadávania je nepoužiteľný, ak pochádza zo zdroja, ktorý by používateľ nemal vidieť. Prístupové práva zamestnanca sa musia preniesť aj do procesu vyhľadávania, namiesto toho, aby boli potlačené len preto, že vyhľadávanie náhodou odhalilo obmedzený materiál. Samotná aplikácia musí vynútiť autorizáciu. Nemalo by sa spoliehať na to, že tento rozhodnutie urobí model.

Dolaďovanie slúži na iný účel. Môže pomôcť prispôsobiť správanie modelu, formát odpovede alebo spracovanie opakujúcich sa vzorov úloh, ak sú k dispozícii vhodné trénovacie príklady. Nie je to priama náhrada za vyhľadávanie, keď je hlavným problémom prístup k meniacim sa faktom. Model doladený na základe vlaňajšieho produktového katalógu nebude automaticky vedieť, čo sa zmenilo dnes ráno.

Na úzko zameranú aplikáciu môže stačiť len výzva a rozhranie API modelu, aspoň na začiatku. Závisí to od toho, nakoľko sú vstupy predvídateľné a čo sa od systému očakáva, že urobí so svojím výstupom. Ak je potrebné každú odpoveď porovnať s rozsiahlym súborom internej dokumentácie, vyhľadávanie sa môže stať nevyhnutným; pri jednoduchšej úlohe by to mohlo len zvýšiť zaťaženie.

Prvú verziu udržujte jednoduchú a vyskúšajte ju na skutočných požiadavkách, nie len na vyleštených demo vstupoch. Pozrite sa, ako si poradí s nejasnou otázkou alebo chýbajúcimi informáciami. Ak radšej blafuje, ako by priznal medzeru, je to niečo, čo treba opraviť skôr, než pridáte ďalšie pohyblivé časti.