Poza łączem SIP: redukcja opóźnień agenta głosowego poniżej 300 ms

Zespół IdentityCall AI | Inżynieria | 8 min czytania

Nowy standard opóźnień

W 2024 roku “test Turinga” dla agentów głosowych nie polega już tylko na inteligencji — chodzi o szybkość. Wcześniejszy standard opóźnień rzędu od 800 ms do 1 s (typowy dla łańcuchów LLM w chmurze) nie jest już akceptowalny w newralgicznych interakcjach z klientami. Użytkownicy postrzegają opóźnienia >500 ms jako “robotyczne” lub “zepsute”, co prowadzi do wchodzenia sobie w słowo i frustracji.

Nowym złotym standardem jest naprzemienność wypowiedzi poniżej 300 ms. Ten artykuł analizuje zmiany architektoniczne niezbędne, by ją osiągnąć.

Wąskie gardło: tradycyjne łańcuchy w chmurze

Tradycyjny stos głosowej AI wygląda tak:

VAD (wykrywanie aktywności głosowej) czeka na ciszę (200-500 ms).
Przesłanie audio do chmury (100 ms).
ASR (transkrypcja) przetwarza całą wypowiedź (200-400 ms).
Inferencja LLM generuje strumień tokenów (200-800 ms).
TTS (synteza) generuje audio z tekstu (200-400 ms).
Pobranie audio i odtwarzanie (100 ms).

Całkowite opóźnienie: 1.5 s - 2.5 s. Właśnie dlatego Twój bot głosowy pierwszej generacji wydawał się powolny.

Rozwiązanie: architektury strumieniowe i edge

1. Wykonanie spekulatywne i strumieniowe ASR

Nie czekaj na ciszę. Nowoczesne architektury wykorzystują strumieniowe ASR, które wysyła częściowe transkrypcje do LLM, gdy użytkownik wciąż mówi.

Technika: LLM zaczyna przewidywać odpowiedź na podstawie pierwszych 80% zdania.
Bezpieczeństwo: “brama zaangażowania” gwarantuje, że bot nie odezwie się, dopóki intencja nie jest jasna, ale tokeny są wstępnie wygenerowane.

2. Edge AI i lokalne VAD

Przeniesienie wykrywania aktywności głosowej (VAD) na edge (lub do zlokalizowanego węzła dostawcy telefonii) oszczędza krytyczny czas przesyłu w obie strony.

Wpływ: Redukuje 100-200 ms jittera sieciowego.
Implementacja: Wykorzystanie modułów VAD w WebAssembly (Wasm) działających bezpośrednio w przeglądarce lub na brzegu telefonii (edge).

3. Optymalizacja TTFT (czas do pierwszego tokenu)

W przypadku samego LLM optymalizujemy czas do pierwszego tokenu.

Kwantyzacja: Użycie modeli skwantyzowanych do 4 bitów (np. Llama-3-8B-Int4) drastycznie zwiększa szybkość inferencji przy znikomej utracie dokładności w zadaniach konwersacyjnych.
Pamięć podręczna: Buforowanie semantyczne przechowuje odpowiedzi na typowe powitania (“Dzień dobry”, “Kto mówi?”), aby serwować je natychmiast (0 ms inferencji).

Diagram architektury (Mermaid)

sequenceDiagram
    participant User
    participant Edge_VAD
    participant Cloud_LLM
    participant TTS_Engine
    
    User->>Edge_VAD: Speaks "I need to reset..."
    Edge_VAD->>Cloud_LLM: Stream: "I need to reset..."
    Cloud_LLM->>Cloud_LLM: Pre-fetch "Reset Password flow"
    User->>Edge_VAD: "...my password"
    Edge_VAD->>Cloud_LLM: Stream: "...my password" [EOS]
    Cloud_LLM->>TTS_Engine: Stream Tokens (Immediate)
    TTS_Engine->>User: Audio Stream (Sub-300ms)

Podsumowanie

Opóźnienie poniżej 300 ms zamienia “bota głosowego” w “agenta głosowego”. Odchodząc od sztywnych cykli żądanie-odpowiedź na rzecz płynnych, strumieniowych architektur, tworzymy doświadczenia, które sprawiają wyjątkowo ludzkie wrażenie.

Gotów budować szybsze agenty? Poznaj naszą dokumentację API z endpointami strumieniowymi.