Generatīvā mākslīgā intelekta produkta izstrāde: kas jāzina vispirms

Ievads

Ģeneratīvo mākslīgo intelektu ir viegli izmēģināt, taču ievērojami grūtāk pārvērst par produktu, uz kuru cilvēki var paļauties. Komanda var pāris dienu laikā savienot valodas modeli ar čata saskarni. Taču panākt, lai šī saskarne apstrādātu reālus klientu pieprasījumus, ievērotu piekļuves atļaujas, strādātu ar uzņēmuma datiem un atgūtos no nepareizām atbildēm, ir pavisam cita lieta.

Uzņēmumiem, kas apsver generatīvās mākslīgās intelektas izmantošanu biznesa lietojumprogrammās, pirmais lēmums nav par to, kuru modeli izmantot. Tas ir lēmums par to, vai problēma vispār prasa jauna produkta izstrādi. Standarta mākslīgā intelekta rīki varētu apmierināt lielāko daļu vajadzību, savukārt pielāgota risinājuma izstrāde ir lietderīgāka gadījumos, kad esošā programmatūra nespēj nodrošināt nepieciešamo darba plūsmu. Uzņēmumi, kas izvērtē pēdējo variantu, var konsultēties ar SysGears generatīvās mākslīgās intelektas inženieriem, lai izpētītu tehniskās prasības produktam, kas izstrādāts, balstoties uz konkrēto lietošanas gadījumu.

Ģeneratīvā AI produkta izstrāde ietver daudz vairāk nekā vienkārši modeļa ievietošanu uzņēmuma zīmola interfeisā. Modelis var apstrādāt valodu, taču pārējā lietojumprogramma nosaka, uz kādu informāciju tas var balstīties, vai tas var mijiedarboties ar citu programmatūru un kas notiek, ja atbilde neatbilst mērķim. Šie lēmumi ietekmē produkta lietderību tikpat lielā mērā kā paša modeļa izvēle.

Iekšējais palīgs var maldināt darbiniekus, ja tas atrod novecojušu politikas dokumentu. Ja tam tiek piešķirta piekļuve klientu datiem, piekļuves atļaujas kļūst tikpat svarīgas kā atbilžu kvalitāte. Ja lietojumprogramma spēj arī mainīt ierakstus, pārliecinoša, bet nepareiza atbilde var radīt reālus zaudējumus.

Tās nav detaļas, kuras var labot pēc izlaišanas. Tās ietekmē arhitektūru, nepieciešamo inženierijas darbu apjomu un AI izstrādes izmaksas, ieskaitot to, kas nepieciešams, lai nodrošinātu produkta darbību. Uzņēmumam šie jautājumi jāizskata pirms izstrādes uzsākšanas, kamēr vēl ir iespēja sašaurināt darbības jomu vai nolemt, ka uzdevumu var paveikt ar jau esošu rīku.

Sāciet ar problēmu, kuras risināšanai nepieciešama ģeneratīvā mākslīgā intelekta sistēma

Pārliecinoša demonstrācija var aizēnot diezgan parastu biznesa problēmu. Ja darbinieki, piemēram, pavada pārāk daudz laika, meklējot iekšējos dokumentos, varbūt pietiks ar semantisko meklēšanas sistēmu. Ja viņiem ir jāinterpretē gari dokumenti, jāizvelk konkrētas detaļas un jāizstrādā atbildes, izmantojot informāciju no vairākiem avotiem, valodas modelis var sniegt kaut ko būtiskāku.

Šī atšķirība ir svarīga jau no paša sākuma. Ģeneratīvā AI attaisno savu izmaksu, ja programmatūrai ir jāsaprot haotisks, nestrukturēts materiāls vai jāsagatavo kaut kas, kas ir atkarīgs no konteksta. Savukārt uzdevumiem, kurus regulē fiksēti noteikumi, parasti ir lētāk izmantot parastu skriptu, un tam ir vieglāk uzticēties.

Iedomāsimies izplatītāju, kas saņem nepārtrauktu produktu pieprasījumu plūsmu. Klienti vienu un to pašu preci apraksta visdažādākajos veidos, tāpēc ģeneratīvā AI lietojumprogramma varētu izprast viņu pieprasījumus, atrast atbilstošās specifikācijas un sagatavot atbildes projektu. Krājumu līmeņi ir atsevišķs jautājums. Tie ir jāiegūst no reāla krājumu uzskaites, savukārt piedāvātā cena ir jānosaka saskaņā ar uzņēmuma cenu noteikšanas noteikumiem, nevis atkarībā no tā, kādu skaitli modelis gadījumā ģenerē.

Šo darba sadalījumu ir vērts skaidri ievērot: ļaujiet modelim strādāt ar valodu un, ja vien iespējams, paredzamās darbības atstājiet tradicionālajai programmatūrai.

Pirms uzsākt jebkādu izstrādi, precīzi nosakiet, kas tieši ir jāuzlabo. Pārdošanas darbiniekiem varbūt būs nepieciešams mazāk laika, lai sagatavotu piedāvājumu; klienti varbūt saņems atbildi, negaidot uz atbalsta darbinieku. Jebkurā gadījumā reģistrējiet, kā process darbojas pašlaik. Pretējā gadījumā komanda var beigt ar to, ka svin jaunas AI saskarnes ieviešanu, nezinot, vai tā ir padarījusi darbu vieglāku.

Izstrādāt vai iegādāties: cik liela kontrole jums patiesībā ir nepieciešama?

Lēmums par to, vai izstrādāt vai iegādāties, bieži tiek pasniegts kā izvēle starp pilnīgu īpašumtiesībām un ērtībām. Praksē pastāv vairākas starpposma iespējas.

Gatavi AI rīki ir saprātīgs sākumpunkts, ja uzņēmumam nepieciešamas pazīstamas funkcijas, piemēram, palīdzība rakstīšanā, sanāksmju kopsavilkumi, dokumentu analīze vai vispārējas nozīmes pētījumi. Šiem produktiem parasti ir nepieciešams mazāk inženiertehniskā darba, un to piegādātāji nodrošina lielāko daļu pamatinfrastruktūras. Uzņēmums var pārbaudīt, vai darbinieki uzskata kādu funkciju par noderīgu, neieguldot līdzekļus īpašā izstrādes projektā.

Problēmas sākas tad, kad vispārējam rīkam jāpielāgojas procesam, kuram tas nav paredzēts. Tas, piemēram, var nesadarboties ar vecāku datu bāzi vai nepiemērot pareizās piekļuves atļaujas, ja darbiniekiem ir atšķirīgas lomas. Tā rezultātiem var būt nepieciešama pārveidošana, lai tos varētu izmantot citā uzņēmuma sistēmā. API un konfigurācijas iespējas var palīdzēt pārvarēt šīs nepilnības, taču tās ne vienmēr ņem vērā jau iedibinātā darba plūsmas īpatnības.

Pielāgots AI produkts kļūst pamatotāks, ja darba plūsma pati par sevi ir konkurences priekšrocība, ja esošie produkti nespēj apmierināt būtisku prasību vai ja lietojumprogrammai ir nepieciešama cieša integrācija ar uzņēmuma īpašumā esošajiem datiem un iekšējām sistēmām.

Trešā iespēja ir izstrādāt savu lietojumprogrammu, balstoties uz modeli, ko uztur ārējs pakalpojumu sniedzējs. Uzņēmums izstrādā saskarni un tās loģiku, integrē sistēmu savā esošajā programmatūrā un izveido savu veidu, kā pārbaudīt rezultātus. Piekļuve pašam modelim notiek caur API, tādēļ nav nepieciešams apmācīt pamata modeli no nulles. Tas dod uzņēmumam iespēju pielāgot produktu savai darba plūsmai, lai gan tas joprojām ir atkarīgs no pakalpojuma sniedzēja cenām, modeļa pieejamības un pakalpojuma ierobežojumiem.

Šai pēdējai atšķirībai ir vērts pievērst uzmanību. Pielāgotas AI lietojumprogrammas izstrāde un jauna AI modeļa izstrāde ir atšķirīgi uzdevumi. Pamata modeļa apmācībai nepieciešami ievērojami skaitļošanas resursi, specializētas zināšanas, piemēroti dati un nepārtraukta eksperimentēšana. Lielākajai daļai uzņēmumu nav nepieciešams uzņemties šādu slogu. Var pietikt ar esošu modeli, ko papildina informācijas iegūšana no uzņēmuma dokumentiem vai rūpīgi izstrādāta piekļuve rīkiem.

Izvēlieties arhitektūru atbilstoši darba plūsmai

Kad biznesa pamatojums ir skaidrs, nākamais izaicinājums ir izlemt, kā lietojumprogramma darbosies. Modelis ir tikai viena sastāvdaļa, un tā var nebūt tā sastāvdaļa, kas prasa visvairāk inženieru darba laika.

Dokumentu palīgprogrammai bieži ir vērts apsvērt meklēšanas papildinātu ģenerēšanu (RAG). Tā vietā, lai paļautos vienīgi uz to, ko modelis apguvis apmācības laikā, lietojumprogramma izgūst atbilstošus fragmentus no apstiprināta informācijas avota un iekļauj tos uzvednē. Pēc tam modelis, izmantojot šo materiālu, formulē atbildi.

Atbildes, kas balstās uz iekšējām politikām vai aktuālu informāciju par produktu, var būt atbilstošākas, ja vien informācijas atgūšana darbojas pareizi. Tas gan nav garantēts. Meklēšana var atrast novecojušu dokumentu, nepamanīt būtisku brīdinājumu vai nodot modelim fragmentu, ko tas pēc tam nepareizi interpretē.

Meklēšanas procesam ir nepieciešama atsevišķa pārbaude. Tas, kā dokumenti tiek sadalīti fragmentos, var ietekmēt to, ko sistēma atrod, un pat labs meklēšanas rezultāts ir bezjēdzīgs, ja tas nāk no avota, kuru lietotājam nevajadzētu redzēt. Darbinieka piekļuves tiesībām ir jāattiecas arī uz meklēšanas procesu, nevis tām jābūt atspēkotām tikai tāpēc, ka meklēšana nejauši atklāja ierobežotas piekļuves materiālu. Lietojumprogrammai pašai ir jānodrošina autorizācija. Nedrīkst paļauties uz to, ka modelis pieņems šādu lēmumu.

Precizēšana kalpo citam mērķim. Tā var palīdzēt pielāgot modeļa darbību, atbildes formātu vai atkārtojošos uzdevumu modeļu apstrādi, ja ir pieejami piemēroti apmācības piemēri. Tā nav tieša meklēšanas aizstājēja, ja galvenā problēma ir piekļuve mainīgiem faktiem. Modelis, kas precizēts, balstoties uz pagājušā gada produktu katalogu, automātiski nezinās, kas ir mainījies šorīt.

Vismaz sākumā lietojumprogrammai ar šauru darbības jomu var pietikt ar vienu uzvedni un modeļa API. Tas ir atkarīgs no tā, cik paredzamas ir ieejas dati un ko no sistēmas izvades tiek sagaidīts. Ja katra atbilde ir jāpārbauda, salīdzinot ar lielu iekšējās dokumentācijas apjomu, var būt nepieciešama informācijas atgūšana; vienkāršākam uzdevumam tas varētu tikai radīt papildu slogu.

Pirmā versija jāveido vienkārša un jāizmēģina ar reāliem pieprasījumiem, nevis tikai ar izkopotiem demonstrācijas ievades datiem. Novērojiet, kā tā rīkojas ar neskaidru jautājumu vai trūkstošu informāciju. Ja tā mēģina izlikties, nevis atzīst trūkumu, tas ir jālabo, pirms pievieno papildu kustīgas detaļas.