2025-11-17T18:07:13.560068

A Matter of Representation: Towards Graph-Based Abstract Code Generation

Iskandar, Bedri, Tsen
Most large language models (LLMs) today excel at generating raw, sequential code with minimal abstractions and custom structures. However, there has been little work on graph-based abstract code generation, where significant logic is encapsulated in predefined nodes and execution flow is determined by edges. This is relevant for visual programming languages, and in cases where raw source code is inaccessible to users and LLM training sets. In this work, we propose and evaluate JSON representations for graphs to enable high accuracy graph-based abstract code generation. We evaluate these representations on ScratchTest, a mini-benchmark based on our custom Python re-implementation of Scratch, which tests the LLM in code graph space. Our findings demonstrate that LLMs can indeed perform the aforementioned generation task in a single pass without relying on specialized or complex pipelines, given the correct graph representations. We also show that different representations induce significantly different accuracies, highlighting the instrumental role of representations in this generation task. All in all, this work establishes the first steps towards representation learning for graph-based abstract code generation.
academic

Eine Frage der Repräsentation: Hin zur graphenbasierten abstrakten Codegenerierung

Grundinformationen

  • Paper-ID: 2510.13163
  • Titel: A Matter of Representation: Towards Graph-Based Abstract Code Generation
  • Autoren: Nyx Iskandar (UC Berkeley), Hisham Bedri (Ramen VR), Andy Tsen (Ramen VR)
  • Klassifizierung: cs.CL (Computerlinguistik)
  • Veröffentlichungskonferenz: 39. Konferenz zu Neuronalen Informationsverarbeitungssystemen (NeurIPS 2025) Workshop: Deep Learning for Code
  • Paper-Link: https://arxiv.org/abs/2510.13163v1

Zusammenfassung

Die meisten großen Sprachmodelle (LLMs) zeigen hervorragende Leistungen bei der Generierung von rohem, sequenziellem Code, aber es gibt wenig Forschung zur graphenbasierten abstrakten Codegenerierung. Graphenbasierter abstrakter Code kapselt wichtige Logik in vordefinierten Knoten ein, wobei Kanten den Ausführungsfluss bestimmen. Diese Codeform ist in visuellen Programmiersprachen verbreitet und wichtig in Szenarien, in denen der ursprüngliche Quellcode für Benutzer und LLM-Trainingssätze nicht zugänglich ist. Dieses Papier schlägt JSON-Repräsentationsmethoden für Graphen vor und evaluiert diese, um hochpräzise graphenbasierte abstrakte Codegenerierung zu ermöglichen. Die Autoren evaluieren diese Repräsentationsmethoden auf ScratchTest, einem kleinen Benchmark basierend auf einer Python-Neuimplementierung von Scratch. Die Forschung zeigt, dass LLMs unter der richtigen Graphenrepräsentation die genannte Aufgabe tatsächlich in einer einzigen Generierung bewältigen können, ohne auf spezialisierte oder komplexe Pipelines angewiesen zu sein. Unterschiedliche Repräsentationsmethoden führen zu deutlich unterschiedlichen Genauigkeitsraten und unterstreichen die kritische Rolle der Repräsentation bei dieser Generierungsaufgabe.

Forschungshintergrund und Motivation

Problemdefinition

Aktuelle LLMs konzentrieren sich im Bereich der Codegenerierung hauptsächlich auf rohe, sequenzielle Codegenerierung, bei der Code in linearer Weise in Zeileneinheiten angeordnet ist. Viele praktische Anwendungsszenarien erfordern jedoch graphenbasierte abstrakte Codegenerierung, wie etwa:

  • Visuelle Programmiersprachen: Scratch, Unreal Engine Blueprints, n8n usw.
  • Hochabstrakte Bibliotheken und Frameworks: Implementierungsdetails werden gekapselt, Benutzer können nur über vordefinierte Schnittstellen operieren

Bedeutungsanalyse

  1. Breite Anwendung: Graphische Programmiersprachen werden von Anfängern, Spieleentwicklern und Softwareingenieuren weit verbreitet verwendet
  2. Knappheit von Trainingsdaten: Neue Bibliotheken und Frameworks verfügen über unzureichende Trainingsdaten und sehen sich denselben Abstraktionsherausforderungen wie graphenbasierter Code gegenüber
  3. Nichtlineare Beziehungen: Graphische Sprachen führen komplexe nichtlineare Beziehungen zwischen Knoten ein, die traditionelles kontextabhängiges Lernen schwer bewältigen kann

Einschränkungen bestehender Methoden

  • Graphgenerierungsmethoden: GraphRNN, GraphGAN usw. konzentrieren sich auf allgemeine Graphgenerierung und sind nicht für funktionale Code-Graphen geeignet
  • Graph Foundation Models (GFMs): GNN-basierte Methoden haben schlechte Skalierbarkeit, LLM-basierte Methoden sind überabhängig von fragiler natürlicher Sprache
  • Codegenerierungsmodelle: Hauptsächlich auf sequenziellen Code ausgerichtet, mit großen Unterschieden in der Unterstützung verschiedener Sprachen/Frameworks

Kernbeiträge

  1. Vorschlag einer JSON-Repräsentationsmethode für Knoten: Ermöglicht es aktuellen LLMs, Code-Graphen mit höchster syntaktischer und logischer Genauigkeit zu generieren
  2. Vorschlag einer JSON-Repräsentationsmethode für Code-Graphen: Verbessert weiter die Genauigkeit der Graphenrepräsentation von LLM-Ausgaben
  3. Konstruktion des ScratchTest-Benchmarks: Basierend auf einer Python-Neuimplementierung von Scratch, speziell zur Evaluierung der Fähigkeit zur graphenbasierten abstrakten Codegenerierung
  4. Validierung der Bedeutung der Repräsentation: Nachweis, dass unter einem Single-Agent-LLM-Framework die richtige Repräsentation die Generierungsgenauigkeit erheblich verbessern kann

Methodische Details

Aufgabendefinition

  • Eingabe: Natürlichsprachliche Beschreibung von Funktionsanforderungen
  • Ausgabe: Ein verbundener Graph, der die Anforderungen erfüllt, mit vordefinierten Knoten und Kantenverbindungen
  • Einschränkungen: Der Graph muss ein gerichteter azyklischer Graph (DAG) sein, um eine gültige Ausführungssequenz zu gewährleisten

ScratchTest-Benchmark-Design

Benchmark-Merkmale

  • Knotenzahl: 53 eingebaute Scratch-Blöcke (von 107 insgesamt in der CLI implementierbaren)
  • Knotentypen: Bewegung, Aussehen, Sound, Ereignisse, Kontrolle, Wahrnehmung, Operatoren, Variablen und 8 weitere Kategorien
  • Vereinfachte Implementierung: Keine direkte Sprite-Manipulation, Funktionsbewertung durch Verhaltensprotokollierung
  • Zustandspersistenz: Verwaltung eines Sprite-Attributwörterbuchs (Position, Ausrichtung usw.)

Evaluierungsmethode

  • Testsatz: 20 eindeutige Funktionsbeschreibungs-Prompts
  • Evaluierungsläufe: Jeder Prompt wird unabhängig 5-mal ausgeführt
  • Evaluierungskriterien: Manuelle Bewertung der logischen Korrektheit von Verhaltensprotokollen und Python-Dateien

Repräsentationsmethodendesign

Referenzknotendarstellung

[NODENAME]: {
    inPorts: [{id: string, type: string}],
    fields: [{id: string, type: string}],
    outPorts: [{id: string, type: string}]
}

Schlüsselkomponenten:

  • NODENAME: Entspricht dem Scratch-Blocknamen
  • inPorts: Eingabeports, einschließlich Parameter und EXEC-Ports (Ausführungsfluss)
  • fields: Parameter mit vordefinierten Optionen
  • outPorts: Ausgabeports, einschließlich Rückgabewerte, THEN-Ports (nachfolgende Ausführung), SUBSTACK-Ports (Schleifen/Kontrolle)
  • type: Port-Typ, verhindert inkompatible Verbindungen

Ausgabegraphendarstellung

{
    nodes: {
        [key: string]: {
            name: string,
            value: any | null
        }
    },
    edges: [{
        outNodeID: string,
        outPortID: string,
        inNodeID: string,
        inPortID: string
    }]
}

Designvorteile:

  • Separation of Concerns: Knoten und Kanten werden separat definiert, was Fehler reduziert
  • Lineare Generierung: Knoten werden zuerst definiert, dann Verbindungen
  • Vermeidung von Redundanz: Jede Kante wird nur einmal definiert

Nachbearbeitungsprozess

  1. Topologische Sortierung: Gewährleistung der gerichteten azyklischen Eigenschaft des Graphen
  2. Python-Konvertierung: Umwandlung der Graphenrepräsentation in eine pythonische Scratch-Implementierung
  3. Objektinstanziierung: Erstellung von Scratch-Block-Objekten und Bindung von Variablen
  4. Verbindungsaufbau: Aufbau des Ausführungsflusses basierend auf THEN- und EXEC-Ports

Experimentelle Einrichtung

Datensatz

  • ScratchTest: 20 Funktionsbeschreibungs-Prompts
  • Beispiel-Prompts:
    • "When the green flag is clicked, continuously move in a square pattern until the user presses the space key"
    • "When the 's' key is pressed, say a secret password made of two random letters and three random numbers"

Bewertungsmetriken

  • Genauigkeit: Anteil der korrekt implementierten Funktionen
  • Bewertungskriterien:
    • Vernünftige Verhaltensprotokoll-Ausgabe
    • Logisch korrekte Python-Datei
    • Keine Nachbearbeitungs- oder Ausführungsfehler

Vergleichsmethoden

Referenzknotendarstellung-Ablation

  1. No Types: Minimale Baseline ohne Port-Typinformationen
  2. Extra Description: Mit natürlichsprachlichen Beschreibungen von Knoten und Ports
  3. Proposed: Vollständige vorgeschlagene Repräsentation

Ausgabegraphendarstellung-Ablation

  1. Alternative: Alternative Repräsentation mit eingebetteten Kanteninformationen in Knoten
  2. Proposed: Vorgeschlagene Repräsentation mit getrennten Knoten und Kanten

Implementierungsdetails

  • Hauptmodell: OpenAI gpt-oss-120b (Groq-Plattform)
  • Weitere Modelle: qwen3-32b, deepseek-r1-distill-llama-70b, llama-3.3-70b-versatile
  • Konfiguration: Temperature=1, Max Tokens=8192, Top P=1
  • Framework: Single-Agent, ohne Feinabstimmung, ohne kontextabhängiges Lernen, ohne Multi-Turn-Interaktion

Experimentelle Ergebnisse

Hauptergebnisse

Referenzknotendarstellung-Ablationsergebnisse

MethodeDurchschnittliche GenauigkeitStandardabweichung
No Types0,650,071
Extra Description0,740,082
Proposed0,750,050

Statistische Signifikanz:

  • Proposed vs No Types: p=0,036 ≤ 0,05 (signifikant)
  • Proposed vs Extra Description: p=0,82 > 0,05 (nicht signifikant)

Ausgabegraphendarstellung-Ablationsergebnisse

MethodeDurchschnittliche GenauigkeitStandardabweichung
Alternative0,490,042
Proposed0,750,050

Statistische Signifikanz: p=0,000024 ≤ 0,05, Proposed zeigt eine Verbesserung von 23-29% gegenüber Alternative

Wichtigste Erkenntnisse

  1. Bedeutung von Typinformationen: Das Hinzufügen von Port-Typen verbessert die Genauigkeit erheblich und verhindert inkompatible Verbindungen
  2. Begrenzte Wertigkeit von Beschreibungsinformationen: Natürlichsprachliche Beschreibungen können die Leistung nicht wesentlich verbessern und erhöhen stattdessen den Token-Verbrauch
  3. Kritische Rolle der Repräsentationsstruktur: Getrennte Graphenrepräsentation ist deutlich überlegen gegenüber eingebetteter Repräsentation
  4. Verbesserte Konsistenz: Die vorgeschlagene Methode zeigt stabilere Leistung über mehrere Läufe hinweg

Häufige Fehlertypen

  1. Ungültige DAG: Generierung von Graphen mit Zyklen
  2. Nicht deklarierte Variablenreferenzen: Referenzierung von nicht definierten Variablen
  3. Port-Verbindungsfehler: Verbindung von Ports in gleicher Richtung oder Vergessen der Port-Definition

Leistung anderer Modelle

Die anderen drei Modelle (qwen3-32b, deepseek-r1-distill-llama-70b, llama-3.3-70b-versatile) zeigen deutlich schlechtere Leistungen als gpt-oss-120b, mit in den meisten Fällen niedrigeren Genauigkeitsraten und höheren Fehlerquoten.

Verwandte Arbeiten

Graphverständnis und -generierung

  • Allgemeine Graphgenerierung: GraphRNN, GraphGAN konzentrieren sich auf das Lernen von Graphverteilungen und sind nicht für funktionale Code-Graphen geeignet
  • Graph Foundation Models: GNN-basierte Methoden haben schlechte Skalierbarkeit, LLM-basierte Methoden sind abhängig von fragiler natürlicher Sprache
  • LLM-Graphverständnis: Bestehende Arbeiten evaluieren hauptsächlich mathematisches Graphverständnis, nicht logische Codierungs-Graphen

LLM-Code-Agenten

  • Codegenerierungsfähigkeiten: Aktuelle LLMs zeigen hervorragende Leistungen bei traditioneller Codegenerierung
  • Verbesserungsmethoden: Reinforcement Learning, Chain-of-Thought, Infill-Training, Constraint Decoding usw.
  • Leistungsunterschiede: Erhebliche Unterschiede in der Generierungsfähigkeit zwischen verschiedenen Sprachen/Frameworks, hauptsächlich durch die Verfügbarkeit von Trainingsdaten bestimmt

Schlussfolgerung und Diskussion

Hauptschlussfolgerungen

  1. Machbarkeitsprüfung: LLMs können graphenbasierte abstrakte Codegenerierung in einer einzigen Generierung bewältigen
  2. Kritische Rolle der Repräsentation: Die richtige JSON-Repräsentation ist entscheidend für die Generierungsgenauigkeit
  3. Designprinzipien: Typinformationen, Separation of Concerns und linearer Generierungsfluss sind Schlüsselelemente einer effektiven Repräsentation
  4. Benchmark-Etablierung: ScratchTest bietet einen Evaluierungsbenchmark für graphenbasierte Codegenerierung

Einschränkungen

  1. Genauigkeitsbeschränkung: Selbst mit der besten Repräsentation wird keine 100%ige Genauigkeit erreicht
  2. Modellabhängigkeit: Die Leistung ist stark von spezifischen LLM-Fähigkeiten abhängig
  3. Skalierungsbeschränkung: Derzeit nur in der relativ einfachen Scratch-Domäne validiert
  4. Evaluierungsmethode: Abhängig von manueller Evaluierung, fehlende automatisierte Evaluierungsstandards

Zukünftige Richtungen

  1. Repräsentationsoptimierung: Erkundung von nicht-JSON-Repräsentationsmethoden
  2. Spezialisierte Modelle: Entwicklung von Generierungsmodellen speziell für Code-Graph-Räume
  3. Multi-Agent-Framework: Kombination von Planung und Fehlerkorrektur in Multi-Turn-Methoden
  4. Großflächige Validierung: Validierung in komplexeren graphischen Programmierumgebungen

Tiefgreifende Bewertung

Stärken

  1. Neuheit des Problems: Erste systematische Untersuchung des graphenbasierten abstrakten Codegenerierungsproblems
  2. Methodische Einfachheit: Die vorgeschlagene JSON-Repräsentationsmethode ist einfach und effektiv, leicht zu implementieren und zu erweitern
  3. Experimentelle Strenge: Mehrfache Läufe und statistische Tests gewährleisten Zuverlässigkeit der Ergebnisse
  4. Praktischer Wert: Bietet Grundlagen für KI-gestützte Entwicklung visueller Programmiersprachen

Mängel

  1. Evaluierungsbeschränkung: Manuelle Evaluierungsmethode ist nicht ausreichend objektiv, schwer großflächig anwendbar
  2. Benchmark-Größe: 20 Testfälle sind relativ wenige, möglicherweise nicht umfassend genug
  3. Modellabdeckung: Ergebnisse hauptsächlich auf einem Modell basierend, andere Modelle zeigen schlechtere Leistung
  4. Theoretische Analyse: Fehlende tiefgreifende theoretische Erklärung, warum bestimmte Repräsentationen effektiver sind

Auswirkungen

  1. Bahnbrechender Beitrag: Etabliert Forschungsbaseline für graphenbasierte Codegenerierung
  2. Praktische Anwendung: Direkt anwendbar auf visuelle Programmiertools wie Scratch
  3. Erweiterbarkeit: Methode kann auf andere graphische Programmierumgebungen erweitert werden
  4. Inspirationswert: Unterstreicht die Bedeutung von Repräsentationslernen in der Codegenerierung

Anwendungsszenarien

  1. Bildungsbereich: Unterstützung der Codegenerierung für Lehrtools wie Scratch
  2. Schnelle Prototypisierung: Automatisierung von Blueprint-Systemen in der Spieleentwicklung
  3. Workflow-Automatisierung: Intelligente Konfiguration von Tools wie n8n
  4. Neue Bibliotheken-Anpassung: Codegenerierung für neue Frameworks mit mangelnden Trainingsdaten

Referenzen

Das Papier zitiert 54 verwandte Arbeiten, die LLM-Codegenerierung, Graphenneuronale Netze, visuelle Programmiersprachen und andere wichtige Arbeiten in mehreren Bereichen abdecken und eine solide theoretische Grundlage für die Forschung bieten.


Gesamtbewertung: Dies ist eine bahnbrechende Arbeit, die sich erstmals systematisch mit dem Problem der graphenbasierten abstrakten Codegenerierung befasst. Obwohl es noch Verbesserungspotenzial in Evaluierungsmethoden und theoretischer Analyse gibt, ist die vorgeschlagene Repräsentationsmethode einfach und effektiv und legt eine wichtige Grundlage für diese neue Forschungsrichtung. Diese Arbeit hat hohen praktischen Wert und Inspirationskraft und wird voraussichtlich weitere Entwicklungen in verwandten Bereichen fördern.