エージェントのメモリを短いコードに圧縮すると、二つのAIは同じ間違った答えで一致するのか？

論文

過去の会話を覚えているエージェントは、それをどこかに保存し、必要な部分をすばやく見つけなければなりません。FlyHashはショウジョウバエの嗅覚から借りた考え方で、各記憶の埋め込みを、ごくわずかな「アクティブビット」だけがオンになる短いスパースなコードに変えます。コードが短いほど、メモリは小さくなります。

論文の結果は、気持ちいいほど素直です。同じコードサイズで、FlyHashはSimHashの約2.5倍の頻度で正しい記憶を取り出します（0.27対0.11）。メモリに余裕がある場合は、標準的なHNSWインデックスが両方を上回り、著者もそう書いています。自分の手法が負ける場面を書く論文は、もっとあっていいはずなのに少なく、私たちが連絡したのはそこに惹かれたからです。

コードは公開されています。github.com/mohanji/flyhash-agent-memory。

会話の経緯

きっかけは、Hugging Faceの論文の下のコメントでした。テンプレート化された質問ではなく、言い換えられた質問に対して、このコードはどう対処するのかを尋ねました。Mohanは、これまでのテストはテンプレート化された言い回しだったと答え、どのデータセットがよいかを聞き返してくれました。私たちが挙げたのは、長くて本物の複数セッションの対話から作られた二つ、LoCoMoとLongMemEvalです。彼はまずLoCoMoから始め、LongMemEvalが続くことにしました。

次に、彼の研究と私たちの研究をつなぐ問いを投げました。いちばん短いコードは、単一の事実についての質問より、時間についての質問（「彼女はいつ引っ越した？」）で多く落ちるのでしょうか。

互いを検証する二つのAIにとって、なぜメモリが重要か

別々の会社の二つのモデルが同じ答えで一致すると、それはよい兆候だと受け取られがちです。でもエージェントの中では、二つのモデルは普通、同じ取得済みメモリを読んでいます。検索が事実を逃していたら、二つはもう独立ではありません。自信たっぷりに、同じ間違った答えで一致することがありえます。

それがどれくらいの頻度で起きるかを見るために、LoCoMo上の小さな公開チェック memory-agreement-check をまとめ、素朴なキーワードメモリ（BM25、上位10件の対話ターン）で1回走らせました。GPTとClaudeが別々に答え、Kimiが何も知らされずに採点しました。

二つのモデルの誤りは強く相関していました（φ = 0.81）。これは1つのリトリーバーと1つのシードによる結果なので、示せるのは関連であって、原因ではありません。それでも、FlyHashに答えてほしい、はっきりした問いが手に入りました。

一緒に走らせている実験

Mohanが取得の側を引き受けてくれ、そこから先は私たちが受け持ちます。

1. Mohan がまず取得を測ります。LoCoMoのカテゴリ（単一ホップ、複数ホップ、時間）ごとのrecall@kを、FlyHashとSimHashの複数のコードサイズ、つまり16、32、64、128のアクティブビットで。質問ごとに上位10件のメモリを使い、最初の実行に合わせます。
2. 私たちは上位5件も加えることを提案しました。メモリが少なければ取りこぼしが増えるので、自信たっぷりに間違った一致の割合がどれだけ速く増えるかが見えるはずです。
3. 彼は取得したコンテキストを、質問1つにつき1行のJSONLで送ります。
4. 私たち が各ファイルに一致チェックを走らせ、結果を彼に送ります。

最後に読み取りたい問いは、こうです。コードが短くなるにつれて、二つのAIが一致して間違える割合は上がるのか。そして、それがいちばん速く上がるのは、時間についての質問なのか。 もしそうなら、小さなメモリには、二つ目のAIによるチェックでは捕まえられない隠れたコストがあります。そうでなければ、FlyHashは論文が言う以上によく見えます。

コード

このチェックは、どんなリトリーバーの出力でも受け付けます。質問1つにつき1行です。

{"qid": "conv-26/0", "memories": [{"text": "[D1:3 | 1:56 pm on 8 May, 2023] Caroline: I went to a LGBTQ support group yesterday...", "dia_id": "D1:3", "score": 0.82}]}

リポジトリには、Mohanのコードの FlyHash と SimHash のクラスを使ってこれらのコンテキストを作る例がすでにあります。

git clone https://github.com/mohanji/flyhash-agent-memory
pip install numpy sentence-transformers
python examples/flyhash_contexts.py --flyhash-src flyhash-agent-memory/src \
  --method flyhash --active-bits 32 --out flyhash-k32.jsonl
python -m memcheck run --backend cli --contexts flyhash-k32.jsonl --memory-name flyhash-k32

同じ質問を複数のコードサイズで、あるいは基準として --method dense に対して走らせると、比較ができます。

最初の数字が言えることと、言えないこと

• 数字は、1つのリトリーバー（BM25）、1組のモデル、1人の審査役、1つのシードによるもので、200問が対象です。別のリトリーバーやモデルなら、どの数字も動きえます。
• BM25が証拠を逃す質問は、他の質問とは性質が違います（複数ホップやオープンドメインの質問は、ずっと頻繁に逃されます）。そのため、比較はカテゴリごとにも行います。
• 因果を調べるテストなら、同じ質問に、証拠のターンがあるときとないときで一度ずつ答えさせます。複数のコードサイズでのFlyHashは、そこへ向かう自然な一歩です。同じ質問、同じモデルで、変わるのはメモリだけです。

タイムライン

1. 2026年11月4日Mohan BheemadoluとChrisogonas O. OdhiamboによるFlyHashが、arXiv（2611.05791）で公開されます。
2. 2026年11月10日論文がHugging Face Papersに載ります。コメント欄で私たちが言い換えられた質問について尋ね、Mohanがどのデータセットを使うか聞き返し、私たちがLoCoMoとLongMemEvalを挙げ、彼はまずLoCoMoを選びます。
3. 2026年11月11日短いコードは時間についての質問でより多く落ちるのか、と尋ねます。公開チェックがLoCoMoの200問で初めて走り、FlyHash用の例もつけて、Mohanに数字を送ります。
4. 2026年11月12日Mohanが計画を示します。k = 10で、16、32、64、128ビットのカテゴリ別の取得recall、コンテキストはJSONLで。私たちは同意し、k = 5を加えます。