技術的概要：CRANE – Nullspace 編集によるコードエージェント向け制約付き推論注入

1. 問題定義

現代のコードエージェントは、複雑なソフトウェアタスクを解決するために高度な推論能力（計画、文脈の統合、エラーからの回復）を必要とする一方で、実行環境と効果的に相互作用するためにツール使用プロトコル（簡潔な出力、正しいスキーマ形式、厳格なツールのタイミング）を厳密に遵守する必要があります。

最近の観察により、対になったモデルチェックポイント間の不一致が示されています：

• インストラクトモデル：これらは簡潔でツールの規律が保たれていますが、深い計画や回復行動が欠如していることが多く、早期の編集やループを引き起こします。
• シンキングモデル：これらはより強力な推論と回復を示しますが、しばしば「過度に熟考」し、トークンを過剰に消費して、ツールプロトコル違反や行動の欠如によりパフォーマンスを低下させます。

既存のモデルマージ技術（Task Arithmetic、TIES、SLERP など）は、通常、マージをエンドポイントの対称的な融合として扱います。これらは、「シンキング」モデルから特定の推論行動を「インストラクト」バックボーンに注入しつつ、厳密にインストラクトモデルのデプロイ済みツールインターフェースを保持するという非対称的なコードエージェント設定向けには設計されていません。単純なマージは、エージェント実行の成功に必要なプロトコルの忠実性を損なうことがよくあります。

2. 手法：CRANE

CRANE（Nullspace 編集によるコードエージェント向け制約付き推論注入）は、シンキングとインストラクトのチェックポイント間の差分ベクトル（$\delta = \theta_{\text{think}} - \theta_{\text{inst}}$）を候補推論編集の方向性プールとして扱うトレーニングフリーのパラメータ編集手法です。これは、エージェントの行動を保持しながらこれらの編集を選択的に注入するための 3 段階パイプラインを採用しています：

ステージ 1：マグニチュード閾値処理（ノイズ除去）

生の差分 $\delta$ には、有用な推論信号とノイズの両方が含まれています。CRANE は、低信頼度の座標を除去するために保守的なスパース化ルールを適用します。

• メカニズム：決定論的な中央値マグニチュード閾値が適用されます。$|\delta|$ の中央値未満のマグニチュードを持つ座標はゼロに設定されます。
• 再スケーリング：残りの非ゼロエントリは、全体的な更新スケールを概ね保持するために 2 倍にスケーリングされます。
• 目的：意味のある推論に寄与せずにエージェントインターフェースを乱す可能性のある低マグニチュードノイズを破棄することです。

ステージ 2：保守的テイラーゲート（CTG）

このステージは、特定の編集方向が推論転送とツール使用の保持の両方に有益かどうかを評価することで、各パラメータブロック（レイヤーとコンポーネント）への注入強度を決定します。

• 較正：小さな較正セットを使用して 2 つのマスク付き損失関数が定義されます：
  • $L_R$（推論）：シンキングモデルによって生成されたコード推論プロンプトのパフォーマンスを測定します。
  • $L_A$（エージェント行動）：インストラクトモデルによって生成されたツール使用プロンプトのパフォーマンスを測定します。
• スコアリング：各座標 $j$ について、一次改善スコアは $s_K(j) = -g_{K,j}\delta_j$ として計算されます。ここで $g_K$ は損失の勾配です。
• ゲート論理：座標は、編集が両方の損失に対して同時に降下方向である場合にのみ正の重みを受け取ります：
  $$p_j = [\min\{s_R(j), s_A(j)\}]_+$$
• 集約：重みはブロックごとに集約され、参照 FFN/エキスパートブロックに対して正規化され、最終的なスケーリング係数 $S_{\text{CTG}}(c, l)$ を決定します。

ステージ 3：段階的シグモイド投影（GSP）

有益な編集であっても、重要な形式トークン（ツールの区切り文字、JSON スキーマ、チャットテンプレートなど）を乱す可能性があります。このステージは、「形式クリティカル」部分空間における更新を抑制します。

• 活性化の収集：形式クリティカルなトレース（ツール呼び出しとスキーマを制御するトークン）に対するインストラクトモデルから隠れ状態が収集されます。
• SVD 投影：活性化行列に対して特異値分解（SVD）が実行されます。高い特異値を持つ方向は、形式クリティカルな出力に強く影響を与える入力方向に対応します。
• ソフトマスキング：ハードなヌル空間投影の代わりに、特異値空間にシグモイドマスクが適用されます。高振幅（形式クリティカル）の方向は大幅に減衰され、低振幅の方向は保持されます。これにより、不連続なカットオフではなく、滑らかな遷移が保証されます。

最終的なマージモデルは以下のように計算されます：
$$\theta_{\text{merged}} = \theta_{\text{inst}} + \Pi_{\text{GSP}} \left( \alpha \cdot S_{\text{CTG}} \cdot T(\delta) \right)$$

3. 主要な貢献

1. 方向性マージ定式化：対になったインストラクト/シンキングモデル向けのモデルマージに対する新規アプローチ。差分を対称的なターゲットではなく、特定のエージェント行動に条件付けられた候補編集プールとして扱う。
2. CRANE レシピ：スパース差分抽出、ツール使用を考慮した保守的テイラーゲート、形式保持型の段階的シグモイド投影を組み合わせた 3 段階のトレーニングフリーパイプライン。
3. 実証的評価：3 つのベンチマーク（Roo-Eval、SWE-bench-Verified、Terminal-Bench v2）と 2 つのモデルスケール（Qwen3-30B-A3B および Qwen3-Next-80B-A3B）にわたる包括的な評価。
4. アブレーション研究：各コンポーネント（スパース化器、テイラーゲート、投影）が観測されたパフォーマンスとコストのトレードオフに必要であることを確認する分析。

4. 実験結果

CRANE は、すべてのベンチマークにおいて、個別のエンドポイントおよび標準的なマージベースライン（Task Arithmetic、TIES、SLERP、AIM、LEWIS、RAIN）を常に凌駕し、かつ効率性を維持しています。

• Roo-Eval（IDE ベースのコーディング）：

  • 30B スケール：66.2% の pass@1 を達成。インストラクトベースライン（46.7%）より +19.5%、最良の代替マージより +19.0% の改善。
  • 80B スケール：81.5% の pass@1 を達成。インストラクトより +8.7% の改善。
  • 効率性：CRANE はインストラクトベースラインよりも低い総トークン数（TTC）でこれらの改善を達成し、30B では約 6000 万トークンの使用量を削減しました。

• SWE-bench-Verified（リポジトリレベルの課題）：

  • 30B スケール：122/500 のインスタンスを解決。インストラクトベースライン（108）および最良のマージベースライン（113）を上回りました。
  • 80B スケール：180/500 のインスタンスを解決。インストラクト（168）および他のすべてのベースラインを凌駕しました。
  • 効率性：CRANE は、ベースラインよりも低い集約トークンコストでより多くのインスタンスを解決しました。

• Terminal-Bench v2（シェル/コマンドラインワークフロー）：

  • 30B スケール：pass@1 を 7.6%（インストラクト 4.8% 対比）に、pass@5 を 17.9% に改善。
  • 80B スケール：pass@1 を 14.8% に、pass@5 を 30.3% に改善。
  • 効率性：CRANE は高い成功率を維持しながら、壁掛け時間を大幅に短縮しました（例：80B でのインストラクト 2 時間 28 分対比 1 時間 58 分）。

アブレーションの知見：単一のコンポーネント（マグニチュード閾値処理、テイラーゲート、または GSP）のいずれかを除去すると、パフォーマンスが大幅に低下しました。特に、GSP を除去すると成功率が最も大きく低下し、形式クリティカルな方向を保持することの重要性が浮き彫りになりました。

5. 意義と主張

本論文は、CRANE がコードエージェントにおけるインストラクトとシンキングのチェックポイントの「相補的だが不一致な」性質を成功裡に解決したと主張しています。マージを汎用的な融合ではなく行動条件付きの方向性編集問題として扱うことで、CRANE はインストラクトモデルのツール規律と効率性を犠牲にすることなく、シンキングモデルの計画および回復能力を注入します。

著者は、これらの改善がトークン予算の増加やより長いロールアウトによって購入されたものではないことを強調しています。実際、CRANE はより少ないトークンと短い壁掛け時間で優れた結果を達成することが多いです。この手法は、推論モデルの強みを活用しつつ、デプロイ済みエージェントプロトコルの制約を厳密に遵守することで、エージェントのパフォーマンスを向上させる実用的なトレーニングフリーの道筋を提供します。

認められた限界：

• この手法は、シンキングチェックポイントが有用な推論を提供し、インストラクトチェックポイントが有用なインターフェースを提供することを前提としています。将来のモデルがすでに両方で優れている場合、単純なマージで十分かもしれません。
• 較正セットはデプロイされたツールの表面を網羅している必要があります。ツールや形式に大きなドリフトが生じた場合は、再較正が必要です。
• GSP プロジェクタの構築には形式トレースでのフォワードパスが必要であり、非常に大規模なモデルでは計算コストがかかる可能性があります。
• 特定の言語（Java、Rust）のパフォーマンスは、Python/JS/Go よりも低いままです。これはマージ手法自体の失敗ではなく、ベースモデルにおける潜在的なトレーニングの非対称性を示唆しています。