技術概要：SMMBench

問題定義

現在のマルチモーダルエージェントのメモリに関するベンチマークは、主に事前構成された一貫した文脈内（例えば、単一の長い会話や統合された検索コーパス）でのシステムを評価する。しかし、現実世界のエージェントタスクでは、ソース分散型の証拠に基づいた推論が求められることが多い。これは、個別のグループチャット、プライベートメッセージ、プロフィール、スクリーンショット、テーブル、ドキュメントなど、複数の独立して生成されたアーティファクトにまたがって断片化された証拠を指す。

特定された核心的な課題は、単に長い入力を読み取ることでなく、ソース分散型メモリ構成にある。この設定において：

1. ソースレベルの不完全性：単一のソースにはクエリに回答するのに十分な情報が含まれておらず、証拠は複数の異なる起源から集約されなければならない。
2. クロスソースの橋渡し：エージェントは関連するソースを特定し、それらの独立したローカル文脈を橋渡ししなければならない。これらはしばしば異なる目的と異なる時点で作成される。
3. 矛盾の解決：ソース間の情報は矛盾したり陳腐化したりする可能性があり、エージェントは権威レベルと時間的状態に基づいて推論し、メモリを更新する必要がある。

既存のベンチマークは、この特定のボトルネックを評価することにほとんど失敗しており、代わりに単一の統合ストリーム内での長文脈検索に焦点を当てている。

手法：SMMBench の構築

著者は、独立したソース間での証拠構成という課題を実用化するために設計されたデータセット、**SMMBench（Source-distributed Multimodal Memory Benchmark：ソース分散型マルチモーダルメモリベンチマーク）**を導入する。

データセット構築パイプライン

このベンチマークは、自然さと証拠の依存関係を確保するために、3段階のパイプラインを通じて構築される。

1. QA 準備：ChartQA、SlideVQA、MLLMKC、MMPB、M3Bench などの多様な公開マルチモーダルベンチマークからの生サンプルを、統合された証拠単位を持つ質問 - 回答ペアに変換する。
2. 会話ソース合成：事前に定義されたプロフィールを持つエージェントをインスタンス化し、複数のチャネル（グループチャットとプライベートチャット）にわたって多ターン会話を生成する。これらの会話は「ホスト」環境として機能し、ターゲットとなる証拠を当初含まないまま、現実的な長期的相互作用をシミュレートする。
3. ソース認識型証拠挿入：重要な設計選択として、補完的な証拠単位を異なる独立したソースにルーティングする（例えば、あるチャットにチャートを、別のチャットにテーブルを、3 つ目のチャットにプロフィール更新を配置する）。LLM ベースの挿入器は、これらの挿入が会話の流れと時間的一貫性を維持するように保証し、回答に不可欠な証拠が単一のソース内では散在し不完全であるというシナリオを作成する。

ベンチマーク統計と範囲

• 規模：264 の異なるソースに基づいた 1,877 の評価サンプル。
• 分布：平均して、各質問は2.82 のソースと4.54 の証拠項目からの証拠を必要とする。
• モダリティ：テキスト、画像、テーブル、ドキュメントを含む豊かなマルチモーダル構成。平均サンプルには 2.31 のテキスト項目、0.95 の画像項目、1.24 のドキュメント項目が含まれる。
• タスクタイプ：このベンチマークは、5 つのタスクカテゴリにわたって 4 つの中核能力を評価する。
  1. シングルホップおよびマルチホップ QA：複数のソースからの証拠を検索し、推論する。
  2. 矛盾の解決：陳腐化または矛盾する記録よりも新しい/権威のある証拠を特定し、優先する。
  3. 推論の推論：相互作用に分散された暗黙の手がかりからユーザーの好みを推測する。
  4. 関数呼び出し（アクション予測）：分散型マルチモーダルコンテンツから復元されたパラメータに基づいて、正確なツール呼び出しを実行する。

評価プロトコル

このベンチマークは、オープンブック（完全な文脈アクセス）と検索ベースの両方の設定をサポートする。システムは以下の点で評価される。

• クロスソース推論：エージェントは断片を特定し、結合できるか？
• 矛盾処理：エージェントは矛盾を解決できるか？
• アクションのグラウンディング：エージェントは記憶された事実を実行可能なアクションに変換できるか？

主要な結果

実験は、代表的なメモリスタイルのベースライン（MemGPT、MIRIX、Mem0 など）とRAG スタイルのベースライン（Native RAG、HMRAG、VRAG など）を使用して、1,877 のサンプルで行われた。

1. 性能ギャップ：現在のシステムは大きく苦戦している。最も強力なベースライン（HMRAG）でさえ、全体のスコアは0.4933であり、正しい証拠を直接モデルに提供するゴールド証拠ベースライン（0.7473）と比較して、0.2540 という大きなギャップが残っている。
2. ソース分散型の難易度：同じ証拠を単一のソースに集中させた場合（ソース集中設定）、すべてのベースラインで性能が向上した。これは、難易度がコンテンツの量だけでなく、独立したソース間での証拠の分散に特有のものであることを確認している。
3. タスク固有の課題：
   • 関数呼び出しは最も困難なタスクであることが判明した（最高スコア：0.1111）。これは、アクション実行のために散在するマルチモーダル証拠から正確なパラメータを復元することが主要なボトルネックであることを示している。
   • 推論の推論と矛盾の解決も、事実ベースの QA タスクと比較して大幅な低下を示した。
4. 検索対構成：検索予算（$K$）を増加させることでリコールは向上したが、それはしばしば精度を低下させるノイズを導入した。結果は、検索だけでは不十分であることを示唆しており、ソース境界を越えて検索された証拠を構成し調整する能力が主要な失敗点である。
5. モダリティの影響：ネイティブなマルチモーダルアクセスは、問題を均一に解決しなかった。一部のシステム（MIRIX など）はネイティブなマルチモーダル入力によって改善されたが、他のシステム（MemGPT など）はパフォーマンスが低下し、ボトルネックはモダリティの知覚ではなく、クロスソースメモリアーキテクチャにあることを示唆している。

エラー分析

600 の失敗事例の診断は、層状の失敗モードを明らかにした。

1. アクセス失敗（61.8%）：支配的なエラータイプは、メモリから必要な分散証拠を表面化できないことである。
2. 利用失敗（16.5%）：証拠が検索されたとしても、エージェントはソース間で手がかりを構成したり、陳腐な記録よりも更新された証拠を優先したりすることに失敗する。
3. アクション失敗（8.2%）：エージェントは記憶された情報を正しい実行可能な出力（関数呼び出しエラー）に変換することに失敗する。

意義と主張

この論文は、ソース分散型メモリ構成が、マルチモーダルエージェントにとって過小評価されているが重要なボトルネックであると主張する。

• 問題の特定：現実世界のエージェントメモリにおける難しさは単なる「長文脈」ではなく、「クロスソース」推論であることを浮き彫りにする。
• ベンチマークへの貢献：SMMBench は、異種で独立して生成されたソースからの証拠を検索し、整合させ、構成するエージェントの能力を体系的に評価する最初の試みを提供する。
• 実証的洞察：結果は、現在の最先端のメモリおよび RAG システムがこの設定では効果的ではないことを示している。検索と成功した構成の間のギャップは、将来の進展には、単にコンテキストウィンドウや検索プールのスケーリングではなく、ソース認識型メモリ管理とクロスソース証拠の調整を可能にするアーキテクチャが必要であることを示唆している。

著者は、マルチモーダルエージェントメモリの進展は、一貫した文脈内での性能だけでなく、現実世界の情報の断片的でソース分散型の性質を処理する能力によって評価されなければならないと結論付けている。