É importante avaliar com cuidado como e onde as decisões são tomadas em seu sistema com agentes de IA.
Delegar mais decisões a um LLM pode permitir que o sistema se generalize para mais tarefas, mas pode comprometer a velocidade, a confiabilidade e a robustez.
Sempre que possível, tente retirar do LLM o máximo possível do processo de tomada de decisão e transferi-lo para código de software explícito. Isso é especialmente importante para fluxos de trabalho de alto risco e/ou em produção.
Ao projetar um sistema com agentes de IA baseado em LLM, uma das decisões mais importantes é definir quanto da tomada de decisão ficará encapsulada em um modelo LLM e quanto ficará em software explícito.
Para facilitar a compreensão, podemos pensar nessa escolha como um espectro entre as seguintes abordagens:
Arquiteturas baseadas em roteador definem explicitamente a ordem e a lógica no código, garantindo testabilidade, previsibilidade e robustez para tarefas de domínio restrito (também chamadas de "agentes de fluxo de trabalho").
Agentes orquestradores usam modelos de linguagem de grande porte (LLMs) para decidir dinamicamente os fluxos das tarefas por meio de prompts em linguagem natural. São ideais para interações abertas, nas quais uma lógica predefinida seria insuficiente ou impossível.
Para fluxos de trabalho de alto risco e em produção, geralmente recomendamos usar mais recursos baseados em roteador e reservar os orquestradores para aplicações que exijam conversas flexíveis e de uso geral.
Arquiteturas baseadas em roteador
Sistemas com agentes de IA baseados em roteador:
Definem explicitamente o fluxo de tomada de decisão por meio de código ou software e usam um LLM para determinar qual rota esse software deve seguir.
São mais próximos dos sistemas de software tradicionais, pois têm caminhos claros e previsíveis que produzem resultados mais consistentes.
São ideais para tarefas que podem ser definidas com precisão.
A seguir, apresentamos um exemplo simplificado de um agente de reservas de uma companhia aérea via chatbot que usa a "abordagem de roteador". Embora o LLM ajude a classificar a intenção da pergunta entre três opções possíveis, é o software que, em última análise, associa essa intenção a uma resposta de texto predefinida. Como o LLM é altamente restrito, o usuário terá uma experiência mais consistente.
Arquiteturas de orquestrador
Ao contrário dos sistemas de roteador, os sistemas com agentes de IA orquestradores:
Definem os fluxos lógicos por meio de prompts em linguagem natural, em vez de software. Observação: em comparação com uma linguagem de programação, a linguagem natural é inerentemente ambígua e flexível — características tanto positivas quanto negativas, como veremos adiante. Chamamos isso de "intenção em vez de instrução".
Podem oferecer várias opções de processamento, enquanto o LLM determina a ordem e a metodologia de execução.
Podem criar dinamicamente novos caminhos lógicos difíceis de definir explicitamente em software.
Essa ambiguidade pode gerar resultados inconsistentes, mas, quando funciona, a experiência pode parecer "mágica".
O exemplo a seguir aplica uma abordagem de orquestrador ao mesmo problema simplificado da companhia aérea. Em vez de deixar o software decidir qual resposta é apropriada, a tomada de decisão é delegada à camada do LLM. Temos aqui um sistema multiagente no qual um agente orquestrador "principal" faz a triagem da consulta do usuário e a encaminha a um agente projetado especificamente para alterar voos, que então fornece a resposta ao usuário.
Nesse exemplo, a camada do LLM desempenha as funções de classificador, roteador e redator da resposta. No exemplo do roteador, ela desempenhava apenas a função de classificador, enquanto o software cuidava do restante.
Sempre que possível, recomendamos abordagens baseadas em roteador, pois elas oferecem as seguintes vantagens:
Velocidade e eficiência: cálculos locais são mais rápidos do que orquestradores que dependem de APIs externas. Também é muito mais barato processar sua lógica "IF/ELSE" em Python do que pagar a um provedor de LLM para executá-la em um modelo de 400 bilhões de parâmetros.
Testabilidade e previsibilidade: práticas consolidadas de software facilitam consideravelmente a depuração, os testes e a manutenção.
Transparência e confiabilidade: a menor variação de comportamento simplifica a solução de problemas. Além disso, uma parcela maior do fluxo da aplicação fica expressa em software transparente e com controle de versão, em vez de nos pesos opacos e não interpretáveis de um LLM.
As desvantagens das abordagens de roteador são a rigidez, a falta de flexibilidade e a dificuldade de lidar com problemas mais abertos. Um chatbot que sempre apresenta exatamente as mesmas respostas pode parecer monótono ou estagnado para os usuários.
Projetos com orquestradores oferecem recursos avançados:
Planejamento: podem planejar respostas dinamicamente.
Seleção de ferramentas/encaminhamento para agentes: selecionam as ferramentas adequadas ou delegam tarefas a agentes.
Combinação iterativa de resultados: iteram e recombinam resultados de forma criativa.
Determinação da conclusão: determinam quando já foram coletadas informações suficientes para finalizar uma resposta.
Frameworks como Pydantic-AI ou o Agents SDK da OpenAI tornam a orquestração simples e rápida de implementar. Por isso, essa abordagem é excelente para demonstrações ou provas de conceito.
As desvantagens dessa abordagem são:
Não há garantia de que as etapas de planejamento do LLM e as ações subsequentes serão corretas ou adequadas. O sistema de roteador enfrenta o mesmo problema, mas, por ser mais restrito, seu comportamento é mais previsível.
Para tarefas simples e bem definidas, dificilmente precisamos de todos os recursos de um sistema multiagente. Por exemplo, no caso do nosso agente de companhia aérea, provavelmente há apenas um número limitado de tipos de consulta que alguém realmente deseja fazer ao interagir com um sistema de atendimento de uma companhia aérea.
Como uma parte maior da lógica fica contida no LLM, o sistema fica muito mais suscetível a jailbreaks ou explorações por agentes mal-intencionados.
Essa abordagem abstrai a tomada de decisão para dentro do LLM e, portanto, dificulta a compreensão do sistema, embora ferramentas de monitoramento como Langfuse ou Braintrust possam ajudar parcialmente.
Observação ao leitor: embora a capacidade dos modelos esteja mudando rapidamente, é improvável que as recomendações abaixo mudem no futuro próximo.
Determine o escopo do problema.
Você consegue definir facilmente a lógica de decisão desejada em um diagrama?
Falhas ou comportamentos inesperados são inaceitáveis em sua aplicação?
Responder "sim" a qualquer uma das perguntas acima indica que os recursos de roteador seriam mais adequados.
Sempre que possível, recomendamos usar abordagens de roteador enquanto forem suficientes. Como princípio geral, se uma parte do sistema puder ser expressa em código, expresse-a em código — ou seja, não use LLMs em excesso quando não forem necessários.
Quando essas abordagens atingirem seus limites, algumas das vantagens abertas dos orquestradores poderão ser reproduzidas de forma controlada. Por exemplo:
Seleção de ferramentas/encaminhamento para agentes: pode ser implementada facilmente por meio de ramificações condicionais ou classificadores LLM.
Determinação da conclusão: classificadores LLM simples podem verificar se a resposta está completa antes de devolvê-la ao usuário.
No entanto, o "planejamento" e a "combinação iterativa de resultados" são, sem dúvida, muito mais difíceis de implementar em um sistema de roteador rígido. Por isso, quando uma tarefa exigir esses recursos, conforme determinado por um classificador LLM ou outra lógica, sugerimos criar no sistema uma ramificação de orquestrador com menos restrições.
A escolha entre arquiteturas de roteador e de orquestrador deve refletir a clareza, a complexidade e o estilo de interação da aplicação. Atualmente, as abordagens baseadas em roteador oferecem confiabilidade, eficiência e facilidade de teste para tarefas bem definidas. Os orquestradores oferecem mais flexibilidade para interações conversacionais mais amplas.
À medida que os LLMs continuarem avançando, o equilíbrio entre essas abordagens poderá mudar. Preferimos arquiteturas baseadas em roteador ou híbridas para cargas de trabalho em produção e reservamos os orquestradores para problemas abertos que exijam interações dinâmicas e semelhantes às humanas.