Resumo Técnico: LibEvoBench

Definição do Problema

O desenvolvimento de software moderno depende fortemente de bibliotecas de terceiros que evoluem de forma independente, resultando frequentemente em bases de código de produção presas a versões mais antigas enquanto as APIs continuam a mudar. Isso cria um "contexto de desenvolvimento específico de versão", onde a correção de uma chamada de API não depende da biblioteca em geral, mas da versão exata especificada no manifesto de dependências do projeto.

Os Grandes Modelos de Linguagem (LLMs) atuais são treinados em corpora temporalmente mistos que agregam código e documentação de múltiplas versões de bibliotecas simultaneamente. O objetivo de treinamento comprime esse material heterogêneo em um único conjunto de pesos sem mecanismos explícitos de estratificação temporal. Consequentemente, os LLMs têm dificuldade com o raciocínio específico de versão, levando a erros anacrônicos: gerar código que é válido para uma versão diferente da biblioteca solicitada. Embora trabalhos anteriores tenham abordado o conhecimento temporal em domínios fatuais gerais, a geração de código consciente de versão apresenta um desafio distinto: os modelos devem distinguir entre múltiplas versões coexistentes da mesma API para evitar a produção de código que seja sintaticamente válido, mas semanticamente incorreto para o ambiente alvo.

Metodologia

Benchmark LibEvoBench

Os autores introduzem o LibEvoBench, um benchmark multi-tarefa projetado para avaliar o conhecimento de API consciente de versão em bibliotecas Python amplamente utilizadas (PyTorch, NumPy e SciPy). O benchmark abrange 29 versões de bibliotecas e inclui mais de 125.000 instâncias de avaliação.

O pipeline de construção do benchmark é totalmente automatizado:

1. Coleta de Dados: Ele minera repositórios públicos do GitHub com arquivos requirements.txt fixos para reunir contextos de código do mundo real.
2. Reconstrução da Superfície da API: Ele reconstrói a superfície pública da API para cada versão usando duas fontes complementares: inventários oficiais de documentação Sphinx e introspecção direta em tempo de execução. Uma API é considerada presente apenas se ambas as fontes concordarem, criando uma verdade fundamental (ground truth) determinística.
3. Classificação de API: Com base em matrizes de compatibilidade, as APIs são classificadas como Estáveis (assinatura inalterada através das versões) ou Em Evolução (adicionadas, removidas ou modificadas).

Tarefas de Avaliação

O LibEvoBench avalia três modalidades distintas de conhecimento:

1. Chamada de API (API-C): Dado um trecho de código incompleto, o modelo deve gerar a chamada de API ausente. Esta tarefa utiliza quatro níveis de redução de ruído (L0–L3) para isolar diferentes capacidades:
   • L0: Apenas contexto de código bruto.
   • L1: Código + docstring redigida (isola o recall da recuperação).
   • L2: Código + docstring + restrição de versão explícita (testa a consciência de versão).
   • L3: Nome da API + versão (testa o recall de parâmetros refinado).
2. Identificação de API (API-I): Dado um caminho de módulo e uma descrição redigida, o modelo deve identificar o nome correto da API. Isso isola o conhecimento declarativo do raciocínio composicional.
3. Recall de Assinatura (SR): Dado apenas o nome completo da API e uma versão alvo, o modelo deve reproduzir a assinatura completa da função a partir da memória. Isso sonda o conhecimento paramétrico de argumentos, padrões e ordenação.

Taxonomia de Alucinação

Um novo sistema de classificação determinístico é introduzido para categorizar os erros do modelo com base na superfície da API indexada por versão:

• Correto: Corresponde à verdade fundamental na versão alvo.
• Desconhecido: O símbolo previsto nunca apareceu em nenhuma versão observada (fabricação).
• Inválido: O símbolo existe na versão alvo, mas não é o pretendido (confusão de recuperação).
• Anacrônico: O símbolo existe no histórico da biblioteca, mas não na versão solicitada (confusão temporal). Esta categoria isola especificamente erros onde o modelo confunde versões em vez de alucinar símbolos inexistentes.

Pontuação de Compreensão de Evolução de Software (SEUS)

Para agregar o desempenho, os autores propõem o SEUS, uma métrica composta que penaliza a inconsistência e o anacronismo. É calculado como a média harmônica das pontuações em APIs Estáveis e em Evolução, ajustada por:

• Penalidade de Estabilidade: Penaliza a variância no desempenho através de diferentes versões de APIs em Evolução.
• Penalidade de Anacronismo: Penaliza a taxa de previsões anacrônicas.

Resultados Principais

Os autores avaliaram modelos proprietários de fronteira (OpenAI GPT-4.1 através de GPT-5.5, Anthropic Claude Sonnet 4/4.6, Google Gemini 2.0/2.5/3 Flash) e a família de pesos abertos Qwen-3.5 (35B, 122B, 397B).

1. Inconsciência de Versão (Version-Obliviousness): Modelos de estado da arte são amplamente inconscientes de versão. O desempenho em APIs em Evolução degrada significativamente à medida que as versões da biblioteca se tornam mais novas, enquanto o desempenho em APIs Estáveis permanece constante. Mesmo os modelos mais fortes (ex: GPT-5.5, Sonnet 4.6) exibem um gap persistente de 7 a 10 pontos de precisão entre APIs Estáveis e em Evolução.
2. Limitação Estrutural: A degradação é uma propriedade estrutural do processo de treinamento, não uma limitação da escala do modelo. Dentro da família Qwen-3.5, o aumento do tamanho do modelo melhora o desempenho absoluto, mas não altera a tendência de queda nas APIs em Evolução.
3. Ineficácia de Restrições Explícitas: Fornecer uma restrição de versão de biblioteca explícita no prompt (L1→L2) não produz melhoria mensurável na precisão. Isso sugere que, embora a tag de versão dispare uma resposta, o modelo carece do conhecimento diferenciado por versão subjacente para sustentá-la.
4. Benefício da Documentação: Fornecer a documentação relevante (L0→L1) resulta em uma melhoria consistente de 10 a 20 pontos, indicando que os modelos podem recuperar e usar informações quando estas são tornadas explícitas, mas falham em internalizá-las durante o treinamento.
5. Análise de Erro: Os erros são impulsionados principalmente pela confusão, não pela fabricação. Os modelos frequentemente produzem símbolos válidos, porém incorretos, da mesma biblioteca (Inválido) ou símbolos de diferentes versões (Anacrônico). Erros anacrônicos constituem uma fração substancial dos erros de nível de parâmetro (6–14% em Signature Recall), intensificando-se com versões alvo mais recentes.

Significância e Contribuições

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

1. LibEvoBench: Um novo benchmark de larga escala para avaliar quão bem os LLMs navegam em APIs em evolução, apresentando uma verdade fundamental determinística e indexada por versão que evita as limitações heurísticas de trabalhos anteriores.
2. Métrica SEUS: Uma métrica unificada projetada para rastrear o progresso na compreensão da evolução de software, penalizando explicitamente o conhecimento inconsistente de versão e os erros anacrônicos.
3. Evidência Empírica de um Gap de Capacidade: A avaliação estabelece que os LLMs atuais são fundamentalmente inconscientes de versão. Os achados destacam que nem a escala do modelo nem os dados de treinamento recentes provaram ser suficientes para fechar o gap na estratificação do conhecimento temporal.

Os autores concluem que a estratificação do conhecimento temporal na geração de código é um gap de capacidade persistente e de primeira classe. Os resultados motivam a necessidade de novas abordagens de treinamento e recuperação que possam fundamentar a geração de código em contextos temporalmente específicos, indo além da geração de código estático para dominar a evolução contínua e diferenciada por versão dos ecossistemas de software do mundo real.