Memoria de largo plazo aislada por tenant en agentes conversacionales: arquitectura, modelo de amenazas y protocolo reproducible

1. Problema y contribución

Un asistente útil en interacciones prolongadas debe recordar información más allá de una sola ventana de contexto: una preferencia expresada la semana anterior, una restricción registrada meses atrás o un documento cargado en otra sesión. Sistemas como MemGPT plantean este problema como administración entre niveles de memoria rápida y lenta [4], mientras LongMemEval lo descompone en extracción, razonamiento entre sesiones, razonamiento temporal, actualizaciones y abstención [5]. Esas formulaciones muestran que la memoria persistente no equivale a ampliar el prompt. Sin embargo, por sí solas no demuestran que la memoria de un usuario no pueda aparecer en la respuesta de otro.

El sistema estudiado atiende múltiples usuarios mediante un runtime y varios servicios compartidos [1]. Sus almacenes cumplen funciones distintas: un checkpointer en PostgreSQL conserva el estado de corto plazo; Mem0 sobre pgvector representa memoria conversacional; Neo4j contiene evidencia documental basada en grafos; Convex coordina jobs y proyecciones operativas. Una respuesta puede combinar evidencia seleccionada de varias capas. Por eso el aislamiento es una propiedad end-to-end de resolución de identidad, escrituras, filtros de recuperación, armado del prompt, observabilidad y borrado; no es una propiedad exclusiva de la base vectorial.

• Formalizar los invariantes de seguridad que debe probar una evaluación de memoria conversacional.
• Reconstruir desde el código el protocolo de seis casos y su regla exacta de decisión [2,3].
• Separar controles implementados, tests inspeccionados y comportamiento real todavía no observado.
• Especificar un experimento ampliado para actualizaciones, hechos obsoletos, borrado, paráfrasis y ablaciones por capa.

2. Trabajo relacionado y la pregunta de aislamiento

MemGPT propone una analogía con sistemas operativos en la que el agente mueve información entre un contexto de trabajo limitado y memoria externa [4]. La referencia es pertinente porque este runtime también usa niveles de memoria, aunque aquí no se afirma que implemente la política de control de MemGPT. LongMemEval resulta más útil como referencia de evaluación: sus cinco capacidades revelan fallas que el recuerdo estático oculta, en especial actualización de conocimiento y abstención [5]. La extensión de la Sección 9 adopta esas capacidades como familias de prueba en lugar de presentar seis preguntas directas como benchmark integral.

GraphRAG organiza corpus privados en representaciones de grafo para recuperar y sintetizar información que no está en el modelo base [6]. El runtime estudiado usa Neo4j para evidencia documental, pero su precedencia declarada —grafo, luego memoria de largo plazo y finalmente estado del hilo— añade una pregunta de sistemas: un almacén de memoria correctamente aislado no alcanza si la recuperación del grafo o la restauración del hilo incorporan evidencia del tenant equivocado. Calidad de recuperación y aislamiento deben medirse por separado.

3. Modelo del sistema y fronteras de confianza

La implementación inspeccionada expone un endpoint de preview que recibe un teléfono y un mensaje sin enviar WhatsApp [1,2]. El registro crea un identificador de usuario desde un teléfono sintético único. Los jobs conversacionales se coordinan fuera del camino síncrono, mientras LangGraph restaura el estado del hilo y consulta memorias persistentes. El README documenta la precedencia de evidencia como Neo4j, luego Mem0 y luego el hilo [1]. Este orden importa: una respuesta puede ser correcta porque la capa prioritaria devolvió evidencia aunque otra capa esté obsoleta o contaminada.

El backend del grafo crea claves de tenant, documento, chunk y entidad que contienen el identificador del tenant, y la consulta de recuperación filtra por tenantId [1]. Son controles de implementación, no una prueba de no interferencia global. La evaluación debe atravesar el endpoint real porque el mapeo de identidad, la orquestación, el armado del prompt, los fallbacks o checkpoints obsoletos pueden eludir un filtro localmente correcto.

1. Registrar un teléfono nuevo y obtener el identificador del runtime.
2. Escribir tres hechos por el mismo camino de preview usado en conversación.
3. Esperar un intervalo configurable para reducir ruido por carreras de ingesta.
4. Ejecutar las consultas específicas y guardar respuesta y latencia de pared.
5. Puntuar evidencia esperada y evidencia perteneciente exclusivamente al otro tenant.

4. Modelo de amenazas e invariantes

El activo protegido es la información conversacional y documental específica de cada usuario. El principal es el tenant resuelto desde una identidad entrante. El evento adversarial no exige un atacante: puede ser una consulta normal que recupera el embedding vecino, un worker que reanuda otro hilo, una query de grafo sin predicado o una traza visible fuera de su alcance. El benchmark actual cubre una sola consecuencia observable: aparece en la respuesta un hecho mutuamente excluyente del otro tenant.

• I1 — Aislamiento de escritura: una frase enviada bajo A no crea estado recuperable bajo B.
• I2 — Aislamiento de lectura: el contexto recuperado para A no contiene ítems de B.
• I3 — Aislamiento de respuesta: la respuesta para A no contiene un hecho protegido exclusivo de B.
• I4 — Borrado completo: después de eliminar el tenant, el hecho no aparece en almacenes ni respuestas.

5. Dataset sintético y unidad experimental

El dataset contiene dos tenants sintéticos, Ana y Bruno. Cada uno recibe un color, una alergia y un empleador. Los valores están emparejados para que el esperado de uno sea el prohibido del otro. La construcción es pequeña pero deliberada: cada prueba de recuerdo funciona también como prueba negativa de aislamiento [3]. La unidad experimental es una respuesta final a una pregunta después de escribir los mensajes de preparación.

El runner normaliza acentos Unicode, mayúsculas, espacios de borde y secuencias repetidas antes de comparar substrings [2]. Un caso aprueba solo si están todos los términos obligatorios, no aparece ninguno prohibido y, si existe una disyunción opcional, aparece al menos un candidato. El dataset no usa equivalencia semántica, entailment ni un modelo juez.

6. Scoring, latencia y regla de decisión

El runner reporta además media, mediana, máximo y proporción bajo 700 ms [2]. La latencia se mide alrededor del request HTTP al endpoint de preview: incluye red y servidor visibles para el cliente, pero no separa recuperación, generación, cola ni proveedor. Incumplir 700 ms identifica un problema end-to-end sin localizar su causa.

7. Procedimiento de reproducción y artefacto de resultados

Una ejecución válida debe fijar revisión de la aplicación, identidad del despliegue, modelos, entorno, timestamp, hash del dataset e intervalo de espera. Los teléfonos únicos generados con tiempo y alias reducen colisiones. La salida debe almacenarse como JSON inmutable, no como resumen copiado de consola.

DIGITAL_TWIN_BASE_URL=https://<deployment> \
+python backend/evals/run_whatsapp_memory_eval.py \
+  --dataset backend/evals/whatsapp_memory_eval.json \
+  --settle-ms 150 \
+  --output eval-result.json \
+  --enforce-targets

1. Registrar revisión Git y hash del dataset antes de ejecutar.
2. Verificar que el target sea un entorno autorizado para evaluación.
3. Ejecutar al menos tres repeticiones con identidades nuevas y conservar toda salida.
4. Separar fallas de recuerdo y filtraciones antes de agregar métricas.
5. Inspeccionar respuestas fallidas junto con trazas bajo controles de acceso.
6. Publicar solo entradas sintéticas, configuración y JSON redactados.

8. Auditoría de evidencia

La auditoría inspeccionó la revisión 1470f8f17163cd87538c5e12ae621658bd46afe3 mediante acceso autenticado a GitHub. Se leyeron runner, dataset JSON, tests unitarios, helper de espacio de recuperación, backend de grafo, métricas y README [1–3]. Las funciones deterministas tienen tests para respuestas esperadas, términos simultáneamente faltantes y filtrados, y cálculo de percentil por rango superior. La revisión no tenía status checks ni workflows asociados, y el repositorio privado no pudo clonarse al entorno de publicación para ejecutar su suite completa.

9. Experimento extendido y plan de ablaciones

El próximo benchmark debería conservar tenants emparejados y ampliar operaciones y variación lingüística. Un piloto útil tendría al menos 20 pares, cinco dominios de hechos y múltiples consultas por operación. Los pares deben recibir hechos semánticamente relacionados pero excluyentes para evitar que respuestas genéricas aprueben. Las plantillas deben separarse antes de generar paráfrasis para impedir duplicados cercanos entre desarrollo y evaluación.

Deben compararse cuatro configuraciones: solo hilo, solo memoria vectorial, solo grafo y precedencia combinada. Se fijarán modelo y prompts. El reporte incluirá exactitud literal, recuerdo semántico con revisión humana ciega, filtración de hechos ajenos, abstención, actualizaciones, borrado, costo por consulta y latencia por etapa. Conviene reportar intervalos bootstrap sobre pares y listar individualmente cada filtración, porque un promedio bajo puede ocultar una falla grave.

10. Amenazas a la validez, ética y privacidad

• Validez de constructo: un substring es un proxy imperfecto del recuerdo y puede fallar con negaciones, citas o paráfrasis.
• Validez interna: el protocolo no atribuye la respuesta a grafo, vector o hilo y no controla deriva del proveedor.
• Validez externa: dos tenants sintéticos en español y tres hechos no representan conversaciones, documentos, idiomas ni escalas reales.
• Validez estadística: seis observaciones hacen que p95 sea el máximo y no estiman la cola.
• Validez de seguridad: ausencia de tres strings emparejados no demuestra no interferencia global.

Los datos sintéticos deben ser la opción por defecto para pruebas públicas de aislamiento. Las conversaciones reales no son necesarias para verificar los invariantes centrales y agregan riesgo de privacidad. Si se usan trazas productivas para depuración, acceso, retención y redacción deben documentarse por separado. Ningún artefacto público debe exponer teléfonos, identificadores internos, documentos, credenciales ni prompts sin redactar.

11. Conclusión

El sistema inspeccionado contiene un punto de partida concreto: tenants sintéticos emparejados, afirmaciones positivas y negativas, requests end-to-end y objetivos explícitos. Es más fuerte que un diagrama, pero más débil que un resultado publicado. La regla efectiva exige recuerdo perfecto sin filtración observada y latencia máxima de 700 ms. Hasta publicar una corrida cruda y fijada, esos valores son criterios de aceptación, no logros.

La lección más general es que la memoria no se resume en si el agente recuerda. Debe recordar el hecho correcto, para el principal correcto, desde una fuente autorizada, después de actualizaciones y borrados, sin revelar el estado vecino. La extensión propuesta transforma ese requisito en un programa medible.