Resumo Técnico: Abstenção de Tarefa para Modelos de Linguagem Grandes na Geração de Código

Definição do Problema

O artigo aborda a questão crítica de alucinação em Modelos de Linguagem Grandes (LLMs) aplicados à geração de código. Enquanto a pesquisa existente foca amplamente em alucinação de amostra (detectar trechos de código individuais que falham na execução ou não atendem aos requisitos), este trabalho identifica uma fonte mais fundamental de erro: alucinação em nível de tarefa. Isso ocorre quando um LLM é intrinsecamente improvável de resolver uma tarefa de codificação específica devido a prompts ambíguos ou às limitações inerentes do modelo, independentemente de quantas amostras ele gerar.

Os autores formalizam o problema de Abstenção de Tarefa: determinar se um LLM deve recusar responder a um prompt específico de geração de código para evitar produzir código funcionalmente incorreto. O objetivo é definir uma função de recusa $r(x)$ que identifique tarefas onde a probabilidade de gerar uma solução correta é baixa, especificamente quando a métrica $H@k$ (a probabilidade de que $k$ amostras geradas aleatoriamente sejam todas incorretas) excede uma tolerância de risco definida pelo usuário $\alpha$.

Metodologia: CODEREFUSER

A abordagem proposta, CODEREFUSER, é construída sobre o framework Learn Then Test (LTT), utilizando testes de múltiplas hipóteses para fornecer garantias teóricas rigorosas e livres de distribuição. O método opera em duas fases:

1. Fase de Calibração

• Construção do Conjunto de Calibração: Diferentemente de tarefas padrão de PLN, o conjunto de calibração consiste em prompts de tarefa emparelhados com casos de teste de oráculo (verdade fundamental).
• Definição de Risco de Admissão: O risco é definido como a probabilidade de que uma tarefa seja admitida (não recusada) mas o LLM falhe em gerar uma solução correta dentro de $k$ tentativas ($H@k$).
• Funções de Pontuação: Para lidar com a diversidade sintática de código semanticamente equivalente, os autores propõem funções de pontuação baseadas em execução em vez de métricas linguísticas estáticas. Estas dependem do agrupamento de amostras de código com base em suas saídas de execução contra casos de teste:
  • Razão de Cluster (CR): Mede a proporção de amostras pertencentes ao cluster semântico dominante (consenso do modelo).
  • Entropia Semântica (SE): Quantifica a incerteza da tarefa medindo a diversidade da distribuição de clusters resultante.
• Seleção de Limiares: Utilizando testes de múltiplas hipóteses, o método identifica um conjunto de limiares válidos ($\Lambda_{valid}$) que garantem que o risco de admissão permaneça abaixo da tolerância $\alpha$ com alta confiança ($1-\delta$).

2. Fase de Teste

• Geração Dual: Para um novo prompt de teste, o LLM gera tanto soluções de código quanto casos de teste correspondentes.
• Filtragem Dual Amostra-Teste (STDF): Um mecanismo inovador para abordar o fato de que os casos de teste gerados por LLMs podem ser inválidos ou defeituosos.
  • Filtragem por Taxa de Erro: Remove casos de teste que causam falhas generalizadas de execução em toda a população de amostras.
  • Filtragem por Diversidade de Saída: Remove casos de teste que induzem alta entropia semântica (indicando comportamento indefinido ou entradas inválidas), limitando a proporção de poda para evitar descartar testes válidos.
• Tomada de Decisão: Os casos de teste refinados são usados para agrupar as amostras de código. A decisão de abstenção é tomada aplicando os limiares calibrados às pontuações de Razão de Cluster ou Entropia Semântica. Se os critérios não forem atendidos, o modelo se abstém.

Contribuições Principais

1. Formalização da Abstenção de Tarefa: O artigo introduz e formaliza o conceito de abstenção em nível de tarefa na geração de código, distinguindo-o da detecção de alucinação em nível de amostra.
2. Framework com Garantia Teórica: Propõe um método fundamentado em testes de múltiplas hipóteses que fornece uma garantia rigorosa e livre de distribuição de que o risco de aceitar uma "má" tarefa é controlado abaixo de um limiar especificado.
3. Pontuação Baseada em Execução com STDF: Os autores introduzem um esquema de pontuação baseado em resultados de execução em tempo de execução e um mecanismo de Filtragem Dual Amostra-Teste (STDF). Isso permite que o sistema opere sem dependência de casos de teste de oráculo durante a fase de teste, mitigando o ruído introduzido por testes gerados pelo modelo.
4. Mínima Dependência de Oráculos: A abordagem requer casos de teste de oráculo apenas durante a fase de calibração, tornando-a prática para implantação onde testes de verdade fundamental não estão disponíveis para cada nova tarefa.

Resultados Experimentais

Os autores avaliaram o CODEREFUSER nos benchmarks HumanEval e MBPP usando quatro LLMs de código de código aberto (DeepSeek-Coder, Qwen2.5-Coder, CodeLlama e WizardCoder).

• Desempenho: O CODEREFUSER superou significativamente as bases existentes, incluindo métodos estáticos (PPL, NLI, CLM) e detectores baseados em execução (CodeHalu, Execution). Em média, alcançou uma melhoria absoluta de 26,5% na precisão de abstenção em comparação com o melhor concorrente existente.
• Estático vs. Execução: Os experimentos demonstraram que métodos estáticos (mesmo com tamanhos de amostra quadruplicados) não conseguiram igualar o desempenho de métodos baseados em execução, confirmando que a execução de código é necessária para estimativa precisa de risco neste domínio.
• Transferibilidade: O método mostrou alta transferibilidade robusta, mantendo alto desempenho quando a calibração foi realizada no MBPP e os testes no HumanEval, apesar da mudança de distribuição.
• Controle de Risco: Os resultados empíricos confirmaram as garantias teóricas, mostrando que o risco de admissão foi controlado com sucesso abaixo da tolerância alvo $\alpha$ em mais de 90% dos casos. Além disso, o CODEREFUSER alcançou esse controle de risco com uma taxa de abstenção significativamente menor (recusando menos tarefas válidas) em comparação com métodos de base como PPL.

Significado e Alegações

O artigo afirma representar progresso em direção à geração de código por LLMs provadamente correta. Ao permitir que os modelos digam com confiança "não sei" para tarefas que é improvável que resolvam, a abordagem fornece um mecanismo confiável para uma geração de código mais segura e robusta.

Os autores reconhecem modestamente as limitações:

• Mudança de Distribuição: A garantia teórica depende da suposição de que os dados de calibração e teste são independentes e identicamente distribuídos (i.i.d.). Embora os experimentos mostrem robustez a mudanças moderadas, desvios extremos do mundo real poderiam enfraquecer as garantias.
• Determinismo: O método assume que as tarefas têm soluções determinísticas. Pode não se aplicar diretamente a sistemas de software não determinísticos ou interativos.
• Escopo de Linguagem: A avaliação atual é limitada a Python; a eficácia em outras linguagens (por exemplo, C, Java) com características diferentes de memória ou ponteiros requer avaliação adicional.

O trabalho não propõe novas aplicações, mas sim uma camada de segurança fundamental que pode ser integrada aos fluxos de trabalho existentes de geração de código para mitigar o risco de alucinação.