A framework for assessing the capabilities of code generation of constraint domain-specific languages with large language models

Die vorgestellte Arbeit stellt ein generisches Framework zur Bewertung der Fähigkeit von Large Language Models vor, Code für domänenspezifische Sprachen wie OCL und Alloy zu generieren, und zeigt, dass diese Modelle bei solchen Sprachen im Vergleich zu Python schwächere Leistungen erbringen, wobei Strategien wie Code-Reparatur und Mehrfachversuche die Qualität jedoch signifikant verbessern können.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen extrem talentierten, aber etwas eigensinnigen Koch namens KI. Dieser Koch kann fantastische Gerichte (Code) kochen, wenn Sie ihm sagen: „Mach mir eine Pizza" oder „Bake einen Kuchen". Er kennt die Rezepte für Pizza (Python) und Kuchen (Java) auswendig, weil er in seiner Ausbildung Millionen von Kochbüchern gelesen hat.

Aber was passiert, wenn Sie ihn bitten, ein sehr spezielles, seltenes Gericht zuzubereiten, das nur in einer kleinen Region bekannt ist? Zum Beispiel ein Gericht namens „OCL" oder „Alloy"? Diese sind wie Spezialgerichte für Software-Ingenieure (Constraint-Sprachen). Der Koch hat davon kaum je gehört. Wenn Sie ihn bitten, dieses Gericht zu kochen, wird er wahrscheinlich raten, Zutaten erfinden oder das Gericht einfach nicht fertig bekommen.

Dieses Papier ist im Grunde eine große Testküche, in der die Autoren herausfinden wollen:

1. Wie gut kann dieser KI-Koch diese speziellen Gerichte kochen?
2. Welche Tricks helfen ihm dabei, besser zu werden?
3. Wie können wir sicherstellen, dass das Essen nicht nur gut aussieht, sondern auch schmeckt (korrekt ist)?

Hier ist die Erklärung der wichtigsten Punkte, einfach und mit Analogien:

1. Das Problem: Der Koch kennt die Spezialgerichte nicht

Der KI-Koch (Large Language Model) ist super in allgemeinen Sprachen wie Python. Aber bei den speziellen Sprachen (DSLs) für Regeln und Einschränkungen (Constraints) stolpert er oft.

• Warum? Weil es im Internet kaum Kochbücher für diese speziellen Gerichte gibt. Der Koch hat wenig Übung.
• Das Ergebnis: Er vermischt Zutaten (Syntax-Fehler) oder das Gericht ist ungenießbar (falsche Logik).

2. Der neue Werkzeugkasten: Das Bewertungs-Framework

Die Autoren haben einen modularen Werkzeugkasten gebaut. Stellen Sie sich das wie eine Koch-Show-Jury vor, die nicht nur schmeckt, sondern den gesamten Prozess analysiert.

• Der Input: Sie geben dem Koch eine Beschreibung des Gerichts (Text) und eine Liste der erlaubten Zutaten (das Datenmodell).
• Der Prozess: Der Koch versucht, das Gericht zu kochen.
• Die Prüfung (Well-formedness): Zuerst schaut ein Assistent: „Ist das überhaupt ein essbares Gericht? Oder ist es nur ein Haufen roher Eier?" (Ist der Code syntaktisch korrekt?).
• Die Prüfung (Correctness): Wenn es essbar aussieht, schmeckt es dann so, wie bestellt? (Ist die Logik richtig?).

3. Die Experimente: Was funktioniert?

Die Autoren haben den Koch mit verschiedenen Tricks getestet, um zu sehen, was ihn am besten unterstützt:

• Die Sprache zählt am meisten:

  • Wenn Sie Python (Pizza) bestellen, ist der Koch fast immer perfekt.
  • Bei OCL und Alloy (den Spezialgerichten) scheitert er oft schon beim Anrichten.
  • Die Erkenntnis: Der Koch muss die Sprache kennen. Ein teurer, smarter Koch (wie GPT-4o) ist viel besser als ein günstigerer, kleinerer Koch (Open-Source-Modelle), der bei diesen Spezialgerichten oft gar nicht erst anfängt, weil ihm der Platz in seiner Küche (der „Context Window") fehlt.

• Der Zettel mit den Anweisungen (Prompting):

  • Man könnte denken: „Wenn ich dem Koch einen noch detaillierteren Zettel mit Rezept schreibe, wird er besser."
  • Die Überraschung: Das hilft bei diesen Spezialgerichten kaum. Ob der Zettel kurz oder lang ist, macht wenig Unterschied. Der Koch braucht einfach mehr Erfahrung mit dem Gericht selbst, nicht mehr Anweisungen.

• Mehrfache Versuche (Multiple Attempts):

  • Wenn der Koch das erste Mal scheitert, sagen Sie: „Versuch's noch einmal!"
  • Ergebnis: Das hilft enorm! Wenn Sie den Koch 3-mal versuchen lassen, ist die Chance viel höher, dass er es endlich richtig macht. Es ist wie beim Würfeln: Je öfter Sie würfeln, desto wahrscheinlicher ist eine 6.

• Reparatur (Code Repair):

  • Wenn das Gericht etwas verbrannt ist, sagen Sie: „Mach das hier noch einmal, aber weniger heiß."
  • Ergebnis: Auch das hilft! Wenn Sie dem Koch den Fehler zeigen und ihn bitten, es zu korrigieren, wird das Ergebnis besser.
  • Der beste Trick: Kombinieren Sie beides! Lassen Sie ihn dreimal versuchen und korrigieren Sie die Fehler. Das kostet zwar mehr Zeit (und Geld), liefert aber das beste Essen.

4. Die großen Lehren (Takeaways) für den Alltag

Die Autoren geben uns drei einfache Regeln mit, wie man mit diesem KI-Koch umgehen sollte, wenn es um schwierige Spezialgerichte geht:

1. Wählen Sie den richtigen Koch: Wenn Sie ein sehr spezielles Gericht (eine seltene Programmiersprache) brauchen, nehmen Sie den teuersten, erfahrensten Koch (GPT-4), nicht den billigen. Der kleine Koch versteht die Sprache einfach nicht.
2. Schreiben Sie keine Romane: Es bringt wenig, den Koch mit extrem langen, komplizierten Anweisungen zu überfluten. Ein kurzer, klarer Auftrag reicht oft, solange der Koch die Sprache kennt.
3. Geben Sie ihm Zeit und Chancen: Lassen Sie ihn nicht nur einmal versuchen. Lassen Sie ihn mehrmals kochen und korrigieren Sie die Fehler. Das ist der sicherste Weg zu einem guten Ergebnis.

Fazit

Dieses Papier sagt uns: KI ist toll, aber sie ist kein Zauberstab für alles. Bei speziellen Sprachen braucht sie mehr Hilfe, mehr Versuche und den richtigen „Koch". Mit dem richtigen Werkzeugkasten (dem Framework der Autoren) können wir herausfinden, wie wir den Koch am besten anleiten, damit er nicht nur „irgendwas" produziert, sondern wirklich funktionierenden Code.

Es ist wie beim Lernen einer neuen Sprache: Man wird nicht perfekt, indem man nur einmal eine Grammatikregel liest, sondern indem man viel übt, Fehler macht, sie korrigiert und immer wieder versucht.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers auf Deutsch:

Titel: Ein Framework zur Bewertung der Fähigkeiten von Large Language Models (LLMs) bei der Code-Generierung für constraint-basierte domänenspezifische Sprachen (DSLs)

Autoren: David Delgado, Lola Burgueño, Robert Clarisó
Institutionen: Universitat Oberta de Catalunya, ITIS Software / Universidad de Málaga

---

1. Problemstellung

Large Language Models (LLMs) haben die Softwareentwicklung revolutioniert, insbesondere durch Code-Vervollständigung und Generierung aus Textanforderungen. Während sie bei allgemeinen Programmiersprachen (GPLs) wie Python, Java oder C# hohe Leistungen zeigen, leiden sie signifikant bei domänenspezifischen Sprachen (DSLs), insbesondere bei formalen Constraint-Sprachen wie OCL (Object Constraint Language) und Alloy.

Die Hauptprobleme sind:

• Ressourcenknappheit: Im Vergleich zu GPLs gibt es nur wenige Trainingsdaten für DSLs, was zu ungenauen Syntax- und Semantikkenntnissen der Modelle führt.
• Komplexität der Constraints: Constraint-Sprachen erfordern das gleichzeitige Management des Domänenmodells (Schema) und der darauf aufbauenden Constraints.
• Declarative Natur: Im Gegensatz zu prozeduralen Sprachen sind Constraints oft global und nicht direkt ausführbar, was die Validierung erschwert.
• Fehlende Evaluierungsstandards: Es gibt kaum Benchmarks oder automatisierte Tools, um die Qualität von generiertem DSL-Code systematisch zu bewerten.

2. Methodik: Das Evaluierungs-Framework

Die Autoren stellen ein modulares, hochkonfigurierbares Framework vor, um die Code-Generierung von LLMs systematisch zu bewerten. Das Framework besteht aus vier Hauptphasen (siehe Abbildung 1 im Paper):

1. Prompt-Erstellung (Building Prompts):

   • Das Framework nutzt verschiedene Prompt-Templates, die Kontext (Domänenbeschreibung, Domänenmodell) und Aufgabenstellung kombinieren.
   • Es unterstützt verschiedene Strategien: Chain of Thought (CoT), Few-Shot Prompting und verschiedene Liefermethoden für Aufgaben (Batch vs. isoliert).
   • Es kann das Domänenmodell vom LLM erklären lassen oder generieren lassen, um den Kontext zu erweitern.

2. Code-Generierung und Extraktion:

   • Der ausgewählte LLM generiert Code basierend auf den Prompts.
   • Es werden multiple Versuche (Attempts) unterstützt, um die Wahrscheinlichkeit eines korrekten Ergebnisses zu erhöhen.
   • Der generierte Code wird extrahiert und für die Validierung aufbereitet.

3. Well-Formedness-Prüfung (Syntax & Semantik):

   • Automatisch: Einsatz von Parsern (z. B. ANTLR) und Compilern, um syntaktische Korrektheit zu prüfen.
   • Manuell/Tool-basiert: Ausführung in spezifischen Umgebungen (USE für OCL, Alloy Analyzer, Python-Interpreter), um semantische Fehler zu erkennen.
   • Code-Repair: Bei Fehlern wird ein einzelner Reparaturversuch (Single-Pass) initiiert, bei dem der LLM den Fehler erklärt und den Code korrigiert.

4. Korrektheits-Prüfung (Correctness):

   • Bewertung, ob der Code die funktionalen Anforderungen erfüllt.
   • LLM-as-a-Judge: Ein LLM (hier GPT-4o-mini) bewertet die Korrektheit basierend auf der Spezifikation und dem Domänenkontext.
   • Manuelle Validierung: Als Ground Truth für die Evaluierung der automatischen Methoden.
   • Metriken: Accuracy (Korrektheit beim ersten Versuch) und pass@k (Wahrscheinlichkeit, dass mindestens einer von $k$ Versuchen korrekt ist).

3. Schlüsselergebnisse (Ergebnisse)

Die Autoren führten Experimente mit ca. 98.400 Code-Generierungsaufgaben durch, basierend auf drei Sprachen (OCL, Alloy, Python) und vier LLMs (DeepSeek Coder, GPT-4o, GPT-4o-mini, Llama 3.1).

• Einfluss der Zielsprache:

  • Python zeigt die beste Leistung (nahezu 100% syntaktisch korrekt, bis zu 80% korrekt).
  • OCL und Alloy schneiden deutlich schlechter ab. Viele generierte Constraints sind syntaktisch ungültig oder semantisch fehlerhaft.
  • Ursache: Mangel an Trainingsdaten und spezifische Operatoren (z. B. Mengenoperationen in Alloy), die LLMs schwer verstehen.

• Einfluss des LLM-Modells:

  • GPT-4o ist das leistungsfähigste Modell für alle Sprachen.
  • GPT-4o-mini folgt dicht, zeigt aber bei OCL Schwächen (vermutlich fehlende Trainingsdaten für OCL).
  • Open-Source-Modelle (DeepSeek, Llama 3.1) scheitern oft bereits an der Syntax (Well-Formedness), insbesondere bei kleinen Kontextfenstern, die das gesamte Domänenmodell nicht fassen können. Sie sind für Constraint-DSLs in der Praxis oft unbrauchbar.

• Einfluss von Prompting-Techniken:

  • Die Wahl des Prompt-Templates hat keinen signifikanten Einfluss auf die Korrektheit (außer bei spezifischen Kombinationen wie OCL + GPT-4o-mini).
  • Da keine Template-Klasse eindeutig überlegen ist, empfiehlt sich das einfachste Template (PT1), um Token-Kosten zu sparen.

• Strategien zur Qualitätsverbesserung:

  • Multiple Attempts (pass@k): Mehrere Versuche erhöhen die Erfolgschance linear, aber mit abnehmendem Grenznutzen.
  • Code Repair: Ein Reparaturversuch erhöht die Korrektheit um 10–20%.
  • Kombination: Die beste Strategie ist die Kombination aus mehreren Versuchen und Code-Repair, obwohl dies die Kosten (API-Calls) maximiert.
  • Task-Delivery: Die Batch-Verarbeitung (alle Constraints in einem Prompt) ist der isolierten Verarbeitung vorzuziehen, um Inkonsistenzen im Domänenmodell zu vermeiden.

4. Wichtige Beiträge

1. Modulares Evaluierungs-Framework: Ein anpassbares System, das Prompt-Strategien, LLM-Auswahl, Reparaturmechanismen und Validierungstools parametrisiert, um systematisch Code-Generierungs-Szenarien zu vergleichen.
2. Umfassende Studie zu Constraint-Sprachen: Der erste Vergleich von OCL und Alloy mit Python unter Verwendung von synthetisch angereicherten Datensätzen (mit Domänenbeschreibungen).
3. Empirische Evidenz: Analyse von über 90.000 Experimenten, die zeigen, dass die Wahl des Modells und der Sprache wichtiger ist als das Prompt-Engineering, und dass Reparatur/Retry-Strategien essenziell für DSLs sind.
4. Reproduzierbarkeit: Bereitstellung aller Artefakte, Datensätze und des Frameworks als Open-Source-Repository.

5. Signifikanz und Implikationen

Das Paper zeigt, dass die direkte Anwendung von LLMs auf Constraint-DSLs ohne Anpassung oft zu unbrauchbarem Code führt. Die Ergebnisse liefern praktische Leitlinien für Entwickler:

• Modellauswahl: Für DSLs muss ein Modell gewählt werden, das spezifisch für die Sprache trainiert wurde (z. B. GPT-4o für OCL/Alloy).
• Ressourcenmanagement: Bei begrenzten Ressourcen sollte man auf komplexe Prompt-Engineering-Techniken verzichten und stattdessen auf Multiple Attempts und Code Repair setzen.
• Kontext-Management: Constraints desselben Domänenmodells sollten gemeinsam generiert werden, um Modellinkonsistenzen zu vermeiden.

Das Framework bietet eine solide Basis für zukünftige Forschung, z. B. zur Integration von Retrieval-Augmented Generation (RAG) oder zur Feinabstimmung (Fine-Tuning) von Modellen speziell für Constraint-Sprachen.