💻 computer science

Evaluating LLMs on Java Code Snippet Adaptation Using a Mutation-Injection Framework

Dieses Paper schlägt ein Mutation-Injection-Framework vor, um große Sprachmodelle bei der instruktionsfreien Anpassung von Java-Code-Snippets zu evaluieren, wobei untersucht wird, wie die Leistung über verschiedene Anpassungstypen, Komplexitätsstufen und Kontextgranularitäten hinweg variiert, unter Verwendung eines Datensatzes, der aus Open-Source-Repositories mit starker Testabdeckung abgeleitet wurde.

Ursprüngliche Autoren: Ali Aman, Muhammad Asaduzzaman, Shaowei Wang, Chanchal K. Roy

Veröffentlicht 2026-06-30

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Ali Aman, Muhammad Asaduzzaman, Shaowei Wang, Chanchal K. Roy

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Koch, der in einem alten Kochbuch ein köstliches Rezept für „Spaghetti Carbonara“ findet. Sie möchten es für Ihre Freunde kochen, aber es gibt ein Problem: Ihre Freunde haben eine Allergie gegen Eier, und Sie haben nur einen winzigen Topf, nicht einen großen. Sie können das Rezept nicht einfach eins zu eins kopieren; Sie müssen es anpassen. Sie müssen die Eier durch etwas anderes ersetzen, die Garzeit ändern und vielleicht einen Schritt überspringen.

In der Welt der Programmierung machen Entwickler genau dasselbe. Sie finden ein Stück Code (ein „Snippet“), das für jemand anderen funktioniert, kopieren es und müssen es dann an ihr eigenes Projekt anpassen.

Dieses Papier ist ein Plan, um zu testen, wie gut Künstliche Intelligenz (KI) diese Aufgabe der „Rezeptanpassung“ eigenständig bewältigen kann, ohne dass ihr genau gesagt wird, was geändert werden muss.

Hier ist eine Aufschlüsselung des Plans des Papers unter Verwendung einfacher Analogien:

1. Das Problem: Der „Stille Koch“-Test

Derzeit, wenn wir eine KI bitten, Code zu reparieren, geben wir ihr meistens eine sehr spezifische Liste von Anweisungen, wie zum Beispiel: „Ändere den Variablennamen von 'x' zu 'y' und tausche die Bibliothek aus.“

Aber in der realen Welt schreiben Entwickler keine Listen. Sie sagen einfach: „Hier ist der Code, den ich kopiert habe; bringe ihn in meinem neuen Projekt zum Laufen.“ Die KI muss den Code und die neue Umgebung betrachten und die Änderungen selbst herausfinden. Die Autoren wollen wissen: Kann die KI die Änderungen herausfinden, ohne ein schrittweises Handbuch zu erhalten?

2. Die Lösung: Die „Mutationsmaschine“

Um dies fair zu testen, können die Autoren nicht einfach zufälligen Code aus dem Internet nehmen, da sie dann nicht genau wüssten, welche Änderungen die KI hätte vornehmen sollen.

Stattdessen bauen sie eine „Mutationsmaschine“ (ein Framework, das sie Mutation-Injection nennen). So funktioniert es:

Schritt 1: Sie beginnen mit einem perfekten, funktionierenden Stück Code, das bereits getestet wurde (wie ein perfektes Rezept).
Schritt 2: Sie nutzen einen Roboter, der den Code absichtlich auf eine spezifische, kontrollierte Weise „kaputt macht“ oder „verunstaltet“. Zum Beispiel könnten sie eine Variable umbenennen, eine Zahl ändern oder ein Werkzeug durch ein anderes ersetzen.
Schritt 3: Sie geben diesen „kaputten“ Code an die KI weiter und sagen: „Repariere das, damit es wieder funktioniert.“
Schritt 4: Wenn die KI es repariert und der Code alle Tests besteht, erhält die KI einen Punkt.

Weil sie die „Fehler“ selbst erzeugt haben, wissen sie genau, was die KI hätte tun sollen. Es ist wie ein Lehrer, der eine Matheaufgabe mit einem bekannten Fehler schreibt, sie einem Schüler gibt und dann prüft, ob der Schüler diesen spezifischen Fehler gefunden und behoben hat.

3. Die drei großen Fragen (Das „Menü“)

Die Forscher testen die KI in drei Hauptbereichen:

Frage 1: Welche „Zutaten“ sind am schwersten auszutauschen?
Einige Änderungen sind einfach, wie das Umbenennen einer Variable (aus „Mehl“ wird „Zucker“). Andere sind schwierig, wie das Ändern der gesamten Kochmethode (vom Backen zum Braten wechseln). Sie wollen sehen, welche Arten von Änderungen die KI am meisten vor Probleme stellen.
Frage 2: Wird es schwieriger, wenn man mehr Dinge gleichzeitig kaputt macht?
Wenn die KI einen kaputten Teil reparieren kann, kann sie dann auch drei kaputte Teile gleichzeitig reparieren? Sie testen, ob die Schwierigkeit linear ansteigt oder ob die KI völlig verwirrt ist, wenn mehrere Dinge gleichzeitig schiefgehen.
Frage 3: Wie viel „Kontext“ benötigt die KI?
Stellen Sie sich vor, Sie reparieren ein Rezept.
- Szenario A: Sie sehen nur die Rezeptkarte.
- Szenario B: Sie sehen die Rezeptkarte und die Liste der Zutaten in Ihrem Vorratsschrank.
- Szenario C: Sie sehen die Rezeptkarte, den Vorratsschrank und das gesamte Layout der Küche.
  Die Forscher wollen wissen: Muss die KI die ganze „Küche“ (den umgebenden Code) sehen, um einen guten Job zu machen, oder reicht die Rezeptkarte aus?

4. Die Regeln des Spiels

Die Sprache: Sie testen dies mit Java, einer sehr verbreiteten Programmiersprache.
Die „Keine Hilfe“-Regel: Der KI ist es nicht erlaubt, gesagt zu bekommen, was sie ändern soll. Sie erhält nur einen generischen Prompt: „Passe dieses Snippet an den Kontext an.“
Das Sicherheitsnetz: Sie verwenden echte Open-Source-Projekte mit starken „Test Suites“. Betrachten Sie diese Tests als Sicherheitsinspektor. Wenn die KI den Code ändert und der Sicherheitsinspektor sagt: „Das funktioniert immer noch perfekt“, hat die KI bestanden.

5. Warum das wichtig ist

Momentan wissen wir nicht wirklich, wie gut die KI in dieser speziellen „Kopieren-Einfügen-und-Fixen“-Fähigkeit ist. Bestehende Tests sind entweder zu einfach, zu vage oder betrachten nur ganze Funktionen (wie eine ganze Mahlzeit) statt kleiner Fragmente (wie eine einzelne Zutat).

Diese Studie zielt darauf ab, einen massiven, fairen Spielplatz zu bauen, auf dem sie genau messen können, wo die KI bei der Anpassung von Code Erfolg hat und wo sie scheitert. Wenn sie herausfinden, dass die KI schlecht im „Werkzeuge tauschen“, aber gut im „Zutaten umbenennen“ ist, können zukünftige Werkzeuge entwickelt werden, um Entwickler gezielt bei den schwierigen Teilen zu unterstützen.

Kurz gesagt: Die Autoren bauen einen kontrollierten „Hindernisparcours“ für die KI, um zu sehen, wie gut sie kaputten Code aus eigener Kraft reparieren kann, ohne einen Spickzettel zu erhalten.

Technisches Resümee: Evaluierung von LLMs bei der Anpassung von Java-Code-Snippets mittels eines Mutation-Injection-Frameworks

Problemstellung

Entwickler nutzen Code häufig wieder, indem sie Fragmente aus bestehenden Repositories oder Online-Quellen kopieren und diese an neue Kontexte anpassen. Dieser Anpassungsprozess umfasst vielfältige Änderungen wie das Umbenennen von Variablen, das Austauschen von APIs, das Hinzufügen von Fehlerbehandlung und das Modifizieren des Kontrollflusses. In realen Szenarien geben Entwickler keine expliziten Schritt-für-Schritt-Anweisungen für die Bearbeitung vor; sie erwarten, dass Werkzeuge die notwendigen Änderungen basierend auf dem kopierten Fragment und dessen Surrounding-Kontext autonom erschließen.

Aktuelle Benchmarks zur Evaluierung von Large Language Models (LLMs) bei der Code-Anpassung leiden unter drei primären Einschränkungen:

Abhängigkeit von expliziten Anweisungen: Viele bestehende Evaluierungen stellen explizite Bearbeitungsanleitungen bereit, wodurch die Fähigkeit der Modelle getestet wird, Änderungen autonom zu inferieren, nicht jedoch die Fähigkeit, ohne Anleitung zu agieren.
Enger Fokus: Benchmarks decken oft nur spezifische Änderungstypen ab (z. B. Variablen-Verkabelung) oder operieren ausschließlich auf der Funktionsebene, wobei sie die feinere Granularität von Code-Fragmenten (z. B. Schleifenkörper, bedingte Verzweigungen) ignorieren, an denen Copy-Paste-Operationen typischerweise stattfinden.
Mangel an kontrollierter Grundwahrheit (Ground Truth): Aufgaben, die aus realen Commits abgeleitet werden, vermischen oft mehrere Änderungstypen, was es schwierig macht, zu isolieren, welche spezifischen Anpassungsarten zu Modellfehlern führen.

Folglich bleibt ungeklärt, wie gut LLMs in der instruktionsfreien Anpassung von Code-Fragmenten performen, wenn die erforderlichen Änderungen variiert, kontrolliert und in unterschiedlicher Komplexität und Kontextualisierung präsentiert werden.

Methodik

Die Autoren schlagen ein Mutation-Injection-Framework vor, um einen kontrollierten, skalierbaren Datensatz zur Evaluierung instruktionsfreier Code-Anpassung zu erstellen. Die Methodik verläuft wie folgt:

1. Datensatzkonstruktion

Quelle: Reife Open-Source-Java-Repositories (mindestens 500 Stars, 70 % Zeilenabdeckung via JaCoCo, Maven-baubar), die über mindestens fünf verschiedene Anwendungsdomänen hinweg reichen.
Fragment-Extraktion: Unter Verwendung des Spoon-Frameworks extrahieren die Autoren syntaktisch vollständige, zusammenhängende Code-Fragmente (3–20 Anweisungen), die durch Testfälle abgedeckt sind und mindestens zwei Nicht-Keyword-Identifikatoren enthalten.
Seed-Selektion: Die Fragmente dienen als „Ground-Truth-Seeds“, die den Zielzustand repräsentieren.

2. Mutation-Injection (Reverse Adaptation)

Anstatt die Modelle zu bitten, Code an ein Ziel anzupassen, beginnt das Framework mit dem Ziel (dem Seed) und wendet Anpassungsoperatoren in umgekehrter Reihenfolge an, um ein mutiertes Fragment ( $F'$ ) zu erzeugen.

Taxonomie: Ein kuratierter Satz von neun Mutationsoperatoren, die aus empirischen Studien zum Verhalten von Entwicklern (z. B. Zhang et al., Roy et al.) abgeleitet wurden. Diese umfassen:
- Identifier-Ebene: Umbenennung von Variablen, Aktualisierung von Konstanten, Identifikator-Auflösung.
- Statement-Ebene: Einfügen von Guards, Typänderungen, Try/Catch-Edits.
- Strukturell/Semantisch: Modifikation des Kontrollflusses, API-Substitution, Logik-Customisierung.
Validierung: Die Mutationen werden validiert, um sicherzustellen, dass der resultierende Code kompiliert und – entscheidend – mindestens einen bestehenden Testfall im Repository fehlschlagen lässt. Dies stellt sicher, dass die Mutation einen semantischen Defekt einführt, den das LLM beheben muss.
Komplexitätsstufen: Aufgaben werden basär auf der Anzahl und Kombination injizierter Mutationen in Komplexitätsstufen ( $L1$ bis $L4$ ) kategorisiert.

3. Aufgabenformulierung

Das LLM wird mit dem mutierten Fragment ( $F'$ ) konfrontiert und erhält die Anweisung, „das Snippet an den umgebenden Kontext anzupassen“. Es werden keine expliziten Edit-Listen oder Schritt-für-Schritt-Anleitungen bereitgestellt.

Kontext-Granularität: Die Studie evaluiert drei Kontextstufen:
- C1: Kein Kontext (nur das Fragment).
- C2: Methoden-Kontext (umgebender Methodenkörper).
- C3: Datei-Kontext (vollständige Quelldatei).

4. Evaluierungsmetriken

Funktionale Korrektheit: Das Output des LLM wird an der ursprünglichen Stelle im Codebase wieder eingefügt, und die Testsuite des Repositories wird ausgeführt. Der Erfolg wird via pass@1 und pass@5 (wobei jeder von 5 generierten Outputs erfolgreich ist) gemessen.
Anpassungs-Ebene Korrektheit: Eine feingliedrige Inspektion prüft, ob spezifische injizierte Mutationen korrekt umgekehrt wurden, unter Verwendung der während der Injection aufgezeichneten JSON-Metadaten.
Statistische Analyse: Mixed-Effects Logistic Regression wird verwendet, um die Interaktionen zwischen Modell, Anpassungstyp, Kontext und Komplexität zu analysieren.

Kernbeiträge

Instruktionsfreies Evaluierungs-Paradigma: Die Studie verlagert den Fokus von expliziter Bearbeitungsanleitung auf autonome Inferenz, was reale Szenarien der Code-Wiederverwendung besser widerspiegelt.
Granularität auf Fragment-Ebene: Im Gegensatz zu Funktions-basierten Benchmarks zielt dieses Framework auf Sub-Methoden-Einheiten (Schleifen, Bedingungen) ab, was der Art und Weise entspricht, wie Entwickler Code in IDEs tatsächlich kopieren und einfügen.
Kontrollierte Ground Truth durch Mutation-Injection: Durch die Anwendung von Operatoren in umgekehrter Reihenfolge wissen die Autoren exakt, welche Änderungen erforderlich sind. Dies ermöglicht eine präzise Attribuierung von Modellfehlern auf spezifische Anpassungstypen – eine Fähigkeit, die Benchmarks fehlt, die aus komplex vermischten realen Commits aufgebaut sind.
Skalierbares, wiederverwendbares Framework: Die Taxonomie wird als programmierbare Mutationsoperatoren operationalisiert, was es zukünftigen Forschern ermöglicht, neue Werkzeuge in großem Maßstab zu evaluieren, ohne manuelle Annotationen vorzunehmen.

Forschungsfragen

Die Studie ist um drei explorative Fragen strukturiert:

RQ1 (Schwierigkeit des Anpassungstyps): Welche Kategorien der Anpassung sind für LLMs ohne explizite Instruktionen am schwierigsten durchzuführen?
RQ2 (Anpassungskomplexität): Wie skaliert die Performance mit der Anzahl und Kombination injizierter Änderungen? Erzeugt die Kombination einfacher Änderungen eine emergente Schwierigkeit?
RQ3 (Kontext-Granularität): Wie viel umgebender Kontext ist für eine erfolgreiche Anpassung erforderlich, und variiert dieser Bedarf je nach Anpassungstyp?

Signifikanz und Ansprüche

Das Paper positioniert sich als ein Registered Report, wobei der Schwerpunkt auf der Rigorosität des experimentellen Designs und der vorregistrierten Natur des Analyseplans liegt.

Schließung der Lücke: Die Autoren behaupten, dass bestehende Benchmarks nicht gleichzeitig instruktionsfreie Aufgaben, Granularität auf Fragment-Ebene, kontrollierte Änderungstypen und Skalierbarkeit bieten können. Ihr Framework ist darauf ausgelegt, diese kombinierte Lücke zu schließen.
Praktische Auswirkungen: Die Ergebnisse sollen die Entwicklung zukünftiger Code-Reuse-Tools und IDE-Plugins leiten, indem sie identifizieren, bei welchen Anpassungstypen aktuelle LLMs Schwierigkeiten haben und welche optimalen Kontextfenster für verschiedene Änderungstypen benötigt werden.
Reproduzierbarkeit: Die Autoren verpflichten sich, den vollständigen Datensatz, das Mutations-Framework und die Evaluierungs-Skripte öffentlich zugänglich zu machen, um Replikation und Erweiterung zu unterstützen.

Das Paper behauptet nicht, das Problem der Code-Anpassung gelöst zu haben, sondern schlägt eine systematische Methode vor, um den aktuellen Stand von LLMs in diesem Bereich zu messen, und bietet damit eine Baseline für zukünftige Verbesserungen. Es räumt Einschränkungen ein, wie die Beschränkung auf Java/Maven und die potenzielle Divergenz zwischen synthetischen Mutationen und natürlichen Entwickler-Anpassungen, und merkt an, dass das Framework darauf ausgelegt ist, in zukünftiger Arbeit auf andere Sprachen und Build-Systeme erweiterbar zu sein.