Resumo Técnico: DELULU – Um Benchmark Multilíngue Verificado para Detecção de Alucinações em Código em Tarefas de Preenchimento no Meio

Declaração do Problema

Modelos de Linguagem de Grande Escala (LLMs) utilizados para geração de código frequentemente produzem alucinações em tarefas de Preenchimento no Meio (FIM). Trata-se de complementos que são sintaticamente válidos e semanticamente plausíveis, mas factualmente incorretos, como métodos de API inventados, parâmetros inválidos, variáveis não definidas ou imports inexistentes. Embora esses erros frequentemente passem por revisões de código superficiais, eles introduzem bugs latentes em tempo de execução que se manifestam apenas sob condições específicas de execução.

Os benchmarks atuais para geração de código (por exemplo, HumanEval, MBPP) focam principalmente na geração em nível de função a partir de especificações em linguagem natural ou carecem de verificação de execução para tarefas FIM. Os benchmarks FIM existentes (por exemplo, HumanEval Infilling, SAFIM) são frequentemente limitados ao Python, não distinguem entre tipos de erro e carecem de uma verdade fundamental baseada em execução para verificar se as alucinações realmente causam falhas em tempo de execução. Além disso, não há uma avaliação sistemática de se os LLMs de ponta podem detectar essas alucinações de forma confiável ao atuar como revisores de código.

Metodologia: O Benchmark DELULU

Os autores introduzem o DELULU, um benchmark multilíngue verificado composto por 1.951 amostras FIM em 7 linguagens de programação (Python, Java, TypeScript, Go, Rust, C#, C++) e 4 categorias de alucinação. O benchmark é construído por meio de um pipeline adversarial rigoroso de cinco estágios, projetado para garantir dificuldade, correção e verificação de execução:

1. Geração de Alucinação: Utilizando o CLAUDE SONNET como único gerador, o sistema cria variantes "alucinadas" de complementos dourados extraídos de repositórios reais do GitHub. O gerador é restrito a modificar exatamente um elemento (nome de método, parâmetro, variável ou importação), mantendo o restante do código idêntico, garantindo que a alucinação seja plausível e indistinguível do código real superficialmente.
2. Avaliação por Juízes Multi-Modelo: Quatro LLMs diversos de ponta (GPT-5.1, GPT-5.2, GPT-5.2-CODEX, GLM-4.7) avaliam independentemente os pares.
3. Amostragem Adversarial Iterativa: O pipeline analisa discordâncias entre juízes e utiliza agrupamento baseado em embeddings para minerar novos exemplos de código semanticamente similares que se assemelham aos modos de falha dos juízes. Este loop é executado por três iterações, expondo progressivamente amostras mais difíceis à medida que a precisão dos juízes diminui ao longo do tempo.
4. Seleção Baseada em Dificuldade: As amostras são pontuadas com base em sua capacidade de enganar os juízes. Apenas amostras que são difíceis o suficiente para enganar pelo menos um juiz (ou causar rejeição excessiva de código dourado) são mantidas.
5. Verificação de Execução Baseada em Docker: Este é o diferenciador crítico. Cada amostra é embalada em um contêiner Docker autossuficiente.
   • O complemento dourado deve compilar e executar sem erros.
   • O complemento alucinado deve produzir um erro de tempo de execução específico e verificável correspondente à sua categoria:
     • Método: AttributeError
     • Parâmetro: TypeError
     • Variável Não Definida: NameError
     • Importação: ImportError
   • Um loop de correção assistido pelo CLAUDE SONNET resolve problemas de dependência para garantir o sucesso da verificação.
6. Revisão por Especialistas Humanos: Um painel de três especialistas humanos revisa as amostras verificadas por Docker para remover viés residual, casos triviais ou erros de rotulagem, resultando no conjunto de dados final de 1.951 amostras.

Principais Contribuições

1. Taxonomia de Alucinação de Quatro Categorias: Uma taxonomia estruturada onde cada categoria (Método, Parâmetro, Variável Não Definida, Importação) mapeia para uma classe distinta e verificável de erro em tempo de execução, permitindo uma verdade fundamental baseada em execução.
2. Pipeline de Curadoria Adversarial: Um processo inovador de cinco estágios que emparelha código do mundo real com contrapartes alucinadas, filtra casos triviais por meio de sondagem multi-modelo e garante verificação baseada em execução.
3. Conjunto de Dados Multilíngue Verificado por Execução: 1.951 amostras em 7 linguagens, cada uma embalada como um contêiner Docker autossuficiente com três modos de invocação (verificar dourado, verificar alucinado, verificar correção).
4. Avaliação Abrangente: Uma avaliação de 11 modelos FIM de peso aberto de 5 famílias (Qwen2.5-Coder, CodeLlama, DeepSeek-Coder-V2, StarCoder2) abrangendo de 0,5B a 32B parâmetros.
5. Estudo de Detecção por Juízes de Ponta: Uma avaliação de 8 LLMs de ponta atuando como revisores de código para detectar alucinações, revelando lacunas significativas nas capacidades de detecção.

Resultados

Desempenho de Geração

• Limites de Escala: O modelo mais forte, Qwen2.5-Coder-32B, alcançou apenas 84,5% de pass@1 nos 950 contextos FIM únicos. Isso indica que, mesmo com 32B parâmetros, os modelos falham em aproximadamente um em cada sete contextos únicos.
• Consistência entre Famílias: A dificuldade é intrínseca à tarefa, não específica a uma família de modelos. Nenhum modelo entre famílias diferentes superou 0,77 de Similaridade de Edição. Mesmo o melhor modelo entre famílias (DeepSeek-Coder-V2-Lite-Instruct) ficou atrás do melhor modelo Qwen por 1,8 pontos de pass@1.
• Tipos de Alucinação: As alucinações de importação foram consistentemente a categoria mais difícil em todos os tamanhos de modelo e linguagens (por exemplo, 77,1% de pass@1 para Qwen-32B em importações versus >85% em outros tipos), sugerindo que detectar imports falsos requer conhecimento específico do ecossistema e não apenas conclusão de padrões locais.
• Ajuste por Instrução: O ajuste por instrução melhorou significativamente o comportamento de "parada" (Correspondência Exata), mas teve impacto mínimo no conhecimento subjacente necessário para evitar a alucinação de identificadores (Similaridade de Edição e CodeBLEU permaneceram similares entre modelos base e instruct).

Desempenho de Detecção

• Detecção Não Resolvida: Mesmo o modelo juiz mais forte, Claude-4.5-Opus, alcançou apenas 92,1% de precisão em ambos corretos (aceitar corretamente o dourado e rejeitar o alucinado).
• Lacuna de Detecção: Juízes menores performaram significativamente pior (por exemplo, GPT-4o-mini em 52,3%), estabelecendo uma faixa de capacidade de 40 pontos.
• Gargalo de Importação: A detecção de alucinações de importação permaneceu a tarefa mais difícil para todos os juízes (83,4% para Opus), confirmando que distinguir nomes de pacotes reais de falsos é uma lacuna de capacidade persistente.
• Falsos Negativos: O principal gargalo para os juízes foi rejeitar complementos alucinados, e não aceitar os dourados.

Significado e Alegações

O artigo afirma que o DELULU aborda uma lacuna crítica na avaliação de código ao fornecer o primeiro benchmark que simultaneamente oferece:

1. Categorização sistemática de alucinações com tipos de granularidade fina.
2. Cobertura multilíngue além do Python.
3. Verificação baseada em execução garantindo que alucinações produzam erros reais de tempo de execução.
4. Calibração de dificuldade adversarial garantindo que o benchmark seja genuinamente desafiador.

Os autores enfatizam que a dificuldade exposta pelo DELULU é intrínseca à tarefa e não específica a uma família, conforme evidenciado pelas taxas de falha consistentes em diversas arquiteturas de modelos. Os resultados sugerem que simplesmente escalar os parâmetros do modelo é insuficiente para resolver a alucinação de código; intervenções direcionadas, como curadoria de dados de treinamento e ajuste fino no estilo de verificador, são provavelmente necessárias.

O artigo posiciona o DELULU não apenas como um benchmark de geração, mas como uma ferramenta reutilizável para avaliar modelos de revisão de código e verificadores, destacando que a capacidade de detectar alucinações é atualmente um problema não resolvido, mesmo para modelos de ponta. O benchmark é lançado como um artefato apenas para testes para prevenir contaminação, com os autores desencorajando explicitamente o ajuste fino no conjunto de dados.