Resumo Técnico: ALLOBENCH: MEDINDO A CAPACIDADE DE ALOCAÇÃO DE FERRAMENTAS ONLINE EM AGENTES LLM

Declaração do Problema

Agentes de Grandes Modelos de Linguagem (LLMs) são cada vez mais incumbidos de criar ferramentas reutilizáveis (scripts, macros, wrappers) para resolver tarefas recorrentes. Embora os benchmarks existentes avaliem se um modelo consegue escrever uma ferramenta correta ou selecionar de uma biblioteca existente, eles falham amplamente em medir a decisão fundamental de quando criar uma ferramenta.

A construção de ferramentas incorre em um custo fixo (tempo, tokens, orçamento de ação), mas oferece o potencial para reutilização futura. Um agente ideal deve equilibrar o risco de desperdiçar recursos em tarefas raras e únicas contra o custo de oportunidade de esperar demais para capturar tarefas frequentes e recorrentes. Este é um problema de aprendizado online sob incerteza. O artigo postula que os modelos de fronteira atuais podem carecer da capacidade de fazer esse equilíbrio racionalmente, particularmente quando o processo de criação de ferramentas envolve a geração de código.

Metodologia: AlloBench

Os autores introduzem o AlloBench, um benchmark pareado projetado para testar o investimento de ferramentas consciente de orçamento através de uma "escada de enquadramento" (framing ladder) que transita de contextos abstratos para contextos totalmente construtivos.

Configuração Experimental

• Fluxo de Tarefas: Um episódio consiste em uma sequência oculta de $T=60$ tarefas extraídas de $N=8$ classes latentes.
• Distribuição: Três classes são "quentes" (alta frequência, ~13–23 ocorrências) e cinco são "armadilhas" (baixa frequência, ~1–6 ocorrências).
• Orçamento: O agente possui um orçamento fixo de $B=3$ para criar ferramentas.
• Mecanismo: Em cada turno, o agente observa uma instância de tarefa. Se a tarefa pertence a uma classe para a qual nenhuma ferramenta existe e o orçamento permanece, o agente escolhe COMMIT (criar uma ferramenta, consumindo orçamento) ou PASS (esperar). Se uma ferramenta existe, ela é aplicada automaticamente.
• Recompensa: O agente ganha um ponto para cada instância de tarefa resolvida (seja por uma ferramenta pré-existente ou por passar se nenhuma ferramenta for necessária, embora o "passar" renda 0 pontos para aquela instância específica). O objetivo é maximizar a utilidade total capturando o máximo possível das ocorrências das classes "quentes" enquanto evita as classes "armadilhas".

A Escada de Enquadramento (Framing Ladder)

Para isolar onde as capacidades de alocação falham, o mesmo fluxo de tarefas é renderizado em quatro enquadramentos distintos:

1. R0 (Abstrato): O modelo vê bolas coloridas e escolhe KEEP/PASS em texto livre. Nenhuma codificação está envolvida.
2. R1 (Declarativo): O modelo vê problemas numéricos e faz chamadas declarativas de KEEP/PASS. Nenhuma geração de código.
3. R2 (Código): O modelo deve gerar uma função Python solve(inputs) não vazia para reivindicar uma classe. A correção do código não é avaliada para recompensa, mas a geração é exigida.
4. R3 (Completo): O modelo deve escrever, executar e reutilizar um script. A correção é necessária para que o script seja creditado.

Métricas

• Taxa de Compromisso na Primeira Visualização (First-Sight Commitment Rate): A fração de compromissos feitos na primeiríssima ocorrência de uma classe. O comportamento ideal dita esperar por evidências de recorrência; taxas altas indicam comportamento "eager" (ansioso/subótimo).
• Pontuação (Score): Uma razão competitiva comparando a utilidade realizada com o ótimo teórico de retrospectiva (soma dos tamanhos das $B$ maiores classes).

Principais Contribuições

1. Benchmark AlloBench: Um benchmark generalizável e pareado para estudar o investimento de ferramentas consciente de orçamento.
2. Pontuação Quantitativa: Uma métrica para comparar de forma justa o desempenho de alocação entre modelos, separando o tempo da capacidade de criação de ferramentas.
3. Descoberta de uma Parede de Capacidade: Evidência de que modelos de fronteira podem alocar orçamentos de forma ótima em configurações abstratas, mas falham ao transitar para contextos de criação de ferramentas.
4. Localização da Falha: Identificação da "emissão de código" (R2) como o principal gatilho para a falha de alocação na maioria dos modelos, e "construção completa" (R3) para os modelos mais fortes.
5. Limitações de Pós-Treinamento: Demonstração de que políticas de RL treinadas em alocação abstrata não se generalizam para enquadramentos baseados em código ou numéricos.

Resultados Experimentais

O estudo avaliou quatro modelos de fronteira (Claude Haiku 4.5, Claude Opus 4.8, GPT-5.4-mini, GPT-5.6 Sol) e um modelo de código aberto (Qwen2.5-Coder-14B).

1. Competência Abstrata vs. Falha de Orçamento de Ferramentas

Todos os quatro modelos de fronteira demonstraram alocação quase ótima no quadro R0 (Abstrato), esperando por evidências de recorrência em >70% dos casos antes de se comprometerem. No entanto, essa competência colapsou em R3 (Construção Completa). Em R3, nenhum modelo esperou pela recorrência por mais de 12% do tempo; eles se comprometeram quase imediatamente ao ver a primeira instância.

2. Localização do Modo de Falha

Ao analisar a transição através da escada de enquadramento, os autores identificaram o gatilho específico para a falha:

• Haiku, Opus e GPT-5.4-mini: Estes modelos mantiveram uma alocação razoável em R0 e R1 (declarativo). Sua capacidade de alocação colapsou drasticamente em R2 (Código), onde foram solicitados a emitir código, mesmo que a correção do código não fosse verificada.
• GPT-5.6 Sol: Este modelo preservou alguma capacidade de alocação em R2 (39% de compromisso na primeira visualização), mas colapsou apenas em R3 (Construção Completa), onde os scripts devem ser executados e verificados.

3. Pós-Treinamento e Generalização

Os autores ajustaram o Qwen2.5-Coder-14B usando PPO para maximizar a utilidade no quadro abstrato R0.

• Sucesso: O modelo pós-treinado reduziu sua taxa de compromisso na primeira visualização em R0 de 74% para 6% e generalizou esse comportamento para reskinagens lexicais (ex: moedas em vez de bolas).
• Falha: A política aprendida não se transferiu para R1 (Declarativo) ou R2 (Código). Apesar de ter sido treinado para ser seletivo em termos abstratos, o modelo reverteu para o compromisso ansioso quando apresentado com problemas numéricos ou requisitos de código.

4. Sensibilidade Econômica

Em uma análise de sensibilidade econômica (variando o custo de criação de ferramentas), a política abstrata (R0) tornou-se mais seletiva conforme os custos aumentavam, acompanhando o ótimo teórico. Em contraste, a política de requisito de código (R2) permaneceu inelástica, continuando a construir ferramentas com taxas próximas a 100%, mesmo quando o custo era tão alto que a estratégia ótima seria construir quase nada.

Significância e Alegações

O artigo estabelece a alocação de ferramentas online como uma fronteira significativa de capacidade para os modelos de fronteira modernos.

• Lacuna de Enquadramento (Framing Gap): Existe uma desconexão fundamental entre a capacidade de um modelo de raciocinar sobre alocação de recursos no abstrato e sua capacidade de executar esse raciocínio quando a tarefa envolve gerar código. Os autores conjecturam que isso é causado pelo pós-treinamento em conjuntos de dados de codificação (ex: DeepSWE), que apresentam fluxos de problemas não relacionados com recompensas independentes, condicionando o modelo a fixar-se na instância imediata em vez de "investir para o futuro".
• Implicações de Design de Sistema: Sistemas de agentes atuais de construção de ferramentas não conseguem gerenciar simultaneamente a alocação de orçamento e a criação de ferramentas. Os autores sugerem que sistemas futuros devem desacoplar essas tarefas: um agente deve tomar a decisão abstrata de investir (baseada na lógica tipo R1), enquanto um agente separado lida com a construção.
• Limitações de Avaliação: Benchmarks existentes confundem a capacidade de criação de ferramentas com a capacidade de alocação. Um modelo pode falhar em uma tarefa não porque não consegue escrever uma ferramenta, mas porque sua política de alocação é suprimida pelo enquadramento construtivo.

O artigo conclui que, embora os modelos possuam a capacidade latente de investimento online ideal, essa capacidade é atualmente suprimida pelos requisitos específicos de emissão e execução de código, um fenômeno ainda não resolvido pelas técnicas de pós-treinamento padrão.