技術要約: TICoder

問題提起

大規模言語モデル（LLM）を用いたリポジトリレベルのコード生成は、複雑なコード依存関係と限定的なコンテキストウィンドウにより、重大な課題に直面しています。既存のアプローチは、リポジトリ内の関数を再利用するために、検索拡張生成（RAG）やプランニングメカニズムを利用していますが、著者らは現在の最先端（SOTA）の手法における2つの決定的な限界を指摘しています。

1. プランニングにおけるテスト駆動型の振る舞いガイダンスの欠如: 既存のプランニングベースの手法は、自然言語（NL）の要件から直接実装ステップを導き出します。しかし、NLの要件はしばしば曖昧または不完全であり、信頼性の低いプランをもたらします。現在のテスト駆動型生成手法は、主にコード生成または生成後の段階でテストケースを適用しており、プランニングプロセスを導くためのその潜在的な可能性が未探索のままです。
2. 再利用におけるコードレベルの実装認識の欠如: 既存の検索戦略は、実装ステップと関数記述の間の意味的な類似性に大きく依存しています。これらは、コードに埋め込まれた実際の実装ロジックを見落としがちです。さらに、取得された関数は、リポジトリ内でそれらが実際にどのように使用されているか（使用パターン）を理解することなくプロンプトに挿入されることが多く、効果的な再利用を妨げています。

メソドロジー: TICoderフレームワーク

著者らは、リポジトリレベルのコード生成のプランニングおよび再利用の両フェーズを改善するために設計されたフレームワークであるTICoderを提案しています。このフレームワークは、主に3つのステージで構成されています。

1. テスト駆動型反復プランニング

NLの要件のみからプランを生成するのではなく、TICoderはテストケースを振る舞いの仕様として活用し、実装ステップを洗練させます。このステージでは、「Judge-and-Reflection（判定と内省）」メカニズムを採用しており、2つのLLMロールが関与します。

• LLM-as-a-Planner（プランナーとしてのLLM）: 要件とテストケースに基づき、明快さ、境界条件への意識、および明示的な依存関係といった原則に従って、初期の実装ステップのシーケンスを生成します。
• LLM-as-a-Judge（判定役としてのLLM）: 生成されたステップを、機能的カバレッジ/一貫性、独立性、および粒度の3つの次元で評価します。
• 反復的な洗練: ステップが品質の閾値を満たさない場合、判定役はフィードバックを提供し、プランナーはステップを洗練させます。このループは、プランが満足いくものになるか、最大反復回数に達するまで継続されます。

2. 実装認識型のコード再利用

このステージでは、関連する被呼出し関数（callee functions）を検索し、それらを効果的に使用する方法を特定することに焦点を当てます。

• デュアルビューによる被呼出し関数の検索: 関数を検索するために、TICoderは以下の組み合わせによる結合類似度スコアを計算します。
  • 機能的類似度 ($Sim_F$): 実装ステップと関数記述の間の意味的類似度。
  • 実装類似度 ($Sim_I$): 実装ステップのコード表現（LLMによって生成されたもの）と、実際の関数実装コードとの間の類似度。
  • 最終スコアは、加重和（$Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$）となります。
• デュアルステージの使用パターン選択: 関数が正しく使用されることを確実にするため、TICoderはリポジトリから代表的な使用パターンを選択します。
  • グラフベースの特定: リポジトリ・コールグラフ（RCG）を構築し、検索された被呼出し関数のすべての呼出元関数（caller functions）を特定します。
  • 構造ベースのクラスタリング: 呼び出す関数の集合（構造的等価性）に基づいて、呼出元関数をグループ化します。
  • パープレキシティに基づくフィルタリング: 各クラスター内で、最も関連性の高い呼出元（最小のパープレキシティ）をセンターとして選択します。その後、グローバルフィルターがこれらのセンターをパープレキシティによってランク付けし、コンテキストの豊かさとトークンの効率性のバランスを取りながら、上位 $n_p$ 個のパターンを選択します。

3. 強化されたコード生成

最終的なコード生成フェーズでは、洗練された実装ステップ、検索された被呼出し関数、選択された使用パターン、テストケース、および元の要件を単一のプロンプトに統合し、LLMに最終的なコードを生成させます。

主な貢献

本論文は、3つの主要な貢献を主張しています。

1. TICoderフレームワーク: テスト駆動型の反復的なプランニングと実装認識型のコード再用を統合した、新しいリポジトリレベルのコード生成フレームワーク。
2. 実装認識型の再利用戦略: デュアルビュー検索メカニズム（機能的類似度 + 実装類似度）とデュアルステージ選択戦略（クラスタリング + パープレキシティ・フィルタリング）により、リポジトリの関数を正確に特定し再利用する。
3. 広範な実証的評価: TICoderが複数のLLMおよびベンチマークにおいて、SOTAのベースラインを上回ることを示す包括的な実験。

実験結果

著者らは、CoderEval（PythonおよびJava）とDevEval（Python）という2つの広く使用されているベンチマークにおいて、3つのバックボーンLLM（GPT-4o-mini、DeepSeek-V3、Qwen2.5-Coder-7B）を用いてTICoderを評価しました。

• 全体的なパフォーマンス: TICoderは、すべてのベースライン（SimpleRAG、RepoCoder、AllianceCoder、RepoScopeを含む）を一貫して上回りました。最も優れた性能を示したベースラインに対して、平均**11.52%**の向上を達成しました。
• 統計的有意性: 両側t検定により、性能向上が統計的に有意であることが確認されました（$p < 0.05$）。
• アブレーション研究: いずれかの主要コンポーネント（プランニング、テストケース、反復的洗練、デュアルビュー検索、または使用パターン）を削除すると、性能の低下を招きました。これは、各モジュールの必要性を検証しています。
  • 特に、プランニングモジュールを削除すると、Pass@1が6.87%低下しました。
  • 生成ステージからテストケースを削除すると、10.42%の大幅な低下を招きました。
• ハイパーパラメータの感度:
  • 反復回数: パフォーマンスは一般に反復とともに向上しましたが、非単調であり、過度な反復はノイズを導入する可能性があります。
  • 類似度重み: 機能的類似度が概して重要でしたが、実装類似度も、特にJavaにおいて顕著な利点をもたらしました。
  • 使用パターン: 適度な数のパターン（例：2つ）が最良の結果をもたらしました。少なすぎるとコンテキストが制限され、多すぎるとノイズが導入されます。

意義と主張

本論文は、テストケースをプランニングフェーズに明示的に組み込み、実装ロジックに根ざした検索を行うことで、TICoderが従来のプランニングベースのRACGアプローチの特定の限界に対処していると断言しています。著者らは、振る舞いの仕様（テスト）と構造的コンテキスト（使用パターン）を通じて、自然言語の要件と実行可能なコードの間のギャップを埋めることにより、TICoderが複雑なリポジトリ設定において、より正確でコンテキストに適したコードの生成を可能にすると主張しています。この研究は、リポジトリレベルの生成を成功させるには、単に類似したコードを見つけるだけでなく、そのコードがどのように振る舞いとして規定され、既存のコードベース内にどのように構造的に統合されているかを理解する必要があることを強調しています。