Generatiivse tehisintellekti toote loomine: mida tuleks esmalt teada

Sissejuhatus

Generatiivset tehisintellekti on lihtne proovida, kuid märksa raskem muuta see tooteks, millele inimesed saaksid loota. Meeskond suudab keelemudeli vestlusliidesega ühendada mõne päevaga. Kuid selle liidese viimine olukorda, kus see suudab käsitleda reaalseid kliendipäringuid, järgida juurdepääsuõigusi, töötada ettevõtte andmetega ja taastuda valedest vastustest, on hoopis teine asi.

Ettevõtetele, kes kaaluvad generatiivse tehisintellekti kasutamist ärirakendustes, ei ole esimene otsus mitte see, millist mudelit kasutada, vaid see, kas probleem üldse nõuab uut toodet. Valmis tehisintellekti tööriistad võivad katta suurema osa vajadustest, samas kui kohandatud rakendus on mõistlikum valik juhul, kui olemasolev tarkvara ei suuda vajalikku töövoogu toetada. Viimast varianti kaaluvad ettevõtted võivad konsulteerida SysGearsi generatiivse tehisintellekti inseneridega, et uurida nende konkreetse kasutusjuhtumi põhjal loodava toote tehnilisi nõudeid.

Generatiivne tehisintellekti toode hõlmab märksa enamat kui lihtsalt mudeli paigutamist ettevõtte brändiga liidese taha. Mudel võib küll keelt töödelda, kuid ülejäänud rakendus määrab, millisele teabele see tugineda saab, kas see suudab suhelda teise tarkvaraga ja mis juhtub, kui vastus ei ole asjakohane. Need otsused mõjutavad toote kasulikkust sama palju kui mudeli valik ise.

Sisemine assistent võib töötajaid eksitada, kui ta toob esile aegunud eeskirjadokumendi. Kui talle anda juurdepääs kliendiandmetele, muutuvad juurdepääsuõigused sama oluliseks kui vastuse kvaliteet. Kui rakendus suudab ka andmeid muuta, võib veenev, kuid vale vastus tekitada tõelist kahju.

Need ei ole üksikasjad, mida saab pärast turule toomist lihtsalt parandada. Need mõjutavad arhitektuuri, vajalikku inseneritööd ja tehisintellekti arenduskulusid, sealhulgas seda, mida on vaja toote töös hoidmiseks. Ettevõte peaks need läbi mõtlema enne arendustööga alustamist, kui on veel võimalus ulatust kitsendada või otsustada, et olemasolev tööriist sobib ülesande täitmiseks.

Alustage probleemist, mis vajab generatiivset tehisintellekti

Veenev demo võib varjata üsna tavalist äriprobleemi. Kui töötajad kulutavad näiteks liiga palju aega sisemiste dokumentide otsimisele, võib semantiline otsingusüsteem olla piisav. Kui nad peavad tõlgendama pikki dokumente, eraldama konkreetseid üksikasju ja koostama vastuseid mitmest allikast pärit teabe põhjal, võib keelemudel pakkuda midagi olulisemat.

See eristus on oluline juba algusest peale. Generatiivne tehisintellekt õigustab oma olemasolu siis, kui tarkvara peab mõtestama segast, struktureerimata materjali või koostama midagi, mis sõltub kontekstist. Kindlate reeglite järgi toimiva ülesande puhul on aga tavaline skript sageli odavam kasutada ja usaldusväärsem.

Võtame näiteks turustaja, kes tegeleb pideva tootepäringute vooga. Kliendid kirjeldavad sama toodet igasugustel viisidel, seega võiks generatiivne tehisintellekti rakendus nende päringutest aru saada, leida asjakohased spetsifikatsioonid ja koostada vastuse. Laoseisud on aga teine teema. Need peavad pärinema reaalajas laoseisuregistritest, samas kui pakutav hind peab järgima ettevõtte hinnakujunduse reegleid, mitte seda numbrit, mille mudel juhuslikult genereerib.

Seda tööjaotust tasub selgelt silmas pidada: laske mudelil tegeleda keelega ja jätke ettearvatavad toimingud võimaluse korral tavapärasele tarkvarale.

Enne arendustööde alustamist tuleb kindlaks määrata, mida tegelikult tuleks parandada. Müügipersonalil võib pakkumise koostamiseks kuluda vähem aega; kliendid võivad saada vastuse ilma klienditoe töötajat ootamata. Igal juhul tuleb dokumenteerida, kuidas protsess praegu toimib. Vastasel juhul võib meeskond lõpuks tähistada uue tehisintellekti liidese kasutuselevõttu, teadmata, kas see on tööd üldse lihtsamaks teinud.

Ehitada või osta: kui palju kontrolli te tegelikult vajate?

Otsus „ise ehitada või osta” esitatakse sageli valikuna täieliku omandiõiguse ja mugavuse vahel. Praktikas on nende vahel mitmeid võimalusi.

Valmis AI-tööriistad on mõistlik lähtepunkt, kui ettevõte vajab tuttavaid funktsioone, nagu kirjutamisabi, koosolekute kokkuvõtted, dokumentide analüüs või üldine uurimistöö. Need tooted nõuavad tavaliselt vähem inseneritööd ning nende müüjad hoolitsevad suure osa alusinfrastruktuuri eest. Ettevõte saab testida, kas töötajad leiavad funktsiooni kasulikuks, ilma et peaks esmalt rahastama spetsiaalset arendusprojekti.

Probleemid algavad siis, kui üldine tööriist peab sobima protsessiga, mille jaoks seda ei ole kavandatud. Näiteks võib juhtuda, et see ei suuda suhelda vanade andmebaasidega või rakendada õigeid juurdepääsuõigusi, kui töötajatel on erinevad rollid. Samuti võib olla vaja selle väljundit ümber kujundada, enne kui mõni teine ärisüsteem seda kasutada saab. API-d ja konfiguratsioonivõimalused võivad aidata neid lünki täita, kuid need ei pruugi tingimata katta väljakujunenud töövoo eripärasid.

Kohandatud tehisintellekti toode on põhjendatum, kui töövoog ise on konkurentsieelis, kui olemasolevad tooted ei suuda täita olulist nõuet või kui rakendus vajab tihedat integratsiooni ettevõtte enda andmete ja sisemiste süsteemidega.

Kolmas võimalus on ehitada oma rakendus üles välise pakkuja poolt majutatava mudeli ümber. Ettevõte arendab liidese ja selle taga oleva loogika, ühendab süsteemi oma olemasoleva tarkvaraga ning seadistab oma viisi tulemuste testimiseks. Mudelile pääseb ligi API kaudu, seega pole vaja alusmudelit nullist treenida. See annab ettevõttele vabaduse kujundada toodet oma töövoo järgi, kuigi see sõltub ikkagi teenusepakkuja hinnakujundusest, mudeli kättesaadavusest ja teenuse piirangutest.

Viimane erinevus väärib tähelepanu. Kohandatud tehisintellekti rakenduse arendamine ja uue tehisintellekti mudeli arendamine on erinevad ettevõtmised. Alusmudeli treenimine nõuab märkimisväärseid arvutusressursse, erialast asjatundlikkust, sobivaid andmeid ja pidevat eksperimenteerimist. Enamikul ettevõtetel pole vaja seda koormat enda kanda võtta. Piisab olemasolevast mudelist, mida täiendatakse ettevõtte dokumentidest andmete hankimisega või hoolikalt kavandatud tööriistade juurdepääsuga.

Valige arhitektuur töövoo järgi

Kui äriplaan on selge, on järgmine väljakutse otsustada, kuidas rakendus toimima hakkab. Mudel on vaid üks komponent ja see ei pruugi olla komponent, mis võtab inseneritööle kõige rohkem aega.

Dokumendiapu puhul tasub sageli kaaluda otsinguga täiendatud genereerimist (RAG). Selle asemel, et tugineda ainult sellele, mida mudel õppimise käigus omandas, otsib rakendus asjakohaseid lõike heakskiidetud teabeallikast ja lisab need sisestusjuhisesse. Seejärel formuleerib mudel vastuse, kasutades seda materjali.

Sisemistele eeskirjadele või ajakohasele tooteteabele tuginevad vastused võivad olla asjakohasemad, eeldusel, et otsing toimib nõuetekohaselt. See ei ole aga kindel. Otsing võib tuua esile aegunud dokumendi, jätta tähelepanuta olulise hoiatuse või anda mudelile lõigu, mida see seejärel valesti tõlgendab.

Otsingut tuleb eraldi testida. See, kuidas dokumendid tükkideks jagatakse, võib mõjutada seda, mida süsteem leiab, ja isegi hea otsingutulemus on kasututu, kui see pärineb allikast, mida kasutaja ei tohiks näha. Töötaja juurdepääsuõigused peavad kehtima ka otsinguprotsessis, mitte neid ei tohi tühistada sellepärast, et otsing tõi juhuslikult esile piiratud juurdepääsuga materjali. Rakendus peab ise autoriseerimist rakendama. Mudelile ei tohiks usaldada sellise otsuse tegemist.

Täpsustamine teenib teist eesmärki. See võib aidata kohandada mudeli käitumist, vastuse vormingut või korduvate ülesannete mustrite käsitlemist, kui sobivad õppimisnäited on kättesaadavad. See ei ole otsene asendus otsingule, kui peamine probleem on juurdepääs muutuvatele faktidele. Eelmise aasta tootekataloogi põhjal täpsustatud mudel ei tea automaatselt, mis täna hommikul muutus.

Kitsa ulatusega rakendusele võib piisata ainult sisestusest ja mudeli API-st, vähemalt alguses. See sõltub sellest, kui ettearvatavad on sisendid ja mida süsteemilt oodatakse väljundiga tegemist. Kui iga vastust tuleb võrrelda suure hulga sisemise dokumentatsiooniga, võib andmete otsimine osutuda vajalikuks; lihtsama ülesande puhul võib see aga lihtsalt lisada koormust.

Hoidke esimene versioon lihtsana ja katsetage seda reaalsete päringutega, mitte ainult viimistletud demo-sisenditega. Vaadake, kuidas mudel toime tuleb ebamäärase küsimuse või puuduva teabega. Kui mudel pigem blufib, kui tunnistab lünka, on see midagi, mida tuleb parandada enne uute liikuvate osade lisamist.