Hur optimerar du latensen för Conversational AI?

För de flesta applikationer är latens ett milt problem. Men för konversations-AI är latens det som skiljer bra applikationer från fantastiska.

Till att börja med är målet med konversations-AI ganska ambitiöst – att ge samma känsla, beröring och röst som ett mänskligt samtal, samtidigt som det överträffar en människas intelligens. För att åstadkomma detta måste en applikation konversera utan långa tysta luckor. Annars är realismen krossad.

Konversations-AI:s latensutmaning förvärras av den bitvisa karaktären hos den. Conversational AI är en serie mellanliggande processer, alla anses vara toppmoderna inom sina respektive områden. Var och en av dessa processer medför additiv latens.

Som generativt röstföretag har vi ägnat lång tid åt att studera hur man minimerar latens för konversations-AI. Idag vill vi dela med oss ​​av våra lärdomar, av hopp om att de ska vara till hjälp för alla som är intresserade av att bygga konversationsbaserade AI-applikationer.

De fyra kärnkomponenterna

Varje konversations-AI-applikation involverar minst fyra steg: tal-till-text, turtagning, textbearbetning (dvs. LLM) och text-till-tal. Även om dessa steg exekveras parallellt, bidrar varje steg fortfarande med viss latens.

Noterbart är att konversations-AI:s latensekvation är unik. Många processlatensproblem kan reduceras till en enda flaskhals. Till exempel, när en webbplats gör en databasförfrågan, driver webbens nätverkslatens den totala latensen, med bara triviala bidrag från backendens VPC-latens. Konversations-AI:s latenskomponenter varierar dock inte drastiskt. De är ojämna, men varje komponents latensbidrag ligger inom en viss grad av de andra. Följaktligen drivs latens av summan av delar.

Automatisk taligenkänning

Systemets "öra"

Automatisk taligenkänning (ASR) – ibland kallad speech-to-text (STT) – är processen att konvertera talat ljud till skriven text.

ASR:s latens är inte den tid det tar att generera text. Tal-till-text-processen körs i bakgrunden när användaren talar. Istället är latensen tiden mellan slutet av talet och slutet av textgenereringen.

Följaktligen kan korta och långa talintervall ådra sig liknande ASR-latens. Och eftersom tal-till-text-modeller är ganska optimerade är latensen vanligtvis under 100 ms, inklusive nätverket tur och retur. (I vissa fall finns det ingen nätverkslatens alls eftersom modellen är inbäddad i webbläsaren, som Chrome/Chromium).

Svängning/avbrott

Systemets "instinkt"

Turn-taking / Interruption (TTI) är en mellanhand som bearbetas som avgör när en användare är färdig med att tala. Den underliggande modellen är känd som en Voice Activity Detector (eller VAD).

Turn-Taking involverar en komplex uppsättning regler. En kort talskur (t.ex. "uh-huh") bör inte utlösa en sväng; annars skulle konversationer kännas för stackato. Istället måste den bedöma när en användare faktiskt försöker få modellens uppmärksamhet. Det måste också avgöra när användaren är klar med att vidarebefordra sina tankar.

En bra VAD-vilja inte signalera en ny sväng när den upptäcker tystnad. Det är tyst mellan ord (och fraser), och modellen måste vara säker på att användaren faktiskt är färdig med att tala. För att åstadkomma detta på ett tillförlitligt sätt måste den söka en tröskel för tystnad (eller mer specifikt, brist på tal). Denna process tvingar fram en fördröjning som motsvarar latens för användaren.

Tekniskt sett, om alla andra konversations-AI-komponenter uppstod noll latens, den latens som tillskrivs TTI skulle vara bra. Människor tar ett slag innan de svarar på tal. En maskin som tar en liknande paus ger realism åt interaktionen. Men eftersom andra komponenter i konversations-AI redan har latens, är minimal TTI-latens idealisk.

Textbearbetning

Systemets hjärna

Därefter måste systemet generera ett svar. Idag uppnås detta vanligtvis med en Large Language Model (LLM), som GPT-4 eller Gemini Flash 1.5.

Valet av språkmodell gör stor skillnad. Modeller som Gemini Flash 1.5 är otroligt snabba – genererar utgångar på mindre än 350 ms. Mer robusta modeller som kan hantera mer komplexa frågor – som GPT-4-varianter och Claude – kan ta mellan 700 ms till 1 000 ms. Att välja rätt modell är vanligtvis det enklaste sättet att rikta in sig på latens när man optimerar en konversations-AI-process.

Men fördröjningen av LLM är tid det tar start genererar tokens. Dessa tokens kan direkt strömmas till följande text-till-tal-process. Eftersom text-till-tal bromsas av den naturliga takten hos en mänsklig röst, kan LLM på ett tillförlitligt sätt överträffa den – allt som spelar roll är den första token-latensen (dvs. tid till första byte).

Det finns andra bidragsgivare till en LLM:s latens utöver modellens val. Dessa inkluderar promptlängden och storleken på kunskapsbasen. Ju större av båda desto längre fördröjning. Det kokar ner till en enkel princip: ju mer som LLM behöver tänka på, desto längre tid tar det. Följaktligen måste företag hitta en balans mellan en sund mängd sammanhang utan att överbelasta modellen.

Text to Speech

Systemets mun

Den sista komponenten i konversations-AI är text-till-tal (TTS). Text-till-tals nettofördröjning är den tid det tar att börja tala efter att ha mottagit inmatningstokens från textbearbetning. Det är allt – eftersom ytterligare tokens görs tillgängliga med en hastighet som är snabbare än mänskligt tal, är text-till-tals latens ** strikt tiden till första byte.

Tidigare var text-till-tal särskilt långsam, det tog så lång tid som 2-3 sekunder att generera tal. Men toppmoderna modeller som vår Turbo-motor kan generera tal med bara 300 ms latens. Faktum är att vår V2/V2.5 Flash TTS-motor kan uppnå 200 ms tid till första byte ljudlatens, det bästa resultatet i fältet (vi måste skryta lite!).

Ytterligare bidragsgivare

Utöver de fyra komponenterna finns det några ytterligare bidragsgivare till konversations-AI:s nettofördröjning.

Nätverkslatens

Det kommer alltid att finnas latens förknippad med att skicka data från en plats till en annan. För vissa konversations-AI-tillämpningar bör ASR-, TTI-, LLM- och TTS-processerna helst vara samlokaliserade, så den enda källan till icke-trivial nätverkslatens är vägarna mellan högtalaren och hela systemet.

Funktionsanrop

Det finns många konversations-AI-applikationer för att anropa funktioner (dvs. gränssnitt med verktyg och tjänster). Till exempel kan jag muntligen be AI:n att kontrollera vädret. Detta kräver ytterligare API-anrop som anropas i textbearbetningsskiktet, vilket kan medföra betydligt mer latens beroende på behoven.

Till exempel, om jag behöver beställa en pizza muntligt, kan det finnas flera API-anrop som är nödvändiga, några med överdriven fördröjning (t.ex. bearbetning av ett kreditkort).

Ett konversations-AI-system kan dock bekämpa förseningarna i samband med funktionsanrop genom att uppmana LLM att svara användaren innan funktionsanropet avslutas (t.ex. "Låt mig kolla vädret åt dig"). Detta modellerar ett verkligt samtal och håller inte användaren utan engagemang.

Dessa asynkroniserade mönster uppnås vanligtvis genom att utnyttja webhooks för att undvika långvariga förfrågningar.

Telefoni

En annan vanlig funktion för AI-plattformar för konversation är att tillåta användaren att ringa in via telefonen (eller, i vissa fall, ringa ett telefonsamtal för användarens räkning). Telefoni kommer att medföra ytterligare latens – och denna latens kan vara mycket geografiskt beroende.

Som bas kommer telefoni att medföra ytterligare 200 ms fördröjning om den finns i samma region. För globala samtal (t.ex. Asien → USA) kan restiden öka avsevärt, med latens på ~500ms. Det här mönstret kan vara vanligt om användare har telefonnummer utanför den region de befinner sig i – vilket tvingar ett hopp till baslandets telefonnätverk.

En avslutande tanke

Vi hoppas att den här rundtursutforskningen av konversations-AI var intressant. Sammanfattningsvis bör ansökningar inriktas på en fördröjning på undersekund. Detta kan vanligtvis uppnås genom att välja rätt LLM för uppgiften. De bör också ha kontakt med användaren när mer komplexa processer körs i bakgrunden för att förhindra långa pauser.

I slutändan är målet att skapa realism. En användare måste känna hur lätt det är att prata med en människa samtidigt som de får fördelarna med ett datorprogram. Genom att skärpa delprocesserna är detta nu möjligt.

På Elevenlabs optimerar vi varje del av delen av ett konversations-AI-system med våra toppmoderna STT- och TTS-modeller. Genom att arbeta med varje del av processen kan vi uppnå sömlösa samtalsflöden. Denna vy uppifrån och ned på orkestrering gör att vi kan raka bort lite latens – till och med 1 ms – vid varje tidpunkt.