Reaaliaikainen puhe tarjoaa täysin uuden tavan käyttää tekoälypohjaisia sovelluksia. Kirjoittamisen tai valikoissa siirtymisen sijaan käyttäjät voivat puhua luontevasti ja saada vastauksia reaaliaikaisella rytmillä ja tunnevivahteilla.
Erinomaisen reaaliaikaisen puhekokemuksen rakentamisessa on kyse elävän vuorovaikutuksen koordinoinnista. Tästä alkaa varsinainen tuotetyö. Reaaliaikainen kokemus on välitön ja luonnollinen. Sitä ylläpitävän sovelluksen rakentaminen on oma tekninen haasteensa.
Malli on vain yksi osa järjestelmää. Tuotantosovellukset tarvitsevat puheelle suunnitellun infrastruktuurin, keskustelun kulun ja syvemmän päättelyn selkeän erottamisen sekä tapahtumapohjaisen ohjauksen, jolla istuntoa hallitaan sen edetessä.
Suuri osa jäljellä olevista haasteista liittyy suojamekanismeihin ja arviointiin. Turvallisuustarkistusten on pysyttävä suoran äänen tahdissa, ja hetkellisiä keskusteluominaisuuksia, kuten ajoitusta, äänensävyä ja keskustelun sujuvuutta, on vaikea arvioida perinteisin menetelmin.
Useimmat puhetta tukevat tekoälysovellukset toimivat edelleen samalla tavalla: puhe muunnetaan tekstiksi, malli ajattelee ja synteettinen ääni lukee vastauksen. Se toimii. Vuorovaikutus kuitenkin tuntuu siltä, mitä se onkin: käsittelyputkelta, ei keskustelulta.
Reaaliaikainen puhe muuttaa tämän. Käyttäjät puhuvat luontevasti ja saavat vastauksia, joissa välittyvät rytmi, äänensävy ja tunnevivahteet. Kokemus on ketjutettuja puheentunnistusputkia nopeampi ja sujuvampi: se muistuttaa enemmän ihmiselle puhumista kuin järjestelmän käyttämistä.
Olemme nähneet tämän mahdollistavan tuotteita ja käyttötapoja, joihin putkiarkkitehtuurit soveltuvat huonosti. Reaaliaikaiset puheagentit voivat hoitaa asiakaspalvelutilanteita, jotka muutoin vaatisivat pitkiä ja rajoittavia IVR-valikoita sekä siirtoja osastolta toiselle. Ne voivat valmentaa, opastaa alkuun, tukea saavutettavuutta eri viestintäkanavissa ja paljon muuta. Reaaliaikaista puhetta kannattaa rakentaa kaikkialle, missä puhuttu keskustelu on tekstikäyttöliittymää parempi vaihtoehto.
Useimmat puhetta tukevat sovellukset käyttävät niin sanottua ”ketjutettua lähestymistapaa”: puheentunnistukseen, kielen käsittelyyn ja puhesynteesiin käytetään erillisten mallien muodostamaa putkea. Nämä järjestelmät toimivat hyvin ja tarjoavat monenlaisia mahdollisuuksia, mutta ääni on mukana vain putken alku- ja loppupäässä. Erilliset vaiheet tuovat vuorovaikutukseen pakollista rakennetta ja viivettä, minkä vuoksi se tuntuu aitoa keskustelua vähemmän luonnolliselta.
Reaaliaikainen puhe toimii toisin. Kuuntelemiseen, ajattelemiseen ja puhumiseen tarkoitettujen erillisten mallien sijaan yksi malli hoitaa kaikki kolme suoraan sekä ymmärtää ja tuottaa ääntä ja litteraatteja samanaikaisesti. Syötettä vastaanotetaan ja tuotosta lähetetään jatkuvasti. Näin järjestelmä voi vastata luontevalla ajoituksella ja tunteikkaasti sekä säilyttää elävän keskustelun realistisen rytmin. Näin ajoituksesta, äänensävystä ja keskeytysten käsittelystä tulee keskeinen osa tuotetta.
Reaaliaikainen kokemus houkuttelee välittömyydellään, mutta sen toteuttaminen on vaikeaa, koska mikään ei odota vuoroaan. Sen tukemiseen tarvitaan muutakin kuin nopeaa ja tarkkaa äänen tuottamista. Vaikeaa on kaikki muu. Malli toimii aktiivisessa istunnossa, joten myös kaiken sitä ympäröivän – tilan, turvallisuuden, orkestroinnin ja ohjauksen – on toimittava keskustelun rinnalla samassa reaaliaikaisessa tahdissa.
Ketjutetussa puhesovelluksessa vuoropohjainen keskustelu tarjoaa selkeän edestakaisen rakenteen. Käyttäjä puhuu, järjestelmä vastaa ja seuraava vaihe alkaa. Reaaliaikaisessa puheessa tätä rakennetta ei ole. Molemmat osapuolet voivat puhua yhtä aikaa, tai kumpikaan ei puhu ja syntyy hiljaisuus. Käyttäjä voi keskeyttää vastauksen tai esittää jatkokysymyksen ennen kuin järjestelmä on lopettanut puhumisen. Keskeytykset eivät enää ole poikkeustapauksia, vaan vuorovaikutuksen keskeinen toimintamalli.
Tämän vuoksi reaaliaikaisissa sovelluksissa on pohjimmiltaan kyse koordinoinnista, ja mallia ympäröivä järjestelmä on yhtä tärkeä kuin itse malli.
Tällaisen järjestelmän tukeminen laajassa mittakaavassa edellyttää suunnittelua nimenomaan elävää vuorovaikutusta varten. Tuotantoon asti päätyvissä järjestelmissä tämä näkyy toistuvasti kolmena osa-alueena.
Reaaliaikaisissa puheistunnoissa on hallittava äänen suoratoisto, vuorottelu, keskeytykset, yhteyden elinkaari ja agentin suoritus. Sovelluksen käyttöympäristöstä riippuen myös puhelinverkon tukea saatetaan tarvita. Nämä ovat käyttökokemuksen perusta ja keskeisiä sovelluksen skaalaamisessa.
Ensimmäinen vaatimus on puheelle suunniteltu istuntokerros. Reaaliaikaisen viestinnän eli RTC:n kehykset tarjoavat sovellukselle ympäristön osallistujien hallintaan, äänen suoratoistoon ja agenttien suorittamiseen puhelinympäristössä. Kokemuksemme mukaan etenkin Livekit on ollut hyödyllinen. Se tarjoaa vähäviiveisen WebRTC-pinon sekä laadukkaan melun- ja värinänvaimennuksen valmiina. Tämän kerroksen toteuttaminen itse on harvoin lisävaivan arvoista.
Reaaliaikaisen puheen moniagenttiarkkitehtuurissa on pohjimmiltaan kyse vastuiden erottamisesta.
Reaaliaikaiset puhemallit soveltuvat erittäin hyvin keskusteluäänen suoratoistoon, mutta niitä ei ole optimoitu syvempään päättelyyn. Työkalukutsut, tiedonhaku ja jäsennelty päätöksenteko kannattaa antaa toisen mallin tehtäväksi.
Hyödyllinen toimintamalli on vastaaja–ajattelija-arkkitehtuuri.
Vastaaja on reaaliaikainen puheagentti. Se ylläpitää elävää vuorovaikutusta: kuuntelee, puhuu, käsittelee keskeytyksiä ja pitää keskustelun sujuvana. Sen suunnittelussa painotetaan reagointinopeutta, selkeyttä ja tunteiden jatkuvuutta.
Ajattelija on erillinen agentti, jonka taustalla on päättelyyn kykenevä malli. Se toimii varsinaisen keskustelukanavan ulkopuolella ja hoitaa esimerkiksi työkalujen käytön, tiedonhaun ja suunnittelun. Vastaaja voi kutsua sitä tarvittaessa ja tuoda tulokset takaisin keskusteluun.
Joissakin tapauksissa ajattelija voi hoitaa päättelyn suoraan. Toisissa tapauksissa se voi orkestroida erikoistuneiden agenttien joukkoa. Keskeistä on, että työn tekee päättelytehtäviin paremmin soveltuva malli.
Hyöty on selvä: vastaaja pysyy nopeana, keskustelukykyisenä ja keskittyneenä, kun taas ajattelija hoitaa enemmän aikaa, kontekstia tai rakennetta vaativan työn.
Tulevat edistyneiden mallien kehitysaskeleet saattavat tehdä tästä lähestymistavasta tarpeettoman, mutta toistaiseksi tämä malli on kokemuksemme mukaan päihittänyt johdonmukaisesti yhden agentin ratkaisut.
Reaaliaikaiset puhejärjestelmät tuottavat luontevasti jatkuvan tapahtumavirran.
Käyttäjät alkavat puhua, pitävät taukoja ja keskeyttävät. Litteraatit päivittyvät vaiheittain. Vastauksia tuotetaan ja suoratoistetaan. Ulkoisia tuloksia saapuu. Istunnon olosuhteet muuttuvat. Kaikki nämä voidaan tallentaa, suoratoistaa ja säilyttää avaintapahtumina, jotka ovat muodostaneet keskustelun nykyisen tilan. Ilman niitä menetämme mahdollisuuden tarkkoihin ja kohdennettuihin toimenpiteisiin.
Tapahtumapohjainen lähestymistapa tarjoaa tähän selkeän hallintatavan. Järjestelmä tallentaa tapahtumat niiden syntyessä, päivittää istunnon tilan ja käynnistää tarvittavat jatkotoimet.
Kevyet käsittelijät pitävät reaaliaikaisen polun reagointikykyisenä. Vaativammat tehtävät – kuten tilakoneiden päivittäminen, mittareiden kirjaaminen, arkaluonteisten tietojen poistaminen, tietokantojen päivittäminen ja istunnosta poistuminen – käynnistetään asynkronisina taustatehtävinä.
Ominaisuuksien lisääntyessä myös taustatehtävien määrä voi kasvaa nopeasti. Pienetkin tuotemuutokset voivat synnyttää uusia tapahtumavirtoja ja riippuvuuksia. Rinnakkaisuuden hyvin jäsennelty arkkitehtuuri on tärkeä, jotta järjestelmä säilyy kehittyessään ymmärrettävänä ja luotettavana.
Tapahtumapohjainen lähestymistapa tukee myös yhtä tuotteen kannalta ratkaisevaa asiaa: itse keskustelun muovaamista. Reaaliaikainen äänijärjestelmä tekee muutakin kuin tuottaa vastauksia: se hallitsee rytmiä ja hiljaisuutta, käsittelee keskeytyksiä sekä päättää, miten ja milloin istunto lopetetaan. Nämä toimintatavat ovat osa tuotekokemusta, joten ne kannattaa suunnitella tietoisesti.
Kun istunnon tila muuttuu puheenvuorojen määrän, kuluneen ajan tai käyttäjän toiminnan perusteella, järjestelmä voi antaa vastaajalle kohdennettuja ohjeita. Se voi esimerkiksi kehottaa agenttia auttamaan käyttäjää lopettamaan keskustelun istunnon aikarajan lähestyessä tai pyytää selvennystä, jos vuorovaikutus pysähtyy. Nämä toimet ovat kevyitä, mutta tekevät kokemuksesta harkitun ja yhtenäisen.
Hyvin suunniteltu järjestelmä säilyttää selkeän kuvan istunnon tilasta: kuka puhuu, miten keskustelu etenee ja mitkä ehdot ovat täyttyneet. Tapahtumavirta päivittää tätä tilaa jatkuvasti, joten oikeat ohjeet voidaan antaa oikeaan aikaan.
Suojamekanismit ovat välttämättömiä käyttäjille suunnatussa tekoälyssä. Niillä hallitaan turvallisuutta, vaatimustenmukaisuutta, väärinkäyttöä ja luotettavuutta. Vuoropohjaisessa järjestelmässä ne voidaan suorittaa luontevissa tarkistuspisteissä: käyttäjän puheenvuoron jälkeen tai ennen vastauksen toimittamista.
Reaaliaikaisesta puheesta puuttuvat useimmat näistä selkeistä tarkistuspisteistä. Käyttäjän syötettä saapuu jatkuvasti. Äänivastauksen suoratoisto on ehkä jo käynnissä. Valmiit litteraatit tulevat usein äänen jäljessä. Jos järjestelmä odottaa viestien valmistumista ennen niiden tarkistamista, keskustelu ei enää tunnu reaaliaikaiselta.
Suojamekanismien onkin toimittava keskustelun rinnalla, jotta vuorovaikutus säilyy luonnollisena. Yksi ratkaisu on suoratoistaa ääni puskuriin ja arvioida litteraatin katkelmia asynkronisesti sitä mukaa kuin niitä valmistuu. Näin turvallisuustarkistukset voidaan tehdä lähes reaaliajassa estämättä vuorovaikutusta.
Kun suojamekanismi aktivoituu, järjestelmä voi reagoida tilanteen mukaisesti ohjaamalla keskustelun toisaalle, muuttamalla toimintaansa tai tarvittaessa päättämällä istunnon. Näin suojamekanismit toimivat reaaliajassa heikentämättä käyttökokemusta.
Reaaliaikaisen keskustelujärjestelmän arvioinnissa vaikeinta on se, ettei joitakin tärkeimmistä ominaisuuksista – ajoitusta, keskeytyksiä, keskustelun sujuvuutta ja äänensävyä – voida arvioida pelkän litteraatin perusteella.
Tavanomaisissa arviointiputkissa järjestelmälle annetaan realistisia tilanteita, sen tuotoksia tarkkaillaan ja ne pisteytetään. Tekstipohjaisissa tai ketjutetuissa äänijärjestelmissä tämä on yksinkertaista: lähetä tekstiä ja tarkista palautuva teksti. Reaaliaikaisessa järjestelmässä syöte on suoraa ääntä, ja tärkein keskusteludynamiikka liittyy aikaan: miten agentti käsittelee päällekkäistä puhetta, kuinka nopeasti se vastaa ja miten se jatkaa keskeytyksen jälkeen.
Manuaalisessa testauksessa eli puhumalla suoraan agentille nämä ominaisuudet saadaan esiin, mutta menetelmä ei skaalaudu. Litteraatteihin perustuva automaatio skaalautuu, mutta siitä puuttuu juuri se signaali, joka erottaa hyvän reaaliaikaisen kokemuksen huonosta.
Yksikään menetelmä ei yksin riitä. Käytännössä tarvitaan useita kerroksia:
Agenttien väliset arvioinnit: toinen reaaliaikainen agentti ohjeistetaan omaksumaan tietty käyttäjäpersoona, minkä jälkeen se keskustelee testattavan järjestelmän kanssa. Kolmas, tuomarina toimiva suuri kielimalli pisteyttää vuorovaikutuksen. Näin voidaan testata laajassa mittakaavassa koko äänipolku ajoituksineen ja keskeytysten käsittelyineen.
Ei-toiminnalliset mittarit: ensimmäisen äänen viive ja litteraatin tunneanalyysi toimivat keskustelun laadun määrällisinä likiarvoina.
Manuaalinen laadullinen arviointi: se on yhä välttämätöntä automaattisilta mittareilta huomaamatta jäävien ongelmien löytämiseksi, etenkin äänensävyn ja luonnollisuuden osalta.
Yksikään menetelmä ei kata kaikkea. Reaaliaikaisten agenttien tuotantokäyttö edellyttää kaikkien kolmen menetelmän yhdistämistä. Siitä huolimatta reaaliaikaisen äänen arviointityökalut ovat yhä kehittymättömiä tekstipohjaisen tekoälyn työkaluihin verrattuna.
Reaaliaikainen puhe muuttaa tuotteen luonnetta. Ajoitus, keskeytykset, hiljaisuus ja keskustelun jatkuminen vaikuttavat käyttäjäkokemukseen yhtä paljon kuin sanat.
Malli on siis vain yksi osa järjestelmää. Reaaliaikainen puhe tuotannossa edellyttää puheelle suunniteltua istuntokerrosta, puhumisen ja päättelyn selkeää erottamista sekä aktiivista istuntoa ympäröivää tapahtumaohjausta. Suojamekanismit ovat edelleen viiveen pullonkaula, mutta luovilla ratkaisuilla suuri osa reaaliaikaisesta kokemuksesta voidaan säilyttää.
Kokonaisuuden heikoin osa on yhä arviointi. Vakiintunutta tapaa testata hyvän reaaliaikaisen puhekokemuksen ominaisuuksia – ajoitusta, äänensävyä, keskeytysten käsittelyä ja keskustelun sujuvuutta – ei vielä ole. Siihen asti teknologiaa hyödyntävien tiimien on yhdistettävä automaattisia testejä, agenttien välisiä testiajoja ja manuaalista arviointia.