LongMemEval 83.2% なぜこの数字が99%よりも意味があるのか
6回の繰り返し実験がリーダーボードの数字以上のことを教えてくれました。
先週、Supermemoryという企業がLongMemEval_Sで約99%の正答率を達成したというブログ記事を公開しました。記事は瞬く間に拡散され、その後彼らは記事を更新しました。すべては「社会実験」であり、現在のメモリ・ベンチマーキング文化がいかに無意味になっているかを示すパロディだったという説明でした。
彼らの指摘は正しかったのです。そして私たちは、その問題を身をもって体験しました。
Nunchi AIではNexusを開発しています。NexusはSynapsisアトマイゼーションエンジンを基盤としたAIエージェント向けメモリインフラです。私たちはこの1週間、LongMemEval_Sを研究用プロトタイプではなく、実際のプロダクションエンジンで動かしました。リーダーボード用の12エージェント・アンサンブルではなく、実際のAPIトラフィックを処理しているそのエンジンです。
最終スコアは83.2%でした。ここでは、その数字自体よりも、その数字に到達するまでの過程がなぜ重要なのかについてお話しします。
LongMemEvalが実際にテストしていること
LongMemEval_SはICLR 2025で発表された500問の質問ベンチマークです。各質問には30～50の対話セッション、約11.5万トークンが付随し、メモリシステムはこれを収集・インデックス化し、再検索して回答しなければなりません。このベンチマークは5つの主要な能力を評価します。
- 情報抽出: 単一セッションから特定の事実を取り出す能力
- 嗜好把握: ユーザーの暗黙的な好みを理解する能力
- マルチセッション推論: 複数セッションに分散した事実を統合する能力
- 時系列推論: 日付計算や出来事の順序を扱う能力
- 知識更新: 古い情報が新しい情報に置き換わったことを認識する能力
このベンチマークが難しい理由は、50のセッションのうち正解が1～3セッションにしか隠れていない場合が多く、質問も意図的に間接的だからです。一部は複数セッションにまたがるカウント、比較、日付計算を要求します。
v1 ベースライン: 76.8%
LongMemEvalのセッションをそのままプロダクションのSynapsisパイプラインに投入しました。対話、アトマイゼーション、ベクトル保存、コサイン類似度検索、LLMによる回答生成という流れです。
v1のスコアは以下の通りです。
- 情報抽出（ユーザー）: 95.7%
- 情報抽出（アシスタント）: 98.2%
- 嗜好把握: 66.7%
- マルチセッション推論: 66.9%
- 時系列推論: 66.2%
- 知識更新: 83.3%
- 全体: 76.8%
単一セッション抽出のスコアが高かったのは、コア検索エンジンが機能していることを示していました。一方、低いカテゴリはどこを改善すべきかを示していました。
v2 過剰エンジニアリングの惨事: 60.8%
診断に自信を持ち、すべてを一度に投入しました。マルチクエリ分解とRRF、時系列加点、古いatom削除ロジック、クエリ拡張、日付順再配列まで実装しました。
結果は60.8%でした。時系列推論は66.2%から12.8%に崩壊し、知識更新は83.3%から57.7%に落ちました。
原因は3つありました。
- 時系列加点が検索ランキングに時間的近接度を注入し、単に最近のatomが本当に関連するatomより上位に来てしまいました。
- 知識削除ロジックが古いatomを削除し最新情報だけを残しましたが、ベンチマークは古い情報と新しい情報を両方見てどちらが現在かを判断する必要がありました。
- 日付順再配列がコンテキストウィンドウ内の順序を変え、関連するatomをトークン制限の外に押し出してしまいました。
教訓は明確でした。検索順序をいじってはいけません。
v4 洗練された失敗: 72.4%
もう少し原則的なアプローチも試しました。検索、証拠パッキング、回答の3段階パイプラインを作り、カテゴリ別パッキング戦略も導入。ラウンドロビンによるセッション多様性、GPT-4o-miniによる嗜好要約、上位20件の最新順再配列も適用しました。
構造は洗練されていましたが、結果は72.4%。v1より低いスコアでした。
問題点は似ていました。
- atomの順序を再配置するすべてのパッキング戦略がスコアを下げました。
- 嗜好要約レイヤーは、元のatomが持っていた情報を失いました。
- ラウンドロビン多様性は、関連度の高いatomの代わりに関連度の低いatomを入れてしまいました。
メモリ検索の三原則
v4までの実験で、3つのルールが明確になりました。
- atomを削除しないこと。 正解が新旧情報の比較を要求する場合があります。
- atomの順序を変えないこと。 コサイン類似度ランキングがLLMリーダーにとって最良のコンテキスト配置です。
- 類似度以外のシグナルを検索スコアに注入しないこと。 時間、最新性、新鮮さはランキング関数の外で扱うべきです。
これらは単なるベンチマークのコツではなく、プロダクションエンジン設計の制約条件となりました。
v5 プロンプトのみ変更: 80.6%
三原則を受け入れ、検索はv1のままにしてプロンプトだけを変更しました。
- 嗜好把握のプロンプトを変更したところ、66.7%から90.0%に上昇。
- 知識更新のプロンプトを変更したところ、83.3%から91.0%に上昇。
- 時系列推論でquestion_dateを基準点として明示したところ、66.2%から72.9%に上昇。
全体スコアは80.6%となりました。検索やアーキテクチャの変更は一切なく、LLMリーダーにより良い指示を与えただけでした。
v6 読み取りミス修正: 83.2%
残ったマルチセッションの誤答を分析すると、46件中20件で同じパターンが見られました。LLMは必要なatomをすべて持っていたのに、カウントを途中で止めていました。正解が4なのに「最低3つ」と答えたり、リストの最後の項目を抜かしたり、断定せず曖昧に答えていました。
修正はプロンプト1行でした。
回答前にすべてのメモリをスキャンし、関連項目をすべて番号付きリストで抽出し、全リストを数えて正確な数字で答えるよう指示しました。「最低」とは言わないようにも明示しました。
その結果、マルチセッションは65.4%から76.7%に上昇し、全体は83.2%となりました。
v5とv6を比較すると、どこで改善が起きたのかがより明確に分かります。
| カテゴリ | v5 | v6 | 変化 |
|---|---|---|---|
| Info Extraction (User) | 94.3% | 95.7% | +1.4 |
| Info Extraction (Asst) | 98.2% | 100.0% | +1.8 |
| Preference Recall | 90.0% | 83.3% | -6.7 |
| Multi-Session | 65.4% | 76.7% | +11.3 |
| Temporal Reasoning | 72.9% | 72.2% | -0.7 |
| Knowledge Update | 91.0% | 89.7% | -1.3 |
| Task-Averaged | 85.3% | 86.3% | +1.0 |
| Overall | 80.6% | 83.2% | +2.6 |
v6最終スコアの内訳は以下の通りです。
- 情報抽出（ユーザー）: 95.7%
- 情報抽出（アシスタント）: 100.0%
- 嗜好把握: 83.3%
- マルチセッション推論: 76.7%
- 時系列推論: 72.2%
- 知識更新: 89.7%
- 全体: 83.2%
83.2%が実際に意味すること
この数字が何であり、何でないのかを明確にお伝えします。
この数字は、実際のAPIトラフィックを処理する同一のSynapsisパイプラインを、最も厳格な公開長期メモリベンチマークで、GPT-4oを回答生成モデルおよび採点モデルとして使用して評価した結果です。
逆にこの数字は、この特定のベンチマークだけのために最適化された研究用プロトタイプのスコアではありません。12エージェント・アンサンブルも作らず、複数プロンプトの中から最良の回答だけを選ぶこともせず、プロダクションに投入しない手法も使いませんでした。
他システムのLongMemEval_S結果と比較すると以下の通りです。
- Mastra (Observational Memory): 95%、GPT-4o基準。研究アーキテクチャであり、まだプロダクションAPIではありません。
- Emergence AI: 86%、GPT-4o基準。RAGベースでレイテンシは5.65秒。
- Supermemory (ASMR): 約99%、自認するパロディで検索1件あたり12並列エージェントを使用。
- Supermemory (プロダクション): マルチセッション71.4%、時系列推論76.7%。実エンジンの公開カテゴリ別スコア。
- TiMem: 76.88%、GPT-4o-mini基準
- Zep/Graphiti: 71.2%、GPT-4o基準
- Long-context GPT-4o, メモリなし: 約60%
私たちの83.2%は、プロダクション実用システムの中で上位に位置します。そして残り16.8%がどこにあるかも把握しています。マルチセッション検索と時系列推論です。どちらもマルチクエリ検索やアンカー型キーワード抽出など、明確な解決策があるエンジニアリング課題です。
回答モデルがなぜこれほど重要なのか
v6の結果を確定した後、同じ検索パイプラインとプロンプトを3つの異なるLLMで実行しました。同じatom、同じコンテキスト順、同じ指示文で、リーダーモデルだけを変更しました。
| カテゴリ | n | GPT-4o | GPT-4o-mini | GPT-OSS-120B (Groq) |
|---|---|---|---|---|
| 情報抽出（ユーザー） | 70 | 95.7% | 95.7% | 95.7% |
| 情報抽出（アシスタント） | 56 | 100.0% | 100.0% | 98.2% |
| 嗜好把握 | 30 | 83.3% | 80.0% | 43.3% |
| マルチセッション推論 | 133 | 76.7% | 62.4% | 25.6% |
| 時系列推論 | 133 | 72.2% | 57.1% | 64.7% |
| 知識更新 | 78 | 89.7% | 80.8% | 82.1% |
| 全体 | 500 | 83.2% | 73.8% | 63.8% |
パターンは明確でした。単純な事実抽出はモデルにほとんど依存しません。3モデルとも単一セッション検索では95%以上を記録しました。違いは、複雑な指示をどれだけ安定して守れるかで現れました。
GPT-4o-miniは全体で9.4ポイント低下し、最大の落差はマルチセッションと時系列推論で見られました。まさにv6プロンプトが「すべての項目を列挙して数えよ」「この基準点から日付を計算せよ」と要求するカテゴリです。miniはこの指示を安定して守れませんでした。
GPT-OSS-120Bはマルチセッションで25.6%に崩壊しました。atomがコンテキスト内に存在しているのにモデルが列挙できないカテゴリです。総117Bパラメータのうち、フォワードパスごとに5.1Bしか活性化しない構造のため、単純抽出は得意でも長いコンテキストで複雑な多段階カウントを維持できません。嗜好把握43.3%も同様です。分散した証拠から暗黙的パターンを統合する作業が活性パラメータ予算を超えてしまうのです。
ここから2つの結論が導かれます。
ベンチマーキングの観点では、回答モデルを公開していないLongMemEvalスコアは意味が薄いです。同じ検索エンジンでも、どのLLMがコンテキストを読むかで83.2%にも63.8%にもなります。結果を報告するシステムは、最終回答を生成するモデルを正確に明示すべきです。
プロダクションの観点では、メモリ検索は必要条件であって十分条件ではありません。リーダーモデルが天井です。検索がボトルネックでなくなるまで検索に投資し、その後は回答モデルが制約条件となります。Nexusの単一セッション抽出が95～100%なのは、単純クエリでは検索がすでに天井に達していることを示しており、残る改善余地はすでに検索されたものをリーダーがどれだけうまく推論できるかにかかっています。
誠実なベンチマーキング・マニフェスト
Supermemoryの社会実験は、実際の問題を浮き彫りにしました。メモリベンチマークがゲーム化されているという点です。アンサンブル手法、プロンプト変種選択、研究専用パイプラインがプロダクション品質と無関係な数字を生み出しています。
そのため、LongMemEvalの結果を報告する際には、最低限以下の基準が必要だと考えます。
- システムがプロダクションか研究専用かを明示すること
- 全体スコアだけでなくすべてのカテゴリスコアを公開すること
- 回答生成モデルを公開すること
- 繰り返し実験の履歴を公開すること
私たちがv2の60.8%、v4の72.4%といった失敗を隠さない理由もここにあります。最終的な数字以上の洞察が、その失敗の過程に詰まっているからです。
メモリレイヤーはAIエージェントの次なる基幹インフラです。ツールやエージェント協調と同じくらい重要です。そのインフラは誠実な測定を受けるに値します。
LongMemEval自体はLongMemEval GitHubリポジトリでご覧いただけます。NexusはAMCP、Agent Memory Continuity Protocolを実装するメモリエンジンです。詳細はNexusでご確認いただけます。
Nexus v6 LongMemEval_S結果: 全体83.2%、テスト時点2026年3月。エンジンバージョン: Synapsisプロダクション。回答モデル: GPT-4o。採点モデル: GPT-4o、LongMemEvalデフォルト設定。