Resumo Técnico: DevIntent - O quanto o código gerado por LLM viola a intenção do desenvolvedor?

Declaração do Problema

Os benchmarks atuais para Grandes Modelos de Linguagem (LLMs) em geração de código baseiam-se primariamente em taxas de aprovação de testes (ex: Pass@1) para medir a correção funcional. No entanto, esta métrica é insuficiente porque não consegue detectar violações de intenção. Um LLM pode gerar um código que satisfaça todos os casos de teste explicitamente declarados e, simultaneamente, viole restrições implícitas ou intenções não declaradas do desenvolvedor. Trabalhos anteriores documentaram casos em que modelos "manipulam" especificações ou sofrem overfitting em declarações de asserção, mas este artigo foca em um modo de falha distinto: saídas que legitimamente passam em testes declarados válidos, mas falham em capturar a real intenção do desenvolvedor.

Metodologia

1. Definição da Métrica: Taxa de Violação de Intenção (IVR)

Os autores introduzem a Taxa de Violação de Intenção (IVR) para quantificar a lacuna entre o sucesso do teste declarado e a intenção do desenvolvedor.
$$IVR = \frac{n_{violando}}{n_{passou\_declarado}}$$
Onde:

• $n_{passou\_declarado}$ é o número de soluções geradas que passam em todos os testes visíveis e declarados.
• $n_{violando}$ é o subconjunto dessas soluções que falha em pelo menos um teste de restrição oculta.

A IVR é calculada apenas sobre as soluções que passam nos testes iniciais públicos; soluções que falham nos testes declarados são excluídas. A IVR reportada é a média das IVRs por problema.

2. Construção do Benchmark

O estudo utiliza um benchmark piloto de 49 problemas de especificação de algoritmos derivados do HumanEval+.

• Engenharia de Prompt: Para cada problema, um "prompt de ouro" (contendo especificações completas) foi manualmente destituído de restrições específicas para criar um prompt ambíguo. O LLM recebe apenas este prompt ambíguo e o teste declarado ($C1$).
• Restrições Ocultas: As restrições removidas do prompt de ouro foram codificadas como testes de restrição oculta ($C2–C4$). Estes testes capturam a intenção não declarada (ex: ordem de ordenação, tipos de dados específicos) que o LLM não é explicitamente instruído a satisfazer.
• Validação: Uma auditoria de vazamento garantiu que os testes declarados ($C1$) pudessem ser satisfeitos sem o conhecimento das restrições ocultas. Soluções canônicas foram executadas contra o conjunto completo para confirmar que as restrições ocultas eram satisfatóveis por um código correto (resultando em uma IVR de 0 para o ground truth).

3. Pipeline de Avaliação

A avaliação envolveu dois modelos: Claude Sonnet 4.6 e OpenAI GPT 4.1.

• Geração: 5 soluções foram geradas por problema com uma temperatura de 1.0 e um limite de 1024 tokens.
• Execução: As soluções foram executadas contra os testes declarados ($C1$) e os testes ocultos ($C2–C4$) com um tempo limite de 5 segundos por teste.
• Análise: A IVR por problema foi calculada, e a IVR geral foi determinada como a média entre os problemas com pelo menos uma solução que passou no teste declarado. Os intervalos de confiança foram estimados via reamostragem de bootstrap.

Resultados Principais

Altas Taxas de Aprovação Declarada vs. Alta Violação de Intenção

Apesar da alta correção funcional nos testes declarados, ambos os modelos exibiram violações de intenção significativas:

• Claude Sonnet 4.6: Passou nos testes declarados 94,3% das vezes, mas violou a intenção em 54,5% dos problemas qualificados (IC 95%: 40,4–68,1%).
• OpenAI GPT 4.1: Passou nos testes declarados 92,7% das vezes, mas violou a intenção em 63,5% dos problemas qualificados (IC 95%: 50,0–76,5%).

Distribuição Bimodal Sistemática

A distribuição da IVR por problema foi encontrada como sendo bimodal, agrupando-se próximo de 0 (nenhuma violação) ou 1 (todas as soluções violam a intenção).

• 95,7% dos problemas qualificados para o Sonnet 4.6 e 91,3% para o GPT 4.1 caíram nessas categorias extremas.
• Isso indica que as violações de intenção são sistemáticas e quase determinísticas, em vez de ruído de amostragem aleatória. Os modelos ou capturam totalmente as restrições ocultas ou falham totalmente em capturá-las.

Hierarquia de Restrições

As taxas de falha nas restrições ocultas declinaram monotonicamente de $C2$ para $C4$. Para ambos os modelos, a primeira restrição removida ($C2$) teve a maior taxa de falha (aprox. 43–44%), sugerindo que a primeira restrição removida é frequentemente a mais central para a intenção da tarefa.

Significância e Alegações

O artigo alega que as taxas de aprovação padrão superestimam significativamente o quão bem o código gerado por LLM reflete a intenção do desenvolvedor.

• Lacuna de Medição: Métricas de correção funcional são insuficientes para implantação porque não conseguem detectar cenários onde o código satisfaz o conjunto de testes, mas viola pressupostos implícitos.
• Falha Sistemática: A natureza bimodal dos resultados sugere que os modelos atuais não "adivinham" a intenção aleatoriamente; eles ou inferem a intenção corretamente ou a ignoram completamente, levando a um alto risco de falhas silenciosas em prompts ambíguos.
• Ferramenta Diagnóstica: A IVR serve como um diagnóstico relativo para medir a lacuna entre especificações declaradas e a intenção real, destacando a necessidade de métodos de avaliação que vão além das simples taxas de aprovação de testes.

Limitações

Os autores reconhecem diversas restrições:

• Escopo: O benchmark é limitado a 49 problemas algorítmicos em Python; os resultados podem diferir para outras linguagens ou tipos de tarefas (ex: transformação de dados).
• Especificidade do Modelo: A avaliação foi restrita ao Sonnet 4.6 e GPT 4.1 em uma única temperatura.
• Poder Estatístico: O pequeno tamanho da amostra ($N=49$) e os intervalos de confiança sobrepostos significam que a diferença entre as taxas de violação dos dois modelos não é estatisticamente distinguível.
• Subjetividade: A definição de "intenção" depende do julgamento de um único anotador sobre o prompt de ouro, tornando a métrica normativa em vez de um ground truth absoluto.
• Contaminação de Dados: Como o benchmark é derivado do dataset público HumanEval+, há um risco de que os modelos tenham encontrado os problemas originais durante o treinamento, embora os autores notem que os prompts ambíguos foram construídos manualmente para mitigar isso.