Modele kaskadowe vs. fuzjowane: Jak architektura wpływa na gotowość twojego agenta głosowego do pracy w firmie

ElevenAgents napędza silnik orkiestracji o niskich opóźnieniach, stworzony specjalnie do rozmów w czasie rzeczywistym i dodający mniej niż 100 ms opóźnienia. Ta architektura łączy nasze badania z najnowszymi LLM-ami od liderów takich jak OpenAI, Google czy Anthropic oraz wybrane modele open-source hostowane przez ElevenLabs. Dzięki użyciu kilku modeli na różnych etapach generowania odpowiedzi agent zapewnia szybkie i trafne rozmowy z zachowaniem kontekstu. Dynamicznie wykorzystując mocne strony każdego modelu, osiągamy niezawodność i skalowalność w różnych zadaniach i scenariuszach, optymalizując równowagę między inteligencją, szybkością i kosztami.

Architektura agenta decyduje o tym, czy będzie działał niezawodnie, dostosuje się do wymagań firmy i zabrzmi naturalnie w rozmowie. Architektura oparta na fuzji, jak model Realtime od OpenAI, może brzmieć bardzo realistycznie w krótkich wymianach. Ale jeśli zespół musi zadbać o zgodność z przepisami, znaleźć przyczynę błędu lub podmienić LLM na lepszy, gdy taki się pojawi, pojedyncza sieć fuzjowana nie daje na to dużych szans.

W ElevenLabs korzystamy z zaawansowanej architektury kaskadowej. Wykorzystujemy wyspecjalizowane komponenty do rozpoznawania mowy, rozumowania i generowania mowy, żeby zapewnić wysoki poziom inteligencji i niezawodności. Dodajemy kontekstową prozodię, optymalizację pod kątem niskich opóźnień i inteligentne zarządzanie kolejnością wypowiedzi, żeby rozmowy brzmiały naturalnie. Zbudowaliśmy to tak, bo firmy i instytucje, z którymi współpracujemy, potrzebują agentów, którzy brzmią realistycznie i którym można zaufać przy złożonych zadaniach.

W tym artykule omawiamy pięć głównych architektur, ich mocne strony, ograniczenia i nasze podejście do budowania agentów do kluczowych zastosowań.narzędzi i bazy wiedzy. Warto wybrać niezależnych agentów zamiast workflow, gdy nie trzeba pilnować ścisłej kolejności kroków lub gdy ważne jest unikanie silosów wiedzy między agentami. Silosy powstają, gdy niektóre narzędzia, dokumenty lub kontekst historyczny są dostępne tylko dla części subagentów. To naturalne w workflow z wieloma agentami i oznacza kompromis między elastycznością a przewidywalnością.

Na co zespoły zwracają uwagę przy wyborze architektury

• Tworzą skuteczne zapytania do generowania odpowiedzi
• Wyszukują i wykorzystują odpowiednie dokumenty
• Generują i wykonują wywołania narzędzi, by wzbogacić odpowiedzi
• Zwracają wyniki do oceny i analizy

Czy poradzi sobie ze złożonymi zadaniami? 

Zespoły zwracają też uwagę na takie rzeczy jak równoczesność, integracje czy jakość głosu, ale to architektura agenta najbardziej wpływa na powyższe aspekty. Najlepsze zespoły dopasowują architekturę do swojego zastosowania, by zoptymalizować te elementy.

Architektury kaskadowe składają się z połączonych wyspecjalizowanych komponentów: , dużego modelu językowego oraz Text to Speech. Każdy etap można osobno optymalizować, testować i aktualizować.poprzednim wpisie. Dzięki temu agent skutecznie znajduje dokumenty nawet wtedy, gdy ostatnia wypowiedź użytkownika to np. dopytanie, potwierdzenie lub nie zawiera wyraźnego pytania.

Czy mogę mu zaufać w produkcji?

Dzięki tej modułowości można podłączyć najnowsze LLM-y do lepszego rozumowania, stosować zabezpieczenia na poziomie tekstu i precyzyjnie kontrolować sposób mówienia agenta przez kontekstowy TTS. Główny kompromis to utrata części prozodii – intonacji, rytmu, emocji – bo mowa jest zamieniana na tekst, a potem generowana od nowa. Część tych cech można odzyskać przez dodatkowe modelowanie, ale nie są one tak naturalne jak w podejściu fuzjowanym. Inne aspekty, jak opóźnienie czy zmiana głosu, można zwykle zoptymalizować do podobnego poziomu w obu podejściach.

Kompromisy między architekturą kaskadową a fuzjowaną Im więcej narzędzi, tym większe wyzwanie dla modelu, by wybrać właściwą sekwencję. W Agent Builder opis narzędzia wyjaśnia, do czego służy i jakie pola zwraca. To na tej podstawie model rozumie kontekst użycia. Warunki wywołania narzędzia powinny być już w systemowym promptcie agenta. Przykład:

• Opis narzędzia dla lookup_order: „Pobiera szczegóły zamówienia klienta na podstawie ID. Zwraca status zamówienia, kupione produkty, adres wysyłki i numer śledzenia.”
• Speech to Text„Po potwierdzeniu tożsamości klienta wywołaj narzędzie lookup_order, by pobrać szczegóły zamówienia.”

Dzięki temu architektury fuzjowane lepiej zachowują i odtwarzają prozodię, bo model przetwarza wymowę i intonację bezpośrednio. Jednak trudniej je testować i kontrolować, bo nie ma dostępu do wyników pośrednich. Zwykle korzystają też z lżejszych LLM-ów, co ogranicza rozumowanie i korzystanie z narzędzi w porównaniu do kaskadowych podejść, gdzie można użyć najmocniejszych dostępnych modeli.Przewodniku po promptowaniu. W tym systemie można zdefiniować różne typy narzędzi, m.in.:

• Webhooki wywołujące zewnętrzne API.
• Narzędzia klienckie, które wysyłają żądania jako zdarzenia przez websocket rozmowy.
• Narzędzia systemowe do wbudowanych akcji, np. przekierowania połączenia.
• Narzędzia MCP łączące się z serwerami Model Context Protocol.

Od lat zarzuca się architekturom kaskadowym, że tracą wskazówki prozodyczne. Mowa zamienia się w tekst, a intonację, rytm i emocje trzeba odtworzyć na wyjściu. Da się to częściowo odzyskać przez modelowanie, ale nie jest to tak naturalne jak w podejściu fuzjowanym. Inne aspekty, jak opóźnienie czy zmiana kolejności wypowiedzi, można zwykle zoptymalizować do podobnego poziomu w obu podejściach.zmienną dynamiczną. Te dane są przechowywane jako proste pary klucz-wartość, wyciągane z odpowiedzi narzędzia według ustalonych mapowań. Po ustawieniu zmienne mogą być użyte w systemowym promptcie, parametrach narzędzi i warunkach workflow. Dzięki temu agent zyskuje coś w rodzaju pamięci roboczej, która zmienia się w trakcie rozmowy.

1. Podstawowa kaskadowa

Architektury fuzjowane działają zupełnie inaczej. Rozpoznawanie, rozumowanie i generowanie odbywa się w jednej sieci multimodalnej. Audio wchodzi, audio wychodzi – bez żadnej warstwy pośredniej.

Brak etapów pośrednich to zarówno zaleta, jak i ograniczenie. Architektura fuzjowana naturalnie zachowuje wskazówki prozodyczne, bo mowa nie jest zamieniana na tekst. Ale trudno tu wdrożyć zabezpieczenia, wymieniać komponenty czy sprawdzać wyniki pośrednie przy debugowaniu. Nie da się też łatwo dostroić STT do branżowej terminologii ani podmienić LLM na mocniejszy do lepszego rozumowania czy obsługi narzędzi. System to jedna sieć i zespół jest ograniczony do tego, co oferuje – a to zwykle lżejsze modele, które nie dorównują czołowym LLM-om przy złożonych zadaniach.

Pięć architekturZbieranie danych i Kryteria oceny. Zbieranie danych pozwala wyciągnąć uporządkowane informacje z transkrypcji rozmowy do dalszej analizy. Klienci często eksportują te dane do własnych hurtowni na potrzeby raportów lub workflow. Przykładowo agent sprzedażowy może automatycznie wyciągnąć dane potencjalnego klienta i utworzyć lub zaktualizować lead w CRM. Z kolei kryteria oceny określają, czy rozmowa była udana. Jeśli wszystkie kryteria są spełnione, rozmowa jest oznaczona jako udana; w przeciwnym razie jako nieudana. Dzięki temu rozmowy zawsze spełniają ustalone standardy jakości i spójności, a feedback jest szybki. Po zakończeniu rozmowy i wywołaniu webhooka agent przetwarza finalną transkrypcję (wraz z wykonaniami narzędzi i metadanymi) przez LLM razem ze wszystkimi punktami zbierania danych i kryteriami oceny. Model na tej podstawie sprawdza, czy każde kryterium jest spełnione i wyciąga wskazane dane do dalszej analizy. Ponieważ LLM interpretuje te ustawienia bezpośrednio z promptu, ważne jest, by były jasne i spójne – wtedy model dobrze je zrozumie i zastosuje. Dlatego polecamy te praktyki przy pisaniu kryteriów oceny i opisów zbierania danych.

1. Kaskadowa podstawowa

1. Obsługa klienta jedno zdanie lub krótki punkt jest lepszy niż kilka celów w jednym kryterium.
2. Asystenci sprzedaży sformułuj cel tak, by dało się go ocenić na podstawie transkrypcji (co zostało powiedziane, co zrobił agent, o co pytał użytkownik). Unikaj celów wymagających zewnętrznego kontekstu, którego LLM nie ma.
3. AI recepcjoniści LLM wie, że jeśli cel jest spełniony – oznacza sukces, jeśli nie – porażkę, a jeśli nie da się ocenić – nieznane. Cel powinien być więc napisany tak, by „spełnione” i „niespełnione” były jednoznaczne; jeśli jest niejasny, model może częściej wybierać „nieznane” lub błędnie klasyfikować.
4. NPC w grach i rozrywce czasem wysyłanych jest wiele kryteriów naraz. Długie kryteria mogą wprowadzać szum i powodować halucynacje.
5. Zamienniki IVR każda uzasadnienie LLM, czy kryterium zostało spełnione, będzie w tym samym języku, co opis kryterium – warto o tym pamiętać.

Audio jest transkrybowane, LLM generuje odpowiedź tekstową, a TTS ją odczytuje. Każdy etap działa na czystym tekście, więc wszystko można zobaczyć, przetestować i kontrolować.

1. Opisz dokładnie, co wyciągnąć: opis to główny sygnał dla LLM. Wyjaśnij, co oznacza pole, kiedy je ustawić i co zrobić, gdy nie wiadomo (np. „Zostaw puste, jeśli klient nie podał preferowanej daty”).
2. Dopasuj typ danych: wartość zwracana przez LLM zawsze będzie zgodna z typem przypisanym do punktu zbierania danych (np. boolean, string, integer). Opis powinien to odzwierciedlać. Przykład: „Podaj liczbę zamówionych sztuk” dla integer, „Tak/nie, czy klient zgodził się na ofertę” dla boolean.
3. Używaj enum, jeśli się da: dla typu string, jeśli wartości są z góry ustalone, użyj enum w schemacie – to ogranicza model i zmniejsza liczbę błędnych odpowiedzi.
4. Jedno pole na jeden cel: Nie łącz kilku niezwiązanych faktów w jednym opisie; rozbij na osobne pola, by każde miało jeden, jasny cel.
5. Opis krótki: Opis może mieć kilka zdań – nie musi być długi. Transkrypcja i tak jest w wiadomości użytkownika, więc schemat + krótki opis wystarczy.

Przykładowe zastosowania:

Tak działa

2. Kaskadowa zaawansowana

Obsługi klienta to wizualny interfejs do projektowania złożonych ścieżek rozmów. Tworzy logiczny obiekt, którym orkiestrator zarządza wieloma subagentami, narzędziami i przekierowaniami pod jednym identyfikatorem agenta. Workflows wprowadzają dodatkowe elementy, o których trzeba pamiętać poza tymi z niezależnych agentów, m.in. jak:

• Systemowe prompty i cele rozmów subagentów współdziałają.
• Tryb ekspresyjny

LLM instruuje TTS nie tylko co powiedzieć, ale jak – np. "uspokajająco", "z naciskiem", "z pilnością", dynamicznie zmieniając ton w trakcie rozmowy. System zmiany kolejności wypowiedzi korzysta z tych samych sygnałów, dzięki czemu agent wie, kiedy odpowiedzieć, a kiedy oddać głos. Modele mowy są w jednej warstwie, bez opóźnień między komponentami, więc całość działa szybko.

Architektura zachowuje wszystko z podstawowej kaskady: pełną przejrzystość, zabezpieczenia na poziomie tekstu, możliwość wymiany komponentów, dostrajanie do branży i dostęp do najmocniejszych modeli rozumowania i obsługi narzędzi. Dodatkowo daje lepszą prozodię, niższe opóźnienia i płynniejszą zmianę kolejności wypowiedzi. Zespół może wdrożyć nowy LLM od razu po premierze albo dostroić STT do słownictwa medycznego bez przebudowy reszty.

Na tej bazie Workflows wprowadzają wyspecjalizowane subagenty działające w grafie skierowanym. Każdy subagent ma wąsko określony cel i rozszerza bazową konfigurację o dodatkowe instrukcje, narzędzia i źródła wiedzy potrzebne tylko w swojej roli. Zamiast definiować całą rozmowę od nowa, subagenty nakładają swój cel na bazowego agenta przez kompozycję promptu i selektywne rozszerzanie kontekstu. Historia rozmowy jest zachowana przy przejściach między subagentami, by utrzymać ciągłość, ale każdy subagent działa z celowo ograniczonym widokiem systemu. Bazy wiedzy i narzędzia są udostępniane wybiórczo, tworząc wyraźne silosy i zapobiegając mieszaniu się odpowiedzialności. By to wzmocnić, obiekt orkiestratora jest przebudowywany przy każdym przejściu, jakby to był niezależny agent. Dzięki temu prompt, konfiguracja i możliwości aktywnego subagenta są w pełni przewidywalne. Takie podejście pozwala Workflows zachować globalną spójność przy jednoczesnej lokalnej specjalizacji – daje przewidywalność, jasny podział ról i precyzyjną kontrolę nad kontekstem, wiedzą i akcjami na każdym etapie rozmowy.

3. Hybryda kaskadowa i fuzjowana

Sterowanie przejściami workflow przez warunki LLM

Niektóre architektury przekazują cechy akustyczne (wymowa, emocje, ton) z mowy bezpośrednio do LLM jako embeddingi, zamiast najpierw zamieniać je na tekst. TTS pozostaje modułowy.

Dzięki temu LLM dostaje więcej informacji o

Przykładowe zastosowania:

Zabezpieczenia i bezpieczeństwo

4. Fuzjowana sekwencyjna

Guardrails

Jeden model multimodalny obsługuje rozpoznawanie, rozumowanie i generowanie w jednym przebiegu, po jednej turze. Tak działa np. model Realtime API od OpenAI.

Prozodia może być bardzo dobra. Ponieważ mowa nie jest zamieniana na tekst, model naturalnie zachowuje tempo, intonację i emocje. Krótkie rozmowy brzmią bardzo płynnie.

Ale trudno tu wdrożyć zabezpieczenia bez warstwy tekstu, brakuje wyników pośrednich do debugowania i nie da się łatwo wymienić LLM ani dostroić STT do branży. Rdzenie rozumowania są zwykle lżejsze niż czołowe LLM-y, więc złożone zadania i obsługa narzędzi wypadają słabiej. Gdy zadanie wymaga rozwiązania trudnego problemu, sama prozodia nie wystarczy.

Przykładowe zastosowania:

Nie ma jednej uniwersalnej architektury dla agentów konwersacyjnych. Każda ma swoje mocne strony i kompromisy – od przewidywalności i kontroli modeli kaskadowych po naturalną prozodię modeli fuzjowanych.

5. Fuzjowana dupleksowa

Nasz zespół Forward Deployed Engineering ściśle współpracuje z klientami, by te możliwości rozwijały się razem z realnymi wdrożeniami. Kolejna generacja agentów zapewni jeszcze większą przejrzystość, przewidywalność i elastyczność bez utraty niskich opóźnień, które umożliwiają rozmowy w czasie rzeczywistym.