Resumo Técnico: FLARE – Feedback de Diagnóstico de Grão Fino para Refinamento de Código de LLM

Declaração do Problema

Grandes Modelos de Linguagem (LLMs) demonstram capacidades significativas na geração de código, mas frequentemente produzem códigos contendo bugs. Os métodos de refinamento iterativo atuais tentam corrigir esses erros gerando um programa inicial, recebendo feedback e refinando o código ao longo de várias rodadas. No entanto, as abordagens existentes dependem de sinais de feedback que são frequentemente de grão muito grosso ou de alto nível. Os sinais comuns incluem falhas de execução (ex: erros de casos de teste) e autocríticas geradas pelo próprio LLM. Esses sinais indicam que um bug existe, mas falham em fornecer orientação suficiente sobre onde o bug reside dentro do código, limitando a capacidade do modelo de realizar correções direcionadas.

Metodologia

Os autores propõem o FLARE, um framework iterativo projetado para fornecer feedback de diagnóstico de grão fino (nível de linha) para guiar o refinamento de código. O framework consiste em dois componentes primários: um modelo de diagnóstico leve e um procedimento de busca de candidatos.

1. Feedback de Diagnóstico de Grão Fino

O FLARE introduz um modelo de diagnóstico treinado para prever pontuações de suspeitabilidade ao nível de linha para códigos com bugs.

• Alinhamento de Entrada: O modelo alinha os sinais internos de probabilidade de nível de token do LLM com as unidades léxicas do código (identificadores, operadores, palavras-chave). Como a tokenização padrão (ex: Byte-Pair Encoding) frequentemente divide unidades léxicas em sub-tokens, o FLARE agrega as probabilidades dos sub-tokens para computar uma pontuação de confiança para cada unidade léxica.
• Representação de Características: Para cada unidade léxica, o modelo constrói uma tupla de características composta pelo embedding do token, seu tipo sintático (ex: Palavra-chave, Identificador) e a pontuação de confiança agregada.
• Arquitetura: Um codificador Transformer bidirecional processa a sequência de unidades léxicas, permitindo que cada unidade atenda ao contexto total do programa. Um classificador linear então gera uma pontuação de suspeitabilidade para cada unidade.
• Agregação: Para gerar o feedback ao nível de linha, o modelo agrega as pontuações de todas as unidades léxicas dentro de uma linha usando max pooling, selecionando a maior pontuação de suspeitabilidade como a pontuação da linha.
• Treinamento: O modelo é treinado no conjunto de dados Collu-Bench, que contém soluções de código com bugs pareadas com localizações de bugs de verdade fundamental (ground-truth) e as probabilidades de token do LLM gerador. O objetivo é prever a posição da unidade léxica problemática real.

2. Busca de Candidatos Top-k

Reconhecendo a incerteza inerente às previsões de diagnóstico, o FLARE não se compromete com uma única localização de falha prevista. Em vez disso, ele emprega uma estratégia de busca:

• Seleção: Em cada iteração, o modelo de diagnóstico classifica as linhas por suspeitabilidade. O FLARE seleciona as $k$ linhas mais suspeitas.
• Refinamento: Para cada uma das $k$ linhas, um prompt de refinamento direcionado é construído contendo o programa atual, o feedback de execução e a linha suspeita específica. O LLM gera uma revisão candidata para cada prompt.
• Avaliação: Todos os $k$ candidatos são executados contra os casos de teste. O candidato que passa em mais testes (ou resolve mais falhas) é selecionado para a próxima iteração. Se um candidato passar em todos os testes, o processo é encerrado.

Principais Contribuições

1. Modelo de Diagnóstico de Grão Fino: O artigo apresenta um modelo de diagnóstico leve que aproveita sinais internos do LLM (confiança e sintaxe) para localizar bugs ao nível de linha, abordando as limitações de granularidade dos métodos de feedback existentes.
2. Framework Iterativo com Busca: O FLARE combina este sinal de diagnóstico com feedback de execução e um procedimento de busca de candidatos top-$k$ para mitigar a incerteza da localização de falhas.
3. Avaliação Abrangente: O framework é avaliado no LiveCodeBench e BigCodeBench utilizando cinco LLMs base diversos (incluindo Qwen, Llama e GPT-4o-mini) e comparado contra baselines fortes como Self-Debugging, Self-Refine e NL-Debugging.

Resultados Experimentais

• Ganhos de Desempenho: Mesmo sem a busca de candidatos ($k=1$), o FLARE supera o baseline mais forte (NL-Debugging) em 9 de 10 configurações, alcançando melhorias absolutas no Pass@1 variando de 1,72% a 7,42%.
• Impacto da Busca: Expandir a busca para $k=10$ candidatos gera uma melhoria média de 8,50% sobre a variante $k=1$, demonstrando que explorar múltiplas regiões de falha plausíveis aumenta significativamente o sucesso do refinamento.
• Precisão de Diagnóstico: Quando avaliado isoladamente em tarefas de localização de falhas, o modelo de diagnóstico do FLARE atinge 67% de Top-1 e 89% de Top-10 de precisão, superando métodos recentes de localização de falhas como FlexFL, LLMAO e BAP.
• Eficiência: A variante $k=1$ do FLARE é mais eficiente que o Self-Debugging e o Self-Refine, reduzindo o tempo médio de execução por tarefa de ~95 segundos para ~73 segundos, pois evita o overhead de gerar texto de auto-depuração. A variante $k=10$ incorre em custos computacionais mais altos devido às múltiplas gerações de candidatos, mas proporciona a maior precisão.

Significância e Alegações

O artigo afirma que sinais de localização de grão fino servem como orientação confiável para o refinamento de código. Ao ir além do feedback de execução grosseiro ou das autocríticas de alto nível, o FLARE fornece ao LLM alvos específicos para correção. Os autores enfatizam que a combinação de localização de diagnóstico precisa e a expansão da busca de candidatos desempenha um papel complementar: a localização identifica regiões prováveis, enquanto a busca mitiga a incerteza da previsão.

O estudo reconhece limitações, observando que o sucesso do framework ainda é limitado pelas capacidades de raciocínio do LLM subjacente. As falhas ocorrem frequentemente não porque a localização do bug foi perdida, mas porque o LLM carece de insight algorítmico para corrigir o problema identificado, interpreta erroneamente os requisitos da tarefa ou falha em gerenciar dependências de estado complexas de longo alcance. No entanto, o FLARE representa um passo significativo em direção a um refinamento de código iterativo mais eficaz e direcionado.