大規模モデルがコードグラフを直接理解：エージェントなしでバグを自動修正、SWE-Benchオープンソースモデルランキングで首位獲得

AIが自動でバグを修正し、解決率44%を達成！これは世界のオープンソースモデルにおける最新かつ最強のレベルです。

Ant Groupの新しいオープンソースモデルは、SWE-bench Liteで他のすべてのオープンソースソリューションを上回り、クローズドソースモデルに匹敵する性能を示しています。

SWE-bench Liteでの具体的なパフォーマンスは以下の通りです：

すべてのオープンウェイトモデル（Open Weight Model）で1位；

すべてのオープンソースシステム（Open Source System）で6位；

全体で14位；

現在のランキングトップのオープンソースモデル「KGCompass」を7.33%上回ります。

彼らはリポジトリのコードグラフモダリティを大規模モデルに統合する（Code Graph Model, CGM）ことを初めて提案し、大規模言語モデルがコードグラフを直接理解し、より効率的にバグを修正し、コードを補完できるようにしました。

これにより、GPT-4やClaude 3.7などのブラックボックスモデルや複雑なエージェントのワークフローへの依存から完全に脱却し、より制御可能で透明性があり、安全なソフトウェアエンジニアリングの自動化を実現します。

さらに、CGMは完全にオープンソースモデルに基づいて構築されています。ご存知の通り、オープンソースモデルはSWE-benchでのパフォーマンスが通常不十分であり、これまでのSOTAレベルのソリューションはほぼすべてクローズドソースモデルに基づいていました。しかし、CGMはQwenモデルに基づいて、クローズドソースモデルに匹敵するレベルを達成しました。

CGMはわずか4ステップで迅速にパッチを特定、生成でき、エージェントソリューションの複雑なオーケストレーションプロセスを省き、効率を大幅に向上させます。

AIに大規模モデルのコードベースを真に理解させる

大規模モデルのトレンド以来、AIプログラミングは急速に台頭し、特にHumanEvalなどのベンチマークでは、多くのモデルが90%以上の精度を達成するなど、関数記述のような小規模タスクで優れたパフォーマンスを示しています。

しかし、実際のソフトウェアエンジニアリングは「関数を記述する」よりもはるかに複雑です。バグ修正や機能強化のようなタスクは、通常、ファイル間、モジュール間の操作を必要とし、プロジェクト内の複雑な構造、依存関係、クラス継承システムをモデルが理解することを求めます。

現在の主流な手法は、通常、クローズドソースモデルに基づいたエージェントを使用することです。これらは人間のプログラマーの行動（コードの観察、ツールの呼び出し、複数回の対話など）をシミュレートしてタスクを完了できます。

しかし、これらの手法にはいくつかの問題もあります：

動作パスが制御不能で、推論エラーが蓄積しやすい；

GPT-4やClaudeなどのクローズドソースモデルに依存するため、プライベートデプロイメントやカスタマイズが難しい；

エンジニアリングコストが高く、効率が低い。

同時に、現在のオープンソースモデルを用いたソリューションでは、SOTAレベルの効果を達成するのは困難です。

そのため、研究チームは次のように提案しました：オープンソースモデルのみを使用し、エージェントに依存せずに、リポジトリレベルのタスクを解決できないか？この問いからCGMが生まれました。

🔍グラフ構造と大規模モデルの深層融合

CGMは、Vision-Language Model（VLM）に似たクロスモーダルモデリング方式を採用しています。従来のLLMのテキスト理解能力とコードリポジトリの構造グラフ（Graph）を組み合わせ、グラフ-言語マルチモーダルモデルを形成します。モデルの核は2つのモダリティを融合しています：

グラフモダリティ：リポジトリを構造化グラフとして構築し、ノードには関数、クラス、ファイル、パッケージなど7種類を含み、エッジは呼び出し、包含、継承などの依存関係を表します；

言語モダリティ：ユーザーが入力した自然言語記述とコードプロンプトにより、モデルがパッチを生成したり、回答したりするのを駆動します。

モデルの入力はコードグラフとテキスト形式のプロンプトであり、LLM内で構造とセマンティクスのバイモーダルアラインメントが行われます。

具体的な構造融合方法は以下の通りです：

小型エンコーダ（CodeT5+）を使用して各ノードをエンコードし、単一の「ノードトークン」に圧縮します。各ノード内は最大512トークンのテキストブロックに分割されます。

アダプター（2層MLP）を介してエンコードされたノード表現をLLMの入力埋め込み空間にマッピングします。これはLLMのコンテキストを512倍に拡張することに相当し、膨大なコードリポジトリのコンテキストをより良く処理できます。

グラフ認識アテンションマスク（Graph-aware Attention Mask）を使用します。LLMの元々の因果的アテンションを置き換え、アテンションメカニズムが隣接ノード間のみに作用するようにします。これはGNNのメッセージ伝達メカニズムに似ており、LLMがコードの構造的依存関係を直接認識し、利用できるようにします。

✏️2段階トレーニング：構造理解＋問題汎化

このモデルアーキテクチャに基づき、チームは2段階のトレーニングを通じてLLMがコードグラフのトポロジー構造を理解できるようにしました。

第1段階：サブグラフ再構築事前学習

CGMがコードグラフの意味的および構造的情報を効果的に捉えるようにトレーニングするため、チームは「Graph-to-Code」タスクを設計しました。大規模なコードグラフからサブグラフをランダムにサンプリングし（出力コード長を制御するためにノード数を制限）、モデルはこれらの入力サブグラフ（ノードタイプと接続関係のみを含み、完全なコード内容は含まない）に基づいて元のコードスニペットを再構築する必要があります。

次に、階層的な方法を採用し、再構築されたコードの構造の一貫性と可読性を維持します。トポロジカルソートと行番号の順序に従ってリポジトリのコンテキストを連結します。高レベルノード（例：REPO、PACKAGE）は出力シーケンスまたはファイルの先頭に配置されます。ファイルノードはトポロジカルソートによって順序が決定され、ファイル内のノード（例：CLASS、FUNCTION）は行番号の順序で連結されます。

第2段階：ノイズ増強ファインチューニング

この段階では、実際のGitHubの問題-修正パッチデータを使用してCGMをファインチューニングします。

モデルは2つの入力に基づいてコードパッチを生成することを学習します：（i）関連するコードサブグラフ、（ii）パッチに基づいて変更が必要な実際のファイルを指定するテキストプロンプト。モデルのロバスト性を向上させるため、意図的にプロンプトに10%のノイズ入力を導入しました。例えば、プロンプトには実際には変更する必要のない無関係なファイルが含まれている場合や、変更されるべき重要なファイルが少なくとも1つ欠落している場合があります。トレーニング中にこのような制御されたノイズを導入することで、モデルは入力情報が不完全であるか、干渉を含むシナリオに対してより良く汎化できるようになります。

📎推論段階：Graph-RAGフレームワークがエージェントを置き換え

最後に、実際の応用能力をさらに向上させるため、CGMはエージェント不要の軽量フレームワークGraph-RAGを構築しました。

これは人間のプログラマーのバグ修正ワークフローを再現しますが、既存のエージェントソリューションよりも効率的です。

コアモジュールの数が10個からさらに4個に削減されました：リライター → リトリーバー → リランカー → ジェネレーター（CGMモデル）。

リライター（Rewriter）：問題記述を書き換え、キーワードと関連ファイルを抽出；

リトリーバー（Retriever）：セマンティックおよび構造的検索を通じて、コードグラフから連結されたサブグラフを抽出；

リランカー（Reranker）：検索結果を並べ替え、生成に最も重要なファイルを選択；

ジェネレーター（Reader）：サブグラフとプロンプトを組み合わせて最終的な修正コードを生成。