ResearchEnvBench: Benchmarking Agents on Environment Synthesis for Research Code Execution

O artigo apresenta o ResearchEnvBench, um novo benchmark que avalia a capacidade de agentes autônomos de sintetizar ambientes de execução para código de pesquisa, revelando lacunas significativas nas soluções atuais quanto à resolução de dependências e compatibilidade de versões.

O essencial

Imagine que você tem um livro de receitas incrível para fazer um bolo de chocolate perfeito (o código de pesquisa). Você pede para um robô superinteligente (o agente de IA) preparar tudo para você fazer o bolo.

Até agora, os testes para esses robôs eram fáceis: eles chegavam em uma cozinha já pronta, com a farinha, o açúcar e o forno pré-aquecidos. O robô só precisava misturar os ingredientes. Se o bolo saísse, o robô passava no teste.

Mas, na vida real da ciência, não é assim. O robô chega em uma cozinha vazia, sem nada. Ele precisa:

1. Comprar os ingredientes certos (instalar bibliotecas).
2. Garantir que o forno seja compatível com o tipo de massa (alinhamento de hardware/CUDA).
3. Consertar a torneira se ela estiver vazando (resolver dependências complexas).
4. E, o mais importante: fazer o bolo realmente assar e ficar bom.

O ResearchEnvBench é o novo "exame de cozinha" que os cientistas criaram para ver se esses robôs conseguem fazer tudo isso sozinhos, sem ajuda humana.

O que é o ResearchEnvBench?

É um banco de testes com 44 receitas de "bolo" muito difíceis (códigos de pesquisa de Inteligência Artificial criados recentemente). Esses "bolos" exigem equipamentos especiais, como placas gráficas poderosas (GPUs), e têm instruções complicadas que muitas vezes não estão escritas claramente no livro de receitas.

O objetivo é ver se o robô consegue transformar uma cozinha vazia em um ambiente onde o código roda perfeitamente.

A "Pirâmide da Verdade" (O Teste de Nível)

Os criadores do teste não se contentam apenas em ver se o robô diz "pronto!". Eles usam uma escada de 5 degraus para verificar se o trabalho realmente funciona:

1. Degrau 1 (O Check-list): O robô leu todas as instruções? (Verificação estática).
2. Degrau 2 (A Cozinha Fria): O robô conseguiu instalar os ingredientes básicos e rodar um teste simples sem ligar o forno? (Execução em CPU).
3. Degrau 3 (O Forno Ligado): O robô conseguiu conectar o código ao "forno" especial (a placa de vídeo/GPU)? Se o código diz "use a GPU" e a GPU não responde, falhou aqui.
4. Degrau 4 (O Bolo Assando): O código realmente processou dados na placa de vídeo? (Cálculo real em GPU).
5. Degrau 5 (A Festa com Múltiplos Fornos): Para as receitas mais difíceis, o robô conseguiu fazer vários fornos trabalharem juntos? (Treinamento distribuído).

O Grande Problema Descoberto

O teste revelou uma verdade desconfortável: os robôs atuais são ótimos em parecer que estão trabalhando, mas ruins em fazer o trabalho real.

• O Efeito "Falso Positivo": Muitos robôs instalaram os pacotes e disseram: "Tudo pronto! O código vai rodar!". Mas, quando os cientistas ligaram o forno, o bolo queimou ou não assou.
• A Alucinação de Capacidade: Os robôs muitas vezes "alucinam". Eles dizem: "Sim, tenho a placa de vídeo instalada!" quando, na verdade, ela não está configurada corretamente. É como um cozinheiro que diz "o forno está quente" mas, na verdade, ele está frio.
• O Abismo: Mesmo os melhores robôs conseguiram fazer o código rodar em apenas 37,5% dos casos quando exigiu o uso de múltiplos fornos (GPUs) trabalhando juntos. A maioria falhou em detalhes sutis, como versões de software que não combinam entre si.

Por que isso importa?

Imagine que você quer que um robô descubra um novo remédio ou preveja o clima. Se o robô não conseguir configurar o laboratório (o ambiente) corretamente, ele nunca vai conseguir testar a hipótese, não importa quão inteligente seja o código que ele escreveu.

O ResearchEnvBench é como um "treinamento de sobrevivência" para esses robôs. Ele força eles a aprenderem a lidar com os problemas chatos e difíceis da vida real (como drivers de vídeo, compiladores e conexões complexas) antes de tentar fazer a descoberta científica.

Em resumo:
O papel diz: "Os robôs de IA estão ficando bons em escrever código, mas ainda são péssimos em preparar o terreno para rodar esse código. Precisamos de um teste que exija que eles não apenas 'instalem' as coisas, mas que provem que as coisas realmente funcionam."

Resumo técnico

Título: ResearchEnvBench: Avaliação de Agentes na Síntese de Ambientes para Execução de Código de Pesquisa

1. O Problema

Embora agentes autônomos baseados em LLMs tenham demonstrado progresso em tarefas como correção de bugs e experimentação autônoma, a maioria das avaliações atuais opera sob uma abstração crítica: assumem que um ambiente de execução pré-configurado e funcional já existe.

Na prática, especialmente em Deep Learning (DL) e Computação de Alto Desempenho (HPC), configurar esses ambientes é um gargalo notório. Envolve:

• Resolver dependências complexas de bibliotecas Python.
• Alinhar drivers de hardware (ex: CUDA) com versões de frameworks (ex: PyTorch).
• Compilar extensões C++/CUDA personalizadas.
• Configurar primitivas de comunicação distribuída.

Benchmarks existentes (como EnvBench ou Multi-Docker-Eval) focam em análise estática (verificar imports faltantes) ou sucesso na construção de contêineres, mas não verificam se o ambiente realmente consegue executar cálculos no hardware acelerador. Isso cria uma lacuna onde agentes podem "instalar" pacotes, mas falham em tornar o código de pesquisa executável e reprodutível.

2. Metodologia e Proposta

Os autores introduzem o ResearchEnvBench, um benchmark focado na síntese de ambientes para execução de código de pesquisa.

A. Construção do Dataset

• Seleção: 44 repositórios de pesquisa de alta qualidade criados após 1º de janeiro de 2024.
• Critérios: Repositórios devem ter dependências de hardware intensivas, kernels CUDA personalizados e requisitos de treinamento distribuído.
• Categorias: Cobrem visão generativa, estimativa de profundidade, áudio, inferência de LLM, engenharia de treinamento, fundações multimodais, IA de documentos e avaliação de aplicações.
• Restrições: O agente não pode modificar o código fonte rastreado (apenas criar scripts auxiliares), simulando o cenário real de "reprodutibilidade".

B. Protocolo de Avaliação: A Pirâmide de Verificação em Tempo de Execução

Diferente de verificações estáticas, o ResearchEnvBench impõe uma hierarquia estrita de validação (C0 a C4):

1. C0 (Integridade Estática): Verificação de imports faltantes (usando pyright).
2. C1 (Integridade em CPU): O ponto de entrada do modelo deve executar em CPU.
3. C2 (Alinhamento de Hardware): O framework instalado deve mapear corretamente para os drivers NVIDIA (verificação de compatibilidade CUDA).
4. C3 (Computação em GPU Única): Execução real de kernels em uma GPU.
5. C4 (Prontidão Distribuída): Configuração correta para execução distribuída multi-GPU (DDP), usando primitivas como NCCL.

C. Métrica de Alucinação de Capacidade (C5)

O benchmark introduz uma métrica para quantificar a discrepância entre o que o agente relata (autoavaliação) e a realidade (probes ocultos).

• Tipos de Alucinação: Caminho (path), Versão (version) e Capacidade (capability).
• Objetivo: Medir a confiabilidade do agente ao declarar sucesso sem ter verificado a execução real.

D. Configuração Experimental

• Ambiente: Contêineres Docker isolados (Ubuntu 22.04) com 2x NVIDIA RTX 4090 e drivers CUDA 12.4.
• Agentes Avaliados: Quatro configurações de ponta (SOTA):
  • Claude Code (com modelos GLM-4.7 e Sonnet 4.5).
  • Codex Agent (GPT-5.1-Codex).
  • NexAU Agent (DeepSeek-V3.1-Nex-N1).

3. Resultados Principais

A avaliação revelou uma lacuna significativa entre a "visibilidade da GPU" e a "prontidão do repositório":

• Queda Acentuada de Desempenho:

  • Alinhamento CUDA (C2): Alto sucesso (79.5% - 93.2%). Os agentes conseguem instalar pacotes que "enxergam" a GPU.
  • Execução Real (C3/C4): Queda drástica. A taxa de sucesso para execução em GPU única (C3) caiu para 41.9% - 48.8%, e para treinamento distribuído (C4) para apenas 34.4% - 37.5%.
  • Isso indica que ter drivers e bibliotecas instalados não garante que o código de pesquisa específico funcione.

• Falhas Comuns:

  • Extensões Nativas: Falhas em carregar operadores compilados (ex: mmcv._ext, flash_attn) que exigem compilação ABI-específica, não apenas pip install.
  • Ferramentas Auxiliares: Dependências ocultas em ferramentas como wandb ou tensorboard.
  • Stacks Mistas: Falha em gerenciar ambientes que exigem múltiplos frameworks (ex: JAX + PyTorch).

• Alucinação de Capacidade (C5):

  • Agentes tendem a ser excessivamente confiantes. O Codex foi mais conservador (menos alucinações), enquanto outros agentes frequentemente relataram sucesso ("ok") baseado apenas em logs de instalação limpos, sem executar os testes de fumaça (smoke tests).
  • O Codex teve apenas 4 alucinações totais, enquanto os outros tiveram entre 16 e 20.

• Eficiência:

  • Maior consumo de tokens não se traduziu em melhor sucesso. O agente NexAU consumiu ~20x mais tokens que o Codex, mas obteve a mesma taxa de sucesso em C4 (34.4%).
  • Agentes tendem a instalar pacotes de forma ampla ("hedge") para cobrir incertezas, aumentando o tamanho do ambiente sem resolver dependências críticas de compilação.

4. Contribuições Chave

1. ResearchEnvBench: Um benchmark rigoroso e realista focado na síntese de ambientes para pesquisa científica, com 44 repositórios complexos pós-2024.
2. Pirâmide de Verificação em Tempo de Execução: Um protocolo de avaliação hierárquico que vai além da análise estática, exigindo validação de hardware, execução em GPU e distribuição.
3. Métrica de Alucinação (C5): Uma nova métrica para quantificar a confiança excessiva dos agentes, medindo a discrepância entre relatórios e realidade.
4. Análise de Falhas: Identificação de que o gargalo não é a instalação de pacotes genéricos, mas a resolução de dependências implícitas de operadores nativos e alinhamento de ABI.

5. Significado e Impacto

O ResearchEnvBench expõe uma falha fundamental nos agentes de IA atuais para ciência: a incapacidade de garantir a reprodutibilidade real de experimentos.

• Para a Comunidade: Estabelece um novo padrão para avaliar agentes que não apenas escrevem código, mas preparam o terreno para sua execução em hardware real.
• Direção Futura: Sugere que o próximo passo para agentes autônomos em ciência não é apenas "instalar mais pacotes", mas desenvolver capacidades de depuração de compilação, resolução de dependências nativas e verificação executiva rigorosa.
• Relevância: Sem essa capacidade, a promessa de agentes autônomos para descoberta científica permanece teórica, pois os experimentos não podem ser validados ou reproduzidos de forma confiável.

O trabalho conclui que, embora os agentes estejam progredindo na configuração de infraestrutura básica, a "prontidão para pesquisa" (Research-Readiness) exige uma compreensão profunda de dependências de baixo nível e validação de execução, algo que ainda é um desafio significativo para os modelos SOTA atuais.