Optymalizacja opóźnień agenta głosowego: przewodnik krok po kroku

Responsywność agenta głosowego zależy od całkowitego opóźnienia między zakończeniem wypowiedzi użytkownika a rozpoczęciem odpowiedzi przez agenta. Rzadko powoduje je jeden wolny komponent. Narasta na kilku niezależnych etapach, z których każdy dodaje od kilkudziesięciu do kilkuset milisekund. Aby je zmniejszyć, trzeba wiedzieć, ile czasu zajmuje każdy etap.

Optymalizacja opóźnień agenta głosowego polega na znalezieniu miejsc, w których ukrywa się ten czas, i odzyskiwaniu go etap po etapie.

Ten artykuł uzupełnia omówienie koncepcji opóźnień. Tamta strona wyjaśnia, czym jest opóźnienie, a ta opisuje architekturę i pomiary. Dzięki temu poznasz budżet opóźnień, który możesz mierzyć, oraz konkretne działania do podjęcia.

Podsumowanie

• Time-to-first-audio obejmuje cały pipeline, a nie tylko czas inferencji jednego modelu.
• Czas LLM do pierwszego tokenu i endpointing to dwa największe źródła opóźnień.
• Nakładanie się etapów zamiast wykonywania ich po kolei odzyskuje większość budżetu.
• Streaming, wybór kodeka i dostrojenie bufora odtwarzacza pozwalają zyskać mierzalne milisekundy.
• Mierz wyniki w każdym regionie dla własnego wdrożenia i raportuj P50 oraz P95.

Określanie budżetu opóźnień agenta głosowego

Budżet opóźnień to docelowy całkowity czas do pierwszego audio, ustalony dla etapów pipeline'u. Każdy etap dostaje limit, a ich suma musi mieścić się w celu. Jego określenie to pierwszy krok, ale też miejsce, w którym najczęściej pojawiają się błędy, bo deweloperzy mogą mylić dwie podobne, lecz różne wartości.

Pierwsza to opóźnienie inferencji modelu: czas, który model poświęca na generowanie wyniku. W przypadku naszych modeli Flash wynosi ono około 75 ms dla typowych krótkich danych wejściowych, bez narzutu sieci i aplikacji. To wewnętrzny wskaźnik przydatny do porównywania modeli. Nie jest to jednak wartość, której doświadcza użytkownik.

Z perspektywy użytkownika liczy się time-to-first-audio (TTFA): czas od momentu, gdy użytkownik przestaje mówić, do usłyszenia pierwszej próbki odpowiedzi agenta. TTFA jest zawsze większe niż opóźnienie inferencji pojedynczego modelu, ponieważ obejmuje cały pipeline.

Kaskadowy agent głosowy to łańcuch pięciu etapów:

• przechwytywanie (mikrofon) -> STT -> LLM -> TTS -> odtwarzanie

Audio jest przechwytywane z mikrofonu, transkrybowane na tekst, wysyłane do modelu językowego, a tekst modelu jest syntezowany z powrotem na mowę, która następnie jest buforowana i odtwarzana. Każdy etap dodaje opóźnienie, a na kilku z nich największy koszt nie jest tym, którego można się spodziewać.

Oto przykład dla agenta anglojęzycznego, którego serwery są względnie blisko użytkownika. Wartości są orientacyjnymi zakresami, a nie gwarancjami.

Zwykle dwa największe źródła opóźnień to czas LLM do pierwszego tokenu i opóźnienie endpointingu na początku łańcucha. 

Tabela ułatwia wizualizację pipeline'u, ale sugeruje, że etapy działają ściśle po kolei, choć tak nie jest. Kilka najważniejszych optymalizacji opóźnień agenta głosowego wynika z ich nakładania, co pozwala odzyskać większość poniższego budżetu.

Speech to Text: optymalizacja opóźnień transkrypcji i endpointingu

Transkrypcja jest drugim etapem pipeline'u, ale jej rzeczywistym kosztem nie jest sama transkrypcja, lecz ustalenie, kiedy użytkownik przestał mówić. Ta sekcja omawia oba aspekty, aby pomóc ci zoptymalizować opóźnienia agenta głosowego.

Transkrypcja odbywa się, zanim trafi do LLM. Scribe v2 Realtime (scribe_v2_realtime) zwraca częściowe transkrypcje w około 150 ms i odbiera strumieniowo fragmenty audio, więc transkrypt powstaje, gdy użytkownik nadal mówi. Obsługuje PCM od 8 kHz do 48 kHz oraz kodowanie mu-law, co ma znaczenie w opisanej niżej sekcji o kodekach. Częściowe wyniki po 150 ms są mało kosztowne.

Większym źródłem opóźnień jest endpointing: moment, w którym system uznaje, że użytkownik faktycznie zakończył swoją wypowiedź.

Voice Activity Detection (VAD) dzieli mowę na podstawie ciszy i to właśnie tam narasta czas. Jeśli czekasz na przykład 700 ms ciszy, zanim uznasz wypowiedź za zakończoną, dodajesz 700 ms do każdej tury, poza czasem samej transkrypcji. Tego opóźnienia nie widać w benchmarku dokładności transkrypcji, ale jest bardzo odczuwalne w prawdziwej rozmowie. Często jest to największe kontrolowalne opóźnienie w całym pipeline'ie, dlatego warto zacząć właśnie od niego.

Endpointing to kompromis między responsywnością a przerywaniem. Krótki próg ciszy pozwala agentowi szybko odpowiadać, lecz grozi przerwaniem użytkownikowi w środku zdania podczas naturalnej pauzy. Długi próg jest bezpieczny, ale spowalnia działanie. W praktyce trzy zmiany optymalizujące opóźnienia w zamianie mowy na tekst to:

1. Dostrój próg ciszy: Ustaw najmniejszą wartość progu ciszy, która nie ucina naturalnych pauz użytkowników, a następnie mierz współczynnik przerwań na produkcji zamiast zgadywać.
2. Dodaj fizyczne zdarzenie sterujące: Użyj ręcznego zatwierdzania, gdy aplikacja wie z innego sygnału, że tura się skończyła (zwolnienie przycisku push-to-talk, zdarzenie UI), zamiast czekać na timer VAD.
3. Nakładaj procesy z LLM: Wysyłaj częściowe wyniki dalej jak najwcześniej. Przekazuj stabilne części do LLM i koryguj je, jeśli końcowy transkrypt się różni. To forma wykonania spekulacyjnego, która ukrywa opóźnienie endpointingu za przetwarzaniem promptu przez LLM.

Więcej informacji o Scribe v2 Realtime znajdziesz na stronie możliwości zamiany mowy na tekst oraz stronie produktu zamiana mowy na tekst w czasie rzeczywistym.

Wpływ LLM na opóźnienia

Model językowy jest zwykle największym pojedynczym źródłem TTFA, dlatego nakładanie etapów daje tu największe korzyści w optymalizacji opóźnień agenta głosowego. Kluczowe jest to, że agent nie potrzebuje całej odpowiedzi, zanim zacznie mówić.

Najwięcej budżetu opóźnień odzyskasz, strumieniując tokeny z LLM do TTS od razu po ich otrzymaniu, w fragmentach podzielonych na granicach zdań lub fraz. Buforuj tokeny do granicy zdania, a następnie syntezuj to zdanie, gdy kolejne jest jeszcze generowane:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

W długich rozmowach wybierz TTS WebSocket, aby otwarte połączenie mogło przyjmować tekst stopniowo bez ponownego kosztu ustanawiania połączenia dla każdego zdania. Do limitu współbieżności liczy się tylko czas aktywnego generowania audio przez model, więc bezczynny otwarty WebSocket jest prawie bezkosztowy.

Text to Speech: streaming i wybór głosu

Text to Speech to etap, na którym możesz najdokładniej kontrolować opóźnienie. Masz tu dwie główne dźwignie: sposób strumieniowania audio oraz wybór głosu.

Flash v2.5 (eleven_flash_v2_5) to model do użycia w agencie. Dla krótkich danych wejściowych zapewnia inferencję modelu w około 75 ms, obsługuje 32 języki i przyjmuje do 40 000 znaków na żądanie.

Wartość 75 ms dotyczy wyłącznie inferencji. TTFA TTS w powyższym budżecie jest wyższe, ponieważ obejmuje też podróż sieciową w obie strony i planowanie na serwerze.

Największą dźwignią jest tutaj streaming. Jeśli poprosisz o całe audio i będziesz na nie czekać, użytkownik usłyszy cokolwiek dopiero po syntezie całego klipu. Przy streamingu użytkownik słyszy pierwszy fragment od razu po jego wygenerowaniu, a reszta dociera, gdy już słucha. Streaming nie przyspiesza modelu — po prostu przekazuje wynik użytkownikowi, gdy model nadal generuje.

Przewodnik jak korzystać ze streamingu opisuje streaming HTTP, a przewodnik po WebSocket w czasie rzeczywistym opisuje ścieżkę WebSocket, której potrzebujesz do przekazywania tokenów z LLM.

Zainicjalizuj klienta raz i używaj go ponownie przy każdym wywołaniu poniżej:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Następnie skonfiguruj strumień i przekazuj go dalej, gdy dociera:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

Drugą dźwignią jest wybór głosu, który również wpływa na opóźnienia. Domyślne głosy, głosy syntetyczne i Instant Voice Clones (IVC) syntezują szybciej niż Professional Voice Clones (PVC), ponieważ PVC mają dodatkową złożoność modelu, która zwiększa narzut na każde generowanie. Dla agenta z rygorystycznymi wymaganiami dotyczącymi opóźnień najniższe opóźnienie zapewnia Flash z IVC lub domyślnym głosem.

Wybór rozmiaru fragmentów streamingu

Gdy tokeny płyną do TTS, a audio wraca, kolejną decyzją jest rozmiar fragmentów i ilość danych buforowanych przez odtwarzacz przed startem.

Mniejsze fragmenty szybciej docierają do odtwarzacza, zmniejszając opóźnienie do pierwszego bajtu, kosztem większej liczby wiadomości i nieco większego narzutu na fragment. Większe fragmenty są wydajniejsze w przesyle, ale użytkownik dłużej czeka na pierwszy. W interaktywnych agentach warto stosować mniejsze fragmenty na początku wypowiedzi, bo użytkownik czeka właśnie na pierwszy; późniejsze docierają, gdy audio jest już odtwarzane, więc ich rozmiar ma mniejsze znaczenie.

Odtwarzacz odpowiada za istotną część pozostałego opóźnienia. Większość odtwarzaczy audio nie zaczyna odtwarzania przy pierwszym bajcie. Buforują niewielką ilość danych, aby uniknąć zacinania, gdy strumień na chwilę zwolni. Domyślny bufor 500 ms jest powszechny i bezpośrednio zwiększa odczuwalne opóźnienie. Jego zmniejszenie oznacza niewielki wzrost ryzyka zacięć w zamian za niższe TTFA, a właściwa wartość zależy od jittera sieci między serwerem a klientem:

• Przy stabilnym połączeniu (odtwarzanie po stronie serwera, klient w tej samej lokalizacji) bufor od 50 do 150 ms jest zwykle bezpieczny i wyraźnie skraca TTFA.
• Przy niestabilnym połączeniu mobilnym lub między regionami większy bufor zapobiega słyszalnym przerwom, które są gorsze niż powodowane przez niego opóźnienie.

Dokładna konfiguracja zależy od przypadku użycia i twoich priorytetów.

Wybór kodeka

Miejsce docelowe audio powinno określać kodek, o który prosisz. Zwracamy formaty takie jak mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 i ulaw_8000. Dopasowanie natywnego formatu transportu usuwa etap transkodowania, co pomaga optymalizować opóźnienia agenta głosowego.

W telefonii, na przykład z Twilio i podobnymi dostawcami, używaj ulaw_8000. Sieć telefoniczna działa end-to-end w 8 kHz mu-law, więc bezpośrednie żądanie tego formatu eliminuje etap transkodowania w pipeline'ie i odpowiada oczekiwaniom operatora. Synteza audio o wyższej jakości nie daje korzyści, ponieważ sieć telefoniczna od razu je przeskaluje; tylko zwiększysz opóźnienie, nie zyskując nic słyszalnego.

W WebRTC i odtwarzaniu w przeglądarce używaj PCM (pcm_24000 lub pcm_16000) albo MP3. PCM nie jest skompresowany, więc klient nie musi go dekodować, co eliminuje niewielkie opóźnienie na fragment i jest wygodne przy bezpośrednim zasilaniu pipeline'u Web Audio. MP3 zajmuje mniej miejsca w transmisji, co pomaga przy ograniczonych połączeniach, kosztem lekkiego dekodowania po stronie klienta.

Geografia i odległości sieciowe

Każda z powyższych optymalizacji zakłada, że bajty mają do przebycia krótką drogę. Geografia wyznacza dolną granicę budżetu opóźnień, więc warto ją sprawdzić, zanim dostroisz cokolwiek innego.

Obsługujemy żądania z klastrów w Ameryce Północnej, Europie i Azji Południowo-Wschodniej, a każde żądanie automatycznie kierujemy do najbliższego klastra. Podróż sieciowa w obie strony przez publiczny internet trwa zwykle od 20 do 200 ms, zależnie od bliskości geograficznej, i nie da się jej skrócić bez zmiany lokalizacji infrastruktury.

Agent, który wydaje się natychmiastowy w San Francisco, blisko klastra w Ameryce Północnej, może działać ociężale dla użytkownika w Azji Południowej, którego ruch dwukrotnie przekracza ocean w każdej turze.

Rozwiązaniem jest umieszczenie serwerów aplikacji blisko użytkowników, nie tylko blisko nas. Jeśli twoi użytkownicy są w Europie, uruchom backend agenta w Europie, aby odcinek między użytkownikiem a serwerem był krótki; nasze routowanie obsłuży wtedy odcinek między twoim serwerem a modelem z pobliskiego klastra.

Samodzielny pomiar opóźnień agenta głosowego

Wartości w powyższej tabeli budżetu opóźnień to orientacyjne zakresy do planowania. Wartości, na których opierasz wdrożenie, powinny pochodzić ze skryptu takiego jak ten, uruchomionego dla własnego wdrożenia.

Poniższe instrumentowanie mierzy TTFA dla etapu TTS w izolacji — czas od żądania do pierwszego fragmentu audio — w wielu próbach i raportuje percentyle. Uruchom je z tego samego regionu, w którym działają twoje serwery, a nie z komputera deweloperskiego. Zakłada użycie klienta elevenlabs z wcześniejszego przykładu:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

Kilka rzeczy, o których warto pamiętać:

• Raportuj P50 i P95: Skup się na nich, a nie na średniej. Średnia ukrywa ogon rozkładu, który sprawia, że agent wydaje się zawodny. P95 to doświadczenie jednej tury na dwadzieścia. 
• Testuj według lokalizacji: Uruchom ten sam skrypt w każdym obsługiwanym regionie i przechowuj wyniki osobno.
• Rozkładaj żądania dla dokładności: Rób odstępy między żądaniami (setTimeout powyżej). Jeśli wyślesz je wszystkie naraz, zmierzysz własne kolejkowanie zamiast usługi. Po przekroczeniu limitu współbieżności żądania są kolejkowane według priorytetu, co zwykle dodaje około 50 ms, a po przekroczeniu dostępnej pojemności otrzymasz HTTP 429.
• Mierz cały łańcuch opóźnień: Rozszerz ten sam wzorzec pomiaru na pozostałe etapy. Umieść finalizację STT, pierwszy token LLM i start odtwarzacza w tych samych nawiasach performance.now(), a wypełnisz pełną tabelę budżetu własnymi wartościami i zobaczysz, który etap zaatakować najpierw.

Dzięki tym wskazówkom samodzielnie zmierzysz opóźnienia agenta głosowego. Następnie będziesz mieć jasną listę priorytetów, którymi warto zająć się najpierw.

Co najbardziej zmniejsza opóźnienia agenta głosowego?

Jeśli chcesz skupić się na kilku szybkich działaniach, te zmiany mają największy wpływ.

Mniej więcej w kolejności wpływu możesz użyć poniższych metod, aby zmniejszyć opóźnienia agenta:

• Rozpoczynaj pracę LLM na stabilnych częściach STT, aby ukryć opóźnienie endpointingu.
• Strumieniuj tokeny LLM do TTS na granicach zdań, aby synteza pierwszego zdania nakładała się na generowanie drugiego.
• Strumieniuj audio TTS do odtwarzacza i zmniejsz jego bufor do najniższej wartości tolerowanej przez jitter sieci.
• Używaj Flash z domyślnym głosem lub IVC, aby uzyskać TTS o najniższym opóźnieniu, oraz dopasuj kodek do transportu (ulaw_8000 dla telefonii, PCM lub MP3 dla przeglądarki/WebRTC).
• Umieszczaj serwery blisko użytkowników i mierz wyniki dla każdego regionu, ponieważ odcinki sieciowe są rzeczywiste i nierówne.

Więcej szczegółowych technik znajdziesz w przewodniku dla deweloperów o optymalizacji opóźnień. Kompletny działający punkt startowy z przykładami znajdziesz w API quickstart i przewodniku po streamingu. 

Chcesz szybciej korzystać z dostrojonych kaskad agentów? ElevenAgents wdraża ten pipeline z gotowymi optymalizacjami nakładania etapów.

Twórz agentów głosowych o niskich opóźnieniach z ElevenAgents

Optymalizacja opóźnień agenta głosowego wymaga mierzenia każdego etapu, a następnie nakładania etapów, aby najwolniejsze działały w tle pracy, która już trwa. Możesz ręcznie tworzyć i dostrajać taką kaskadę przez kilka iteracji, korzystając z powyższych wzorców, lub zacząć od pipeline'u, który już ma optymalizacje opóźnień.

ElevenAgents realizuje pełną kaskadę — od strumieniowego STT, przez przekazywanie tokenów do LLM, po Flash TTS — z wbudowanymi technikami nakładania etapów. Zamiast zaczynać od zera, dostroisz progi do wydajności, która jest dla ciebie najważniejsza.

Zacznij korzystać z ElevenAgents, aby utworzyć agenta już dziś lub skontaktuj się z działem sprzedaży i dowiedz się więcej.

FAQ o optymalizacji opóźnień agenta głosowego