はじめに
前回の記事では、Long-term Memory の仕組みと設計について見てきました。
Long-term Memory によって「記憶できない」という問題は解決できます。しかし、LLM のコンテキストウィンドウには上限があるため、「情報が多すぎる」という新たな問題が発生します。本記事では、
- Context Compression とは何か
- なぜ長い会話で性能が低下するのか
- どのように情報を圧縮するのか
について見ていきます。
Context Compressionとは
Context Compression の「Context」は、
LLM に入力される自然言語の情報全体を指します。たとえば、
- 会話履歴
- Long-term Memory から取得した情報
- 参照文書
- Tool Results
などが Context として LLM に渡されます。
Context Compression とはコンテキストの「圧縮」、つまり限られたコンテキストウィンドウの中で、LLM にとって重要な情報だけを残し、それ以外の情報を圧縮・削減する技術です。 「圧縮」と言っても単純に情報量を減らすことではありません。Context Compression の目的は、
情報量を減らしながら、必要な情報は維持する
LLM に渡す情報を整理し、
重要な情報だけを残して入力サイズを削減する
ことにあります。Context Compression は Long-term Memory から取得した大量の情報を、そのまま LLM に渡すのではなく、重要な情報だけを抽出して渡すための仕組みなのです。
なぜContext Compressionが必要なのか
長いコンテキストには、大きく分けて二つの問題があります。
- コンテキストウィンドウに収まらない
- コンテキストウィンドウに収まっても有効活用できない
問題1: コンテキストウィンドウに収まらない
一つ目は、情報量がコンテキストウィンドウの上限を超えてしまう問題です。たとえ関連情報が存在していたとしても、コンテキストウィンドウへ収まらなければ LLM は利用できません。
この問題は前回の記事で説明した Long-term Memory と密接に関係しています。Long-term Memory が利用できるようになることで大量の情報を保存・取得できるようになりますが、その結果として今度はコンテキストウィンドウへ収まりきらないケースが発生します。
問題2: コンテキストウィンドウに収まっても有効活用できない
二つ目は、コンテキストウィンドウの範囲内に収まっていたとしても、LLM がその情報を効果的に利用できるとは限らないという問題です。これは単なるトークン数の問題ではありません。たとえコンテキストウィンドウの上限を超えていなくても、
- 関係のない情報が増える
- 本当に重要な情報が埋もれる
- 必要な情報を見つけにくくなる
といった問題が発生します。つまり、「情報を入力できること」と
「情報を有効活用できること」は別問題なのです。
コンテキストが長いだけでは不十分
長いコンテキストを扱えるモデルであっても、コンテキストが長くなるにつれて重要な情報を見つけられなくなる場合があります。つまり、「情報量が多いこと」と「 必要な情報を正しく利用できること」は別の問題なのです。これらの研究結果は、
コンテキストは長ければ長いほど良い
という単純な話ではないことを示しています。重要なのは、
必要な情報を見つけやすい形で LLM に渡すこと
です。近年の研究では、コンテキストが長くなるにつれて、LLM が重要な情報を正しく利用できなくなる現象が報告されています。代表的な例として、
- Needle in a Haystack と
- Lost in the Middle
が挙げられます。
Needle in a Haystack
Needle は「針」、Haystack は「干し草の山」を意味します。つまり、Needle in a Haystack は「干し草の山」の中から一本の「針」を探し出すような問題です。
Created by Nano Banana 2 Lite
「大量の情報」例えば、
- 大量の検索結果
- 数百ページの文書
- 数年分の会話履歴
の中に「重要な情報」を一つだけ埋め込み、それを正しく取り出せるかを評価します。
Lost in the Middle（中央の情報が活用されにくい現象）
Lost in the Middle は直訳すると、
「中央で見失う」
「途中で失われる」
といった意味になります。
Needle in a Haystack は「重要な情報を発見できるか」に着目したベンチマークですが、Lost in the Middle は長いコンテキストにおいて、重要な情報が中央付近に配置された場合に性能が低下する現象を明らかにした研究です。
2023年にStanford University の Liu らによって発表された論文 "Lost in the Middle: How Language Models Use Long Contexts" では、長いコンテキストの中で重要な情報の位置を変化させた場合の性能を評価しています。
この研究では、Multi-Document Question Answering や Key-Value Retrieval といったタスクを用いて、LLM が長いコンテキスト内の情報をどの程度活用できるかを測定しました。論文中の Figure 1 （図1）では、この傾向が U 字型の性能曲線として視覚的に示されています。
図1：関連情報の位置によって LLM の性能がどのように変化するかを示しています。興味深いことに、重要な情報がコンテキストの先頭や末尾に存在する場合は高い性能を維持できる一方で、中央付近に存在する場合は性能が大きく低下します。つまり、LLM は長いコンテキストを扱えるとしても、その中の情報を均等に利用できるわけではありません。このようなU字型の性能特性は、先頭の情報を優先的に利用する「Primacy Bias（初頭効果）」と、末尾の情報を優先的に利用する「Recency Bias（新近効果）」と関連していると考えられています。
この内容を単純化すると、
重要な情報が
- 先頭にある場合は性能が高い
- 中央にある場合は性能が低下する
- 末尾にある場合は再び性能が高くなる
という U 字型の傾向が観察されます。中央付近の情報は見落とされやすく、この現象は Lost in the Middle（中央の情報が活用されにくい現象）と呼ばれています。
つまり、LLM は長いコンテキストを扱えるようになったとしても、その中のすべての情報を均等に利用できるわけではありません。言い換えると、
情報をたくさん入力したからといって、必要な情報をうまく利用できるとは限らない
ということです。そのため、単にコンテキストウィンドウを拡大するだけでは十分ではなく、重要な情報をより効果的に配置・抽出する仕組みが必要になります。
代表的なContext Compressionの手法
現在の Agent Engineering では、Context Compression を実現する方法として、主に次のような手法が利用されています。
| 手法 | アプローチ | 概要 |
|---|---|---|
| Truncation | 切り捨て | 古い情報や重要度の低い情報を取り除く |
| Summarization | 要約 | 長い情報を要約して短くする |
| Retrieval-based Compression | 選択 | 関連性の高い情報だけを選択する |
| Hierarchical Memory | 階層化 | 情報を階層化して管理する |
これらは互いに排他的なものではなく、実際のシステムでは複数の手法を組み合わせて利用することが一般的です。
次に、それぞれの圧縮手法について詳しく見ていきましょう。
Truncation（切り捨て）
Truncation は最も単純な Context Compression の手法です。コンテキストウィンドウの上限を超えそうになった場合、古い情報や重要度の低い情報を単純に切り捨てます。たとえば、
Conversation History
（会話履歴）
Message 1
Message 2
... →
Message 91 Message 91
... ...
Message 100 Message 100
多くのチャットシステムで利用されている方法であり、実装が非常に簡単という利点があります。一方で、
- 重要な情報を誤って削除してしまう
- 長期的な文脈を失う
- ユーザーの過去の意図を忘れてしまう
といった問題もあります。そのため、Agent Engineering では単独で利用されるよりも、他の圧縮手法と組み合わせて利用されることが一般的です。
Summarization（要約）
Summarization は、情報を切り捨てるのではなく、内容を短く要約して保持する方法です。
Truncation（切り捨て）の場合は古い情報そのものを取り除きますが、Summarization では古い情報を短い要約へ変換して保持します。
Truncation ：古い情報を切り捨てる
Summarization ：古い情報を要約して残す
たとえば、「100件の会話履歴」をそのまま保存する代わりに、Conversation Summary（会話要約）へ変換します。たとえば、
Conversation History → Conversation Summary
Message 1 ・ユーザーは来月出張する予定
Message 2 ・JALを希望
... ・通路側座席を希望
Message 100 ・本社近くのホテルを希望
Truncation とは異なり、情報量を削減しながら重要な内容を維持できることが特徴ですが、
- 要約時に情報が失われる
- 要約ミスが発生する
- 要約を繰り返すと情報が劣化する
といった課題があります。
そのため、実際の Agent Engineering では Summarization を単独で利用するだけでなく、Retrieval-based Compression や Hierarchical Memory と組み合わせて利用することが一般的です。
Retrieval-based Compression（選択）
Retrieval-based Compression は、すべての情報を圧縮するのではなく、現在のタスクに関連する情報だけを選択する方法です。Truncation（切り捨て）は古い情報を削除し、Summarization（要約）は情報を短くまとめます。一方、Retrieval-based Compression は情報そのものを削除したり要約したりするのではなく、
必要な情報だけを選択する
というアプローチを取ります。たとえば、Long-term Memory に 「1000件の情報」が保存されていたとしても、「現在のタスクに関連する5件」だけを取り出して利用します。Long-term Memory の記事で説明した Retriever も、この考え方の一部です。
この方法の利点は、不要な情報を LLM に渡さずに済むことです。たとえ大量の情報が保存されていたとしても、現在のタスクに必要な情報だけを選択することで、コンテキスト使用量を大幅に削減できます。
実際の Agent Engineering では、この手法が最も広く利用されています。Retrieval-based Compression が Context Compression の中心的な役割を担うことが多く、他の手法と組み合わせて利用されることが一般的です。
RAG（Retrieval-Augmented Generation）との関連性
LLM の商用化以降、関連技術は概ね次のような流れで発展してきました。
LLM の次の世代の技術として登場した RAG では、大量の文書をそのまま LLM に渡すのではなく、Retriever を利用して関連性の高い情報だけを取得して利用します。
Retrieval-based Compression も基本的な考え方は同じです。つまり、
必要な情報だけを選択して LLM に渡す
というアプローチを採用しています。
RAG という技術がすでに広く普及していたことを考えると、その後に登場した AI Agent において Retrieval-based Compression が広く利用されるようになったのは、ある意味では自然な流れだと言えるでしょう。
このように、Retrieval-based Compression はまったく新しい発想というよりも、RAG で広く利用されるようになった Retrieval の考え方を Agent Engineering へ応用したものと捉えることができます。
※ RAG の仕組みについてさらに詳しく知りたい方は、Lewis et al. による原論文 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" を参照してみてください。RAG における Retriever と Generator の役割や、現在の AI Agent にも受け継がれている Retrieval の考え方を理解することができます。
Hierarchical Memory（階層化）
Hierarchical Memory は情報を階層化して管理する方法です。たとえば、
- Level 1: 会話全文
- Level 2: 会話要約
- Level 3: 長期的な知識
のように複数の階層へ整理します。
必要に応じて適切な階層の情報を利用することで、コンテキスト使用量を抑えつつ重要な情報を維持できます。ただし、実装は比較的複雑になります。
Context Compressionのアプローチ整理
このように、Context Compression にはさまざまな手法があります。実際のシステムでは、
- Truncation（切り捨て）
- Summarization（要約）
- Retrieval-based Compression（選択）
- Hierarchical Memory（階層化）
のいずれか一つを選ぶのではなく、複数の手法を組み合わせて利用することが一般的です。
Truncationは情報を削除し、Summarizationは情報を短くし、Retrieval-based Compressionは必要な情報を選択します。これらの手法は、
情報量を減らす
という方向で Context Compression を実現します。一方、Hierarchical Memory は、
情報を複数の階層で管理する
という異なるアプローチを取ります。
Context Compression設計で重要なこと
ここまで見てきたように、Context Compression にはさまざまな実現方法があります。しかし重要なのは、
どの手法を使うか
ではなく、
必要な情報をどれだけ維持できるか
です。圧縮しすぎれば重要な情報が失われます。逆に、圧縮しなさすぎればコンテキストサイズはほとんど減りません。つまり、
圧縮率と情報保持率のバランス
が重要になります。実際の Agent Engineering では、
- 不要な情報は減らす
- 重要な情報は残す
- LLM が利用しやすい形で渡す
ことが求められます。言い換えると、Context Compression の目的は単なる圧縮ではなく、
LLM が必要な情報を利用しやすくすること
にあります。
まとめ
今回は AI Agent を支える基盤技術の一つである Context Compression について見てきました。Long-term Memory によって大量の情報を保存できるようになった一方で、
- コンテキストウィンドウに収まらない
- コンテキストウィンドウに収まっても有効活用できない
という新しい問題が生まれます。Needle in a Haystack や Lost in the Middle の研究からも分かるように、
情報をたくさん入力したからといって、必要な情報をうまく利用できるとは限りません。
そのため、AI Agent では Context Compression を利用して、
必要な情報だけを LLM に渡す
ことが重要になります。Context Compression を実現する方法としては、
- Truncation（切り捨て）
- Summarization（要約）
- Retrieval-based Compression（選択）
- Hierarchical Memory（階層化）
などがあり、実際のシステムではこれらを組み合わせて利用することが一般的です。
次回は、Agent が長いタスクをどのように管理し、一貫した動作を維持するのかを支える State Management（状態管理）について見ていきます。