SemVerBench mede se LLMs entendem regras de versão

O que aconteceu

O SemVerBench é o primeiro benchmark criado para medir diretamente se LLMs entendem a semântica de resolução de restrições de versão, o conjunto de regras que define se um número como 2.1.4 atende a um pedido como ^1.2.3. O benchmark foi publicado no arXiv em 10 de setembro de 2026 (arXiv:2609.11180v1) e cobre três ecossistemas de software: npm, PEP 440 e Cargo.

O conjunto tem 240 itens verificáveis por máquina, cada um com resposta única. A construção foi feita de forma neutra em relação aos autores, a partir de quatro fontes equilibradas: a suíte de testes oficial de cada ecossistema mais três modelos de fronteira que propuseram itens. A rotulagem ficou a cargo de um oráculo de duas implementações independentes, desenhado para evitar circularidade. Ou seja, o gabarito do SemVerBench não depende da resposta de nenhum modelo.

Seis modelos de fronteira foram avaliados. O padrão de erro é sistemático e previsível por mecanismo. A regra do comparador parcial com carry, em que >1.2 significa >=1.3.0, derruba todos os modelos no ecossistema Cargo, com taxa de erro perto de 60%. A correspondência de prefixo padrão do PEP 440 é universal: nessa parte, os modelos acertam tudo. Mas nos casos de borda de zero-pad e pós-lançamento o GPT-5.1 desaba, com 0 acerto em 26 itens. O Claude mantém entre 97% e 100% nos mesmos casos, resultado verificado em um conjunto de 67 itens validado pelo oráculo.

Na comparação geral, o Opus supera de forma estatisticamente significativa todos os outros modelos. Já o Sonnet supera os modelos da OpenAI, família que inclui o GPT-5.1 e o GPT-5, segundo o teste de McNemar. Os modelos da OpenAI avaliados pelo SemVerBench ficaram atrás dos dois modelos Claude medidos.

Contexto

Agentes de código tomam decisões de versão o tempo todo, quase sempre sem que ninguém veja. Instalar uma dependência, rodar uma atualização, verificar se um pacote é compatível com o projeto: cada uma dessas etapas exige julgar se uma versão cai dentro de uma faixa. Até agora, esse julgamento nunca havia sido medido de forma direta. O SemVerBench chega para preencher essa lacuna.

A escolha de três ecossistemas distintos não é acidental. npm, PEP 440 e Cargo têm regras próprias, e algumas delas são notoriamente contraintuitivas. O caso do comparador parcial é o exemplo mais claro: quem lê >1.2 tende a pensar em qualquer coisa acima de 1.2, mas a regra correta no Cargo exige >=1.3.0. É exatamente nesse ponto que todos os modelos testados tropeçam.

O dado mais revelador do estudo é a natureza do erro. Quando os autores injetam a regra ou dão uma dica leve e correta, a maior parte dos erros se recupera. Quando tentam decomposição de intervalos, não. Os modelos também estão no teto nas formas básicas das mesmas regras. A leitura dos pesquisadores é que existe uma lacuna de ativação e aplicação, não de conhecimento.

Por que importa

Quem escreve código com apoio de agentes ganha e perde com isso. Uma resolução de versão errada pode quebrar um build, instalar um pacote incompatível ou deixar uma dependência vulnerável no projeto. Como o erro não aparece como erro, e sim como uma instalação que parece ter dado certo, o custo só surge depois.

A análise estratificada por autor também traz um resultado relevante para quem desconfia de benchmarks construídos por empresas de IA. O estudo não encontrou favoritismo estatisticamente significativo dos modelos em relação aos itens que eles próprios propuseram. Os três modelos de fronteira que contribuíram com itens não se saíram melhor nos itens que criaram.

Impacto

O impacto de curto prazo é operacional. A tarefa de resolver versão é verificável e existe um resolvedor livre e 100% correto. Quando os agentes delegam a esse resolvedor em vez de raciocinar sobre versões de cabeça, a taxa de acerto chega a cerca de 100%. O próprio artigo recomenda essa delegação.

Os modelos da OpenAI aparecem como o caso mais crítico do estudo por causa do colapso do GPT-5.1 nos itens de zero-pad e pós-lançamento do PEP 440. O Claude, medido pelo SemVerBench, se manteve estável nesses mesmos itens. Opus e Sonnet, ambos avaliados no benchmark, ficaram à frente dos modelos da OpenAI na comparação estatística.

O que muda

A recomendação prática do SemVerBench é direta: agentes de código devem delegar a resolução de versão a um resolvedor, não tentar resolvê-la internamente. O motivo é simples. O problema tem gabarito verificável e ferramenta gratuita que acerta 100% das vezes, o que transforma o raciocínio do modelo em risco desnecessário.

O segundo ponto é o uso de pistas. Injetar a regra ou uma dica leve e correta recuperou a maioria dos erros no experimento. Isso sugere que prompts de sistema com as regras de versão do ecossistema usado podem reduzir falhas sem trocar de modelo.

O que vem agora

O SemVerBench está publicado no arXiv e descreve 240 itens abertos à verificação por máquina, o que permite reprodução independente. O material não indica cronograma de adoção por ferramentas de código nem planos de expansão para outros ecossistemas além de npm, PEP 440 e Cargo.

A expectativa imediata é que a delegação a resolvedores vire prática padrão em agentes de programação, já que o ganho medido no estudo vai de taxas de erro de dois dígitos para perto de 100% de acerto. Para os modelos da OpenAI e para o Claude, o resultado serve como mapa de pontos cegos: as regras de borda de cada ecossistema, não as regras básicas, são onde a avaliação separa os sistemas.

Fontes

• arXiv cs.AI: SemVerBench: Benchmarking LLM Comprehension of Version-Constraint Resolution Semantics (arXiv:2609.11180v1, submetido em 10 de setembro de 2026) - https://arxiv.org/abs/2609.11180