Generatyvinio AI produkto kūrimas: ką reikia žinoti pirmiausia

Įvadas

Generatyvinę AI lengva išbandyti, tačiau kur kas sunkiau paversti ją produktu, kuriuo žmonės galėtų pasitikėti. Komanda per kelias dienas gali prijungti kalbos modelį prie pokalbių sąsajos. Tačiau užtikrinti, kad ta sąsaja apdorotų tikrus klientų užklausimus, laikytųsi prieigos teisių, dirbtų su įmonės duomenimis ir atsigautų po netinkamų atsakymų, yra visiškai kita istorija.

Įmonėms, svarstančioms generatyvinio AI panaudojimą verslo reikmėms, pirmasis sprendimas yra ne tai, kokį modelį pasirinkti, o tai, ar problema iš viso reikalauja naujo produkto. Paruošti AI įrankiai gali patenkinti didžiąją dalį poreikių, o individualus sprendimas yra prasmingesnis tada, kai esama programinė įranga negali prisitaikyti prie reikiamo darbo srauto. Įmonės, svarstančios pastarąjį variantą, gali pasikonsultuoti su „SysGears“ generatyvinio AI inžinieriais, kad išsiaiškintų techninius reikalavimus produktui, sukurtam pagal jų konkretų naudojimo atvejį.

Generatyvinis AI produktas apima žymiai daugiau nei vien modelio įdiegimą į įmonės prekės ženklu pažymėtą sąsają. Modelis gali tvarkyti kalbą, tačiau likusi programos dalis nulemia, kokia informacija jam prieinama, ar jis gali sąveikauti su kita programine įranga ir kas atsitinka, kai jo atsakymas neatitinka tikslų. Šie sprendimai daro tokį patį poveikį produkto naudingumui kaip ir paties modelio pasirinkimas.

Vidinis asistentas gali suklaidinti darbuotojus, jei pateiks pasenusį politikos dokumentą. Suteikus jam prieigą prie klientų įrašų, prieigos leidimai tampa tokie pat svarbūs kaip ir atsakymų kokybė. Jei programa taip pat gali keisti įrašus, įtikinamas, bet neteisingas atsakymas gali padaryti realią žalą.

Tai nėra smulkmenos, kurias galima ištaisyti po paleidimo. Jos daro įtaką architektūrai, reikalingoms inžinerinėms pastangoms ir AI kūrimo sąnaudoms, įskaitant tai, ko reikia, kad produktas veiktų. Įmonė turėtų išnagrinėti šiuos klausimus prieš pradėdama kurti, kol dar yra galimybė susiaurinti apimtį arba nuspręsti, kad esamas įrankis atliktų šią užduotį.

Pradėkite nuo problemos, kuriai spręsti reikalingas generatyvinis AI

Įtikinama demonstracija gali užgožti gana įprastą verslo problemą. Pavyzdžiui, jei darbuotojai praleidžia per daug laiko ieškant vidinių dokumentų, gali pakakti semantinės paieškos sistemos. Jei jiems reikia interpretuoti ilgus dokumentus, išgauti konkrečius duomenis ir parengti atsakymus naudodami informaciją iš kelių šaltinių, kalbos modelis gali suteikti kažką reikšmingesnio.

Šis skirtumas svarbus nuo pat pradžių. Generatyvinis AI pasiteisina tada, kai programinė įranga turi suprasti netvarkingą, nestruktūruotą medžiagą arba parengti tekstą, priklausantį nuo konteksto. Tačiau užduočiai, kuriai taikomos fiksuotos taisyklės, dažnai pigiau ir patikimiau naudoti įprastą skriptą.

Pavyzdžiui, paimkime platintoją, kuris nuolat gauna daugybę užklausų apie produktus. Klientai tą patį daiktą apibūdina įvairiausiais būdais, todėl generatyvinė AI programa galėtų suprasti jų užklausas, surasti atitinkamas specifikacijas ir parengti atsakymą. Kitas dalykas – atsargų lygis. Šie duomenys turi būti paimti iš realaus atsargų apskaitos įrašų, o nurodyta kaina turi atitikti įmonės kainodaros taisykles, o ne bet kokį skaičių, kurį atsitiktinai pateikia modelis.

Šį darbo pasiskirstymą verta aiškiai išlaikyti: leiskite modeliui dirbti su kalba, o nuspėjamas operacijas, kur įmanoma, palikite tradicinei programinei įrangai.

Prieš pradedant bet kokią plėtrą, tiksliai nustatykite, kas iš tikrųjų turėtų būti patobulinta. Pardavimo darbuotojams gali prireikti mažiau laiko parengti pasiūlymą; klientai gali gauti atsakymą nelaukdami pagalbos agento. Bet kuriuo atveju užfiksuokite, kaip procesas veikia dabar. Kitaip komanda gali galiausiai džiaugtis naujos AI sąsajos įdiegimu, nežinodama, ar ji iš tikrųjų palengvino darbą.

Kurti ar pirkti: kiek kontrolės jums iš tikrųjų reikia?

Sprendimas „kurti ar pirkti“ dažnai pateikiamas kaip pasirinkimas tarp visiškos nuosavybės ir patogumo. Praktikoje yra keletas tarpinės galimybės.

Paruošti naudoti AI įrankiai yra protingas pradinis taškas, kai įmonei reikalingos pažįstamos funkcijos, pavyzdžiui, rašymo pagalba, susitikimų santraukos, dokumentų analizė ar bendro pobūdžio tyrimai. Šiems produktams paprastai reikia mažiau inžinerinio darbo, o jų tiekėjai pasirūpina didžiąja dalimi pagrindinės infrastruktūros. Įmonė gali išbandyti, ar darbuotojams ši funkcija yra naudinga, prieš tai nefinansuodama specialaus kūrimo projekto.

Problemos prasideda tada, kai bendro pobūdžio įrankis turi būti pritaikytas procesui, kuriam jis nebuvo sukurtas. Pavyzdžiui, jis gali nesusieti su senesne duomenų baze arba netaikyti tinkamų prieigos teisių, kai darbuotojai eina skirtingas pareigas. Be to, jo rezultatai gali reikalauti pertvarkymo, kad juos galėtų naudoti kita verslo sistema. API ir konfigūracijos parinktys gali padėti užpildyti šias spragas, tačiau jos nebūtinai padės išspręsti įprasto darbo srauto ypatumus.

Individualiai pritaikytas AI produktas tampa labiau pateisinamas, kai pats darbo srautas yra konkurencinis pranašumas, kai esami produktai negali patenkinti esminio reikalavimo arba kai programai reikalinga glaudi integracija su nuosavais duomenimis ir vidinėmis sistemomis.

Trečiasis variantas – sukurti savo programą, pagrįstą išorinio teikėjo talpinamu modeliu. Įmonė sukuria sąsają ir jos logiką, integruoja sistemą į esamą programinę įrangą ir nustato savo rezultatų tikrinimo būdą. Prie paties modelio prieinama per API, todėl nereikia mokyti bazinio modelio nuo nulio. Tai suteikia įmonei laisvę pritaikyti produktą prie savo darbo eigos, nors vis dar priklauso nuo teikėjo kainodaros, modelio prieinamumo ir paslaugų apribojimų.

Šis paskutinis skirtumas nusipelno dėmesio. Individualizuotos AI programos kūrimas ir naujo AI modelio kūrimas yra skirtingi uždaviniai. Pagrindinio modelio mokymas reikalauja didelių skaičiavimo išteklių, specializuotų žinių, tinkamų duomenų ir nuolatinio eksperimentavimo. Daugumai įmonių nereikia prisiimti tokios naštos. Gali pakakti esamo modelio, papildyto duomenų paieška iš įmonės dokumentų arba kruopščiai suprojektuota prieiga prie įrankių.

Pasirinkite architektūrą, pritaikytą darbo srautui

Kai verslo atvejis tampa aiškus, kitas iššūkis – nuspręsti, kaip veiks programa. Modelis yra tik viena sudedamoji dalis, ir ji nebūtinai yra ta, kuriai reikia skirti daugiausia inžinieriaus laiko.

Dokumentų asistentui dažnai verta apsvarstyti paieškos papildytą generavimą (RAG). Vietoj to, kad remtųsi vien tuo, ką modelis išmoko mokymo metu, programa iš patvirtinto informacijos šaltinio išrenka atitinkamas ištraukas ir įtraukia jas į užklausą. Tada modelis, remdamasis ta medžiaga, suformuluoja atsakymą.

Atsakymai, pagrįsti vidaus politika ar naujausia informacija apie produktą, gali būti tinkamesni, jei paieška veikia kaip reikia. Tačiau tai nėra garantuota. Paieška gali išrinkti pasenusį dokumentą, praleisti svarbią išlygą arba pateikti modeliui ištrauką, kurią jis vėliau neteisingai interpretuoja.

Paieškos funkcija turi būti atskirai išbandyta. Tai, kaip dokumentai suskirstomi į fragmentus, gali paveikti tai, ką sistema randa, o net ir geras paieškos rezultatas yra bevertis, jei jis gaunamas iš šaltinio, kurio vartotojas neturėtų matyti. Darbuotojo prieigos teisės turi būti taikomos ir paieškos procese, o ne ignoruojamos vien dėl to, kad paieška atsitiktinai atskleidė riboto prieinamumo medžiagą. Autorizaciją turi užtikrinti pati programa. Negalima pasitikėti, kad modelis pats priims tokį sprendimą.

Tikslinimas tarnauja kitam tikslui. Jis gali padėti pritaikyti modelio elgseną, atsakymo formatą arba pasikartojančių užduočių modelių tvarkymą, kai yra tinkamų mokymo pavyzdžių. Tai nėra tiesioginis paieškos pakaitalas, kai pagrindinė problema yra prieiga prie besikeičiančių faktų. Modelis, patobulintas pagal praėjusių metų produktų katalogą, automatiškai nežinos, kas pasikeitė šį rytą.

Komandos eilutė ir modelio API gali būti viskas, ko reikia siauros apimties programai, bent jau pradžioje. Tai priklauso nuo to, kiek nuspėjami yra įvesties duomenys ir ko tikimasi, kad sistema darys su savo išvestimi. Jei kiekvieną atsakymą reikia patikrinti pagal didelį vidinės dokumentacijos rinkinį, informacijos paieška gali tapti būtina; paprastesnei užduočiai tai galėtų tiesiog pridėti papildomų sąnaudų.

Pirmoji versija turi būti paprasta, ją reikėtų išbandyti su tikrais užklausimais, o ne tik su kruopščiai parengtais demonstraciniais įvesties duomenimis. Pažiūrėkite, kaip ji susidoroja su neaiškiu klausimu ar trūkstama informacija. Jei ji, užuot pripažinusi spragą, imasi blefuoti, tai reikia ištaisyti prieš pridedant daugiau kintamųjų dalių.