LLM と長く仕事をしていくうちに、十分なコンテキスト、多すぎるコンテキスト、トークンの無駄遣い、そして圧縮の戦いという永遠の葛藤に巻き込まれることが増えてきた。エージェンティックなメモリシステムに目を向けると、この戦いに役立つ強力な武器がいくつかあることがわかる。
私が調査した 19 のシステムで繰り返し浮かび上がった知見は、ウィンドウを大きくすると予算問題が解消されるどころか、むしろ悪化するということだ。200K トークンのウィンドウだからといって、その 200K トークン全てに均等に注意を払えるわけではない。ウィンドウが埋まるずっと前に、パフォーマンスは低下し始める。この低下は均一ではなく、長いコンテキストの中央部分は端の部分よりも確実に注意が向けられにくくなる。そして、エージェントの実際のタスクは、ウィンドウの大きさに関わらずウィンドウの一定のスライスを占めるため、それ以外のすべてが同じアテンション予算を争うオーバーヘッドとなる。
この問題をうまく処理しているシステムは、6 つのメカニズムに収束している。どれもエキゾチックではない。いくつかは恥ずかしいほどシンプルだ。しかし、これらをスキップしたシステムはその代償を払うことになる。
6 つのメカニズム
圧縮パス
最も目に見えるメカニズムだ。長い会話や大きなメモリセグメントを取得し、それを要約して、オリジナルを要約に置き換える。MemoryOS はこれをセグメントレベルで行っている。会話セグメントが閾値を超えて大きくなると、セグメント要約機能が作動し、ワーキングコンテキストを圧迫する前にコンパクトな表現に圧縮する。Karpathy パターンの wiki（purpose.md、overview.md）は、これを知識レベルで行うバージョンだ。wiki は、エージェントがトピックについて学習したすべての情報をセッションをまたいで維持する、圧縮された形式である。
トレードオフは情報の損失だ。圧縮は定義上、非可逆な操作である。要約は、圧縮時に関連性があると判断されたものをキャプチャする。後になってエージェントが関連性が無いと判断された詳細を必要とした場合、それは失われる。これは圧縮を避ける理由にはならないが、唯一のメカニズムとして扱わない理由にはなる。
見落とされがちな 2 つ目のコストがある。圧縮は実行時に無料ではない。MemoryOS は、セグメント要約を維持するために、1 回のインタラクションで 20 以上の LLM 呼び出しを行うことができる。インタラクション頻度の高いシステムにとって、これは現実的な運用コストとなる。
結果プレビューの切り捨て
すべての取得リクエストに対して完全なメモリ内容を返すのではなく、短いプレビューを返し、エージェントに完全なレコードを取得するかどうかを判断させる。supermemory は、呼び出し元が結果ごとに返されるテキスト量を調整できるスニペット長のコントロールを公開している。mem9 はさらに進んで、ソースターンに 3 つの環境変数（MEM9_SOURCE_TURN_MIN_SCORE、MEM9_SOURCE_TURN_PER_MEMORY_LIMIT、MEM9_SOURCE_TURN_TOTAL_LIMIT）を付与し、オペレーターが表示されるソースターンの数と最小関連性スコアを正確に制御できるようにしている。
トレードオフは、追加のツール呼び出しである。エージェントが完全な内容を必要とする場合、明示的に要求する必要がある。ほとんどの検索パターンでは、これが適切なトレードオフとなる。エージェントは、レコードを全文読むトークンコストを支払う前に、そのレコードが関連性があるかどうかを判断するのに十分なシグナルを得られる。
2 段階検索
プレビュー切り捨ての具体的かつ重要なバリエーションだ。検索は識別子と短いプレビューを返す。必要なときに別の GetByID 呼び出しが完全なレコードを取得する。mem9 の MemoryRepo インターフェースはこのパターンを中心に構築されており、search と fetch は異なるトークンフットプリントを持つ別個の操作である。
数字がその根拠を明確に示している。1 件 1,500 トークンのマッチが 10 件あれば、エージェントが使うかどうかに関わらず 15,000 トークンがコンテキストに注入される。2 段階検索では、合計で約 450 トークンの 10 個の識別子と短いプレビューが返され、その後エージェントが実際に必要とするレコードのみが取得される。セッション内で 20 回のリコールステップを実行すると、その差は約 200,000 トークンの節約に積み上がる。
これは採用できる最も安価な規律である。メモリストアへのアーキテクチャ変更、追加の LLM 呼び出し、情報損失は一切必要ない。これは検索インターフェースの決定事項である。
分解してから呼び出す
完全なユーザークエリをそのまま検索レイヤーに送るのではなく、まずサブクエリに分解する。SimpleMem の意図認識型検索プランナーは、メモリストアにアクセスする前に、受信したクエリをアトミックな検索意図に分解する。GitNexus もクエリツールの分解で同様のことを行っている。複雑なクエリは対象を絞ったサブクエリに分割され、それぞれがメモリグラフの焦点を絞ったスライスを取得する。
利点は精度である。分解されたクエリは無関係な情報をあまり取得しないため、コンテキスト内のノイズが少なくなる。トレードオフはレイテンシーだ。分解により、検索が開始される前に計画ステップが追加される。インタラクティブなエージェントにとってこれは重要だが、バッチ処理やバックグラウンドのエージェントにとっては通常問題にならない。
階層型ストレージによる予算フィルタリング
階層型メモリアーキテクチャ（先週の記事のテーマ）をすでに構築している場合、副作用として予算フィルタリングが得られる。supermemory の 3 層モデルでは、ホットで頻繁にアクセスされる情報は、コンパクトでシグナルの高い結果を返す層に存在する。コールドな情報は、デフォルトではクエリされない層に存在する。Hindsight のオブザベーション層も同様に機能する。生の観察結果は直接コンテキストに注入されるのではなく、検索候補になる前に上位層にプロモーションされる。
トレードオフはリコールの完全性である。プロモーションされていない情報は関連性があっても、標準的な検索パスでは表面化しない可能性がある。これは圧縮と同じトレードオフだが、障害モードが異なる。要約による情報損失ではなく、降格による情報損失となる。
自己誘導型ツールレスポンス
最も議論されることの少ないメカニズムであり、最も興味深いものの一つでもある。ツール呼び出し後にエージェントが何をすべきかを決定させるのではなく、ツールレスポンス自体に次に何をすべきかのヒントを含める。GitNexus はツールレスポンスに ---
**Next:** ブロックを追加し、フォローアップアクションを提案する。mem9 はソースターンに構造化されたメタデータを付与し、エージェントの次の検索ステップをガイドする。
効果としては、エージェントがツール呼び出し間の計画に費やすトークンが少なくなる。ツールレスポンスは次のステップを明白にするのに十分な構造を持つ。トレードオフはプロンプトエンジニアリングの労力である。適切な自己誘導型レスポンスを作成するには、エージェントが次に何を必要とするかを事前に把握している必要があるが、これは常に可能とは限らない。
Tolaria の極限事例
Tolaria を別に検討する価値があるのは、予算規律を極限まで追求した論理的な終着点を表しているからだ。ADR-0009 は、システムから埋め込みを完全に削除する決定を文書化している。Tolaria は部分文字列のみの検索を使用する。ベクトルインデックスも、セマンティック検索も、埋め込み呼び出しもない。
その理由は直接的だ。最も安価なトークンは、そもそも取得しないトークンである。埋め込みベースの検索は意味的に類似した結果を返す。つまり、エージェントが明示的に要求しなかった結果を返す。それらの結果の一部は有用だが、多くはそうではない。そして、それらすべてにトークンコストがかかる。
Tolaria の立場は、無関係だが類似した結果のコストが、セッションを通じて累積すると、そのユースケースにおけるセマンティックリコールの利点を上回るというものだ。このトレードオフがあなたのシステムに当てはまるかどうかは、そのシステムの目的次第である。クエリが正確で構造化されているシステム（コードナビゲーション、識別子によるドキュメント検索）では、Tolaria の立場は妥当である。クエリが曖昧で探索的なシステムでは、埋め込みを削除すると、回復が困難な方法でリコールが損なわれる。
Tolaria の事例の価値は、それをコピーすべきだということではない。ほとんどのシステムがそうしない方法で、セマンティック検索のコストを可視化する点にある。
圧縮オンリーシステムに対する反論
調査した 19 のシステムのうち、いくつかは圧縮を主要な、あるいは唯一の予算メカニズムとして依存している。その障害モードを挙げておく価値がある。
第一に、要約は、圧縮時には関連性がないと判断されたが、後になって関連性を持つようになる詳細を失う。これは仮定の話ではない。将来の関連性が未知の情報に非可逆圧縮スキームを適用した場合の標準的な障害モードである。
第二に、圧縮はホットパス上のコストである。MemoryOS が 1 インタラクションあたり 20 以上の LLM 呼び出しを行うのは、圧縮重視のシステムでは珍しいことではない。スケールが大きくなると、このコストは無視できない。
第三に、そして最も微妙な点だが、逃げ道のない圧縮は緩やかな忘却である。コンテキストサイズを減らす唯一の方法が要約であり、要約が非可逆であるならば、システムは情報を継続的に破棄し、それを回復する方法がないことになる。2 段階検索、階層型ストレージ、結果プレビューの切り捨てはすべて、元のレコードを保持する。圧縮はそうではない。
これは圧縮が間違っているという意味ではない。圧縮だけでは不十分であるという意味だ。
再近接性重み付けと永続キュー
上記の 6 つのカテゴリーにきれいに当てはまらない 2 つのメカニズムを挙げておく。
graymatter は、RRF フュージョンを再近接性に半分の重みで使用している。これは厳密な意味での予算メカニズムではないが、そのように機能する。検索ランキングで古い情報の重みを下げることで、古くてシグナルの弱いレコードが、最近のシグナルの強いレコードを圧迫する可能性を減らす。効果は、明示的な階層プロモーションではなく、ランキング重み付けによるソフトな階層化である。
llm-wiki の 540 行からなるインジェストキューのステートマシンは、異なるアプローチを取っている。キューはインジェスト操作をシリアル化し、情報がメモリストアに入る前に 4 つのシグナルによる関連性ランキングを適用する。予算管理は読み取り時ではなく書き込み時に行われる。関連性の閾値をクリアしない情報は保存されないため、取得されることも、コンテキストを消費することもない。これは間接的な予算管理だが、持続可能である。節約効果は将来のすべてのセッションにわたって累積する。
適切に設計されたシステムの共通点
19 のシステムを概観すると、コンテキスト予算をうまく処理しているシステムには、いくつかの共通する特性がある。
それらは、検索を 1 段階の注入ではなく、2 段階の操作として扱う。完全なレコードの前にプレビューを返す。要約に置き換えるのではなく、元のレコードを保持する。ハードコードされたデフォルトではなく、明示的なパラメータを通じてオペレーターに検索量の制御を提供する。そして、読み取り時だけでなく書き込み時にも予算を考慮する。
うまく処理できていないシステムは、単一のメカニズム、通常は圧縮に依存し、コンテキストウィンドウを管理すべきリソースではなく、埋めるべきバッファとして扱う傾向がある。
この調査からの最終的な立場はシンプルだ。ウィンドウが大きくなればなるほど、より多くの規律が必要となる。埋めること自体が原則的に間違っているからではなく、間違った情報で埋めることが、空きスペースを残しておくよりも多くのコストを要するからだ。
次の記事では、メモリを注入としてではなくツールとして捉え、19 のシステムが、何が自動的にコンテキストにプッシュされ、何をエージェントが明示的に要求しなければならないかという境界をどのように扱っているかを取り上げる予定だ。
いつものように、これを面白い、役に立つと感じた場合、あるいは単に知識を広める手助けをしたい場合:
シェアをお願いします
