Kaip sukūriau savo dirbtinio intelekto pokalbių robotą: kūrėjo kelionė

Viskas prasidėjo nuo paprastos problemos – skendėjau klientų užklausose. Kaip vienintelis savo augančios technologijų konsultacijų svetainės kūrėjas, kiekvieną dieną praleisdavau valandas atsakinėdamas į tuos pačius klausimus vėl ir vėl. Mano produktyvumas smuko, ir žinojau, kad kažkas turi pasikeisti. Nušvitimo akimirka atėjo antradienį 2 val. nakties, apsiblaususiomis akimis atsakydama į dar vieną el. laišką „Kaip atkurti slaptažodį?“. Kodėl negalėjau sukurti kažko, kas tvarkytų šias pasikartojančias sąveikas?

Su susidomėjimu stebėjau dirbtinio intelekto ir didelių kalbų modelių sprogimą, bet dažniausiai kaip stebėtojas. Žinoma, kaip ir visi kiti, žaidžiau su „ChatGPT“ ir „Claude“, bet savo dirbtinio intelekto asistento kūrimas atrodė skirtas komandoms, turinčioms gilesnes kišenes ir gilesnes žinias. Vis dėlto negalėjau atsikratyti minties, kad individualus pokalbių robotas – toks, kuris išmanytų mano verslą iš vidaus – galėtų būti sprendimas, kurio man labai reikėjo.
Tai, kas prasidėjo kaip savaitgalio projektas, skirtas sutaupyti laiko, virto šešių mėnesių manija, kuri iš esmės pakeitė mano požiūrį į programinės įrangos kūrimą, naudotojo patirtį ir pačią žmogaus ir kompiuterio sąveikos prigimtį. Tai istorija apie tai, kaip sukūriau savo pokalbių robotą, ko išmokau pakeliui ir kodėl galbūt norėsite susikurti tokį ir jūs.

Pirmoji didelė kliūtis buvo technologijų rinkinio pasirinkimas. Mane iš karto pribloškė galimybės – ar turėčiau kurti sistemą ant esamų API, tokių kaip „OpenAI“ GPT ar „Anthropic“ „Claude“? Ar turėčiau tobulinti atvirojo kodo modelį? O gal turėčiau siekti mažesnio masto, taisyklėmis pagrįstos sistemos, kuriai visiškai nereikėtų pažangiausio dirbtinio intelekto?

Po kelių savaičių tyrimų ir kelių koncepcijos įrodymo testų apsistojau ties hibridiniu metodu. Kaip smegenis naudočiau tobulintą atvirojo kodo kalbos modelį, kartu su paieškos papildytos generavimo (RAG) sistema, kad suteikčiau jai prieigą prie mano svetainės dokumentacijos ir DUK turinio. Tai leistų pokalbių robotui turėti bendrą intelektą, tuo pačiu metu išmanant konkrečiai apie mano verslą.

Pačiam modeliui pasirinkau „Mistral“ 7B parametrų modelį – pakankamai mažą, kad veiktų mano kukliame serveryje, bet pakankamai galingą, kad galėtų sklandžiai apdoroti natūralią kalbą. RAG komponentas naudotų vektorinę duomenų bazę („Pinecone“), kad saugotų mano dokumentacijos įterpimus, leisdamas pokalbių robotui ištraukti atitinkamą informaciją atsakant į klausimus. Priekinė dalis buvo sukurta naudojant „React“, o „Node.js“ serverio sistema tvarkė API iškvietimus ir apdorojimą. Pasirinkau „WebSockets“, kad palaikyčiau pokalbių ryšį su vartotojais ir galėčiau natūraliau bendrauti be puslapių perkrovimo.
Šis paketas suteikė man reikalingo lankstumo, kartu išlaikant valdomas išlaidas. Atvirojo kodo pagrindas reiškė, kad nebuvau priklausomas nuo API kainodaros, kuri galėtų staiga išaugti, jei mano svetainė staiga išpopuliarėtų, o vektorinės duomenų bazės metodas užtikrino, kad mano pokalbių robotas visada turėtų prieigą prie naujausios informacijos apie mano paslaugas.

Įprastą pokalbių robotą nuo tikrai naudingo asistento skiria duomenys – konkrečiai, jūsų duomenys. Greitai supratau, kad mano pokalbių robotas bus toks geras, kokia gera bus informacija, kurią jam pateiksiu. Tai reiškė, kad turėjau ne tik išgauti savo svetainės turinį, bet ir užfiksuoti, kaip bendrauju su klientais.

Pradėjau nuo šimtų el. laiškų, pagalbos užklausų ir tiesioginių pokalbių žurnalų peržiūros. Anonimizavau šiuos duomenis, išskirdamas žmonių užduodamų klausimų modelius ir – svarbiausia – kaip į juos atsakydavau. Tai davė man mokymo pavyzdžių, kurie atspindėjo mano tikrąjį toną, techninių detalių lygį ir problemų sprendimo būdą.
Norėdamas struktūrizuoti žinias, sukūriau išsamų DUK dokumentą, apimantį viską – nuo kainų klausimų iki techninių specifikacijų. Taip pat dokumentavau dažniausiai pasitaikančius trikčių šalinimo darbo eigą, užfiksuodamas sprendimų medžius, kuriais nesąmoningai vadovaujuosi padėdamas klientams diagnozuoti problemas.

Pats mokymo procesas buvo iteracinis ir pamokantis. Pirmasis mano bandymas sukūrė pokalbių robotą, kuris žinojo faktus apie mano verslą, bet reagavo kaip įmonės vadovas. Jam trūko šilumos ir kartais humoro, kuris buvo būdingas mano paties bendravimui. Grįžau prie braižymo lentos, šį kartą sutelkdamas dėmesį į pavyzdžių, kurie demonstruotų asmenybę kartu su informacija, įtraukimą.

Vienas netikėtas iššūkis buvo išmokyti pokalbių robotą, kada pasakyti „nežinau“ – tai esminis bet kurios dirbtinio intelekto sistemos įgūdis. Turėjau jį specialiai apmokyti atpažinti savo žinių ribas ir prireikus pateikti aiškius kelius į žmonių pagalbą. Tam reikėjo sukurti neigiamų pavyzdžių ir kraštutinių atvejų, kai teisingas atsakymas būtų eskaluoti, o ne improvizuoti atsakymą.

Po trijų mokymo iteracijų pagaliau turėjau modelį, kuris galėjo išlaikyti tai, ką pavadinau „vidurnakčio testu“ – ar jis galėjo atsakyti į klausimus, į kuriuos atsakydavau iki vėlumos? Kai jis sėkmingai parodė vartotojui mūsų API autentifikavimo procesą taip pat aiškiai, kaip ir aš, žinojau, kad kažką darome.

Skirtumas tarp patobulintos DUK paieškos ir tikro pokalbių asistento yra konteksto suvokimas – gebėjimas prisiminti, kas buvo pasakyta anksčiau, ir tuo remtis. Tai pasirodė esąs vienas techniškai sudėtingiausių viso projekto aspektų.

Pirmajame mano įdiegime buvo naudojamas paprastas kontekstinis langas, kuris prie kiekvienos naujos užklausos tiesiog pridėdavo kelis paskutinius pokalbius. Tai veikė su pagrindiniais tolesniais klausimais, bet greitai sugedo sudėtingose situacijose. Jei vartotojas paklausdavo apie A funkciją, tada apie B funkciją, o tada vėl užduodavo tolesnį klausimą apie A funkciją, pokalbių robotas susipainiodavo.

Galiausiai įdiegiau sudėtingesnę konteksto valdymo sistemą, kurioje buvo naudojamas kelių metodų derinys:

Slankus kontekstinis langas, kuriame pirmenybė teikiama naujausiems pokalbiams, bet taip pat saugoma svarbi ankstesnė informacija
Subjektų stebėjimas, siekiant nustatyti, kada vartotojai grįžo prie anksčiau minėtų produktų ar funkcijų
Sesijos būsenos valdymas, siekiant stebėti, kuriuose daugiapakopiuose procesuose, tokiuose kaip paskyros kūrimas, buvo vartotojai

Lūžis įvyko, kai pridėjau aktualumo vertinimą, kad nustatyčiau, kurios pokalbio istorijos dalys buvo svarbiausios dabartinei užklausai. Užuot aklai įtraukusi paskutinius N pokalbių, sistema dabar įvertino, kurios ankstesnės pokalbio dalys buvo semantiškai labiausiai susijusios su nauju klausimu.

Tai labai padidino vartotojų pasitenkinimą. Pokalbių robotas dabar galėjo valdyti natūralius pokalbių srautus, tokius kaip: „Kiek kainuoja bazinis planas?“ → „Kokias funkcijas jis apima?“ → „O premium planas?“ → „Ar jame yra anksčiau minėta failų bendrinimo funkcija?“ Neatmesdamas konteksto ir nesusipainiodamas.
Stebėti, kaip vartotojai sąveikauja su sistema be nusivylimo, buvo nepaprastai malonu – jie neprisitaikė prie pokalbių roboto apribojimų; pokalbių robotas prisitaikė prie jų natūralaus pokalbio stiliaus.

Kad ir kaip gerai apmokytumėte savo modelį, iškils kraštutinių atvejų – dažnai tokiais būdais, kokių net nenumatėte. Netrukus po pokalbių roboto paleidimo savo svetainėje pradėjau matyti keletą intriguojančių ir kartais juokingų gedimų režimų, kurie privertė mane grįžti prie braižymo lentos.

Vienas lankytojas 15 minučių bandė įtikinti mano pokalbių robotą parašyti eilėraštį apie kibernetinį saugumą (kažką, kas viršija jo numatytą paskirtį). Kitas bandė jį naudoti kaip bendrą programavimo asistentą, įklijuodamas kodo fragmentus ir prašydamas derinimo pagalbos technologijoms, visiškai nesusijusioms su mano verslu. Labiausiai nerimą kėlė retkarčiais pasitaikančios „haliucinacijos“ – atvejai, kai pokalbių robotas užtikrintai pateikdavo neteisingą informaciją, neteisingai interpretuodamas dokumentaciją arba pernelyg apibendrindamas mokymo pavyzdžius.
Šiuos iššūkius sprendžiau taikydamas daugiasluoksnį metodą:
Pirma, sistemos raginime įdiegiau aiškesnes taikymo srities ribas, aiškiai nurodydamas modeliui jo paskirtį ir apribojimus. Tai sumažino atvejų, kai vartotojai bandė jį naudoti ne pagal paskirtį.
Antra, pridėjau pasitikėjimo vertinimo mechanizmą. Kai modelio išvestis rodė neapibrėžtumo požymius (dėl lingvistinių žymeklių arba mažo prognozavimo patikimumo), jis pripažindavo šį neapibrėžtumą vartotojui, o ne pateikdavo spėliones kaip faktus. Trečia, sukūriau eskalavimo kelią su aiškiais veiksniais. Tam tikros temos arba vartotojo nusivylimo aptikimas paskatindavo pokalbių robotą pasiūlyti sujungti vartotoją su manimi tiesiogiai, taip užtikrinant sklandų perdavimą.
Galiausiai sukūriau grįžtamojo ryšio ciklą, kuriame vartotojai galėjo pažymėti probleminius atsakymus, kurie buvo automatiškai pridedami prie peržiūros eilės. Tai suteikė man sistemingą būdą nustatyti ir išspręsti problemas, o ne žaisti „kurmių daužymo“ žaidimą su kraštutiniais atvejais.
Turbūt vertingiausia pamoka gauta analizuojant šiuos kraštutinius atvejus: tobulas pokalbių robotas buvo ne tas, kuris niekada nedarė klaidų, o tas, kuris grakščiai valdė savo apribojimus ir žinojo, kada reikia įtraukti žmogų. Šis požiūrio pokytis pakeitė tai, kaip vertinu sėkmę, ir lėmė tolesnius mano tobulėjimus.

Techniškai puikus pokalbių robotas su gremėzdiška sąsaja yra tarsi „Ferrari“ su kvadratiniais ratais – visa ta galia nueina perniek, jei vartotojai negali patogiai juo bendrauti. Šią pamoką išmokau skaudžiai, kai mano pirmieji beta versijos testuotojai skundėsi viskuo – nuo lėto reagavimo laiko iki painių pokalbių eigų.

Pirmoji mano sukurta sąsaja buvo techniškai funkcionali, bet atrodė sterili ir mechaniška. Vartotojų testavimas parodė, kad žmonės nedrįso su ja bendrauti – ji tiesiog neatrodė patraukli. Grįžau prie braižymo lentos turėdamas omenyje šiuos principus:

Asmenybė svarbi: pridėjau subtilių dizaino elementų, kurie atspindėjo pokalbių roboto asmenybę – draugišką avatarą, spausdinimo indikatorius, imituojančius žmogaus ritmą, ir retkarčiais pasitaikančias animacijas, kurios suteikė jam gyvumo pojūtį, neperžengiant keisto slėnio ribų.

Nustatykite aiškius lūkesčius: sukūriau įžanginį pranešimą, kuriame aiškiai paaiškinau, kuo pokalbių robotas gali padėti ir kokie jo apribojimai, nuo pat pradžių nustatydamas tinkamus vartotojų lūkesčius.

Laipsniškas atskleidimas: užuot iš anksto užvaldžius vartotojus visomis galimybėmis, įdiegiau sistemą, kurioje pokalbių robotas siūlytų atitinkamus tolesnius veiksmus, atsižvelgdamas į pokalbio kontekstą.
Mobiliesiems įrenginiams pritaikytas dizainas: pamačius, kad daugiau nei 60 % mano naudotojų svetainę lankėsi mobiliuosiuose įrenginiuose, visiškai perkūriau pokalbių sąsają, kad ji nepriekaištingai veiktų mažesniuose ekranuose – didesni jutikliniai elementai, viso ekrano pokalbių režimas ir balso įvesties parinktys.
Vizualinis grįžtamasis ryšys: pridėjau subtilius būsenos indikatorius, kad naudotojai visada žinotų, kas vyksta – ar pokalbių robotas „galvoja“, ar kilo ryšio problemų, ar į pokalbį buvo įtrauktas žmogus.
Vienas konkretus naudotojo sąsajos elementas padarė netikėtą skirtumą: „paaiškinimo“ mygtukas, kurį naudotojai galėjo paliesti, jei manė, kad pokalbių robotas juos neteisingai suprato. Ši paprasta funkcija smarkiai padidino naudotojų pasitenkinimą, nes suteikė jiems akivaizdų kelią į priekį, kai nutrūko ryšys, o ne vertė juos perfrazuoti savo klausimą nuo nulio.
Metrikos prieš ir po buvo stulbinančios – vidutinė pokalbio trukmė padidėjo 340 %, o naudotojų, kurie kelis kartus grįžo naudotis pokalbių robotu, skaičius padvigubėjo. Pamoka buvo aiški: techniniai pajėgumai mažai ką reiškia, jei žmogiškoji sąsaja sukuria trintį.

Pokalbių robotas neegzistuoja atskirai – kad būtų tikrai vertingas, jis turi integruotis su jūsų esama skaitmenine ekosistema. Mano atveju tai reiškė jo prijungimą prie mano klientų duomenų bazės, dokumentacijos sistemos ir pagalbos bilietų platformos.

Pradinė integracija buvo bazinė – pokalbių robotas galėjo ieškoti dokumentuose ir turėjo tik skaitymo prieigą prie DUK. Tačiau vartotojai greitai panoro daugiau: „Ar galite patikrinti mano užsakymo būseną?“, „Ar galite atnaujinti mano el. pašto adresą?“, „Ar galite man sukurti pagalbos bilietą?“. Šie prašymai buvo visiškai logiški vartotojo požiūriu, tačiau reikalavo gilesnės sistemos integracijos.
Naudojau mikropaslaugų metodą, sukurdamas konkrečius API galinius taškus, į kuriuos pokalbių robotas galėtų kreiptis su atitinkama autentifikacija. Kiekviena integracija turėjo savo saugumo aspektus. Tik skaitymo operacijoms, tokioms kaip užsakymo būsenos tikrinimas, įdiegiau patvirtinimo srautą, kuriame vartotojai turėtų pateikti užsakymo numerius ir susijusius el. pašto adresus. Rašymo operacijoms, tokioms kaip paskyros duomenų atnaujinimas, sukūriau patikimesnį autentifikavimo veiksmą.

Viena ypač naudinga integracija buvo su mano bilietų pardavimo sistema. Kai pokalbių robotas aptikdavo, kad negali tinkamai išspręsti problemos, jis pasiūlydavo sukurti pagalbos užklausą, iš anksto užpildytą pokalbio istorija (su vartotojo leidimu). Tai reiškė, kad kai galiausiai atsakydavau į užklausą, turėdavau visą kontekstą, vartotojui nereikėdavo kartoti savo atsakymų.

Integracijos pavertė pokalbių robotą iš atskiros klausimų ir atsakymų sistemos tikru verslo asistentu. Vidutinis dažniausiai pasitaikančių problemų sprendimo laikas sutrumpėjo nuo 8 valandų (laukiant, kol atsakysiu į el. laiškus) iki mažiau nei 3 minučių. Dar svarbiau, kad vartotojai pranešė apie didesnį pasitenkinimą net tada, kai pokalbių robotas negalėjo visiškai išspręsti jų problemos, tiesiog todėl, kad jis galėjo pateikti tiesioginius būsenos atnaujinimus ir sukurti atskaitomybę per užklausų sistemą.

Pamoka: pokalbių roboto vertė padidėja daug kartų, kai jis gali prisijungti prie esamų sistemų ir iš tikrųjų atlikti naudingus veiksmus vartotojų vardu, o ne tik kalbėti apie juos.

Kaip sužinoti, ar jūsų pokalbių robotas iš tikrųjų yra sėkmingas? Šis klausimas pasirodė esąs sudėtingesnis, nei iš pradžių maniau. Neapdoroti naudojimo skaičiai neatskleidė visos istorijos – dažnai naudojamas pokalbių robotas iš tikrųjų gali rodyti prastą svetainės navigaciją, o ne naudingą asistentą.

Įdiegiau daugiaaspektį analizės metodą:
Pokalbių metrikos: stebėjau užbaigimo rodiklius (ar vartotojai gavo atsakymus į savo klausimus?), pokalbio trukmę, nutraukimo taškus ir temų pasiskirstymą, kad suprasčiau, kam žmonės iš tikrųjų naudoja pokalbių robotą.
Verslo poveikio metrikos: matavau sumažėjusį el. laiškų kiekį, gautą atsakant į dažniausiai užduodamus klausimus, pagalbos užklausų nukreipimo rodiklį (problemos išspręstos nekuriant užklausų) ir laiką, per kurį klientai gali ištaisyti problemas.
Vartotojų pasitenkinimas: po kiekvieno pokalbio vartotojai galėjo įvertinti savo patirtį, o aš analizavau šiuos įvertinimus, palygindamas juos su pokalbių transkripcijomis, kad nustatyčiau teigiamos ir neigiamos patirties modelius.
Įtaka pajamoms: stebėjau konversijų rodiklius tų vartotojų, kurie bendravo su pokalbių robotu, ir tų, kurie to nedarė, ypač tų pokalbių, kuriuose pokalbių robotas rekomendavo konkrečias paslaugas.
Duomenys atskleidė netikėtų įžvalgų. Pavyzdžiui, pokalbių robotas buvo vertingiausias ne atsakant į paprasčiausius klausimus (kuriuos būtų galima išspręsti geriau dokumentuojant) ar sudėtingiausius (kurie galiausiai pareikalavo žmogaus įsikišimo), o sprendžiant tarpines problemas, kurioms reikėjo abipusio paaiškinimo, tačiau kurios atitiko nusistovėjusius modelius.

Taip pat pastebėjau, kad vartotojai, kurie bendravo su pokalbių robotu, 37 % dažniau užsisakė aukščiausios kokybės paslaugas, nebūtinai todėl, kad pokalbių robotas buvo puikus pardavėjas, bet todėl, kad sumažino trintį informacijos rinkimo etape kliento kelionėje.
Šie rodikliai lėmė mano tobulinimo planą. Pirmenybę teikiau sričių, kuriose pokalbių robotas jau pasirodė esąs vertingas, tobulinimui, o ne bandžiau priversti jį atlikti viską. Kas dvi savaites peržiūrėdavau pokalbių žurnalus, kuriuose vartotojai išreiškė nepasitenkinimą, nustatydavau modelius ir įgyvendindavau tikslinius patobulinimus – nesvarbu, ar tai reikštų papildomus mokymo duomenis, UX pakeitimus, ar naujas sistemų integracijas.
Šis duomenimis pagrįstas požiūris pavertė pokalbių robotą iš šaunaus technologinio projekto tikru verslo turtu su išmatuojama investicijų grąža.

Savo dirbtinio intelekto pokalbių roboto kūrimas buvo nuolatinių atradimų kelionė. Žvelgiant atgal, pateikiu pagrindines pamokas, kurios gali padėti kitiems, einantiems panašiu keliu:
Pradėkite siaurai, tada plėskite: Sėkmingiausias mano metodas buvo sutelkti pokalbių robotą į kelių dalykų atlikimą išskirtinai gerai, o tada išplėsti jo galimybes. Pradinė versija sprendė tik pagrindinius produkto klausimus, tačiau tai darė labai tiksliai.
Žmogaus ir dirbtinio intelekto perdavimas yra labai svarbus: Nuo pat pradžių projektuokite sklandų eskalavimą. Akimirkos, kai jūsų pokalbių robotas atpažįsta savo apribojimus ir sklandžiai pereina prie žmogaus pagalbos, yra tokios pat svarbios, kaip ir klausimai, į kuriuos jis gali tiesiogiai atsakyti.
Investuokite į gerą pokalbių dizainą: Jūsų raginimų, mokymo duomenų ir pokalbių srautų kokybė yra svarbesnė nei neapdoroto modelio galimybės. Gerai suprojektuota sistema, naudojanti mažesnį modelį, dažnai pranoksta galingą modelį su prastu vadovavimu.
Vartotojai atleidžia apribojimus, bet ne painiavą: Vartotojai suprasdavo, kada pokalbių robotas negalėjo kažko padaryti, bet nusivildavo, kai jis atrodė painus ar prieštaravo pats sau. Aiškumas dėl galimybių pasirodė esąs svarbesnis nei funkcijų įvairovė.
Saugumo ir privatumo aspektai kinta: Pokalbių robotui vis labiau integruojantis į verslo sistemas, saugumo aspektai tapo vis svarbesni. Turėjau įdiegti tinkamą autentifikavimą, duomenų mažinimo praktikas ir aiškius naudotojų sutikimo mechanizmus.

Kalbant apie ateitį, tyrinėju kelias įdomias kryptis:

Multimodalinės galimybės: suteikti naudotojams galimybę įkelti ekrano kopijas arba klaidų pranešimų nuotraukas, o pokalbių robotas pateiktų vaizdines gaires.

Proaktyvi pagalba: pereiti nuo reaktyvaus klausimų ir atsakymų režimo, siekiant nustatyti momentus, kai pokalbių robotas gali proaktyviai pasiūlyti pagalbą, remdamasis naudotojų elgesiu.

Suasmeninimas: naudoti pokalbių istoriją ir paskyros duomenis, siekiant pritaikyti atsakymus grįžtantiems naudotojams, įsiminti jų pageidavimus ir ankstesnes problemas.

Balso sąsaja: daugelis naudotojų išreiškė susidomėjimą kalbėtis su asistentu, o ne rašyti, ypač mobiliuosiuose įrenginiuose.

Šio pokalbių roboto sukūrimas pakeitė ne tik mano verslo operacijas, bet ir mano supratimą apie žmogaus ir kompiuterio sąveiką. Technologijos ir toliau sparčiai vystysis, tačiau pagrindiniai principai išlieka: suprasti naudotojų poreikius, kurti apgalvotus pokalbius ir kurti sistemas, kurios žinotų tiek savo galimybes, tiek apribojimus.

Jei svarstote apie savo pokalbių roboto kūrimą, raginu jus žengti šį žingsnį. Pradėkite nuo mažų dalykų, sutelkite dėmesį į tikrus vartotojų poreikius ir nepamirškite, kad tikslas nėra išlaikyti Turingo testą – siekiama išspręsti realias problemas tikriems žmonėms. Sėkmingiausi dirbtinio intelekto asistentai yra ne tie, kurie tobulai imituoja žmones, o tie, kurie prasmingai papildo jų galimybes.