Cuando la memoria de un agente se comprime en códigos cortos, ¿coinciden dos IA en la misma respuesta errónea?
con Mohan Bheemadolu · desarrollador de agentes de IA, Redmond · coautor de FlyHash for LLM agent memory
En medio minuto
Mohan Bheemadolu y la Dra. Chrisogonas O. Odhiambo escribieron FlyHash: una forma de guardar los recuerdos de un agente de IA como códigos binarios muy cortos, inspirada en cómo la nariz de una mosca de la fruta distingue los olores. Con el mismo tamaño de código, encuentra el recuerdo correcto unas 2.5 veces más a menudo que el SimHash habitual. Eso plantea una pregunta que ninguno de los dos podía responder solo. Los agentes suelen ser verificados por una segunda IA, pero ambas leen la misma memoria recuperada. Si una memoria más pequeña falla más a menudo en el dato, ¿empiezan los dos verificadores a coincidir en la misma respuesta errónea? Una primera ejecución con memoria corriente sugiere que puede ser así: cuando la memoria no contenía la evidencia, el 45% de las respuestas en las que ambas IA coincidían eran erróneas, frente al 3% cuando sí la contenía. Eso fue con un solo recuperador y una sola semilla, así que muestra una asociación, no una causa. El plan de Mohan es medir FlyHash con cuatro tamaños de código sobre el mismo benchmark y enviarnos las memorias recuperadas; la comprobación de coincidencia se ejecuta después sobre ellas.
El artículo
Un agente que recuerda conversaciones pasadas tiene que guardarlas en algún sitio y encontrar rápido el fragmento adecuado. FlyHash toma prestado el olfato de la mosca de la fruta: convierte el embedding de cada recuerdo en un código corto y disperso en el que solo unos pocos "bits activos" están encendidos. Códigos cortos significan una memoria pequeña.
Los resultados del artículo son refrescantemente claros. Con el mismo tamaño de código, FlyHash recupera el recuerdo correcto unas 2.5 veces más a menudo que SimHash (0.27 contra 0.11). Cuando la memoria no está ajustada, un índice HNSW estándar sigue superando a ambos, y los autores lo dicen. Los artículos que declaran dónde pierde su método son más raros de lo que deberían, y eso fue lo que nos hizo escribirles.
El código es abierto: github.com/mohanji/flyhash-agent-memory.
Cómo fue la conversación
Empezó en los comentarios bajo el artículo en Hugging Face. Preguntamos cómo se las arreglan los códigos con preguntas parafraseadas en lugar de formuladas con plantilla. Mohan respondió que las pruebas hasta ahora usaban formulaciones con plantilla y preguntó qué conjunto de datos le sugeríamos. Le propusimos dos construidos a partir de diálogos largos y reales de varias sesiones: LoCoMo y LongMemEval. Decidió empezar con LoCoMo y seguir con LongMemEval.
Luego hicimos la pregunta que une su trabajo con el nuestro: ¿perderán más los códigos más cortos en preguntas sobre el tiempo ("¿cuándo se mudó ella?") que en datos aislados?
Por qué importa la memoria para dos IA que se verifican entre sí
Que dos modelos de empresas distintas coincidan en una respuesta suele tomarse como buena señal. Pero en un agente, ambos modelos suelen leer la misma memoria recuperada. Si la recuperación no encontró el dato, ya no son independientes: pueden coincidir, con total seguridad, en la misma respuesta errónea.
Para ver con qué frecuencia ocurre, armamos una pequeña comprobación abierta sobre LoCoMo, memory-agreement-check, y la ejecutamos una vez con memoria simple por palabras clave (BM25, los 10 turnos de diálogo principales). GPT y Claude respondieron por separado, y Kimi los calificó a ciegas.
Los errores de los dos modelos estaban fuertemente correlacionados (φ = 0.81). Eso es un solo recuperador y una sola semilla, así que muestra una asociación, no una causa. Pero le da a FlyHash una pregunta precisa que responder.
El experimento que hacemos juntos
Mohan se ofreció a aportar la parte de recuperación; desde ahí seguimos nosotros.
- Mohan mide primero la recuperación: recall@k para cada categoría de LoCoMo (un salto, varios saltos, temporal) con varios tamaños de código de FlyHash y SimHash, 16, 32, 64 y 128 bits activos, con los 10 recuerdos principales por pregunta, igual que en la primera ejecución.
- Sugerimos añadir también los 5 principales: menos recuerdos significan más fallos, lo que debería mostrar con qué rapidez crece la proporción de respuestas coincidentes y erróneas dadas con seguridad.
- Él envía los contextos recuperados como JSONL, una línea por pregunta.
- Nosotros ejecutamos la comprobación de coincidencia sobre cada archivo y le enviamos los resultados.
La pregunta que leeremos al final: a medida que los códigos se acortan, ¿sube la proporción de respuestas en las que ambas IA coinciden y se equivocan, y sube más rápido en las preguntas sobre el tiempo? Si es así, una memoria más pequeña tiene un coste oculto que una verificación por una segunda IA no detectará. Si no, FlyHash queda incluso mejor de lo que dice el artículo.
El código
La comprobación acepta la salida de cualquier recuperador. Una línea por pregunta:
{"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}]}El repositorio ya trae un ejemplo que construye estos contextos con las clases FlyHash y SimHash del código 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-k32Ejecutar las mismas preguntas con varios tamaños de código, o con --method dense como referencia, da la comparación.
Lo que las primeras cifras pueden y no pueden decir
- Provienen de un solo recuperador (BM25), una pareja de modelos, un juez y una semilla, sobre 200 preguntas. Otros recuperadores y modelos pueden mover cada número.
- Las preguntas cuya evidencia BM25 no encuentra son distintas de las demás (las de varios saltos y las de dominio abierto fallan mucho más a menudo), así que la comparación se hace también dentro de cada categoría.
- Una prueba causal respondería las mismas preguntas una vez con y otra sin los turnos de evidencia. FlyHash con varios tamaños de código es un paso natural hacia eso: mismas preguntas, mismos modelos, solo cambia la memoria.
Cronología
- FlyHash se publica en arXiv (2611.05791) por Mohan Bheemadolu y Chrisogonas O. Odhiambo.
- El artículo aparece en Hugging Face Papers. En los comentarios preguntamos por las preguntas parafraseadas; Mohan pregunta qué conjunto de datos usar; sugerimos LoCoMo y LongMemEval, y él elige LoCoMo primero.
- Preguntamos si los códigos cortos pierden más en preguntas sobre el tiempo. La comprobación abierta se ejecuta por primera vez sobre 200 preguntas de LoCoMo, con un ejemplo para FlyHash, y enviamos las cifras a Mohan.
- Mohan expone el plan: recall de recuperación por categoría con 16, 32, 64 y 128 bits con k = 10, contextos como JSONL. Estamos de acuerdo y añadimos k = 5.