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

表現の問題:グラフベース抽象コード生成に向けて

基本情報

  • 論文ID: 2510.13163
  • タイトル: A Matter of Representation: Towards Graph-Based Abstract Code Generation
  • 著者: Nyx Iskandar (UC Berkeley)、Hisham Bedri (Ramen VR)、Andy Tsen (Ramen VR)
  • 分類: cs.CL (計算言語学)
  • 発表会議: 39th Conference on Neural Information Processing Systems (NeurIPS 2025) Workshop: Deep Learning for Code
  • 論文リンク: https://arxiv.org/abs/2510.13163v1

概要

現在のほとんどの大規模言語モデル(LLM)は、生のシーケンシャルコード生成に優れていますが、グラフベース抽象コード生成に関する研究はほとんど行われていません。グラフベース抽象コードは、重要なロジックを事前定義されたノードにカプセル化し、エッジによって実行フローを決定します。このコード形式はビジュアルプログラミング言語で一般的であり、生のソースコードがユーザーとLLMトレーニングセットにアクセス不可能な場合に重要です。本論文は、グラフの高精度なグラフベース抽象コード生成を実現するためのJSON表現方法を提案および評価しています。著者らはScratchTestでこれらの表現方法を評価しており、これはScratchのPython再実装に基づく小規模ベンチマークです。研究により、正しいグラフ表現の下では、LLMは確かに単一生成でこのタスクを完了でき、特殊または複雑なパイプラインに依存する必要がないことが判明しました。異なる表現方法は大きく異なる精度をもたらし、このタスクにおける表現の重要な役割を強調しています。

研究背景と動機

問題定義

現在のLLMはコード生成分野において主に生のシーケンシャルコード生成に焦点を当てており、このようなコードは行単位で線形に配列されます。しかし、多くの実際のアプリケーションシナリオではグラフベース抽象コード生成が必要です。例えば:

  • ビジュアルプログラミング言語:Scratch、Unreal Engine Blueprints、n8nなど
  • 高度な抽象レベルのライブラリとフレームワーク:実装の詳細がカプセル化され、ユーザーは事前定義されたインターフェースを通じてのみ操作できます

重要性分析

  1. 広範な応用:グラフベースプログラミング言語は初心者、ゲーム開発者、ソフトウェアエンジニアによって広く使用されています
  2. トレーニングデータの希少性:新興ライブラリとフレームワークは十分なトレーニングデータが不足しており、グラフベースコードが直面する同じ抽象化の課題に直面しています
  3. 非線形関係:グラフベース言語はノード間に複雑な非線形関係を導入し、従来の文脈内学習では解決が困難です

既存方法の限界

  • グラフ生成方法:GraphRNN、GraphGANなどは汎用グラフ生成に焦点を当てており、機能的なコードグラフには適していません
  • グラフ基礎モデル(GFM):GNNベースの方法はスケーラビリティが低く、LLMベースの方法は脆弱な自然言語に過度に依存しています
  • コード生成モデル:主にシーケンシャルコードを対象としており、異なる言語/フレームワークのサポート能力に大きなばらつきがあります

核心的な貢献

  1. ノードのJSON表現方法を提案:現在のLLMが構文的および論理的に最も正確なコードグラフを生成できるようにします
  2. コードグラフのJSON表現方法を提案:LLMの出力グラフ表現の精度をさらに向上させます
  3. ScratchTestベンチマークを構築:Scratchのpython再実装に基づき、グラフベース抽象コード生成能力を評価するために特別に設計されています
  4. 表現の重要性を検証:単一エージェントLLMフレームワークの下では、正しい表現が生成精度を大幅に向上させることを証明しています

方法の詳細

タスク定義

  • 入力:自然言語で記述された機能要件
  • 出力:要件を満たす連結グラフ。事前定義されたノードとエッジの接続関係を含みます
  • 制約:グラフは有向非環グラフ(DAG)である必要があり、有効な実行シーケンスを保証します

ScratchTestベンチマーク設計

ベンチマークの特徴

  • ノード数:53個の組み込みScratchブロック(107個中CLIで実装可能な部分)
  • ノードタイプ:モーション、外観、サウンド、イベント、コントロール、センシング、オペレータ、変数など8つのカテゴリ
  • 簡略化実装:スプライトを直接操作せず、動作ログを通じて機能を評価します
  • 状態永続化:スプライト属性辞書(位置、方向など)を維持します

評価方法

  • テストセット:20個の独自の機能説明プロンプト
  • 評価回数:各プロンプトを独立して5回実行
  • 評価基準:動作ログとPythonファイルの論理的正確性を手動で評価

表現方法の設計

参照ノード表現

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

主要コンポーネント

  • NODENAME:対応するScratchブロック名
  • inPorts:入力ポート。パラメータとEXECポート(実行フロー)を含みます
  • fields:事前定義されたオプションのパラメータ
  • outPorts:出力ポート。戻り値、THENポート(後続実行)、SUBSTACKポート(ループ/制御)を含みます
  • type:ポートタイプ。互換性のない接続を防止します

出力グラフ表現

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

設計上の利点

  • 関心の分離:ノードとエッジを別々に定義し、エラーを削減します
  • 線形生成:最初にノードを定義し、次に接続関係を定義します
  • 重複の回避:各エッジは1回だけ定義する必要があります

後処理フロー

  1. トポロジカルソート:グラフの有向非環特性を保証します
  2. Python変換:グラフ表現をPythonic Scratch実装に変換します
  3. オブジェクトインスタンス化:Scratchブロックオブジェクトを作成し、変数をバインドします
  4. 接続確立:THENおよびEXECポートに基づいて実行フローを確立します

実験設定

データセット

  • ScratchTest:20個の機能説明プロンプト
  • プロンプト例
    • "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"

評価指標

  • 精度:機能を正しく実装した割合
  • 評価基準
    • 合理的な動作ログ出力
    • 論理的に正しいPythonファイル
    • 後処理または実行エラーなし

比較方法

参照ノード表現アブレーション

  1. No Types:ポートタイプ情報を削除した最小ベースライン
  2. Extra Description:ノードとポートの自然言語説明を追加
  3. Proposed:完全な提案表現

出力グラフ表現アブレーション

  1. Alternative:ノード内にエッジ情報を埋め込む代替表現
  2. Proposed:ノードとエッジを分離する提案表現

実装の詳細

  • 主要モデル:OpenAI gpt-oss-120b (Groqプラットフォーム)
  • その他のモデル:qwen3-32b、deepseek-r1-distill-llama-70b、llama-3.3-70b-versatile
  • 設定:Temperature=1、Max Tokens=8192、Top P=1
  • フレームワーク:単一エージェント、ファインチューニングなし、文脈内学習なし、マルチターン相互作用なし

実験結果

主要結果

参照ノード表現アブレーション結果

方法平均精度標準偏差
No Types0.650.071
Extra Description0.740.082
Proposed0.750.050

統計的有意性

  • Proposed vs No Types: p=0.036 ≤ 0.05 (有意)
  • Proposed vs Extra Description: p=0.82 > 0.05 (有意でない)

出力グラフ表現アブレーション結果

方法平均精度標準偏差
Alternative0.490.042
Proposed0.750.050

統計的有意性:p=0.000024 ≤ 0.05、Proposedはalternativeより23~29%向上

主要な発見

  1. タイプ情報の重要性:ポートタイプの追加により精度が大幅に向上し、互換性のない接続を防止します
  2. 説明情報の限定的な価値:自然言語説明はパフォーマンスを大幅に向上させることができず、むしろトークン消費を増加させます
  3. 表現構造の重要な役割:分離型グラフ表現は埋め込み型表現よりも大幅に優れています
  4. 一貫性の向上:提案方法は複数回の実行でより安定したパフォーマンスを示します

一般的なエラータイプ

  1. 無効なDAG:環路を含むグラフの生成
  2. 未宣言変数参照:未定義の変数の参照
  3. ポート接続エラー:同じ方向のポートの接続またはポート定義の忘却

その他のモデルのパフォーマンス

その他の3つのモデル(qwen3-32b、deepseek-r1-distill-llama-70b、llama-3.3-70b-versatile)のパフォーマンスはgpt-oss-120bよりも明らかに劣り、ほとんどの場合精度が低く、エラー率が高いです。

関連研究

グラフの理解と生成

  • 汎用グラフ生成:GraphRNN、GraphGANはグラフ分布の学習に焦点を当てており、機能的なコードグラフには適していません
  • グラフ基礎モデル:GNNベースの方法はスケーラビリティが低く、LLMベースの方法は脆弱な自然言語に依存しています
  • LLMグラフ理解:既存の研究は主に数学グラフの理解を評価しており、論理的なコーディンググラフではありません

LLMコードエージェント

  • コード生成能力:現在のLLMは従来のコード生成で優れたパフォーマンスを示しています
  • 強化方法:強化学習、思考の連鎖、穴埋め訓練、制約付きデコーディングなど
  • パフォーマンスの差異:異なる言語/フレームワークの生成能力には大きな差異があり、主にトレーニングデータの可用性によって決まります

結論と議論

主要な結論

  1. 実現可能性の検証:LLMは単一生成でグラフベース抽象コード生成を完了できます
  2. 表現の重要な役割:正しいJSON表現は生成精度に重要です
  3. 設計原則:タイプ情報、関心の分離、線形生成フローは効果的な表現の主要要素です
  4. ベンチマークの確立:ScratchTestはグラフベースコード生成の評価ベンチマークを提供します

限界

  1. 精度の制限:最良の表現を使用しても、100%の精度には達していません
  2. モデル依存性:パフォーマンスは特定のLLM能力に大きく依存しています
  3. スケール制限:現在、比較的単純なScratchドメインでのみ検証されています
  4. 評価方法:手動評価に依存しており、自動化された評価基準が不足しています

今後の方向性

  1. 表現の最適化:JSON以外のより優れた表現方法を探索します
  2. 専門モデル:コードグラフ空間に特化した生成モデルを開発します
  3. マルチエージェントフレームワーク:計画とエラー修正を組み合わせたマルチターン方法
  4. 大規模検証:より複雑なグラフベースプログラミング環境での検証

深い評価

利点

  1. 問題の新規性:グラフベース抽象コード生成問題を初めて体系的に研究しています
  2. 方法の簡潔性:提案されたJSON表現方法はシンプルで効果的であり、実装と拡張が容易です
  3. 実験の厳密性:複数回の実行と統計検定により結果の信頼性を確保しています
  4. 実用的価値:ビジュアルプログラミング言語のAI支援開発の基礎を提供しています

不足

  1. 評価の限界:手動評価方法は十分に客観的ではなく、大規模な応用が困難です
  2. ベンチマークスケール:20個のテストケースは比較的少なく、十分に包括的ではない可能性があります
  3. モデルカバレッジ:主に1つのモデルの結果に基づいており、他のモデルのパフォーマンスは低くなっています
  4. 理論分析:特定の表現がより効果的である理由についての深い理論的説明が不足しています

影響力

  1. 開拓的な貢献:グラフベースコード生成の研究ベースラインを確立しています
  2. 実際の応用:Scratchなどのビジュアルプログラミングツールに直接適用できます
  3. 拡張性:方法は他のグラフベースプログラミング環境に拡張可能です
  4. 啓発的意義:コード生成における表現学習の重要性を強調しています

適用シーン

  1. 教育分野:Scratchなどの教育ツールのコード生成を支援します
  2. 迅速なプロトタイピング:ゲーム開発のブループリントシステムの自動化
  3. ワークフロー自動化:n8nなどのツールのインテリジェント構成
  4. 新しいライブラリの適応:トレーニングデータが不足している新しいフレームワークのコード生成

参考文献

本論文は54の関連文献を引用しており、LLMコード生成、グラフニューラルネットワーク、ビジュアルプログラミング言語など複数の分野の重要な研究をカバーしており、研究に堅実な理論的基礎を提供しています。


総合評価:これは開拓的な研究であり、グラフベース抽象コード生成問題を初めて体系的に解決しています。評価方法と理論分析にはまだ改善の余地がありますが、提案された表現方法はシンプルで効果的であり、この新興研究分野の重要な基礎を築いています。この研究は強い実用的価値と啓発的意義を持ち、関連分野のさらなる発展を推進することが期待されています。