Roteamento de modelos em agentes de IA: o modelo certo por tarefa

Roteamento de modelos em agentes de IA significa escolher, para cada tipo de tarefa, o modelo que seja capaz o bastante, rápido o bastante e autorizado a executá-la, em vez de enviar tudo para um único modelo. Você define os tipos de tarefa, escreve um critério de qualidade para cada um, atribui um modelo a cada tipo e adiciona um plano alternativo para os casos que a primeira escolha não consegue resolver. Depois, testa o próprio roteamento, e não apenas os modelos, para que as decisões continuem valendo quando as entradas, os provedores ou as versões mudarem.

Principais pontos

• Roteie por tipo de tarefa e por risco, não por hábito. Uma tarefa curta e bem definida raramente exige o mesmo modelo que uma tarefa aberta e de vários passos.
• Escreva primeiro o critério de qualidade. Um modelo só é adequado em relação a um teste que a equipe consegue rodar e a um resultado que uma pessoa aceita.
• Trate permissões e regras de dados como filtros obrigatórios. A capacidade decide entre os modelos permitidos, nunca o contrário.
• Teste o roteador e também os modelos: tarefas classificadas errado, entradas ambíguas, tempos esgotados e planos alternativos precisam de casos próprios.
• Meça o custo por resultado aceito e rode os testes de novo sempre que um modelo, um prompt ou uma ferramenta mudar.

O que é roteamento de modelos para um agente de negócio?

Um agente de negócio faz muitos tipos de trabalho no mesmo dia. Ele pode ler um e-mail recebido, extrair três campos de um anexo, resumir uma conversa longa, redigir uma resposta, conferir uma política e decidir se precisa pedir aprovação a uma pessoa. Essas tarefas diferem na dificuldade, no custo de um erro e na rapidez com que alguém espera a resposta.

Usar um único modelo para tudo é simples e é um ponto de partida razoável. O problema é que isso esconde uma troca. Se você escolhe um modelo forte para tudo, as tarefas simples demoram e custam mais do que precisam. Se escolhe um modelo leve para tudo, as tarefas difíceis falham em silêncio, e falha silenciosa em um fluxo de negócio é a mais cara.

O roteamento resolve isso tornando a escolha explícita. Uma camada de roteamento olha a tarefa, decide a qual caminho ela pertence e a envia para lá. A Anthropic descreve o roteamento como um padrão comum de fluxo em seu guia sobre como construir agentes eficazes: classificar a entrada e direcioná-la para um passo seguinte especializado. Em uma empresa, o roteador faz parte do harness, a camada em volta do modelo que guarda instruções, ferramentas, permissões e verificações. Se quiser alinhar o vocabulário antes, leia Modelo, agente e harness de IA: qual é a diferença?.

Nem sempre o roteamento é necessário. Algumas tarefas nem precisam de um modelo, e para elas uma regra fixa é mais segura. O guia Agente de IA ou fluxo determinístico? Como decidir ajuda a separar os dois casos antes de você começar a escolher modelos.

Quais atributos da tarefa devem decidir a rota?

Equipes costumam rotear com base na impressão vaga de que uma tarefa é fácil ou difícil. Uma abordagem melhor é descrever cada tipo de tarefa com um conjunto pequeno de atributos e deixar que eles guiem a escolha. Estes são os que mais pesam na prática:

• Profundidade de raciocínio: a tarefa exige vários passos dependentes entre si ou uma transformação direta?
• Custo de um erro: o que acontece se a saída estiver errada e quem perceberia?
• Tamanho da entrada: quanto contexto o modelo precisa ler de uma vez e ele precisa se manter fiel a esse contexto?
• Formato da saída: o resultado precisa seguir uma estrutura rígida que outro sistema vai consumir?
• Uso de ferramentas: a tarefa chama ferramentas e quantas chamadas em sequência?
• Latência: há uma pessoa esperando ou o trabalho roda em segundo plano?
• Sensibilidade dos dados: quais endpoints e regiões a empresa pode usar para esses dados?
• Volume: com que frequência a tarefa ocorre e a repetição faz pequenas diferenças se acumularem?

A maior parte disso pode entrar na definição da tarefa. Um contrato de tarefa de IA testável já reúne entradas, saídas, limites e regras de aceite, então o roteamento vira um campo em um documento que você já mantém, e não um conhecimento informal na cabeça de alguém.

Observe que a sensibilidade dos dados é um filtro, não uma preferência. Se os registros de um cliente só podem ser processados por infraestrutura aprovada, o conjunto de modelos elegíveis já é menor antes de você comparar qualidade. Aplique o filtro primeiro e escolha dentro do que sobrar.

Como associar tipos de tarefa a modelos?

A lista abaixo é um guia de decisão, não um ranking de produtos. Ela descreve a faixa de modelo que costuma servir a cada tipo de tarefa e o que precisa acompanhá-la. Ajuste de acordo com os seus próprios testes.

• Extrair campos fixos de documentos limpos e consistentes: um modelo menor e mais rápido, com validação de esquema e uma regra que rejeita saída incompleta.
• Rotular ou classificar solicitações em uma lista curta de categorias: um modelo menor com um sinal de confiança, escalando os casos ambíguos para um modelo mais forte ou para uma pessoa.
• Resumir uma conversa ou um documento longo: um modelo que lide bem com a entrada completa, com uma verificação de que cada afirmação remete à fonte.
• Redigir uma mensagem que um cliente ou parceiro vai ler: um modelo mais forte para tom e julgamento, com aprovação humana antes de qualquer envio.
• Planejar em várias ferramentas e etapas: o nível de raciocínio mais forte que você consiga justificar, com limites de passos e pontos de retomada para que o trabalho possa continuar se for interrompido.
• Aritmética, totais e conciliação: código comum para o cálculo, e um modelo apenas para interpretar entradas bagunçadas ou explicar o resultado.
• Qualquer coisa que envolva dados restritos: somente os endpoints aprovados para esses dados, seja qual for o resultado da comparação de capacidade.
• Um tipo de tarefa que ninguém classificou ainda: use por padrão o modelo mais forte, registre e revise, para que uma rota adequada possa ser definida.

O último item importa mais do que parece. Um roteador precisa de um padrão seguro para o desconhecido. Se as tarefas desconhecidas caem no caminho mais barato, você descobre a lacuna por causa de um erro. Se caem no caminho mais forte, você descobre por uma linha de registro.

Um cenário ilustrativo

Imagine uma pequena distribuidora cuja caixa de entrada de operações recebe e-mails de fornecedores (este é um cenário ilustrativo, não um caso real). O agente primeiro rotula cada e-mail: aviso de entrega, fatura, reclamação ou outro. Um modelo menor faz isso, porque as categorias são poucas e um rótulo errado é pego pela etapa seguinte. Para avisos de entrega, um modelo menor extrai a data e a referência em uma estrutura fixa, e um código valida o formato. Para reclamações, um modelo mais forte lê a conversa inteira, redige uma resposta e anexa os trechos de origem, e uma pessoa aprova. Para qualquer coisa rotulada como outro, o modelo mais forte assume e o caso entra em uma lista de revisão. São três rotas, um padrão e uma pessoa no ponto em que o custo do erro é maior.

Como testar se as decisões de roteamento se sustentam?

Roteamento é uma hipótese: este tipo de tarefa é bem atendido por este modelo. Como toda hipótese, precisa de evidência, e a evidência vem de rodar os mesmos casos em cada candidato com a mesma pontuação. Este é o plano que recomendamos.

• Passo um: liste seus tipos de tarefa e escreva uma regra de aceite para cada um. Se você não sabe dizer como é um bom resultado, não consegue escolher um modelo para ele.
• Passo dois: monte um conjunto de testes para cada tipo a partir de trabalho real e anonimizado, incluindo os casos incômodos: campos ausentes, idiomas misturados, anexos contraditórios, pedidos que ficam entre duas categorias. O guia Como avaliar agentes de IA em tarefas de negócio mostra como começar.
• Passo três: rode cada modelo candidato em cada conjunto, com as mesmas instruções e a mesma pontuação. Use um critério que um revisor conseguiria aplicar à mão e confira por amostragem a pontuação automática contra o julgamento humano. O guia de avaliações (evals) da OpenAI é uma boa referência para estruturar esse trabalho.
• Passo quatro: escolha o modelo menos custoso que passa do critério com alguma folga, e não o que passa por pouco. A folga absorve a variação normal entre execuções.
• Passo cinco: teste o roteador isoladamente. Dê a ele entradas mal rotuladas, ambíguas e fora do escopo e verifique onde cada uma cai. Um modelo perfeito atrás de um roteador que manda tarefas para o lugar errado continua produzindo trabalho errado.
• Passo seis: teste os caminhos de falha. Simule um tempo esgotado, uma queda do provedor, uma resposta malformada e uma falha de validação, e confirme que o plano alternativo é acionado e que nada é enviado ou alterado por engano.
• Passo sete: rode em modo de observação, em que o agente produz resultados que as pessoas comparam com o próprio trabalho sem que nada entre em produção. O texto Teste um agente de IA em modo de observação descreve esse padrão.
• Passo oito: repita toda a sequência sempre que uma versão de modelo, um prompt ou uma ferramenta mudar. Fixe as versões que você testou para que uma atualização silenciosa não altere o comportamento sem ninguém ver.

Dois pontos merecem destaque. Primeiro, o conjunto de testes deve incluir casos em que se espera que o modelo mais barato falhe, porque é isso que prova que a regra de escalonamento funciona. Segundo, uma decisão de roteamento não está concluída quando a média parece boa. Olhe os piores casos de cada tipo de tarefa, pois a empresa paga pelas falhas, não pela média.

O que registrar e acompanhar depois que o roteamento entra no ar?

Os testes mostram que o roteador funcionou nos casos que você imaginou. A produção mostra o resto. Para aprender com ela, cada tarefa concluída deve deixar um registro com o tipo de tarefa atribuído, o modelo que a tratou, se houve plano alternativo ou escalonamento, quanto tempo levou, o que a validação concluiu e se uma pessoa aceitou ou alterou o resultado.

Isso é um problema de observabilidade, e as ideias gerais do guia introdutório de observabilidade do OpenTelemetry se aplicam bem: rastros que acompanham uma tarefa por todas as etapas e campos consistentes para que os registros possam ser comparados. Para chamadas de modelo em particular, o projeto desenvolve convenções semânticas para IA generativa, que oferecem um vocabulário comum para registrá-las. Para ir além, veja também Observabilidade de agentes de IA: o que registrar?.

Com esses registros em mãos, algumas perguntas passam a ter resposta:

• Quais tipos de tarefa escalam com frequência e a rota padrão deles deveria mudar?
• Quais rotas produzem resultados que as pessoas editam muitas vezes?
• Estão aparecendo tipos de tarefa para os quais nenhuma rota foi desenhada?
• A composição do trabalho mudou desde a última revisão?

O custo deve ser lido do mesmo modo. O custo de uma chamada é um mau guia, porque uma chamada barata que exige retrabalho custa mais do que uma melhor que é aceita. O material da FinOps Foundation sobre economia unitária aponta o hábito certo: ligar o gasto a uma unidade de resultado que tenha sentido. Para um agente, essa unidade é um resultado aceito, como uma solicitação classificada que ninguém precisou corrigir.

Onde o roteamento costuma dar errado?

Alguns padrões de falha se repetem em implantações de negócio.

O primeiro é rotear apenas pela confiança que o próprio modelo declara. Modelos podem parecer seguros e estar errados, então os sinais de confiança funcionam melhor junto com verificações externas: validação de esquema, conferência com a fonte, regras de negócio e amostragem por um revisor.

O segundo é um roteador mais complicado do que o trabalho. Se você tem dois tipos de tarefa e um deles é trivial, uma regra basta. Adicione um classificador treinado apenas quando as categorias forem numerosas ou as entradas variadas demais para regras. Cada camada de roteamento é mais uma coisa para testar e manter.

O terceiro é dividir o trabalho entre agentes quando o roteamento resolveria. Se um agente dá conta do serviço e só a escolha do modelo muda a cada passo, rotear dentro de um único agente é mais simples do que coordenar vários. O texto Um agente ou vários: quando dividir o trabalho de IA explica quando a separação compensa o custo extra.

O quarto é esquecer que o roteamento esconde desvios. Quando um provedor atualiza um modelo, uma rota que passou no trimestre passado pode falhar hoje sem nenhuma mudança do seu lado. A proteção é a reavaliação agendada, não a memória.

O quinto é ignorar permissões. Um modelo forte não deve receber acesso mais amplo só por ser mais capaz. As permissões de ferramentas e os limites de aprovação pertencem à função do agente e permanecem os mesmos, seja qual for o modelo que esteja respondendo.

Como a Be Human trata o roteamento de modelos na operação gerenciada?

A Be Human trata o roteamento como parte do harness de uma função de agente definida. No primeiro trabalho, descrevemos os tipos de tarefa da função, os limites de aprovação e o critério de sucesso, e depois associamos cada tipo de tarefa a um modelo elegível dentro das regras de dados e permissões do cliente. A operação gerenciada inclui avaliações recorrentes com os conjuntos de teste da função, monitoramento de escalonamentos e falhas e mudanças controladas quando um modelo, um prompt ou uma integração precisa ser atualizado, com a equipe do cliente aprovando tudo o que altere o que o agente pode fazer.

Perguntas frequentes

Precisamos de mais de um modelo para começar? Não necessariamente. Comece com um modelo capaz, escreva os tipos de tarefa e os testes e observe os registros. Se um grupo claro de tarefas simples estiver lento ou caro, ou um grupo de tarefas difíceis estiver falhando, é o momento de adicionar uma segunda rota.

O modelo deve decidir a própria rota? Ele pode ajudar a classificar, mas a decisão deve ser conferida por algo fora dele. Use regras para os casos claros, um classificador menor para os variados e um padrão seguro que leve ao caminho mais forte quando o sinal for fraco. Mantenha a lógica visível para que um revisor possa ler por que uma tarefa foi para determinado lugar.

Com que frequência devemos testar o roteamento de novo? Teste de novo sempre que uma versão de modelo, uma instrução, uma ferramenta ou uma fonte de dados mudar, e em intervalos regulares mesmo quando nada parece ter mudado. Provedores podem alterar o comportamento mantendo o mesmo nome, então execuções agendadas sobre um conjunto de testes estável são o alerta mais antecipado que você tem. O texto Agentes de IA com tarefas agendadas: como rodar rotinas com segurança trata de como rodar esse tipo de rotina com confiabilidade.

E se o modelo mais barato passa nos testes, mas as pessoas ainda corrigem a saída dele? Então os testes estão deixando algo de fora. Adicione os casos corrigidos ao conjunto de testes, endureça a regra de aceite e rode a comparação de novo. As edições que as pessoas fazem estão entre as melhores evidências que você terá sobre como é um bom resultado.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.