私たちは、自己要約と呼ばれる強化学習プロセスを通じて、長いホライズンのタスクに対応できるよう Composer を学習させています。自己要約を Composer の学習に組み込むことで、モデルの最大コンテキストウィンドウを大幅に超える軌跡から学習シグナルを得られます。これにより、Composer は数百回のアクションを要する困難なコーディングタスクにも取り組めるようになります。

#コンパクション手法の限界

社内ベンチマークスイートであるCursorBenchにおいて、私たちは、難易度の高い実世界のタスクでのより高い性能が、より多くの思考とコードベースの探索に直接相関していることを確認しています。ユーザーがエージェントと協力して、より難しく、より意欲的なタスクに取り組むようになるほど、思考と探索の効果はさらに高まると考えられます。

ただし、主な課題は、エージェントの軌跡がモデルのコンテキスト長よりも速いペースで拡大していることです。多くのエージェントハーネスは、エージェントのワークフローにおける中間ステップとしてコンパクションを使うことで、これに対処しようとしています。エージェントがコンテキスト制限に達すると、ハーネスはコンテキストをより短く変換し、中断した地点からエージェントの生成を続けます。

実際には、コンパクションは通常、ハーネスによって次の2つの方法のいずれかで処理されます。1つは、プロンプトで要約を行うモデルを使ってテキスト空間で処理する方法、もう1つは、モデルが古いコンテキストを削除するスライディングコンテキストウィンドウによる方法です。研究者たちは、潜在空間におけるコンパクション手法の探究も始めています。これは、モデルがコンテキストをテキストではなくベクトルとして記憶する方法ですが、現時点ではこうしたアプローチはテキストベースの手法よりも大幅に低速です。

こうしたコンパクション手法に共通する欠点は、コンテキスト内の重要な情報をモデルが忘れてしまう可能性があり、その結果、長時間にわたるタスクを進めるにつれて有効性が低下することです。

#学習された挙動としての自己要約

Composer は、エージェント型コーディング向けに設計された特化型のモデルで、Cursor のエージェントハーネス内で強化学習によって学習されています。これにより、compaction-in-the-loop を組み込んだ形で学習でき、要約して保持すべき最も重要な情報を見極める能力が向上します。

Composer はタスクを進める中で、固定のコンテキスト長のしきい値に近づくと、一度処理を止めて自身のコンテキストを要約してから続行します。より正確には、自己要約のプロセスは次のように機能します。

1. Composer は、固定のトークン長のしきい値に達するまで、プロンプトから生成を行います。

2. モデルに現在のコンテキストを要約するよう求める合成クエリを挿入します。

3. モデルには最適な要約を考えるための思考用スペースが与えられ、その後、要約されたコンテキストを生成します。

4. Composer は、要約に加えて会話の状態 (プランの状態、残りのタスク、これまでの要約回数など) を含む要約済みコンテキストを使って、手順 1 に戻ります。

Composer が推論時にもこれをうまく実行できるようにするため、学習にも同じ要約手順を組み込んでいます。各学習ロールアウトには、単一のプロンプトと応答のペアではなく、要約でつながれた複数の生成が含まれることがあります。つまり、自己要約そのものも報酬の対象になります。

技術的な観点では、これにあたって学習に大きな変更は必要ありません。連鎖内でモデルが生成したすべてのトークンに対して、最終報酬を適用します。これにより、良い軌跡におけるエージェントの応答だけでなく、それを成立させた自己要約にもより大きな重みが与えられます。同時に、重要な情報を落としてしまった不十分な要約の重みは下げられます。Composer は学習が進むにつれて、この自己要約プロセスを使ってより長いコンテキストを構築することを学びます。難しい例では、複数回にわたって自己要約することもよくあります。

#トークン効率の高い圧縮

自己要約を検証するために、これを高度に調整されたプロンプトベースの圧縮ベースラインと比較します。圧縮のトリガーを変化させながら、難易度の高いソフトウェアエンジニアリングのタスク群でこの問題を検証します。

ベースラインの圧縮手法では、要約用プロンプトは数千トークンに及び、要約に保持すべき内容を説明する、慎重に設計された10近いセクションが含まれています。出力される圧縮済みコンテキストも平均で5,000トークンを超え、コンテキスト内の重要な情報を説明する構造化されたセクションを多数含みます。

一方、Composer は自己要約するように訓練されているため、必要なのは「会話を要約してください」という内容を少し超える程度の、ごく短いプロンプトだけです。出力される要約は平均で約1,000トークンにとどまります。これは、残すべき価値の高い情報を文脈に応じて判断することを学習しているためです。

自己要約の影響を測定するために、Composer をコンテキスト制約のある2つのテスト環境で検証しました。1つは80kトークンでトリガーされる環境、もう1つは40kトークンでトリガーされる環境です (こちらは要約がより頻繁に行われることを意味します) 。どちらのシナリオでも、自己要約は、はるかにトークン効率の高い圧縮によって、CursorBench において大幅に優れた結果を生み出します。対象を絞ったベースライン手法と比べても、圧縮による誤差を一貫して50%削減しながら、トークン使用量は5分の1で済み、KVキャッシュ (以前のトークンから保存された中間計算結果) も再利用できます。

#難しい問題を解く

コンパクションのより大きな可能性は、長い推論チェーンを必要とする難問をモデルが一発で解けるようにすることです。現在の Composer 2 の学習では、それがしばしば起きているのを確認しています。ケーススタディとして、Terminal-Bench 2.0 の make-doom-for-mips として知られる問題を取り上げます。この問題は簡潔でありながら、非常に難しいものです。

/app/doomgeneric/ に doom のソースコードを用意してあります。さらに、描画された各フレームを /tmp/frame.bmp に書き出す、使ってほしい特別な doomgeneric_img.c も作成してあります。最後に、doomgeneric_mips という名前のファイルを想定して実行する vm.js も用意しました。あとは残りを何とかしてください……

説明するのは簡単ですが、この問題は非常に難しく、強力なモデルのいくつかでも、公式に報告されている結果では正しく解けていません。

Composer の初期研究チェックポイントをテストしたところ、この問題を正しく解けることがわかりました。その解法には、かなりの量のコードを実装してテストすることに加え、いくつかの代替実装を試すことも必要でした。以下は、この問題を解く過程でレンダリングされた画像です。

最終的に、Composer は正確な解法を見つけるまでに 170 ターン費やし、その過程で簡潔で、人間が読める構造化された形式の自己要約を作成しました。10 万を超えるトークンを、問題解決に最も役立つと判断した 1,000 トークンまで自己要約しました。

#長いホライズンの未来に向けて

コンパクションを学習ループに組み込むことで、Composerは重要な情報を効率的に先へ引き継ぐための明示的な仕組みを学習し、困難なタスクに対してより高い能力を発揮できるようになります。自己要約に関する私たちの取り組みは、マルチエージェント連携のような、さらに長く複雑なプロセスでもComposerを学習させるという、より大きな目標に向けた一歩です。モデルの学習が進むほど、これらのエージェント型システムの適用範囲と知能が向上していくことを、私たちは引き続き確認しています。

Composerの次のバージョンについても、まもなくさらに詳しくお伝えします。