Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

Diese Arbeit stellt einen Rahmen vor, der Tests und statische Analyse nutzt, um die Qualität von Code zu bewerten und generative Open-Source-LLMs durch Feedback zu deren Fehlerbehebung zu verbessern, wobei festgestellt wird, dass diese Modelle zwar häufig fehlerhaften Code produzieren und Schwierigkeiten bei der Fehlererkennung haben, jedoch erhebliche Fähigkeiten zur Korrektur aufweisen, wenn sie mit entsprechenden Analysedaten versorgt werden.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen sehr talentierten, aber noch etwas unerfahrenen Koch-Assistenten (das ist die Künstliche Intelligenz oder LLM). Dieser Assistent kann fantastisch kochen, wenn Sie ihm eine Rezeptur geben. Aber manchmal vergisst er, dass er Salz statt Zucker nehmen soll, oder er benutzt ein Messer, das nicht ganz scharf ist, und schneidet sich dabei.

In diesem Papier untersuchen vier Forscher, wie gut dieser Koch-Assistent tatsächlich ist, wenn es darum geht, Code (die "Rezepte" für Computerprogramme) zu schreiben, und wie man ihm beibringt, seine Fehler zu erkennen und zu korrigieren.

Hier ist die Geschichte der Studie, einfach erklärt:

1. Das Problem: Der Assistent ist kreativ, aber nicht perfekt

Die Forscher haben vier verschiedene KI-Modelle (wie Llama, Gemma und Mixtral) gebeten, kleine C-Programme zu schreiben.

• Das Ergebnis: Der Assistent war oft kreativ, aber leider auch oft falsch. Etwa die Hälfte der Programme funktionierte gar nicht richtig (sie "stürzten ab" oder taten das Falsche).
• Die Gefahr: Noch schlimmer war, dass viele Programme unsicher waren. Das ist, als würde der Koch ein Messer mit einer scharfen Klinge auf den Tisch legen, ohne es zu sichern. Ein kleiner Fehler könnte später dazu führen, dass jemand (oder ein Hacker) in das Haus eindringen kann.

2. Der Test: Ein strenger Inspektor und ein Sicherheitsbeauftragter

Um herauszufinden, wie schlecht oder gut der Assistent ist, haben die Forscher zwei Werkzeuge eingesetzt:

• Der Test-Manager (Unit Tests): Dieser prüft, ob das Gericht schmeckt, wie bestellt. "Hast du wirklich die Suppe gekocht oder einen Kuchen?"
• Der Sicherheitsinspektor (Infer): Das ist ein spezielles Werkzeug, das nach versteckten Gefahren sucht. "Ist der Herd aus? Ist das Messer weggeräumt?"

Die überraschende Erkenntnis: Der Assistent war sehr schlecht darin, selbst zu merken, dass er Fehler gemacht hat. Wenn man ihn fragte: "Ist dein Gericht sicher?", sagte er oft "Ja", obwohl es voller Löcher war. Er hatte also kein gutes "Bauchgefühl" für seine eigenen Fehler.

3. Die Lösung: Der Feedback-Zyklus (Lernen durch Kritik)

Da der Assistent seine Fehler nicht selbst sah, gaben die Forscher ihm eine Checkliste mit den Fehlern, die der Sicherheitsinspektor gefunden hatte.

• Die Aufgabe: "Hier ist dein Programm. Hier ist die Liste der Fehler (z. B. 'Du hast ein Messer liegen lassen'). Bitte korrigiere es."
• Das Ergebnis: Das war der große Durchbruch! Wenn der Assistent genau wusste, wo der Fehler lag, konnte er ihn fast immer beheben.
  • Bei Sicherheitslücken (wie dem vergessenen Messer) gelang es ihm in 89 % der Fälle, das Problem zu lösen.
  • Bei logischen Fehlern (falsches Rezept) schaffte er es in 62 % der Fälle.

4. Die Lektion: Wir müssen ihm die Brille aufsetzen

Die wichtigste Botschaft der Studie ist: KI kann Code schreiben, aber sie kann ihn noch nicht zuverlässig auf Sicherheit prüfen.

Stellen Sie sich vor, Sie bauen ein Haus. Der KI-Assistent ist der Baumeister, der die Wände hochzieht. Aber er vergisst oft, ob die Fenster sicher sind oder ob die Elektrik brennt.

• Früher: Man vertraute blind auf den Baumeister.
• Jetzt: Die Forscher sagen: "Wir brauchen einen automatischen Bauprüfer (den Sicherheitsinspektor), der sofort schreit: 'Achtung, hier fehlt ein Balken!' und dem Baumeister sagt: 'Mach das hier nochmal richtig'."

Fazit für den Alltag

Diese Forschung zeigt uns einen Weg, wie wir KI sicherer im Alltag nutzen können:

1. Vertraue nicht blind: KI-Code ist oft gut, aber nicht immer sicher.
2. Nutze Werkzeuge: Wir müssen automatische Prüfsysteme (wie den "Sicherheitsinspektor") nutzen, die den Code scannen.
3. Gib Feedback: Wenn die KI einen Fehler macht, gib ihr die genaue Information darüber zurück. Dann lernt sie sofort und korrigiert den Fehler.

Es ist wie beim Lernen eines neuen Sports: Der Trainer (die KI) kann den Ball werfen, aber er braucht einen Videotrainer (den Analytiker), der ihm zeigt: "Nein, dein Arm war zu weit unten." Sobald er das sieht, kann er den Wurf sofort verbessern.

Zusammengefasst: KI ist ein mächtiger Werkzeugkasten, aber wir müssen sie mit einem strengen Sicherheitsnetz ausstatten, damit sie nicht nur schnell, sondern auch sicher arbeitet.

Technische Zusammenfassung

1. Problemstellung

Große Sprachmodelle (LLMs) werden zunehmend zur Code-Generierung eingesetzt, was die Produktivität steigert, aber erhebliche Risiken hinsichtlich Korrektheit, Sicherheit und Vertrauenswürdigkeit mit sich bringt. Bisherige Studien zeigen, dass von kommerziellen LLMs generierter Code oft Sicherheitslücken, Bugs und „Code Smells" enthält. Ein zentrales Problem ist, dass LLMs oft nicht in der Lage sind, ihre eigenen Fehler zu erkennen oder zu beheben, und dass bestehende Werkzeuge zur Fehlerbehebung oft manuelle Eingriffe erfordern.

Das Paper adressiert die Frage, wie man die Qualität und Sicherheit von Code, der von Open-Source-LLMs generiert wird, systematisch bewerten und durch automatisiertes Feedback verbessern kann.

2. Methodik

Die Autoren entwickelten ein dreistufiges Framework, das Code-Generierung, Selbstbewertung und Reparatur kombiniert. Das Experiment basierte auf vier aktuellen Open-Source-Modellen: Llama 3 (8B und 70B), Gemma 7B und Mixtral 8x7B.

A. Datengrundlage und Setup

• Benchmark: Es wurden 100 Aufgaben aus dem Mostly Basic Python Problems (MBPP)-Dataset entnommen und manuell in die Programmiersprache C übersetzt. Dies geschah, um das Risiko zu minimieren, dass Modelle die Aufgaben aus dem Training „auswendig gelernt" haben (Memorization).
• Kompilierung: Der generierte Code wurde mit dem Clang-Compiler (v15.0.0) verarbeitet.
• Bereinigung: Ein automatisiertes Skript entfernte nicht-code-Texte (z. B. Erklärungen), fügte fehlende Standardbibliotheken hinzu und bereinigte Formatierungsfehler.

B. Die drei Phasen des Experiments

1. Code-Generierung:

   • Die Modelle generierten Code basierend auf natürlichen Sprachbeschreibungen.
   • Korrektheitsprüfung: Der Code wurde gegen Ground-Truth-Unit-Tests (angepasst von MBPP) ausgeführt. Ergebnisse wurden in vier Kategorien unterteilt: Alle Tests bestanden, Tests fehlgeschlagen, Ausführungsfehler (z. B. Segfault, Timeout) oder Kompilierungsfehler.
   • Sicherheitsprüfung: Der kompilierbare Code wurde mit Infer (ein statischer Analyser von Meta) analysiert, um Sicherheitslücken wie Pufferüberläufe, Speicherlecks, Nullzeiger-Dereferenzierung und nicht initialisierte Werte zu erkennen.

2. Selbstbewertung (Self-Evaluation):

   • Die Modelle wurden aufgefordert, die Korrektheit und Sicherheit des Codes zu bewerten, der von sich selbst und den anderen drei Modellen generiert wurde.
   • Dies diente dazu, die Fähigkeit der Modelle zur Fehlererkennung und ein mögliches „Selbstpräferenz"-Verhalten (ob Modelle ihren eigenen Code besser bewerten) zu testen.

3. Reparatur (Repair):

   • Den Modellen wurden fehlerhafter Code sowie die spezifischen Fehlerberichte (aus den Unit-Tests oder Infer-Analysen) als Feedback gegeben.
   • Die Modelle sollten den Code iterativ reparieren (bis zu 6 Iterationen pro Aufgabe).
   • Es wurde untersucht, ob Modelle Code, der von ihnen selbst oder anderen generiert wurde, besser reparieren können.

C. Prompt-Engineering

Für jede Phase wurden verschiedene Prompt-Strategien getestet (Vanilla, Few-Shot mit Beispielen, Chain-of-Thought, Kombinationen). Die besten Ergebnisse wurden mit spezifischen Prompts erzielt, die klare Formatvorgaben und schrittweise Denkprozesse (Chain-of-Thought) oder direkte Anweisungen zur Fehlerbehebung enthielten.

3. Wichtige Beiträge

• Umfassende Evaluation: Eine systematische Analyse von Korrektheit und Sicherheit in Open-Source-LLMs für C-Code, die über reine Generationsmetriken hinausgeht.
• Feedback-Schleife: Demonstration, dass die Kombination aus Testergebnissen und statischer Analyse als Feedback genutzt werden kann, um die Codequalität signifikant zu verbessern.
• Selbstbewusstsein-Test: Untersuchung, ob LLMs ihre eigenen Fehler erkennen können (Ergebnis: Nein, sie tun dies sehr schlecht).
• Reparaturfähigkeit: Nachweis, dass LLMs bei Vorliegen von detaillierten Fehlerberichten (Tests oder Infer-Reports) in der Lage sind, einen Großteil der Fehler zu beheben.
• Open-Source-Infrastruktur: Bereitstellung eines vollständig automatisierten Pipelines, der leicht um andere Modelle oder Analyser erweitert werden kann.

4. Ergebnisse

Code-Generierung und Qualität

• Korrektheit: Nur 46% bis 65% des generierten Codes waren korrekt (alle Tests bestanden). Llama 3 70B schnitt am besten ab (65%), Gemma 7B am schlechtesten (46%).
• Sicherheit: Laut Infer-Analyse enthielt 87% bis 96% des Codes keine Sicherheitslücken. Allerdings ist zu beachten, dass statische Analyser False Positives/Negatives haben können. Mixtral generierte die meisten Sicherheitsprobleme.
• Fazit: Generierter Code ist häufiger funktional inkorrekt als unsicher.

Selbstbewertung

• Die Modelle zeigten eine sehr geringe Fähigkeit, Fehler in Code zu erkennen.
• Die Genauigkeit bei der Erkennung von Korrektheitsfehlern lag oft unter 60%, und die F1-Scores waren durchweg niedrig (< 0,8).
• Bei der Sicherheitsbewertung waren die Modelle noch schlechter: Viele Modelle antworteten fast immer mit „Nein" (kein Fehler), was zu einer hohen Gesamtgenauigkeit führte, aber eine Recall-Rate von nahe 0% bei der tatsächlichen Erkennung von Lücken bedeutete.
• Es gab keine Evidenz für eine „Selbstpräferenz" (dass Modelle ihren eigenen Code besser bewerten oder reparieren als den anderer).

Reparatur (Repair)

• Korrektheits-Reparatur: Das beste Modell (Llama 3 70B) konnte 62% der fehlerhaften Dateien (96 von 155) vollständig reparieren.
• Sicherheits-Reparatur: Die Modelle zeigten hier eine deutlich höhere Erfolgsrate. Das beste Modell reparierte 89% der identifizierten Sicherheitslücken (39 von 44).
• Interessanter Befund: Modelle reparierten Code, der von Gemma generiert wurde, oft besser als ihren eigenen Code. Es gab keine Tendenz, dass Modelle ihren eigenen Code schlechter reparieren.
• Iterativer Ansatz: Die schrittweise Reparatur basierend auf einzelnen Fehlerberichten (One-Assert-at-a-Time) erwies sich als effektiver als das gleichzeitige Beheben aller Fehler.

5. Bedeutung und Ausblick

Das Paper zeigt, dass LLMs zwar noch nicht zuverlässig fehlerfreien und sicheren Code autonom generieren können, sie aber ausgezeichnete Reparaturfähigkeiten besitzen, wenn sie mit präzisen Feedback-Mechanismen (Tests und statische Analyse) versorgt werden.

• Praktische Implikation: Ein vollständig automatisiertes Pipeline, das Code generiert, analysiert und basierend auf den Ergebnissen repariert, ist ein vielversprechender Ansatz für die Entwicklung sicherer Software.
• Rolle des Prompt-Engineering: Die Art der Prompt-Struktur (z. B. Chain-of-Thought vs. direkte Anweisungen) hat einen signifikanten Einfluss auf die Ergebnisse.
• Zukunft: Die Autoren planen, das Framework auf andere Sprachen (z. B. Rust, Python) zu erweitern und hybride Ansätze zu testen, die statische und dynamische Analysen kombinieren, um die Genauigkeit der Feedback-Schleife weiter zu erhöhen.

Zusammenfassend liefert das Paper einen wichtigen Baustein für die Entwicklung von selbstkorrigierenden Software-Entwicklungswerkzeugen, die LLMs nicht nur als Code-Generatoren, sondern als Teil eines geschlossenen Regelkreises zur Qualitätssicherung nutzen.