Kaip aš sukūriau savo AI pokalbių robotą: kūrėjo kelionė

Viskas prasidėjo nuo paprastos problemos – paskendau klientų užklausose. Būdamas vienintelis mano besiplečiančios technologijų konsultacijų svetainės kūrėjas, kasdien praleisdavau valandas atsakydamas į tuos pačius klausimus. Mano produktyvumas mažėjo, ir aš žinojau, kad kažkas turi duoti. Lemputė pasirodė antradienį 2 val. ryto, kai akys blanko nuo atsakymo į dar vieną klausimą "Kaip iš naujo nustatyti slaptažodį?" paštu. Kodėl negalėjau sukurti kažko, kad galėčiau valdyti šias pasikartojančias sąveikas?
Su susidomėjimu stebėjau AI ir didelių kalbų modelių sprogimą, bet dažniausiai kaip žiūrovas. Žinoma, žaidžiau su „ChatGPT“ ir „Claude“, kaip ir visi kiti, bet sukurti savo AI asistentą atrodė kaip kažkas, kas skirta komandoms, turinčioms gilias kišenes ir gilesnę patirtį. Vis dėlto negalėjau atsikratyti minties, kad pritaikytas pokalbių robotas, išmanantis mano verslą viduje ir išorėje, galėtų būti sprendimas, kurio man labai reikėjo.
Tai, kas prasidėjo kaip savaitgalio projektas, skirtas sutaupyti sau laiko, peraugo į šešių mėnesių manija, kuri iš esmės pakeitė mano požiūrį į programinės įrangos kūrimą, vartotojo patirtį ir patį žmogaus ir kompiuterio sąveikos pobūdį. Tai istorija apie tai, kaip aš sukūriau savo pokalbių robotą, ko išmokau pakeliui ir kodėl galbūt norėsite jį sukurti.

Pirmoji didelė kliūtis buvo apsispręsti dėl mano technologijų krūvos. Mane iš karto pribloškė pasirinkimai – ar turėčiau remtis esamomis API, tokiomis kaip OpenAI GPT ar Anthropic's Claude? Ar turėčiau patikslinti atvirojo kodo modelį? O gal turėčiau siekti mažesnių tikslų, naudodamas taisyklėmis pagrįstą sistemą, kuriai visai nereikėjo pažangiausio AI?
Po kelias savaites trukusių tyrimų ir kelių koncepcijos įrodymo testų pasirinkau hibridinį požiūrį. Kaip smegenis naudočiau patobulintą atvirojo kodo kalbos modelį, suporuotą su paieškos papildytos kartos (RAG) sistema, kad suteikčiau prieigą prie mano svetainės dokumentų ir DUK turinio. Tai leistų pokalbių robotui turėti bendrą žvalgybos informaciją, kartu išmanant mano verslą.
Pačiam modeliui pasirinkau „Mistral“ 7B parametrų modelį – pakankamai mažą, kad veiktų mano kuklioje serverio sąrankoje, bet pakankamai galingas, kad natūralia kalba būtų tvarkoma įspūdingai sklandžiai. RAG komponentas naudotų vektorinę duomenų bazę (Pinecone), kad saugotų mano dokumentų įterpimus, kad pokalbių robotas galėtų gauti atitinkamą informaciją atsakydamas į klausimus.
Prietaisas buvo sukurtas naudojant „React“, o „Node.js“ programa apdoroja API iškvietimus ir apdorojimą. Pasirinkau „WebSockets“, kad palaikyčiau pokalbio ryšį su vartotojais ir suteikčiau natūralesnį judėjimą pirmyn ir atgal be puslapio įkėlimo iš naujo.
Šis krūvas suteikė man reikalingo lankstumo ir išlaikiau valdomas išlaidas. Atvirojo kodo fondas reiškė, kad aš nepriklausau API kainoms, kurios gali smarkiai išaugti, jei mano svetainė staiga išpopuliarėtų, o vektorinės duomenų bazės metodas užtikrino, kad mano pokalbių robotas visada turės prieigą prie naujausios informacijos apie mano paslaugas.

Bendrąjį pokalbių robotą nuo tikrai naudingo asistento skiria duomenys – konkrečiai jūsų duomenys. Greitai supratau, kad mano pokalbių robotas bus tiek geras, kiek jam tiekiu informaciją. Tai reiškė, kad reikia ne tik iškrapštyti svetainės turinį; Man reikėjo užfiksuoti esmę, kaip aš bendrauju su klientais.
Pradėjau peržvelgdamas šimtus el. pašto mainų, palaikymo bilietų ir tiesioginių pokalbių žurnalų. Šiuos duomenis anonimizuojau, išskirdamas žmonių užduodamų klausimų modelius ir – svarbiausia – kaip į juos atsakiau. Tai davė man mokymo pavyzdžių, atspindinčių mano tikrąjį toną, techninių detalių lygį ir problemų sprendimo metodą.
Struktūrizuotoms žinioms sukūriau išsamų DUK dokumentą, apimantį viską nuo klausimų apie kainas iki techninių specifikacijų. Taip pat dokumentavau įprastas trikčių šalinimo darbo eigas, užfiksuodamas sprendimų medžius, kuriais nesąmoningai vadovaujuosi padėdamas klientams diagnozuoti problemas.
Pats mokymo procesas buvo kartotinis ir nuolankus. Mano pirmasis bandymas sukūrė pokalbių robotą, kuris žinojo faktus apie mano verslą, bet atsakė kaip įmonės vadovas. Jame trūko šilumos ir kartais humoro, kuris apibūdino mano bendravimą. Grįžau prie piešimo lentos, šį kartą sutelkdamas dėmesį į pavyzdžius, kurie kartu su informacija demonstravo asmenybę.
Vienas netikėtas iššūkis buvo išmokyti pokalbių robotą pasakyti „nežinau“ – tai būtinas bet kurios AI sistemos įgūdis. Turėjau jį specialiai išmokyti atpažinti savo žinių ribas ir prireikus suteikti aiškius kelius į žmogaus pagalbą. Tam reikėjo sukurti neigiamus pavyzdžius ir kraštutinius atvejus, kai teisingas atsakymas buvo eskaluoti, o ne improvizuoti atsakymą.
Po trijų treniruočių pakartojimų pagaliau turėjau modelį, kuris galėtų išlaikyti vadinamąjį „vidurnakčio testą“ – ar jis galėtų susidoroti su tokiais klausimais, į kuriuos aš nemiegodavau atsakyti? Kai jis sėkmingai pervedė vartotoją per mūsų API autentifikavimo procesą tokiu pat aiškumu, kokį naudoju aš, žinojau, kad kažkur judame.

Skirtumas tarp šlovingos DUK paieškos ir tikro pokalbio 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ų.
Mano pirmasis diegimas naudojo paprastą konteksto langą, kuris tiesiog pridėjo keletą paskutinių mainų prie kiekvienos naujos užklausos. Tai pavyko sprendžiant pagrindinius tolesnius klausimus, tačiau greitai nutrūko sudėtinguose scenarijuose. Jei vartotojas paklaustų apie funkciją A, tada B funkciją, tada vėl imtųsi tolesnių veiksmų apie A funkciją, pokalbių robotas susipainiotų.
Galiausiai įdiegiau sudėtingesnę konteksto valdymo sistemą, kuri naudojo metodų derinį:

Slenkantis konteksto langas, kuriame pirmenybė teikiama naujausiems mainams, tačiau taip pat buvo išsaugota svarbi ankstesnė informacija
Objekto stebėjimas, skirtas nustatyti, kada naudotojai grįžo į anksčiau minėtus produktus ar funkcijas
Seanso būsenos valdymas, kad būtų galima stebėti, kur naudotojai dalyvavo kelių etapų procesuose, pvz., paskyros sąrankoje

Proveržis įvyko, kai pridėjau aktualumo balą, kad nustatyčiau, kurios pokalbio istorijos dalys yra svarbiausios dabartinei užklausai. Užuot aklai įtraukusi paskutinius N pasikeitimus, sistema dabar įvertino, kurios ankstesnės pokalbio dalys semantiškai buvo labiausiai susijusios su naujuoju klausimu.
Dėl to pasikeitė vartotojų pasitenkinimas. Dabar pokalbių robotas gali valdyti natūralius pokalbių srautus, tokius kaip: „Kiek kainuoja pagrindinis planas? → "Kokios funkcijos apima?" → "O priemokų planas?" → "Ar jame yra failų bendrinimo funkcija, kurią paminėjote anksčiau?" Nenuleidžiant konteksto ir nesusipainiojant.
Stebėti, kaip vartotojai be nusivylimo sąveikauja su sistema, buvo labai 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 ypatingos situacijos – dažnai tokiais būdais, kokių niekada nesitikėjote. Netrukus po pokalbių roboto paleidimo savo svetainėje pradėjau matyti keletą žavių ir kartais linksmų nesėkmių režimų, kurie grąžino mane prie piešimo lentos.
Vienas lankytojas praleido 15 minučių, bandydamas įtikinti mano pokalbių robotą parašyti eilėraštį apie kibernetinį saugumą (kažkas daugiau, nei numatyta). Kitas bandė jį naudoti kaip bendrąjį programavimo asistentą, įklijavo kodo fragmentus ir paprašė pagalbos dėl technologijų, visiškai nesusijusių su mano verslu. Labiausiai rūpėjo kartais pasitaikančios „haliucinacijos“ – atvejai, kai pokalbių robotas užtikrintai pateikdavo neteisingą informaciją neteisingai interpretuodamas dokumentus arba per daug apibendrindamas mokymo pavyzdžius.
Šiuos iššūkius sprendžiau taikydamas daugiasluoksnį metodą:
Pirma, sistemos eilutėje įdiegiau aiškesnes taikymo srities ribas, aiškiai nurodydamas modeliui jo paskirtį ir apribojimus. Tai sumažino vartotojų, bandančių jį naudoti nenumatytiems tikslams, skaičių.
Antra, pridėjau pasitikėjimo balų mechanizmą. Kai modelio išvestis rodo neapibrėžtumo požymius (dėl kalbinių žymenų arba mažo numatymo patikimumo), jis pripažintų šį neapibrėžtumą vartotojui, o ne pateiktų spėjimus kaip faktus.
Trečia, sukūriau eskalavimo kelią su aiškiais trigeriais. Tam tikros temos arba naudotojo nusivylimo aptikimas paskatintų pokalbių robotą pasiūlyti tiesiogiai susisiekti su vartotoju su manimi, taip užtikrinant sklandų perdavimą.
Galiausiai sukūriau grįžtamojo ryšio kilpą, kurioje vartotojai galėtų pažymėti probleminius atsakymus, kurie buvo automatiškai įtraukti į peržiūrų eilę. Tai suteikė man galimybę sistemingai nustatyti ir išspręsti problemas, o ne žaisti su kraštiniais atvejais.
Turbūt vertingiausia pamoka gauta analizuojant šiuos kraštutinius atvejus: tobulas pokalbių robotas buvo ne tas, kuris niekada neklydo, o tas, kuris grakščiai tvarkėsi su savo apribojimais ir žinojo, kada įtraukti žmogų. Šis požiūrio pokytis pakeitė tai, kaip aš įvertinau sėkmę ir vadovaujuosi tolesniais patobulinimais.

Techniškai puikus pokalbių robotas su gremėzdiška sąsaja yra kaip „Ferrari“ su kvadratiniais ratais – visa ta galia nueina perniek, jei naudotojai negali su juo patogiai naudotis. Šią pamoką išmokau sunkiai, kai mano pirmieji beta versijos bandytojai skundėsi viskuo – nuo lėto atsako laiko iki painių pokalbių srautų.
Pirmoji mano sukurta sąsaja buvo techniškai funkcionali, bet atrodė sterili ir mechaninė. Naudotojų testavimas atskleidė, kad žmonės nedvejojo, ar su juo įsitraukė – tai tiesiog nesijautė kviečianti. Grįžau prie piešimo lentos turėdamas omenyje šiuos principus:
Asmenybė yra svarbi: pridėjau subtilių dizaino elementų, atspindinčių pokalbių roboto asmenybę – draugišką avatarą, spausdinimo indikatorius, imituojančius žmogaus ritmą, ir retkarčiais sukurtų animacijų, suteikiančių gyvumo pojūtį, neįžengiant į nepaprastą slėnį.
Nustatykite aiškius lūkesčius: sukūriau įvadinį pranešimą, kuriame aiškiai paaiškinau, kuo gali padėti pokalbių robotas, ir jo apribojimus, nuo pat pradžių nustatydamas tinkamus vartotojų lūkesčius.
Laipsniškas atskleidimas: užuot priblokšęs naudotojus visomis galimybėmis iš anksto, įdiegiau sistemą, kurioje pokalbių robotas, atsižvelgdamas į pokalbio kontekstą, pasiūlytų atitinkamus tolesnius veiksmus.
Mobiliesiems pritaikytas dizainas: pamačius, kad daugiau nei 60 % mano vartotojų svetainę pasiekia mobiliaisiais įrenginiais, visiškai perdariau pokalbių sąsają, kad ji nepriekaištingai veiktų mažesniuose ekranuose – didesni jutikliniai objektai, viso ekrano pokalbių režimas ir balso įvesties parinktys.
Vaizdinis grįžtamasis ryšys: pridėjau subtilių būsenos indikatorių, kad vartotojai visada žinotų, kas vyksta – ar pokalbių robotas „galvoja“, ar kilo ryšio problemų, ar į pokalbį buvo įtrauktas žmogus.
Vienas konkretus vartotojo sąsajos elementas padarė stebėtiną skirtumą: mygtukas „aiškinimas“, kurį vartotojai galėjo spustelėti, jei jautė, kad pokalbių robotas juos neteisingai suprato. Ši paprasta funkcija žymiai pagerino vartotojų pasitenkinimą, nes nutrūkus ryšiui suteikė jiems akivaizdų kelią į priekį, o ne privertė perfrazuoti klausimą nuo nulio.
„Prieš ir po“ metrika buvo įspūdinga – vidutinė pokalbių trukmė padidėjo 340%, o vartotojų, kurie grįžo naudotis pokalbių robotu, skaičius padvigubėjo. Pamoka buvo aiški: techninės galimybės mažai ką reiškia, jei žmogaus sąsaja sukuria trintį.

Pokalbių robotas neegzistuoja atskirai – kad būtų tikrai vertingas, jis turi integruotis su esama skaitmenine ekosistema. Mano atveju tai reiškė prijungimą prie savo klientų duomenų bazės, dokumentų sistemos ir palaikymo bilietų platformos.
Pradinė integracija buvo pagrindinė – pokalbių robotas galėjo ieškoti dokumentų ir turėjo tik skaitymo prieigą prie DUK. Tačiau vartotojai greitai norėjo daugiau: „Ar galite patikrinti mano užsakymo būseną? "Ar galite atnaujinti mano el. pašto adresą?" "Ar galite sukurti man paramos bilietą?" Šios užklausos buvo visiškai logiškos vartotojo požiūriu, tačiau reikalavo gilesnės sistemos integracijos.
Naudojau mikropaslaugų metodą, kurdamas konkrečius API galinius taškus, kuriuos pokalbių robotas galėtų iškviesti su tinkamu autentifikavimu. Kiekviena integracija turėjo savo saugumo sumetimų. Tik skaitomoms operacijoms, pvz., užsakymo būsenos tikrinimui, įdiegiau patvirtinimo eigą, kai naudotojai turės pateikti užsakymų numerius ir susijusius el. pašto adresus. Rašymo operacijoms, tokioms kaip paskyros informacijos atnaujinimas, sukūriau patikimesnį autentifikavimo veiksmą.
Viena ypač naudinga integracija buvo su mano bilietų pardavimo sistema. Kai pokalbių robotas aptiko, kad jis negali tinkamai išspręsti problemos, jis pasiūlys sukurti palaikymo bilietą, iš anksto užpildytą pokalbių istorija (su vartotojo leidimu). Tai reiškė, kad kai galiausiai atsakiau į bilietą, turėjau visą kontekstą ir vartotojui nereikėjo kartotis.
Integracijos pavertė pokalbių robotą iš atskiros klausimų ir atsakymų sistemos į tikrą verslo asistentą. Vidutinis įprastų problemų sprendimo laikas sumažėjo nuo 8 valandų (laukiu, kol atsakysiu į el. laiškus) iki mažiau nei 3 minučių. Galbūt dar svarbiau yra tai, kad vartotojai pranešė apie didesnį pasitenkinimą net tada, kai pokalbių robotas negalėjo visiškai išspręsti jų problemos, nes jis gali nedelsiant atnaujinti būseną ir sukurti atskaitomybę per bilietų pardavimo sistemą.
Pamoka: pokalbių roboto vertė padidėja, kai jis gali prisijungti prie jūsų esamų sistemų ir iš tikrųjų atlikti naudingus veiksmus vartotojų vardu, o ne tik apie juos kalbėti.

Kaip sužinoti, ar jūsų pokalbių robotas tikrai sėkmingas? Šis klausimas pasirodė sudėtingesnis, nei maniau iš pradžių. Neapdoroti naudojimo skaičiai neatskleidė visos istorijos – dažnai naudojamas pokalbių robotas iš tikrųjų gali rodyti prastą svetainės naršymą, o ne naudingą asistentą.
Įgyvendinau daugialypį analizės metodą:
Pokalbių metrika: stebėjau užbaigimo rodiklius (ar vartotojai gavo atsakymus į savo klausimus?), pokalbio trukmę, atsisakymo taškus ir temų pasiskirstymą, kad suprasčiau, kam žmonės iš tikrųjų naudoja pokalbių robotą.
Poveikio verslui metrika: įvertinau sumažėjusį el. laiškų skaičių, skirtą dažniausiai užduodamiems klausimams, palaikymo bilietų nukreipimo rodiklį (problemos išspręstos nesukūrus bilietų) ir klientų užklausų sprendimo laiką.
Vartotojų pasitenkinimas: po kiekvieno pokalbio vartotojai galėjo įvertinti savo patirtį. Aš išanalizavau šiuos įvertinimus pagal pokalbių stenogramas, kad nustatytų teigiamos ir neigiamos patirties modelius.
Įtaka pajamoms: stebėjau vartotojų, kurie naudojasi pokalbių robotu, ir tų, kurie to nedarė, konversijų rodiklius, ypač pokalbiuose, kuriuose pokalbių robotas rekomendavo konkrečias paslaugas.
Duomenys atskleidė stebinančias įžvalgas. Pavyzdžiui, pokalbių robotas buvo vertingiausias ne už pačius paprasčiausius klausimus (kuriuos būtų galima išspręsti turint geresnę dokumentaciją) ar sudėtingiausius klausimus (kurie galiausiai reikėjo žmogaus įsikišimo), bet dėl vidurio klausimų, kuriuos reikėjo paaiškinti pirmyn ir atgal, tačiau jie buvo vadovaujami nusistovėjusiais modeliais.
Taip pat išsiaiškinau, kad vartotojai, kurie bendravo su pokalbių robotu, 37 % dažniau prisiregistravo gauti aukščiausios kokybės paslaugas, nebūtinai todėl, kad pokalbių robotas buvo puikus pardavėjas, bet todėl, kad sumažino trintį kliento kelionės informacijos rinkimo etape.
Šios metrikos vadovavosi mano tobulinimo planu. Pirmenybę teikiau sritims, kuriose pokalbių robotas jau pasirodė vertingas, tobulinimui, o ne stengiausi, kad jis viską padarytų. 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 sistemos integracijas.
Šis duomenimis pagrįstas požiūris pavertė pokalbių robotą iš šaunaus technologijų projekto į tikrą verslo turtą su išmatuojama IG.

Savo AI pokalbių roboto kūrimas buvo nuolatinių atradimų kelionė. Žvelgiant atgal, čia pateikiamos pagrindinės pamokos, kurios gali padėti kitiems panašiais keliais:
Pradėkite siaurai, tada išplėskite: mano sėkmingiausias būdas buvo sutelkti dėmesį į pokalbių robotą, kad jis atliktų keletą dalykų ypač gerai, prieš išplečiant jo galimybes. Pradinėje versijoje buvo nagrinėjami tik pagrindiniai gaminio klausimai, tačiau tai buvo padaryta labai tiksliai.
Žmogaus ir dirbtinio intelekto perdavimas yra labai svarbus: dizainas grakščiai eskalacijai nuo pat pradžių. Akimirkos, kai jūsų pokalbių robotas atpažįsta savo apribojimus ir sklandžiai pereina prie žmogaus pagalbos, yra lygiai taip pat svarbūs, kaip ir klausimai, į kuriuos jis gali atsakyti tiesiogiai.
Investuokite į gerą pokalbio dizainą: jūsų raginimų, mokymo duomenų ir pokalbių srautų kokybė yra svarbiau nei neapdorotos modelio galimybės. Gerai suprojektuota sistema, naudojanti mažesnį modelį, dažnai pranoksta galingą modelį, kurio valdymas prastas.
Vartotojai atleidžia apribojimus, bet ne painiavą: vartotojai suprato, kai pokalbių robotas negali ko nors padaryti, bet nusivilia, kai atrodė sutrikęs arba prieštarauja pats sau. Aiškumas apie galimybes pasirodė svarbesnis nei funkcijų platumas.
Saugumo ir privatumo aspektai keičiasi: pokalbių robotui vis labiau integruojantis į verslo sistemas, saugumo sumetimai tapo vis svarbesni. Turėjau įdiegti tinkamą autentifikavimo, duomenų mažinimo praktiką ir aiškius vartotojo sutikimo mechanizmus.
Kalbant apie ateitį, aš tyrinėju keletą įdomių krypčių:
Daugiarūšės galimybės: naudotojams suteikiama galimybė įkelti klaidų pranešimų ekrano kopijas ar nuotraukas, o pokalbių robotas teikia vaizdines nuorodas.
Proaktyvi pagalba: ne tik reaktyvūs klausimai ir atsakymai, bet ir nustatyti momentus, kai pokalbių robotas gali aktyviai pasiūlyti pagalbą, atsižvelgdamas į vartotojo elgesį.
Suasmeninimas: pokalbių istorijos ir paskyros duomenų naudojimas norint pritaikyti atsakymus grįžtantiems vartotojams, prisiminti jų nuostatas ir ankstesnes problemas.
Balso sąsaja: daugelis vartotojų išreiškė susidomėjimą kalbėti su asistentu, o ne rašyti, ypač mobiliuosiuose įrenginiuose.
Šio pokalbių roboto kūrimas pakeitė ne tik mano verslo operacijas, bet ir supratimą apie žmogaus ir kompiuterio sąveiką. Technologijos ir toliau sparčiai vystysis, tačiau pagrindiniai dalykai išlieka: suprasti vartotojų poreikius, kurti apgalvotus pokalbius ir kurti sistemas, kurios žinotų savo galimybes ir apribojimus.
Jei ketinate sukurti savo pokalbių robotą, raginu jus žengti žingsnį. Pradėkite nuo mažo, susitelkite į tikrus vartotojų poreikius ir atminkite, kad tikslas nėra išlaikyti Turingo testą – tai išspręsti tikras problemas tikriems žmonėms. Sėkmingiausi dirbtinio intelekto padėjėjai yra ne tie, kurie puikiai imituoja žmones, o tie, kurie reikšmingai padidina žmogaus galimybes.