Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

Este artigo apresenta um framework que utiliza testes e análise estática para avaliar e orientar a autoaperfeiçoamento de modelos de linguagem de grande porte na geração de código, demonstrando que, embora esses modelos frequentemente produzam código incorreto ou inseguro e tenham dificuldade em detectar tais problemas, eles apresentam uma capacidade substancial de corrigir falhas quando recebem feedback detalhado sobre erros e vulnerabilidades.

O essencial

Imagine que você contratou um estagiário de programação superinteligente, mas que nunca praticou a profissão na vida real. Ele leu milhões de livros de código, mas nunca construiu um prédio de verdade. Esse é o modelo de Inteligência Artificial (LLM) que os pesquisadores estão estudando.

Este artigo é como um relatório de estágio desse estagiário, focado em três perguntas:

1. Ele consegue construir o código certo?
2. Ele sabe quando errou?
3. Se você apontar o erro, ele consegue consertar?

Aqui está a explicação do que eles descobriram, usando analogias do dia a dia:

1. O Cenário: O "Estagiário" e o "Chefe Rigoroso"

Os pesquisadores pegaram quatro modelos de IA famosos (Llama, Gemma, Mixtral) e pediram para eles escreverem programas em C (uma linguagem de programação antiga, mas muito usada em sistemas críticos, como freios de carros ou aviões, onde um erro pode ser catastrófico).

Para testá-los, eles usaram duas ferramentas de "checagem":

• O Teste de Funcionamento (Ground Truth): Como um professor corrigindo uma prova. O código roda e vê se a resposta está certa.
• O Analista de Segurança (Infer): Como um inspetor de obras. Ele olha o projeto no papel (sem construir) para ver se há riscos de colapso, como vazamentos de memória ou ponteiros perigosos.

2. O Resultado: O Estagiário é Confuso

Os resultados foram mistos, mas reveladores:

• A Construção (Geração de Código):
  O estagiário foi razoável, mas não perfeito. Cerca de 46% a 65% dos códigos que ele escreveu funcionavam corretamente. Ou seja, em quase metade dos casos, ele entregou um código que não fazia o que era pedido ou travava.

  • Analogia: Se você pedisse para ele desenhar uma cadeira, ele faria uma cadeira funcional na maioria das vezes, mas em muitos casos, as pernas estariam tortas ou faltaria o assento.

• A Segurança (Vulnerabilidades):
  Surpreendentemente, a maioria dos códigos (cerca de 87% a 96%) não tinha falhas de segurança graves detectadas pelo inspetor.

  • Analogia: O estagiário construiu cadeiras que funcionam, mas algumas delas têm parafusos frouxos que só o inspetor nota. A maioria das cadeiras parece segura, mas não é perfeita.

3. O Grande Problema: A "Cegueira" do Estagiário

Aqui está a parte mais preocupante. Quando os pesquisadores pediram para o próprio estagiário olhar o código que ele escreveu e dizer: "Ei, isso está certo?" ou "Ei, tem algum buraco de segurança aqui?", a resposta foi: Ele não sabe.

• Autoavaliação: Os modelos foram péssimos em detectar seus próprios erros. Eles tinham uma taxa de acerto muito baixa.
  • Analogia: É como pedir para um pintor cego avaliar se a pintura que ele acabou de fazer está torta. Ele diz "está perfeita" quando está torto, ou "está horrível" quando está perfeita. Eles não têm "autoconsciência" sobre a qualidade do que produzem.

4. A Solução: O "Manual de Instruções" (Feedback)

A parte boa (e o foco principal do artigo) é o que acontece quando você não deixa o estagiário adivinhar.

Os pesquisadores deram um feedback específico: "Olha, o teste X falhou" ou "O inspetor disse que há um vazamento de memória na linha 10".

• O Conserto (Repair): Quando receberam essas dicas, os modelos melhoraram drasticamente.
  • No conserto de erros de lógica, o melhor modelo conseguiu corrigir 62% dos códigos errados.
  • No conserto de falhas de segurança, eles corrigiram 89% das vulnerabilidades.
  • Analogia: Se você apenas disser "essa cadeira está ruim", o estagiário fica perdido. Mas se você disser "a perna esquerda está 2cm curta", ele consegue cortar a madeira e consertar quase tudo.

5. Conclusão: O Que Aprendemos?

1. Não confie cegamente: A IA gera código útil, mas frequentemente erra a lógica e não percebe seus próprios erros.
2. A IA é um "consertador" excelente, mas um "criador" imperfeito: Ela precisa de ajuda para começar, mas brilha quando recebe instruções claras sobre o que está errado.
3. O Futuro é a "Pipeline" Automática: A melhor maneira de usar essas IAs não é deixá-las sozinhas, mas colocá-las em um ciclo onde:
   • Elas geram o código.
   • Ferramentas automáticas (como testes e analisadores) acham os erros.
   • O erro é devolvido para a IA.
   • A IA conserta.
   • E o ciclo se repete até ficar perfeito.

Resumo em uma frase:
Os modelos de IA são como estagiários talentosos que precisam de um supervisor rigoroso (ferramentas de teste) para apontar os erros; sozinhos, eles não sabem que estão errados, mas com as dicas certas, eles conseguem consertar quase tudo.

Resumo técnico

1. Problema e Contexto

Os Grandes Modelos de Linguagem (LLMs) têm sido amplamente adotados para acelerar o desenvolvimento de software, gerando trechos de código, funções e até aplicações completas. No entanto, há preocupações significativas quanto à correção funcional e à segurança do código gerado. Estudos anteriores indicam que o código produzido por LLMs comerciais frequentemente contém vulnerabilidades, bugs e más práticas (code smells).

O problema central abordado neste trabalho é a falta de confiabilidade autônoma dos LLMs na geração de código seguro e correto, bem como a sua incapacidade de identificar e corrigir esses erros quando gerados por si mesmos ou por outros modelos. O objetivo é criar um framework que utilize feedback de testes e análise estática para guiar a auto-melhoria desses modelos.

2. Metodologia

Os autores propõem um framework automatizado e modular composto por três fases principais, aplicado a quatro modelos de código aberto de última geração: Llama 3 (8B e 70B), Gemma 7B e Mixtral 8x7B. O foco experimental foi a linguagem C, devido à sua complexidade em gerenciamento de memória.

A. Geração de Código

• Benchmark: Foi criado um conjunto de dados adaptando 100 tarefas do Mostly Basic Python Problems (MBPP) para a linguagem C, garantindo que os modelos não estivessem apenas memorizando soluções pré-existentes.
• Processo: Os modelos geraram código para resolver as tarefas. O código foi limpo automaticamente (remoção de texto explicativo, adição de bibliotecas padrão) e compilado usando o compilador Clang.

B. Avaliação (Self-Evaluation)

• Correção: Os modelos foram solicitados a classificar se o código gerado (por eles mesmos ou por outros) atendia às especificações da tarefa.
• Segurança: Os modelos foram questionados sobre a presença de vulnerabilidades específicas (ex: uninitialized values, null pointer dereference) em trechos de código, comparando suas respostas com a "verdade fundamental" (ground truth).

C. Análise Estática e Correção (Repair)

• Ferramenta de Análise: Foi utilizado o Infer (ferramenta de análise estática da Meta) para detectar vulnerabilidades de segurança (gerenciamento de memória, vazamentos, overflow de buffer) no código compilável.
• Fase de Reparo: O framework alimentou os LLMs com o código defeituoso e os relatórios de falha (seja de testes unitários falhos ou de vulnerabilidades detectadas pelo Infer).
• Iteração: Os modelos tentaram corrigir o código iterativamente (até 6 iterações), utilizando o feedback como guia. O processo foi testado com diferentes prompts (engenharia de prompts), incluindo técnicas como Chain-of-Thought e instruções específicas de correção.

3. Contribuições Principais

1. Framework Automatizado de Melhoria: Proposição de um pipeline completo que integra geração, teste, análise estática e reparo iterativo sem intervenção humana significativa após a configuração inicial.
2. Avaliação de Autoconsciência: Investigação da capacidade dos LLMs de avaliar a correção e segurança do código gerado por si mesmos versus o de outros modelos (avaliação de "auto-preferência").
3. Análise Comparativa de Modelos: Estudo detalhado de quatro modelos open-source de arquiteturas e tamanhos variados (7B a 70B parâmetros).
4. Validação de Engenharia de Prompts: Demonstração sistemática de como o design do prompt impacta drasticamente a qualidade da geração, avaliação e reparo.

4. Resultados Chave

Geração e Correção Inicial

• Correção: Apenas 46% a 65% do código gerado passou em todos os testes unitários. O modelo Llama 3 70B teve o melhor desempenho (65%).
• Segurança: A análise estática (Infer) indicou que 87% a 96% do código não continha vulnerabilidades detectáveis, sugerindo que os erros funcionais são mais comuns que falhas de segurança graves neste conjunto de dados. No entanto, 44 vulnerabilidades reais foram encontradas após verificação manual.

Capacidade de Auto-Avaliação

• Desempenho Pobre: Os modelos performaram muito mal na detecção de erros.
  • Na avaliação de correção, as pontuações F1 foram inferiores a 80%.
  • Na detecção de vulnerabilidades, a precisão foi extremamente baixa (muitas vezes < 5%), embora a acurácia geral fosse alta devido ao desbalanceamento dos dados (a maioria do código era "seguro" ou "correto", levando os modelos a responderem "NÃO" ou "SIM" indiscriminadamente).
• Falta de Autoconsciência: Não houve evidência de que os modelos fossem melhores avaliando seu próprio código; na verdade, alguns modelos tendiam a ser excessivamente otimistas ou pessimistas.

Capacidade de Reparo (Repair)

• Correção Funcional: Quando fornecidos com relatórios de testes falhos, os modelos conseguiram corrigir o código com sucesso em uma taxa de 62% (para o melhor modelo, Llama 3 70B, que corrigiu 96 de 155 arquivos incorretos).
• Correção de Segurança: A taxa de sucesso foi ainda mais impressionante: o melhor modelo corrigiu 89% das vulnerabilidades (39 de 44) quando informado sobre o tipo de falha.
• Observação Importante: Os modelos mostraram-se capazes de reparar código gerado por outros modelos tão bem quanto o seu próprio, e em alguns casos, corrigiram melhor o código de modelos menores (como o Gemma) do que o seu próprio.

5. Significado e Conclusões

O artigo conclui que, embora os LLMs atuais não sejam confiáveis para gerar código seguro e correto "de primeira" (zero-shot), eles possuem uma capacidade substancial de auto-melhoria quando guiados por feedback externo preciso.

• Integração de Ferramentas: A combinação de LLMs com ferramentas de análise estática (como Infer) e testes unitários é uma via promissora para criar pipelines de desenvolvimento de software mais seguros.
• Limitações de Auto-Avaliação: Os modelos não devem ser confiados para auditar seu próprio código; a intervenção de ferramentas externas é crucial.
• Futuro: O trabalho sugere a expansão para outras linguagens (como Rust e Python) e a integração de análises híbridas (estática e dinâmica) para reduzir falsos positivos e negativos, tornando a geração de código por IA uma prática viável e segura para a indústria.

Em resumo, o estudo demonstra que a chave para a adoção segura de LLMs na engenharia de software não é apenas melhorar o modelo base, mas sim criar sistemas de feedback iterativo que utilizam ferramentas de verificação formal para guiar o modelo na correção de seus próprios erros.