GPT-4o のようなフロンティアモデルは、大規模な編集では、怠惰による手抜き、不正確さ、そして高いレイテンシといった問題が生じがちです。

これはコーディングエージェントに見られる弱点です。
数百行を正確に編集するには複数回のモデル呼び出しが必要となり、場合によってはエージェントが無限ループに陥ることがあります。小さな局所的な修正でさえバグが発生しがちです。

何より厄介なのは、既存のモデルは大規模な編集が遅く、プログラマーの集中を途切れさせてしまうことです。

私たちは、ファイル全体のコード編集タスクの重要なバリエーションである fast apply に特化したモデルを訓練しました。

難易度の高いコード編集は、計画と適用の2段階に分けられます。

Cursor では、計画段階は高性能な最先端モデルを用いたチャットインターフェースとして行います。
現在のファイルへの変更の適用は簡単で、即座に行えるはずです。

当社の高速適用モデルは GPT-4 および GPT-4o を上回る性能を発揮し、精度とレイテンシのトレードオフ曲線におけるパレート前線を更新します。
コード編集向けに特化した推測デコーディングの派生手法speculative editsを用いることで、70B モデルで約1000トークン**（約3500文字/秒）の速度を実現しています。

これは、Llama-3-70b を用いた標準的な推論に比べて約13倍の高速化、また当社の従来の GPT-4 を用いた推測編集デプロイに比べて約9倍の高速化を意味します。

デフォルトでは、言語モデルは、現在のファイル、会話履歴、そして現在のコードブロックを条件として、ファイル全体を再書き換えた内容を生成します。

本記事では、新しいモデルの学習と評価の方法を説明します。
なぜ差分ではなくファイルを書き直すのか、そして仮編集（speculative edits）によってどのように途方もない高速化が得られるのかをお見せします。

プロンプトを用いたリライトの評価

400行未満のファイルに対する、約450件の全ファイル編集からなる評価セットを作成し、採点者としてClaude-3 Opusを用いて、いくつかのプロンプト指定モデルの性能を測定します。

厳選した数十の例全体で、Opus ベースの採点は、GPT-4-Turbo や GPT-4o よりも当社の評価と高い一致を示します。

これらのスコアは、Claudeモデルの出力に有利に偏っている可能性があります。
ただし、このスコアはモデルに関する私たちの定性的評価とも一致しています。

Claude の高い性能は、ポストトレーニングによる副産物だと考えています。
Claude モデルはアシスタントメッセージ内で数千行のコード（LOC）を出力する一方、GPT-4 はコードを省略し、欠落部分を...やコメントで示します。

GPT-4 の低いパフォーマンスは、無関係な変更に起因する場合もあります。
GPT-4 はコメントアウトされたコードや不要な改行を削除してしまうことがあります。
関係のないコードを「修正／整形」してしまう傾向があります。

速度計測

速度は次のように測定します：

これには次のような利点があります。

1. 異なるトークナイザー間で速度を均一化します
2. さまざまなプロンプト／生成トークン長に対して、重要な指標を単一の数値で示します（TTFT と生成の文字数/秒を両方カウントするのではなく）
3. レイテンシにTTFTが含まれるため、生成速度の下限を堅めに見積もれます。多くのトークナイザーと一般的なテキストでは、1トークンは3〜4文字に相当するため、文字/秒を4で割ればトークン/秒の下限になります。

gpt-4-turbo の推測編集による高速化も加味すると、次のとおりです。

Diffモデル

なぜ差分の提案ではなく、モデルにファイル全体の書き換えをさせるのですか？

言語モデルがdiff形式の編集を苦手とする理由について、いくつかの可能性がわかりました。

少ないトークンで考える - 出力トークンが多いほど、モデルは正解にたどり着くためのフォワードパスをより多く行えます。
Diff は、モデルに少ないトークンで考えさせる仕組みです。

Diffは分布外 -
事前学習、とりわけ後学習の段階では、モデルはコードの差分よりもコードのファイル全体を多く見ている可能性が高い。

行番号の出力 - トークナイザーが数値の並び（例: 123）を単一トークンとして扱う場合、差分用の正しい行番号をどの出力トークン（多くは最初のトークン）に割り当てるかを決める必要があります。さらに、モデルは行番号を数えるのが著しく苦手です。

Aiderのdiff形式に着想を得て、行番号の問題を解消しました。
標準的なdiff形式の代わりに、モデルは検索・置換ブロックとしてdiffハンクを提案します。

diff
@@ ... @@
function binarySearch(arr, x) {
- let low = 0, high = arr.length - 1;
- while (low <= high) {
- let mid = Math.floor((low + high) / 2);
- if (arr[mid] === x) {
- return mid;
- }
- low += 1;
- }
- return -1;
+ let low = 0, high = arr.length - 1;
+ while (low <= high) {
+ let mid = Math.floor((low + high) / 2);
+ if (arr[mid] === x) {
+ return mid;
+ } else if (arr[mid] < x) {
+ low = mid + 1;
+ } else {
+ high = mid - 1;
+ }
+ }
+ return -1;
}

先頭が-またはの行をすべて、先頭が+またはの行に置き換えます。
差分には冗長な-や+が含まれているため、diff 解析システムは軽微なモデルの不具合にも堅牢です。

多くのモデルは正確な差分を出力できませんが、Claude Opus は例外です。

学習

claude-3-opus-diff の apply モデルは gpt-4-turbo-spec よりも高速かつ高精度ですが、それでもなお遅すぎます。

Anthropic のどのモデルにも推測的編集を組み込むことはできないため、高性能なカスタムモデルを訓練してデプロイする必要があります。

シンセティックデータ

まずは、少数の「fast-apply」プロンプトと、豊富な Cmd‑K プロンプトから始めます。

cmd-k プロンプトは、fast-apply に必要なデータにおおよそ対応しています。
編集指示と、現在のファイル内のコード選択を含みます。

各編集指示ごとに、まず現在のファイルをもとに GPT-4 にチャット応答を生成させ、つぎに言語モデルにその変更を「適用」させます。
少量の「実データ」の適用入力を活用して、より高品質な適用データポイントを追加生成します。
最後に、これらのデータセットを80/20の比率で結合し、ファインチューニング用データを作成します。

モデル学習

当社は DeepSeek Coder Instruct と Llama 3 の各モデルファミリーを学習しています。微調整用データセットを高品質化するため、次の取り組みを行っています。

1. 小さなファイル（<100 LOC）は学習データ内で過度に偏っていたため、ダウンサンプリングしています。
2. ファイル名ごとに学習例の数を間引きます。
3. 処理がノーオペレーション（no-op）に終わったデータポイントはダウンサンプリングします。

当社の最良モデル（llama-3-70b-ft）は、claude-3-opus-diffとほぼ同等の性能で、gpt-4-turboやgpt-4oを上回ることが確認できました。

3つのファインチューニング済みモデルはいずれも評価では gpt-4-turbo を上回りましたが、ファインチューニング済みの deepseek-33b と llama-3-70b にははっきりとした違いを感じました。
llama-3-70b は、他のファインチューニング済みモデルや gpt-4-turbo よりも手応えが良好でした。
一方で他のファインチューニング済みモデルは今ひとつで、しばしば GPT-4 より有用性が低いと感じられました。

予測編集

最大の成果は、「speculative edits」と呼ぶ独自の推測デコードアルゴリズムによるものです。
ファイル全体の書き換えと同等の効果を、最大9倍の速度で実現します。

コード編集では、任意の時点で下書きトークンに強い事前情報があるため、ドラフトモデルではなく決定的なアルゴリズムで将来のトークンを推定できます。

私たちはFireworksと協力し、推測的編集に強い高速適用モデルをデプロイしました。
同社は優れた推論エンジンを備えており、当社のカスタム推測ロジックに対応するAPIサポートも実装してくれました。

その結果、推測的編集による効果は GPT-4 より Llama-3 のほうが大きく、次に速いモデルと比べて 4～5 倍の高速化が得られます。

今後の展望

長コンテキスト学習 - 最大2,500行のファイルを書き換えられるよう、長コンテキスト対応の学習に取り組んでいます。
RoPE の位置 ID を素朴に線形スケーリングする手法はうまく機能せず、コミュニティによる Llama 3 70B の長コンテキスト向けファインチューニングでも同様の問題が見られます。

知識蒸留 - 現行モデルが持つ「fast apply（高速適用）」の能力を、より小型のモデル、特に llama-3-8b へ蒸留したいと考えています。
小型モデルの低レイテンシは、ファイルが大きくなるほど重要になります。

さらなる精度向上 - 新たにリリースしたモデルのデータを用いたオンポリシー型強化学習により、追加の性能向上が期待できます。

チャットでの活用を超えて、fast-apply は、より高度なコード生成システムを支える重要な基盤です。
モデルの推論・計画能力が向上するほど、低レイテンシーでの適用のメリットはますます大きくなります！

まだ試していない方は、ぜひ Cursor でこの機能を試してみてください！製品に込められた磨き込みと深みの一端を示す、小さな
例です。

このブログ記事は、Anysphere における応用研究の一端を示す妥当なサンプルです。
私たちは、推測編集のようなアプリケーション固有の推論高速化を実装し、タスク特化型モデルを学習・評価し、これらをユーザーに有用な機能として提供しています。

研究エンジニアおよびソフトウェアエンジニアを募集しています。Anysphere の詳細はこちらをご覧ください。