Если память агента сжать в короткие коды, сойдутся ли два ИИ на одном неверном ответе?

Статья

Агент, который помнит прошлые разговоры, должен где-то их хранить и быстро находить нужный фрагмент. FlyHash берёт идею у обоняния плодовой мушки: он превращает эмбеддинг каждого воспоминания в короткий разреженный код, где включено лишь несколько «активных битов». Короткие коды — это маленькая память.

Результаты в статье освежающе простые. При равном размере кода FlyHash находит нужное воспоминание примерно в 2,5 раза чаще, чем SimHash (0,27 против 0,11). Когда с памятью не тесно, стандартный индекс HNSW всё равно побеждает обоих, и авторы прямо об этом пишут. Статьи, где сказано, в чём метод проигрывает, встречаются реже, чем следовало бы, и именно поэтому мы им написали.

Код открыт: github.com/mohanji/flyhash-agent-memory.

Как шёл разговор

Всё началось с комментариев под статьёй на Hugging Face. Мы спросили, как коды справляются с вопросами, заданными своими словами, а не по шаблону. Mohan ответил, что пока тесты шли с шаблонными формулировками, и спросил, какой набор данных мы посоветуем. Мы предложили два, собранные из длинных реальных многосессионных диалогов: LoCoMo и LongMemEval. Он решил начать с LoCoMo, а потом взять LongMemEval.

Затем мы задали вопрос, который связывает его работу с нашей: проиграют ли самые короткие коды больше на вопросах о времени («когда она переехала?»), чем на отдельных фактах?

Почему память важна для двух ИИ, проверяющих друг друга

Когда две модели от разных компаний сходятся на одном ответе, это обычно считают хорошим знаком. Но в агенте обе модели чаще всего читают одну и ту же найденную память. Если поиск упустил факт, они уже не независимы: они могут уверенно сойтись на одном и том же неверном ответе.

Чтобы увидеть, как часто это бывает, мы собрали небольшую открытую проверку на LoCoMo, memory-agreement-check, и прогнали её один раз на обычной памяти по ключевым словам (BM25, 10 лучших реплик диалога). GPT и Claude отвечали отдельно, а Kimi оценивал их вслепую.

Ошибки двух моделей оказались сильно связаны (φ = 0,81). Это один поисковик и одно зерно случайности, так что это связь, а не причина. Но у FlyHash теперь есть точный вопрос, на который нужно ответить.

Эксперимент, который мы ставим вместе

Mohan предложил взять на себя поиск; дальше работаем мы.

1. Mohan сначала измеряет поиск: recall@k для каждой категории LoCoMo (один шаг, несколько шагов, вопросы о времени) при нескольких размерах кода FlyHash и SimHash, 16, 32, 64 и 128 активных битов, с 10 лучшими воспоминаниями на вопрос, как в первом прогоне.
2. Мы предложили добавить ещё top 5: меньше воспоминаний значит больше промахов, и это покажет, как быстро растёт доля уверенно неверных согласованных ответов.
3. Он присылает найденные контексты в JSONL, по строке на вопрос.
4. Мы запускаем проверку согласия на каждом файле и отправляем ему результаты.

Вопрос, на который мы будем отвечать в конце: когда коды становятся короче, растёт ли доля ответов, на которых оба ИИ сошлись и ошиблись, и быстрее ли всего она растёт на вопросах о времени? Если да, у меньшей памяти есть скрытая цена, которую проверка вторым ИИ не поймает. Если нет, FlyHash выглядит даже лучше, чем сказано в статье.

Код

Проверка принимает вывод любого поисковика. Одна строка на вопрос:

{"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}]}

В репозитории уже есть пример, который строит такие контексты на классах FlyHash и SimHash из кода Mohan:

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 в качестве эталона, получится сравнение.

Что могут и чего не могут сказать первые цифры

• Они получены на одном поисковике (BM25), одной паре моделей, одном судье и одном зерне, на 200 вопросах. Другие поисковики и модели могут сдвинуть любую цифру.
• Вопросы, чьи доказательства BM25 упускает, отличаются от остальных (вопросы с несколькими шагами и открытые упускаются гораздо чаще), поэтому сравнение делается ещё и внутри каждой категории.
• Причинную проверку дал бы ответ на те же вопросы один раз с репликами-доказательствами и один раз без них. FlyHash при нескольких размерах кода — естественный шаг к ней: те же вопросы, те же модели, меняется только память.

Хронология

1. 4 ноября 2026Mohan Bheemadolu и Chrisogonas O. Odhiambo публикуют FlyHash на arXiv (2611.05791).
2. 10 ноября 2026Статья появляется на Hugging Face Papers. В комментариях мы спрашиваем про вопросы своими словами; Mohan спрашивает, какой набор данных взять; мы предлагаем LoCoMo и LongMemEval, и он выбирает сначала LoCoMo.
3. 11 ноября 2026Мы спрашиваем, не проигрывают ли короткие коды больше на вопросах о времени. Открытая проверка впервые идёт на 200 вопросах LoCoMo, с примером для FlyHash, и мы отправляем Mohan цифры.
4. 12 ноября 2026Mohan излагает план: полнота поиска по категориям при 16, 32, 64 и 128 битах с k = 10, контексты в JSONL. Мы соглашаемся и добавляем k = 5.