Structured Distillation for Personalized Agent Memory: 11x Token Reduction with Retrieval Preservation

この論文は、ソフトウェアエンジニアリングの会話履歴を構造化された要約（1 交換あたり平均 38 トークン）に圧縮する「構造化蒸留」手法を提案し、トークン数を 11 分の 1 に削減しつつ、検索精度を大幅に維持または向上させることを実証しています。

要約

この論文は、**「AI との長い会話履歴を、忘れずに、かつ軽くして記憶させる方法」**について研究したものです。

まるで、**「膨大な量の会話メモを、11 倍も小さく压缩（圧縮）して、必要な時だけサッと取り出せるようにする」**という技術です。

以下に、専門用語を使わず、日常の例え話を使って解説します。

---

🏰 1. 問題：AI は「記憶力ゼロ」の相棒

あなたは AI と一緒に 3 ヶ月間、毎日 1 時間ずつ仕事をしてきたと想像してください。

• あなた： 「あ、3 週間前にあの接続エラーを直したな」と覚えていますが。
• AI： 「え？何の話？初めて聞きますよ」と、毎回ゼロからスタートします。

AI に過去の話を全部覚えてもらうには、過去の会話そのものを全部読み込ませる必要があります。でも、それは**「図書館の全蔵書を、1 回の質問に持っていこうとする」**ようなもので、重すぎて現実的ではありません。

✂️ 2. 解決策：「構造化された要約（Distillation）」

そこで著者は、**「会話の『本質』だけを取り出して、小さなカードに書き留める」**という方法を開発しました。

• 従来の要約： 「前回、接続の問題を直しました。色々と試して、最終的にこうしました……」と、AI が自由にまとめてしまう（これだと重要な単語が抜けてしまう）。
• この論文の方法： 会話から**「何をしたか（核心）」「使ったファイル名」「エラーメッセージ」「どのトピックの部屋に属するか」**という 4 つの要素だけを、決まったフォーマットで抜き出す。

【例え話：料理のレシピ】

• 元の会話（Verbatim）： 371 文字の長い料理談義。「まず卵を割って、フライパンを熱して、塩を少し入れて……あ、でもバターの方がいいかもね……」
• 圧縮されたカード（Distilled）： 「卵料理：バター使用、塩少々、フライパンで炒める（38 文字）」
• 結果： 文字数は11 倍に減りましたが、**「何を作ったか」「どんな材料を使ったか」**という重要な情報は残っています。

🔍 3. 検索テスト：「本当に見つかるのか？」

「こんなに短くしたら、後で検索しても見つからないんじゃないか？」という不安をテストしました。

• テスト方法： 201 個の質問（例：「あのエラーメッセージは何だったっけ？」）を出して、**「元の長い会話」から探す場合と「圧縮されたカード」**から探す場合を比べました。
• 結果：
  • 意味で探す検索（ベクトル検索）： 圧縮しても96% 以上の精度で正解が見つかりました！AI が「意味」を理解して探すなら、短くても大丈夫です。
  • 単語で探す検索（BM25）： 圧縮すると、重要な単語が抜けてしまい、精度が下がりました。「単語の一致」だけで探す場合は、元の長い文章の方が有利です。

🌉 4. 最強の組み合わせ：「2 段構えの検索」

実は、**「圧縮カードでざっくり探す」＋「見つかった会話の元データで詳しく確認する」**という組み合わせが最も優秀でした。

• 仕組み：
  1. まず、**「圧縮されたカード（11 倍軽い）」**を使って、AI が「多分これだ！」と候補を 10 個くらい選びます。
  2. 次に、**「元の長い会話（重いが詳細）」**から、その候補の具体的な部分だけを読み込んで、ユーザーに見せます。
• メリット：
  • AI のメモリ（作業スペース）は11 倍軽く済みます。
  • ユーザーが見るのは、圧縮された要約ではなく、元の会話そのものなので、情報が欠落していることはありません。
  • 検索精度は、元の文章だけで探す場合よりも少しだけ向上しました（異なる検索方法が補い合っているため）。

🏆 5. 結論：なぜこれがすごいのか？

この技術を使えば、**「AI が自分の過去の経験を、1 冊の小さなノートにまとめて持ち歩く」**ことができます。

• 従来の方法： 過去の会話全部を記憶させようとすると、AI の頭（メモリ）がパンクして、新しいことが覚えられなくなる。
• この方法： 過去の会話は**「索引（目次）」として軽く保存し、必要な時だけ「元のページ」**を呼び出す。

【まとめ】
これは、「記憶の整理整頓」です。
部屋（会話）が散らかって広すぎて探せない状態から、「何があったか」を 11 倍のコンパクトなカードに整理し、必要な時に元の部屋へ案内する仕組みを作りました。これにより、AI は長い間一緒に働いても、あなたの過去の仕事を忘れずに、かつ賢く動けるようになります。

---

一言で言うと：
「AI に『過去の会話全部』を丸ごと覚えさせるのではなく、『重要なポイントだけ』を 11 倍軽くして索引化し、必要な時に元データを呼び出す仕組みを作ったよ！」

技術概要

構造化蒸留によるパーソナライズド・エージェント・メモリの技術的サマリー

タイトル: Structured Distillation for Personalized Agent Memory: 11× Token Reduction with Retrieval Preservation
著者: Sydney Lewis (2026 年 3 月)

1. 背景と課題 (Problem)

AI エージェントとの長期的な対話において、人間は過去の文脈（「3 週間前に接続プールの問題を修正した」など）を断片的に記憶しているが、エージェントはセッションごとにリセットされ、履歴を保持しない。
従来のリtrieval-augmented generation (RAG) アプローチでは、過去の対話全文をコンテキストに読み込む必要があるが、平均 371 トークンの交換をそのまま保持すると、コンテキストウィンドウの圧迫とコスト増大が深刻化する。
既存の「要約（Compaction）」アプローチは、文脈ウィンドウが満杯になった際に LLM に要約させ、元データを破棄する「損失のある圧縮」であり、情報の劣化が累積する問題がある。
本研究の核心課題: 単一ユーザーの対話履歴を、検索品質を損なわずにコンパクトなメモリ層へ「構造化蒸留（Structured Distillation）」し、後続の検索（Recall）で同等の品質を維持できるか？

2. 手法 (Methodology)

2.1 データセット

• 対象: 1 人のソフトウェアエンジニアによる 6 個のプロジェクト、4,182 会話、14,340 回の交換（Exchange）。
• 平均長さ: 原文 371 トークン。

2.2 構造化蒸留 (Structured Distillation)

各対話交換（Exchange）を、LLM によって生成された構造化オブジェクト（「Palace Object」と呼称）に変換する。原文はディスクに保持され、検索用インデックスとしてのみ蒸留されたテキストを使用する。
各オブジェクトは以下の 4 つのフィールドで構成される：

1. exchange_core: 達成されたことの要約（1-2 文）。LLM 生成。
2. specific_context: 決定的な技術的詳細（エラーメッセージ、パラメータ値など）。LLM 生成。
3. thematic_room_assignments: 1-3 のトピック別「部屋」への割り当て（ファイル、概念、ワークフロー）。LLM 生成。
4. files_touched: 対話内で言及されたファイルパス。正規表現による抽出（LLM 生成ではない）。

重要な原則: 「生存語彙原則（Surviving Vocabulary Principle）」を採用。LLM は自由な言い換えをせず、対話内で使用された具体的な用語（例：「connection pool timeout」）をそのまま維持するよう指示される。これにより、検索クエリとの一致を最大化する。

2.3 検索アーキテクチャ

• ベクトル検索: all-MiniLM-L6-v2 で 384 次元の埋め込みを生成し、FAISS (IndexFlatL2) に格納。
• キーワード検索: BM25 (Okapi, FTS) を蒸留テキストとメタデータに対して構築。
• 検索モード:
  • Pure Modes: 蒸留テキストのみ、または原文のみで検索（HNSW, Exact, BM25 の組み合わせ）。
  • Cross-layer Modes: 原文のキーワード検索と、蒸留テキストのベクトル検索を融合（Fusion）。

2.4 評価手法

• クエリセット: 201 件の検索クエリ（概念的、フレーズ、正確な用語の 3 種類）。
• 評価者: 5 つのローカル LLM (Qwen, Phi, Mistral など) と、不一致時の調整役として Claude Opus。
• 指標: MRR (Mean Reciprocal Rank), Mean Grade, P@1, nDCG@10。
• 統計的検定: ペアワイズ t 検定とウィルコクソンの符号付き順位和検定（Bonferroni 補正適用）。

3. 主要な結果 (Key Results)

3.1 圧縮率と検索品質の維持

• 圧縮率: 交換あたりの平均トークン数が 371 → 38 トークン となり、11 倍の圧縮を達成。
• 純粋な蒸留モデルの性能: 最良の純粋な蒸留設定（Distill Core+Rooms / Exact / Weighted）は、最良の原文ベースライン（Full Text / BM25-FTS）の MRR の 96% (0.717 vs 0.745) を維持。
• クロスレイヤー検索の優位性: 原文の BM25 キーワード検索と、蒸留テキストの HNSW ベクトル検索を融合したクロスレイヤー設定が、最良の純粋原文ベースラインをわずかに上回る MRR 0.759 を達成。これは、両者の信号が補完的であることを示唆。

3.2 検索メカニズム依存性 (Mechanism-Dependent Preservation)

結果は検索メカニズムによって大きく異なる。

• ベクトル検索 (HNSW, Exact): 10 対 10 の比較で、統計的に有意な劣化は見られなかった。蒸留によって保持された意味的意味合いがベクトル類似性によって捕捉されている。
• キーワード検索 (BM25): 10 対 10 の比較で、統計的に有意な劣化が見られた。圧縮により語彙が失われ、キーワードマッチングに必要な語彙が不足するため。
• 効果量: BM25 では中程度の効果量（|d| = 0.5 以上）が見られるのに対し、ベクトル検索では無視できるほど小さい。

3.3 クエリタイプ別の挙動

• 正確な用語クエリ: 蒸留モデルの方が原文を上回る場合もあった（ファイルメタデータによる正確な識別子マッチングのため）。
• 概念的クエリ: 原文が蒸留モデルを上回る傾向が最も強かった（抽象的な意味の圧縮による損失）。

4. 主な貢献 (Key Contributions)

1. 単一ユーザー向け構造化蒸留手法: 対話交換を構造化オブジェクトに変換し、11 倍の圧縮を実現する手法を提案。
2. 大規模な評価: 107 種類の検索設定（5 つの純粋モード、5 つのクロスレイヤーモード）と 214,519 件の評価ペアを用いた包括的な評価。
3. 具体的なメモリ予算の削減: 1,000 回の交換を約 39,000 トークン（原文なら約 407,000 トークン）に収容可能にし、コンテキストオーバーフローなしの永続メモリを実現。
4. 2 階層アーキテクチャの提案: 検索用インデックス（蒸留テキスト）と表示用データ（原文）を分離する設計。検索は高速な蒸留層で行い、ユーザーには原文を提示する。

5. 意義と結論 (Significance & Conclusion)

本研究は、AI エージェントのパーソナライズド・メモリ管理における新しいパラダイムを示している。

• 損失なし圧縮の限界の突破: 従来の「要約して元データを捨てる」アプローチではなく、「構造化されたインデックスを作成し、元データを保持する」アプローチにより、検索品質を維持しつつコンテキストコストを劇的に削減できることを実証した。
• メカニズムの重要性: 検索品質の維持は、圧縮そのものよりも「どの検索メカニズムを使うか」に依存する。ベクトル検索は構造化蒸留と相性が良く、キーワード検索は劣化する。
• 実用的なアーキテクチャ: エージェントは軽量な蒸留メモリ（作業記憶）を持ち、必要な場合にのみ原文（Ground Truth）にアクセスする「2 階層構造」は、スケーラブルなエージェントシステムの実現に寄与する。

結論: 構造化蒸留は、単一ユーザーの対話履歴を 11 倍圧縮しても、ベクトル検索を用いれば検索品質を 96% 以上維持可能である。原文と蒸留テキストを融合させることで、さらに原文単独を上回る検索精度を達成できる。これは、エージェントが長期にわたって文脈を維持し、人間と対称的な記憶を持つための実用的な解決策となる。

制限事項: 評価は単一ユーザーのデータに限定されており、LLM による評価者の合意度（Kappa 統計量）は低めであったが、主要な傾向（ベクトル検索の優位性、BM25 の劣化）はすべての評価者で一貫していた。