OpenHands のブログに掲載されたこの記事は、OpenHands のコンテキストコンデンサーを紹介している。記事はこれを、増え続ける会話のコンテキストを管理することを目的とした OpenHands のエージェントアーキテクチャの進歩として示している。出発点は、長く複雑なタスクでエージェントを動かしたことのある人なら誰でもよく知っている問題である。会話が長くなるにつれて、エージェントは遅くなり、ターンあたりのコストが高くなり、効果も下がっていく。LLM は、コンテキストに無関係な情報が大量に含まれていると性能が落ちるからである。新しいチャットを始めればこれを避けられるが、継続性が失われ、ユーザーがセッションをまたいでコンテキストを手作業で引き継がなければならなくなる。
コンデンサーは、代わりに会話の大きさを一定の範囲内に保つ。会話がしきい値を超えて大きくなると、直近のやり取りはそのまま残しつつ、それより古いやり取りを要約する。これにより、エージェントはすべての詳細を保持することなく、それ以前に起きたことについての簡潔な「記憶」を持てる。記事は 3 つの成果を大きく掲げている。ターンあたりの API コストが最大 2 分の 1 に下がること、長いセッションでも応答時間が一定に保たれること、そしてソフトウェアエンジニアリングのタスクで同等かそれ以上の性能を発揮することである。
要点
- 要約は、ユーザーの目標、エージェントがここまでに達成した進捗、そしてまだやるべきことを表すように作られる。ソフトウェア開発のタスクでは、重要なファイルや失敗しているテストといった技術的な詳細も保持する。
- 凝縮はコンテキストが特定のサイズに達したときにだけ実行される。記事によれば、これによりキャッシュの再構築にかかるコストを複数のターンにわたって償却でき、プロンプトキャッシュの利点が保たれる。
- 記事の主張によれば、イベントのサイズが同程度である場合、凝縮を行わないベースラインのコンテキスト管理は時間とともに 2 乗で増加するのに対し、凝縮を用いるアプローチは線形に増加する。
- SWE-bench Verified のインスタンスのサブセットで、ベースラインの OpenHands エージェントと比較評価したところ、ターンあたりの平均コストは凝縮が始まった時点からベースラインと差が開き、最終的にベースラインの半分未満に落ち着いた。
- そのサブセットにおいて、凝縮を行うエージェントは平均 54% のインスタンスを解決し、ベースラインは 53% だった。また、より少ない費用、より少ないトークン、より短い完了時間で、より多くの割合のインスタンスを解決した。記事は、これらの傾向は選んだ区切り値にかかわらず成り立つと述べている。
- 報告されている唯一のトレードオフはターン数の増加であり、記事はこれを、エージェントがときどきコンテキストを凝縮するためにターンを 1 回必要とするためだとしている。
- これらの結果はすべて、機能を発表する記事の中で報告された、OpenHands 自身による自社エージェントの評価に基づくものである。
背景
記事はコンデンサーを、すでに提供されている機能として位置づけている。コンテキストの凝縮は OpenHands で利用可能であり、マネージド版の OpenHands Cloud でも、すぐに使える状態にあると説明されている。記事は要約に基づく凝縮を、新しいチャットを始めることの代替策として位置づけ、長いコンテキストによって損なわれる 3 つのものとしてコスト、レイテンシ、有効性を挙げている。エージェントの履歴が上限に近づいたときにそれを要約する他のアプローチについては、コンパクション を参照のこと。