Asystenci głosowi w produkcji: decyzje architektoniczne, które mają znaczenie

Czas odpowiedzi to wymaganie

Demo zbudujesz w jedno popołudnie: rozpoznawanie mowy, model językowy, synteza mowy. Co innego sprawić, żeby prawdziwi dzwoniący zaakceptowali takiego asystenta. W produkcji asystent głosowy jest systemem czasu rzeczywistego, w którym transmisja, turn detection, modele, narzędzia zewnętrzne i prowadzenie rozmowy walczą o tę samą sekundę. Większość decyzji o tym, czy to zadziała, zapada wcześnie, w architekturze, a ich późniejsza zmiana jest kosztowna.

W rozmowie ludzie wymieniają się po około 200 milisekundach. Pół sekundy już widać, dłuższe pauzy szybko sprawiają wrażenie wahania albo zerwanego połączenia. Ile opóźnienia jest znośne, zależy od przypadku. Awatar rozrywkowy na targach może potrzebować więcej niż asystent przyjmujący rezerwację pod presją czasu. Istotne jest, by cel ustawić świadomie, dla każdego zastosowania, zanim powstanie architektura.

Dwie rzeczy czynią ten cel wiarygodnym. Trzeba mierzyć od początku do końca, od ostatniego słowa dzwoniącego do pierwszego dźwięku odpowiedzi, i to po stronie dzwoniącego. Oraz patrzeć na wolne momenty zamiast na średnią. Inżynierowie biorą do tego 95. percentyl, zapisywany jako p95: jeśli co dwudziesta wymiana jest wolna, to przy dwudziestu wymianach na rozmowę mniej więcej dwie na trzy rozmowy zawierają przynajmniej jedną niezręczną ciszę. Czas generowania modelu, liczba, którą chętnie podają dostawcy, pomija transmisję, turn detection i wywołania narzędzi.

Rozpoznawanie mowy, model językowy i synteza mowy są w dużej mierze towarem, który można wynająć. Opóźnienie kryje się we wszystkim dookoła i tam leży praca.

Kaskada, speech-to-speech czy forma mieszana

Pierwsza decyzja architektoniczna dotyczy tego, ile modeli siedzi w pętli rozmowy. Modele speech-to-speech szybko dojrzały. Radzą sobie z wchodzeniem w słowo, wydają sygnały słuchania, gdy dzwoniący mówi, i utrzymują ton oraz akcent. Rozumowanie i wywołania narzędzi nie są już powodem, by ich unikać. Kontrola jest.

W formie mieszanej mały, szybki model prowadzi rozmowę i trzyma rytm, a wszystko, co wymaga dokładności, reguł albo systemu źródłowego, trafia przez wywołania narzędzi do większych modeli. Dzwoniący słyszy jedną ciągłą rozmowę, a barierki działają w warstwie tekstu, gdzie łatwiej je dobrze ustawić. Cokolwiek zbudujesz: zachowuj zapisy rozmów. Ewaluacja, audyt i każde późniejsze ulepszenie wiszą na nich.

Gdzie to działa i co kupić

Miejsce jest decyzją o modelu. Kto dobiera rozpoznawanie mowy, model językowy i syntezę mowy osobno, zawsze najlepsze, często kończy z układanką rozciągniętą po dostawcach i regionach, a każdy przeskok kosztuje więcej, niż dają lepsze modele. Modele stojące obok siebie i wystarczająco dobre zwykle wygrywają z rozproszonymi znakomitymi. W Europie o regionie często decyduje to, gdzie mogą leżeć dane, zanim zdecyduje opóźnienie. Dlatego to pytanie należy do pierwszej rozmowy o architekturze.

Samo połączenie potrzebuje protokołu zbudowanego dla dźwięku: WebRTC dla przeglądarek i aplikacji, SIP dla linii telefonicznych. Zapytanie i odpowiedź po HTTP kosztuje czas przy każdej wymianie i praktycznie uniemożliwia przerywanie. To instalacja, której nikt nie powinien budować od zera. Dostarczają ją frameworki takie jak LiveKit czy Pipecat oraz platformy zarządzane. Kupienie tej instalacji jest rozsądne. Oddanie zachowania systemu już nie.

Spięcie wszystkiego u jednego dostawcy to najszybsza droga do działającego systemu. Ceną jest architektura, której trudno dotknąć, gdy za pół roku pojawi się lepszy model.

Turn detection to decyzja produktowa

Rozstrzygnięcie, kiedy dzwoniący skończył, to najtrudniejsza część pętli i najbardziej niedoceniana. Cisza jest słabym sygnałem. Kto odczytuje numer sprawy, poprawia się albo szuka słowa w drugim języku, milknie w środku zdania na ponad 700 milisekund. Sztywny czas oczekiwania albo ucina takich rozmówców, albo dokłada pustkę do każdej wymiany. Przy 800 milisekundach na wymianę i trzydziestu wymianach to 24 sekundy ciszy.

Ten czas oczekiwania to ustalenie, jak mówią Twoi dzwoniący, i powinien różnić się między procesami: cierpliwy przy zbieraniu adresu, szybki przy pytaniu tak lub nie. Systemy produkcyjne łączą wykrywanie aktywności głosu, sygnał końca wypowiedzi z rozpoznawania mowy oraz mały model, który z doboru słów i melodii mowy przewiduje, czy myśl jest zakończona. Same detektory są małe i tanie. Różnicę robi reguła wokół nich.

Najdłuższe pauzy robią ci, którzy mówią nie w swoim języku ojczystym. Próg dostrojony na rodzimych użytkownikach w cichym biurze ucina więc dużą część prawdziwych rozmówców. Nad wszystkim stoi jakość dźwięku. Mikrofon, redukcja echa i redukcja szumu są przed każdym modelem, zwłaszcza przy awatarach i terminalach w przestrzeni publicznej.

Gdzie asystenci głosowi psują się w produkcji

Większość usterek nie pokazuje się w demonstracji. Te pojawiają się przy prawdziwych rozmówcach.

Żadna z tych usterek nie leży w modelu, więc żadnej nie rozwiąże lepszy model.

Dlaczego warto z partnerem i dlaczego z nami

Silny własny zespół może wziąć powyższe punkty i budować bezpośrednio na platformie. Partner opłaca się tam, gdzie platforma nie pomaga: przy wpasowaniu asystenta w istniejący krajobraz systemów, przy europejskich wymaganiach wobec danych i przy projektowaniu rozmów, które wytrzymują zetknięcie z prawdziwymi użytkownikami w prawdziwym otoczeniu.

• Integracja z istniejącymi systemami. Jako część grupy Apollogic, partnera SAP i Microsoft, łączymy asystentów głosowych z systemami ERP, CRM i obsługi, z których mają czytać i w których mają działać.
• Europejskie wymagania wobec danych. Biura w Hamburgu i Poznaniu, praca w UE, na własnych serwerach tam, gdzie projekt tego wymaga, i doświadczenie w otoczeniach regulowanych, takich jak szpitale.
• Wielojęzyczność od początku. Niemiecki, angielski i polski w zespole, a testy z osobami mówiącymi w obcym dla siebie języku należą u nas do każdego projektu.
• Niezależność od dostawcy. Nie sprzedajemy platformy, więc dobieramy elementy pasujące do przypadku i trzymamy je wymienne.

Sytuacje, w których zwykle pracujemy: awatary na targi i wydarzenia, gdzie otwarta rozmowa w głośnych halach liczy się bardziej niż ścisła dokładność. Awatary samoobsługowe w miejscach z ruchem klientów, z dźwiękiem z głośnika, wielojęzyczną publicznością i operacjami, które muszą niezawodnie trafić do systemu. Oraz asystenci na systemach firmowych, gdzie odpowiedzi i działania biorą się z danych firmy i każdy krok musi dać się prześledzić.

Jak wygląda u nas projekt

Nie ma jednego słusznego układu, więc nie zaczynamy od szablonu. Projekt głosowy prowadzimy u nas w trzech etapach, z punktem decyzyjnym po pierwszym.

• Analiza. Oglądamy cały przebieg: scenariusz i miejsca, w których rozmowy wykolejają się, otoczenie, systemy, do których asystent musi sięgnąć, i to, jak dokładne mają być odpowiedzi. Awatar rozrywkowy może improwizować, system przyjmujący rezerwacje już nie. Wynikiem są architektura, cele czasu odpowiedzi i przycięty pilotaż. Ty decydujesz, czy idziemy dalej.
• Budowa i pilotaż. Budujemy asystenta, podłączamy go do Twoich systemów i testujemy na prawdziwej mowie: różni mówcy, języki, hałas w tle i przerwania, a nie cicha sala konferencyjna.
• Start i praca. Wdrożenie z pomiarem każdej warstwy, regularny przegląd prawdziwych rozmów i elementy, które da się wymienić, gdy pojawią się lepsze modele.

Pytania, które kupujący zwykle zadają, należą do analizy: jak asystent podłącza się do istniejącego centrum obsługi albo centrali telefonicznej, jakie języki musi znać, gdzie leżą nagrania i kto ma do nich dostęp, jak dzwoniący dowiaduje się, że rozmawia z AI, czego wymaga unijny AI Act, oraz kto prowadzi i ulepsza system po starcie.

Czy zaczynasz od zastosowania, porównujesz dostawców, czy siedzisz na prototypie, który nie wytrzymuje kontaktu z prawdziwymi użytkownikami: to moment, w którym zwykle wchodzimy. Jak przycinamy projekty, opisujemy na stronie Jak pracujemy.

theBlue.ai to firma zajmująca się AI dla przedsiębiorstw, z biurami w Hamburgu i Poznaniu. Zespół pracuje nad projektami AI od 2016 roku i należy do grupy Apollogic z ponad 120 programistami. Więcej o nas na stronie O nas.

Źródła: Stivers i in., „Universals and cultural variation in turn-taking in conversation”, PNAS 106(26), 2009 dla odstępu między mówiącymi. Cekura, sierpień 2026 dla rozkładu czasów odpowiedzi na sześciu platformach. Części tego artykułu pochodzą z wykładu „Voice Agents: Where Latency Hides and How to Fight It”, który nasza CTO Agata Chudzińska wygłosiła 29 września 2026 roku na ML Con w Nowym Jorku.

Najczęściej zadawane pytania