Quando a memória de um agente é espremida em códigos curtos, duas IAs concordam na mesma resposta errada?

O artigo

Um agente que lembra conversas passadas precisa guardá-las em algum lugar e achar rapidamente o trecho certo. O FlyHash toma emprestado o olfato da mosca-da-fruta: transforma o embedding de cada memória num código curto e esparso, no qual só alguns "bits ativos" ficam ligados. Códigos curtos significam memória pequena.

Os resultados do artigo são refrescantemente diretos. Com o mesmo tamanho de código, o FlyHash recupera a memória certa cerca de 2,5 vezes mais que o SimHash (0,27 contra 0,11). Quando a memória não é apertada, um índice HNSW padrão ainda vence os dois, e os autores dizem isso. Artigos que dizem onde o método deles perde são mais raros do que deveriam, e foi isso que nos fez escrever a eles.

O código é aberto: github.com/mohanji/flyhash-agent-memory.

Como foi a conversa

Começou nos comentários embaixo do artigo no Hugging Face. Perguntamos como os códigos lidam com perguntas parafraseadas, e não padronizadas. Mohan respondeu que os testes até então usaram formulações padronizadas e perguntou que conjunto de dados sugeríamos. Sugerimos dois, construídos a partir de diálogos longos e reais de várias sessões: LoCoMo e LongMemEval. Ele decidiu começar pelo LoCoMo e seguir com o LongMemEval.

Depois fizemos a pergunta que liga o trabalho dele ao nosso: os códigos mais curtos vão perder mais em perguntas sobre tempo ("quando ela se mudou?") do que em fatos isolados?

Por que a memória importa para duas IAs que se conferem

Dois modelos de empresas diferentes concordando numa resposta costuma ser tomado como bom sinal. Mas, num agente, os dois modelos geralmente leem a mesma memória recuperada. Se a recuperação perdeu o fato, eles deixam de ser independentes: podem concordar, com toda a confiança, na mesma resposta errada.

Para ver com que frequência isso acontece, montamos uma pequena verificação aberta sobre o LoCoMo, a memory-agreement-check, e a rodamos uma vez com memória simples por palavras-chave (BM25, os 10 principais turnos de diálogo). O GPT e o Claude responderam separadamente, e o Kimi os corrigiu às cegas.

Os erros dos dois modelos foram fortemente correlacionados (φ = 0,81). É um recuperador e uma semente, então mostra uma associação, não uma causa. Mas dá ao FlyHash uma pergunta precisa para responder.

O experimento que estamos rodando juntos

Mohan se ofereceu para fornecer o lado da recuperação; a partir daí, seguimos nós.

1. Mohan mede primeiro a recuperação: recall@k para cada categoria do LoCoMo (single-hop, multi-hop, temporal) em vários tamanhos de código do FlyHash e do SimHash, 16, 32, 64 e 128 bits ativos, com as 10 principais memórias por pergunta, como na primeira rodada.
2. Sugerimos acrescentar também as 5 principais: menos memórias significam mais perdas, o que deve mostrar com que rapidez cresce a parcela de respostas concordantes e confiantemente erradas.
3. Ele envia os contextos recuperados em JSONL, uma linha por pergunta.
4. Nós rodamos a verificação de concordância em cada arquivo e enviamos a ele os resultados.

A pergunta que vamos ler no final: à medida que os códigos encurtam, a parcela de respostas em que as duas IAs concordam e erram aumenta, e aumenta mais depressa nas perguntas sobre tempo? Se aumenta, uma memória menor tem um custo oculto que a conferência por uma segunda IA não vai pegar. Se não aumenta, o FlyHash parece ainda melhor do que o artigo diz.

O código

A verificação aceita a saída de qualquer recuperador. Uma linha por pergunta:

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

O repositório já tem um exemplo que gera esses contextos com as classes FlyHash e SimHash do código do 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

Rodar as mesmas perguntas em vários tamanhos de código, ou com --method dense como referência, dá a comparação.

O que os primeiros números podem e não podem dizer

• Eles vêm de um recuperador (BM25), um par de modelos, um juiz e uma semente, em 200 perguntas. Outros recuperadores e modelos podem mexer em todos os números.
• As perguntas cuja evidência o BM25 perde são diferentes das demais (as multi-hop e as de domínio aberto são perdidas com muito mais frequência), então a comparação também é feita dentro de cada categoria.
• Um teste causal responderia às mesmas perguntas uma vez com e uma vez sem os turnos de evidência. O FlyHash em vários tamanhos de código é um passo natural nessa direção: mesmas perguntas, mesmos modelos, só a memória muda.

Cronologia

1. 4 de novembro de 2026O FlyHash é publicado no arXiv (2611.05791) por Mohan Bheemadolu e Chrisogonas O. Odhiambo.
2. 10 de novembro de 2026O artigo aparece no Hugging Face Papers. Nos comentários, perguntamos sobre perguntas parafraseadas; Mohan pergunta qual conjunto de dados usar; sugerimos LoCoMo e LongMemEval, e ele escolhe o LoCoMo primeiro.
3. 11 de novembro de 2026Perguntamos se códigos curtos perdem mais em perguntas sobre tempo. A verificação aberta roda pela primeira vez em 200 perguntas do LoCoMo, com um exemplo para o FlyHash, e enviamos os números ao Mohan.
4. 12 de novembro de 2026Mohan apresenta o plano: recall de recuperação por categoria com 16, 32, 64 e 128 bits e k = 10, contextos em JSONL. Concordamos e acrescentamos k = 5.