記憶検索拡張（キオクケンサクカクチョウ）
LLMエージェントがベクトルデータベースやナレッジグラフから過去の記憶を選択的に検索・想起し、現在のタスクに活用する技術。RAGの記憶版として位置づけられ、エージェントの経験学習と適応的行動を可能にする。
記憶検索拡張とは
記憶検索拡張（Memory Retrieval-Augmented）は、LLMエージェントが外部記憶ストア（ベクトルDB、ナレッジグラフ、リレーショナルDB）から過去の経験・対話・学習結果を選択的に検索し、現在のタスクコンテキストに注入する技術である。RAG（Retrieval-Augmented Generation）が静的なドキュメント検索であるのに対し、記憶検索拡張はエージェント自身が生成・蓄積した動的な記憶を対象とする点が本質的に異なる。
2024年のSelf-RAG（Asai et al.）やCRAG（Yan et al.）の登場により、検索の自律的判断（「検索すべきかどうか」をLLM自身が決定）が可能になり、記憶検索拡張の実用性が飛躍的に向上した。
記憶検索のアーキテクチャ
基本フロー
- クエリ生成: 現在のタスクコンテキストから検索クエリを自動生成
- 埋め込み変換: クエリをベクトル化（Qwen3-Embedding-8B: 4096次元、text-embedding-3-large: 3072次元）
- 検索実行: ベクトルDB/KGに対してTop-K検索（K=5〜20）
- リランキング: 検索結果を関連性・鮮度・重要度で再順序付け
- コンテキスト注入: 上位結果をプロンプトに挿入
- 生成: 注入された記憶を参照してLLMが応答生成
ベクトルDB比較
| ベクトルDB | 次元上限 | 検索速度(1M件) | フィルタリング | ホスティング | 価格帯/月 |
|---|---|---|---|---|---|
| Qdrant v1.12 | 65,536 | 5ms P95 | Payload Filter | Self-host/Cloud | 無料〜$100 |
| Pinecone v3 | 20,000 | 10ms P95 | Metadata Filter | Cloud only | $70〜 |
| Weaviate v1.28 | 65,536 | 8ms P95 | GraphQL Filter | Self-host/Cloud | 無料〜$150 |
| ChromaDB v0.6 | 制限なし | 15ms P95 | Where Filter | Self-host | 無料（OSS） |
| Milvus v2.5 | 32,768 | 3ms P95 | Expression Filter | Self-host/Cloud | 無料〜$200 |
| pgvector v0.8 | 16,000 | 20ms P95 | SQL WHERE | PostgreSQL拡張 | DB費用内 |
検索戦略の比較
1. Dense Retrieval（密ベクトル検索）
テキストを連続ベクトル空間に埋め込み、コサイン類似度で検索。
- 精度: 意味的類似性に強い（同義語・言い換えを捉える）
- 弱点: 固有名詞・型番の完全一致に弱い
- 推奨モデル: Qwen3-Embedding-8B（多言語）、BGE-M3（多言語+マルチグラニュラリティ）、Voyage-3（英語特化）
2. Sparse Retrieval（疎ベクトル検索）
BM25やSPLADEによるキーワードベース検索。
- 精度: 固有名詞・コード・型番に強い
- 弱点: 同義語・言い換えに弱い
- 推奨: Elasticsearch BM25、SPLADE v3
3. Hybrid Retrieval（ハイブリッド検索）
Dense + Sparseの組合せ。Reciprocal Rank Fusion（RRF）で統合。
- 統合式: score = Σ 1/(k + rank_i)、k=60が標準
- 精度向上: Dense単体比で10-15%のRecall改善（BEIR benchmark）
- 推奨: Qdrant Hybrid Mode、Milvus Multi-Vector、Weaviate Hybrid
4. Graph-augmented Retrieval（グラフ拡張検索）
ベクトル検索結果をナレッジグラフで拡張。関連エンティティを2-hopまで辿る。
- 実装: GraphRAG（Microsoft, 2024）、LightRAG、Neo4j + LangChain
- 利点: 関連概念の連鎖的発見、推論パスの明示化
- コスト: グラフ構築に時間（10,000ノードで約30分）
リランキングの技術
検索結果の初期ランキングを改善するためのリランキング手法。
| リランカー | アーキテクチャ | レイテンシ | 精度(NDCG@10) |
|---|---|---|---|
| Cohere Rerank v3.5 | Cross-Encoder | 50ms/クエリ | 0.72 |
| BGE-Reranker-v2.5 | Cross-Encoder | 30ms/クエリ | 0.69 |
| Jina Reranker v2 | Cross-Encoder | 40ms/クエリ | 0.70 |
| RankGPT (GPT-4) | LLM Listwise | 2s/クエリ | 0.74 |
| ColBERT v2 | Late Interaction | 10ms/クエリ | 0.68 |
記憶検索の最適化テクニック
- クエリ拡張: 元クエリからLLMで3〜5の関連クエリを生成し、結果を統合
- Hypothetical Document Embedding（HyDE）: 想定回答を先に生成し、その埋め込みで検索（Gao et al., 2022）
- Multi-Query Retrieval: 複数視点のクエリを並行実行し、結果をマージ
- Contextual Compression: 検索結果をLLMで圧縮し、関連部分のみを抽出（LLMLingua: 圧縮率2-5倍）
- Adaptive Retrieval: 検索の必要性をLLMが自律判断（Self-RAG: 検索不要なら直接生成）
Self-RAGの自律的検索判断
Self-RAG（Asai et al., 2024）は、記憶検索を「常に実行」するのではなく、LLM自身が以下の判断トークンを生成して検索の要否を決定する。
- [Retrieve]: 検索が必要と判断 → 記憶ストアを検索
- [No Retrieve]: 検索不要と判断 → そのまま生成
- [IsRel]: 検索結果が関連性ありと判定
- [IsSup]: 検索結果が生成の根拠として十分と判定
- [IsUse]: 最終出力が有用と判定
この自律判断により、不要な検索を40%削減しつつ、回答精度を維持（FactScore +5%）。
よくある質問（FAQ）
Q1: 記憶検索拡張とRAGの違いは何ですか？ A: RAGは外部ドキュメント（PDF、Web等）からの情報検索に特化するのに対し、記憶検索拡張はエージェント自身の行動ログ・対話履歴・学習結果という「自己生成データ」を検索対象とする。また、記憶検索拡張は時間減衰や重要度スコアなど、記憶特有のランキング要素を持つ。
Q2: 検索のTop-Kはいくつに設定すべきですか？ A: タスクの複雑さとコンテキスト予算に依存する。単純QAではK=3〜5、複雑な推論ではK=10〜20が一般的。コンテキストウィンドウの30%以内に収まるよう調整し、超過する場合はリランキング後に圧縮する。
Q3: ベクトルDBとナレッジグラフはどちらを使うべきですか？ A: 両方の併用が推奨。ベクトルDBは意味的類似性に基づく「あいまい検索」に強く、ナレッジグラフは構造化された関係性に基づく「正確な推論」に強い。GraphRAGパターンでは、ベクトル検索でエントリーポイントを発見し、グラフ走査で関連情報を拡張する。
まとめ
- 記憶検索拡張はRAGの記憶版、エージェント自身の経験データを検索対象とする
- Dense/Sparse/Hybrid/Graph-augmentedの4検索戦略をタスクに応じて選択
- リランキングで初期検索結果を10-15%改善可能
- Self-RAGの自律的検索判断で不要な検索を40%削減
- ベクトルDB+ナレッジグラフのハイブリッド構成が最も効果的