OpenAI lança novos benchmarks para programação de IA em línguas com poucos recursos

A OpenAI lançou duas novas avaliações voltadas para "linguagens de programação com poucos recursos": o MultiLangBench exige que os modelos implementem, em zero, um mecanismo de banco de dados compatível com SQLite usando 20 linguagens distintas; outra avaliação exige que os modelos migrem programas COBOL para C++, Java, Kotlin, Python ou Rust, mantendo o comportamento original. Os resultados oficiais mostram que o GPT‑6 Astra alcançou uma taxa média de aprovação nos testes de 87,4% no MultiLangBench, enquanto o GPT‑6.1 Sol atingiu 97,9% de precisão na migração COBOL sob alta intensidade de raciocínio. Isso indica que a capacidade de programação da IA está se expandindo além de linguagens dominantes como Python e JavaScript para incluir tecnologias antigas ainda utilizadas por bancos, governos e instituições de pesquisa. No entanto, esses resultados foram obtidos em avaliações projetadas e executadas pela OpenAI; 87,4% representa a proporção de casos de teste aprovados e não indica que o modelo já implementou uma versão viável para produção do SQLite, nem 97,9% pode ser interpretado como a possibilidade de bancos migrarem sistemas críticos sem revisão humana.

Autor do artigo, fonte: OpenAI

Na área de programação com IA, línguas de baixo recurso referem-se a línguas com poucos códigos públicos, documentação e materiais de perguntas e respostas disponíveis para treinamento de modelos, e não significam que essas línguas careçam de valor prático.

Python e JavaScript possuem grandes ecossistemas de código aberto, permitindo que os modelos vejam uma grande quantidade de código, relatórios de erros e registros de correções durante o treinamento. Já os materiais públicos para COBOL, Fortran, Visual Basic e OCaml são muito menos abundantes, e muitos desses códigos ainda permanecem armazenados em sistemas internos de empresas.

Ao mesmo tempo, essas linguagens ainda desempenham tarefas cruciais. A OpenAI citou dados da IBM, afirmando que o COBOL sustenta mais de 40% dos sistemas de banco online, 80% das transações de cartão de crédito presenciais e 95% das transações de caixas eletrônicos; o Fortran continua sendo utilizado em previsões do tempo e análise de segurança de reatores nucleares.

Manter esses sistemas não é apenas difícil por causa da sintaxe obsoleta. Os desenvolvedores originais podem já ter deixado a empresa, e a documentação não está completa; as regras de negócio reais estão apenas no código. Por que um programa corta casas decimais ou como trata registros de contas inexistente pode não ter nenhuma explicação, mas afeta diretamente os resultados de cálculos financeiros.

Portanto, o que a IA realmente precisa provar não é “se consegue traduzir COBOL para Python que pareça mais moderno”, mas sim se, após a migração, ainda executa exatamente as mesmas regras de negócio.

A OpenAI lançou o MultiLangBench para isso. Ele exige que o modelo construa, durante um processo de programação mais longo, um mecanismo de banco de dados compatível com SQLite usando a linguagem especificada.

O programa candidato receberá um arquivo de banco de dados inicial e uma consulta SQL; após a execução, produzirá um banco de dados modificado. O sistema de avaliação então chama a implementação oficial do SQLite para verificar se o conteúdo do banco de dados corresponde ao resultado padrão. Através do arquivo de banco de dados como interface comum, o mesmo conjunto de funcionalidades pode ser comparado entre linguagens.

Cobertura de teste para 20 linguagens, incluindo C, C++, COBOL, Fortran, Java, JavaScript, Lean, OCaml, Python, Rust, Visual Basic e Zig, avaliando a capacidade do modelo de organizar repositórios de código, gerenciar estado, tratar erros, adicionar novas funcionalidades e evitar quebrar funcionalidades existentes. Os casos de teste são adaptados do conjunto de testes existente do SQLite.

Com a máxima intensidade de raciocínio, a GPT-6 Astra alcançou uma taxa média de aprovação nos testes de 87,4%, enquanto a GPT-5.6 Sol atingiu 26,8%. A OpenAI afirmou que a Astra apresentou melhorias em todas as 20 línguas:

COBOL aumentou de 10,9% para 72,1%, OCaml aumentou de 25,6% para 85,8%, Fortran aumentou de 21,4% para 83,5%, Visual Basic aumentou de 27,5% para 89,4%. Dentre 20 linguagens, 19 superaram 83%, e COBOL continua sendo a mais difícil.

(Módulo interativo com 20 idiomas alternativos, onde você pode visualizar os desempenhos e custos de cada modelo em cada idioma.)

Esses números precisam ser compreendidos corretamente. 87,4% é a proporção média de aprovação dos casos de teste e não indica que o modelo tem 87,4% de probabilidade de gerar um banco de dados completo, estável e totalmente compatível com todas as especificações do SQLite. Os cerca de 12,6% de falhas nos testes ainda podem corresponder a problemas suficientes para impedir a implantação em produção, como transações, tratamento de erros ou consistência de dados.

Isso prova que o modelo pode continuar construindo software mais complexo em idiomas desconhecidos, e não que o SQLite já possa ser reescrito de uma só vez pela IA.

A OpenAI também testou o GPT-6 Luna, com custo mais baixo. Ele obteve uma taxa média de aprovação de 40,3% em 20 idiomas, superando os 26,8% do GPT-5.6 Sol.

O custo médio da API da Luna é de aproximadamente US$ 0,77 por amostra, enquanto o GPT‑5.6 Sol é de cerca de US$ 3,48, uma redução de aproximadamente 78%. No entanto, seu desempenho não atingiu o nível da Astra: a Luna obteve apenas 17,1% em COBOL, 31,4% em Fortran e 41,6% em Visual Basic.

Este conjunto de resultados apresenta duas abordagens distintas: Astra utiliza mais recursos de raciocínio para maximizar a conclusão de tarefas complexas; já Luna processa mais amostras com custos mais baixos, sendo ideal para tentativas em massa, análises preliminares e tarefas auxiliares de baixo risco.

O chamado custo é apenas uma estimativa das taxas da API no contexto da avaliação e não inclui os recursos necessários para revisão de engenheiros, ambiente de teste, aceitação comercial e correção de erros. Para sistemas legados, as taxas de chamada do modelo geralmente não são o maior custo do projeto de migração.

O segundo critério de avaliação exige que o modelo migre um programa COBOL para C++, Java, Kotlin, Python ou Rust.

O foco do teste não é se o código da tradução está limpo, mas se a saída observável dos programas antigo e novo é idêntica byte a byte. Cada resultado de migração deve passar em todos os testes ocultos para ser considerado bem-sucedido.

A OpenAI destacou especificamente o exemplo de ponto fixo: o COBOL pode descartar diretamente os dígitos decimais extras por padrão, a menos que o programa exija explicitamente arredondamento. Se o modelo alterar arbitrariamente para arredondamento, conforme os hábitos de programação modernos, o programa poderá funcionar normalmente, mas os resultados financeiros já terão sido alterados.

Com baixa intensidade de inferência, a precisão de transferência do GPT-6.1 Sol atingiu 86,6%, enquanto o GPT-5.6 Sol alcançou apenas 5,4%; o custo estimado da API do primeiro é ainda 39% mais baixo. Após aumentar a intensidade de inferência, o GPT-6.1 Sol atingiu 97,9%, aproximando este conjunto de avaliações da saturação.

Os 97,9% aqui referem-se à "proporção de programas que passaram completamente nos casos ocultos neste teste da OpenAI", e não à "qualquer sistema COBOL ter 97,9% do código que pode ser migrado automaticamente com segurança".

Sistemas bancários reais podem estar conectados a mainframes, bancos de dados proprietários, agendadores de processamento em lote e protocolos de comunicação internos, além de apresentarem fluxos excepcionais não cobertos por casos de teste. A OpenAI também afirmou explicitamente que a migração para produção ainda requer revisão por especialistas e retestagem em relação às regras de negócio e dependências reais.

OpenAI já enviou o ambiente de avaliação, o conjunto de testes e os resultados por idioma do MultiLangBench ao GitHub, permitindo que desenvolvedores verifiquem o conteúdo dos testes e os reexecutem com outros modelos ou frameworks de Agentes.

Isso é mais valioso do que apenas exibir uma tabela de desempenho: externos podem observar em quais funções SQL o modelo falhou e comparar se os resultados foram afetados por prompts, permissões de ferramentas, orçamento de raciocínio e duração da execução.

No entanto, o artigo oficial apenas anunciou a liberação do MultiLangBench, sem mencionar que as amostras completas do programa de avaliação de migração COBOL e os testes ocultos também já estão disponíveis. O desempenho de 97,9% deste último não pode ser verificado ou reproduzido externamente, como ocorre com o MultiLangBench.

Ambos os testes também foram desenvolvidos pela OpenAI e são principalmente utilizados para comparar os próprios modelos da OpenAI. Eles ainda não abrangem grandes repositórios de código empresarial real, custos de manutenção a longo prazo, vulnerabilidades de segurança, degradação de desempenho e o tempo necessário para revisão humana. Portanto, os resultados demonstram, em primeiro lugar, o progresso dos modelos em tarefas controladas, e não uma validação final da resolução do problema de modernização de software empresarial.

Nos últimos dois anos, as demonstrações de produtos de programação baseados em IA concentraram-se principalmente na criação de páginas da web, aplicativos móveis e ferramentas Python. Esses cenários são intuitivos, mas não são os problemas de software mais caros para grandes empresas.

O que bancos, seguradoras, governos e instituições de pesquisa realmente têm dificuldade em lidar são códigos que funcionam há décadas e que ninguém ousa alterar facilmente. Eles podem não ser modernos, mas contêm as regras essenciais para processamento de contas, cálculo de impostos, cadeias de suprimentos e operação de infraestrutura.

O significado do MultiLangBench está aqui: a capacidade do modelo pode se desvincular da linguagem de treinamento mais comum e aplicar métodos de engenharia de software a pilhas tecnológicas com recursos escassos, ferramentas desatualizadas e custos de erro mais altos.

Se essa capacidade continuar a melhorar, a mudança mais inicial trazida pela IA pode não ser “excluir todos os COBOL com um clique”, mas sim ajudar engenheiros a ler código desconhecido, completar testes, recuperar documentação ausente e localizar regras de negócio, antes de realizar migrações verificadas módulo por módulo. Especialistas humanos ainda serão responsáveis por decidir quais comportamentos devem ser mantidos e quando é possível substituir realmente os sistemas antigos.