RealCompanion: cuánta memoria necesita un companion de IA

TL;DR

Verificado verbatim contra el abstract y el HTML v2 (arXiv 2610.01780, v2 del 02/10/2026; Arman Behnam y Sunglyoung Kim — Quis Lab — y Liangwei Yang, independiente; preprint sin peer review): RealCompanion es un benchmark construido con diez relaciones reales entre personas y un companion de IA: 27.218 mensajes a lo largo de hasta 120 días, publicados junto a cuatro ficheros derivados (perfil, persona, respuestas de referencia y preguntas), cada uno citando los mensajes que lo sostienen. No hay gente ni preguntas inventadas, que es justo lo que critica del resto del campo.
Los tres hallazgos, literales del abstract: solo el 3,4% de los mensajes de las personas depende de algo dicho antes, y cuando depende, el mensaje necesario está a una mediana de 2.157 mensajes de distancia. Mirar los mensajes recientes encuentra el necesario el 95,9% de las veces en conjunto, pero solo el 2,2% cuando está lejos. Y etiquetar los mismos mensajes como “memories” hace que los modelos saquen el pasado 10 a 14 puntos porcentuales más, aunque no haga falta.
Nadie sabe cuándo mirar: los detectores probados rondan el azar en mensajes reales (AUROC 0,530-0,601), y tres sistemas de agente reconstruyen la persona con el mismo F1 (~0,70) con 546M, 18M y 36M de tokens procesados — una diferencia de 30× en coste para el mismo resultado, más 70-80 campos inventados por cada 100 recuperados.
Nada de esto es reproducible hoy: el dataset está gated en Hugging Face (acceso manual) y el código está en un repositorio anónimo que no abre sin sesión. Esto es lectura de un paper, no guía de uso: lo que te llevas es el criterio de diseño, no la herramienta.
La tesis que sobrevive al escepticismo: la demanda de pasado en conversaciones reales es rara y lejana, así que lo barato (ventana de recencia + umbral) cubre casi todo, y el coste está en decidir cuándo mirar, no en cómo recuperar. Si construyes memoria de agentes, es la misma lección del context engineering como cuello de botella, con datos reales por fin detrás.

El contexto: los benchmarks de memoria miden un mundo inventado

La premisa de buena parte de la industria de memoria de agentes —mem0, MemGPT, perfiles de usuario de larga vida— es que la conversación acumula un pasado que hace falta recuperar. Los benchmarks con los que se mide esa premisa comparten un defecto de nacimiento: la gente y las preguntas están generadas. Es lo que el paper llama corpus “authored”: LoCoMo (Maharana et al., 2024), LongMemEval (Wu et al., 2024), PersonaMem, CloneMem o CIMemories construyen la persona y las preguntas, y al hacerlo deciden de antemano qué importa. Si el benchmark se monta para que cada pregunta necesite memoria, el sistema evaluado vive en un mundo donde el pasado siempre importa. En datos reales, no.

RealCompanion es el único del campo que entra con conversaciones reales verbatim (Tabla 1 del paper). El más cercano en datos, según reconocen los propios autores, es AlpsBench: curó secuencias reales de WildChat, pero evalúa igualmente con preguntas fabricadas. Aquí, diez personas que llevaban meses usando una aplicación de companion, con su consentimiento explícito para investigación y publicación, anonimizadas con sustitutos consistentes. Dos honestidades del propio paper que conviene tener a la vista: el comité de ética que aprobó el estudio es interno del operador de datos (no hubo IRB independiente), y los propios autores advierten de que una muestra de la escritura de una persona podría reidentificarla por estilometría. El lab detrás, Quis Lab, no es un nombre conocido del campo: leamos esto como trabajo académico independiente, no como estándar de industria.

Qué hay en el benchmark

Por cada participante, cinco ficheros: la conversación completa (la fuente) y cuatro derivados con citas a los mensajes que los sostienen — perfil (cada claim con sus mensajes), persona, respuestas de referencia y preguntas. Cada etiqueta lleva la traza de razonamiento que la produjo, verificada contra la conversación. La construcción es de modelos con auditoría humana, y el paper reporta el desacuerdo entre ambos.

Los probes vienen en tres estratos con funciones distintas: el proporcional (1.169 ítems puntuables, muestra aleatoria) es el único que responde a “cada cuánto hace falta el pasado”; el enriquecido responde a “qué pasa cuando hace falta”; y el control de abstención (434 aperturas de sesión) mide si el sistema se contiene cuando no hace falta nada. Esta separación no es un detalle metodológico: es el mecanismo que delata a los benchmarks anteriores.

Hallazgo 1: el pasado se necesita poco, y cuando hace falta, está lejos

En el estrato proporcional, el 3,4% de los mensajes enviados por las personas lleva demanda verificada de memoria (IC 95%: 2,5-4,6) bajo la lectura grabada; bajando a la lectura estricta —fuera los referentes visibles en pantalla—, el 1,3% (0,8-2,1). Tres de las diez personas no contribuyen ni un solo ítem con demanda de memoria bajo la lectura grabada (cinco bajo la estricta). La demanda de pasado, según los datos, es propiedad de la profundidad de la relación, no una constante del chat.

Y cuando el pasado hace falta, no está cerca: el mensaje más lejano que un probe necesita está a una mediana de 2.157 mensajes hacia atrás (cuartil superior: 5.114; máximo: 12.542). Hasta el referente más cercano está a una mediana de 450 mensajes. Nada que una ventana de contexto normal contenga.

Hallazgo 2: la ventana de recencia cubre casi todo — con letra pequeña

Sobre los 1.477 probes de chat con referencia, la ventana de recencia encuentra el mensaje necesario el 95,9% de las veces. Ese número agregado tiene trampa, y el paper la señala él mismo: el 72,6% de esos probes es respondible desde el hilo reciente, así que el 95,9% mide en buena parte la composición del corpus, no la capacidad de recuperación. La letra pequeña está en la Tabla 4: en los ítems cuyo material está lejos, la recencia encuentra el mensaje solo el 2,2% de las veces (frente al 0,5% del azar). BM25 lo hace once veces mejor (24,8%) y aun así falla tres de cuatro. El oráculo: 100%.

El segundo dato incómodo para la industria de RAG: a presupuesto igual —diez mensajes—, BM25 rinde lo mismo que no dar contexto ninguno (1,426 contra 1,431 en la Tabla 5; la ventana de diez mensajes previos da 1,625), y con etiqueta y orden controlados puntúa 0,189 menos que la recencia. Donde aparece es en la localización de ítems lejanos: encuentra el mensaje necesario once veces más que la recencia (24,8% contra 2,2%), pero aun así falla tres de cuatro. Instalar un pipeline de recuperación tiene un coste —el que sea, se paga en tokens y complejidad— y aquí, sobre datos reales, compra poco incluso donde el pasado está lejos.

El 96% que resume el paper: del total de ganancia que aporta entregar evidencia grabada (de 1,431 sin contexto a 1,763 con el oráculo, Tabla 5), el 96% aterriza en probes que no necesitaban memoria. El reemplazo oracle vale +0,455 (0,319-0,588) solo en los 167 ítems realmente dependientes. Vender el stack completo por ese 4% es la mala arquitectura que el paper documenta.

Hallazgo 3: decidir cuándo mirar es lo que nadie sabe hacer

Los detectores que prueban los autores —un modelo al que se le enseña el probe y sus tres mensajes previos, y un score léxico— separan a ojo de azar los mensajes reales: AUROC 0,530 (0,488-0,572) contra probes cuyo referente está ausente, 0,548 (0,488-0,609) contra aperturas de sesión, 0,601 (0,527-0,676) contra su propio objetivo. Su umbral captura 6 de los 40 probes que necesitan memoria y levanta 40 falsos positivos.

El contraste que delata a los benchmarks authored: el mismo detector, sobre las preguntas inventadas del question track, sube a 0,802 (frente a 0,546 en los probes de chat real). Una pregunta escrita comparte más palabras con su evidencia que un mensaje humano en conversación — el índice de cuándo mirar está filtrado en la redacción de la pregunta. Sobre datos reales, ese índice no existe, al menos para los detectores probados.

Y el hallazgo de behavioral economics que atraviesa todo el paper: etiquetar los mismos diez mensajes como “memories” en lugar de “mensajes anteriores” sube su uso 10 a 14 puntos porcentuales en todas las poblaciones, incluidos probes que no necesitan memoria. Renombrar una ventana de recencia igual, en cambio, no cambia nada. El framing mueve el comportamiento más que la técnica: parte de lo que los sistemas de memoria “logran” en producción puede ser simplemente el sesgo de la etiqueta.

Hallazgo 4: mismo F1 con 30× de tokens, y alucinación estructural

Tres sistemas de agente leyeron la historia completa de cada participante para reconstruir su ficha de persona, tres ejecuciones por sistema. Resultado (Tabla 6; claim de los autores, con los sistemas que ellos eligieron —los agentes de coding de cada vendor, no sistemas de memoria dedicados):

Sistema (según Tabla 6 del paper)	F1	Precision	Recall	Tokens
Claude Opus 5.5	0,686	0,557	0,893	546M
Codex GPT-5.6-sol	0,688	0,573	0,861	18M
Antigravity + Gemini 3.8 Flash	0,701	0,591	0,861	36M

Mismo F1 (~0,70) con 546M contra 18M de tokens procesados — el abstract lo llama “31-fold”, que es el redondeo generoso de 30,3×. Dos lecturas: escalar el modelo no compra nada en esta tarea, y el sistema barato empata al de frontiera. Pero la parte que deberías subrayar es la estructura del error: precision de 0,56-0,59 contra recall de 0,86-0,89 — los tres recuperan lo que la ficha tiene y añaden 70-80 campos de más por cada 100 recuperados. Leen a la persona y luego imaginan más. Las tres ejecuciones de un mismo sistema coinciden entre sí (0,93-0,95) más de lo que coinciden con la ficha real (0,86-0,88 entre sistemas): la invención es consistente, que es justo lo que la hace peligrosa en un perfil de usuario que un sistema va a tomar como verdad.

Qué dice esto de LoCoMo, LongMemEval y de tu stack

Si los benchmarks authored obligan a mirar al pasado en cada pregunta y los datos reales muestran que el pasado se mira en el 3,4% de los mensajes, las tablas de ranking de memoria están comparando sistemas en un mundo que no existe. Un score alto de LoCoMo no responde a “cuánta memoria necesita mi agente”; responde a “qué tal recupera cuando le obligas a recuperar”. Son preguntas distintas y el paper tiene los datos para separarlas.

Para quien construye memoria de agentes, los tres hallazgos funcionan como checklist de diseño barato primero:

Mide tu tasa natural de demanda de pasado antes de instalar nada. Si es baja —y en el único corpus real publicado ronda el 3,4%—, ventana de recencia + umbral de abstención cubre la mayoría de los casos sin stack.
No empieces por RAG. A presupuesto igual, el recuperador léxico no batió a la recencia en calidad de respuesta (empató con no dar contexto: 1,426 vs 1,431), y donde el pasado está lejos acierta once veces más pero falla tres de cuatro. El oráculo completo solo añade valor claro en los ítems dependientes, que son la minoría.
Cuida la etiqueta tanto como la técnica. El mismo bloque etiquetado “memories” sesga el uso 10-14 puntos. Si tu sistema decide cuándo mirar por la etiqueta del contexto, tiene un sesgo, no una memoria.
Audita la invención, no solo el recall. Precision 0,56-0,59 con recall 0,86-0,89 significa que tu ficha de usuario crece con campos que nadie dijo. Un perfil con 70-80 campos inventados por 100 reales es un pasivo, no un activo — en la línea de lo que documentamos con el envenenamiento de memoria RAG.

Las trampas

Todo es self-reported y sin peer review. Preprint con v2 del 02/10/2026 y un lab sin historial conocido. Ninguna cifra tiene réplica independiente.
El 95,9% es un número agregado. Sin el 72,6% de ítems respondibles del hilo reciente al lado, engaña. El dato operativo es el par: 95,9% global, 2,2% en los ítems lejanos.
“31-fold” es redondeo del abstract: 546M/18M son 30,3×. Cita la tabla, no el adjetivo.
Reproducibilidad cero para el lector: el dataset está gated (acceso manual; la ficha de HF hoy es de acceso y citación) y el código, en un repositorio anónimo que exige sesión. Los datos enlazados vía OSF son view-only.
Los agentes evaluados son los de coding de cada vendor (Claude Code, Codex, Antigravity). Extrapolación a sistemas de memoria dedicados (mem0, MemGPT) es interpretación — en el paper solo aparecen en trabajo relacionado.
Ética con asterisco: consentimiento explícito de los diez participantes y anonimización con sustitutos, pero el comité que aprobó es interno del operador (sin IRB) y los autores mismos avisan del riesgo de reidentificación estilométrica.
El companion es anónimo por diseño: el paper no dice qué producto usaban las personas, y especularlo es humo. Los datos son de relaciones persona-companion genéricas, no de “tu app favorita”.

Qué haría yo

Si construyes un agente con historia: escribe la tasa natural de tu producto antes de elegir stack — cuántos de tus mensajes reales necesitan algo que ya salió de la ventana. Si ese número se parece al del paper, recencia + umbral es arquitectura completa, no MVP. Y si contratas o configuras un sistema de memoria, pide dos métricas: precision del perfil (qué proporción de lo que guarda lo dijo el usuario) y comportamiento con la etiqueta neutralizada. Si empeora al quitarle la palabra “memories”, lo que tiene es un sesgo de framing con infraestructura alrededor.

Si evalúas benchmarks para decidir compras: desconfía por defecto de cualquier tabla de memoria que no publique su tasa natural de demanda. En authored, es 100%; en datos reales, un 3,4%. El ranking que no dice en qué mundo mide no te dice nada de tu caso.

Qué NO sabemos

Si los detectores fallan por limitación actual o por naturaleza del problema: el paper prueba unos cuantos detectores, no agota el espacio.
Qué pasa con relaciones más largas: 120 días como máximo; el horizonte de memoria crece con la relación y el paper lo dice — la longitud fija el horizonte que el sistema debe cubrir.
Cómo rinden los sistemas de memoria dedicados (mem0, MemGPT, Generative Agents): no se evaluaron; el 31× es entre agentes de coding.
Si el 3,4% se traslada fuera de companions de chat: soporte técnico, asistentes de trabajo y agentes de coding tienen dinámicas de referencia al pasado distintas. Diez relaciones de un producto concreto es una muestra pequeña, y el paper no identifica el producto.
Cómo se comporta el benchmark cuando alguien lo use de verdad: no hay leaderboard público ni resultados de terceros a fecha de este análisis (06/10/2026).

Fuentes

Primarias: arXiv 2610.01780 — abstract · HTML v2 completo (abstract, §2 Background, §5 Benchmark Setup, §6 Results, Tablas 1, 4, 5 y 6, Apéndices B, E y H) — consultados el 06/10/2026.
Datos y código: OSF view-only (enlace del propio paper) · dataset Quislab/RealCompanion en HF (gated manual, verificado el 06/10/2026) · código anónimo en anonymous.4open.science (inaccesible sin sesión, verificado el 06/10/2026).
Recepción: página del paper en Hugging Face (265 upvotes vía API, consultada el 06/10/2026).
Contexto interno: memoria de agentes, el nuevo cuello de botella · envenenamiento de memoria RAG · chunking por identificadores y costes RAG · Code2Skill: skills minadas de GitHub.