Resumo Técnico: Agentes ReAct com Estado para Experimentação Autônoma e Eficiente em Tokens

Declaração do Problema

O padrão "autoresearch" permite a experimentação autônoma ao fazer com que um Modelo de Linguagem de Grande Escala (LLM) modifique iterativamente o código para otimizar uma métrica alvo. Embora eficaz, a implementação padrão é sem estado (stateless): a cada iteração, o agente deve reconstruir todo o contexto experimental relendo o histórico completo de resultados e modificações de código acumulados em um arquivo de diretiva de pesquisa (ex: program.md).

Este design incorre em uma ineficiência estrutural:

• Custo de Tokens: O tamanho do prompt cresce linearmente ($O(n)$) com o número de iterações, levando a um custo total de tokens de $O(n^2)$.
• Redundância: O agente retransmite informações que já processou em etapas anteriores.
• Escalabilidade: À medida que os experimentos se acumulam, o prompt se aproxima dos limites da janela de contexto, exigindo truncamento ou sumarização, o que corre o risco de perder nuances experimentais críticas.

O artigo postula que, como os LLMs não podem manter estado transitório entre interações (Huang et al. [10]), o gerenciamento de estado externo é uma necessidade arquitetônica para quebrar essa curva de custo quadrática.

Metodologia

Os autores reformulam o padrão autoresearch como um agente ReAct com estado (stateful) usando LangGraph. Em vez de prompts monolíticos contendo o histórico completo, o agente interage com o sistema de ML via chamadas de ferramentas (tool calls), enquanto o histórico experimental, os traços de raciocínio e as métricas de convergência persistem em um grafo de estado persistente tipado.

Arquitetura

O agente opera como um grafo de estado com três nós primários:

1. REASON (Raciocínio): Invoca o LLM (Claude Haiku 4.5) com o contexto do estado atual. O modelo gera traços de raciocínio e chamadas de ferramentas.
2. TOOLS (Ferramentas): Executa chamadas de ferramentas deterministicamente (ex: rodar experimentos, consultar resultados) e retorna observações.
3. CHECK (Verificação): Avalia critérios de convergência (limiar de métrica alvo, orçamento de iteração ou conclusão do LLM) sem envolvimento do LLM.

Arestas condicionais roteiam o fluxo: se o LLM produzir chamadas de ferramentas, o controle passa para TOOLS; caso contrário, prossegue para CHECK. Se não houver convergência, o loop retorna para REASON.

Gerenciamento de Estado

A inovação central é o AgentState (um dicionário tipado) que persiste através das iterações. Ele inclui:

• messages: Uma janela deslizante das últimas 20 mensagens para limitar o custo de entrada.
• experiment_history: Uma lista de todos os resultados passados.
• current_best: O melhor resultado encontrado até o momento.
• train_py_content: O estado atual do código.

Crucialmente, o agente utiliza uma classe auxiliar (ExperimentState ou CodeState) para gerar um resumo compacto para o LLM em cada etapa. Este resumo inclui:

• Contagem de iterações atuais e melhores métricas agregadas.
• Os últimos 5 experimentos (ou resultados recentes).
• Notas de estratégia e abordagens que falharam.

Isso garante que o LLM receba apenas $O(1)$ tokens de entrada por iteração, independentemente do número total de experimentos realizados. O histórico completo permanece acessível no estado, mas é excluído do prompt, a menos que seja explicitamente consultado via ferramentas.

Ferramental

O agente interage com o sistema de ML através de ferramentas específicas:

• Ajuste de Hiperparâmetros: get_experiment_history e run_experiment.
• Otimização de Código: get_current_train_py, modify_train_py (com salvaguardas para preservar a lógica de avaliação), submit_training_job e query_results.

Principais Contribuições

1. Reformulação Arquitetônica: Transformação do padrão de pesquisa autônoma sem estado em um agente ReAct com estado usando LangGraph, desacoplando a memória de trabalho do agente de seu contexto de prompt.
2. Eficiência de Tokens: Demonstração de uma redução estrutural no custo de tokens de $O(n^2)$ (sem estado) para $O(n)$ (com estado) no total, com um custo de $O(1)$ por iteração.
3. Blueprint de Implementação: Fornecimento de uma arquitetura detalhada e reproduzível (incluindo esquemas de estado, lógica de grafo e definições de ferramentas) para que profissionais implementem agentes com estado.

Resultados Experimentais

Os autores avaliaram o agente com estado contra um baseline sem estado em duas tarefas de benchmark usando 3 sementes aleatórias.

Tarefa 1: Ajuste de Hiperparâmetros (Observações Pequenas)

• Configuração: 15 iterações otimizando XGBoost no conjunto de dados UCI Covertype. Observações eram pequenas (~200 tokens: configuração JSON + métricas).
• Resultados:
  • Redução de Tokens: O agente com estado consumiu 90% menos tokens (2.492 vs. 24.465), uma redução de 9.8×.
  • Performance: Ambos os agentes alcançaram pontuações F1 comparáveis (0.779 vs. 0.764), com diferenças atribuídas à variância da semente, não à superioridade arquitetônica.
  • Curva de Custo: O custo de entrada sem estado cresceu linearmente de ~700 para ~1.900 tokens por iteração; o custo com estado permaneceu constante em ~100 tokens.

Tarefa 2: Otimização de Performance de Código (Observações Grandes)

• Configuração: 40 iterações otimizando uma função de processamento de dados em Python. Observações eram grandes (~1.500–3.000 tokens: código fonte completo + benchmarks).
• Resultados:
  • Redução de Tokens: O agente com estado consumiu 52% menos tokens (627K vs. 1.275K), uma redução de 2.0×.
  • Performance: Ambos os agentes alcançaram ganhos de velocidade comparáveis (~1.9× sobre o baseline).
  • Curva de Custo: Embora o agente com estado ainda incorresse um custo fixo para enviar o "melhor código atual" (~1.500 tokens) em cada etapa, o custo total estabilizou. Em contraste, o custo sem estado continuou a subir linearmente, acumulando mais de 80.000 tokens de histórico na iteração 40.

Análise Comparativa

A razão de redução de tokens é inversamente proporcional ao tamanho da observação em relação ao resumo do estado.

• Observações Pequenas: O resumo de tamanho fixo é dramaticamente menor que o histórico acumulado, gerando altas razões de redução (9.8×).
• Observações Grandes: O agente com estado ainda precisa transmitir o artefato de código atual, limitando a razão (2.0×). No entanto, o artigo observa que conforme as iterações aumentam (ex: para 100 ou 200), a divergência entre $O(n^2)$ e $O(n)$ fará com que a razão se amplie significativamente (projetada em 4× a 7×).

Significância e Alegações

O artigo alega que a principal contribuição é a eficiência estrutural, não necessariamente a qualidade da otimização. O agente com estado alcança uma qualidade de otimização comparável ao baseline sem estado enquanto reduz drasticamente o consumo de tokens.

• Escalabilidade: O custo de $O(1)$ por iteração permite sequências de experimentos arbitrariamente longas sem truncamento de prompt ou perda de capacidade de tomada de decisão.
• Impacto Econômico: Embora as economias sejam modestas para execuções curtas, elas se tornam materiais para pesquisa em larga escala (centenas de experimentos diariamente), onde o custo quadrático da execução sem estado torna-se um gargalo dominante.
• Perspectiva Futânea: Os autores sugerem que, à medida que os horizontes de experimentação se alongam, o custo quadrático de tokens da execução sem estado se tornará a principal restrição, tornando as arquiteturas com estado essenciais para a experimentação autônoma sustentável.

Os autores mantêm a modéstia quanto à qualidade da otimização, declarando explicitamente que as diferenças observadas nas métricas estão dentro do ruído e não devem ser interpretadas como vantagens de qualidade do método com estado. O foco permanece estritamente nos ganhos de eficiência decorrentes da mudança arquitetônica.