Avaliando modelos GPT e de código aberto em tarefas de mutação de código

Tabela de hyperlinks

Resumo e 1 Introdução

2 Antecedentes e trabalho relacionado

3 desenho do estudo

3.1 Visão geral e perguntas de pesquisa

3.2 conjuntos de dados

3.3 Geração de mutação through LLMS

3.4 Métricas de avaliação

3.5 Configurações do experimento

4 Resultados da avaliação

4.1 RQ1: desempenho sobre custo e usabilidade

4.2 RQ2: similaridade de comportamento

4.3 RQ3: Impactos de diferentes solicitações

4.4 RQ4: Impactos de diferentes LLMs

4.5 RQ5: Causas raiz e tipos de erro de mutações não compiláveis

5 discussão

5.1 Sensibilidade às configurações de experimento escolhidas

5.2 Implicações

5.3 Ameaças à validade

6 conclusão e referências

4.4 RQ4: Impactos de diferentes LLMs

Para responder a este RQ, adicionamos dois LLMs extras, GPT-4 e Starchat16b e comparamos seus resultados com os dois LLMs padrão, GPT-3.5 e Code LLAMA-13B. A metade direita da Tabela 7 mostra resultados comparativos entre os modelos usando o immediate padrão. Observamos que os LLMs de código fechado geralmente superam os outros na maioria das métricas. O GPT-3.5 se destaca na contagem de mutações, custo de geração por 1K de mutações e tempo médio de geração, superb para gerar rapidamente inúmeras mutações. O GPT-4 lidera todas as métricas de usabilidade e métricas de similaridade de comportamento, demonstrando sua eficácia nas tarefas relacionadas ao código, embora seus aprimoramentos sobre o GPT-3.5 nas métricas de comportamento sejam triviais. Entre os dois LLMs de código aberto, apesar de Starchat-𝛽-16b ter mais parâmetros, o Codellama-13b supera todas as métricas. Isso sugere que a arquitetura e a qualidade dos dados do modelo afetam significativamente o desempenho além do número de parâmetros.

4.5 RQ5: Causas raiz e tipos de erro de mutações não compiláveis

Mutações não compiláveis ​​requerem uma etapa de compilação para filtrar, o que resulta em recursos computacionais desperdiçados. Conforme mencionado na Seção 4.1, os LLMs geram um número significativo de mutações não compiláveis. Este RQ analisa os tipos de erros e possíveis causas radiculares dessas mutações não compiláveis. Após a configuração das etapas anteriores, primeiro amostra 384 mutações de não compilação das saídas do GPT-3.5, garantindo que o nível de confiança seja de 95% e a margem de erro seja de 5%. A partir da análise guide dessas mutações não compiláveis, identificamos 9 tipos de erro distintos, conforme mostrado na Tabela 8.

Mostrado como Tabela 8, o tipo de erro mais comum, o uso de métodos desconhecidos, representa 27,34% do whole de erros, revelando a questão da alucinação de modelos generativos [30]. A destruição estrutural do código é o segundo erro mais comum, responsável por 22,92%, indicando que garantir que os códigos gerados sejam sintaticamente corretos continuam sendo um desafio para o LLMS atual. Este resultado sugere que ainda há espaço significativo para melhorias nos LLMs atuais.

Para analisar quais tipos de código são propensos a fazer com que os LLMs gerem mutações não compiláveis, examinamos os locais de código de todas as mutações não compiláveis ​​geradas pelo GPT-3.5, Codellama, Leam e 𝜇BerT na seção 4.1, como mostrado na Figura 3. Para todas as abordagens, as dicas de código com a metodinvocação. Em explicit, existem mais de 30% das mutações não compiláveis ​​no native com o MethodInvocation e 20% ocorrem no native com a referência de membros. Isso é potencialmente causado pela complexidade inerente dessas operações, que geralmente envolvem múltiplas dependências e referências. Se qualquer método ou membro necessário estiver ausente ou especificado incorretamente, ele poderá facilmente levar a mutações não compiláveis. Os erros destacam a necessidade de uma melhor geração de mutação com reconhecimento de contexto, garantindo que o método chama e as referências de membros se alinhem à estrutura do programa pretendida. Além disso, inspecionamos as mutações de exclusão rejeitadas pelo compilador e descobrimos que, para GPT-3.5, Codellama, Leam, 𝜇bert e Main, essas mutações representam 7,1%, 0,2%, 45,3%, 0,14percente 14,4percentde todas as suas mutações não compiláveis, respectivamente. Assim, para os LLMs, a exclusão não é a principal razão para a não compilação.