Améliorer les mutations d'amélioration génétique à l'aide de grands modèles de langage

Aperçu du contenu

• Abstrait
• Introduction
• Montage expérimental
• Résultats
• Conclusions et travaux futurs
• Les références

Abstrait

Les grands modèles de langage (LLM) ont été appliqués avec succès aux tâches de génie logiciel, y compris la réparation de programmes. Cependant, leur application dans les techniques basées sur la recherche telles que l’amélioration génétique (IG) est encore largement inexplorée. Dans cet article, nous évaluons l'utilisation des LLM comme opérateurs de mutation pour l'IG afin d'améliorer le processus de recherche. Nous élargissons la boîte à outils Gin Java GI pour appeler l'API d'OpenAI afin de générer des modifications pour l'outil JCodec. Nous échantillonnons de manière aléatoire l'espace des modifications en utilisant 5 types de modifications différents. Nous constatons que le nombre de correctifs réussissant les tests unitaires est jusqu'à 75 % plus élevé avec les modifications basées sur LLM qu'avec les modifications par insertion standard. De plus, nous observons que les correctifs trouvés avec les LLM sont généralement moins diversifiés que les modifications standard. Nous avons exécuté GI avec une recherche locale pour trouver des améliorations d'exécution. Bien que de nombreux correctifs d'amélioration soient trouvés par l'IG amélioré par LLM, le meilleur correctif d'amélioration a été trouvé par l'IG standard.

Introduction

À mesure que les systèmes logiciels deviennent plus grands et plus complexes, un effort manuel important est nécessaire pour les maintenir [2]. Pour réduire les efforts des développeurs dans les tâches de maintenance et d’optimisation des logiciels, des paradigmes automatisés sont essentiels. L'amélioration génétique (GI) [15] applique des techniques basées sur la recherche pour améliorer les propriétés non fonctionnelles des logiciels existants telles que le temps d'exécution ainsi que les propriétés fonctionnelles telles que la réparation de bogues. Bien que l'IG ait connu du succès dans l'industrie [12,13], elle reste limitée par l'ensemble des opérateurs de mutation qu'elle emploie dans la recherche [14].

Les grands modèles linguistiques (LLM) ont un large éventail d'applications car ils sont capables de traiter des requêtes textuelles sans formation supplémentaire pour la tâche particulière à accomplir. Les LLM ont été pré-entraînés sur des millions de référentiels de code couvrant de nombreux langages de programmation différents [5]. Leur utilisation pour des tâches d'ingénierie logicielle a eu un grand succès [9,6], se montrant également prometteuse pour la réparation de programmes [17,19].

Kang et Yoo [10] ont suggéré qu'il existe un potentiel inexploité dans l'utilisation des LLM pour améliorer l'IG. GI utilise les mêmes opérateurs de mutation pour différentes tâches d'optimisation. Ces opérateurs sont fabriqués à la main avant de démarrer la recherche et aboutissent ainsi à un espace de recherche limité. Nous émettons l’hypothèse que l’augmentation des suggestions de correctifs LLM en tant qu’opérateur de mutation supplémentaire enrichira l’espace de recherche et aboutira à des variantes plus efficaces.

Dans cet article, nous menons plusieurs expériences pour déterminer si l'utilisation des LLM comme opérateur de mutation en GI peut améliorer l'efficience et l'efficience de la recherche. Nos résultats montrent que les correctifs générés par LLM ont des taux de compilation de 51,32 % et 53,54 % respectivement pour la recherche aléatoire et la recherche locale (avec la catégorie d'invite Medium). Auparavant, il a été démontré que les LLM (utilisant un modèle LLM tel quel) produisaient du code compilé environ 40 % du temps [16,18]. Nous constatons que les vérifications basées sur LLM échantillonnées de manière aléatoire ont été compilées et ont réussi les tests unitaires plus souvent que les vérifications GI standard. Nous observons que le nombre de correctifs réussissant les tests unitaires est jusqu'à 75 % plus élevé pour les modifications basées sur LLM que pour les modifications par GI Insert. Cependant, nous observons que les correctifs trouvés avec les LLM sont moins diversifiés. Pour la recherche locale, la meilleure amélioration est obtenue en utilisant les modifications standard de la déclaration GI, suivies par les modifications basées sur LLM. Ces résultats démontrent le potentiel des LLM en tant qu’opérateurs de mutation et soulignent la nécessité de poursuivre les recherches dans ce domaine.

Montage expérimental

Pour analyser l'utilisation des LLM comme opérateur de mutation en GI, nous avons utilisé le modèle GPT 3.5 Turbo d'OpenAI et la boîte à outils GI Gin [3]. Nous avons expérimenté deux types de recherche implémentés dans Gin : la recherche aléatoire et la recherche locale. Les requêtes au LLM utilisant l'API OpenAI se faisaient via la bibliothèque Langchain4J, avec une température de 0,7. Le projet cible pour l'amélioration de nos expériences était le projet populaire JCodec [7] qui est écrit en Java. Les méthodes « chaudes » devant être ciblées par les modifications ont été identifiées à l'aide de l'outil de profilage de Gin en répétant le profilage 20 fois et en prenant l'union de l'ensemble résultant.

Pour les expériences d'échantillonnage aléatoire, nous avons configuré les exécutions avec des modifications au niveau de l'instruction (copier/supprimer/remplacer/échanger à partir de [14] et insérer une pause/continuer/revenir à partir de [4]) et des modifications LLM, générant 1 000 de chaque type au hasard. . Un délai d'attente de 10 000 millisecondes a été utilisé pour chaque test unitaire afin de détecter les boucles infinies introduites par les modifications ; le dépassement du délai d'attente compte comme un échec du test. Pour la recherche locale, des expériences ont été mises en place de la même manière. Il y a eu 10 exécutions répétées (une pour chacune des 10 principales méthodes à chaud), mais les exécutions étaient limitées à 100 évaluations, ce qui donnait un total de 1 000 évaluations, correspondant à la recherche aléatoire. En pratique, cela représentait 99 modifications par exécution, la première étant utilisée pour chronométrer le code original non corrigé.

Nous avons expérimenté trois invites différentes pour envoyer des requêtes au LLM pour les deux types de recherche : une invite simple, une invite moyenne et une invite détaillée. Avec les trois invites, notre implémentation demande cinq variantes différentes du code disponible. L'invite simple demande uniquement le code sans aucune information supplémentaire. L'invite moyenne fournit plus d'informations sur le code fourni et les exigences, comme le montre la figure 1. Plus précisément, nous fournissons au LLM le langage de programmation utilisé, le projet auquel appartient le code, ainsi que les instructions de formatage. L'invite détaillée étend l'invite moyenne avec un exemple de modification utile. Cet exemple est tiré des résultats obtenus par Brownlee et al. [4]. Le correctif est une instance réussie de la modification par insertion appliquée au projet jCodec (c'est-à-dire une modification qui a compilé, réussi les tests unitaires et offert une accélération par rapport au code original). Nous utilisons le même exemple pour toutes les requêtes d'invite détaillées utilisées dans nos expériences ; en effet, les LLM sont capables de raisonnement inductif dans lequel l'utilisateur présente des informations spécifiques, et le LLM peut utiliser cette entrée pour générer des déclarations plus générales, encore améliorées dans GPT-4 [8].

Les modifications LLM sont appliquées en sélectionnant une instruction de bloc au hasard dans une méthode cible « à chaud ». Le contenu de ce bloc se trouve in the prompt. The first code block in the LLM response is identified. Gin uses JavaParser (https://javaparser.org) internally to represent target source files, so we attempt to parse the LLM suggestion with JavaParser, and replace the original block with the LLM suggestion.

Résultats

La première expérience compare les mutations GI standard, à savoir les modifications d'insertion et d'instruction, avec les modifications LLM utilisant des invites différemment détaillées (simples, moyennes et détaillées) à l'aide d'un échantillonnage aléatoire. Le tableau 1 montre les résultats pour tous les correctifs ainsi que pour les correctifs uniques uniquement. Nous indiquons combien de correctifs ont été analysés avec succès par JavaParser (nommés Valid), combien compilés et combien ont réussi tous les tests unitaires (nommés Réussi). Nous avons exclu les correctifs syntaxiquement équivalents au logiciel d'origine. Les meilleurs résultats sont en gras .

Nous constatons que même si beaucoup plus de correctifs valides ont été trouvés avec les modifications standard Insert et Statement, davantage de correctifs réussis ont pu être trouvés en utilisant les modifications générées par LLM. En particulier, pour les invites moyennes et détaillées, 292 et 230 correctifs ont réussi les tests unitaires, respectivement. Pour les éditions Insert et Statement, seuls 166 et 91 ont réussi les tests unitaires, respectivement. De manière anecdotique, les méthodes chaudes avec les taux de réussite des correctifs les plus bas/plus élevés différaient pour chaque opérateur : comprendre cette variation sera intéressant pour une enquête future.

Il est également à noter que les correctifs LLM sont moins diversifiés : plus de 50 % de correctifs uniques en plus ont été trouvés par les opérateurs de mutation standard que le LLM utilisant Medium,

et des invites détaillées. Cependant, avec l'invite Simple, aucun correctif n'a réussi les tests unitaires, car les modifications suggérées ne pouvaient souvent pas être analysées. Des invites détaillées sont donc nécessaires pour forcer LLM à générer des sorties utilisables.

Nous avons étudié plus en détail les différences entre les invites Medium et Détaillées pour comprendre la réduction des performances avec Détaillé (dans les ensembles de correctifs uniques), car Medium avait un nombre plus élevé de correctifs compilés et transmis. Aux deux niveaux d'invite, la réponse générée était la même pour 42 cas (sur le total de cas valides uniques). Cependant, Detail avait tendance à générer des réponses plus longues avec une moyenne de 363 caractères, alors que Medium avait une moyenne de 304 caractères. Nous avons examiné manuellement plusieurs réponses rapides détaillées, dans lesquelles nous avons identifié certaines incluant des variables provenant d'autres fichiers, offrant potentiellement une expansion significative de l'ensemble des variantes de code que GI peut explorer.

La deuxième expérience élargit notre analyse en comparant les performances des modifications standard et LLM avec la recherche locale. Le tableau 2 présente les résultats de l'expérience de recherche locale. Nous rapportons le nombre de correctifs compilés et transmis ainsi que le nombre de correctifs pour lesquels des améliorations d'exécution ont été trouvées. De plus, nous rapportons l’amélioration médiane et la meilleure en millisecondes (ms). Dans le tableau, nous avons exclu tous les correctifs vides. Comme auparavant, les meilleurs résultats sont en gras .

Encore une fois, nous constatons que davantage de correctifs réussissant les tests unitaires pourraient être trouvés avec le LLM à l'aide des invites Medium et Détaillées. De plus, d’autres améliorations pourraient être trouvées en utilisant le LLM avec ces invites. Plus précisément, avec Medium et Detail, nous avons trouvé respectivement 164 et 196 améliorations, alors que nous n'en avons trouvé que 136 avec Insert et 71 avec Statement. La meilleure amélioration a pu être trouvée avec 508 ms avec l'édition Statement. La meilleure amélioration trouvée à l'aide des LLM (en utilisant l'invite Medium) n'a permis d'améliorer le temps d'exécution que de 395 ms. Nous avons également examiné une série de modifications dans les résultats de la recherche locale pour mieux comprendre les distinctions entre les invites moyennes et détaillées en raison du faible taux de compilation des réponses aux invites détaillées. Dans l'exemple, une séquence de modifications visait à intégrer un appel à la fonction clip. L'invite détaillée a tenté d'incorporer l'appel presque immédiatement dans quelques modifications, ce qui a probablement conduit à un code invalide. En revanche, l'invite Medium a apporté des changements moins radicaux, affinant progressivement le code. Il a commencé par remplacer l'expression de l'opérateur ternaire par une instruction if-then-else et des appels de fonction système avant de finalement tenter d'incorporer l'appel de fonction clip.

Conclusions et travaux futurs

L'amélioration génétique des logiciels dépend fortement des opérateurs de mutation qu'ils utilisent dans le processus de recherche. Pour diversifier les opérateurs et enrichir davantage l'espace de recherche, nous avons incorporé un Large Language Model (LLM) en tant qu'opérateur.

Limites . Pour généraliser, les travaux futurs devraient considérer des projets autres que notre cible, jCodec. Nos expériences utilisaient une API ne nous donnant aucun contrôle sur les réponses générées par le LLM ni aucun moyen de les modifier ou de les optimiser. Bien que nous n'ayons pas observé de changements de comportement au cours de nos expériences, OpenAI peut modifier le modèle à tout moment, les travaux futurs devraient donc prendre en compte les modèles locaux. Nous avons testé seulement trois types d'invites pour les demandes LLM et, parmi ce nombre limité d'invites, nous avons constaté une variation dans les résultats. Enfin, notre implémentation pour analyser les réponses des LLM était relativement simpliste. Cependant, cela signifierait seulement que nos résultats rapportés sont pessimistes et qu'une amélioration encore plus importante pourrait être obtenue par l'opérateur basé sur LLM.

Résumé . Nous avons constaté que, bien que des correctifs plus valides et plus diversifiés aient été trouvés avec des modifications standard utilisant l'échantillonnage aléatoire, davantage de correctifs réussissant les tests unitaires ont été trouvés avec des modifications basées sur LLM. Par exemple, avec la modification LLM utilisant l'invite Medium, nous avons trouvé plus de 75 % de correctifs en plus réussissant les tests unitaires qu'avec la modification Insertion classique. Dans notre expérience de recherche locale, nous avons trouvé la meilleure amélioration avec la modification de la déclaration (508 ms). La meilleure amélioration basée sur LLM a été trouvée avec l'invite Medium (395 ms). Il existe donc un potentiel dans l'exploration d'approches combinant à la fois les modifications LLM et GI « classiques ».

Nos expériences ont révélé que les invites utilisées pour les requêtes LLM affectent grandement les résultats. Ainsi, dans les travaux futurs, nous espérons expérimenter davantage l’ingénierie rapide. Il peut également être utile de mélanger les invites : par exemple, en commençant par moyen puis en passant à détaillé pour effectuer des modifications plus importantes qui s'écartent des minima locaux. De plus, la possibilité de combiner les éditions LLM avec d'autres telles que les modèles standard de copie/suppression/remplacement/échange ou PAR [11] pourrait être intéressante. Enfin, nous espérons mener des expérimentations plus approfondies sur des programmes de tests supplémentaires.

Disponibilité des données. Le code, l'infrastructure d'invite et expérimentale du LLM, les données de l'évaluation et les résultats sont disponibles en open source sur [1]. Le code se trouve également sous la branche 'llm' de github.com/gintool/gin (commit 9fe9bdf ; dérivé du master commit 2359f57 en attendant une intégration complète avec Gin).

Remerciements UKRI EPSRC EP/P023991/1 et ERC 741278.

Les références

1. Artefact d’amélioration des mutations d’amélioration génétique à l’aide de grands modèles de langage. Zenodo (septembre 2023). https://doi.org/10.5281/zenodo.8304433

   
   

2. B¨ohme, M., Soremekun, EO, Chattopadhyay, S., Ugherughe, E., Zeller, A. : Où est le bug et comment est-il corrigé ? Une expérience avec des praticiens. Dans : Proc. Symposium ACM sur les fondements du génie logiciel. pp. 117-128 (2017)

   
   

3. Brownlee, AE, Petke, J., Alexander, B., Barr, ET, Wagner, M., White, DR : Gin : la recherche sur l'amélioration génétique facilitée. Dans : GECCO. pp. 985-993 (2019)

   
   

4. Brownlee, AE, Petke, J., Rasburn, AF : injection de raccourcis pour une exécution plus rapide du code Java. Dans : IEEE CEC 2020. p. 1 à 8

   
   

5. Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, HPdO, Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al. : Évaluation de grands modèles de langage formés sur le code. Préimpression arXiv arXiv:2107.03374 (2021)

   
   

6. Fan, A., Gokkaya, B., Harman, M., Lyubarskiy, M., Sengupta, S., Yoo, S., Zhang, JM : Grands modèles de langage pour le génie logiciel : enquête et problèmes ouverts (2023)

7. Github - jcodec/jcodec : dépôt principal de Jcodec, https://github.com/jcodec/jcodec

   
   

8. Han, SJ, Ransom, KJ, Perfors, A., Kemp, C. : Raisonnement inductif chez l'homme et grands modèles de langage. Recherche sur les systèmes cognitifs p. 101155 (2023)

   
   

9. Hou, X., Liu, Y., Yang, Z., Grundy, J., Zhao, Y., Li, L., Wang, K., Luo, X., Lo, D., Wang, H. : Grands modèles de langage pour le génie logiciel : une revue systématique de la littérature. arXiv:2308.10620 (2023)

   
   

10. Kang, S., Yoo, S. : Vers une amélioration génétique adaptée aux objectifs grâce à de grands modèles linguistiques. arXiv:2304.09386 (2023)

    
    

11. Kim, D., Nam, J., Song, J., Kim, S. : Génération automatique de correctifs tirés des correctifs écrits par l'homme (2013), http://logging.apache.org/log4j/

    
    

12. Kirbas, S., Windels, E., Mcbello, O., Kells, K., Pagano, M., Szalanski, R., Nowack, V., Winter, E., Counsell, S., Bowes, D., Hall, T., Haraldsson, S., Woodward, J. : Sur l'introduction de la réparation automatique des programmes dans Bloomberg. Logiciel IEEE 38(4), 43-51 (2021)

    
    

13. Marginean, A., Bader, J., Chandra, S., Harman, M., Jia, Y., Mao, K., Mols, A., Scott, A. : Sapfix : Réparation automatisée de bout en bout à échelle. Dans : ICSE-SEIP. pages 269 à 278 (2019)

    
    

14. Petke, J., Alexander, B., Barr, ET, Brownlee, AE, Wagner, M., White, DR : Paysages de transformation de programme pour la modification automatisée de programmes à l'aide de Gin. Génie logiciel empirique 28(4), 1–41 (2023)

    
    

15. Petke, J., Haraldsson, SO, Harman, M., Langdon, WB, White, DR, Woodward, JR : Amélioration génétique des logiciels : une enquête complète. Transactions IEEE sur le calcul évolutif 22, 415-432 (2018)

    
    

16. Siddiq, ML, Santos, J., Tanvir, RH, Ulfat, N., Rifat, FA, Lopes, VC : Explorer l'efficacité des grands modèles de langage dans la génération de tests unitaires. Préimpression arXiv arXiv:2305.00418 (2023)

    
    

17. Sobania, D., Briesch, M., Hanna, C., Petke, J. : Une analyse des performances de correction automatique des bogues de chatgpt. Dans : Atelier international IEEE/ACM 2023 sur la réparation automatisée de programmes (APR). p. 23-30. Société informatique IEEE (2023)

    
    

18. Xia, CS, Paltenghi, M., Tian, JL, Pradel, M., Zhang, L. : Fuzzing universel via de grands modèles de langage. Préimpression arXiv arXiv:2308.04748 (2023)

    
    

19. Xia, CS, Zhang, L. : Poursuivez la conversation : correction de 162 bogues sur 337 pour 0,42 $ chacun à l'aide de chatgpt. Préimpression arXiv arXiv:2304.00385 (2023)