Głos w czasie rzeczywistym daje użytkownikom zupełnie nowy sposób interakcji z aplikacjami opartymi na AI. Zamiast pisać lub poruszać się po menu użytkownicy mówią naturalnie i otrzymują odpowiedzi w naturalnym tempie, z uwzględnieniem kontekstu emocjonalnego.
Stworzenie doskonałego interfejsu głosowego czasu rzeczywistego polega na koordynowaniu interakcji na żywo. Właśnie tutaj zaczyna się właściwa praca nad produktem. Interakcja w czasie rzeczywistym jest natychmiastowa i naturalna, ale stworzenie aplikacji, która utrzyma takie wrażenie, stanowi odrębne wyzwanie inżynieryjne.
Model jest tylko jednym z elementów systemu. Aplikacje produkcyjne wymagają infrastruktury zaprojektowanej od podstaw pod kątem głosu, wyraźnego oddzielenia płynności rozmowy od głębszego rozumowania oraz sterowania opartego na zdarzeniach, które pozwala zarządzać sesją w miarę jej przebiegu.
Mechanizmy ochronne i ewaluacja to źródło wielu pozostałych trudności. Kontrole bezpieczeństwa muszą nadążać za dźwiękiem na żywo, a ulotne cechy rozmowy, takie jak tempo, ton i płynność, trudno ocenić tradycyjnymi metodami ewaluacji.
Większość dzisiejszych aplikacji AI z obsługą głosu nadal działa tak samo: system odbiera mowę i zamienia ją na tekst, model myśli, a następnie głos syntetyczny odczytuje odpowiedź. To działa. Interakcja przypomina jednak to, czym faktycznie jest: potok przetwarzania, a nie rozmowę.
Głos w czasie rzeczywistym to zmienia. Użytkownicy mówią naturalnie i otrzymują odpowiedzi zachowujące odpowiednie tempo, ton i kontekst emocjonalny. Interakcja jest szybsza i płynniejsza niż w łańcuchowych systemach rozpoznawania mowy, więc bardziej przypomina rozmowę z człowiekiem niż obsługę systemu.
Zaobserwowaliśmy, że otwiera to nowe możliwości produktowe, z którymi architektury potokowe radzą sobie słabo. agenci głosowi działający w czasie rzeczywistym mogą obsługiwać klientów bez długich, ograniczających menu IVR i przekierowywania między działami. Mogą prowadzić coaching i onboarding, wspierać dostępność w różnych kanałach i nie tylko. Głos w czasie rzeczywistym warto wdrażać wszędzie tam, gdzie rozmowa ma przewagę nad interfejsem tekstowym.
Większość aplikacji z obsługą głosu wykorzystuje tak zwane „podejście łańcuchowe”: potok oddzielnych modeli do zamiany mowy na tekst, przetwarzania języka i zamiany tekstu na mowę. Takie systemy działają dobrze i otwierają wiele możliwości, ale dźwięk pojawia się w nich tylko na początku i na końcu procesu. Oddzielne etapy narzucają sztywną strukturę i powodują opóźnienia, przez co interakcja jest mniej naturalna niż prawdziwa rozmowa.
Głos w czasie rzeczywistym działa inaczej. Zamiast korzystać z oddzielnych modeli do słuchania, myślenia i mówienia, jeden model natywnie obsługuje wszystkie trzy zadania, jednocześnie rozumiejąc i generując zarówno dźwięk, jak i transkrypcje. Dane wejściowe i wyjściowe są przetwarzane nieprzerwanie, dzięki czemu system odpowiada w naturalnym tempie i w sposób nacechowany emocjonalnie, zachowując realistyczny rytm rozmowy na żywo. W rezultacie tempo, ton i sposób reagowania na przerywanie stają się kluczowymi elementami produktu.
Interakcja w czasie rzeczywistym jest atrakcyjna, bo daje poczucie natychmiastowości, ale trudna, ponieważ nic nie czeka na swoją kolej. Jej obsługa wymaga czegoś więcej niż szybkiego i dokładnego generowania dźwięku. Trudność kryje się we wszystkim pozostałym. Model działa w ramach sesji na żywo, dlatego wszystko wokół niego (stan, bezpieczeństwo, orkiestracja i sterowanie) musi działać równolegle z rozmową i w tym samym tempie.
W aplikacji głosowej opartej na podejściu łańcuchowym rozmowa podzielona na tury ma przejrzystą strukturę wymiany zdań. Użytkownik mówi, system odpowiada i rozpoczyna się kolejny etap. Głos w czasie rzeczywistym nie zapewnia takiej struktury. Obie strony mogą mówić jednocześnie albo żadna z nich się nie odzywa i zapada cisza. Użytkownik może przerwać odpowiedź w połowie lub zadać dodatkowe pytanie, zanim system skończy mówić. Przerywanie przestaje być przypadkiem brzegowym, a staje się podstawowym wzorcem interakcji.
Właśnie dlatego aplikacje działające w czasie rzeczywistym są przede wszystkim problemem koordynacji, a system otaczający model ma równie duże znaczenie jak sam model.
Skalowalna obsługa takiego systemu wymaga zaprojektowania go specjalnie z myślą o interakcji na żywo. Składają się na nią trzy elementy, które regularnie występują w systemach trafiających do środowiska produkcyjnego.
Sesje głosowe w czasie rzeczywistym muszą obsługiwać strumieniowe przesyłanie dźwięku, naprzemienne zabieranie głosu, przerywanie i działanie agentów. W zależności od miejsca wdrożenia aplikacji może być również wymagana obsługa połączeń telefonicznych. Są to podstawowe elementy doświadczenia i mają kluczowe znaczenie dla skalowania aplikacji.
Pierwszym wymaganiem jest warstwa sesji zaprojektowana od podstaw pod kątem głosu. Platformy komunikacji w czasie rzeczywistym (RTC) zapewniają aplikacji środowisko do zarządzania uczestnikami, strumieniowego przesyłania dźwięku i uruchamiania agentów w środowisku telefonicznym. Z naszego doświadczenia wynika, że szczególnie pomocny jest Livekit, który oferuje gotowy stos WebRTC zapewniający niskie opóźnienia, wysokiej jakości redukcję szumów oraz ograniczanie wahań opóźnienia transmisji. Samodzielne wdrażanie tej warstwy rzadko jest warte dodatkowej złożoności.
Architektura wieloagentowa dla głosu w czasie rzeczywistym służy przede wszystkim rozdzieleniu odpowiedzialności.
Modele głosowe działające w czasie rzeczywistym bardzo skutecznie prowadzą strumieniowe rozmowy głosowe, ale nie są zoptymalizowane pod kątem głębszego rozumowania. Zadania takie jak wywoływanie narzędzi, wyszukiwanie informacji czy podejmowanie ustrukturyzowanych decyzji lepiej powierzyć innemu modelowi.
Przydatnym wzorcem jest architektura odpowiadającego i myślącego.
Agent odpowiadający jest agentem głosowym działającym w czasie rzeczywistym. Odpowiada za podtrzymywanie interakcji na żywo: słuchanie, mówienie, obsługę przerywania i zachowanie płynności rozmowy. W jego projekcie priorytetami są szybkość reakcji, jasność i spójność emocjonalna.
Agent myślący jest odrębnym agentem opartym na modelu zdolnym do rozumowania. Działa poza głównym kanałem rozmowy i wykonuje zadania takie jak korzystanie z narzędzi, wyszukiwanie informacji i planowanie. Agent odpowiadający może w razie potrzeby wywołać agenta myślącego i włączyć uzyskane wyniki do rozmowy.
W niektórych przypadkach agent myślący może bezpośrednio prowadzić rozumowanie. W innych może pełnić funkcję koordynatora zestawu wyspecjalizowanych agentów. Najważniejsze jest to, że pracę tę wykonuje model lepiej dostosowany do zadań wymagających rozumowania.
Korzyść jest prosta: agent odpowiadający pozostaje szybki, rozmowny i skupiony, a agent myślący zajmuje się pracą wymagającą więcej czasu, kontekstu lub struktury.
Przyszły rozwój pionierskich modeli może sprawić, że to podejście stanie się zbędne. Na razie jednak konsekwentnie osiąga ono lepsze wyniki niż rozwiązania oparte na jednym agencie.
Systemy głosowe działające w czasie rzeczywistym naturalnie generują ciągły strumień zdarzeń.
Użytkownicy zaczynają mówić, robią pauzy i przerywać. Transkrypcje są aktualizowane stopniowo. Odpowiedzi są generowane i przesyłane strumieniowo. Napływają wyniki zewnętrzne. Warunki w ramach sesji ulegają zmianie. Wszystkie te elementy można rejestrować, przesyłać strumieniowo i przechowywać jako kluczowe zdarzenia, które ukształtowały bieżący stan rozmowy. Bez nich tracimy możliwość precyzyjnych i ukierunkowanych interwencji.
Podejście zdarzeniowe zapewnia przejrzysty sposób zarządzania tym procesem. System rejestruje zdarzenia w chwili ich wystąpienia, aktualizuje stan sesji i uruchamia odpowiednie dalsze działania.
Lekkie procedury obsługi utrzymują szybkość reakcji ścieżki czasu rzeczywistego, natomiast bardziej złożone zadania —takie jak aktualizowanie maszyn stanów, rejestrowanie metryk, usuwanie informacji wrażliwych, aktualizowanie baz danych i kończenie sesji — są uruchamiane asynchronicznie w tle.
W miarę dodawania funkcji liczba tych zadań wykonywanych w tle może szybko rosnąć. Nawet niewielkie zmiany produktu mogą wprowadzać nowe przepływy zdarzeń i zależności. Dobrze uporządkowana architektura obsługująca tę współbieżność pomaga zachować zrozumiałość i niezawodność systemu w miarę jego rozwoju.
Podejście zdarzeniowe wspiera również kluczowy aspekt produktu: kształtowanie samej rozmowy. System dźwiękowy działający w czasie rzeczywistym nie tylko generuje odpowiedzi, ale też zarządza tempem, obsługuje ciszę i przerwanie oraz decyduje, jak i kiedy zakończyć sesję. Te zachowania są częścią doświadczenia oferowanego przez produkt i warto je świadomie projektować.
Gdy stan sesji zmienia się w zależności od liczby tur, upływu czasu lub zachowania użytkownika, system może przekazywać agentowi odpowiadającemu konkretne wskazówki. Może na przykład przekazać agentowi polecenie, aby pomógł użytkownikowi zakończyć rozmowę, gdy zbliża się limit sesji, albo udzielił wyjaśnień, jeśli interakcja utknie w miejscu. Takie interwencje są niewielkie, ale sprawiają, że całe doświadczenie wydaje się przemyślane i spójne.
Dobrze zaprojektowany system zachowuje przejrzysty obraz stanu sesji: kto mówi, jak przebiega rozmowa i które warunki zostały spełnione. Stan ten jest stale aktualizowany przez strumień zdarzeń i umożliwia przekazanie właściwych wskazówek we właściwym czasie.
W AI przeznaczonej dla użytkowników mechanizmy ochronne są niezbędne. Odpowiadają za bezpieczeństwo, zgodność z przepisami, zapobieganie nadużyciom i niezawodność. W systemie opartym na turach są oczywiste momenty na ich uruchomienie: po wypowiedzi użytkownika lub przed przekazaniem odpowiedzi.
Głos w czasie rzeczywistym eliminuje większość tych dogodnych punktów kontrolnych. Dane głosowe użytkownika napływają bez przerwy. Dźwięk odpowiedzi może być już przesyłany strumieniowo. Gotowe transkrypcje często pojawiają się z opóźnieniem względem dźwięku. Jeśli system czeka z kontrolą do otrzymania pełnych wiadomości, rozmowa przestaje sprawiać wrażenie prowadzonej w czasie rzeczywistym.
Mechanizmy ochronne muszą więc działać równolegle z rozmową, aby zachować naturalność interakcji. Jednym z rozwiązań jest strumieniowe przesyłanie dźwięku do bufora i asynchroniczne ocenianie kolejnych fragmentów transkrypcji, gdy tylko się pojawią. Dzięki temu kontrole bezpieczeństwa mogą działać niemal w czasie rzeczywistym bez blokowania interakcji.
Gdy zadziała mechanizm ochronny, system może odpowiednio zareagować w ramach rozmowy, przekierowując ją, dostosowując zachowanie lub kończąc sesję, jeśli jest to konieczne. Dzięki temu mechanizmy ochronne działają w czasie rzeczywistym bez pogarszania jakości doświadczenia użytkownika.
Najtrudniejsze w ewaluacji systemu rozmów w czasie rzeczywistym jest to, że niektórych kluczowych cech (tempa, przerwań, płynności i tonu) nie da się ocenić wyłącznie na podstawie transkrypcji.
Standardowe procesy ewaluacji przekazują systemowi realistyczne scenariusze, obserwują wyniki i je oceniają. W systemach tekstowych lub opartych na łańcuchowym przetwarzaniu dźwięku jest to proste: wysłać tekst i sprawdzić otrzymany tekst. W trybie czasu rzeczywistego dane wejściowe są dźwiękiem na żywo, a najważniejsze aspekty dynamiki rozmowy zależą od czasu: jak agent radzi sobie z nakładającymi się wypowiedziami, jak szybko odpowiada i jak wraca do rozmowy po przerwaniu.
Testy ręczne, czyli bezpośrednia rozmowa z agentem, pozwalają ocenić te cechy, ale trudno je skalować. Automatyzacja oparta na transkrypcjach jest skalowalna, ale usuwa sygnały odróżniające dobre doświadczenie w czasie rzeczywistym od złego.
Żadna pojedyncza metoda nie wystarczy. W praktyce potrzebny jest zestaw metod:
Ewaluacje agent–agent: drugi agent działający w czasie rzeczywistym otrzymuje instrukcję odgrywania określonego typu użytkownika i prowadzi rozmowę z testowanym systemem. Trzeci LLM pełni rolę sędziego i ocenia interakcję. Pozwala to przeprowadzać na dużą skalę testy całej ścieżki audio, w tym tempa i sposobu reagowania na przerwanie.
Metryki pozafunkcjonalne: czas do rozpoczęcia odtwarzania dźwięku i analiza sentymentu transkrypcji dostarczają ilościowych wskaźników zastępczych jakości rozmowy.
Ręczny przegląd jakościowy: nadal jest niezbędny do wykrywania problemów pomijanych przez automatyczne metryki, szczególnie związanych z tonem i naturalnością.
Żadna pojedyncza metoda nie obejmuje wszystkich aspektów. Wdrażanie agentów działających w czasie rzeczywistym na produkcji wymaga połączenia wszystkich trzech metod, a nawet wtedy narzędzia do ewaluacji dźwięku w czasie rzeczywistym pozostają mniej rozwinięte niż narzędzia do oceny AI opartej na tekście.
Głos w czasie rzeczywistym zmienia charakter produktu. Na doświadczenia użytkowników wpływają nie tylko słowa, lecz także tempo, przerwania, cisza i sposób powrotu do rozmowy.
Oznacza to, że model jest tylko jednym z elementów systemu. System głosowy działający w czasie rzeczywistym na produkcji wymaga warstwy sesji zaprojektowanej od podstaw pod kątem głosu, wyraźnego rozdzielenia mówienia od rozumowania oraz sterowania aktywną sesją na podstawie zdarzeń. Mechanizmy ochronne nadal są wąskim gardłem pod względem opóźnień, ale pomysłowe rozwiązania pozwalają zachować znaczną część doświadczenia czasu rzeczywistego.
Najsłabszym elementem całego zestawu nadal jest ewaluacja. Wciąż nie ma ustalonego sposobu testowania cech decydujących o jakości głosu w czasie rzeczywistym: tempa, tonu, sposobu obsługi przerywania i płynności rozmowy. Dopóki taki sposób nie powstanie, zespoły korzystające z tej technologii będą musiały łączyć testy automatyczne, testy agent–agent i przeglądy ręczne.