Voicebot AI od środka: skąd bierze się opóźnienie odpowiedzi

Opóźnienie to cisza, którą słyszy dzwoniący, a poprzeczkę ustawiają ludzie

Najpierw granica pomiaru, bo większość sporów o opóźnienie voicebota to tak naprawdę spory o to, kiedy włączyć stoper. Liczy się czas od ostatniego dźwięku klienta do pierwszej słyszalnej próbki odpowiedzi. Inferencja modelu to tylko kawałek. Reszta to decyzja, że klient skończył, transkrypcja, sprawdzenie czegoś w systemie, synteza mowy i droga dźwięku przez sieć.

Ludzki punkt odniesienia jest dobrze zmierzony. Stivers i współautorzy w PNAS (2009) zmierzyli tury pytanie-odpowiedź w 10 językach: średnia przerwa to +208 ms, mediana +100 ms. Japończycy odpowiadali średnio po 7 ms, Duńczycy po 469 ms. Polskiego w badaniu nie było, ale wszędzie poprzeczka leży wyraźnie poniżej pół sekundy.

Od maszyn na razie wymaga się mniej. Poradnik ElevenLabs podaje, że naturalnie brzmiący agent celuje zwykle w P50 poniżej 800 ms i P95 poniżej 1,5 sekundy. Benchmarki Twilio z listopada 2025 dają 1115 ms jako cel i 1400 ms jako górną granicę dla całej przerwy. Dasha mówi wprost, że nie ma popartego źródłami uniwersalnego progu „dobrego” opóźnienia.

Rozsądna robocza zasada mieści się w tych liczbach: typowa tura poniżej sekundy, a wolny ogon, czyli tury, które klient zapamięta, poniżej dwóch sekund także wtedy, gdy bot coś sprawdza w systemie.

Jak działa voicebot AI? To łańcuch etapów, każdy z własnym budżetem

Klasyczny voicebot AI to łańcuch, czyli kaskada. Dźwięk wpada, coś decyduje, że tura się skończyła, speech-to-text robi transkrypcję, LLM odpowiada (czasem po wywołaniu narzędzi), text-to-speech zamienia odpowiedź w dźwięk, a sieć albo linia telefoniczna niesie go z powrotem. Streaming pozwala etapom zachodzić na siebie: LLM oddaje zdania do TTS w miarę ich powstawania, więc płacisz za czas do pierwszego tokenu i pierwszego dźwięku, a nie za całe generowanie.

Tabela zestawia trzy publiczne zestawy liczb. To nie są pomiary twojego systemu ani naszego. Ostatnia kolumna jest twoja.

Czytaj kolumny z góry na dół, nigdy w poprzek. Każde źródło inaczej rysuje granice etapów, więc wiersz Twilio plus wiersz ElevenLabs nie dają żadnej sensownej sumy. ElevenLabs nazywa swoje liczby orientacyjnymi, Twilio „punktem startowym, a nie najlepszym możliwym wynikiem”, a Cresta podaje zakresy, które widział jej zespół. Zwróć też uwagę, że dwa z trzech źródeł milczą o narzędziach, a to dokładnie tam prawdziwe boty wychodzą poza budżet.

Wykrycie końca wypowiedzi to najdroższy etap

Zanim cokolwiek ruszy, system musi uznać, że klient skończył. Najprostszy endpointing czeka na ciszę, a CTO Cresty pisze, że w realistycznych rozmowach próg 600 ms ciszy to absolutne minimum. Krótszy próg sprawia, że bot wchodzi w słowo, gdy ktoś zawiesza głos, żeby pomyśleć. Wystarczy, że ktoś dyktuje numer i zawiesza głos: „mój numer klienta to… chwileczkę…”.

Semantyczne wykrywanie końca tury czyta słowa i ich rytm zamiast czekać na ciszę. Cresta podaje, że w typowych przypadkach skraca to odpowiedź poniżej 300 ms bez przerywania klientowi. Deepgram Flux wbudowuje wykrywanie tury w sam model mowy. Jego dane (deklarowane przez dostawcę, październik 2025): sygnał końca tury w ciągu 1 s na p90 i 1,5 s na p95, odpowiedzi agenta szybsze o 200-600 ms i około 30% mniej fałszywych przerwań.

Flux ma też tryb „eager”, który odpala 150-250 ms wcześniej, kosztem 50-70% więcej wywołań LLM. W tym kompromisie zawiera się cały ten etap: szybkość kupujesz zgadywaniem, a każde wczesne zgadnięcie kosztuje tokeny i czasem odpowiedź do wyrzucenia. Samo p95 równe 1,5 s to mniej więcej wielkość całego budżetu tury z tabeli wyżej, dlatego strojenie tego etapu na nagraniach twoich klientów daje więcej niż jakiekolwiek ustawienie z quickstartu.

Push-to-talk usuwa ten etap tam, gdzie da się go użyć

Jeśli użytkownik sam mówi systemowi, kiedy skończył, nie ma czego wykrywać. Poradnik ElevenLabs zaleca ręczne zatwierdzanie tury właśnie wtedy, gdy aplikacja zna koniec wypowiedzi z innego sygnału, na przykład z puszczenia przycisku. Nie trzeba czekać na timer ciszy, kaszel czy rozmowa obok nie wywołają fałszywego przerwania, a transkrypcja rusza w chwili puszczenia przycisku.

To pasuje do użytkowników, którzy są operatorami, a nie dzwoniącymi: magazyn i serwis terenowy na słuchawkach, dyspozytorzy, technicy dyktujący odczyty, kierowcy, narzędzia wewnętrzne używane przez jedną osobę kilkadziesiąt razy dziennie. Hałas przestaje być problemem, bo przyciskowi jest obojętne, że za plecami jedzie wózek widłowy.

Nie pasuje do infolinii. Klient dzwoniący na twój numer nie przytrzyma klawisza i nie da się go o to poprosić. Tam płacisz za wykrywanie końca tury i je stroisz. Praktyczny wniosek: najpierw ustal, kim jest użytkownik, potem wybieraj architekturę. Dla pracowników push-to-talk to pełnoprawna decyzja projektowa, a nie kompromis.

Voicebot po polsku: wynik z benchmarku to nie twoje rozmowy

Najczęstsza skarga na voiceboty w Polsce nie dotyczy szybkości. W badaniu EY-Parthenon i PSMB (wrzesień 2026) 45% niezadowolonych klientów wskazało, że bot nie zrozumiał problemu, 28% że odpowiedzi były zbyt ogólne, 20% że rozmowa się zapętliła, a 19% że trudno było dotrzeć do konsultanta. Rozmowy z voicebotem dobrze ocenia 60% klientów, z człowiekiem 88%.

Część tego „nie zrozumiał” to rozpoznawanie mowy, i tu liczby z benchmarków potrafią zmylić. Praca Pietronia i współautorów (arXiv, luty 2026) zmierzyła WER na polskim Common Voice: ElevenLabs Scribe 3,29%, Whisper large 6,3%. Na ponad 9 godzinach prawdziwych konsultacji lekarskich, nagranych zwykłymi mikrofonami, z nakładającymi się głosami i szumem tła, ElevenLabs miał 12,06%, a Whisper 53,83%. Ten sam model, z 6% do 54% błędnych słów. To nie było audio telefoniczne, które jest jeszcze trudniejsze. Wcześniejszy Polish ASR Leaderboard z UAM (2024) pokazał to samo na 25 systemach: mediana WER 14,52 na mowie czytanej i 32,42 na konwersacyjnej.

Wniosek nie brzmi „wybierz model X”. Brzmi: zmierz WER na 50 własnych nagranych rozmowach, zanim wybierzesz dostawcę, i kluczowe dane (numer zamówienia, PESEL, adres e-mail) zawsze odczytuj klientowi do potwierdzenia.

Druga strona to synteza. Polski TTS potyka się na tekście, który nie jest zapisany słowami, więc normalizuj go przed wysłaniem do syntezy, zamiast liczyć, że model zgadnie odmianę. „15:30” zamień na „piętnasta trzydzieści” albo „o piętnastej trzydzieści”, zależnie od zdania. „2 zł” to „dwa złote”, „5 zł” to „pięć złotych”, a „1 234,50 zł” to „tysiąc dwieście trzydzieści cztery złote pięćdziesiąt groszy”. „12.11” to „dwunastego listopada”, „ul.” to „ulica”, a „nr” to „numer”. Numery telefonów czytaj w grupach, tak jak dyktują je ludzie.

Pozostałe skargi z badania EY to w dużej mierze decyzje inżynierskie. Odpowiedzi „zbyt ogólne” leczy pobieranie faktów z systemów przez narzędzia zamiast odpowiadania z pamięci modelu. Na pętle działa reguła dwóch prób: po drugim niezrozumieniu bot przełącza na człowieka. A fraza „chcę rozmawiać z konsultantem” powinna działać zawsze i od razu.

Wywołania narzędzi to miejsce, gdzie umiera budżet 2 sekund

Bot, który tylko rozmawia, jest szybki. Bot, który sprawdza zamówienie, termin w kalendarzu albo stan magazynu, płaci dużo więcej, i to z powodów strukturalnych. Cresta ujmuje to jako regułę: wywołanie narzędzia przed odpowiedzią zamienia jeden czas do pierwszego tokenu w jeden pełny przebieg LLM plus kolejny czas do pierwszego tokenu. Model musi najpierw dopisać wywołanie do końca, potem narzędzie się wykonuje, a potem model zaczyna od nowa z wynikiem.

Przykład z primera Voice AI & Voice Agents pokazuje skalę: przy 450 ms do pierwszego tokenu i 100 tokenach na sekundę wywołanie funkcji o długości 100 tokenów zajmuje 1450 ms, zanim funkcja w ogóle ruszy. Przenieś to na jedną realistyczną turę, a wyjdą słupki poniżej.

To około 3,1 sekundy przed doliczeniem wykrycia końca tury i sieci, za jedno sprawdzenie. Cztery sprawdzenia po kolei, każde w osobnym przebiegu modelu, powtarzają dwa pierwsze słupki cztery razy. Dźwignie dotyczą więc kształtu pętli bardziej niż szybkości modelu.

Zacznij od równoległych wywołań. Jeśli model zwraca kilka wywołań w jednej odpowiedzi, a środowisko wykonuje je współbieżnie, płacisz za jeden przebieg modelu plus najwolniejsze narzędzie. Sprawdź obie połowy, bo naiwna pętla czeka na nie po kolei, nawet gdy model poprosił o nie razem. To, co przewidywalne, pobieraj z wyprzedzeniem: Cresta radzi odpalać takie wywołania współbieżnie na starcie rozmowy, a klasyką jest wyszukanie klienta po numerze telefonu. No i ogranicz pętlę. LiveKit ocenia wpływ narzędzi i MCP na opóźnienie jako „potencjalnie wysoki” i wskazuje limit max_tool_steps.

Kiedy narzędzie pracuje, wypełniaj ciszę uczciwie. LiveKit sugeruje dźwięk „myślenia” w trakcie wykonywania narzędzia i uprzedzenie klienta przed wywołaniem. Krótkie „już sprawdzam” zmienia przerwę, którą klient czuje, ale nie tę, którą mierzysz, więc śledź obie. I pamiętaj, że p95 twojego CRM staje się częścią p95 twojego voicebota. Jak w ogóle wystawić te systemy jako narzędzia, opisaliśmy w tekście o podłączaniu AI do danych firmy.

Nieaktualny kontekst kosztuje czas i poprawność

W każdej turze model czyta rozmowę od nowa. Dłuższa historia to więcej tekstu przed pierwszym tokenem, a LiveKit zauważa, że zwięzłe instrukcje systemowe i przycinanie lub streszczanie starszych tur skraca czas do pierwszego tokenu. Mniej oczywisty koszt to poprawność. W bocie, który czyta dane na żywo, stary wynik narzędzia w historii wygląda dokładnie jak fakt.

Zderzyliśmy się z tym przy głosowym inżynierze wyścigowym dla iRacing. Kierowca mówi przez push-to-talk, Whisper transkrybuje, agent OpenAI z 19 narzędziami MCP czyta telemetrię na żywo, a TTS odpowiada w stylu radia F1, w niecałe 2 sekundy razem z wywołaniami narzędzi. Pytanie „czy zjeżdżać na tym okrążeniu?” uruchamia cztery narzędzia w jednej pętli rozumowania: status obsługi w alei serwisowej, średni czas okrążenia, tabelę wyników i raport uszkodzeń. Trzymanie całego łańcucha wywołań w historii zatruwało następne pytanie, bo agent rozumował na czasie okrążenia sprzed 30 sekund, który był już błędny.

Rozwiązaniem było okno przesuwne. Utrwalane są tylko pytanie kierowcy i finalna odpowiedź agenta (MAX_HISTORY = 4), prompt systemowy jest przypięty na początku, a każde pośrednie wywołanie narzędzia uruchamia się na świeżo w każdej turze i jest potem odrzucane. Historia okrążeń wszystkich 64 aut leży w SQLite, zapisywana przez proces odpytujący grę co 100 ms, poza kontekstem modelu. Model ma mniej do czytania i nic starego, czemu mógłby uwierzyć.

Uczciwie o tym, czego ta liczba nie obejmuje: push-to-talk, więc bez wykrywania końca tury, bez linii telefonicznej, jeden wyszkolony użytkownik, zero równoległych rozmów. To dowód dla części budżetu związanej z narzędziami i kontekstem, a nie wynik klasy infolinii. Sam wzorzec przenosi się wprost: status zamówienia, stan magazynu i saldo też zmieniają się w trakcie rozmowy, więc trzymaj rozmowę, a fakty pobieraj na nowo.

Speech-to-speech czy kaskada: co oddajesz za niższą liczbę

Model speech-to-speech słyszy dźwięk i odpowiada dźwiękiem, pomijając transkrypcję i syntezę. Mniej przeskoków brzmi jak mniejsze opóźnienie i przy luźnej rozmowie często tak jest. LiveKit ocenia jednak wybór między kaskadą a modelem realtime jako „żaden do średniego” wpływ na opóźnienie, a położenie agenta względem modeli jako „bardzo wysoki”.

Oddajesz kontrolę. Porównanie Deepgrama (warto pamiętać, że Deepgram sprzedaje komponenty kaskady) wylicza: kaskada daje tekst na każdym etapie, więc masz ślad audytowy i możesz wymienić jeden komponent bez ruszania reszty, a speech-to-speech potrzebuje równoległej transkrypcji, która może rozjechać się z tym, co faktycznie padło. Deepgram pyta też, czy narzędzia działają równie stabilnie przy audio na wejściu i wyjściu, i zauważa, że realne koszty potrafią sięgać 4x teoretycznego minimum.

Większa liczba dotyczy skuteczności. Benchmark τ-Voice (marzec 2026) objął 278 zadań obsługi klienta: agent tekstowy z rozumowaniem rozwiązał 85%, agenci głosowi 31-51% na czystym audio i 26-38% przy realistycznym szumie i akcentach. Aktualizacja Sierry z maja 2026 pokazuje, że najlepszy wynik głosowy urósł z 30% do 67%, czyli około 79% możliwości wersji tekstowej. Luka szybko się zamyka, ale wciąż jest.

Urwanie 300 ms z tury niewiele znaczy, jeśli zadanie kończy się sukcesem dwa razy na trzy. Przy botach, które działają na systemach firmy, bezpieczniejszym punktem wyjścia jest kaskada ze streamingiem na każdym styku, a speech-to-speech pasuje tam, gdzie chodzi bardziej o rozmowę niż o transakcje.

Ile kosztuje minuta rozmowy w listopadzie 2026

Najpierw ceny ze stron oficjalnych, w dolarach, bo w takiej walucie rozlicza się API. Wszystkie pobrane 13 listopada 2026, zmieniają się często.

OpenAI wycenia audio realtime za tokeny i nie podaje, ile tokenów ma minuta, więc nie ma tu kwoty za minutę speech-to-speech. Kto ją podaje, sam przeliczył coś, czego OpenAI nie publikuje.

Polskie gotowe voiceboty sprzedaje się abonamentowo. Zestawienie ainora.lt (aktualizacja 29 października 2026, przygotowane przez konkurencyjnego dostawcę, ceny z cenników 17 firm) pokazuje plany od 159 do 8500 zł miesięcznie, minuty ponad pakiet za 0,39-1,09 zł netto i wdrożenie od 0 do 20 000 zł. To ceny deklarowane przez dostawców, nie audyt. Opóźnienie ma tu swoją cenę: szybszy głos ElevenLabs Flash kosztuje w Retell $0,04 za minutę zamiast $0,015, a tryb „eager” we Fluxie płaci za swoje 150-250 ms o 50-70% większą liczbą wywołań LLM. Czy te minuty się zwracają, to osobny rachunek, rozpisany w tekście o ROI AI w obsłudze klienta.

Mierz latencję voicebota dla całej tury na p95, nie sam model na p50

ElevenLabs podaje dla modelu Flash v2.5 około 75 ms inferencji przy krótkich tekstach i uczciwie zaznacza, że to sama inferencja. Humanness Index Vapi pokazuje ten sam model z 197 ms do pierwszego dźwięku w swoim rankingu, gdzie metoda to mediana prób na żywo z doliczonym czasem sieci. Żadna liczba nie jest fałszywa. Mierzą inne granice i tylko jedną z nich słyszy klient.

Mierz więc od strony dzwoniącego. Metoda Cresty to dobry punkt wyjścia: puść symulowane połączenie przez prawdziwą ścieżkę telefoniczną albo WebRTC, nagraj je po stronie klienta i użyj ASR ze znacznikami czasu słów, żeby policzyć przerwę między ostatnim słowem klienta a pierwszym słowem bota. Potem patrz na percentyle, nie na średnią. Średnia 900 ms potrafi ukryć co dziesiątą turę trwającą trzy sekundy, a to właśnie te tury klient opisuje jako „zawiesił się”.

Rozdziel też liczby według typu tury: zwykła odpowiedź, tura z wywołaniem narzędzia i tura, w której klient przerwał botowi, mają różne budżety. Wymieszane wyglądają dobrze wszystkie naraz.

Działanie głosem wymaga bramki: potwierdzenie, AI Act, RODO

Odczyt danych głosem to niskie ryzyko. Rezerwacja, anulowanie czy zwrot już nie, a głos dokłada błędy, których tekst nie zna: przesłyszenie i przerwanie w trakcie akcji. Analiza AAIF z października 2026 zauważa, że w LiveKit kod narzędzia domyślnie działa dalej po przerwaniu agenta, a Pipecat domyślnie anuluje trwające wywołania. Dwa zdania stamtąd warto powiesić nad biurkiem: timeout nie jest dowodem, że nic się nie stało, a ponowienie bez sprawdzenia potrafi utworzyć dwie rezerwacje.

Wzorzec jest prosty: czytaj samodzielnie, działaj po potwierdzeniu. Bot odczytuje akcję („Anuluję piątkową wizytę o 15:00, potwierdzasz?”), czeka na wyraźne „tak”, wysyła zapis z kluczem idempotencji i mówi „gotowe” dopiero, gdy system to potwierdzi. Kosztuje to jedną turę więcej, czyli mało w porównaniu z podwójną rezerwacją.

Druga bramka jest prawna i zaczyna się od AI Act, który w praktyce oznacza linijkę kodu, a nie zapis w regulaminie. Art. 50 ust. 1 nakłada na dostawcę obowiązek zaprojektowania systemu tak, żeby ludzie wiedzieli, że rozmawiają z AI, chyba że jest to oczywiste, a ust. 5 każe to zrobić najpóźniej przy pierwszej interakcji. Obowiązki stosuje się od 2 sierpnia 2026, co potwierdza komunikat Komisji o wytycznych. Firma, która buduje własnego voicebota, jest jego dostawcą, więc zdanie „rozmawiasz z asystentem AI” należy do pierwszej wypowiedzi TTS, zapisanej w kodzie. Ludzko brzmiący głos w telefonie to przeciwieństwo „oczywistego”. Kosztuje to kilka sekund na starcie rozmowy i tych akurat nie warto oszczędzać. Szerszy kalendarz jest w naszym przewodniku po AI Act.

Przy RODO najprościej traktować bota jako trzy warstwy przetwarzania. Nagranie audio, transkrypcja i to, co trafia do kontekstu LLM, to w praktyce trzy różne zbiory danych, każdy z własnym celem i okresem przechowywania. Poradnik Przedsiębiorcy (październik 2026) zwraca uwagę, że nagranie i transkrypcja nie muszą być przechowywane tak samo długo, że transkrypcja może trafić dalej do CRM, narzędzia analitycznego albo modelu językowego, i że „rozmowa jest nagrywana” oraz „rozmowę prowadzi sztuczna inteligencja” to dwa różne komunikaty. Zaleca też informację warstwową: krótki komunikat głosowy na początku, pełna klauzula z art. 13 RODO dostępna dalej. Sprawdź przy okazji, gdzie fizycznie lecą audio i tekst, bo API do STT, LLM i TTS bywają poza EOG.

Połączenia wychodzące to osobna sprawa. Art. 398 Prawa komunikacji elektronicznej zakazuje używania automatycznych systemów wywołujących oraz telekomunikacyjnych urządzeń końcowych do marketingu bezpośredniego bez uprzedniej zgody abonenta lub użytkownika końcowego. Można się spierać, czy voicebot z LLM to „automatyczny system wywołujący”, ale przepis obejmuje też urządzenia końcowe, więc zgoda i tak jest potrzebna. Bezpieczny zakres to obsługa połączeń przychodzących.

Checklista przed startem, którą zrobisz sam

Nic z tego nie wymaga dostawcy. Wystarczy jeden inżynier i tydzień nagrań.

Jeśli w tym tygodniu zrobisz jedną rzecz, niech to będzie ostatni wiersz. Pięćdziesiąt nagranych rozmów przez prawdziwą linię powie ci o opóźnieniu i zrozumieniu więcej niż jakakolwiek tabela dostawcy, łącznie z tą.

Stronę z narzędziami, łącznie z bramką potwierdzenia przed akcją, opisaliśmy w case study inżyniera wyścigowego. A jeśli przyda ci się druga para oczu nad budżetem, od tego jest bezpłatny audyt.

FAQ