Modelos em Cascata vs. Fundidos: Como a arquitetura define se seu agente de voz está pronto para empresas

ElevenAgents são alimentados por um motor de orquestração de baixa latência, criado especialmente para conversas em tempo real, adicionando menos de 100ms de atraso. Essa arquitetura combina o melhor das pesquisas da ElevenLabs com LLMs de ponta de provedores como OpenAI, Google e Anthropic, além de modelos open-source selecionados e hospedados pela ElevenLabs. Ao usar múltiplos modelos em diferentes etapas do pipeline de respostas, o agente garante conversas altamente responsivas e com entendimento de contexto. Aproveitando dinamicamente os pontos fortes de cada modelo em conjunto, conseguimos desempenho confiável e escalável em várias tarefas empresariais e cenários de conversação, otimizando o equilíbrio entre inteligência, velocidade e custo.

A arquitetura do agente determina sua capacidade de atuar de forma confiável em produção, se adaptar a necessidades específicas do negócio e soar natural nas conversas. Uma arquitetura baseada em fusão, como o modelo Realtime da OpenAI, pode soar muito realista em interações curtas. Mas quando as equipes precisam garantir regras de conformidade, investigar uma resposta com erro ou trocar por um LLM mais avançado quando surgir, uma rede única fundida oferece pouco caminho para isso.

Na ElevenLabs, usamos uma arquitetura avançada baseada em cascata. Aproveitamos componentes especializados para reconhecimento de fala, raciocínio e geração de fala, garantindo altos níveis de inteligência e confiabilidade. Adicionamos prosódia contextual, otimização de baixa latência e alternância inteligente de turnos para que as conversas fluam naturalmente. Construímos assim porque as empresas e governos com quem trabalhamos exigem agentes que soem realistas e sejam confiáveis em produção para tarefas complexas.

Neste artigo, mostramos as cinco principais arquiteturas, seus pontos fortes, limitações e como pensamos a base para agentes usados em fluxos de trabalho críticos.ferramentas e uma base de conhecimento. Clientes devem preferir agentes independentes em vez de workflows quando o caso de uso exige pouca verificação de sequência de etapas ou quando é importante evitar silos de conhecimento entre agentes. Silos de conhecimento surgem quando certas ferramentas, documentos ou contexto histórico estão acessíveis para alguns subagentes, mas não para outros. Isso é inerente a workflows multiagente e traz um equilíbrio entre flexibilidade e determinismo.

O que as equipes avaliam ao escolher uma arquitetura

• Criam solicitações de geração de forma eficiente
• Buscam e incorporam documentos relevantes
• Geram e executam chamadas de ferramentas para informar as respostas do agente
• Entregam resultados para avaliação e coleta de dados

Ele consegue lidar com tarefas complexas? 

Embora fatores como concorrência, integrações e qualidade de voz também sejam importantes, as dimensões acima podem ser mais diretamente influenciadas pela arquitetura do agente. As equipes mais bem-sucedidas adaptam a arquitetura para otimizar esses pontos conforme o uso desejado.

Arquiteturas baseadas em cascata são compostas por componentes especializados conectados em sequência: , um Large Language Model e Transformar Texto em Áudio. Cada etapa pode ser otimizada, testada e atualizada de forma independente.post anterior. Isso permite recuperar documentos de forma confiável mesmo quando a entrada mais recente do usuário é um acompanhamento, um reconhecimento de esclarecimento ou não contém uma pergunta explícita.

Posso confiar nele em produção?

Essa modularidade permite que as equipes usem os LLMs mais avançados para melhorar o raciocínio, apliquem limites claros na camada de texto e controlem com precisão como o agente fala usando TTS contextual. O principal ponto negativo é que arquiteturas em cascata tendem a perder mais informações prosódicas — como entonação, ritmo e emoção — porque a fala é convertida em texto antes de ser gerada novamente. Esses elementos podem ser parcialmente recuperados com modelagem explícita, mas não são capturados de forma tão natural quanto nas abordagens fundidas. Outros aspectos, como latência e turnos de fala, geralmente podem ser otimizados para alcançar desempenhos semelhantes em ambas as abordagens.

Os equilíbrios entre arquiteturas em cascata e fundidas À medida que mais ferramentas são adicionadas, aumenta também a responsabilidade do modelo em escolher a sequência correta de ferramentas. No Agent Builder, a descrição da ferramenta explica o que ela faz e quais campos retorna. É essa informação que o modelo de linguagem usa para entender o contexto do uso. Uma vez definida, as condições específicas para acionar a ferramenta ficam no prompt do sistema do agente. Por exemplo:

• Descrição da ferramenta para lookup_order: “Recupera os detalhes do pedido de um cliente pelo ID do pedido. Retorna status do pedido, itens comprados, endereço de entrega e código de rastreamento.”
• Speech to Text“Após verificar a identidade do cliente, chame a ferramenta lookup_order para buscar os detalhes do pedido.”

Esse design permite que arquiteturas baseadas em fusão preservem e reproduzam a prosódia de forma mais eficaz, já que o modelo processa pronúncia e entonação diretamente. Porém, modelos fundidos são mais difíceis de testar e controlar, pois não expõem saídas intermediárias. Eles também costumam usar LLMs mais leves, o que limita o raciocínio e o uso de ferramentas em comparação com abordagens em cascata que podem usar os modelos mais avançados disponíveis.Guia de Prompt. Dentro desse framework, vários tipos de ferramentas podem ser definidos, principalmente:

• Ferramentas webhook que chamam APIs externas.
• Ferramentas client que enviam solicitações como eventos pelo websocket da conversa.
• Ferramentas de sistema para ações internas, como transferências de chamadas.
• Ferramentas MCP que conectam a servidores Model Context Protocol.

A crítica mais comum às arquiteturas em cascata é que elas perdem pistas prosódicas. A fala é reduzida a texto, e a entonação, ritmo e emoção precisam ser reconstruídos na saída. Essas pistas podem ser parcialmente recuperadas com modelagem explícita, mas não são capturadas de forma tão natural quanto nas abordagens fundidas. Outros aspectos, como latência e alternância de turnos, normalmente podem ser otimizados para níveis semelhantes em ambas as abordagens.variável dinâmica. Essas informações são mantidas como pares chave-valor simples, extraídas da resposta da ferramenta usando mapeamentos pré-definidos. Uma vez definidas, essas variáveis podem ser usadas no prompt do sistema do agente, em parâmetros de ferramentas futuras e em condições de workflow. Esse ciclo de feedback dá aos agentes uma espécie de memória de trabalho que evolui conforme interagem.

1. Cascata Básica

Arquiteturas fundidas seguem um caminho diferente. Reconhecimento, raciocínio e geração acontecem dentro de uma única rede multimodal. O áudio entra e sai, sem camada intermediária para inspeção.

A ausência de etapas intermediárias é tanto o atrativo quanto a limitação. A arquitetura fundida pode preservar pistas prosódicas de forma natural, já que a fala nunca é convertida em texto. Porém, há pouca possibilidade de aplicar regras de segurança, trocar componentes individuais ou inspecionar saídas intermediárias para depuração. Também há limitações para ajustar o STT a termos específicos do setor ou integrar um LLM diferente para raciocínio mais forte e uso de ferramentas. O sistema é uma única rede, e as equipes ficam restritas às capacidades de raciocínio que ela oferece, o que hoje significa núcleos mais leves que não alcançam os LLMs de ponta em tarefas complexas.

As cinco arquiteturasColeta de Dados e os Critérios de Avaliação. A Coleta de Dados permite extrair informações estruturadas da transcrição da chamada para análise e agregação. Os clientes costumam exportar esses dados para o data lakehouse da empresa para relatórios ou enriquecimento de workflows. Por exemplo, um Agent de Vendas pode extrair automaticamente dados de um prospect para criar ou atualizar um lead no sistema de CRM. Já os Critérios de Avaliação determinam se uma chamada é considerada bem-sucedida. Se todos os critérios forem atendidos, a chamada é marcada como sucesso; caso contrário, é sinalizada como falha. Isso garante que as conversas sigam padrões definidos de qualidade e integridade, além de fornecer feedback rápido. Assim que a chamada termina e o webhook pós-chamada é acionado, o agente processa a transcrição finalizada, incluindo execuções de ferramentas e metadados, em um LLM junto com todos os pontos de coleta de dados e critérios de avaliação configurados. O modelo usa esse prompt combinado para determinar se cada critério foi atendido e para extrair os dados especificados para análise. Como o LLM interpreta essas configurações diretamente no prompt de entrada, é importante formatá-las de forma clara e consistente para que o modelo entenda e aplique corretamente. Por isso, recomendamos as seguintes práticas para escrever descrições de Critérios de Avaliação e Coleta de Dados.

1. Cascata Básica

1. Atendimento ao cliente uma frase ou bullet curto é melhor do que vários objetivos em um critério só.
2. Assistentes de vendas formule o objetivo de modo que sucesso/falha possa ser decidido pela transcrição (o que foi dito, o que o agente fez, o que o usuário pediu). Evite objetivos que dependam de contexto externo que o LLM não tem.
3. Recepcionistas com IA o LLM já entende que para marcar como sucesso o objetivo deve ser atingido, como falha se não for, e como desconhecido se não der para saber pela transcrição. Por isso, o objetivo deve ser escrito de forma que “atingido” vs “não atingido” fique bem definido; se for ambíguo, o modelo pode tender para desconhecido ou classificar errado.
4. NPCs para entretenimento e jogos às vezes, muitos critérios de avaliação são enviados juntos. Critérios longos podem gerar ruído e causar alucinações.
5. Substituição de URA qualquer justificativa dada pelo LLM sobre se um critério foi atendido ou não será na mesma língua da descrição do critério, então é importante considerar isso.

O áudio é transcrito, o LLM gera uma resposta em texto e o TTS fala essa resposta. Cada etapa trabalha com texto simples, então você pode ver, testar e controlar tudo.

1. Descreva exatamente o que extrair: a descrição é o principal sinal para o LLM. Explique o que o campo significa, em que situação deve ser preenchido e o que fazer quando não estiver claro (ex: “Deixe nulo se o cliente não informou uma data preferida”).
2. Combine com o tipo esperado: o valor fornecido pelo LLM sempre vai corresponder ao tipo de dado definido para o ponto de coleta (ex: booleano, string, inteiro etc). Então a descrição deve refletir isso. Por exemplo: “Extrair o número de itens solicitados” para inteiro, e “Sim/não se o cliente aceitou a oferta” para booleano.
3. Use enums sempre que possível: para tipo string, se o conjunto de valores for fixo, use enum no schema; isso limita o modelo e reduz saídas inválidas.
4. Um alvo de extração por item: Não coloque vários fatos não relacionados na descrição de um item; divida em itens separados para que cada chamada tenha um alvo de extração claro.
5. Mantenha as descrições curtas: As descrições podem ter algumas frases; não precisa de parágrafos longos. A transcrição já está na mensagem do usuário, então o schema + descrição curta é suficiente.

Exemplos de uso:

Essa é a abordagem usada no

2. Cascata Avançada

Atendimento ao cliente oferecem uma interface visual para criar fluxos de conversa complexos. No final, geram o objeto lógico usado pelo orquestrador para gerenciar múltiplos subagentes, ferramentas e transferências sob um identificador de agente independente. Workflows trazem componentes adicionais além dos já descritos para agentes independentes, incluindo como:

• Prompts de sistema e objetivos de conversa dos subagentes interagem.
• Modo Expressivo

O LLM então instrui o TTS sobre como falar – não só o que dizer – como "de forma tranquilizadora", "com ênfase", "com urgência", adaptando o tom dinamicamente ao longo da conversa. O sistema de alternância de turnos usa os mesmos sinais, permitindo que o agente saiba quando responder ou ceder a vez. Os modelos de fala ficam juntos em uma única pilha, sem saltos de rede entre componentes, mantendo a latência baixa.

A arquitetura mantém tudo da cascata básica: transparência total, regras de segurança na camada de texto, possibilidade de trocar componentes, ajuste para domínio e acesso aos melhores modelos de raciocínio e uso de ferramentas disponíveis. Ela adiciona prosódia, latência e alternância de turnos significativamente melhores. As equipes podem integrar um novo LLM de ponta assim que for lançado ou ajustar o STT para termos médicos, sem precisar refazer outros componentes.

Sobre essa base compartilhada, Workflows introduzem subagentes especializados que atuam em um grafo direcionado. Cada subagente recebe um objetivo bem definido e complementa a configuração base com instruções adicionais de prompt, ferramentas e fontes de conhecimento relevantes apenas para sua função. Em vez de redefinir toda a configuração da conversa, os subagentes adicionam sua intenção ao agente base por meio de composição de prompt e extensão seletiva de contexto. O histórico da conversa é mantido entre transições de subagentes para garantir continuidade, mas cada subagente opera com uma visão propositalmente limitada do sistema. Bases de conhecimento e ferramentas são expostas de forma seletiva, criando silos claros que evitam vazamento de responsabilidades. Para reforçar esse isolamento, o objeto do orquestrador é reconstruído a cada transição como se fosse um agente independente. Isso garante que o estado do prompt, configuração e capacidades disponíveis do subagente ativo permaneçam totalmente determinísticos. Esse design permite que Workflows mantenham consistência global e, ao mesmo tempo, suportem especialização local, resultando em comportamento previsível, separação clara de responsabilidades e controle preciso sobre como contexto, conhecimento e ações são aplicados em cada etapa da interação.

3. Cascata e Fundido Híbrido

Controlando transições de workflow com condições do LLM

Algumas arquiteturas enviam características acústicas (pronúncia, emoção, tom) da fala diretamente para o LLM como embeddings, em vez de converter primeiro para texto. O TTS permanece modular.

Isso fornece ao LLM informações mais ricas sobre

Exemplos de uso:

Segurança e proteção

4. Fundido Sequencial

Guardrails

Um único modelo multimodal faz reconhecimento, raciocínio e geração em uma só etapa, um turno de cada vez. Essa é a arquitetura de modelos como a API Realtime da OpenAI.

A prosódia pode ser forte. Como a fala nunca é convertida em texto, o modelo preserva ritmo, entonação e pistas emocionais naturalmente. Conversas curtas podem soar muito fluidas.

Mas há pouca possibilidade de aplicar regras de segurança sem uma camada de texto, poucas saídas intermediárias para depuração e pouca flexibilidade para trocar por um LLM melhor ou ajustar o STT para seu domínio. Os núcleos de raciocínio tendem a ser mais leves do que os LLMs de ponta, então tarefas complexas e uso de ferramentas em várias etapas ficam prejudicados. Quando a tarefa exige resolver um problema complexo, só a prosódia não basta.

Exemplos de uso:

Não existe uma arquitetura única que sirva para todos os agentes conversacionais. Cada variante tem pontos fortes e equilíbrios, desde a previsibilidade e controle dos modelos em cascata até a prosódia natural dos modelos fundidos.

5. Fundido Duplex

Nossa equipe de Forward Deployed Engineering está trabalhando lado a lado com os clientes para garantir que essas capacidades evoluam junto com as implantações reais. A próxima geração de Agents vai oferecer ainda mais transparência, determinismo e adaptabilidade, sem abrir mão da baixa latência que torna possível a conversa em tempo real.