Modele kaskadowe vs fuzjowane: Porównanie architektur agentów konwersacyjnych

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 wpływa na to, jak naturalnie, inteligentnie i spójnie odpowiada oraz czy zachowuje się przewidywalnie w dłuższym czasie. Na przykład agent oparty na architekturze fuzjowanej może brzmieć bardzo naturalnie w krótkich rozmowach, ale mieć trudności z rozumowaniem lub spójnością w dłuższych wymianach.

W ElevenLabs korzystamy z architektury kaskadowej, która łączy wyspecjalizowane moduły do rozpoznawania mowy, rozumowania i generowania mowy. Dla porównania, model Realtime od OpenAI stosuje podejście fuzjowane, łącząc te etapy w jednej sieci.

W tym wpisie omawiamy pięć głównych architektur agentów konwersacyjnych, które dziś spotykamy – pokazujemy ich główne założenia, kompromisy i to, jak zespoły wybierają między nimi w zależności od celu.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 czym zespoły skupiają się, budując agentów

• 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

Budowanie kontekstu rozmowy 

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.

Wyszukiwanie to jednak tylko jeden ze sposobów, w jaki agenci korzystają z zewnętrznych systemów.

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.

Z kolei podejścia fuzjowane łączą te etapy w jeden model multimodalny. Dźwięk trafia do modelu i wychodzi z niego, a rozpoznawanie mowy, rozumowanie i generowanie odbywa się w jednej sieci. 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.”
• Instrukcja w systemowym promptcie: „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.

Pięć możliwych architekturzmienną 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

Gdy już mamy wykonanie i orkiestrację, czas na mierzenie skuteczności.

W prostych architekturach kaskadowych dźwięk jest transkrybowany, LLM generuje odpowiedź tekstową, a TTS odczytuje dokładnie te słowa. Ponieważ każdy etap działa na czystym tekście, zespoły mają pełną kontrolę i wgląd. Zabezpieczenia można stosować na poziomie tekstu, wywołania narzędzi i integracje API obsługuje bezpośrednio LLM, a przewidywalne ścieżki pozwalają lepiej zarządzać rozmową i logiką biznesową.

Agent nie rozpoznaje jednak niuansów mowy, takich jak ton, rytm czy emocje, co może sprawiać, że rozmowa brzmi mniej naturalnie.Zbieranie 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.

Możliwe zastosowania:

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ć.

2. Zaawansowana kaskadowa

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.

Zaawansowane architektury kaskadowe wprowadzają kontekstowy TTS – LLM decyduje nie tylko co powiedzieć, ale i jak, przekazując instrukcje typu „powiedz to uspokajająco” lub „odpowiedz z naciskiem” do modelu TTS. Agent mówi bardziej realistycznym tonem i stylem, zachowując jednocześnie te same zabezpieczenia, przewidywalność, korzystanie z narzędzi i możliwość audytu co prosty system kaskadowy.

Tak działa

Możliwe zastosowania to bardziej ekspresyjne wersje:

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ą.
• Przechodzenie przez różne punkty przejścia w grafie jest ustalane.

Specjalistyczne cele rozmów

Niektóre architektury kaskadowe przekazują cechy akustyczne (np. wymowę, emocje, ton) z wejściowej mowy bezpośrednio do LLM jako embeddingi. Dzięki temu agent lepiej zachowuje intencje użytkownika, a TTS pozostaje modułowy. Nadal można korzystać z narzędzi i zabezpieczeń, ale blok ASR+LLM jest trudniejszy do audytu niż czysty tekst, a wymiana LLM nie jest już tak prosta jak w modelu kaskadowym.

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.

4. Fuzjowana sekwencyjna

Sterowanie przejściami workflow przez warunki LLM

W architekturach fuzjowanych sekwencyjnie jeden model multimodalny obsługuje rozpoznawanie, rozumowanie i generowanie mowy. Działa po jednej wypowiedzi – słucha do końca, a potem od razu generuje dźwięk. Dzięki przetwarzaniu audio end-to-end takie architektury naturalnie wychwytują cechy jak wymowa, tempo czy intonacja, co często daje płynniejszą i bardziej ekspresyjną mowę.

Kompromis to trudniejsze egzekwowanie zabezpieczeń bez warstwy tekstu, ograniczone korzystanie z narzędzi przez lżejsze modele rozumowania i mniejsza możliwość podglądu działania bez wyników pośrednich.

Gdy rozmowa przechodzi do nowego etapu, system aktywuje wersję agenta dostosowaną do tego kroku. Każdy etap działa według własnych instrukcji i ma dostęp tylko do wiedzy i narzędzi potrzebnych do swojej roli. Przykładowo etap obsługi zwrotów może korzystać z polityki zwrotów bez dziedziczenia kontekstu z onboardingu czy triage. Przejścia między etapami są sterowane przez jawne warunki, które decydują, kiedy zmienić odpowiedzialność i pozwalają na naturalne kierowanie rozmową. Dla użytkownika przejścia są płynne – każdy etap dziedziczy odpowiedni kontekst rozmowy, ale nie ujawnia mechaniki przekazania. Dodatkowo zabezpieczenia monitorują przejścia, by uniknąć nieproduktywnych cykli i zapewnić, że workflow jest stabilny i zmierza do celu.

Zabezpieczenia i bezpieczeństwo

5. Fuzjowana dupleksowa

Guardrails

W architekturach fuzjowanych dupleksowo model przetwarza wejście i wyjście jednocześnie. Pozwala to uzyskać najbardziej ludzką płynność rozmowy, z naturalnym nakładaniem się wypowiedzi w krótkich dialogach, ale wprowadza też sporo złożoności. Trudniej egzekwować zabezpieczenia, zakłócenia i przerwania mogą powodować błędy, a wgląd w działanie jest minimalny w porównaniu do architektur kaskadowych.

Zgodne zarządzanie danymi

Czasem rozmówcy mogą przekazać agentowi wrażliwe dane, które podlegają ścisłym wymogom przechowywania i przetwarzania, np. dane medyczne wymagające zgodności z HIPAA. Dla takich przypadków oferujemy tryb Zero Retention Mode (ZRM) na poziomie agenta lub workspace. Po włączeniu wszystkie dane rozmowy są przetwarzane tylko w pamięci i nigdy nie są zapisywane na stałe. Po zakończeniu rozmowy i przetwarzania żadne dane nie są przechowywane przez ElevenLabs. Transkrypcje, nagrania audio i wyniki analizy nie są dostępne w panelu agentów, a zasada ta dotyczy zarówno systemów klienta, jak i naszych logów wewnętrznych. Dane są przetwarzane podczas rozmowy, a skonfigurowane webhooki po rozmowie otrzymają wyniki – klient może więc zapisać transkrypcję lub analizę u siebie, jeśli chce.

Jak wybrać architekturę do swojego 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.

W tym artykule pokazaliśmy, jak agenci ElevenLabs zarządzają kontekstem rozmowy, narzędziami, oceną i workflow, by zapewnić niezawodne doświadczenia w czasie rzeczywistym na dużą skalę. Wraz z wdrażaniem agentów w coraz bardziej złożonych środowiskach stale rozwijamy nasz silnik orkiestracji – od konfigurowalnych modeli oceny i bogatszych warunków przejść po lepszy wgląd w budowę promptów i zużycie tokenów na każdym etapie.

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.