Defective Task Descriptions in LLM-Based Code Generation: Detection and Analysis

1. Declaração do Problema

Os Modelos de Linguagem Grandes (LLMs) são cada vez mais utilizados para geração de código, mas seu desempenho depende fortemente da suposição de que as descrições de tarefa fornecidas pelo usuário são suficientemente detalhadas e bem formadas. Na prática, os prompts em linguagem natural frequentemente contêm defeitos como:

• Vaguidão Lexical (LV): Terminologia imprecisa ou sinônimos que reduzem a especificidade.
• Subespecificação (US): Restrições, casos de borda ou requisitos ausentes (por exemplo, omitir limites numéricos).
• Sintaxe e Formatação (SF): Ruído superficial, como erros de digitação, erros de formatação ou problemas de espaçamento em branco.

Esses defeitos podem degradar drasticamente a correção do código. Os benchmarks de avaliação atuais frequentemente utilizam prompts "limpos", falhando em refletir cenários do mundo real onde as descrições são imperfeitas. Além disso, há uma falta de ferramentas automatizadas para detectar esses defeitos antes da geração de código, e não está claro como diferentes tamanhos de modelo ou arquiteturas lidam com tais defeitos.

2. Metodologia

A. Construção do Conjunto de Dados

Os autores construíram um conjunto de dados em grande escala de 6.573 descrições de tarefa defeituosas derivadas de três benchmarks estabelecidos:

1. HumanEval: Docstrings estruturadas com assinaturas tipadas.
2. MBPP: Descrições curtas e informais em linguagem natural.
3. LiveCodeBench: Problemas de programação competitiva com contratos de E/S explícitos e exemplos.

Estratégia de Injeção de Defeitos:
Usando gpt-5-mini, os autores mutaram sistematicamente as descrições originais para criar três tipos de defeitos por tarefa:

• LV: Substituição de termos específicos por sinônimos mais amplos (por exemplo, "ordenar" $\to$ "organizar") ou renomeação de identificadores.
• US: Remoção de exatamente uma restrição explícita (por exemplo, um limite numérico, regra de ordenação ou requisito de tratamento de erro).
• SF: Introdução de erros de digitação, erros de delimitador ou problemas de indentação sem alterar a semântica.

Validação:

• Automática: Um juiz LLM independente (Qwen2.5-Coder-32B) pontuou as mutações quanto à conformidade e naturalidade.
• Manual: Três pesquisadores verificaram manualmente uma amostra aleatória estratificada (100 instâncias), confirmando alta concordância com o juiz automatizado (97% de conformidade, 86% de naturalidade).

B. Configuração Experimental

• Modelos Avaliados: 10 LLMs variando de modelos open-source pequenos (6–7B parâmetros) a modelos open-source grandes (15–34B) e modelos proprietários de raciocínio de última geração (GPT-5-mini, Claude Sonnet 4).
• Métricas:
  • Correção do Código: Pass@1 (porcentagem de vezes que a primeira solução gerada passa nos testes unitários).
  • Detecção de Defeitos: Macro-F1, Coeficiente de Correlação de Matthews (MCC), Precisão e Revocação.

C. Solução Proposta: SpecValidator

Os autores desenvolveram o SpecValidator, um classificador leve projetado para detectar defeitos em descrições de tarefa.

• Arquitetura: Baseado em Qwen2.5-Coder-1.5B.
• Regimes de Treinamento: Comparou três abordagens:
  1. Sondagem Linear (Linear Probing): Treinamento apenas da cabeça de classificação em embeddings congelados.
  2. Ajuste Fino LoRA: Adaptação de baixo rank (rank $r=16$) nas camadas de atenção.
  3. Ajuste Fino Completo: Atualização de todos os parâmetros.
• Baselines: Comparado contra prompts zero-shot e few-shot do GPT-5-mini e Claude Sonnet 4.

3. Contribuições Principais

1. Análise em Grande Escala: Um estudo abrangente de 10 modelos em 3 benchmarks, revelando que o impacto do defeito é impulsionado pelo tipo de defeito e pela estrutura do benchmark e não pela capacidade do modelo.
2. SpecValidator: Um classificador altamente eficiente, ajustado finamente com LoRA (modelo de 1,5B) que supera modelos de fronteira na detecção de defeitos enquanto atualiza apenas 0,14% dos parâmetros.
3. Descoberta de Defeitos do Mundo Real: Demonstrou que o SpecValidator pode generalizar para descrições de benchmarks do mundo real não vistas, identificando com sucesso defeitos latentes de "Subespecificação" na verdade fundamental de benchmarks padrão (HumanEval, MBPP, LiveCodeBench).
4. Conjunto de Dados Público: Liberação de um conjunto de dados contendo 6.573 instâncias de descrições de tarefa defeituosas para apoiar pesquisas futuras.

4. Resultados Principais

A. Impacto dos Defeitos na Geração de Código (RQ1)

• Subespecificação (US) é a mais severa: Causou quedas de Pass@1 de 7,9% a 15,3% em todos os modelos e benchmarks. Mesmo modelos de última geração (GPT-5-mini, Claude Sonnet 4) sofreram quedas de ~9,7%. Nenhum modelo foi imune.
• Vaguidão Lexical (LV) é moderada: O impacto variou por benchmark (até 12,2% de queda no HumanEval, mas apenas ~1,5–3,2% no MBPP). Modelos maiores (por exemplo, Qwen2.5-32B) mostraram melhor resiliência à LV.
• Sintaxe/Formatação (SF) é negligenciável: Ruído superficial teve impacto mínimo (<3,7% de queda), sugerindo que LLMs especializados em código são robustos a erros de digitação.
• Resiliência do Benchmark: LiveCodeBench foi quase imune a todos os defeitos (deltas dentro de ±2,0%). Os autores atribuem isso ao seu rico enraizamento contextual (exemplos explícitos de E/S), que permite aos modelos inferir restrições ausentes.
• Irrelevância do Tamanho do Modelo: O tamanho maior do modelo não correlacionou-se com melhor robustez. A sensibilidade foi determinada pela estrutura da descrição, não pela contagem de parâmetros do modelo.

B. Desempenho de Detecção de Defeitos (RQ2)

• SpecValidator (LoRA) alcançou o melhor desempenho: F1 = 0,804, MCC = 0,745.
• Baselines: GPT-5-mini (Zero-shot) e Claude Sonnet 4 performaram mal (F1 $\approx$ 0,47–0,52), indicando que fortes capacidades de geração de código não se transferem para metarraciocínio sobre a qualidade do prompt em configuração zero-shot.
• Eficiência: A abordagem LoRA (0,14% de parâmetros treináveis) superou o Ajuste Fino Completo (100% de parâmetros), provavelmente devido ao overfitting neste último.
• Modo de Erro: A principal confusão foi entre as classes Limpo e Subespecificado, pois defeitos de US não deixam traço textual positivo (são gramaticalmente corretos, mas faltam informações).

C. Generalização para Prompts Reais (RQ3)

• Quando aplicado às descrições "limpas" originais dos benchmarks, o SpecValidator sinalizou 83 de 456 (18,2%) como defeituosos (especificamente Subespecificados).
• Validação:
  • Essas descrições sinalizadas resultaram em Pass@1 próximo de zero em todos os 10 modelos (90,9% de taxa de falha no MBPP, 98,0% no LiveCodeBench).
  • Inspeção manual de 33 casos de MBPP sinalizados confirmou que 72,7% eram genuinamente subespecificados.
• Conclusão: Benchmarks padrão contêm defeitos latentes que impedem significativamente a geração de código, e o SpecValidator pode detectá-los.

5. Significado e Implicações

• Redefinindo Robustez: O estudo desafia a noção de que modelos maiores são inerentemente mais robustos. Em vez disso, a robustez é uma função da estrutura da descrição da tarefa (por exemplo, presença de exemplos de E/S).
• Qualidade do Benchmark: A descoberta de defeitos latentes em benchmarks principais (como MBPP e LiveCodeBench) sugere que as métricas de avaliação atuais podem estar infladas ou enganosas se não levarem em conta a qualidade do prompt.
• Ferramentas Práticas: O SpecValidator oferece um método computacionalmente barato e altamente preciso para auditar prompts antes da geração de código, prevenindo desperdício de computação e implantações falhas.
• Direções Futuras: O artigo argumenta pela superação de estudos simples de perturbação em favor de uma análise estruturada de defeitos de especificação e enfatiza a necessidade de benchmarks com enraizamento contextual mais rico para garantir geração de código baseada em LLM confiável.