FrontierCS 2 testou 12 agentes de IA em tarefas de P&D: o melhor passou em 58%

O benchmark FrontierCS 2 faz uma pergunta que o setor costuma evitar: um agente baseado em LLM consegue, em vez de resolver um exercício didático, dar uma contribuição digna de um artigo científico? O conjunto reúne 48 tarefas abertas em 13 áreas. Entre os 12 agentes testados, o melhor, Claude Opus 5.5, passa em 58% das suas execuções. Em 16 tarefas, nenhuma execução passou, ou seja, em um terço do conjunto o resultado é zero.

Como transformar um artigo em prova

O desenho é simples e bastante rígido. Os autores pegam um artigo científico e o código que seus criadores publicaram em acesso aberto. Em seguida, removem do repositório justamente o código que implementa a contribuição do trabalho. A parte removida passa a ser o padrão de referência humano: o patamar a ser atingido não é um limite abstrato, mas o que os pesquisadores de fato conceberam.

O agente recebe um repositório funcional sem a peça-chave e precisa reconstruí-la ou superá-la. As tarefas cobrem 13 domínios: sistemas de aprendizado de máquina, computação de alto desempenho, bancos de dados, segurança, robótica e outros. Além das 48 tarefas publicadas, o FrontierCS 2 tem um conjunto fechado com mais de 100 tarefas, que será anunciado depois. Ele serve de proteção contra overfitting ao benchmark público: não dá para ajustar o agente àquilo que ele nunca viu.

Um ambiente de pesquisa em vez de uma única tentativa

Os benchmarks abertos anteriores costumavam entregar ao agente o enunciado da tarefa e avaliar um único programa após o fim da execução. O FrontierCS 2 muda esse formato: o agente trabalha dentro de um ambiente de pesquisa e pode enviar um patch a qualquer momento. Para cada patch, o avaliador devolve uma nota em um conjunto de desenvolvimento. Esse é um sinal que permite melhorar a solução de forma iterativa, como faria uma pessoa.

Já o avaliador em si, o conjunto final de testes reservado e a solução de referência permanecem fechados. O envio final é verificado em um conjunto oculto e comparado com a referência. O agente pode ajustar a solução à métrica visível, mas ela será avaliada com dados que ele não observou.

Nota alta ainda não é aprovação

O ponto mais interessante dos resultados não é o número 58%, e sim a diferença entre nota e aprovação. A maioria das execuções que superaram a referência na pontuação final somada ainda assim não passou: elas falharam em uma métrica específica ou em uma carga de trabalho específica. Para trabalhos de sistemas, esse quadro é típico. Uma otimização de banco de dados ou de kernel de HPC que acelera um cenário e quebra outro é inútil em produção, e o benchmark leva isso em conta.

Os autores também construíram uma escala comum de capacidade para agentes e tarefas. A tarefa mediana ficou com uma dificuldade aproximadamente igual à que o agente mais forte consegue resolver. O conjunto não é fácil demais, caso contrário os resultados bateriam no teto, nem inalcançável de saída. Ele deixa margem para medir o progresso dos próximos modelos.

Parâmetros principais

• 48 tarefas abertas em 13 domínios, mais um conjunto fechado com mais de 100 tarefas
• 12 agentes testados
• Melhor resultado: Claude Opus 5.5, com 58% das execuções aprovadas
• 16 tarefas em que nenhuma execução passou
• O agente pode enviar patches a qualquer momento e recebe uma nota no conjunto de desenvolvimento
• O avaliador, o conjunto final de testes e a referência ficam ocultos do agente

O que observar em equipes que constroem agentes

Para quem desenvolve agentes de programação e pipelines de pesquisa, o benchmark traz três lições práticas. Primeiro, a avaliação deve usar um conjunto de métricas e cargas de trabalho, e não um único número agregado: o ganho médio esconde regressões. Segundo, vale testar separadamente a capacidade de iterar com base no feedback do conjunto de desenvolvimento e de se sustentar no conjunto oculto, porque é aí que o agente se diferencia de um simples gerador de código. Terceiro, a falha nas 16 tarefas mostra onde está o teto. São tarefas que exigem não só habilidade de programação, mas também intuição de pesquisa, e o conjunto fechado permitirá ver se esse teto se move nas próximas gerações de modelos.