Piのコンパクション：会話履歴を圧縮してコンテキストを延命する仕組み

ローカルLLMを1つだけ実行している場合、コンパクションは苦痛です。それを避ける最善の方法は、コンテキストをできるだけ小さく保つことです。

私が有用だと思うトリックの1つは、2つのKVキャッシュを持つ1つのモデルを実行し、最初のキャッシュがトークンを生成している間に、2番目のキャッシュが入力トークンが生成されている間（ツール実行中）にそれらを即座に要約し、その後、ハーネスが2番目のKVキャッシュに切り替えて、新しく生成された入力トークンを受け取り、最初のキャッシュのKVは要約されたトークンに置き換えられるというものです。これは一種のピンポンであり、より多くのスペースと引き換えに時間を節約します。まだ実験中ですが、うまく機能しているように見え、GPU使用率が向上するという素晴らしいボーナスもあります。ちなみに、私は独自のハーネスとモデルサービングコードを持っていますが、これは他のハーネスやモデルサーバーでも簡単に実装できます。

私の経験では、コンパクションの最善のアプローチは、そもそもコンパクションが必要になる状況に陥らないようにし、一般的にコンテキストウィンドウの使用率を約30%未満に保つことです。長いエージェントワークフローでも、これはかなり長い間達成可能であり、多くの人が考えるよりもはるかに長く持続します。

各セッションで私が行っていることは次のとおりです：

1. 脇道やトピック外の作業、またはセッション内で既に完了した反復作業については、後方に分岐（/treeを使用）して要約します。

2. 30%を超えた場合、または「価格が2倍になる」マルチティア価格設定に達した場合は、剪定（/prune）します（私のカスタム拡張機能）。

3. 既に剪定したのにまだ30%に近い場合は、「すべて剪定」（/prune-all）します（より広範囲な剪定）。

定義：

'/prune'：新しいセッションでコンテキストの約50%を削除します（以前に剪定されていない場合）

- 保持：ユーザーメッセージ、通常のアシスタント散文、コマンド/ステータスマーカー、拡張機能のレシート、モデル設定、各ツール呼び出しのプレーンテキストのレシート。

- 削除：思考、署名、実際のツール呼び出し/結果、ツール出力、画像、コンパクションの要約、その他の拡張機能の状態。

'/prune-extended'：新しいセッションでコンテキストの約80%を削除します

- 保持：ユーザーメッセージ、通常のアシスタント散文と結論、コマンド/ステータスマーカー、拡張機能のレシート、モデル設定。

- 削除：思考、署名、すべてのツール呼び出し/結果と出力、画像、コンパクションの要約、その他の拡張機能の状態、および/pruneによって作成されたツールアクティビティのレシート。

両方とも新しいセッションを作成し、正常に切り替わった後に古いセッションを削除します。これらを使用することで、私は…

プロンプトキャッシュの仕組みは、より創造的なコンパクション技術を本当に妨げていると思います。例えば、ツールの結果や思考トレースを使用後にポインタに置き換えるような、何らかのヒューリスティックな段階的コンパクションが、モデルをより長く賢く保つ可能性がありますが、それは毎ターン、場合によってはターン内でもキャッシュを壊すことを意味し、コストを大幅に増加させるでしょう。

コンパクションに関する現在の解決策はどれも好きではありません。正確に何を要約すべきかを指定できる方法が欲しいです。なぜなら、ほとんどの場合、ノイズの多いMCPツール呼び出しやテスト実行などをコンパクトにしたいだけだからです。何を要約するかを選択させて、残りはそのままにしておいてほしいです。