O roteamento de modelos está se tornando um componente-chave da pilha de IA empresarial, enviando prompts dinamicamente para o modelo de IA certo para otimizar velocidade e custos. No entanto, as estruturas atuais tratam principalmente o roteamento como um problema de classificação estática, o que limita severamente o seu potencial.

Uma nova estrutura de código aberto chamada Agent-as-a-Router resolve esse gargalo, tratando o roteador como um agente dinâmico de construção de memória. Ele usa um loop Context-Action-Feedback (CAF) para rastrear sucessos e falhas do modelo e atualizar o comportamento do roteador.

Os pesquisadores também lançaram o ACRouter, uma implementação concreta deste paradigma. Em seus testes, o ACRouter superou significativamente os roteadores estáticos e a dispendiosa estratégia de usar modelos premium como padrão, tudo sem exigir que as equipes treinassem modelos massivos ou escrevessem heurísticas infinitas.

Para aplicações do mundo real, esta estrutura oferece a opção de substituir a infraestrutura de IA codificada por sistemas auto-otimizados que podem se adaptar às mudanças no comportamento do usuário e nos modelos básicos usados ​​na pilha de IA corporativa.

A economia do roteamento e o déficit de informação

As configurações de modelo único são úteis para experimentos, mas prejudiciais ao dimensionar aplicativos de IA. Os engenheiros de IA usam o roteamento de modelos para mapear tarefas para modelos abertos mais baratos e mais rápidos, quando possível, enquanto reservam modelos de fronteira caros para raciocínios complexos.

Atualmente, os desenvolvedores contam com dois mecanismos principais para esta tarefa. O primeiro é o roteamento baseado em heurística, que depende de regras manuais codificadas. Por exemplo, um desenvolvedor pode escrever uma regra determinando que, se um prompt contiver determinadas palavras-chave, ele será roteado para GPT-5.5. Caso contrário, ele vai para um modelo de código aberto auto-hospedado como o Kimi K2.7.

O segundo mecanismo são políticas treinadas estáticas. Esses são classificadores de aprendizado de máquina treinados em conjuntos de dados históricos que analisam as incorporações do prompt e prevêem o melhor modelo com base em dados de treinamento anteriores.

Ambas as abordagens são estáticas. Quando os pesquisadores testaram esses mecanismos existentes em codificação do mundo real e fluxos de trabalho de agentes, eles encontraram um limite rígido de precisão. A principal descoberta mostra que os roteadores estáticos sofrem de um grave déficit de informações. Como eles apenas avaliam o texto de entrada e nunca veem se o modelo realmente conseguiu executar a tarefa, eles adivinham cegamente quando se deparam com casos extremos complexos.

Isso resulta em três pontos distintos de falha. Primeiro, os roteadores estáticos sofrem com um estado de informação congelada, o que significa que não podem acumular novo feedback de execução durante a implantação. Segundo, eles falham na generalização fora de distribuição (OOD). Eles falham durante as operações do segundo dia, quando os dados corporativos ou o comportamento do usuário mudam porque seus dados de treinamento não correspondem mais à realidade. Finalmente, eles são altamente vulneráveis ​​à rotatividade de modelos. Um classificador estático treinado nos modelos atuais pode se tornar obsoleto quando um modelo melhor for lançado na semana seguinte.

Agente como roteador: um sistema em autoevolução

A tese central do Agente como Roteador é que um roteador verdadeiramente eficaz deve adquirir e acumular informações baseadas na execução durante a implantação, essencialmente aprendendo no trabalho.

Os pesquisadores conseguiram isso por meio do circuito CAF. Quando um novo prompt chega, o roteador examina os metadados do prompt e da tarefa, como a linguagem de programação ou a dificuldade. Em seguida, ele pesquisa em sua memória histórica tarefas semelhantes para ver quais modelos tiveram sucesso ou falharam no passado. O roteador usa esse contexto para selecionar o modelo alvo e executar a tarefa. Finalmente, o sistema observa o resultado do mundo real, extrai um sinal de sucesso ou falha e grava esse feedback de volta em sua memória para informar futuras decisões de roteamento.

Considere um pipeline automatizado de análise de dados empresariais. O roteador recebe uma tarefa de geração de SQL e a envia para um modelo de código aberto como o Kimi. O modelo alucina um nome de coluna e não consegue compilar o SQL. O loop CAF observa o erro do compilador, registra-o como feedback e registra-o. Na próxima vez que uma consulta SQL obscura semelhante chegar, o roteador verificará seu contexto e encaminhará a tarefa para um modelo mais avançado como Claude Opus 4.8.

ACRouter

Os pesquisadores desenvolveram o ACRouter como a instanciação concreta desta estrutura. É composto por três componentes principais: o orquestrador, o verificador e a memória. Esta arquitetura é suportada por uma camada de ferramentas para executar fisicamente o loop CAF.

O módulo Memória alimenta a fase de contexto. Construído em um armazenamento de vetores, ele recupera interações passadas relevantes e atualiza o banco de dados histórico com novos resultados. O orquestrador cuida da fase de ação. Ele processa o prompt do usuário juntamente com a memória recuperada para selecionar o modelo de destino mais capaz do pool disponível. O verificador gerencia a fase de feedback avaliando a saída do modelo escolhido para gerar um sinal claro de sucesso ou falha.

A camada de ferramentas conecta o Verifier a ambientes de execução do mundo real, como um interpretador de código Python, uma sandbox de agente ou um mecanismo de banco de dados. A camada de ferramentas permite que o sistema execute o código ou consulta gerado e observe o resultado exato, fornecendo o sinal verificável que o roteador precisa aprender.

O orquestrador em si é leve. Em vez de um modelo de linguagem enorme e computacionalmente pesado, os pesquisadores treinaram um adaptador de parâmetros de menos de um bilhão baseado em Qwen 3.5 (parâmetros de 0,8B), o que significa que ele pode ser auto-hospedado em um dispositivo de sua escolha.

ACRouter em ação: Superando as linhas de base da fronteira

Para testar a estrutura, os pesquisadores introduziram o CodeRouterBench, um ambiente de avaliação que compreende cerca de 10.000 tarefas com pontuações verificadas em oito modelos de fronteira, incluindo Claude Opus 4.6, GPT-5.4, Qwen3-Max e GLM-5. A avaliação foi dividida entre testes em distribuição (ID) (cobrindo nove dimensões de codificação de turno único, como design de algoritmo e geração de testes) e um ambiente de teste de programação de agente fora de distribuição (OOD). As tarefas OOD eram qualitativamente diferentes, exigindo planejamento em várias etapas, navegação em arquivos e depuração iterativa para verificar se o roteador poderia se adaptar a domínios fundamentalmente novos.

Os resultados da linha de base revelaram por que uma estratégia de modelo único é falha: nenhum modelo único domina todas as categorias. Por exemplo, embora Claude Opus 4.6 tenha alcançado o desempenho médio mais alto, ele foi superado no design de algoritmo pelo GLM-5 (uma melhoria relativa de 86%) e na geração de testes pelo Qwen3-Max (uma melhoria de 111%), apesar do Opus custar cerca de 12 vezes mais que modelos menores como o Kimi-K2.5.

Nos benchmarks, os roteadores estáticos falharam continuamente ao enviar uma tarefa de codificação de nicho específico para um modelo mal equipado para essa sintaxe exata. O roteador estático não tinha como saber que o código não estava sendo executado. Em contraste, o ACRouter ajustou sua estratégia após receber um sinal de feedback negativo do ambiente de execução.

De acordo com o benchmarking dos pesquisadores, o ACRouter está firmemente na fronteira de Pareto em termos de custo e desempenho. Tanto nos fluxos de tarefas de ID quanto nos testes complexos de agente OOD, o ACRouter alcançou o menor arrependimento cumulativo, uma métrica que mede decisões de roteamento abaixo do ideal ao longo do tempo. No conjunto de testes em distribuição, o ACRouter custou US$ 13,21 em toda a execução da tarefa, em comparação com US$ 34,02 para sempre usar o Opus como padrão – uma economia de 2,6x.

Ele combinou dinamicamente as tarefas com o modelo mais capaz para aquele nicho específico, sugerindo que as empresas podem alcançar ou exceder a precisão de nível limite em diversas cargas de trabalho sem pagar um preço premium por cada consulta.

Advertências, limitações e como começar

Embora o paradigma do agente como roteador resolva o déficit de informações, não é uma solução geral para todos os fluxos de trabalho de IA.

A estrutura brilha em tarefas verificáveis ​​em que o verificador obtém um sinal claro de sucesso ou falha do ambiente, como codificação ou recuperação de dados. É eficaz para aplicações com mudanças de distribuição e domínios onde diferentes modelos se destacam em nichos completamente distintos.

Por outro lado, a configuração é um exagero para tarefas triviais onde qualquer modelo será suficiente, ou para aplicações de baixo volume que não justificam a sobrecarga de engenharia. Também é inadequado para domínios subjetivos, como a escrita criativa, onde uma resposta correta não pode ser facilmente verificada e os sinais de feedback são impossíveis de padronizar.

Os pesquisadores abriram o código no GitHub e lançaram os pesos do modelo orquestrador no Hugging Face sob a licença Apache 2.0. O roteador é compatível com Claude Code, Codex e OpenCode.

Fonte ==> Cyberseo