Resumo Técnico: Agente-como-Roteador

1. Declaração do Problema

Usuários do mundo real frequentemente têm acesso a múltiplos Modelos de Linguagem de Grande Escala (LLMs) de diferentes provedores, cada um excelendo em domínios distintos (ex: design de algoritmos, ciência de dados ou conclusão de código), mas nenhum deles domina todas as tarefas. Os agentes de codificação atuais geralmente dependem de um único LLM fixo para todas as tarefas, um design que prioriza a previsibilidade do lado do provedor em detrimento da eficiência de custo centrada no usuário e da qualidade por nível de tarefa.

O problema central é o roteamento automático de modelos: determinar qual modelo deve lidar com cada tarefa de codificação recebida para maximizar o desempenho enquanto minimiza o custo. Os métodos de roteamento existentes tratam isso como um problema de classificação estático e pontual, frequentemente empregando modelos de linguagem como políticas de roteamento. No entanto, experimentos preliminares revelam uma lacuna significativa de desempenho entre os roteadores estáticos e um "oráculo por tarefa" (que conhece o melhor modelo para cada tarefa específica). O artigo identifica que o gargalo para os roteadores existentes não é a falta de capacidade de raciocínio, mas sim um déficit de informação: os roteadores estáticos falham em acumular experiência fundamentada na execução durante a implantação.

2. Metodologia

2.1. Diagnóstico: Déficit de Informação

Os autores realizaram um estudo de ablação usando um roteador LLM zero-shot (alimentado pelo Claude Sonnet 4.6).

• Roteador Vanilla: Obteve 41,41% de AvgPerf.
• + Estatísticas de Desempenho: Quando fornecido com estatísticas de desempenho prévias de um conjunto de sondagem mantido fora do treinamento (held-out), a pontuação subiu para 47,74% (+15,3% de ganho relativo), superando até mesmo o melhor roteador heurístico (47,50%) que codificava os mesmos priors estáticos.
• Conclusão: A principal limitação é a falta de informação dinâmica e fundamentada na execução, não a capacidade de raciocínio do próprio modelo de roteamento.

2.2. O Framework Agente-como-Roteador

Para abordar o déficit de informação, os autores propõem o Agente-como-Roteador, um framework que formaliza o roteamento como um loop Contexto-Ação-Feedback (C-A-F). Diferente dos roteadores estáticos, este framework evolui ao longo de um fluxo de tarefas:

1. Contexto ($c_i$): O roteador observa o prompt da tarefa, metadados e o histórico acumulado (Memória) de loops anteriores.
2. Ação ($a_i$): O roteador seleciona um modelo do pool de candidatos.
3. Feedback ($f_i$): A saída do modelo selecionado é executada em um sandbox, e um verificador gera uma pontuação e um custo.
4. Atualização: O feedback é memorizado e fundido ao contexto para a próxima tarefa ($c_{i+1}$).

Esta formulação relaciona-se a um problema de bandido multi-armado contextual, onde a métrica natural para avaliação é o regret cumulativo (a lacuna acumulada entre o desempenho do roteador e o oráculo por tarefa).

2.3. Instanciação ACRouter

O framework é instanciado como ACRouter, composto por três módulos principais:

• Orquestrador: Toma decisões de roteamento integrando o prior DimensionBest, os 10 vizinhos históricos mais próximos (recuperados via kNN de cosseno da Memória) e metadados da tarefa. Utiliza um modelo Qwen3.5-0.8B leve e ajustado (fine-tuned) combinado com regras heurísticas via votação ponderada.
• Verificador: Avalia as saídas dos modelos em um ambiente de sandbox. Ele agrega sinais (parsing AST, resultados de execução, LLM-as-Judge) em uma pontuação de desempenho unificada ($u_i \in [0, 1]$).
• Memória: Um armazenamento vetorial online indexado por embeddings de tarefas. Ele registra o modelo escolhido, desempenho, custo e traços de verificação. Utiliza um armazenamento limitado por FIFO (20K entradas) para permitir a recuperação de sucessos e falhas passadas de forma granular e sensível ao contexto.

2.4. CodeRouterBench

Para avaliar o roteamento em tarefas de streaming, os autores introduzem o CodeRouterBench, um benchmark que compreende:

• ~10.000 tarefas através de 10 dimensões de codificação (9 tarefas de turno único in-distribution e 1 dimensão de programação agêntica out-of-distribution).
• 8 LLMs de Fronteira (incluindo Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5, etc.).
• Pontuações Verificadas por Execução: As tarefas são pontuadas via execução em sandbox ou LLM-as-Judge, fornecendo uma matriz de observação de verdade fundamental para comparação baseada em regret.

3. Principais Contribuições

1. Framework: A proposta do Agente-como-Roteador, que formaliza o roteamento de modelos como um loop C-A-F, permitindo que os roteadores fechem ativamente a lacuna de informação através de feedback fundamentado na execução.
2. Artefatos:
   • ACRouter: Uma instanciação concreta do framework com módulos de Orquestrador, Verificador e Memória.
   • CodeRouterBench: Um ambiente de avaliação padronizado (~10K tarefas, 8 LLMs) projetado especificamente para comparação de roteadores baseada em regret em tarefas de streaming, incluindo um testbed de programação agêntica OOD.
3. Descobertas:
   • Déficit de Informação: O gargalo do roteamento é o acesso à informação, não o raciocínio. Fornecer estatísticas de desempenho gera um ganho relativo de 15,3%.
   • Desempenho: O ACRouter alcança o menor regret cumulativo em tarefas in-distribution e generaliza efetivamente para tarefas de programação agêntica out-of-distribution (OOD).
   • Limitações Estáticas: Roteadores estáticos leves (classificadores treinados, heurísticas) performam razoavelmente em tarefas in-distribution, mas falham significativamente em tarefas OOD, enquanto o ACRouter mantém um desempenho forte.

4. Resultados Experimentais

Os experimentos foram conduzidos em fluxos de tarefas tanto in-distribution (ID) quanto out-of-distribution (OOD).

• Desempenho In-Distribution:

  • O ACRouter alcançou o maior desempenho médio (49,98%) e o menor regret cumulativo (205,5), superando a heurística estática "DimensionBest" (47,50%) e todos os baselines de política treinada.
  • Também demonstrou superioridade em eficiência de custo (razão Perf/$ de 3.79) comparado ao uso constante do modelo mais forte (Always-Opus 4.6, que teve uma razão de 1.29).

• Generalização Out-of-Distribution (OOD):

  • No testbed de programação agêntica (176 tarefas), o ACACRouter alcançou 62,50% de AvgPerf, superando significativamente o baseline Always-Opus (57,14%) e todos os outros roteadores.
  • Classificadores estáticos (ex: LogReg, RouteLLM-BERT) colapsaram em tarefas OOD, com o desempenho caindo para 8,93%–21,43%, inclusive abaixo da seleção aleatória.
  • A capacidade do ACRouter de acumular experiência verificada durante o stream permitiu que ele se adaptasse à nova distribuição de tarefas, enquanto métodos estáticos baseados em priors congelados falharam na generalização.

• Análise de Custo:

  • Embora o ACRouter incorra em overhead para os módulos de Memória e Verificador, ele permanece mais econômico do que selecionar sempre o modelo mais caro (Opus 4.6) ao mesmo tempo em que entrega maior qualidade.
  • A estratégia "Always-Kimi-K2.5" ofereceu a maior eficiência de custo (Perf/$ 12.62), mas com um custo substancial no desempenho absoluto (36,66% AvgPerf).

5. Significância e Alegações

O artigo afirma que fechar ativamente a lacuna de informação através de feedback fundamentado na execução é um princípio geral para construir sistemas agênticos que devem rotear entre ferramentas ou modelos heterogêneos.

• Mudança de Paradigma: O trabalho move o roteamento de um problema de classificação estática para um processo dinâmico e autoadaptável (loop C-A-F).
• Utilidade Prática: Demonstra que os usuários podem alcançar desempenho próximo ao do oráculo e eficiência de custo através do roteamento dinâmico, em vez de depender de um único "melhor" modelo.
• Generalização: O loop C-A-F é apresentado não apenas como um mecanismo de roteamento, mas como um paradigma de tomada de decisão mais amplo aplicável à seleção de ferramentas, seleção de endpoints de API e alocação de esforço.
• Modéstia: Os autores reconhecem limitações, como a incapacidade de observar as taxas de hit de cache do lado do provedor (tornando as estimativas de custo relativas em vez de absolutas) e o uso de um limite de passos reduzido para tarefas OOD para manter a tratabilidade do orçamento. Eles observam que, embora sua instanciação atual utilize uma política de LLM com memória kNN, outras técnicas de memória ao nível de parâmetros ainda precisam ser exploradas.

Em resumo, o artigo argumenta que, para sistemas de codificação agêntica, o futuro não reside em encontrar um único modelo dominante, mas em construir roteadores adaptáveis que aprendam com o feedback de execução para selecionar a ferramenta certa para o trabalho certo.