【仕組み解説】Piにおけるコンパクション（Compaction）の内部構造とは？

Piにおけるデータ管理の要、「コンパクション」がどのように動作しているのかを分かりやすく解説します。ストレージ効率を高め、パフォーマンスを最適化するための重要なプロセスについてまとめました。

ローカルLLMを使ってると、コンパクション（圧縮）は結構悩みの種なんだよね。現在のコンテキストを破棄して128k近いコンテキストをパースし、さらに5〜10kのトークンを生成するなんて、10t/s〜45t/s（モデルによるけど）の環境だとかなり時間がかかる。だから自分は、コンテキストが一杯になったらすぐに新しいセッションを開始するようにしてる。

ローカル環境で動かす利点は、推論の最中にコンパクションを実行できることかな。例えば、ツール呼び出しでコンテキストが溢れそうなとき、推論を一時停止して、GPU上で直接トークンを操作して古いツール呼び出しを要約やログに置き換えたり削除したりできる。KVキャッシュを再構築して（プリフィルのオーバーヘッドは一回発生するけど）推論を再開すれば、例えば50kのマークダウンファイル1000個を一度のLLM呼び出しで読み込むようなことも簡単にできる。LLMのAPI呼び出しに依存する現在のエージェント用ハーネスでは不可能な芸当だよ。

ローカルLLMを一つだけ動かしているとコンパクションは面倒だよね。一番の回避策は、できるだけコンテキストを小さく保つこと。自分が便利だと思うコツは、一つのモデルで2つのKVキャッシュを動かすやり方。最初のキャッシュでトークンを生成している間に、入力トークンが生成されている（ツール実行時間などの）隙間を使って、もう一方のキャッシュで裏で要約処理を行う。で、ハーネス側は新しいKVキャッシュに切り替えて、最初のKVキャッシュを要約済みのトークンで置き換える。いわばピンポン方式で、時間短縮のためにメモリ空間を犠牲にする感じだね。まだ試行錯誤中だけどかなりうまくいってるし、GPU使用率が上がるという嬉しいオマケもある。まあ自分用のハーネスとモデルサービングコードを使ってるけど、他のハーネスやモデルサーバーでも簡単に実装できるはず。

今のところコンパクションに関する既存の解決策はどれも好きじゃないな。どこをどう要約するか細かく指定できるようにしてほしい。だいたいの場合、MCPツールのノイズの多い呼び出しやテストの実行ログなんかを圧縮したいだけなんだよね。要約したい箇所を自分で選べて、それ以外はそのまま残せるような仕組みが理想。

記事でもう少し踏み込んだ解説があるかと期待してたんだけどな。
例えば、要約の連鎖が長くなりすぎて、それ自体がコンテキストウィンドウを溢れさせてしまったらどうなるんだろう？要約の結果に対してさらに要約をかけるような運用になるのかな？

コンパクションじゃなくて、「プルーニング（剪定）」をうまく実装できた人っている？エージェントが会話履歴を見て、価値の低いメッセージを削除していくっていうアプローチだけど。
例えば、本筋から逸れた話やツール呼び出しの出力、価値の低いコードベースの探索なんかでコンテキストが埋まってしまうことがあるからさ。
多くの場面で、自分は要約するより会話の履歴をそのまま残したい派なんだよね。要約された会話だとLLMが意図やコンテキストを見失って、後のチャットがイライラする展開になりがちだから（あるいは、要約された段落が続くと、次のトークン予測の精度が落ちるのかも？よくわからないけど）。

OMPがデフォルトのコンパクションを「画像」に変更したらしいよ！正直かなりぶっ飛んでるよね。従来のコンパクション処理でかかる生成コストを節約するために、コンテキストを小さな文字として画像に書き込んでるらしいんだけど、ちゃんと理解できてるかな？

プロンプトキャッシングの仕組みのせいで、より創造的なコンパクション技術が阻害されてる気がする。例えば、ツール結果や思考プロセスを使った後に、それらをポインターに置き換えるような進歩的なヒューリスティック・コンパクションがあればモデルの賢さを長く維持できるかもしれない。でもそれだと毎ターン、あるいはターン内でさえキャッシュが無効化されて、コストが跳ね上がるよね。

コンパクションのたびにKVキャッシュを丸ごと捨てるのは好きじゃないな。会話全体のキャッシュミスを誘発するから、時間もコストも無駄だよ。
LLM自体、新しいシステムプロンプトなんて必要なくたって、会話の要約くらい完璧にこなせる能力はあるはずなんだけどね。