Avaliação de LLMs para Geração de Correção de Código

Modelos de linguagem grandes (LLMs) como o Codex da OpenAI mostraram que conseguem criar código a partir de descrições escritas em linguagem do dia a dia. Eles foram avaliados pela capacidade de gerar código que funciona bem em várias tarefas. Recentes benchmarks destacaram melhorias em como os LLMs lidam com essas tarefas. No entanto, existe uma lacuna quando se trata de medir quão bem os LLMs podem fazer mudanças específicas em códigos existentes com base em descrições em linguagem natural dessas mudanças.

Este artigo discute o desafio de transformar descrições em linguagem natural de mudanças no código, especialmente Correções de bugs descritas em relatórios de problemas, em atualizações de código corretas. Apresentamos um conjunto de dados que inclui programas em Java com descrições de bugs e correções, e avaliamos quão bem vários LLMs líderes se saem nessa área.

#Contexto

O uso de LLMs no desenvolvimento de software tem ganhado força. Por exemplo, o GitHub Copilot, que utiliza o Codex da OpenAI, tem se mostrado eficaz na geração de código a partir de descrições escritas. Outros produtos como o Amazon CodeWhisperer e o GhostWriter também dependem de LLMs para ajudar desenvolvedores.

A pesquisa em LLMs para geração de código tem sido impulsionada por benchmarks que testam seu desempenho em tarefas definidas. O benchmark HumanEval, por exemplo, ajudou a guiar a melhoria de LLMs mais novos como o GPT-4. Melhorias observadas nesses testes frequentemente indicam um desempenho melhor em cenários de codificação do mundo real.

Os benchmarks existentes têm se concentrado principalmente em quão bem os LLMs podem criar peças de código completas do zero. No entanto, não houve muitos testes para checar como os LLMs lidam com a edição de códigos existentes com base em descrições. No desenvolvimento prático de software, os desenvolvedores frequentemente lidam com a correção de bugs ou atualizações de códigos, em vez de escrever código novo totalmente.

Na codificação do mundo real, os desenvolvedores geralmente trabalham dentro de bases de código existentes ao fazer mudanças. As mudanças costumam vir na forma de Pull Requests (PRs) em resposta a problemas relatados em sistemas como o GitHub. Este artigo dá os primeiros passos para estabelecer um benchmark para avaliar quão bem os LLMs podem gerar atualizações de código com base em descrições em linguagem natural.

#O Problema NL2Fix

O foco aqui é um problema chamado NL2Fix, que envolve corrigir código com bugs quando o problema é descrito em linguagem natural. Usamos um conjunto bem conhecido de bugs chamado Defects4J, que tem exemplos reais de bugs e correções. Nosso objetivo é criar um benchmark para ver quão bem os LLMs podem lidar com esses bugs.

Introduzimos um conjunto de dados que consiste em 283 programas Java, cada um com descrições das mudanças pretendidas. Essas mudanças incluem como corrigir vários bugs, e garantimos que as correções mantenham a funcionalidade geral do programa. Nossa avaliação envolve checar quão bem diferentes LLMs podem produzir correções plausíveis com base nas descrições dadas.

#Visão Geral do Conjunto de Dados

O conjunto de dados que usamos vem do Defects4J, que contém bugs de projetos reais. Inclui casos de teste que mostram se o bug foi corrigido. Dividimos o conjunto de dados para focar em bugs que podem ser corrigidos mudando apenas um método. Entre 835 bugs no Defects4J, encontramos 283 que se encaixam nesse critério. Esse foco facilita a avaliação de quão bem os LLMs podem gerar correções.

Além dos bugs, também coletamos o título e as descrições dos problemas de repositórios como GitHub e Jira. Removemos quaisquer comentários de código das versões com bugs para evitar dar dicas sobre as correções. Assim, os LLMs devem gerar soluções puramente com base na descrição do problema.

#Transformadores Generativos Pré-treinados (GPT)

Transformadores Generativos Pré-treinados (GPT) são modelos projetados para prever o próximo pedaço de texto com base no contexto anterior. Eles se tornaram capazes de realizar uma variedade de tarefas sem ajustes específicos. Ao gerar respostas, esses modelos podem adotar estilos diferentes, o que impacta a diversidade das saídas.

Escolhemos três LLMs específicos com base na arquitetura GPT para nossa avaliação. Esses incluem o Codex para conclusão de código, o modelo de edição do Codex para fazer alterações de código, e o modelo ChatGPT para tarefas conversacionais. Os modelos escolhidos passam por vários testes para verificar quão bem eles criam correções de código.

#Técnicas de Prompting

A forma como fazemos perguntas ou definimos tarefas para os modelos pode afetar muito seu desempenho. Técnicas conhecidas como prompting são essenciais para guiar os LLMs a entregar melhores saídas. Aplicamos alguns métodos:

1. Zero-Shot Prompting: Neste setup básico, fornecemos ao modelo o título do problema e a descrição junto com o código com erro para pedir uma correção sem dar exemplos.

2. Few-Shot Prompting: Essa técnica envolve fornecer alguns exemplos de tarefas semelhantes junto com suas entradas e saídas. Isso ajuda a guiar o modelo a entender o que esperamos dele.

3. Extração de Raciocínio: Essa estratégia envolve dividir o problema em partes menores, como primeiro identificar onde está o bug e depois explicar por que é um problema antes de, finalmente, pedir uma correção.

#Geração e Validação de Correções

Para gerar correções candidatas, executamos os modelos e produzimos várias sugestões para cada bug. O processo envolve checar se essas sugestões conseguem compilar e se passam em certos testes para garantir que estão corretas.

Classificamos o resultado de cada correção como plausível (passa em todos os testes), errada (falha em um ou mais testes), ou não compilável (não pode ser executada devido a erros de sintaxe). Isso nos permite medir quão eficaz cada modelo é em oferecer soluções válidas.

#Métricas Pass@k

Para avaliar a qualidade das correções geradas, usamos uma métrica conhecida como pass@k, que indica a probabilidade de selecionar uma solução correta de um conjunto de correções geradas. Testamos os modelos sob diferentes configurações e analisamos seu desempenho em termos de taxas de acerto.

Nossos resultados revelam que os LLMs podem gerar correções plausíveis para uma parte dos bugs incluídos em nosso conjunto de dados. Por exemplo, com um dos modelos, observamos uma taxa de acerto indicando que uma fração significativa dos bugs poderia ser abordada corretamente.

#Análise das Características das Correções

Analisamos as características das correções propostas pelos LLMs, especificamente observando quão semelhantes elas são tanto ao código com erro quanto às correções realmente desenvolvidas. O objetivo é entender quão bem os modelos estão capturando a essência das edições necessárias.

A avaliação dos patches mostra que as correções sugeridas costumam apresentar um grau considerável de semelhança com o código buggy existente. No entanto, também encontramos casos onde a saída permanece distinta das correções originais desenvolvidas por programadores humanos.

#Conclusão

A pesquisa destaca as capacidades e limitações dos atuais LLMs na geração de correções de código com base em descrições em linguagem natural. Embora os modelos possam produzir edições plausíveis, há uma variabilidade notável em seu desempenho em diferentes tarefas. A necessidade de benchmarks que cubram essa área é clara, já que isso pode abrir caminho para uma melhor integração de ferramentas de IA no desenvolvimento de software do mundo real.

Trabalhos futuros provavelmente se concentrarão em expandir o benchmark e refinar técnicas para melhorar a precisão e confiabilidade das correções geradas. A exploração contínua de LLMs neste contexto é essencial para desenvolver ferramentas que possam ser confiáveis para os desenvolvedores de software.