Razvoj izdelka na podlagi generativne umetne inteligence: kaj je treba vedeti na začetku

Uvod

Generativno umetno inteligenco je enostavno preizkusiti, precej težje pa jo je spremeniti v izdelek, na katerega se lahko ljudje zanesijo. Ekipa lahko v nekaj dneh poveže jezikovni model s klepetalnim vmesnikom. Da pa ta vmesnik obravnava dejanske zahteve strank, upošteva dostopna dovoljenja, deluje s podatki podjetja in se popravi po napačnih odgovorih, je povsem druga zgodba.

Za podjetja, ki razmišljajo o uporabi generativne umetne inteligence v poslovnih aplikacijah, prva odločitev ni, kateri model uporabiti. Gre za to, ali problem sploh zahteva nov izdelek. Gotova orodja umetne inteligence lahko pokrijejo večino potreb, medtem ko je prilagojena implementacija smiselnejša, kadar obstoječa programska oprema ne more prilagoditi zahtevanega delovnega toka. Podjetja, ki preučujejo slednjo možnost, se lahko posvetujejo z inženirji za generativno umetno inteligenco pri SysGears, da raziskajo tehnične zahteve izdelka, zasnovanega na njihovem konkretnem primeru uporabe.

Generativni AI-izdelek vključuje precej več kot le vgradnjo modela v vmesnik z blagovno znamko podjetja. Model morda obvladuje jezik, toda preostali del aplikacije določa, na katere informacije se lahko opira, ali lahko komunicira z drugo programsko opremo in kaj se zgodi, če njegov odgovor ni ustrezen. Te odločitve vplivajo na uporabnost izdelka prav toliko kot sama izbira modela.

Notranji pomočnik lahko zavede zaposlene, če poišče zastarel dokument o pravilih. Če mu omogočimo dostop do evidenc strank, postanejo dostopna dovoljenja prav tako pomembna kot kakovost odgovorov. Če aplikacija lahko tudi spreminja evidence, bi lahko prepričljiv, a napačen odgovor povzročil resno škodo.

To niso podrobnosti, ki jih je mogoče popraviti po uvedbi. Vplivajo na arhitekturo, potrebni inženirski napor in stroške razvoja umetne inteligence, vključno s tem, kar je potrebno za nemoteno delovanje izdelka. Podjetje bi jih moralo obravnavati, preden se zaveže k razvoju, dokler je še mogoče zožiti obseg ali se odločiti, da bi za to delo zadostovalo obstoječe orodje.

Začnite s problemom, ki zahteva generativno umetno inteligenco

Prepričljiva predstavitev lahko zakrije precej običajen poslovni problem. Če zaposleni na primer porabijo preveč časa za iskanje v notranji dokumentaciji, je morda dovolj semantični iskalni sistem. Če pa morajo razlagati dolge dokumente, izluščiti določene podrobnosti in sestavljati odgovore na podlagi informacij iz več virov, lahko jezikovni model prinese nekaj bistvenega.

Ta razlika je pomembna že od samega začetka. Generativna umetna inteligenca se izplača, ko mora programska oprema razumeti neurejeno, nestrukturirano gradivo ali sestaviti nekaj, kar je odvisno od konteksta. Za nalogo, ki jo urejajo fiksna pravila, pa je običajen skript pogosto cenejši za izvajanje in lažje mu je zaupati.

Vzemimo za primer distributerja, ki se spopada z neprekinjenim tokom poizvedb o izdelkih. Stranke opisujejo isti izdelek na najrazličnejše načine, zato bi generativna umetna inteligenca lahko razumela njihove zahteve, poiskala ustrezne specifikacije in pripravila odgovor. Stanje zalog je druga zgodba. Podatki o zalogah morajo izhajati iz aktualnih evidenc zalog, medtem ko mora ponujena cena slediti cenovnim pravilom podjetja, ne pa kakršni koli številki, ki jo model slučajno izračuna.

To delitev dela je vredno jasno ohraniti: pustimo, da model obdeluje jezik, predvidljive operacije pa, kjer je to mogoče, prepustimo konvencionalni programski opremi.

Preden se začne kakršen koli razvoj, natančno opredelite, kaj naj bi se dejansko izboljšalo. Prodajno osebje bo morda potrebovalo manj časa za pripravo ponudbe; stranke bodo morda dobile odgovor, ne da bi morale čakati na predstavnika podpore. V vsakem primeru zabeležite, kako proces deluje zdaj. V nasprotnem primeru se lahko zgodi, da bo ekipa na koncu proslavljala uvedbo novega vmesnika z umetno inteligenco, ne da bi vedela, ali je to delo sploh olajšalo.

Razviti ali kupiti: koliko nadzora dejansko potrebujete?

Odločitev med razvojem in nakupom se pogosto predstavlja kot izbira med popolnim lastništvom in udobjem. V praksi pa obstaja več možnosti vmes.

Pripravljena orodja za umetno inteligenco so smiselna izhodiščna točka, ko podjetje potrebuje znane funkcije, kot so pomoč pri pisanju, povzetki sestankov, analiza dokumentov ali splošno raziskovanje. Ti izdelki običajno zahtevajo manj inženirskega dela, njihovi ponudniki pa skrbijo za večino osnovne infrastrukture. Podjetje lahko preizkusi, ali zaposleni neko funkcijo najdejo koristno, ne da bi najprej financiralo namenski razvojni projekt.

Težave se začnejo, ko mora splošno orodje ustrezati procesu, za katerega ni bilo zasnovano. Morda se na primer ne more povezati z obstoječo bazo podatkov ali uporabiti ustreznih dostopnih dovoljenj, kadar imajo zaposleni različne vloge. Njegov izhodni rezultat je morda treba tudi prilagoditi, preden ga lahko uporabi drug poslovni sistem. API-ji in možnosti konfiguracije lahko pomagajo premostiti te vrzeli, vendar ne bodo nujno pokrivali posebnosti uveljavljenega delovnega toka.

Izdelek umetne inteligence, izdelan po meri, postane bolj upravičen, kadar je sam delovni tok konkurenčna prednost, kadar obstoječi izdelki ne morejo izpolniti bistvene zahteve ali kadar aplikacija potrebuje tesno integracijo z lastniškimi podatki in notranjimi sistemi.

Tretja možnost je, da razvijete lastno aplikacijo na podlagi modela, ki ga gosti zunanji ponudnik. Podjetje razvije vmesnik in logiko, ki stoji za njim, sistem poveže s svojo obstoječo programsko opremo ter vzpostavi lasten način preizkušanja rezultatov. Dostop do samega modela poteka prek API-ja, zato ni treba osnovnega modela usposabljati od začetka. To podjetju omogoča, da izdelek prilagodi svojemu delovnemu toku, čeprav je še vedno odvisno od cen ponudnika, razpoložljivosti modelov in omejitev storitev.

Ta zadnja razlika zasluži pozornost. Razvoj prilagojene aplikacije z umetno inteligenco in razvoj novega modela umetne inteligence sta različna projekta. Usposabljanje osnovnega modela zahteva znatne računalniške vire, specializirano strokovno znanje, ustrezne podatke in nenehno eksperimentiranje. Večina podjetij si tega bremena ne želi prevzeti. Obstoječi model, dopolnjen z iskanjem podatkov iz dokumentov podjetja ali skrbno zasnovanim dostopom do orodij, je lahko zadosten.

Izberite arhitekturo, prilagojeno delovnemu toku

Ko je poslovni primer jasen, je naslednji izziv odločitev, kako bo aplikacija delovala. Model je le ena od komponent in morda sploh ni tista, ki zahteva največ inženirskega časa.

Za pomočnika pri delu z dokumenti je pogosto vredno razmisliti o generiranju, dopolnjenem z iskanjem (RAG). Namesto da se aplikacija zanaša izključno na to, kar se je model naučil med usposabljanjem, pridobi ustrezne odlomke iz odobrenega vira informacij in jih vključi v navodilo. Model nato na podlagi tega gradiva oblikuje odgovor.

Odgovori, ki temeljijo na notranjih pravilih ali aktualnih informacijah o izdelkih, so lahko ustreznejši, če iskanje deluje pravilno. To pa ni zagotovljeno. Iskanje lahko prikaže zastarel dokument, spregleda ključno opozorilo ali modelu predloži odlomek, ki ga ta nato napačno razbere.

Iskanje je treba preizkusiti samostojno. Način, kako so dokumenti razdeljeni na dele, lahko vpliva na to, kaj sistem najde, in celo dober rezultat iskanja je neuporaben, če izhaja iz vira, ki ga uporabnik ne bi smel videti. Dostopne pravice zaposlenega morajo veljati tudi v procesu iskanja, namesto da bi bile preklicane, ker je iskanje naključno odkrilo omejeno gradivo. Aplikacija sama mora uveljavljati avtorizacijo. Modelu se ne sme zaupati, da bo sprejel to odločitev.

Natančno prilagajanje služi drugemu namenu. Lahko pomaga prilagoditi obnašanje modela, obliko odgovora ali obravnavo ponavljajočih se vzorcev nalog, kadar so na voljo ustrezni primeri za usposabljanje. Ni neposredna nadomestitev za iskanje, kadar je glavni problem dostop do spreminjajočih se dejstev. Model, natančno prilagojen lanskoletnemu katalogu izdelkov, ne bo samodejno vedel, kaj se je spremenilo danes zjutraj.

Za aplikacijo z ozkim obsegom sta morda dovolj že ukaz in API modela, vsaj na začetku. To je odvisno od tega, kako predvidljivi so vhodni podatki in kaj se od sistema pričakuje, da bo naredil z izhodnimi podatki. Če je treba vsak odgovor preveriti glede na obsežno notranjo dokumentacijo, je iskanje morda nujno; za preprostejšo nalogo pa bi to lahko pomenilo le dodatno obremenitev.

Prvo različico ohranite preprosto in jo preizkusite na resničnih zahtevah, ne le na dodelanih demo vhodnih podatkih. Preverite, kako se odziva na nejasna vprašanja ali manjkajoče informacije. Če raje blefira, namesto da bi priznal pomanjkljivost, je to nekaj, kar je treba popraviti, preden dodate več spremenljivih delov.