💬 NLP

RuBench: A Repository-Level Agentic Coding Benchmark with Natively Authored Russian Task Specifications

O RuBench é um benchmark de codificação agêntica em nível de repositório que apresenta 25 especificações de tarefas nativamente elaboradas em russo a partir de projetos de código aberto reais, projetado para avaliar agentes de codificação de nível de produto em trabalho de manutenção real, garantindo simultaneamente a resistência à contaminação de dados e revelando insights críticos sobre os comportamentos de sistemas implantados por meio de análise estatística rigorosa e auditoria de trajetórias.

Autores originais: Evgeny Shilov (Independent Researcher)

Publicado 2026-07-08

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Evgeny Shilov (Independent Researcher)

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está contratando uma equipe de mecânicos especialistas para consertar uma frota de carros de corrida complexos e personalizados. Até agora, a maioria dos testes para esses mecânicos era escrita em um inglês perfeito e formal, como um manual técnico. Mas, no mundo real, os clientes não falam como manuais; eles falam como pessoas. Eles dizem coisas como: "Meu carro começou a tremer toda vez que eu pisava nos freios em uma terça-feira chuvosa", em sua própria língua nativa.

RuBench é um novo teste projetado para ver se os assistentes de codificação de IA conseguem realmente entender esses pedidos de clientes bagunçados e do mundo real quando escritos em russo, não em inglês.

Aqui está um detalhamento de como o teste funciona, o que aconteceu e a reviravolta surpreendente que os pesquisadores encontraram, usando analogias simples.

1. O Teste: Uma Oficina de "Mundo Real"

A maioria dos testes anteriores fornecia aos agentes de IA uma descrição limpa e em inglês de um erro (bug). O RuBench é diferente:

Os Carros: O teste utiliza cinco projetos de software de código aberto reais e populares (como aiohttp ou Laravel). Estes não são quebra-cabeças falsos; são bases de código vivas usadas por milhares de desenvolvedores.
Os Pedidos: Em vez de um relatório de erro formal, os pesquisadores escreveram 25 novos pedidos do zero em russo. Eles soam como um proprietário de negócio reclamando com um empreiteiro: "O bot trava quando o tornamos administrador; conserte isso, mas não quebre os chats existentes."
A Caixa Misteriosa: Os pesquisadores esconderam a "chave de respostas" (a correção de código real e os testes que provam que ela funciona). A IA tem que descobrir a correção por conta própria. Somente os pesquisadores possuem a chave para verificar se a IA teve sucesso.
Atualização: Todos os erros foram encontrados em atualizações de código feitas após o treinamento dos modelos de IA. Isso garante que a IA não tenha apenas memorizado a resposta de seus dados de treinamento.

2. Os Mecânicos: Quem Fez o Trabalho?

Os pesquisadores testaram quatro diferentes "equipes de mecânicos" (combinações de ferramentas de software e modelos de IA). Eles passaram cada equipe pelos 25 reparos três vezes para ver o quão consistentes elas eram.

O Astro do Desempenho: A equipe que utilizou o Claude Code com o modelo "Opus 4.8" foi a melhor. Ela corrigiu com sucesso cerca de 79% dos problemas.
O Meio da Tabela: O modelo "Sonnet 5" fez quase tão bem (75%), e o "GPT-5.5" (via Codex CLI) corrigiu cerca de 67%.
O Mecânico com Dificuldades: O modelo "Haiku 4.5" (uma versão mais barata e rápida) corrigiu apenas cerca de 53% das tarefas.

A Ressalva: Como havia apenas 25 tarefas, a diferença entre as três melhores equipes não foi estatisticamente "provada" como real — poderia ser apenas sorte. No entanto, a lacuna entre as principais equipes e o modelo problemático Haiku foi enorme e clara. As equipes de elite resolveram uma classe de problemas completamente diferente daquela do grupo inferior.

3. A Grande Surpresa: A "Substituição Silenciosa"

Esta é a parte mais interessante do artigo. Os pesquisadores também testaram uma quinta equipe usando um modelo novíssimo chamado Fable 5.

Ao analisarem de perto os registros da "caixa preta" do que a IA estava fazendo, eles descobriram um segredo:

Em 20% das tarefas, o modelo Fable 5 não realizou o trabalho de fato.
Em vez disso, o produto de software (Claude Code) substituiu silenciosamente o Fable 5 pelo mais antigo e forte Opus 4.8 no meio do trabalho.
Por quê? O Fable 5 possui salvaguardas de segurança que são muito rigorosas. Quando ele viu uma tarefa envolvendo protocolos padrão de internet (como corrigir um cabeçalho web), sua salvaguarda de segurança ficou nervosa e disse: "Não tenho permissão para tocar nisso", e o sistema automaticamente entregou o trabalho ao Opus 4.8 para finalizá-lo.

A Lição: Os pesquisadores perceberam que, quando testamos produtos de IA, não estamos testando apenas o "cérebro" (o modelo); estamos testando o "corpo" (o pacote de software completo). Se o software troca o cérebro secretamente no meio da tarefa, os resultados do teste estão mentindo sobre o que aquele cérebro específico pode fazer.

4. O Veredito

Sucesso: Agentes de IA de nível de produto já são bons o suficiente para lidar com trabalhos de manutenção reais especificados em uma língua não inglesa (russo). A melhor configuração resolveu quase 8 de cada 10 tarefas.
Choque de Realidade: Os modelos "baratos" (como o Haiku) ainda são significativamente mais fracos, resolvendo apenas cerca de metade dos problemas.
Metodologia: O artigo prova que, para obter resultados honestos, devemos observar todo o "diário" (trajetória) da IA para garantir que ela não trapaceou trocando de modelo ou procurando as respostas online.

Em resumo, o RuBench mostra que a IA está ficando boa em falar "humano" (em russo), mas também revelou que o software que envolve essas IAs pode ser, às vezes, astuto, substituindo o trabalhador por um melhor sem avisar ninguém.

Resumo Técnico: RuBench 1.0

Definição do Problema

Os atuais benchmarks de codificação agêntica em nível de repositório (ex: SWE-bench) falham em avaliar uma capacidade crítica do mundo real: a habilidade de agentes de codificação interpretarem e executarem tarefas especificadas nativamente em línguas não inglesas, particularmente no estilo de solicitações de clientes, em vez de issues de GitHub curadas em inglês. Os benchmarks "multilíngues" existentes ou dependem de declarações em inglês por design ou operam ao nível de snippet/arquivo único, carecendo da complexidade de manutenção de um repositório completo. Além disso, benchmarks estáticos sofrem de vazamento de solução (solution leakage) e memorização, enquanto as avaliações frequentemente desacoplam o harness do agente do modelo, ignorando como as configurações de produtos implantadas (CLI + modelo + esforço de raciocínio) afetam materialmente o comportamento.

Metodologia

O RuBench 1.0 introduz um benchmark projetado para medir a codificação agêntica em nível de repositório com especificações nativas em russo.

Construção do Benchmark

Mineração de Tarefas: 25 tarefas foram mineradas de commits de correção mesclados entre fevereiro e junho de 2026 em cinco repositórios de código aberto ativos: aioimplies, aiogram, Laravel, NestJS e Fastify. Estes abrangem Python, PHP, TypeScript e JavaScript.
Especificações Nativas: Diferente de benchmarks traduzidos, cada tarefa apresenta uma especificação escrita do zero em russo, mimetizando o pedido de um proprietário de negócio (descrevendo sintomas, comportamento requerido e restrições) em vez de uma entrada de rastreamento de issues de um desenvolvedor. Estas especificações não existem na web pública antes do lançamento.
Portão de Atualidade (Freshness Gate): Todas as 25 tarefas são posteriores aos cortes de dados de treinamento de todos os modelos avaliados (variando de julho de 2025 a janeiro de 2026), garantindo um argumento de contaminação tarefa a tarefa.
Oráculo Privado: A graduação é realizada pelas suítes de testes de regressão dos mantenedores originais, que são retidas do lançamento público. Um manifesto SHA-256 desses oráculos é enviado para verificar a integridade sem revelar os testes.
Espaço de Trabalho: Os agentes recebem um snapshot do repositório no commit pai da correção, desprovido de histórico de git e testes de oráculo.

Protocolo Experimental

Configurações: O estudo avalia quatro configurações de produtos implantados (agente CLI + modelo + esforço de raciocínio definido como máximo):
- Claude Code com Opus 4.8
- Claude Code com Sonnet 5
- Claude Code com Haiku 4.5
- Codex CLI com GPT-5.5
- Hors concours: Claude Code com Fable 5 (lançamento de 2 de julho de 2026).
Execução: Cada configuração é executada três vezes de forma independente por tarefa em espaços de trabalho isolados com acesso à rede (necessário para instalação de pacotes).
Métricas: O desempenho é reportado como pass@1 (fração de execuções bem-sucedidas entre 3 tentativas) em média sobre 25 tarefas. A incerteza é quantificada via intervalos de confiança de Wilson de 95% ao nível de tarefa e comparações de bootstrap pareadas (10.000 reamostragens).
Auditorias de Validade: As trajetórias são auditadas para fuga de oráculo (oracle escape) e, crucialmente, para substituição de modelo (garantindo que o modelo em execução corresponda ao modelo solicitado).

Resultados Principais

Desempenho: A melhor configuração, Claude Code + Opus 4.8, resolveu 78,7% das tarefas (média sobre 3 execuções). A mais fraca, Claude Code + Haiku 4.5, resolveu 53,3%.
Significância Estatística: Com $N=25$ , o limite de resolução do benchmark é de aproximadamente 25 pontos percentuais. Lacunas estatisticamente resolvíveis (onde o intervalo de bootstrap exclui o zero) foram encontradas apenas entre o modelo mais fraco (Haiku 4.5) e os demais. Diferenças entre as três principais configurações (Opus 4.8, Sonnet 5, GPT-5.5) estavam dentro das margens de ruído.
Custo e Eficiência:
- Sonnet 5 alcançou 74,7% de resolução a 78% do custo do Opus 4.8 ($2,42 vs $3,12 por tarefa).
- Codex CLI + GPT-5.5 foi o mais eficiente em tokens (16k tokens de saída vs 33k para o Opus 4.8), mas resolveu menos tarefas (66,7%).
Descoberta de Substituição de Salvaguarda: Uma auditoria da configuração hors concours Claude Code + Fable 5 revelou que, em 5 de 25 tarefas (20%), o produto substituiu silenciosamente o modelo solicitado (Fable 5) pelo Opus 4.8 devido a gatilhos internos de salvaguarda (especificamente para correções rotineiras de protocolo HTTP). Isso resultou em uma classificação de "fallback de salvaguarda" para essas tarefas, demonstrando que o produto implantado, e não apenas o modelo, é a unidade de medida.

Significância e Alegações

O artigo reivindica três contribuições primárias:

Um Novo Protocolo de Benchmark: O RuBench é o primeiro benchmark de nível de repositório utilizando especificações nativamente autoradas em língua não inglesa com oráculos privados e um portão de atualidade, abordando a lacuna na avaliação da recuperação de intenção em língua nativa.
Medição Honesta de Incerteza: Ao reportar intervalos de confiança ao nível de tarefa e comparações pareadas, o estudo reconhece explicitamente as limitações estatísticas de benchmarks com baixo N ( $N=25$ ), evitando alegações excessivamente confiantes sobre rankings onde as lacunas não são estatisticamente resolvíveis.
Regra de Validade de Nível de Produto: A descoberta da substituição silenciosa de modelos estabelece uma regra de validade: uma avaliação só é válida se a trajetória confirmar que o modelo em execução corresponde ao modelo solicitado. Isso destaca que as avaliações de "agentes" frequentemente medem a lógica de salvaguarda e roteamento do fornecedor, em vez da capacidade bruta do modelo.

Os autores concluem que, embora agentes de nível de produto possam lidar com trabalho de manutenção real especificado em russo (78,7% de sucesso para o nível superior), o campo é atualmente mais separado pelo "nível barato" (Haiku) do que pelos modelos de fronteira, e que as avaliações futuras devem auditar trajetórias para garantir a integridade do modelo sendo testado.