Quand la mémoire d'un agent est condensée en codes courts, deux IA s'accordent-elles sur la même mauvaise réponse ?

L'article

Un agent qui se souvient de conversations passées doit les stocker quelque part et retrouver vite le bon morceau. FlyHash s'inspire de l'odorat de la mouche du vinaigre : il transforme l'embedding de chaque souvenir en un code court et épars, où seuls quelques « bits actifs » sont allumés. Des codes courts, c'est une petite mémoire.

Les résultats de l'article sont d'une simplicité rafraîchissante. À taille de code égale, FlyHash retrouve le bon souvenir environ 2,5 fois plus souvent que SimHash (0,27 contre 0,11). Quand la mémoire n'est pas serrée, un index HNSW standard fait encore mieux que les deux, et les auteurs le disent. Les articles qui indiquent où leur méthode perd sont plus rares qu'ils ne devraient l'être, et c'est ce qui nous a donné envie de leur écrire.

Le code est ouvert : github.com/mohanji/flyhash-agent-memory.

Comment la conversation s'est déroulée

Tout a commencé dans les commentaires sous l'article, sur Hugging Face. Nous avons demandé comment les codes se comportent face à des questions reformulées plutôt que calquées sur un gabarit. Mohan a répondu que les tests jusque-là utilisaient des formulations à gabarit et nous a demandé quel jeu de données nous suggérions. Nous en avons proposé deux, construits à partir de longs dialogues réels répartis sur plusieurs sessions : LoCoMo et LongMemEval. Il a décidé de commencer par LoCoMo et de poursuivre avec LongMemEval.

Puis nous avons posé la question qui relie son travail au nôtre : les codes les plus courts perdront-ils davantage sur les questions de temps (« quand a-t-elle déménagé ? ») que sur les faits isolés ?

Pourquoi la mémoire compte pour deux IA qui se contrôlent mutuellement

Deux modèles de deux entreprises différentes qui s'accordent sur une réponse, on y voit souvent un bon signe. Mais dans un agent, les deux modèles lisent généralement la même mémoire récupérée. Si la récupération a raté le fait, ils ne sont plus indépendants : ils peuvent s'accorder, avec aplomb, sur la même mauvaise réponse.

Pour voir à quelle fréquence cela arrive, nous avons monté un petit contrôle ouvert sur LoCoMo, memory-agreement-check, et l'avons exécuté une fois avec une mémoire simple par mots-clés (BM25, les 10 premiers tours de dialogue). GPT et Claude ont répondu séparément, et Kimi les a notés à l'aveugle.

Les erreurs des deux modèles étaient fortement corrélées (φ = 0,81). C'est un seul retriever et un seul seed : cela montre une association, pas une cause. Mais cela donne à FlyHash une question précise à laquelle répondre.

L'expérience que nous menons ensemble

Mohan a proposé de fournir la partie récupération ; nous prenons le relais à partir de là.

1. Mohan mesure d'abord la récupération : le recall@k pour chaque catégorie de LoCoMo (single-hop, multi-hop, temporel) à plusieurs tailles de code FlyHash et SimHash, 16, 32, 64 et 128 bits actifs, avec les 10 premiers souvenirs par question, comme dans la première exécution.
2. Nous avons suggéré d'ajouter aussi le top 5 : moins de souvenirs, c'est plus de ratés, ce qui devrait montrer à quelle vitesse croît la part de réponses concordantes mais fausses données avec assurance.
3. Il envoie les contextes récupérés en JSONL, une ligne par question.
4. Nous exécutons le contrôle d'accord sur chaque fichier et lui envoyons les résultats.

La question que nous lirons à la fin : à mesure que les codes raccourcissent, la part des réponses sur lesquelles les deux IA s'accordent et qui sont fausses augmente-t-elle, et augmente-t-elle le plus vite pour les questions de temps ? Si oui, une mémoire plus petite a un coût caché qu'un contrôle par une seconde IA ne détectera pas. Sinon, FlyHash paraît encore meilleur que ne le dit l'article.

Le code

Le contrôle accepte la sortie de n'importe quel retriever. Une ligne par question :

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

Le dépôt contient déjà un exemple qui construit ces contextes avec les classes FlyHash et SimHash du code de 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

Exécuter les mêmes questions à plusieurs tailles de code, ou avec --method dense comme référence, donne la comparaison.

Ce que les premiers chiffres peuvent dire, et ce qu'ils ne peuvent pas dire

• Ils viennent d'un seul retriever (BM25), d'une seule paire de modèles, d'un seul juge et d'un seul seed, sur 200 questions. D'autres retrievers et d'autres modèles peuvent faire bouger chaque chiffre.
• Les questions dont BM25 rate les preuves ne sont pas comme les autres (les questions multi-hop et ouvertes sont ratées bien plus souvent) ; la comparaison est donc aussi faite au sein de chaque catégorie.
• Un test causal répondrait aux mêmes questions une fois avec et une fois sans les tours de dialogue contenant les preuves. FlyHash à plusieurs tailles de code est une étape naturelle dans cette direction : mêmes questions, mêmes modèles, seule la mémoire change.

Chronologie

1. 4 novembre 2026FlyHash est publié sur arXiv (2611.05791) par Mohan Bheemadolu et Chrisogonas O. Odhiambo.
2. 10 novembre 2026L'article apparaît sur Hugging Face Papers. Dans les commentaires, nous posons la question des questions reformulées ; Mohan demande quel jeu de données utiliser ; nous suggérons LoCoMo et LongMemEval, et il choisit LoCoMo en premier.
3. 11 novembre 2026Nous demandons si les codes courts perdent davantage sur les questions de temps. Le contrôle ouvert tourne pour la première fois sur 200 questions LoCoMo, avec un exemple pour FlyHash, et nous envoyons les chiffres à Mohan.
4. 12 novembre 2026Mohan expose le plan : rappel de récupération par catégorie à 16, 32, 64 et 128 bits avec k = 10, contextes en JSONL. Nous sommes d'accord et ajoutons k = 5.