Balso sąveika tikruoju laiku suteikia žmonėms iš esmės kitokį būdą naudotis DI grindžiamomis programomis. Užuot rinkę tekstą ar naršę meniu, naudotojai kalba natūraliai ir gauna tikruoju laiku pateikiamus, emocinį kontekstą perteikiančius atsakymus.
Norint sukurti puikią balso patirtį tikruoju laiku, reikia koordinuoti gyvą sąveiką. Būtent čia prasideda tikrasis produkto kūrimo darbas. Tikralaikė sąveika yra betarpiška ir gyva, o sukurti tokią patirtį išlaikančią programą – atskiras inžinerinis iššūkis.
Modelis yra tik viena sistemos dalis. Gamybinėms programoms reikia balsui pritaikytos infrastruktūros, aiškiai atskirtų pokalbio eigos ir gilesnio protavimo procesų bei įvykiais grindžiamo besirutuliojančio seanso valdymo.
Daugiausia neišspręstų sunkumų susiję su apsaugos priemonėmis ir vertinimu. Saugos patikros turi neatsilikti nuo tiesioginio garso, o tokias trumpalaikes pokalbio savybes kaip tempas, tonas ir eiga sunku įvertinti tradiciniais metodais.
Dauguma šiandienos balsą palaikančių DI programų vis dar veikia taip pat: gaunama kalba, ji paverčiama tekstu, modelis apdoroja informaciją, o susintetintas balsas perskaito atsakymą. Tai veikia. Tačiau sąveika ir atrodo kaip apdorojimo grandinė, o ne pokalbis.
Balso sąveika tikruoju laiku tai pakeičia. Naudotojai kalba natūraliai ir gauna tinkamu tempu, tonu bei emociniu kontekstu perteikiamus atsakymus. Ši patirtis greitesnė ir sklandesnė nei naudojant grandinines kalbos vertimo tekstu sistemas: ji labiau primena pokalbį su žmogumi nei sistemos valdymą.
Pastebėjome, kad tai atveria produktų galimybes, kurias sunku įgyvendinti naudojant grandinines architektūras. Tikruoju laiku veikiantys balso agentai gali aptarnauti klientus be ilgų, ribojančių interaktyviojo atsako balsu (IVR) meniu ir peradresavimo tarp skyrių. Jie gali mokyti, padėti pradėti naudotis paslauga, gerinti prieinamumą įvairiose terpėse ir atlikti daugybę kitų užduočių. Visur, kur pokalbis balsu pranašesnis už tekstines sąsajas, verta kurti tikralaikio balso sprendimus.
Daugumoje balsą palaikančių programų taikomas vadinamasis „grandininis metodas“: atskirų modelių seka kalbai paversti tekstu, kalbai apdoroti ir tekstui paversti kalba. Šios sistemos veikia gerai ir atveria daug galimybių, tačiau garsas naudojamas tik proceso pradžioje ir pabaigoje. Atskiri etapai sukuria privalomą struktūrą ir delsą, todėl sąveika atrodo ne tokia natūrali kaip tikras pokalbis.
Balso sąveikai tikruoju laiku taikomas kitoks metodas. Užuot klausius, mąsčius ir kalbėjus naudojant atskirus modelius, visas tris užduotis tiesiogiai atlieka vienas modelis, vienu metu suprantantis ir generuojantis garsą bei transkripcijas. Įvestis ir išvestis apdorojamos nuolat, todėl sistema gali natūraliu tempu pateikti emocingus atsakymus ir išlaikyti tikrovišką gyvo pokalbio ritmą. Todėl tempas, tonas ir pertraukimų valdymas tampa esmine produkto dalimi.
Tikralaikė patirtis patraukli dėl betarpiškumo, tačiau ją įgyvendinti sunku, nes niekas nelaukia savo eilės. Tam nepakanka greitai ir tiksliai generuoti garsą. Sunkiausia yra visa kita. Modelis veikia tiesioginiame seanse, todėl visa jį supanti sistema – būsena, sauga, procesų koordinavimas ir valdymas – turi veikti kartu su pokalbiu tuo pačiu tempu.
Grandininėje balso programoje paeiliui vykstantis pokalbis suteikia aiškią apsikeitimo replikomis struktūrą. Naudotojas kalba, sistema atsako, tada prasideda kitas etapas. Balso sąveika tikruoju laiku tokios struktūros nesuteikia. Abi pusės gali kalbėti vienu metu arba gali nekalbėti nė viena ir įsivyrauti tyla. Naudotojas gali pertraukti atsakymą arba užduoti papildomą klausimą sistemai dar nebaigus kalbėti. Pertraukimai nebėra reti kraštutiniai atvejai – jie tampa pagrindiniu sąveikos modeliu.
Dėl šio modelio tikralaikės programos iš esmės tampa koordinavimo uždaviniu, o modelį supanti sistema yra ne mažiau svarbi nei pats modelis.
Norint tokią sistemą naudoti dideliu mastu, ją reikia projektuoti specialiai tiesioginei sąveikai. Gamybinėse sistemose nuolat pasikartoja trys pagrindinės dalys.
Tikruoju laiku vykstančiuose balso seansuose reikia valdyti garso srautą, kalbėjimo eiliškumą, pertraukimus, ryšio gyvavimo ciklą ir agento vykdymą. Atsižvelgiant į programos diegimo vietą, gali reikėti ir telefonijos palaikymo. Tai yra pamatinės patirties dalys, būtinos norint plėsti programą.
Pirmasis reikalavimas – balsui pritaikytas seansų sluoksnis. Tikralaikio ryšio (RTC) sistemos suteikia programai aplinką, kurioje galima valdyti dalyvius, transliuoti garsą ir vykdyti agentus telefonijos aplinkoje. Mūsų patirtis rodo, kad ypač naudinga yra Livekit: ji iš karto suteikia mažos delsos WebRTC technologijų rinkinį, kokybiškai slopinantį triukšmą ir mažinantį signalo svyravimus. Dėl papildomo sudėtingumo šį sluoksnį retai verta kurti patiems.
Kelių agentų architektūra, skirta balsui tikruoju laiku, iš esmės grindžiama atsakomybių atskyrimu.
Tikruoju laiku veikiantys balso modeliai labai efektyviai transliuoja pokalbio garsą, tačiau nėra optimizuoti gilesniam protavimui. Tokias užduotis kaip įrankių iškvietimas, informacijos paieška ar struktūrizuotas sprendimų priėmimas geriau patikėti kitam modeliui.
Naudingas sprendimo modelis – atsakiklio ir mąstytojo architektūra.
Atsakiklis yra tikruoju laiku veikiantis balso agentas. Jis palaiko tiesioginę sąveiką: klausosi, kalba, valdo pertraukimus ir užtikrina sklandžią pokalbio eigą. Jį projektuojant pirmenybė teikiama greitai reakcijai, aiškumui ir emociniam nuoseklumui.
Mąstytojas yra atskiras agentas, naudojantis protavimui pritaikytą modelį. Jis veikia už pagrindinio sąveikos kanalo ribų ir atlieka tokias užduotis kaip įrankių naudojimas, informacijos paieška ir planavimas. Prireikus atsakiklis gali jį pasitelkti ir įtraukti rezultatus į pokalbį.
Kai kuriais atvejais mąstytojas gali pats atlikti protavimą. Kitais atvejais jis gali koordinuoti specializuotų agentų grupę. Svarbiausia, kad šį darbą atliktų protavimo užduotims geriau pritaikytas modelis.
Nauda paprasta: atsakiklis išlieka greitas, susitelkęs ir tinkamas pokalbiui, o mąstytojas atlieka darbus, kuriems reikia daugiau laiko, konteksto ar struktūros.
Ateityje dėl priešakinių modelių pažangos šio metodo gali nebereikėti, tačiau kol kas mūsų patirtis rodo, kad jis nuosekliai pranoksta vienu agentu grindžiamus sprendimus.
Tikruoju laiku veikiančios balso sistemos natūraliai sukuria nenutrūkstamą įvykių srautą.
Naudotojai pradeda kalbėti, daro pauzes ir pertraukia. Transkripcijos atnaujinamos dalimis. Atsakymai generuojami ir transliuojami. Gaunami išorinių sistemų rezultatai. Seanso sąlygos kinta. Visa tai galima fiksuoti, transliuoti ir saugoti kaip svarbiausius įvykius, nulėmusius konkrečią dabartinę pokalbio būseną. Be jų prarandame galimybę tiksliai ir kryptingai įsikišti.
Įvykiais grindžiamas metodas suteikia aiškų būdą visa tai valdyti. Sistema fiksuoja įvykius, kai jie nutinka, atnaujina seanso būseną ir inicijuoja tinkamus tolesnius veiksmus.
Paprastos apdorojimo programos neapkrauna tikralaikio proceso, o sudėtingesnės užduotys – būsenos automatų atnaujinimas, rodiklių registravimas, neskelbtinos informacijos šalinimas, duomenų bazių atnaujinimas ir seanso užbaigimas – inicijuojamos kaip asinchroninės foninės užduotys.
Pridedant funkcijų, šių foninių užduočių skaičius gali sparčiai augti. Net nedideli produkto pakeitimai gali sukurti naujų įvykių srautų ir priklausomybių. Gerai struktūrizuota lygiagrečių procesų architektūra padeda išlaikyti sistemą suprantamą ir patikimą jai tobulėjant.
Šis įvykiais grindžiamas metodas taip pat padeda spręsti itin svarbų produkto klausimą – formuoti patį pokalbį. Tikruoju laiku veikianti garso sistema ne tik generuoja atsakymus: ji valdo tempą, tylą bei pertraukimus ir nusprendžia, kaip ir kada užbaigti seansą. Ši elgsena yra produkto patirties dalis, todėl ją verta projektuoti sąmoningai.
Seanso būsenai kintant pagal replikų skaičių, praėjusį laiką ar naudotojo elgseną, sistema gali pateikti atsakikliui tikslinių nurodymų. Artėjant seanso trukmės ribai, ji gali paraginti agentą padėti naudotojui užbaigti pokalbį, o sąveikai įstrigus – pateikti paaiškinimą. Tokios intervencijos paprastos, tačiau dėl jų patirtis atrodo apgalvota ir vientisa.
Gerai suprojektuota sistema aiškiai atspindi seanso būseną: kas kalba, kaip vyksta pokalbis ir kokios sąlygos jau įvykdytos. Ši įvykių srauto nuolat atnaujinama būsena leidžia tinkamu metu pateikti tinkamus nurodymus.
Naudotojams skirtose DI sistemose apsaugos priemonės yra būtinos. Jos padeda užtikrinti saugą, atitiktį, patikimumą ir užkirsti kelią piktnaudžiavimui. Paeiliui veikiančioje sistemoje aišku, kada jas taikyti: naudotojui baigus kalbėti arba prieš pateikiant atsakymą.
Balso sąveikoje tikruoju laiku daugumos tokių patogių patikros taškų nebelieka. Naudotojo įvestis gaunama nuolat. Garso išvestis tuo metu jau gali būti transliuojama. Galutinės transkripcijos dažnai atsilieka nuo garso. Jei sistema prieš tikrindama laukia viso pranešimo, pokalbis nebeatrodo vykstantis tikruoju laiku.
Todėl apsaugos priemonės turi veikti lygiagrečiai su pokalbiu, kad sąveika išliktų gyva ir natūrali. Vienas būdas – perduodamą garsą kaupti buferyje ir asinchroniškai vertinti gaunamus transkripcijos fragmentus. Taip saugos patikros gali vykti beveik tikruoju laiku, nestabdant sąveikos.
Suveikus apsaugos priemonei, sistema gali reaguoti atsižvelgdama į kontekstą: pakreipti pokalbį kita linkme, pakoreguoti elgseną arba prireikus užbaigti seansą. Taip apsaugos priemonės veikia tikruoju laiku ir neblogina naudotojo patirties.
Sunkiausia vertinant pokalbių sistemą tikruoju laiku tai, kad kai kurių svarbiausių savybių – tempo, pertraukimų, pokalbio eigos ir tono – neįmanoma įvertinti atliekant tik transkripcijomis pagrįstus bandymus.
Įprastose vertinimo eigose sistemai pateikiami tikroviški scenarijai, stebimi jos rezultatai ir skiriami įverčiai. Teksto arba grandininėse garso sistemose tai paprasta: pateikiamas tekstas ir patikrinamas tekstinis rezultatas. Tikruoju laiku įvestis yra tiesioginis garsas, o svarbiausia pokalbio dinamika priklauso nuo laiko: kaip agentas tvarkosi su persidengiančia kalba, kaip greitai atsako ir kaip tęsia pokalbį po pertraukimo.
Rankinis testavimas, kai kalbamasi tiesiogiai su agentu, leidžia įvertinti šias savybes, tačiau jo neįmanoma lengvai išplėsti. Transkripcijomis pagrįstą automatizavimą galima išplėsti, tačiau jis pašalina signalus, skiriančius gerą tikralaikę patirtį nuo prastos.
Vieno metodo nepakanka. Praktiškai reikia kelių metodų derinio:
Agentų tarpusavio vertinimas: antras tikruoju laiku veikiantis agentas, kuriam nurodyta įkūnyti konkrečią naudotojo personą, kalbasi su bandoma sistema. Trečiasis LLM, veikiantis kaip vertintojas, įvertina sąveiką. Taip dideliu mastu išbandomas visas garso kelias, įskaitant laiką ir pertraukimų valdymą.
Nefunkciniai rodikliai: laikas iki pirmojo garso ir transkripcijos emocinio tono analizė suteikia kiekybinių pokalbio kokybės pakaitinių rodiklių.
Rankinė kokybinė peržiūra: ji tebėra būtina norint aptikti automatinių rodiklių nepastebimas problemas, ypač susijusias su tonu ir natūralumu.
Nė vienas metodas neapima visko. Norint tikruoju laiku veikiančius agentus naudoti gamybinėje aplinkoje, reikia derinti visus tris metodus. Tačiau net ir tada tikralaikio garso vertinimo priemonės tebėra nebrandžios, palyginti su tekstiniam DI skirtomis priemonėmis.
Balso sąveika tikruoju laiku keičia patį produktą. Naudotojo patirtį formuoja ne tik žodžiai, bet ir tempas, pertraukimai, tyla bei pokalbio pratęsimas po trikdžių.
Vadinasi, modelis yra tik viena sistemos dalis. Gamybinei balso sąveikai tikruoju laiku reikia balsui pritaikyto seansų sluoksnio, aiškiai atskirtų kalbėjimo ir protavimo procesų bei įvykiais grindžiamo tiesioginio seanso valdymo. Apsaugos priemonės tebėra pagrindinė delsos priežastis, tačiau kūrybiški sprendimai gali išsaugoti didžiąją tikralaikės patirties dalį.
Silpniausia viso sprendimo dalis tebėra vertinimas. Vis dar nėra nusistovėjusio būdo išbandyti savybes, nuo kurių priklauso gera balso patirtis tikruoju laiku: tempą, toną, pertraukimų valdymą ir pokalbio eigą. Kol toks būdas neatsiras, šią technologiją kuriančioms komandoms teks derinti automatinius testus, agentų tarpusavio bandymus ir rankines peržiūras.