技術的概要：SynConfRoute 小規模 CodeLLM による効率的なコード補完のための構文認識ルーティング

問題定義

企業は、高品質な AI コード補完への需要とデータプライバシーの必要性との間で、決定的な緊張関係に直面している。大規模なプロプライエタリ CodeLLM（30B〜480B 超のパラメータ）は優れた性能を提供するが、高価な自己ホスト型インフラまたは外部 API を必要とする。後者は、プロプライエタリなソースコードを露出させるリスクがある（例：サムスンとシスコの事例）。一方、小規模 CodeLLM（1B〜3B パラメータ）は、サブ秒の遅延で開発者のワークステーション上でローカルに実行でき、データが機械から外部へ流出しないことを保証するが、複雑なタスクでは失敗することが多い。

核心的な課題は、ローカルな小規模モデルで十分なのか、それともより大規模な自己ホスト型モデルへリクエストをエスカレーションすべきかを判断することである。既存の自然言語処理（NLP）向けルーティング戦略は、トークンの信頼度や学習された特徴に依存しているが、コードの固有の特性を考慮していない。コードにおいては、正しさが表面の類似性ではなく、実行ベースのテストによって定義されるためである。さらに、どの小規模モデルが最も優れた品質とコストのトレードオフを提供するか、またルーティングなしで品質ギャップを埋めるために推論時の技術（数ショット検索など）が機能するかどうかは依然として不明である。

手法

1. ベンチマークとモデル選択（RQ1）

著者は、12 ファミリーにわたる 29 種類の CodeLLM（0.5B から 480B パラメータまで）を、実行ベースの Fill-in-the-Middle（FIM）ベンチマークで評価した。

• HumanEval-Infilling: HumanEval から派生した 1,033 件の単一行 Python タスク。
• SAFIM: 競技プログラミングからの構文認識 FIM タスク。Python、Java、C++ を対象とし、制御フロー、アルゴリズムブロック、API 呼び出しのサブタイプを網羅。
• 評価指標: pass@1（実行ベースの正解率）。ExecEval フレームワークを通じて測定。
• 設定: 小規模/中規模モデルは、単一の 80 GB アクセラレータ上で Q4_K_M 量子化を用いて Ollama 経由で提供。大規模な参照モデルは、テンソル並列化を用いて vLLM 経由で提供。

2. ルーティング戦略の開発（RQ2）

本研究は、コード固有の構造的性質を活用するように設計された、トレーニング不要の 2 段階ルーティング手法であるSynConfRouteを提案した。

• ティア 1（ローカル）: 小規模モデル（例：3B）が補完と信頼度スコア（最初の 3 トークンの平均対数確率）を生成する。
• ティア 2（エスカレーション）: 大規模モデル（例：32B または 480B）が、共有組織用アクセラレータ上で利用可能。
• ルーティングロジック:
  1. 信頼度チェック: ローカルモデルの信頼度が閾値 $t^*$ 未満の場合、リクエストはエスカレーションされる。
  2. 構文検証: 信頼度が高い場合、完成したコード（プレフィックス＋生成物＋サフィックス）が、言語固有のパーサー（Python 用 ast.parse、Java 用 javalang、C++ 用 g++ -fsyntax-only）を用いて構文的妥当性をチェックされる。
  3. 決定: コードが構文的に無効な場合、信頼度に関わらずリクエストはエスカレーションされる。信頼度が高く、かつ構文的に妥当な補完のみがローカルに保持される。

3. 比較分析

著者は、SynConfRoute を 6 つのベースラインと比較した。

• 推論前: 静的コードシグナル（決定木）、埋め込み KNN、組み合わせ特徴量、Eagle ELO ルーティング。
• 推論後: 信頼度のみのルーティング、カスケードルーティング。
• 推論時の代替案: 数ショット検索（TF-IDF、埋め込み）およびマルチサンプル投票。

主要な貢献と知見

1. モデル選択：ファミリーとトレーニング目的がサイズを上回る

• モデルファミリーの優位性: Qwen2.5-Coder-3B モデルは、HumanEval-Infilling で 64.7% の pass@1 を達成し、10 倍小さいにもかかわらず、32B モデル（64.8%）と同等の性能を示した。
• トレーニング目的の重要性: エージェントタスク向けにトレーニングされたより大規模な 80B MoE モデル（Qwen3-Coder-Next）は 41.1% しかスコアせず、FIM 向けにトレーニングされた 3B モデルを大幅に下回った。これは、パラメータ数よりも特定タスク（FIM）へのトレーニングがより重要であることを確認するものである。
• 量子化: Q4_K_M 量子化は、3B モデルにおいて FP16 品質を完全に保持したが、過激な 2 ビット量子化は壊滅的だった。1B 未満のモデルは、実用的な展開には不適と判断された。

2. SynConfRoute：構造的妥当性の活用

• 失敗の分解: 3B モデルの失敗分析により、「信頼度が高いが誤っている」補完の 46% が構文的に無効（構造的に破損）であり、54% が意味的に誤っていることが明らかになった。
• 性能向上: SynConfRoute は、定型タスクにおいて信頼度のみのルーティングに対して pass@1 を**6.4%向上させ（78.9% 対 72.5%）、より困難な多言語タスクでは最大31%**向上させた。
• 偽陽性のゼロ: 構文チェックは、正しいローカル補完を拒否することなく、構造的に破損したすべての補完を検知した。
• 相補性: 3B モデルと 480B モデルは異なる誤りを犯した。3B モデルは、480B モデルが誤ったインデントにより失敗する単純なタスク（例：return 文）を解決することが多かった。ルーティングはこれらのローカルでの成功を保持した。

3. 一般化と限界（RQ3）

• 言語横断: SynConfRoute は Python、Java、C++ 間で一般化し、9 つの SAFIM スプリットすべてにおいて信頼度のみのルーティングを上回った。ルーティングの境界はプログラミング言語ではなく、エラーの種類（構造的か意味的か）である。
• 推論時の代替案の失敗: 数ショット検索は、モデルがタスクを解決するのではなく例のパターンをコピーするため、最良の小規模モデル（3B）の性能を 10% 低下させた。マルチサンプル投票はわずかな利益しか提供せず、小規模モデルの失敗は知識の欠如であり、サンプリングの問題ではないことを示唆した。
• 天井: 残りの 54% の信頼ある失敗（構文的に妥当だが意味的に誤っている）は、静的ルーティングの天井を表す。このギャップを埋めるには、モデルレベルの改善が必要である。

意義と実用的含意

本論文は、SynConfRoute が、カスタムトレーニングなしで「ローカルファースト」なコード補完戦略を求める企業にとって、即座に展開可能なソリューションを提供すると主張している。

• 品質対コスト: SynConfRoute パイプライン（3B ローカル＋480B エスカレーション）は78.9% の pass@1を達成し、480B モデル単独を使用する場合よりも7.4% 高い性能を示した。
• 効率性: この品質の向上は、常に大規模モデルへルーティングする場合と比較して、共有アクセラレータの使用量を58% 削減するものである。
• プライバシー: 補完の**58%**が完全にオンデバイスに留まり、データ露出を防止する。
• 展開: システムは、微調整を必要とせず、市販のモデル（例：Qwen2.5-Coder-3B）と標準フレームワーク（Ollama、vLLM）を使用する。構文チェックは無視できる遅延（<1 ms）を追加するのみである。

著者は、コード補完は構造的妥当性（構文）をルーティング信号として利用できる NLP には存在しない固有の領域であると結論づけている。これにより、高品質、低遅延、厳格なデータプライバシーを両立するハイブリッドアーキテクチャが可能となる。