Code Roulette: How Prompt Variability Affects LLM Code Generation

Die Autoren stellen eine agnostische Evaluierungspipeline vor, um die Sensitivität von Large Language Models gegenüber Prompt-Variationen bei der Code-Generierung zu quantifizieren, und untermauern deren Nutzen durch umfangreiche Experimente.

Das Wesentliche

Code Roulette: Warum ein kleiner Tippfehler beim Programmieren mit KI alles verändern kann

Stellen Sie sich vor, Sie haben einen sehr talentierten, aber etwas nervösen Koch (die KI), der Ihnen ein Gericht kochen soll. Sie geben ihm eine Zutatliste (den „Prompt" oder die Eingabeaufforderung).

Die Forscher aus Cambridge haben sich gefragt: Wie empfindlich ist dieser Koch? Wenn Sie ihm das Rezept nur ein klein wenig anders formulieren – vielleicht ein Wort durch ein Synonym ersetzen, einen kleinen Tippfehler machen oder den Satz umstellen – ändert sich dann das Gericht komplett? Oder bleibt es im Grunde dasselbe?

Hier ist die einfache Erklärung ihrer Forschung, „Code Roulette":

1. Das Problem: Jeder spricht anders

Wenn wir Menschen mit einer KI programmieren, schreiben wir nicht alle gleich.

• Der eine sagt: „Mach eine Liste mit Zahlen."
• Der andere sagt: „Erstelle eine Sammlung von Ziffern."
• Der dritte macht einen Tippfehler: „Mach eine Lise mit Zahlen."

Die Forscher wollten herausfinden: Hört die KI auf das, was gemeint ist, oder reagiert sie panisch auf die kleinen Unterschiede in der Formulierung? Wenn die KI bei „Liste" eine Python-Liste baut, aber bei „Sammlung" eine Datenbank erstellt, obwohl Sie dasselbe meinten, ist das ein großes Problem für das Vertrauen in die Technologie.

2. Die Methode: Das „Rezept-Verderben"-Experiment

Die Forscher haben einen cleveren Test entwickelt, den sie wie ein wissenschaftliches Koch-Experiment durchführen:

• Der Basis-Test: Sie geben der KI ein perfektes Rezept und lassen sie 5-mal kochen. Das ist der „Goldstandard".
• Das Verderben: Dann nehmen sie das Rezept und fangen an, es absichtlich zu „verderben".
  • Tippfehler: Sie tauschen Buchstaben gegen benachbarte Tasten auf der Tastatur aus (z. B. „a" statt „s"). Das ist wie wenn man im Rezept versehentlich „Salz" statt „Zucker" schreibt.
  • Synonyme: Sie tauschen Wörter aus (z. B. „schnell" statt „rasch"). Das ist wie „Huhn" statt „Geflügel" zu sagen.
  • Umformulierung: Sie lassen die KI das Rezept selbst umschreiben, sodass es anders klingt, aber die gleiche Bedeutung hat.
• Der Vergleich: Sie lassen die KI mit diesen „verdorbenen" Rezepten kochen und vergleichen die Ergebnisse mit dem Original.

3. Was sie herausfanden: Die KI ist ein Lauscher, kein Philosoph

Die Ergebnisse waren aufschlussreich und ein bisschen beunruhigend:

• Tippfehler sind tödlich: Wenn man nur ein paar Buchstaben falsch tippt (wie ein echter Mensch, der schnell tippt), wird das Ergebnis der KI oft völlig anders. Die KI scheint sehr empfindlich auf kleine Fehler zu reagieren. Es ist, als würde der Koch bei einem einzigen Buchstabendreher im Rezept das ganze Gericht wegwerfen und etwas völlig Neues backen.
• Wortwahl ist weniger wichtig: Wenn man nur Synonyme benutzt (z. B. „Haus" statt „Gebäude"), ist die KI viel stabiler. Sie versteht die Absicht besser, auch wenn die Wörter anders sind.
• Das „alte" vs. „neue" Rezept:
  • Bei Aufgaben, die die KI schon auswendig gelernt hat (wie alte LeetCode-Programmieraufgaben), ist sie sehr robust. Sie erkennt das Rezept sofort, egal wie sehr man es verdreht. Das ist wie ein Koch, der das „Spaghetti Bolognese"-Rezept schon 10.000 Mal gekocht hat.
  • Bei neuen, kreativen Aufgaben, die die KI noch nie gesehen hat, wird sie sehr instabil. Schon eine kleine Änderung im Prompt führt zu völlig unterschiedlichen Ergebnissen. Hier fehlt ihr das „Verständnis" für die Absicht.

4. Warum ist das wichtig?

Stellen Sie sich vor, Sie und Ihr Kollege arbeiten an einem gemeinsamen Projekt. Sie geben der KI fast das gleiche Rezept, aber Sie machen einen kleinen Tippfehler.

• Ohne dieses Wissen: Sie wundern sich, warum die KI plötzlich eine ganz andere Software gebaut hat als Ihr Kollege. Sie denken, die KI ist unzuverlässig.
• Mit diesem Wissen: Sie verstehen, dass die KI wie ein sehr wortwörtlicher Übersetzer ist, der auf kleine Nuancen reagiert.

Die Forscher sagen: Wir müssen lernen, wie wir mit diesen KI-Köchen umgehen. Vielleicht müssen wir ihnen genauere Anweisungen geben oder ihre Ergebnisse besser prüfen, bevor wir ihnen blind vertrauen.

Fazit

Die Studie „Code Roulette" zeigt uns, dass KI beim Programmieren nicht so stabil ist wie ein menschlicher Experte. Kleine Änderungen in der Sprache können zu großen Änderungen im Code führen. Das ist wie beim Roulette: Je mehr man das Rad dreht (den Prompt verändert), desto unvorhersehbarer wird das Ergebnis.

Um KI sicherer zu machen, müssen wir verstehen, wie empfindlich sie auf unsere Worte reagiert – und vielleicht lernen, unsere „Rezepte" so zu schreiben, dass auch ein nervöser Koch sie richtig versteht.

Technische Zusammenfassung

1. Problemstellung

Die Generierung von Code durch Large Language Models (LLMs) ist ein zentrales Anwendungsfeld, das die Entwicklung beschleunigt und die Einstiegshürden senkt. Ein kritisches, jedoch oft unterschätztes Problem ist jedoch die Empfindlichkeit (Sensitivity) der generierten Code-Ausgaben gegenüber Variationen im Eingabe-Prompt.

• Hintergrund: Benutzer mit unterschiedlichem Hintergrund, Erfahrung und mentalen Modellen formulieren Anforderungen auf natürliche Weise unterschiedlich (z. B. durch Synonyme, Umformulierungen oder unbeabsichtigte Tippfehler).
• Herausforderung: Es ist unklar, wie robust LLMs gegenüber diesen textlichen Schwankungen sind, die dieselbe funktionale Anforderung beschreiben. Wenn kleine Änderungen im Prompt zu drastisch unterschiedlichen Code-Implementierungen führen, untergräbt dies die Zuverlässigkeit, Wartbarkeit und das Vertrauen in die KI-gestützte Entwicklung.
• Ziel: Quantifizierung der Sensitivität von LLMs gegenüber Prompt-Variationen, um die Stabilität der Ausgabe zu verstehen und geeignete Maßnahmen (z. B. bessere Benutzerführung oder Regularisierungstechniken) abzuleiten.

2. Methodik

Die Autoren stellen eine evaluationspipeline vor, die agnostisch gegenüber spezifischen Programmieraufgaben und LLM-Architekturen ist.

• Pipeline-Design:
  • Eingabe: Ein ursprünglicher Prompt $p$.
  • Augmentierung: Eine Funktion $F$ verändert den Prompt basierend auf einer Rate $r \in [0, 1]$.
  • Referenz: Für den unveränderten Prompt werden $n$ unabhängige Code-Samples generiert, um eine Ground-Truth-Baseline zu etablieren.
  • Variation: Der Augmentierungsparameter $r$ wird schrittweise von 0 bis 1 erhöht, um den Prompt schrittweise zu verzerren.
  • Messung: Für jede Stufe wird der Abstand zwischen den generierten Codes und der Referenz-Baseline berechnet.
• Augmentierungsmethoden:
  1. Tippfehler (Keyboard Typos): Zufälliges Ersetzen von Zeichen durch benachbarte Tasten auf der QWERTY-Tastatur (simuliert menschliche Fehler).
  2. Synonyme: Ersetzen von Wörtern durch semantisch äquivalente Synonyme (basierend auf WordNet).
  3. Paraphrasierung: Umformulierung des gesamten Prompts durch ein LLM (z. B. Gemini), um den Wortschatz zu variieren, während die Semantik erhalten bleibt.
• Metrik zur Distanzmessung:
  • Es wird TSED (Tree Similarity of Edit Distance) verwendet. Dies ist eine auf Syntaxbäumen basierende Metrik, die strukturelle Unterschiede zwischen Code-Fragmenten quantifiziert (Wertebereich 0 bis 1, wobei 1 Identität bedeutet).
  • Begründung: Herkömmliche Textmetriken wie BLEU oder BERT-Score wurden verworfen, da sie bei Code oft zu hohe Werte liefern (Ceiling-Effekt) und keine strukturellen Unterschiede erfassen, die für Wartung und Review kritisch sind. Die Autoren messen hier die Konsistenz der Ausgabe, nicht zwingend die funktionale Korrektheit.

3. Daten und Experimente

• Modelle: Vier populäre LLMs wurden getestet: GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash und Llama 3.3 70B.
• Datensätze:
  1. LeetCode (Old): Bekannte Aufgaben, die wahrscheinlich im Training der Modelle enthalten sind (Risiko von Datenkontamination).
  2. LeetCode (New): Aufgaben von März 2025, die vermutlich nicht im Training waren.
  3. Eigener Datensatz (Our Dataset): 22 offene Aufgaben (Simulationen, Algorithmen, Data Science), die nicht typischen Wettbewerbsaufgaben ähneln und gezielt von Trainingsdaten isoliert wurden.
• Setup: Temperatur auf 0 gesetzt, um Stochastik zu minimieren. Jeder Prompt wurde 5-mal wiederholt. Insgesamt ca. 3400 Datenpunkte pro Augmentierungsstufe.

4. Wichtige Ergebnisse

• Einfluss der Augmentierungsmethode:
  • Tippfehler: Führen zu einem rapiden Abfall der Code-Ähnlichkeit (TSED) bereits bei niedrigen Augmentierungsraten (0.0 bis 0.6). Ab einem TSED-Wert von ca. 0,3 stabilisiert sich der Abfall, da die Prompts unlesbar werden.
  • Synonyme & Paraphrasierung: Diese Methoden sind deutlich weniger invasiv. Die Code-Ähnlichkeit bleibt über einen weiten Bereich stabil und fällt erst langsam ab. Gemini 2.0 Flash zeigte hier die größte Robustheit.
• Einfluss des Datensatzes (Datenkontamination):
  • LeetCode (Old): Zeigte die geringste Sensitivität. Die Modelle erkennen diese Aufgaben auch bei starken Verzerrungen wieder (hohe Robustheit), was auf Datenkontamination hindeutet.
  • LeetCode (New): Mittlere Sensitivität. Die Modelle bleiben stabil, bis ca. 50 % des Prompts verändert sind.
  • Eigener Datensatz: Zeigte die höchste Sensitivität. Bereits bei 10 % Prompt-Veränderung fiel die Code-Ähnlichkeit unter 0,5. Zudem gab es selbst bei unveränderten Prompts eine hohe Varianz (nur 0,7 Ähnlichkeit), was auf mangelnde Konsistenz bei offenen, nicht-trivialen Aufgaben hinweist.
• Modellvergleich: Alle Modelle zeigten ähnliche Verhaltensmuster bezüglich der Augmentierungstypen. GPT-4o mini und Gemini 2.0 Flash waren bei unveränderten Prompts am stabilsten (hohe Deterministik bei Temp=0), während Llama 3.3 und Claude 3 Haiku eine höhere Instabilität aufwiesen.

5. Hauptbeiträge

1. Evaluationsverfahren: Entwicklung einer pipeline zur Messung der Sensitivität von LLMs bei der Code-Generierung gegenüber Prompt-Variationen.
2. Umfassende Analyse: Empirische Untersuchung mehrerer führender LLMs über verschiedene Augmentierungsmethoden und Datensätze hinweg.
3. Open Source: Bereitstellung des Codes und eines neuen Datensatzes mit offenen Programmieraufgaben für die Community.
4. Metrik-Validierung: Demonstration, dass TSED eine überlegene Metrik zur Messung von Code-Strukturvariationen im Vergleich zu allgemeinen Textmetriken (BERT, BLEU) ist.

6. Bedeutung und Implikationen

• Vertrauensbildung: Das Verständnis der Prompt-Sensitivität ist essenziell, um Vertrauen in KI-generierten Code zu schaffen. Es zeigt, dass Benutzer möglicherweise mehr Anleitung benötigen oder dass Pipelines Regularisierungstechniken (z. B. Mittelwertbildung mehrerer Outputs) integrieren müssen.
• Datenkontamination: Die Studie unterstreicht die Notwendigkeit, Benchmarks mit aktuellen, nicht im Training enthaltenen Aufgaben zu verwenden, da alte Benchmarks (wie LeetCode-Old) die Robustheit von Modellen überschätzen.
• Zukünftige Forschung: Die Autoren schlagen vor, die Methoden auf Dialog-basierte Interaktionen, mehrstufige Pipelines und die Einbeziehung von Nutzern mit unterschiedlichem Erfahrungshintergrund (zur Modellierung mentaler Modelle) auszuweiten.

Zusammenfassend liefert das Paper den Beweis, dass LLMs für Code-Generierung zwar robust gegenüber semantisch ähnlichen Umformulierungen sein können, aber extrem empfindlich auf strukturelle Textänderungen (wie Tippfehler) reagieren und dass ihre Konsistenz stark davon abhängt, ob die Aufgabe im Trainingsdatensatz enthalten war.