Jak stworzyć agenta głosowego opartego na AI w 2026 roku: architektura i struktura systemu

Agent głosowy oparty na sztucznej inteligencji odbiera połączenia telefoniczne, analizuje, czego chce dzwoniący na podstawie naturalnej mowy, i albo odpowiada, albo podejmuje odpowiednie działanie, bez konieczności korzystania z menu z numerowanymi opcjami. Aby to było możliwe, współpracują trzy komponenty: model, który transkrybuje dźwięk dzwoniącego, model językowy wielkiego rozmiaru, który decyduje, co z tym zrobić, oraz model, który wypowiada odpowiedź.

Połączenia telefoniczne wciąż istnieją. Firmy przeniosły obsługę klienta na czaty i e-maile, ale klienci i tak nadal dzwonili. Agent głosowy wypełnia tę lukę. Nie jest to chatbot z dodanym głośnikiem – on słucha, interpretuje intencje z faktycznej mowy ludzi i zachowuje się podobnie do wykwalifikowanej osoby na linii.

Aby agent przeszedł fazę demonstracyjną, trzeba wybrać odpowiednią architekturę i zestaw technologii, a także zredukować opóźnienie do mniej niż sekundy, zanim faktyczny klient będzie mógł z nim skontaktować się. Poniższe sekcje omawiają wszystkie te aspekty.

Budowa w ośmiu decyzjach

Każda decyzja zmniejsza liczbę opcji dla następnej.

1. Określ proces pracy połączenia. Zdecyduj, jakie typy połączeń obsługuje agent, co może robić oraz dokładnie w którym momencie przejmuje kontrolę osoba.
2. Wybierz architekturę. Kaskadowa, półkaskadowa lub natywna konwersja mowy na mowę. Ten wybór określa minimalną latencję oraz maksymalne koszty.
3. Wybierz usługę telefoniczną. Twilio, AWS Connect lub WebRTC, w zależności od kanału i regionu.
4. Dodaj funkcję konwersji mowy na tekst. Deepgram Nova-3 lub AssemblyAI w trybie strumieniowym, z dostosowanym słownikiem terminów specjalistycznych załadowanym przed uruchomieniem.
5. Połącz LLM z narzędziami. Ustaw zasady wywoływania funkcji i eskalacji, a także połącz system CRM lub system rezerwacji.
6. Dodaj funkcję konwersji tekstu na mowę. Wybierz głos, włącz strumieniowanie i dąż do tego, aby pierwszy dźwięk trwał mniej niż 200 ms.
7. Testuj opóźnienia i przerwy w działaniu. Uruchamiaj zaprogramowane oraz specjalnie przygotowane scenariusze i dąż do czasu realizacji poniżej jednej sekundy od początku do końca.
8. Monitoruj po uruchomieniu. Obserwuj wskaźnik ukończenia zadań, skuteczność radzenia sobie z problemami, poziom satysfakcji klientów oraz czas obsługi od pierwszego dnia.

Dlaczego firmy je tworzą

Ilość połączeń, która kiedyś uzasadniała istnienie zespołu telefonicznego, już nie mieści się w ramach jednego takiego zespołu. Pytania powtarzalne, połączenia po godzinach pracy, próby kontaktu z osobami, które się nie pojawiły, oraz powiadomienia wysyłane do klientów – wszystko to przychodzi przez ten sam kanał, a zatrudnianie dodatkowych osób do obsługi tego wszystkiego hamuje dalszy rozwój.

Menu interaktywnej odpowiedzi głosowej odstraszają dzwoniących, którzy rozłączają się, gdy tylko nie mają dostępu do wybranych opcji. Agent głosowy zachowuje się inaczej, ponieważ może prowadzić prawdziwą rozmowę, zadawać dodatkowe pytania, kierować złożone przypadki oraz realizować powtarzalne procesy telefoniczne na dużą skalę. Dane dotyczące przyjęcia tej technologii wskazują na to samo. Badania pokazują, że 97% użytkowników telefonów mobilnych korzysta z asystentów głosowych, 89% klientów deklaruje, że woli marki oferujące wsparcie oparte na sztucznej inteligencji głosowej, a firmy je wdrażające zgłaszają niższe koszty operacyjne o 20 do 30%. Traktuj te dane jako wyniki badań rynkowych, a nie gwarancje.

Nacisk ten objawia się w pięciu obszarach, w których zespoły ludzkie nie są w stanie nadążyć:

Powtarzalna liczba połączeń przychodzących. W logistyce szacuje się, że od 50 do 70% połączeń przychodzących to zapytania typu „gdzie jest mój zamówienie”. To samo pytanie, tysiące razy dziennie, rozwiązywane przez osoby, które mogłyby zajmować się trudniejszymi zadaniami.

Telefony po godzinach pracy. Pacjenci starają się umawiać się o północy, a kandydaci na pożyczki dzwonią w niedziele. Klienci nie planują swoich pytań zgodnie z godzinami otwarcia.

Brak stawienia się bez możliwości rekompensaty. Kliniki tracą około 20% umówionych wizyt z powodu braku stawienia się pacjentów. Bez automatycznego follow-upu miejsce to pozostaje puste, a wraz z nim dochód.

Ręczna praca wysyłkowa. Przypomnienia o odnowieniu, śledzenie rat oraz potwierdzenia dostawy – wszystko odbywa się według tego samego schematu. Płacenie ludziom za czytanie go na głos jest drogie i niepotrzebne.

Nagłe wzrosty obciążenia, których nikt nie może sprostać. Dziesięciu agentów obsługuje dziesięć połączeń. Agent głosowy może obsłużyć tysiące połączeń jednocześnie, bez kolejki i bez muzyki oczekiwania.

Trzy architektury

Architektura określa, jak szybko agent odpowiada, jak dużą kontrolę ma zespół, jak łatwe jest debugowanie oraz jak przewidywalne pozostają koszty w skali. Dominują trzy wzorce produkcyjne, z których każdy inaczej balansuje opóźnienia, kontrolę i koszty, a niewłaściwy wybór może mieć wysokie koszty korekty.

1. Kaskadowy pipeline

Trzy specjalistyczne modele działają sekwencyjnie. Funkcja mowy do tekstu przekształca dźwięk w tekst, model LLM czyta ten tekst i pisze odpowiedź, a funkcja tekstu do mowy zamienia odpowiedź z powrotem w dźwięk. Pomiędzy poszczególnymi etapami przekazywany jest zwykły tekst, a właśnie ta prostota stanowi sedno tego rozwiązania. Jest to najczęściej używana architektura produkcyjna w 2026 roku.

Rzeczywista latencja od początku do końca wynosi od 500 do 800 ms. To nie jest najwyższa wartość, ale zapewnia pełną modułowość. Można zastąpić Deepgram przez AssemblyAI, ChatGPT przez Claude lub Cartesia przez ElevenLabs, nie zmieniając niczego innego. Każdy komponent generuje logi, a każda warstwa może być mierzona, dostosowywana i zastępowana osobno. Rozwiązania o dużej skali, intensywnie wykorzystujące telefonię i wymagające ścisłego przestrzegania regulacji najczęściej działają w ten sposób – nie dlatego, że jest to najbardziej zaawansowane rozwiązanie, ale dlatego, że jest najłatwiejsze do kontrolowania.

Proces budowy w formie łańcucha składa się z tych elementów, z których każdy można zastąpić niezależnie:

• Strumień telefoniczny. Połączenie przez Twilio lub AWS Connect oraz przekazanie przychodzącego dźwięku do rozpoznawania mowy za pomocą SIP lub WebRTC.
• Strumieniowe przetwarzanie mowy na tekst. Deepgram Nova-3 w trybie strumieniowym zaczyna transkrybować jeszcze przed tym, jak dzwoniący skończy zdanie.
• Orkiestracja LLM. Przekazuj transkrypcję do GPT-5 lub Claude Sonnet wraz z instrukcją określającą zakres, ton i warunki eskalacji.
• Wywoływanie funkcji. Łącz się z systemem CRM, systemem rezerwacji lub bazą danych. Model wywołuje je w trakcie rozmowy i czeka na wynik.
• Strumieniowy TTS. Wysyłaj wyniki modelu do Cartesia lub ElevenLabs, aby odtwarzanie rozpoczęło się przed ukończeniem generowania pełnej odpowiedzi.
• Rejestracja i odtwarzanie. Zapisuj transkrypcje i audio na każdym poziomie, aby można było zlokalizować przyczynę awarii w konkretnym komponencie.
• Przekazanie do człowieka. Określ, które intencje i słowa kluczowe powodują przeniesienie zadania do żywego agenta.

2. Półkaskada

Tutaj dźwięk trafia bezpośrednio do modelu multimodalnego, który rozumie go w sposób naturalny, a tylko strona wyjściowa przechodzi przez dedykowany model konwersji tekstu na mowę. Ta jedna zmiana zmniejsza opóźnienie do 300–500 ms i umożliwia realizację funkcji, których nie potrafi system kaskadowy.

Model wykrywa rozczarowanego rozmówcę, rosnącą intonację w pytaniu lub zmianę języka w trakcie zdania. Pomiędzy dźwiękiem a zrozumieniem modelu nie ma żadnego kroku transkrypcji. Wynik nadal przechodzi przez specjalistyczny model TTS, dzięki czemu jakość głosu pozostaje dokładnie kontrolowalna. ElevenLabs Agents oraz Google’s Gemini Live stosują ten sam model, a jest to właściwy wybór, gdy sposób, w jaki ktoś coś mówi, ma takie samo znaczenie jak to, co mówi.

3. Natywna konwersja mowy na mowę

Jeden model radzi sobie ze wszystkim: wejście dźwięku, wyjście dźwięku, brak tekstu pomiędzy nimi oraz brak granic pomiędzy komponentami. Opóźnienie spada do 200–300 ms. Poniżej 300 ms rozmowa przestaje przypominać działanie oprogramowania, co ma znaczenie tam, gdzie wahania podważają zaufanie.

Jednakże istnieją rzeczywiste kompromisy. Podczas długich rozmów koszt rośnie, ponieważ model przetwarza na nowo każdy wcześniejszy element rozmowy przy każdej zmianie strony, więc rozmowa, która wydaje się kosztować 0,30 dolara na minutę, w praktyce może kosztować aż 1,50 dolara. Tracimy również kontrolę na poziomie poszczególnych komponentów. Gdy coś pójdzie nie tak, nie możemy zidentyfikować odpowiedzialnego warstwy, ponieważ warstw takich nie ma.

Obowiązuje jeszcze jedna ograniczenie. Rozmowy telefoniczne przez publiczną sieć przesyłają dźwięk o częstotliwości 8 kHz, co oznacza utratę dużej części bogactwa dźwięku, które modele dźwiękowe są przeznaczone do wykorzystania, więc ich przewaga nad rozwiązaniami typu kaskada znacznie się zmniejsza.

Który wybrać

Zacznij od rozwiązania typu cascade, jeśli implementacja obejmuje telefonię, rejestrację zgodności z regulacjami lub konieczność przewidywalności kosztów. Sama modularność wystarcza jako uzasadnienie w większości przypadków korporacyjnych. Przejdź do rozwiązania typu pół-cascade, gdy ma znaczenie dźwięk wejściowy – np. gdy dzwoniący zmieniają język lub gdy konieczna jest detekcja tonu emocjonalnego, albo w sytuacjach, gdy transkrypcja niszczy informacje, których potrzebujesz. Wybierz rozwiązanie typu speech-to-speech tylko wtedy, gdy odpowiedzi poniżej 300 ms są bezwzględnie konieczne, a objętość połączeń sprawia, że kalkulacja kosztów na minutę jest wykonalna. Obejmuje to wąski zakres przypadków, a w większości implementacji rozwiązanie typu cascade daje lepsze rezultaty.

| Criteria                 | Cascaded Pipeline                         | Half-Cascade                            | Native Speech-to-Speech                    |
|--------------------------|-------------------------------------------|-----------------------------------------|--------------------------------------------|
| Latency                  | 500-800ms                                 | 300-500ms                               | 200-300ms                                  |
| Approx. Cost/min         | Low                                       | Medium                                  | High ($0.30 can reach $1.50)               |
| Modularity               | Full, swap any component independently    | Partial, TTS is swappable, input        | None, one model, no layers                 |
|                          |                                           | model is not                            |                                            |
| Emotion & Tone Detection | No, transcription strips it              | Yes, model hears audio natively         | Yes                                        |
| Compliance Logging       | Per-layer logs on every component         | Partial                                 | Not possible                               |
| PSTN Compatibility       | Strong                                    | Strong                                  | Weak, 8kHz audio narrows the               |
|                          |                                           |                                         | quality advantage                          |
| Best For                 | Telephony, compliance-sensitive,          | Multilingual callers, emotional         | Sub-300ms use cases with manageable        |
|                          | high-volume deployments                   | context, tone detection                 | call volume                                |
| Avoid When               | Latency is a hard requirement             | You need full component control         | Long calls, regulated industries,          |
|                          | under 500ms                               | or strict cost caps                     | unpredictable volume                       |

Pięć warstw

Niezależnie od tego, jak prosty lub złożony jest agent, jego struktura jest identyczna: dochodzi dźwięk, wychodzi odpowiedź, a kroki pomiędzy nimi decydują o tym, jak szybka, dokładna i „ludzka” będzie ta wymiana.

| Layer         | Role                    | Common Tools                  | Enterprise Consideration          |
|---------------|-------------------------|-------------------------------|-----------------------------------|
| Telephony     | Call routing            | Twilio, AWS Connect, SIP      | Region coverage, number portability |
| STT           | Speech transcription    | Deepgram, AssemblyAI, Whisper | Accents, noise, vocabulary        |
| LLM           | Reasoning and response  | GPT, Claude, Gemini, Llama    | Latency, compliance, tool use     |
| TTS           | Voice output            | ElevenLabs, Cartesia, PlayHT  | First-byte latency, brand voice   |
| Orchestration | Turn-taking and routing | Retell AI, Vapi, LiveKit      | Barge-in, handoff, monitoring     |

Komponenty, w kolejności:

1. Telefonia. Drzwi wejściowe. Osoba dzwoniąca wybiera numer, a ten warstwa przekazuje dźwięk dalej w łańcuchu przetwarzania. Powszechnymi rozwiązaniami są Twilio, AWS Connect i WebRTC.
2. Tłumaczenie mowy na tekst. Przekształca to, co mówi dzwoniący, na tekst. Hałas, akcenty oraz specjalistyczna terminologia wpływają na jakość, a błędy w tym etapie odbijają się na każdej kolejnej warstwie.
3. LLM. „Mózg”. Czyta transkrypcję, określa intencję, wybiera działanie i pisze odpowiedź. Gdy potrzebuje danych z zewnątrz, takich jak status zamówienia lub saldo, wywołuje odpowiedni narzędzie i czeka.
4. Tłumaczenie tekstu na mowę. Przekształca odpowiedź z powrotem na dźwięk, a zarówno jakość głosu, jak i szybkość reakcji zależą od niego.
5. Integracje. Połączenia z rzeczywistymi systemami: CRM, platformami rezerwacyjnymi, bazami danych oraz procesorami płatności. Bez nich agent może prowadzić rozmowy, ale nie może nic zrobić.

Każda przekazana informacja powoduje opóźnienie, a każdy komponent może zawieść niezależnie. Wiedza o tym, gdzie znajduje się każdy z nich, pozwala zamienić pięciogodzinne sesje naprawy błędów w pięciominutowe.

Warstwa 1: przekład mowy na tekst

Wszystko poniżej w łańcuchu zależy od tego wyniku, więc błędy tutaj rozprzestrzeniają się po całym procesie. Model przyjmuje strumień audio, dzieli go na fragmenty i przewiduje najbardziej prawdopodobną sekwencję słów na podstawie wzorców akustycznych i prawdopodobieństw językowych. Współczesne systemy STT są na tyle szybkie, że potrafią transkrybować słowo po słowie, podczas gdy rozmówca nadal mówi.

Cozę pogarsza dokładność. Cztery czynniki wpływają negatywnie na funkcjonowanie systemów konwersji mowy na tekst w warunkach produkcyjnych: hałas tła, silne akcenty, specyficzna leksyka danego obszaru oraz niska jakość dźwięku. Sieć telefoniczna dodatkowo pogłębia ten problem, ponieważ jej ograniczenie do 8 kHz eliminuje częstotliwości, które pomagają modelom odróżniać słowa o podobnym brzmieniu.

Narzędzia.

• Deepgram Nova-3 jest standardowym wyborem do rozmów telefonicznych w czasie rzeczywistym – radzi sobie z hałaśliwymi liniami, akcentami oraz niskimi prędkościami transmisji bez większych trudności.
• AssemblyAI Universal-Streaming sprawdza się najlepiej, gdy dźwięk jest czysty.
• gpt-4o-transcribe od OpenAI jest dokładny, jednak dodatkowy opóźnienie jest odczuwalne podczas rozmowy na żywo.
• Whisper to silny model zaprojektowany do przetwarzania danych partiami, więc nie nadaje się do transmisji strumieniowej.

Strumieniowanie versus przetwarzanie partiami. Przetwarzanie partiami czeka, aż osoba dzwoniąca skończy mówić, zanim rozpocznie obróbkę, natomiast strumieniowanie transkrybuje treść w miarę przychodzenia dźwięku. Dla agentów głosowych strumieniowanie jest jedyną możliwą opcją.

Luki w słownictwie. Domyślnie większość modeli STT ma trudności z nazwami firm, terminami medycznymi oraz żargonem branżowym. Spersonalizowane listy słów, wskazówki dotyczące wymowy oraz dopasowanie modelu do konkretnego obszaru pomagają rozwiązać większość tych problemów, dlatego warto przeznaczyć na to czas przed wdrożeniem w sektorach opieki zdrowotnej, logistyki lub finansów.

Warstwa 2: model LLM

Warstwa STT wytwarza tekst, a model decyduje, co z nim zrobić. Czyta transkrypcję, identyfikuje prośbę, wybiera odpowiednią akcję i pisze odpowiedź. W prostym połączeniu oznacza to odpowiedź na pytanie. W złożonym przypadku oznacza to wywołanie zewnętrznego narzędzia, oczekiwanie oraz połączenie uzyskanych danych w naturalną odpowiedź – wszystko to w czasie, jaki człowiek potrzebuje na pauzę między zdaniami.

Wybór modelu. GPT-5 i Claude Sonnet to najbardziej niezawodne opcje do generowania głosu w 2026 roku, ponieważ oba dobrze radzą sobie z kontekstem, ścisło przestrzegają instrukcji i dostarczają odpowiedzi na tyle krótkie, by można je było wypowiedzieć. Gemini 3 Flash zasługuje na rozważenie, gdy priorytetem jest niska opóźniona. Llama i Mistral nadają się dla zespołów, które potrzebują wdrożenia lokalnego lub ściślejszej kontroli kosztów.

Polecenia głosowe versus polecenia tekstowe. Głos ma jedną ograniczenie, którego brakuje komunikacji tekstowej – mianowicie długość. Agent, który odczytuje akapit, traci rozmówcę. W instrukcjach systemowych należy określić ton, długość odpowiedzi, warunki eskalacji oraz dokładne sformułowania do użycia, gdy agent nie ma odpowiedzi.

Wywoływanie funkcji. Gdy ktoś dzwoni z pytaniem dotyczącym zamówienia, agent sprawdza system zamówień lub CRM, czeka na wynik, a następnie odpowiada. To właśnie odróżnia agenta, który tylko rozmawia, od tego, który podejmuje działania. Jest jednak jeden problem: wywoływanie funkcji blokuje transmisję danych strumieniową, więc konwersację należy projektować z uwzględnieniem tych przerw.

Pamięć. Istnieją dwa rodzaje pamięci. Pamięć sesyjna obejmuje pojedynczy telefon, dzięki czemu nikt nie musi powtarzać szczegółów, natomiast pamięć trwała obejmuje kilka połączeń. Zazwyczaj najpierw wdraża się pamięć sesyjną, a funkcję trwałości dodaje się później, gdy już ustabilizuje się podstawowy proces.

Warstwa 3: konwersja tekstu na mowę

Ostateczne wrażenie klienta zależy od funkcji konwersji tekstu na mowę. Nawet poprawna, szybka i dobrze przemyślana odpowiedź traci na wartości, jeśli brzmi jak tekst wygenerowany przez robota.

Co sprawia, że głos brzmi naturalnie. Prosodia, tempo i szybkość pierwszego bajtu. Prosodia to melodia mowy, ruch wysokości tonu, który informuje słuchacza, czy dana fraza jest pytaniem. Tempo dotyczy umieszczania pauz we właściwych miejscach. Modele wytrenowane na ogromnych ilościach rzeczywistej mowy radzą sobie teraz dobrze w obu tych aspektach, a dźwięki generowane przez roboty stały się znacznie rzadsze niż w 2025 roku. Szybkość pierwszego bajtu to opóźnienie przed tym, jak rozmówca usłyszy cokolwiek po rozpoczęciu generacji.

Narzędzia.

• Cartesia Sonic jest liderem pod względem szybkości – pierwszy dźwięk pojawia się szybciej niż u większości konkurentów.
• ElevenLabs oferuje najbardziej realistyczny efekt i umożliwia klonowanie na podstawie krótkiego fragmentu audio.
• gpt-4o-mini-tts od OpenAI stanowi rozsądny wybór domyślny, jeśli cała reszta rozwiązania jest już oparta na technologii OpenAI.
• PlayHT i Rime warto wypróbować, gdy potrzebny jest konkretny akcent lub regionalny ton mowy.

Klonowanie głosu. Większość platform klonuje głos na podstawie krótkiego nagrania, co zapewnia firmom spójny głos marki podczas każdej rozmowy. Szpital może brzmieć spokojnie i profesjonalnie, podczas gdy sieć restauracji szybkiej obsługi – dynamicznie i energicznie. Należy to ustalić przed uruchomieniem usługi.

Strumieniowe TTS. Osoba dzwoniąca powinna usłyszeć pierwsze słowo, podczas gdy model nadal pisze ostatnie zdanie, co oznacza, że dźwięk jest wysyłany przed ukończeniem odpowiedzi. Ważna jest opóźnienie pierwszego bajtu, a nie całkowity czas generowania. W przypadku rozmów na żywo warto utrzymać je poniżej 200 ms.

Warstwa 4: telefonia i kanały

Tutaj świat zewnętrzny łączy się z procesem przetwarzania. Sposób, w jaki dźwięk przemieszcza się od dzwoniącego do modelu STT, decyduje o jakości rozmowy, opóźnieniach oraz o tym, jak dużą kontrolę masz nad infrastrukturą.

Jak łączą się połączenia. PSTN, zwykła sieć telefoniczna, ogranicza częstotliwość dźwięku do 8 kHz, co negatywnie wpływa na wszystkie późniejsze rozwiązania. SIP służy do ruchu VoIP i umożliwia dokładniejszą kontrolę routingu. WebRTC przesyła dane przez Internet z lepszą jakością dźwięku, dzięki czemu nadaje się do użytku w przeglądarce i aplikacjach. Powszechnym rozwiązaniem jest wykorzystanie SIP dla połączeń przychodzących, a WebRTC dla wszystkiego, co odbywa się w sieci.

Dostawcy.

• Twilio jest bezpiecznym wyborem domyślnym dzięki szerokiemu zasięgowi, niezawodnym usługom SIP trunking oraz dobrym dokumentacjom, chociaż jego koszty rosną przy dużym obłożeniu.
• AWS Connect nadaje się dla zespołów, które już korzystają z usług AWS.
• Vonage to dobra opcja dla rozszerzeń na rynki międzynarodowe, szczególnie w Europie i na Bliskim Wschodzie.

Platformy orkiestracji. Retell AI, Vapi i LiveKit znajdują się pomiędzy operatorem a wybranymi rozwiązaniami do konwersji mowy na tekst, sztucznych inteligencji typu LLM oraz konwersji tekstu na mowę. Zarządzają one ruchem audio w czasie rzeczywistym, kolejnością rozmów, wykrywaniem przerwań oraz przekazywaniem połączeń. W przypadku zastosowań telefonicznych Retell AI jest najbardziej rozwinięty, Vapi oferuje najwięcej możliwości dostosowania własnych procesów, natomiast LiveKit najlepiej funkcjonuje z WebRTC.

Przepływy przychodzące i wychodzące. Przepływ przychodzący czeka na połączenie i reaguje na jego nadejście. Przepływ wychodzący wykonywa połączenie, sprawdza, kto odebrał, i wykonuje z góry zaplanowane zadania, takie jak przypomnienie o płatności lub potwierdzenie umówienia. Proces jest taki sam we wszystkich przypadkach – różni się jedynie osoba inicjująca rozmowę oraz sposób jej rozpoczęcia.

Warstwa 5: integracje

Integracje umożliwiają agentowi działanie, a nie tylko rozmowę. Model może odczytać intencję i przygotować odpowiedź, ale bez połączenia z rzeczywistymi systemami nie może zarezerwować terminu, sprawdzić zamówienie ani zmienić danych. Jedyne, co może zrobić, to opisać, co by zrobił.

Co jest łączone. Zazwyczaj cztery kategorie: systemy CRM do wyszukiwania kont i kontaktów, narzędzia do planowania terminów, systemy obsługi zamówień lub logistyki do sprawdzania statusu oraz procesory płatności do wystawiania rachunków. Agent kliniki potrzebuje narzędzia do planowania terminów, a agent sklepu – API do obsługi zamówień. Systemy się różnią, ale mechanizm jest zawsze taki sam: model wtrąca się w trakcie rozmowy, czeka i wykorzystuje uzyskaną odpowiedź w następnym zdaniu.

Jak działa połączenie. Napędza je wywoływanie funkcji, ten sam mechanizm opisany dla warstwy LLM. Gdy model decyduje, że potrzebuje danych z zewnątrz, wysyła strukturyzowaną prośbę i zatrzymuje się. Wynik nie wraca sam. Twój własny kod musi go przechwycić i dodać do historii rozmowy, zanim model będzie mógł go wykorzystać. Bez tego kroku agent utyka w trakcie połączenia, nie mając nic do powiedzenia.

Gdzie występują problemy. Najwięcej kłopotów powodują dwa aspekty. Powolna API bezpośrednio przyczynia się do opóźnienia, a osoba wywołująca nie może stwierdzić, czy model się zastanawia, czy CRM potrzebuje 800 ms na odpowiedź. Pauza to po prostu pauza. Drugim problemem jest obsługa błędów. Gdy wyszukiwanie wygaśnie, agent potrzebuje przygotowanej frazy do wypowiedzenia, a nie ciszy ani pętli powtarzanych zdań.

Autoryzacja. Dane uwierzytelniające to zazwyczaj klucze API lub tokeny OAuth z ograniczeniami do tylko odczytu lub ograniczonego dostępu do zapisu. Sprawdzanie statusu zamówienia wymaga jedynie możliwości odczytu. Przerysowywanie umów wymaga dostępu do kalendarza, co zwiększa trudność w radzeniu sobie z błędami, ponieważ błędna operacja może zmienić aktualne dane.

Zmniejszanie opóźnień

Trzy elementy odgrywają kluczową rolę: transmisja zarówno tekstu mówionego do pisanego, jak i pisanego do mówionego bez czekania na pełne wyniki, przechowywanie w pamięci cache odpowiedzi na często zadawane pytania oraz umieszczanie wszystkich komponentów w tej samej lokalizacji. W połączeniu pozwalają one zmniejszyć odczuwalne opóźnienie o około 40%, a docelowy czas przetwarzania od początku do końca powinien wynosić mniej niż sekundę.

Przyczyny opóźnień

Każdy komponent dodaje swój własny czas przetwarzania. Przetwarzanie tekstu mówionego w trybie strumieniowym zajmuje od 50 do 150 ms, inferencja modeli językowych dodatkowo od 200 do 500 ms w zależności od modelu i długości promptu, a pierwszy bajt generowanego dźwięku wymaga kolejnych 100 do 200 ms, przy czym na każdym etapie dochodzi jeszcze czas przesyłania danych przez sieć. Proces, który jest średni na każdym poziomie, zajmuje około 1,5 sekundy przed jakąkolwiek optymalizacją. Wywołania funkcji pogarszają sytuację, ponieważ przetwarzanie jest całkowicie wstrzymywane do chwili, aż narzędzie zwróci wynik, co dodaje od 300 do 800 ms.

Co z tym zrobić

Największy wpływ ma tryb strumieniowy. Uruchamiaj przetwarzanie tekstu mówionego w tym trybie, aby transkrypcja rozpoczynała się przed zakończeniem mówienia użytkownika, oraz używaj strumieniowego generowania dźwięku, aby audio było odtwarzane przed pełnym napisaniem odpowiedzi. Same te dwie zmiany przynoszą 40% oszczędności czasu.

Kasowanie z pamięci podręcznej również pomaga. Jeśli większość dzwoniących zadaje te same trzy pytania, wygeneruj odpowiedzi z góry i udostępnij je natychmiast. Ponadto trzymaj komponenty razem pod względem geograficznym. Rozdzielenie usługi STT w regionie US-East od modelu LLM w regionie EU-West powoduje 80 do 120 ms dodatkowego czasu przesyłania danych w sieci przy każdej transakcji.

Aby uzyskać jak najniższy czas reakcji, rozwiązania typu speech-to-speech w wersji natywnej redukują całkowity czas oczekiwania do 200–300 ms. Korzyści są istotne, szczególnie tam, gdzie szybkość rozmowy ma kluczowe znaczenie.

Rozpoznawanie przerw

System rozpoznawania przerw słucha dźwięku dzwoniącego podczas odtwarzania TTS, przerywa odpowiedź w połowie zdania i natychmiast kieruje rozmowę w inny sposób. Zarówno Retell AI, jak i Vapi obsługują to w wersji natywnej. Ustaw odpowiedni próg dźwiękowy, aby hałasy tła nie powodowały fałszywych przerw.

Gdzie to wdrożyć

Wybór sposobu wdrożenia wpływa na koszty, zgodność z regulacjami, opóźnienia oraz stopień kontroli nad infrastrukturą, a jego znaczenie jest większe, niż zdają sobie sprawę większość zespołów, dopóki nie znajdą się już w środowisku produkcyjnym.

Chmura jest standardem. AWS, Azure i GCP oferują zarządzane usługi dla każdego komponentu procesu, charakteryzujące się szybkim ustawieniem, automatycznym skalowaniem i brakiem konieczności posiadania sprzętu. Wadą jest to, że dane opuszczają twoje środowisko, co ma znaczenie w branżach podlegających regulacjom.

W środowisku lokalnym oznacza to, że audio, transkrypcje oraz dane klientów nigdy nie opuszczają twoich serwerów. Branże takie jak ochrona zdrowia, finanse oraz wszystkie kraje z regulacjami dotyczącymi lokalizacji danych często wymagają dokładnie tego rozwiązania. Narzędzia open-source, takie jak Whisper, oraz samodzielnie hostowane modele LLM, umożliwiają realizację tego bez konieczności odbudowywania każdej warstwy.

Hybrydowa implementacja dzieli proces na części w zależności od stopnia wrażliwości każdej z nich. Telefonia i konwersja mowy na tekst pozostają lokalnie, dzięki czemu surowy dźwięk nigdy nie opuszcza lokalizacji, inferencja modeli językowych odbywa się w zarządzanym chmurze, a konwersja tekstu na mowę jest realizowana tam, gdzie opóźnienie jest najmniejsze. Przedsiębiorstwa często wybierają tę opcję, ponieważ osoby sprawdzające zgodność mogą oddzielnie zatwierdzić sposób przetwarzania danych w każdej warstwie.

Zgodność

• W sektorze opieki zdrowotnej w USA HIPAA wymaga podpisanych umów z dostawcami, szyfrowania dźwięku w stanie spoczynku oraz rejestracji dostępów.
• GDPR obejmuje wszystkie procesy dotyczące mieszkańców UE, wymagając wyraźnych powiadomień o zgodzie w przypadku nagrywanych rozmów.
• Regulacje dotyczące lokalizacji danych w ZEA, Arabii Saudyjskiej i Niemczech ograniczają miejsca przechowywania danych rozmów, dlatego przed wdrożeniem należy sprawdzić każdego dostawcę pod kątem tych wymogów.

Mas skalowania

Rozwiązania chmurowe skalują się horyzontalnie, natomiast instalacje lokalne wymagają planowania mocy przerobowej z wyprzedzeniem na okresy oczekiwanych szczytów. Przed wdrożeniem przeprowadź testy przy objętości trzy do pięciu razy większej od przewidywanego szczytu.

Monitorowanie

Cztery aspekty wymagają ciągłej uwagi: szybkość zakończenia połączeń i przenoszenia danych, opóźnienia na poziomie poszczególnych komponentów w procesach STT, LLM i TTS, nieudane wywołania narzędzi oraz nieobsłużone intencje wraz z transkrypcjami przechowywanymi do ponownego odtworzenia.

Jeśli szybkość przenoszenia danych gwałtownie rośnie, oznacza to błąd w projekcie rozmowy. Jeśli czas reakcji modelu LLM stale rośnie, należy sprawdzić, czy prompt nie stał się zbyt długi lub czy wywołanie narzędzia utknęło w oczekiwaniu. LangSmith zajmuje się monitorowalnością modeli LLM, natomiast Datadog lub Grafana obsługują infrastrukturę.

Testowanie i ocena

Większość problemów można wykryć przed wdrożeniem, jeśli przetestuje się odpowiednie elementy.

1. Zacznij od scenariuszy zapisanych dla 20 do 30 kluczowych ścieżek połączeń.
2. Przejdź do testowania adwersarialnego: przerywaj działanie agenta, dostarczaj mu niekompletne informacje i zadawaj pytania wykraczające poza jego zakres.
3. Obserwuj błędy, które są istotne – mianowicie pewne błędne odpowiedzi, przekazy danych, które nigdy się nie uruchamiają, oraz wywołania narzędzi, które pozostawiają sytuację bez reakcji.
4. Wykorzystaj narzędzia takie jak Hamming lub zestaw narzędzi oceniających Vapi do programowego symulowania setek scenariuszy.

Najważniejsze są cztery wskaźniki: stopa ukończenia zadań, stopa kontroli sytuacji, CSAT oraz średni czas obsługi. Śledź je od pierwszego dnia. Komponenty, które radzą sobie przy 10 jednoczesnych wywołaniach, często zawodzą przy 100, stąd konieczność testów obciążeniowych trzy do pięć razy intensywniejszych. Po uruchomieniu sprawdzaj transkrypcje co tydzień i wykorzystuj je do udoskonalania instrukcji, precyzyjniejszego definiowania funkcji oraz rozszerzania mechanizmów awaryjnych. Agenci, które rozwijają się najszybciej, mają za sobą ustrukturyzowaną rutynę przeglądów.

Dziesięć lekcji z rzeczywistych wdrożeń

Rozwijający, którzy po raz pierwszy pracują z asystentami głosowymi, zazwyczaj wychodzą z jednego założenia: wybrać dobry model, napisać solidny prompt i uruchomić system. Sześć tygodni później próbują rozwiązać problemy z przerwanymi połączeniami i gwałtownymi skokami opóźnień, zdziwieni tym, że asystent z całą pewnością siebie podaje wymyślone fakty. To właśnie z takich błędów zespoły uczą się na własnych błędach.

1. Lepszy transport niż wybór modelu. Zastąpienie WebSockets protokołem UDP może przynieść większą korzyść niż zmiana modelu LLM. Większość modeli funkcjonuje dobrze przy przyzwoitym promptzie, natomiast opóźnienia i infrastruktura w ogóle nie reagują na prompty.
2. Jeden asystent, jedno zadanie. Dla kilku różnych zadań należy użyć kilku asystentów, którzy mogą ze sobą komunikować się. Jeden asystent, który ma zajmować się wszystkim, sprawdza się słabo.
3. Wywoływanie funkcji blokuje transmisję strumieniową. Nic nie jest transmitowane, dopóki wywołanie narzędzia nie zostanie zakończone. Należy projektować przepływ rozmowy wokół tej luki, a nie wbrew niej.
4. Długie okna kontekstu wprowadzają w błąd. Wypełnianie promptu do pełna to zakład, który zazwyczaj przegrywa, ponieważ im więcej kontekstu, tym bardziej model odbiega od właściwego toru. Podawaj tylko to, co jest konieczne.
5. RAG daje moc, ale wymaga utrzymania. Zapewnia pipeline danych, który należy do ciebie, który trzeba odświeżać i utrzymywać w aktualności, więc należy uczciwie ocenić ten koszt.
6. API w czasie rzeczywistym przewyższają statyczne mechanizmy pobierania danych dla danych w czasie rzeczywistym. Jeśli ważna jest świeżość, bezpośrednie zapytanie do źródła daje lepsze wyniki niż mechanizm pobierania danych oparty na wczorajszym zapisie.
7. Wyniki narzędzi wymagają ponownego promptowania. Model nie widzi wyniku narzędzia, dopóki nie zostanie on dodany do historii i odesłany z powrotem. Jeśli o tym zapomnisz, agent będzie odpowiadał w próżnię.
8. Prompty to część architektury. Testuj je i wprowadzaj poprawki w taki sam sposób, jak robisz to z kodem, ponieważ zawierają one podstawową logikę agenta.
9. Audio i transkrypcje się różnią. To, co usłyszał dzwoniący, i to, co zostało zapisane, nie zawsze się pokrywają, dlatego kontrola jakości nie może polegać wyłącznie na dokładności transkrypcji.
10. Infrastruktura głosowa to nie infrastruktura tekstowa. Wnioski z skalowania w obszarze tekstu nie mają zastosowania tutaj. Głos ma specyficzne profile opóźnień, zachowanie połączeń i sposoby awarii, więc trzeba zacząć od nowa.

Jakie to kosztuje

Realizacja tego wewnętrznie kosztuje około 8 500 dolarów przy najprostszym przykładzie funkcjonalnym, przy czym koszt zmienia się w zależności od objętości i funkcji, a system klasy korporacyjnej kosztuje 100 000 dolarów lub więcej, plus trzy do sześciu miesięcy pracy inżynierów przed uruchomieniem. To jeszcze przed pracami związanymi z spełnieniem wymogów prawa oraz rocznymi kosztami operacyjnymi w wysokości 15–20%, które zwykle pojawiają się po wdrożeniu w produkcji.

| Tier                              | Upfront Cost | Timeline    | Key Features                                               |
|-----------------------------------|--------------|-------------|------------------------------------------------------------|
| MVP/Proof of Concept              | $8K-$30K     | 4-10 weeks  | Basic voice flows, single integrations, RAG memory         |
| Mid-Tier (CRM/multi-intent)       | $25K-$150K   | 2-6 months  | Contextual reasoning, telephony (Twilio), analytics        |
| Enterprise (autonomous, compliant)| $150K-$300K+ | 4-12 months | Multi-agent orchestration, multilingual, deep ERP/CRM,     |
|                                   |              |             | HITL governance                                            |

Sama zespół, składający się z inżynierów AI, programistów backendowych, specjalistów DevOps i QA, kosztuje 150 000 dolarów lub więcej rocznie, a ten zespół poświęca swój czas na infrastrukturę, a nie na podstawową działalność biznesową.

Minimalna architektura funkcjonalna

Najpierw muszą istnieć sześć komponentów:

• Dostęp audio. Twilio lub WebRTC przekazują głos dzwoniącego do systemu.
• Strumieniowe transkrybowanie mowy. Deepgram Nova-3 transkrybuje na żywo, gdy dzwoniący jeszcze mówi.
• Model z krótkim promptem. GPT-5 lub Claude Sonnet – prompt systemu musi mieć mniej niż 500 tokenów, ponieważ dłuższe prompty spowalniają odpowiedzi.
• Strumieniowe generowanie mowy. Cartesia lub ElevenLabs zaczynają odtwarzanie, zanim zostanie napisana cała odpowiedź.
• Rejestracja. Od pierwszego dnia należy przechowywać transkrypcje i nagrania audio z każdej warstwy.
• Plan awaryjny i przekazanie zadania. Ustaw zasadę przekierowania dla sytuacji, których agent nie może rozwiązać.

Częste pytania

Czy możliwe jest przechowywanie danych klientów z dala od osób trzecich? Tak, dzięki hostowaniu lokalnemu lub hybrydowemu. Zachowaj telefonię i konwersję mowy na własnej infrastrukturze, aby surowy dźwięk pozostał zabezpieczony, a inferencję modeli LLM uruchamiaj w zarządzanym chmurze, jeśli wymogi prawne to pozwalają.

Czy sztuczna inteligencja głosowa może obsługiwać połączenia telefoniczne i SMS-y w tej samej aplikacji? Tak. Zarówno warstwa telefoniczna, jak i warstwa orkiestracji modeli LLM działają w różnych kanałach, więc proces obsługi połączenia telefonicznego może kierować rozmowę SMS przez ten sam model i logikę wywoływania funkcji.

Jak naprawić złą intonację i tempo mowy? Prozodia oraz tempo pochodzą od modelu TTS, a nie od scenariusza. Zarówno Cartesia, jak i ElevenLabs domyślnie dobrze radzą sobie z naturalnymi wzniesieniami i opadami tonu. Jeśli mowa nadal brzmi płasko, rozwiązaniem jest zazwyczaj inny model głosu, a nie inny prompt.

Jak dodać sztuczną inteligencję głosową do istniejącego systemu telefonicznego bez zmiany numerów? Przenieś numer do trunku SIP za pośrednictwem dostawcy usług telefonicznych, a następnie kieruj przychodzący dźwięk z tego trunku do warstwy STT. Dzwoniący wybierają ten sam numer co wcześniej, zmienia się jedynie ścieżka przekierowania połączenia.

Jak uniknąć uwięzienia u dostawcy? Wykorzystaj architekturę kaskadową. Każdy komponent działa niezależnie, więc Deepgram można zastąpić AssemblyAI, a Cartesia – ElevenLabs, bez konieczności przepisywania reszty systemu. Zarówno półkaskadowa, jak i natywna architektura przekładu mowy na mowę poświęcają tę elastyczność w zamian za niższą opóźnioność.