標準的なRAGパイプラインは、企業がそれを長期・複数セッションのLLMエージェント導入に使おうとすると破綻します。これは、永続的なAIアシスタントへの需要が高まる中で、重大な制約です。
キングス・カレッジ・ロンドンおよびアラン・チューリング研究所の研究者らが開発した新しい手法であるxMemoryは、会話を検索可能な意味的テーマの階層として整理することで、この問題を解決します。
実験の結果、xMemoryはさまざまなLLMにおいて推論コストを削減しつつ、回答の質と長距離（ロングレンジ）の推論を向上させることが示されています。研究者らによれば、一部のタスクでは、既存システムと比べてトークン使用量が1クエリあたり9,000トークン超からおよそ4,700トークンまで減少します。
パーソナライズされたAIアシスタントや複数セッションの意思決定支援ツールといった実世界の企業向けアプリケーションにとって、これは、計算コストを爆発させることなく、一貫した長期記憶を維持できる、より信頼性の高い文脈対応型エージェントを企業が導入できることを意味します。
RAGはこのために作られていなかった
多くの企業向けLLMアプリケーションでは、これらのシステムが長く複数セッションにまたがるやり取りの中でも、一貫性とパーソナライゼーションを維持することが重要な期待です。長期的な推論を支えるための一般的なアプローチの1つは、標準的なRAGを使うことです。つまり、過去の対話や出来事を保存し、埋め込み類似度に基づいて上位の一致を固定数だけ取得し、それらをコンテキストウィンドウに連結して回答を生成します。
しかし、従来のRAGは、取得される文書が高度に多様であるような大規模データベースを前提に構築されています。主要な課題は、完全に無関係な情報をふるい分けることです。対照的に、AIエージェントの記憶は、制約された連続的な会話の流れであり、そのため保存されるデータチャンクは相関が高く、しばしばほぼ重複（ニア・デュープ）を含みます。
単にコンテキストウィンドウを大きくしても機能しない理由を理解するために、「柑橘類」という概念を標準的なRAGがどう扱うかを考えてみましょう。
ユーザーが「オレンジが大好き」「みかん（マンダリン）も好きです」といった発言を含む会話を多数しており、それとは別に「柑橘類とは何か」という事柄についての他の会話も行っていたとします。従来のRAGは、これらを意味的に非常に近いものとして扱い、「柑橘類っぽい」断片を同様のものばかり繰り返し取得してしまう可能性があります。
論文の共著者であるLin GuiはVentureBeatに対し、「もし検索が、埋め込み空間で最も密度が高いクラスタに崩れ込むのだとしたら、エージェントは好み（プリファレンス）に関する非常に似通った複数の文章を得る一方で、実際の質問に答えるために必要なカテゴリの事実を見落としかねません」と述べています。
エンジニアリングチームがよく行う対策は、検索後の枝刈り（pruning）や圧縮を適用してノイズを除去することです。これらの方法は、取得される文章が高度に多様であり、無関係なノイズのパターンは有用な事実からきれいに切り分けられる、という前提に立っています。
研究者らが書いているように、このアプローチは会話エージェントの記憶には不十分です。人間の対話は「時間的に絡み合っている（temporally entangled）」ためです。会話の記憶は、指示対象の相互参照（コリファレンス）、省略（エリプシス）、そして厳密なタイムライン依存に強く依存します。この相互接続性のため、従来の枝刈りツールは重要な部分をうっかり削除してしまい、AIが正確に推論するのに必要な不可欠な文脈を失わせることがよくあります。
多くのチームがたどり着く解決策が、かえって悪化させる理由
これらの制約を克服するため、研究者らはエージェントの記憶が構築され、検索される方法を「デカップリングから集約へ（decoupling to aggregation）」という形で切り替えることを提案しています。
ユーザーのクエリを、生の重なり合うチャットログに直接照合するのではなく、システムは会話を階層的な構造に整理します。まず、会話のストリームを、異なる独立した意味的コンポーネント（要素）にデカップリングします。これらの個々の事実は、その後、テーマのより高いレベルの構造的階層へと集約されます。
AIが情報を思い出す必要があるときは、階層を上から下へ検索します。テーマから意味へ、そして最後に生のスニペットへと進みます。このアプローチは冗長性を避けます。2つの対話スニペットの埋め込みが似ていても、それらが異なる意味的コンポーネントに割り当てられていれば、一緒に取得されにくくなります。
このアーキテクチャが成功するには、2つの重要な構造特性のバランスを取らなければなりません。意味的コンポーネントは、AIが冗長なデータを取得しないよう、十分に区別されていなければなりません。同時に、より高レベルの集約は、モデルが正確な回答を作れるように、元の文脈に対して意味的に忠実であり続ける必要があります。
コンテキストウィンドウを縮める4階層
研究者らは、構造化された記憶管理と、適応的な上から下への探索戦略を組み合わせたフレームワークであるxMemoryを開発しました。
xMemoryは、会話の生ストリームを継続的に、構造化された4階層の階層へと整理します。最下層には生のメッセージがあり、まずそれらを「エピソード」と呼ばれる連続したブロックへ要約します。これらのエピソードから、システムは、反復されるチャットログから長期にわたる中核の知識を切り離す、再利用可能な事実を意味（セマンティクス）として抽出します。最後に、関連する意味は高レベルのテーマにグルーピングされ、検索しやすくなります。
xMemoryは、これらのアイテムをどのようにグループ化するかを常に最適化するための特別な目的関数を用います。これにより、カテゴリが大きくなりすぎて検索が遅くなることも、細分化しすぎて、証拠の集約や質問への回答を行うモデルの能力が弱まることも防ぎます。
プロンプトを受け取ると、xMemoryはこの階層に対して上から下へ検索を行います。テーマおよび意味のレベルから始め、関連する事実を多様でコンパクトな集合として選択します。これは、ユーザーのクエリがしばしば複数のトピックにわたる説明の収集を必要としたり、複雑なマルチホップ推論のために連結された事実をつなげたりする、実世界のアプリケーションで極めて重要です。
事実の高レベルな骨格（スケルトン）ができたら、システムは研究者らが「不確実性ゲーティング（Uncertainty Gating）」と呼ぶ仕組みによって冗長性を制御します。特定の詳細が、測定可能な形でモデルの不確実性を下げる場合にのみ、エピソードまたはメッセージのレベルへ掘り下げて、より細かな生の根拠（エビデンス）を取り出します。
Guiはこう述べています。「意味的類似度は候補生成（candidate-generation）の信号であり、不確実性は意思決定（decision）の信号です。類似度は、近くに何があるかを教えてくれます。不確実性は、プロンプト予算の中で実際に価値があるのは何かを教えてくれます。」そして、追加の詳細がもはや質問への回答に役立たないことを検知すると、拡張を停止します。
代替案はあるのか？
既存のエージェントの記憶システムは、一般に2つの構造カテゴリに分類されます。フラットな設計と、構造化された設計です。どちらも根本的な制約を抱えています。
MemGPTのようなフラットなアプローチは、生の対話や最小限に処理された痕跡（トレース）をログとして残します。これにより会話は捉えられますが、履歴が長くなるほど大きな冗長性が蓄積し、検索コストが増大します。
A-MEMやMemoryOSのような構造化システムは、記憶を階層やグラフへ整理することでこの問題を解決しようとします。ですが、それでも主な検索単位としては、生のテキスト、あるいは最小限に処理されたテキストに依存しており、結果として広範で肥大化したコンテキストを取り込むことが多いです。さらに、これらのシステムは、厳密なスキーマ制約を持つLLM生成の記憶レコードにも大きく依存しています。AIのフォーマットが少しでも逸脱すると、記憶が機能しない（メモリフェイル）原因になり得ます。
xMemoryは、その最適化された記憶構築スキーム、階層的な検索、そして記憶がより大きくなったときの動的な再構築によって、これらの制約に対処します。
xMemoryを使うべきタイミング
エンタープライズ・アーキテクトにとって、標準RAGよりもこのアーキテクチャを採用すべきタイミングを理解することは重要です。Guiによると、「xMemoryが最も魅力的なのは、システムが、数週間あるいは数か月にわたる相互作用の間、一貫性を保つ必要がある場合です。」
たとえばカスタマーサポート担当者は、このアプローチの恩恵を大きく受けます。近い内容のサポートチケットを何度も引き出さずに、安定したユーザーの嗜好、過去のインシデント、アカウント固有の文脈を記憶しておく必要があるためです。パーソナライズされたコーチングもまた理想的なユースケースです。そこでは、AIが、持続するユーザーの特性を、日々の出来事に紐づく一時的な詳細から切り分けることが求められます。
一方で、企業が、ポリシーマニュアルや技術ドキュメントのようなファイルの集合に対してチャットするためのAIを構築している場合、「よりシンプルなRAGスタックのほうが、依然としてより良いエンジニアリング上の選択です」とGuiは述べています。これらの静的でドキュメント中心のシナリオでは、コーパスの多様性が十分にあるため、標準的な近傍探索による検索でも、階層型メモリの運用オーバーヘッドなしに十分に機能します。
書き込みコストはそれだけの価値がある
xMemoryは、LLMの最終的な回答生成に伴うレイテンシのボトルネックを削減します。標準的なRAGシステムでは、LLMは冗長な対話で埋め尽くされた巨大なコンテキストウィンドウを読み込み、処理せざるを得ません。xMemoryの精密なトップダウン検索によって、はるかに小さく、高度に的を絞ったコンテキストウィンドウが構築されるため、読み手となるLLMはプロンプトの分析と最終出力の生成に費やす計算時間を大幅に減らせます。
長いコンテキストが必要なタスクに関する実験では、xMemoryを備えたオープンモデル／クローズドモデルの双方が、他のベースラインを上回りました。はるかに少ないトークン数でタスク精度を高めることができたのです。
ただし、この効率的な検索には、前払いのコストが伴います。エンタープライズでの導入におけるxMemoryの「落とし穴」は、大規模な読み取りコストを前払いの書き込みコストに置き換える点にあります。最終的にはユーザーの質問への回答をより速く、より安くしますが、高度なアーキテクチャを維持するには、かなりのバックグラウンド処理が必要です。
標準的なRAGパイプラインが、生のテキスト埋め込みをデータベースに手軽に投入するのに対し、xMemoryは複数の補助的なLLM呼び出しを実行しなければなりません。会話の境界を検出し、エピソードを要約し、長期的な意味情報を抽出し、さらに全体を貫くテーマを統合するためです。
加えて、xMemoryの再構築プロセスは、AIが自分自身の内部ファイリングシステムをキュレーションし、関連付け、更新しなければならないため、追加の計算要件を伴います。本番環境でこの運用上の複雑性を管理するために、チームは重い再構築処理を、ユーザーのクエリを同期的にブロックするのではなく、非同期に実行するか、マイクロバッチとして処理できます。
プロトタイプを素早く作りたい開発者向けに、xMemoryのコードは公開されており
