Resumo Técnico: Código é Mais do que Texto: Estimativa de Incerteza para Geração de Código

Declaração do Problema

Grandes Modelos de Linguagem (LLMs) estão sendo cada vez mais implantados como geradores de código para assistentes de IDE e agentes autônomos. No entanto, programas silenciosamente incorretos representam riscos significativos de segurança e confiabilidade, pois erros podem passar despercebidos em revisões e se acumular em etapas subsequentes. Embora a Estimativa de Incerteza (UE) Confiável seja essencial para a predição seletiva e revisão com intervenção humana (human-in-the-loop), os métodos atuais são, em grande parte, transposições diretas da geração de Linguagem Natural (NL). Esses métodos derivados de NL tratam o código meramente como uma sequência de tokens, falhando em explorar propriedades que tornam o código distinto:

1. Fragilidade do Token: Ao contrário da NL, onde o significado é frequentemente recuperável apesar de erros, um único token errado (ex: um operador ou índice) pode quebrar um programa inteiro.
2. Lacuna Intenção–Código: A intenção algorítmica pode ser abstraída da implementação concreta; variações de superfície no código podem esconder uma lógica idêntica, enquanto uma sintaxe idêntica pode esconder algoritmos diferentes.
3. Executabilidade: O código pode ser executado contra casos de teste, fornecendo um sinal comportamental de correção único para a geração de código.

O artigo argumenta que os métodos de UE existentes, que dependem de incerteza de sequência uniforme ou agrupamento de superfície, perdem esses sinais críticos.

Metodologia

Os autores propõem um framework de três eixos para a estimativa de incerteza de código, onde cada eixo corresponde a uma dessas propriedades distintas do código. Os sinais são projetados para serem ortogonais e complementares.

1. Incerteza Léxica (Fragilidade do Token)

• Conceito: Aborda a esparsidade da incerteza no código. Em vez de tirar a média da entropia sobre toda a sequência (o que dilui erros críticos), o método foca nas posições mais incertas.
• Implementação: Entropia de Top-K Tokens. O modelo gera uma saída única via greedy decoding. O escore de incerteza é a média das $K$ maiores entropias de nível de token ($H(y_t)$) na sequência.
• Racional: Um único token de alta entropia geralmente indica um ponto de decisão crítico onde o modelo está incerto, o que é mais preditivo de falha do que a entropia média de toda a sequência.

2. Incerteza Algorítmica (Lacuna Intenção–Código)

• Conceito: Mede a consistência ao nível da intenção algorítmica, em vez da sintaxe de superfície.
• Implementação: Consistência de Pseudo-Código. Em vez de amostrar múltiplas implementações de código (o que introduz ruído de implementação), o modelo é instruído a gerar $N$ planos de solução em linguagem natural (pseudo-código) descrevendo os passos algorítmicos.
• Métrica: A concordância entre amostras é medida usando ROUGE-L sensível a passos (step-aware), que divide os planos em passos semânticos e computa o pareamento bidirecional. Alta discordância entre os planos indica alta incerteza.

3. Incerteza Funcional (Executabilidade)

• Conceito: Aproveita a capacidade de executar o código para medir a correção comportamental.
• Implementação: Consistência Comportamental. O modelo gera um programa candidato e $M$ casos de teste autogerados. O candidato é executado contra esses testes em um ambiente isolado (sandbox).
• Métrica: O escore de incerteza é a taxa de falha ($1 - \text{taxa de passagem}$) do candidato contra seus próprios testes autogerados. Isso serve como um sinal de calibração em vez de um mecanismo de seleção (ao contrário do CodeT, que reclassifica candidatos).

Ensemble

Os três sinais ($U_{lex}$, $U_{algo}$, $U_{func}$) operam em escalas diferentes. Os autores normalizam o ranking de cada escore para $[0, 1]$ e os combinam via soma ponderada. Os pesos padrão são $(0.2, 0.4, 0.4)$ para os eixos Léxico, Funcional e Algorítmico, respectivamente.

Principais Contribuições

1. Framework de Três Eixos: O artigo introduz um framework de UE específico para código que mapeia diretamente para fragilidade de token, intenção algorítmica e executabilidade, indo além das abstrações derivadas de NL.
2. Validação Empírica: O método é avaliado em quatro benchmarks (APPS-Intro, APPS-Interview, HumanEval, MBPP) e cinco LLMs capazes de codificação (incluindo Qwen3-14B, DeepSeek-Coder-V2 e Devstral-Small-2505).
3. Análise de Custo-Desempenho: O estudo demonstra que a Entropia de Top-K tokens sozinha, apesar de ser um método de passagem única (single-pass), iguala o desempenho das bases de multi-passagem de NL mais fortes com um custo computacional mais de $3\times$ menor.
4. Ortogonalidade de Sinais: A análise confirma que os três sinais capturam informações distintas (baixas correlações pareadas) e visam diferentes modos de falha (ex: léxico para erros de token único, algorítmico para incompatibilidades de estratégia, funcional para erros semânticos).

Resultados

• Ganhos de Desempenho: O ensemble de três eixos melhora o AUROC médio de 0.696 (a base derivada de NL mais forte) para 0.776 em todos os modelos. No Qwen3-14B, o ensemble atinge 0.800 de AUROC.
• Eficiência Léxica: A entropia de Top-K tokens (passagem única) alcança um AUROC médio de 0.728, igualando a base de consistência multi-passagem "Consistency (VR)" (0.728), sendo significativamente mais rápida (2.29s vs 7.10s por problema no HumanEval).
• Assimetria de Escopo de Token: Uma análise do escopo de tokens revela que a entropia calculada apenas em tokens de código (AUROC 0.716) é um sinal forte, enquanto a entropia apenas em tokens de comentário performa pior que o acaso (AUROC 0.375). Isso sugere que a incerteza em explicações de linguagem natural dentro do código é anti-correlacionada com a correção funcional.
  *. Generalização Cross-Language: O sinal léxico (Entropia Top-5) generaliza-se para linguagens não-Python (C++, Java, Go, JS), superando consistentemente as bases de passagem única e os métodos de consistência de multi-passagem.

Significância e Alegações

O artigo afirma que a estimativa de incerteza de código merece um design específico para código, em vez de ser apenas uma transposição direta da linguagem natural. Os autores argumentam que, conforme o deployment de Code-LLMs amadurece, o gargalo muda da escala de capacidade para a calibração.

Principais conclusões incluem:

• A fragilidade do token implica que a incerteza no código é esparsa; focar em tokens de alta entropia é mais eficaz do que a média da sequência.
• A abstração de pseudo-código fornece uma base mais limpa para a estimação de consistência, separando a intenção do ruído de implementação.
• A executabilidade oferece um sinal comportamental único e de baixo custo, indisponível na geração de NL.
• Orientação Prática: Para cenários sensíveis à latência (ex: autocompletar de IDE), a entropia de Top-K tokens é recomendada como um padrão competitivo e de baixo custo. Quando a calibração é primordial e o custo é menos restrito, o ensemble completo de três eixos fornece o melhor desempenho.

Os autores posicionam este trabalho como uma "primeira instanciação" desses eixos, sugerindo que frameworks futuros devem expandir para incluir outros sinais específicos de código (ex: verificações de tipo, análise estática) em vez de forçá-los em estimadores de estilo NL.