Verbesserung genetischer Verbesserungsmutationen mithilfe großer Sprachmodelle

Inhaltsübersicht

• Abstrakt
• Einführung
• Versuchsaufbau
• Ergebnisse
• Schlussfolgerungen und zukünftige Arbeit
• Verweise

Abstrakt

Große Sprachmodelle (LLMs) wurden erfolgreich auf Software-Engineering-Aufgaben angewendet, einschließlich der Programmreparatur. Ihre Anwendung in suchbasierten Techniken wie Genetic Improvement (GI) ist jedoch noch weitgehend unerforscht. In diesem Artikel bewerten wir die Verwendung von LLMs als Mutationsoperatoren für GI, um den Suchprozess zu verbessern. Wir erweitern das Gin Java GI-Toolkit, um die OpenAI-API aufzurufen und Bearbeitungen für das JCodec-Tool zu generieren. Wir testen den Bearbeitungsraum nach dem Zufallsprinzip anhand von fünf verschiedenen Bearbeitungstypen. Wir stellen fest, dass die Anzahl der Patches, die Unit-Tests bestehen, bei LLM-basierten Bearbeitungen bis zu 75 % höher ist als bei standardmäßigen Insert-Bearbeitungen. Darüber hinaus stellen wir fest, dass die mit LLMs gefundenen Patches im Vergleich zu Standardbearbeitungen im Allgemeinen weniger vielfältig sind. Wir haben GI mit lokaler Suche ausgeführt, um Laufzeitverbesserungen zu finden. Obwohl viele Verbesserungspflaster durch LLM-verstärkte GI gefunden werden, wurde das beste Verbesserungspflaster durch Standard-GI gefunden.

Einführung

Da Softwaresysteme immer größer und komplexer werden, ist ein erheblicher manueller Aufwand für deren Wartung erforderlich [2]. Um den Entwickleraufwand bei Softwarewartungs- und -optimierungsaufgaben zu reduzieren, sind automatisierte Paradigmen unerlässlich. Genetic Improvement (GI) [15] wendet suchbasierte Techniken an, um nichtfunktionale Eigenschaften vorhandener Software wie die Ausführungszeit sowie funktionale Eigenschaften wie das Reparieren von Fehlern zu verbessern. Obwohl GI in der Industrie Erfolg hatte [12,13], bleibt es durch die Menge an Mutationsoperatoren, die es bei der Suche verwendet, begrenzt [14].

Large Language Models (LLMs) haben ein breites Anwendungsspektrum, da sie in der Lage sind, Textabfragen ohne zusätzliche Schulung für die jeweilige Aufgabe zu verarbeiten. LLMs wurden auf Millionen von Code-Repositories in vielen verschiedenen Programmiersprachen vorab trainiert [5]. Ihr Einsatz für Software-Engineering-Aufgaben war sehr erfolgreich [9,6] und erweist sich auch für die Programmreparatur als vielversprechend [17,19].

Kang und Yoo [10] haben darauf hingewiesen, dass der Einsatz von LLMs zur Verbesserung des Gastrointestinaltrakts ungenutztes Potenzial bietet. GI verwendet dieselben Mutationsoperatoren für verschiedene Optimierungsaufgaben. Diese Operatoren werden vor Beginn der Suche manuell erstellt und führen daher zu einem begrenzten Suchraum. Wir gehen davon aus, dass die Erweiterung der LLM-Patch-Vorschläge als zusätzlicher Mutationsoperator den Suchraum bereichert und zu erfolgreicheren Varianten führt.

In diesem Artikel führen wir mehrere Experimente durch, um zu untersuchen, ob die Verwendung von LLMs als Mutationsoperator im GI die Effizienz und Wirksamkeit der Suche verbessern kann. Unsere Ergebnisse zeigen, dass die von LLM generierten Patches Kompilierungsraten von 51,32 % bzw. 53,54 % für die Zufallssuche bzw. lokale Suche (mit der Eingabeaufforderungskategorie „Mittel“) aufweisen. Zuvor wurde gezeigt, dass LLMs (unter Verwendung eines LLM-Modells im Ist-Zustand) Code erzeugen, der in etwa 40 % der Fälle kompiliert werden kann [16,18]. Wir stellen fest, dass zufällig ausgewählte LLM-basierte Bearbeitungen im Vergleich zu Standard-GI-Bearbeitungen häufiger Komponententests kompilierten und bestanden haben. Wir stellen fest, dass die Anzahl der Patches, die Unit-Tests bestehen, bei LLM-basierten Bearbeitungen bis zu 75 % höher ist als bei GI-Insert-Bearbeitungen. Wir stellen jedoch fest, dass die mit LLMs gefundenen Patches weniger vielfältig sind. Bei der lokalen Suche wird die beste Verbesserung durch standardmäßige GI-Erklärungsbearbeitungen erzielt, gefolgt von LLM-basierten Bearbeitungen. Diese Ergebnisse verdeutlichen das Potenzial von LLMs als Mutationsoperatoren und unterstreichen den Bedarf an weiterer Forschung in diesem Bereich.

Versuchsaufbau

Um die Verwendung von LLMs als Mutationsoperator im GI zu analysieren, verwendeten wir das GPT 3.5 Turbo-Modell von OpenAI und die GI-Toolbox Gin [3]. Wir haben mit zwei in Gin implementierten Suchtypen experimentiert: Zufallssuche und lokale Suche. Anfragen an das LLM über die OpenAI-API erfolgten über die Langchain4J-Bibliothek mit einer Temperatur von 0,7. Das Zielprojekt für Verbesserungen in unseren Experimenten war das beliebte JCodec-Projekt [7], das in Java geschrieben ist. „Hot“-Methoden, auf die die Änderungen abzielen, wurden mit Gins Profiler-Tool identifiziert, indem die Profilerstellung 20 Mal wiederholt und die Vereinigung der resultierenden Menge ermittelt wurde.

Für die Zufallsstichprobenexperimente richten wir die Läufe mit Bearbeitungen auf Anweisungsebene (Kopieren/Löschen/Ersetzen/Austauschen aus [14] und Einfügen von Pause/Fortfahren/Zurück aus [4]) und LLM-Bearbeitungen ein und generieren 1000 von jedem Typ nach dem Zufallsprinzip . Für jeden Komponententest wurde ein Zeitlimit von 10.000 Millisekunden verwendet, um durch Bearbeitungen verursachte Endlosschleifen abzufangen. Das Überschreiten des Timeouts gilt als Testfehler. Für die lokale Suche wurden Experimente ähnlich aufgebaut. Es gab 10 Wiederholungsläufe (einen für jede der 10 angesagtesten Methoden), aber die Läufe waren auf 100 Bewertungen begrenzt, was insgesamt 1000 Bewertungen ergab, was der Zufallssuche entsprach. In der Praxis waren dies 99 Bearbeitungen pro Durchlauf, da die erste zur Zeitmessung des ursprünglichen, nicht gepatchten Codes verwendet wurde.

Wir haben mit drei verschiedenen Eingabeaufforderungen zum Senden von Anfragen an das LLM für beide Suchtypen experimentiert: einer einfachen Eingabeaufforderung, einer mittleren Eingabeaufforderung und einer detaillierten Eingabeaufforderung. Bei allen drei Eingabeaufforderungen fordert unsere Implementierung fünf verschiedene Variationen des vorliegenden Codes an. Die einfache Eingabeaufforderung fordert lediglich den Code ohne weitere Informationen an. Die Medium-Eingabeaufforderung liefert weitere Informationen über den bereitgestellten Code und die Anforderungen, wie in Abbildung 1 dargestellt. Konkret stellen wir dem LLM die verwendete Programmiersprache, das Projekt, zu dem der Code gehört, sowie Formatierungsanweisungen zur Verfügung. Die detaillierte Eingabeaufforderung erweitert die mittlere Eingabeaufforderung um ein Beispiel für eine nützliche Änderung. Dieses Beispiel wurde den Ergebnissen von Brownlee et al. entnommen. [4]. Der Patch ist eine erfolgreiche Instanz der Einfügungsbearbeitung, die auf das jCodec-Projekt angewendet wurde (d. h. eine Bearbeitung, die kompiliert wurde, die Unit-Tests bestanden hat und eine Beschleunigung gegenüber dem Originalcode bot). Wir verwenden dasselbe Beispiel für alle detaillierten Eingabeaufforderungen, die in unseren Experimenten verwendet werden. Dies liegt daran, dass LLMs zu induktivem Denken fähig sind, bei dem der Benutzer spezifische Informationen präsentiert, und das LLM diese Eingaben verwenden kann, um allgemeinere Aussagen zu generieren, was in GPT-4 [8] weiter verbessert wurde.

LLM-Änderungen werden durch zufällige Auswahl einer Blockanweisung in einer „heißen“ Zielmethode angewendet. Der Inhalt dieses Blocks befindet sich 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.

Ergebnisse

Das erste Experiment vergleicht Standard-GI-Mutationen, nämlich Insert- und Statement-Bearbeitungen, mit LLM-Bearbeitungen, die unterschiedlich detaillierte Eingabeaufforderungen (einfach, mittel und detailliert) unter Verwendung von Zufallsstichproben verwenden. Tabelle 1 zeigt die Ergebnisse für alle Patches sowie nur für einzelne Patches. Wir berichten, wie viele Patches erfolgreich von JavaParser analysiert wurden (als „Valid“ bezeichnet), wie viele kompiliert wurden und wie viele alle Komponententests bestanden haben (als „Passed“ bezeichnet). Wir haben Patches ausgeschlossen, die syntaktisch der Originalsoftware entsprechen. Die besten Ergebnisse sind fett gedruckt .

Wir sehen, dass mit den standardmäßigen Insert- und Statement-Bearbeitungen zwar wesentlich mehr gültige Patches gefunden wurden, mit den LLM-generierten Bearbeitungen jedoch mehr Pass-Patches gefunden werden konnten. Insbesondere bei den mittleren und detaillierten Eingabeaufforderungen bestanden 292 bzw. 230 Patches die Unit-Tests. Bei den Änderungen „Einfügen“ und „Anweisung“ bestanden nur 166 bzw. 91 die Komponententests. Anekdotischerweise waren die Hot-Methoden mit den niedrigsten/höchsten Patch-Pass-Raten für jeden Betreiber unterschiedlich. Das Verständnis dieser Variation wird für zukünftige Untersuchungen interessant sein.

Es ist auch bemerkenswert, dass LLM-Patches weniger vielfältig sind: Über 50 % mehr einzigartige Patches wurden von Standard-Mutationsoperatoren gefunden als das LLM, das Medium verwendet.

und detaillierte Eingabeaufforderungen. Mit der Simple-Eingabeaufforderung bestand jedoch kein einziger Patch die Unit-Tests, da die vorgeschlagenen Änderungen oft nicht geparst werden konnten. Daher sind detaillierte Eingabeaufforderungen erforderlich, um LLM zu zwingen, verwertbare Ausgaben zu generieren.

Wir haben die Unterschiede zwischen den Eingabeaufforderungen „Medium“ und „Detailliert“ weiter untersucht, um die Leistungseinbußen bei „Detailliert“ (in den einzelnen Patch-Sets) zu verstehen, da „Medium“ eine höhere Anzahl kompilierter und übergebener Patches aufwies. In beiden Eingabeaufforderungsebenen war die generierte Antwort in 42 Fällen (von der Gesamtzahl der eindeutig gültigen Fälle) gleich. Allerdings generierte „Detailliert“ tendenziell längere Antworten mit durchschnittlich 363 Zeichen, während „Mittel“ durchschnittlich 304 Zeichen hatte. Wir haben mehrere detaillierte Eingabeaufforderungsantworten manuell untersucht und dabei festgestellt, dass einige Variablen aus anderen Dateien enthalten, was möglicherweise eine erhebliche Erweiterung des Satzes an Codevarianten darstellt, die GI untersuchen kann.

Das zweite Experiment erweitert unsere Analyse und vergleicht die Leistung der Standard- und LLM-Bearbeitungen mit der lokalen Suche. Tabelle 2 zeigt die Ergebnisse des Local Search-Experiments. Wir berichten über die Anzahl der Kompilierungs- und Weitergabe-Patches sowie über die Anzahl der Patches, bei denen Laufzeitverbesserungen gefunden wurden. Darüber hinaus geben wir den Median und die beste Verbesserung in Millisekunden (ms) an. In der Tabelle haben wir alle leeren Patches ausgeschlossen. Wie zuvor sind die besten Ergebnisse fett gedruckt .

Auch hier sehen wir, dass mit dem LLM mithilfe der Eingabeaufforderungen „Mittel“ und „Detaillierte“ mehr Patches gefunden werden konnten, die die Komponententests bestanden. Darüber hinaus könnten durch die Verwendung des LLM mit diesen Eingabeaufforderungen weitere Verbesserungen erzielt werden. Konkret fanden wir bei „Medium“ und „Detailliert“ 164 bzw. 196 Verbesserungen, während wir bei „Einfügen“ nur 136 und bei „Anweisung“ nur 71 fanden. Die beste Verbesserung konnte mit 508 ms beim Statement-Edit erzielt werden. Die beste Verbesserung, die mit LLMs (mit der Eingabeaufforderung „Medium“) gefunden wurde, konnte die Laufzeit nur um 395 ms verbessern. Wir haben auch eine Reihe von Änderungen in den Ergebnissen der lokalen Suche untersucht, um Einblicke in die Unterschiede zwischen mittleren und detaillierten Eingabeaufforderungen zu gewinnen, da die Kompilierungsrate der Antworten auf detaillierte Eingabeaufforderungen niedrig ist. Im Beispiel zielte eine Folge von Bearbeitungen darauf ab, einen Funktionsaufruf in den Clip einzubinden. Die detaillierte Eingabeaufforderung versuchte, den Aufruf innerhalb weniger Änderungen fast sofort zu integrieren, was wahrscheinlich zu ungültigem Code führte. Andererseits nahm die Medium-Eingabeaufforderung weniger radikale Änderungen vor und verfeinerte den Code schrittweise. Es begann damit, den ternären Operatorausdruck durch eine if-then-else-Anweisung und Systemfunktionsaufrufe zu ersetzen, bevor schließlich versucht wurde, den Clip-Funktionsaufruf einzubinden.

Schlussfolgerungen und zukünftige Arbeit

Die genetische Verbesserung von Software hängt in hohem Maße von den Mutationsoperatoren ab, die sie im Suchprozess verwendet. Um die Operatoren zu diversifizieren und den Suchraum weiter zu bereichern, haben wir ein Large Language Model (LLM) als Operator integriert.

Einschränkungen . Zusammenfassend lässt sich sagen, dass zukünftige Arbeiten neben unserem Ziel jCodec auch andere Projekte berücksichtigen sollten. Unsere Experimente verwendeten eine API, die uns keine Kontrolle über die vom LLM generierten Antworten oder irgendeine Möglichkeit gab, sie zu ändern oder zu optimieren. Obwohl wir während unserer Experimente keine Verhaltensänderungen beobachtet haben, kann OpenAI das Modell jederzeit ändern, sodass zukünftige Arbeiten lokale Modelle berücksichtigen sollten. Wir haben nur mit drei Eingabeaufforderungstypen für LLM-Anfragen experimentiert und innerhalb dieser begrenzten Anzahl von Eingabeaufforderungen eine Variation in den Ergebnissen festgestellt. Schließlich war unsere Implementierung zum Parsen der Antworten der LLMs relativ einfach. Dies würde jedoch nur bedeuten, dass unsere gemeldeten Ergebnisse pessimistisch sind und eine noch größere Verbesserung durch den LLM-basierten Betreiber erzielt werden könnte.

Zusammenfassung . Wir haben festgestellt, dass bei Standardbearbeitungen mit Zufallsstichproben zwar mehr gültige und vielfältigere Patches gefunden wurden, bei LLM-basierten Bearbeitungen jedoch mehr Patches, die die Unit-Tests bestanden. Bei der LLM-Bearbeitung mit der Eingabeaufforderung „Medium“ haben wir beispielsweise festgestellt, dass über 75 % mehr Patches die Unit-Tests bestanden haben als bei der klassischen Insert-Bearbeitung. In unserem Experiment zur lokalen Suche haben wir die beste Verbesserung mit der Anweisungsbearbeitung (508 ms) festgestellt. Die beste LLM-basierte Verbesserung wurde mit der mittleren Eingabeaufforderung (395 ms) gefunden. Daher besteht Potenzial in der Erforschung von Ansätzen, die sowohl LLM- als auch „klassische“ GI-Bearbeitungen kombinieren.

Unsere Experimente haben gezeigt, dass die für LLM-Anfragen verwendeten Eingabeaufforderungen einen großen Einfluss auf die Ergebnisse haben. Daher hoffen wir, in zukünftigen Arbeiten mehr mit Prompt Engineering experimentieren zu können. Es kann auch hilfreich sein, Eingabeaufforderungen zu mischen: Beginnen Sie beispielsweise mit „Mittel“ und wechseln Sie dann zu „Detailliert“, um größere Änderungen vorzunehmen, die über lokale Mindestwerte hinausgehen. Darüber hinaus könnte die Möglichkeit interessant sein, LLM-Bearbeitungen mit anderen wie Standard-Kopieren/Löschen/Ersetzen/Austauschen oder PAR-Vorlagen [11] zu kombinieren. Schließlich hoffen wir, umfangreichere Experimente mit weiteren Testprogrammen durchführen zu können.

Datenverfügbarkeit. Der Code, die LLMs-Eingabeaufforderung und die experimentelle Infrastruktur, Daten aus der Evaluierung und Ergebnisse sind als Open Source unter [1] verfügbar. Der Code befindet sich auch im „llm“-Zweig von github.com/gintool/gin (Commit 9fe9bdf; verzweigt vom Master-Commit 2359f57 bis zur vollständigen Integration mit Gin).

Danksagungen UKRI EPSRC EP/P023991/1 und ERC 741278.

Verweise

1. Artefakt zur Verbesserung genetischer Verbesserungsmutationen mithilfe großer Sprachmodelle. Zenodo (September 2023). https://doi.org/10.5281/zenodo.8304433

   
   

2. Böhme, M., Soremekun, EO, Chattopadhyay, S., Ugherughe, E., Zeller, A.: Wo ist der Fehler und wie wird er behoben? Ein Experiment mit Praktikern. In: Proc. ACM-Symposium über die Grundlagen des Software-Engineerings. S. 117–128 (2017)

   
   

3. Brownlee, AE, Petke, J., Alexander, B., Barr, ET, Wagner, M., White, DR: Gin: Forschung zur genetischen Verbesserung leicht gemacht. In: GECCO. S. 985–993 (2019)

   
   

4. Brownlee, AE, Petke, J., Rasburn, AF: Verknüpfungen einfügen, um Java-Code schneller auszuführen. In: 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.: Evaluierung großer Sprachmodelle, die auf Code trainiert wurden. arXiv-Vorabdruck arXiv:2107.03374 (2021)

   
   

6. Fan, A., Gokkaya, B., Harman, M., Lyubarskiy, M., Sengupta, S., Yoo, S., Zhang, JM: Große Sprachmodelle für die Softwareentwicklung: Umfrage und offene Probleme (2023)

7. Github – jcodec/jcodec: Jcodec-Hauptrepo, https://github.com/jcodec/jcodec

   
   

8. Han, SJ, Ransom, KJ, Perfors, A., Kemp, C.: Induktives Denken beim Menschen und große Sprachmodelle. Kognitive Systemforschung p. 101155 (2023)

   
   

9. Hou, X., Liu, Y., Yang, Z., Grundy, J., Zhao, Y., Li, L., Wang, K., Luo, X., Lo, D., Wang, H.: Große Sprachmodelle für die Softwareentwicklung: Eine systematische Literaturrecherche. arXiv:2308.10620 (2023)

   
   

10. Kang, S., Yoo, S.: Auf dem Weg zu einer objektiven, maßgeschneiderten genetischen Verbesserung durch große Sprachmodelle. arXiv:2304.09386 (2023)

    
    

11. Kim, D., Nam, J., Song, J., Kim, S.: Automatische Patch-Generierung, gelernt aus von Menschen geschriebenen Patches (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.: Zur Einführung der automatischen Programmreparatur in Bloomberg. IEEE Software 38(4), 43–51 (2021)

    
    

13. Marginean, A., Bader, J., Chandra, S., Harman, M., Jia, Y., Mao, K., Mols, A., Scott, A.: Sapfix: Automatisierte End-to-End-Reparatur bei Skala. In: ICSE-SEIP. S. 269–278 (2019)

    
    

14. Petke, J., Alexander, B., Barr, ET, Brownlee, AE, Wagner, M., White, DR: Programmtransformationslandschaften für automatisierte Programmmodifikation mit Gin. Empirisches Software Engineering 28(4), 1–41 (2023)

    
    

15. Petke, J., Haraldsson, SO, Harman, M., Langdon, WB, White, DR, Woodward, JR: Genetische Verbesserung von Software: Eine umfassende Umfrage. IEEE Transactions on Evolutionary Computation 22, 415–432 (2018)

    
    

16. Siddiq, ML, Santos, J., Tanvir, RH, Ulfat, N., Rifat, FA, Lopes, VC: Untersuchung der Wirksamkeit großer Sprachmodelle bei der Generierung von Unit-Tests. arXiv-Vorabdruck arXiv:2305.00418 (2023)

    
    

17. Sobania, D., Briesch, M., Hanna, C., Petke, J.: Eine Analyse der automatischen Fehlerbehebungsleistung von chatgpt. In: 2023 IEEE/ACM International Workshop on Automated Program Repair (APR). S. 23–30. IEEE Computer Society (2023)

    
    

18. Xia, CS, Paltenghi, M., Tian, JL, Pradel, M., Zhang, L.: Universelles Fuzzing über große Sprachmodelle. arXiv-Vorabdruck arXiv:2308.04748 (2023)

    
    

19. Xia, CS, Zhang, L.: Halten Sie das Gespräch am Laufen: 162 von 337 Fehlern für jeweils 0,42 $ mit chatgpt behoben. arXiv-Vorabdruck arXiv:2304.00385 (2023)