昨日、「"100% on LoCoMo"」および「LongMemEvalで記録された最初のパーフェクトスコア。500/500の問題、あらゆるカテゴリが100%。」と主張する、新しいオープンソースのメモリ・プロジェクト「MemPalace」がローンチされました。ローンチの投稿（ツイート）はバズり、150万回超の閲覧を記録した一方で、リポジトリは24時間未満でGitHubスターを7000以上獲得しました。
興味深いのは、見出しの数字が誇張されていること自体ではありません。興味深いのは、プロジェクト自身のBENCHMARKS.mdファイルがそれを詳細に記録しているのに対し、ローンチのツイートではこうした注意点が省かれていることです。いくつかの失敗モードは、ここ1年以上この分野が論争している方法論上の争点（Zep vs Mem0、Lettaの「Filesystem All You Need」に関する再現性ポストなど）と一致しています。
1. LoCoMoの100%はtop_kの回避（bypass）です。
ランナーはtop_k=50を使用します。LoCoMoの10の会話はそれぞれ19、19、32、29、29、28、31、30、25、30セッションです。すべての会話が50未満のセッション数なので、top_k=50は毎回、候補プールとしてその会話全体を取得します。Sonnetの再ランキングはその後、すべてのセッションについて読解（reading comprehension）を行います。
BENCHMARKS.mdには、これがそのままこう書かれています：
top-k=50でのLoCoMo 100%の結果には構造的な問題があります。10個の会話はいずれも19〜32セッションですが、top-k=50はその数を超えています。これにより、埋め込みモデルのランキングに関係なく、正解（ground-truth）のセッションは常に候補プールに入っています。Sonnetの再ランクは本質的に、すべてのセッションに対して読解を行っているだけで、埋め込みによる検索ステップは完全に回避されています。
同じファイルにある正直なLoCoMoの数値は、再ランクなしでR@10が60.3%、LLMなしのハイブリッドスコアリングでR@10が88.9%です。これは実際のもので、特に目立つものではありません。さらに、公開されているLoCoMoのバージョンでは、100%も独立に不可能です。なぜなら、答えキーの約6.4%には、幻覚的な事実、誤った日付、話者の帰属エラーが含まれており、どんな誠実なシステムでもそれらには同意しないからです。
2. LongMemEvalの「パーフェクトスコア」はメトリクスのカテゴリ誤りです。
公開されているLongMemEvalはエンドツーエンドQAです。過去のチャットセッションの「藪（haystack）」から検索して、回答を生成し、GPT-4がそれを評価して正しいかどうかを判定します。公開リーダーボード上のあらゆるスコアは、「生成された回答」のうち正しいと判断された割合です。
MemPalaceのLongMemEvalランナーは検索のみを行います。500の各質問について、セッションごとに1つのドキュメントを作り、ユーザー側の発話だけを連結します（アシスタント側の発話は一切インデックス化されません）。デフォルトのChromaDB埋め込み（all-MiniLM-L6-v2）で埋め込み、コサイン距離が上位5のセッションを返し、正解のセッションIDに対して集合としての一致（set membership）を確認します。recall_any@5とrecall_all@5の両方を計算し、プロジェクトはより緩い方を報告します。
回答を生成することはありません。ジャッジも呼び出しません。なお、このリポジトリにあるLongMemEvalの数値は、100%も、98.4%の「held-out」も、96.6%の生のベースラインも含めて、公開リーダーボードが意味する意味でのLongMemEvalスコアではありません。これらは同じデータセットに対するrecall_any@5の検索数値であり、はるかに簡単なタスクです。それらのいずれかを「LongMemEvalのパーフェクトスコア」と呼ぶのは、メトリクスのカテゴリ誤りです。
3. 100%そのものが「テストに教える（teaching to the test）」です。
100%を出すハイブリッドv4モードは、開発セットで残っていた誤答3つを調べ、それぞれに対して狙いを定めたコードを書いて作られました。単一引用符で囲まれた特定のフレーズを含む質問には「引用句のブースト」、Rachelという人物名の質問には「人物名のブースト」、高校の同窓会に関する質問には「『I still remember』／『when I was in high school』」のパターンです。つまり、3つのパッチで3つの特定の質問に対応しただけです。
BENCHMARKS.md、461行目、抜粋（verbatim）：
これはテストに教えることです。修正は、一般的な失敗パターンを分析して見つかったのではなく、正確な失敗ケースを中心に設計されました。
4. コードに存在しない「売りにされている機能」。
ローンチ投稿には、「"contradiction detection catches wrong names, wrong pronouns, wrong ages before you ever see them"（矛盾検出が、見る前に誤った名前・誤った代名詞・誤った年齢を見つける）」が機能として列挙されています。mempalace/knowledge_graph.pyには「contradict」への一致が一切ありません。唯一の重複排除ロジックは、（subject, predicate, object）のトリプルに対する完全一致チェックで、同一トリプルを2回追加することを防ぐだけです。同じ主語に関する矛盾した事実は、際限なく蓄積し得ます。
5. 「30x lossless compression（30倍のロスレス圧縮）」は、プロジェクト自身のベンチマークでは測定可能なロスがあります。
圧縮モジュール mempalace/dialect.py は、55文字で文を切り詰め、キーワード頻度でフィルタし、さらに元のテキストを復元せずに、圧縮文字列をヘッダ辞書へ分割するdecode()関数を提供します。ラウンドトリップはありません。
同じBENCHMARKS.mdでは、results_raw_full500.jsonlが96.6%のR@5、results_aaak_full500.jsonlが84.2%のR@5と報告されています。これは、同じデータセットかつ同じメトリクスに対して、プロジェクト自身が実行したものとしては12.4ポイントの低下です。ロスレス圧縮が測定された品質低下を引き起こせないのは明らかです。
ベンチマークの会話にとって重要な点。
この分野には、ジャッジの信頼性が敵対的に検証されているベンチマークと、評価パイプラインが標準化されるか、もしくは完全に開示されている必要があります。それまでは「LoCoMoで100%」という見出しはこれからもバズり続け、注意点を記したBENCHMARKS.mdファイルは、おそらく誰も読まないままであり続けるでしょう。MemPalaceで異常なのは、個々の失敗モードが特別に何かということではありません。ひとつのリポジトリに、それらがあれだけ一度に揃っていて、しかもバズるリーチを伴うローンチの中で出ていること。そして、ローンチ上のコミュニケーションでは省かれている問題の大部分を、プロジェクト自身の内部ドキュメントが誠実に開示していることです。
最初の24時間で、他にも2つの独立した技術的批評が投稿されました。issue #27でのREADMEとコードの突合・分解（teardown）と、もう1つ（中国語）の#30です。
開示：私たちは自前のメモリ・システムに取り組んでいます。引用はすべて、リンクされたリポジトリに対してオープンで検証可能です。
注：Redditのスパムフィルタの都合でリンクは省略しています。最初のコメントに、全文の記事、BENCHMARKS.mdの引用、PenfieldのLoCoMo監査、引用されたZep / Mem0 / Lettaのポストがあります。
[link] [comments]
