Supermavenの100万トークンBabbleアーキテクチャはなぜRAGチャンク遅延なしにコードベース全体をインライン補完できるのか

コードのインライン補完（Inline Completion）において、レイテンシはツールの実用性を左右する決定的な要素です。開発者がエディタ上でキーを入力したり思考のために指を止めたりした際、思考の中断（コンテキストスイッチ）を防いで「フロー状態」を維持するためには、補完候補が250〜300ミリ秒未満で画面上に提示されなければなりません。応答が700〜1,000ミリ秒を超えてしまうと、AIは思考を加速させる存在ではなく、タイピングのリズムを乱すボトルネックへと変わってしまいます。

複数ファイルにまたがるコードベース全体の文脈を把握するため、初期のAIコーディングアシスタントは検索拡張生成（RAG: Retrieval-Augmented Generation）に依存していました。しかし、従来のRAG方式には深刻なトレードオフがつきまといます。ベクトル検索、関連性スコアリング、プロンプトの再構成に数百ミリ秒もの時間を要するうえ、機械的なコードのチャンク分割（チャンキング）によってファイル間の型定義やインターフェース契約、共通ヘルパー関数が分断されてしまう問題です。

Tabnineの生みの親であるJacob Jackson氏が開発したSupermavenは、独自のニューラルネットワークアーキテクチャBabbleと、ネイティブ100万トークン（1-Million-Token）のコンテキストウィンドウによってこの課題を解決しました。キー入力のたびにコードを動的に分割・検索するのではなく、リポジトリ全体をメモリ空間に直接展開した状態で保持し、約250ミリ秒という超低遅延でプロジェクト全体を踏まえたインライン補完を実現しています。

コード補完における従来のRAG方式の限界

Supermavenがなぜ独自のモデル構造を開発するに至ったかを理解するには、一般的なRAGパイプラインがリアルタイムなプログラミング環境で直面する技術的制約を整理する必要があります。

従来のRAGベースの補完エンジンは、キー入力のたびに以下の段階を踏んで処理を行います。

[キー入力トリガー]
       │
       ▼
1. ローカルコンテキストの抽出（カーソル周辺のコード、編集中のファイルの断片）
       │
       ▼
2. ベクトルおよびキーワード検索（クエリ埋め込み生成、ベクトルDBでのANN探索）
       │
       ▼
3. チャンクのスコアリングと絞り込み（上位K件のコードスニペットを選定）
       │
       ▼
4. プロンプトの組み立て（取得したチャンクを4k〜8kの小さなコンテキスト枠に注入）
       │
       ▼
5. LLM推論の実行（補完候補のトークン生成）

チャット形式のUIであれば、検索処理に500ミリ秒余分にかかってもユーザーはほとんど気になりません。しかし、1秒間に何度もキーを入力するインライン補完では、この多段階処理が致命的な遅延と精度の劣化を引き起こします。

1. 多段階検索による累積遅延

RAGの各プロセスには物理的な計算時間がかかります。カーソル位置のスニペットを埋め込みベクトルに変換し、数万単位のインデックスから近傍探索（ANN）を行い、取得結果をリランキングする一連の処理だけで100〜400ミリ秒を消費します。この検索が完了して初めてモデルの生成処理が開始されるため、従来のコパイロット系ツールでは全体のレイテンシが700〜900ミリ秒、場合によってはそれ以上に達してしまいます。

2. チャンク分割による抽象構文木（AST）と依存関係の破壊

自然言語の文書であれば、300単語程度で段落を分割しても要意を保てる場合が多いですが、ソースコードは高度に相互接続された抽象構文木（AST）および依存グラフで成り立っています。

• service.ts 内の関数実装は、types.ts で定義された複雑なジェネリクス型インターフェースに依存しています。
• routes.py のハンドラー処理は、config.py 内のグローバル設定辞書によって厳格に規定されています。
• ディレクトリを越えて呼び出される共通マクロやユーティリティ関数は、階層の深いモジュールに配置されていることが一般的です。

コードを固定サイズで機械的にスライスすると、こうしたファイル間の論理的結合が断ち切られます。もし埋め込みモデルがカーソル位置と離れた場所にある型定義との意味的類似度を捉えきれなかった場合、そのコードブロックはプロンプトから除外されます。その結果、モデルは存在しないメソッド名を捏造したり、シグネチャの不一致を起こしたり、コンパイルの通らないコードを生成してしまいます。

Babbleの内部構造：標準Transformerの限界と新アーキテクチャ

RAGの弱点を根本的に克服するアプローチは、コンテキストウィンドウを大幅に拡大してコードベース全体を直接プロンプトに収めることです。しかし、標準的なTransformerアーキテクチャでは、計算コストと応答速度の面でこれを実現することは極めて困難でした。

標準的な自己注意機構（Self-Attention）の壁

標準的なTransformerのマルチヘッド・アテンション計算は、プロンプトの読み込み時にシーケンス長に対して2乗の計算量（$O(N^2)$）を要し、Key-Value（KV）キャッシュのメモリ消費量はトークン数に比例して線形に肥大化します。仮に100万トークンをそのまま処理しようとした場合：

• 80億パラメータ規模の一般的なモデルであっても、開発者1セッションあたりのKVキャッシュだけで数十GBのVRAMを占有します。
• 1回のキー入力ごとに100万トークン全体のアテンションを再計算すると、推論レイテンシは秒単位、あるいは数十秒へと跳ね上がり、インライン補完としての実用性を完全に失います。

Babbleアーキテクチャのブレークスルー

Babbleは、コードシーケンスのモデリングと超低遅延推論のためにゼロから設計された独自のニューラルネットワークです。標準Transformerのスケール限界を以下の3つのアプローチで打破しています。

1. サブクアドラティック（準線形）なコンテキスト統合： Babbleは、全トークン間を総当たりで結合する密なアテンションではなく、状態空間モデル（SSM）や高効率な再帰機構を着想源としたシーケンス処理方式を採用しています。これにより、100万トークンに及ぶ広範な文脈を、従来の4,000トークン規模のTransformerと同等の計算負荷およびレイテンシで処理可能にしました。
2. 極小のメモリフットプリント： 巨大なKVキャッシュを必要としない構造をとることで、長文コンテキストの保持に伴うハードウェアメモリの消費を劇的に圧縮しました。これにより、サーバー側で多数の高頻度リクエストを並行して処理できる経済性を確立しています。
3. 静的ファイルではなく「編集シーケンス（Edit Sequences）」による学習： 従来のモデルの多くがGitHub上の静的な完成ファイルスナップショットを学習データとしているのに対し、Babbleはgit diffのような開発者の編集履歴や変更ストリームを用いて学習されています。そのため、コードの最終的な構造だけでなく、リファクタリングや型定義の拡張、機能追加の際に人間がどのような思考プロセスで変更を加えるかをモデルが内在的に把握しています。

リポジトリ取り込みの仕組み：250msのインライン推論を実現するパイプライン

Supermavenが100万トークンの巨大な文脈を抱えながら250ミリ秒という超高速応答を維持できる理由は、コードベース全体の事前取り込みとキー入力時の推論を完全に分離している点にあります。

[プロジェクトを開く] ──► 10〜20秒の1回限りのバックグラウンド処理 ──► サーバー側で計算済み状態をキャッシュ
                                                                         │
[開発者がキーを入力] ────────────────────────────────────────────────────┴──► 差分のみの増量前向き推論（≤ 250ms）

初回の事前計算フェーズ

開発者がVS Code、JetBrains、Neovimなどでプロジェクトを開くと、Supermavenの軽量クライアントがローカルリポジトリを非同期に走査します。最初の10〜20秒間で最大100万トークン分のコードがサーバーへ送られ、長大コンテキストの計算済み状態がキャッシュ（Prefix Caching）として確立されます。

この処理はバックグラウンドで静かに完了するため、エディタの操作がブロックされることはありません。一度この処理が完了すれば、モデルはプロジェクト内の全API、データ構造、命名規則を完全に把握した状態になります。

キー入力ごとの差分推論

開発者がコードの入力を開始した際：

1. 動的検索の完全排除： ベクトル埋め込みの計算、類似度検索、チャンクの並び替えは一切行われません。
2. キャッシュ状態の再利用： エディタ上で編集中の最新バッファと差分トークンのみを、サーバー上の計算済みコードベース状態に対して差分適用します。
3. 即時の補完表示： 画面上でキーが入力されてから補完候補がレンダリングされるまでのフレームレート測定において、Supermavenは約250ミリ秒（15フレーム）を記録し、競合ツールを大きく引き離しました。

実証実験：100万トークンのコンテキストは本当に機能しているのか？

超長大コンテキストを扱うモデルでは、先頭と末尾の情報しか参照できず中間部分を忘れてしまう「Lost in the Middle」現象や、不要なコードノイズによって予測精度が落ちるリスクが懸念されます。

SupermavenはBabbleの有効性を検証するため、厳格なベンチマーク測定を実施しました。

1. ニードル・イン・ア・ヘイスタック（Needle in a Haystack）試験

合成テストとして、ランダムに生成した8文字のキー・バリュ対（例: // needle: vhmpphtv => 'oualsoki'）を、5万〜100万トークンのコードベースの様々な深さに埋め込みました。

• 結果： Babbleは、埋め込まれた位置が全体の10%であれ、50%であれ、90%であれ、100万トークンの全域において100%の回収率（Recall）を達成しました。

2. 密集キー・バリュー検索（Dense Retrieval）

目立つコメントを1箇所に埋め込むニードル試験よりも難易度が高いテストとして、30万トークンにおよぶ連続コード内に無数のアサーション文を配置しました。

assert obj['tvdiqaac'] == 'm'
assert obj['qacbblfk'] == 'c'
# 数万〜数十万トークンの間隔...
assert obj['tvdiqaac'] == 'm'

再度出現したキーに対する値を補完させるタスクにおいて、Babbleはトークン間の隔たりが非常に大きい場合でも75%〜100%の高い精度を維持し、長期にわたって変数のマッピング関係を記憶できることを実証しました。

3. コンテキスト長と予測誤差の推移

長大なコンテキストが実際の開発環境で補完精度を向上させるかを評価するため、公式のPyTorchリポジトリ全体（200通り以上のファイル順序で平均化）を用いて次のトークンの予測誤差（Prediction Loss）を測定しました。

• 結果： コンテキスト長が数千トークンから100万トークンへと拡大するにつれ、予測誤差は滑らかに単調減少し続けました。Babbleがプロジェクト内のコードをノイズとして散逸させることなく、有益な文脈情報として活用していることが示されました。

アーキテクチャ比較：ネイティブ100万コンテキスト vs 従来型RAG

技術の進化と業界へのインパクト

2024年11月、Cursorの開発元であるAnysphere社がSupermavenを買収しました。Cursorは、マルチファイルを自律操作するAgent用途にはフロンティアモデルが優れている一方、毎秒打鍵されるTabキーによるインライン補完には、極限まで最適化された専用シーケンスモデルと推論パイプラインが不可欠であることを認識していました。

Supermavenの中核技術と超低遅延・長文コンテキストのノウハウは、そのままCursor Tabへと統合されました。CursorのAST解析機能とBabbleの高速推論が融合したことで、補完性能はさらに進化を遂げました。これに伴い、Supermavenは2025年11月に単独商用サービスの終了（Sunsetting）を発表し、既存のNeovimおよびJetBrainsユーザーに対して無償で推論環境を提供しつつ、VS CodeユーザーにはCursorへの移行を推奨しています。

まとめ

SupermavenのBabbleアーキテクチャは、AI開発ツールにおける重要な設計原則を示しました。インラインコード補完のように極めて厳しい低遅延が求められる領域では、多段階のRAGパイプラインを組むよりも、長大なネイティブコンテキストを備えた軽量な専用シーケンスモデルを用いる方が圧倒的に優れた結果を生むということです。チャンク分割による情報の欠落とベクトル検索の遅延ペナルティを排除したBabbleは、プロジェクト全体の文脈把握と瞬時の応答性を両立できることを実証しました。

参考文献

• Introducing Supermaven, the first code completion tool with a 300,000-token context window
• Benchmarking Supermaven's Long-Context Capabilities
• Announcing Supermaven 1.0
• Supermaven joins Cursor
• Sunsetting Supermaven