Memora: 長期タスク向けの拡張型メモリシステム

要約概要

• 目的

  • AIエージェントが会話・文書から必要な情報を自動抽出し、長期的に保存・検索できるよう支援するメモリフレームワーク

• 中核設計

  • 元の全文であるMemory valueはそのまま保持し、検索にはPrimary abstractionとCue anchorsを使用

• 主な差別化要素

  • 原文全体を直接埋め込む一般的なRAGより、情報損失と検索の曖昧さを減らす構造を志向

• 主な機能

  • メモリの自動抽出、重複排除、統合・更新、意味ベース検索、キーワード検索、LLMベースの多段検索をサポート

• 適用対象

  • 長期対話型AI、マルチエージェントシステム、パーソナライズドサービス、文書ベースの知識管理

• 現在の状態

  • PythonベースのMITライセンス公開プロジェクトで、ベンチマークと実験機能を含むが、初期公開段階に近い

---

序論

エージェントのメモリ管理の複雑さを解決

• 既存のAIエージェント開発では、次の問題を開発者が直接処理する必要がある

  • どの情報をメモリとして保存するかを決める
  • 保存された情報をいつ更新または削除するかを判断する
  • ユーザーの質問に関連する記憶を検索する
  • 重複または衝突する記憶を管理する

• Memoraは、このようなメモリのライフサイクルをフレームワーク内部で処理することを目指す

• 開発者は、低レベルの保存・検索ロジックよりも、エージェントの業務機能と応答生成に集中できる

既存メモリ構造の限界

• 一般的なRAGシステム

  • 文書や会話の原文を一定サイズに分割
  • 各断片を埋め込み、ベクターデータベースに保存
  • 質問と意味的に近い断片を検索

• この方式は実装が簡単だが、次の問題が発生しうる

  • 長い文脈が複数の断片に分離される
  • 類似表現の情報が重複保存される
  • 単純な意味類似度が実際の質問意図と一致しないことがある
  • 圧縮された要約だけを保存すると詳細情報が失われる可能性がある

• グラフ型知識ベースは関係表現には有利だが、スキーマや関係構造を継続的に管理しなければならない負担がある

---

本論

原文と検索構造を分離

• Memoraの各メモリは3つの要素で構成される

Memory value

• 実際に保存される全情報
• 原文と詳細内容を圧縮せず保持
• 検索インデックスには直接含めない
• 情報損失なく元の文脈を維持する役割

Primary abstraction

• そのメモリが何についてのものかを示す代表要約
• 1つのメモリごとに1つ生成
• 検索、更新、統合、重複排除の基準として活用
• メモリの同一性を示す標準単位として使用

Cue anchors

• 1つのメモリにアクセスするための複数の意味的手がかり
• 人物、対象、出来事、主要属性などを組み合わせて構成
• 1つの記憶に複数の手がかりを接続できる
• 複数の記憶が同じ手がかりを共有する多対多構造を形成

検索対象の選択的インデックス化

• Memoraはすべての原文を直接インデックス化しない

• 実際の検索には次の情報のみを使用

  • Primary abstraction
  • Cue anchors

• 検索が完了すると、関連付けられた元のMemory valueを返す

• この構造の目的

  • 検索表現と実際の保存情報を分離
  • 検索インデックスを簡潔に保つ
  • 原文の詳細情報をそのまま保持
  • 原文埋め込みで発生しうる意味的ノイズを低減

RAGとグラフ構造の中間形

• 一般的なRAGより構造化された検索手がかりを提供

• グラフデータベースのように、すべての関係を厳密なスキーマで定義しない

• 記憶の上に抽象化レイヤーを追加し、柔軟性と構造性を同時に確保しようとする方式

• 中核となる方向性

  • 原文は自由な形で保存
  • 検索と接続には構造化表現を使用
  • 保存構造と検索構造を独立して管理

---

メモリ生成から応答までの処理フロー

1. メモリ収集

• エージェントが会話または文書を処理

• 内容から次の情報を自動抽出

  • 事実情報
  • 出来事および経験
  • 手順と作業方法

• 長い会話はトピック別のエピソードに分割

• 重要情報を構造化メモリ項目に変換

2. インテリジェント保存

• ChromaDBベクターデータベースを基本ストレージとして使用

• 意味埋め込みを用いてメモリを保存

• 新しい情報が入力されると既存メモリと比較

• 類似または重複する情報に対して次の処理を実行

  • 重複排除
  • 既存の記憶と統合
  • 古い情報を更新

• 必要に応じてCue indexを生成し、構造化検索を支援

3. 適応型検索

• 質問の種類と設定に応じて複数の検索戦略を提供

Semantic検索

• 質問とメモリ表現の間のベクトル類似度を計算
• 実装が単純で、一般的な質問に適用可能
• 表現が異なっても意味が近い情報を見つけられる

Prompted検索

• LLMが検索プロセスを段階的に実行
• 初回検索結果をもとに検索語と検索範囲を反復調整
• 複合質問や複数の記憶を組み合わせる必要がある質問に適する
• LLM呼び出しが追加されるため、コストと応答時間が増加しうる

Hybrid検索

• ベクトルベースの意味検索とBM25・キーワード検索を組み合わせる
• 意味的類似性と正確な単語一致を併用
• 固有名詞、製品名、コード、日付などの検索漏れを減らすのに有利

GRPO検索

• 強化学習で訓練された検索ポリシーを使用
• 質問に必要なメモリを選択する方法自体を学習
• LLMベースの反復検索をローカル微調整モデルに置き換えることを目指す
• 現在は実験的機能に分類される

4. 回答生成

• 検索されたメモリを所定形式で構成
• その内容をLLMプロンプトに挿入
• LLMは質問と検索された記憶を併用して応答を生成
• 回答が保存済みメモリに根拠を持つよう誘導

---

メモリ品質を維持する管理機能

• メモリを追加し続けるだけのフラットなストレージとは異なり、既存メモリの状態を管理

• 主な管理機能

  • 重複した記憶の削除
  • 類似した記憶の統合
  • 変更された事実の更新
  • メモリ構造の再整理

• Primary abstractionをメモリ更新と統合の基準として使用

• 時間とともにメモリが無制限に重複蓄積する問題を減らすことを目指す

多様なメモリタイプをサポート

• メモリ値と抽象化方式を変えることで、複数の種類の記憶を表現できる

事実的記憶

• 人物、場所、属性、設定などの比較的安定した情報
• 例: 特定ユーザーの勤務地、好みのツール、プロジェクトの技術スタック

エピソード記憶

• 特定時点で発生した出来事や会話
• 例: 過去の会議で決定された内容、特定のエラーを解決した過程

手続き記憶

• 作業方法や再利用可能な手順
• 例: サーバー配備手順、エラー点検順序、文書生成ルール

---

マルチエージェントの記憶共有と分離

• 同じ環境で動作する複数のエージェントが共通メモリ空間を使用できる

• あるエージェントが保存した情報を別のエージェントが再利用できる

• エージェントまたは役割ごとにメモリ範囲を制限することもできる

• 期待される効果

  • エージェント間の知識重複を削減
  • 作業引き継ぎを改善
  • 共通プロジェクト情報の一貫性を維持

• アクセス制御と分離機能により、選択的共有と個人情報保護を支援する構造

保存インフラと表現構造の分離

• メモリ表現方式が特定ストレージに強く依存しないよう設計

• プロジェクト構造には次のデータベース接続機能が含まれる

  • ChromaDB
  • Redis

• ローカルまたはリモートの保存環境に適用可能

• 保存バックエンドを変更しても、メモリの抽象化・手がかり構造は維持できる

---

基本的な利用方法

• Python 3.10以上が必要
• GitHubリポジトリを複製した後、パッケージをインストール
• MemoraClientを作成し、ユーザーまたはエージェント識別子を指定
• add()を使って会話や文書をメモリに追加
• query()を使って意味ベース検索を実行
• advance_query()を使ってPromptedまたはGRPO方式の高度な検索を実行

エージェント連携構造

• ユーザーメッセージを受け取ると、まず関連メモリを検索

• 検索結果とユーザー質問を用いて回答を生成

• 生成された回答とユーザーメッセージを1つの会話記録として構成

• その会話を再びMemoraに保存

• 反復プロセス

  • 質問を受信
  • 関連記憶を検索
  • 応答を生成
  • 会話を保存
  • 後続の質問で再利用

---

長期メモリ性能評価

LoCoMoベンチマーク

• 長期間にわたる会話で記憶検索能力を評価

• 主な評価タイプ

  • 単一ステップ質問
  • 複数情報を組み合わせる多段質問
  • 時間関係質問
  • オープンエンド質問

• Semantic、Prompted、Cue indexなどの組み合わせを試験できる

LongMemEvalベンチマーク

• 長期メモリシステムの多様な質問処理能力を評価
• エピソードメモリと意味検索設定を適用できる
• 実際の長期対話環境で情報保持と検索性能を検証する用途

GRPOベース検索ポリシー学習

• 検索手順を強化学習ポリシーとして学習させる実験機能

• 処理段階

  • 現在のポリシーで検索経路を生成
  • 検索結果の根拠性・重複・コストを評価
  • グループ相対的優位性を計算
  • GRPO方式で検索ポリシーを学習

• Qwen 3Bまたは7B系モデルとLoRA微調整を例示

• 学習にはGPUが必要

• 目標

  • 毎回の検索で外部LLMを呼び出すコストを削減
  • 特定データと業務に最適化された検索戦略を構築

• 制約

  • 学習データと評価基準が必要
  • モデル訓練と運用管理が追加される
  • 一般利用者がすぐ適用するにはSemantic検索より複雑

---

主な利点

• 原文の詳細情報を圧縮せず保持可能
• 検索用表現と実際の情報が分離され、メモリ構造が明確
• メモリの重複排除と更新を体系的に処理できる
• 意味検索、キーワード検索、LLM検索、強化学習検索を選択できる
• 事実的・エピソード的・手続き的記憶を1つのフレームワークで管理可能
• 複数のエージェントが同じ記憶を共有できる
• 既存のエージェントシステムに比較的少ない変更で統合することを目指す
• ローカルおよびリモートの保存構造の両方をサポート可能

構造的な限界と注意点

• Primary abstractionとCue anchorsの品質が検索性能に直接影響する
• 自動生成された抽象化が不正確だと、原文が正確でも検索で漏れる可能性がある
• 原文を直接インデックス化しない構造は、細かな文言や希少情報の検索に不利な可能性がある
• 重複排除と統合の過程で、異なる出来事が1つの記憶として誤って統合されることがある
• Prompted検索は複数回のLLM呼び出しによりコストと遅延が増加しうる
• GRPO方式はGPU、学習データ、評価体系が必要で、運用の複雑性が高い
• マルチエージェント共有メモリでは、アクセス権限と情報分離を明確に設計する必要がある
• 個人情報や機密性の高い会話を保存する場合、別途暗号化・削除・保持ポリシーが必要
• 公開リポジトリにはリリースがなく、参加者と利用指標も少ないため、大規模運用の安定性が十分検証されたとは言いがたい

---

結論

構造化されたアクセス層を追加した長期メモリ方式

• Memoraは、原文全体を単純にベクトル化する方式から離れ、次の構造を提案する

  • 詳細内容はMemory valueに保持
  • 代表的意味はPrimary abstractionで表現
  • 多様な検索経路はCue anchorsで構成

• 中核的価値は情報保持と検索効率のバランスにある

• 単純な文書検索より、次の環境で活用可能性が高い

  • 長期間ユーザーと相互作用するパーソナライズドエージェント
  • 多数の開発・業務文書を継続的に蓄積するシステム
  • 複数役割のエージェントが知識を共有する環境
  • 過去の決定と作業手順を再利用する必要があるプロジェクト

導入前の検証が必要

• 実際に適用する際は、次の要素を優先的に検証する必要がある

  • 日本語文書の抽象化とCue生成品質
  • 既存RAGと比較した検索精度
  • メモリ統合過程の誤り率
  • 長期運用時のデータ増加量と検索速度
  • LLMおよび埋め込みAPIのコスト
  • 個人情報保存とアクセス制御の方式

• 初期段階では、主要文書の一部を対象に小規模PoCを行い、一般的なRAGおよびハイブリッド検索方式と性能を比較するアプローチが適切