Alibaba Cloud afirma una victoria de 9,27x en memoria de IA frente a un rival sin nombre

MemOS Cloud ejecutó el benchmark, y las condiciones divulgadas son las que cabría esperar de una prueba controlada: configuración de máquina idéntica, conjuntos de datos idénticos, carga idéntica. A lo largo de cinco puntos de carga entre 10 y 40 consultas por segundo, PolarDB for PostgreSQL registró una latencia P99 menor que la base de datos de comparación en todas las ocasiones. La dispersión reportada va de 1,79x a 9,27x, con una mediana de 2,71x y una media de 3,96x en esos cinco puntos.

Ninguna de las dos empresas nombra al rival. Esa omisión importa, porque una victoria de 9,27x en la parte alta de la curva de carga dice tanto sobre el oponente como sobre PolarDB. Un benchmark contra un sistema no identificado no puede reproducirse fuera de las dos empresas, y los lectores no tienen forma de comprobar si la base de datos de grafos fue dimensionada, ajustada o configurada como la ejecutaría un usuario en producción.

Por qué la memoria dejó de ser un registro de chat

El planteamiento del equipo ApsaraDB de Alibaba Cloud y de MemTensor es que las ventanas de contexto son una pista falsa. Las ventanas limitadas y la información perdida entre sesiones son síntomas superficiales, sostiene la fuente. El problema más difícil es escribir, recuperar y escalar la memoria en infraestructura compartida a medida que crece el volumen de usuarios, lo que convierte algo que parece una característica del modelo en un ejercicio de sistemas distribuidos.

Los agentes que pasan de responder preguntas de un solo turno a tareas de larga duración cambian para qué sirve la memoria. Una preferencia expresada una vez tiene que sobrevivir meses, docenas de sesiones y posiblemente varios agentes que trabajan para el mismo usuario. La fuente enumera lo que eso exige en producción: acceso de alta concurrencia, aislamiento multiusuario, recuperación ante fallos, escalado dinámico y gobernanza del ciclo de vida que decida cuándo debe actualizarse o eliminarse un hecho almacenado.

Una base de datos en lugar de tres

Una pila de memoria suele implicar tres despliegues. Los datos estructurados, como IDs de usuario, marcas de tiempo, etiquetas y ámbitos de permisos, van a una base de datos relacional. Los datos semánticos, como una preferencia declarada por tonos apagados o una paleta Morandi, van a un almacén vectorial. Las relaciones entre entidades y las rutas de múltiples saltos van a un almacén de grafos. Sincronizar los tres recae en la capa de aplicación.

PolarDB for PostgreSQL los colapsa en un solo sistema. Una extensión PGVector optimizada se encarga de la búsqueda semántica, el motor de grafos PolarAGE se encarga de las relaciones entre entidades, y PostgreSQL nativo cubre los datos estructurados. Alibaba Cloud afirma que PolarAGE alcanza decenas de miles de consultas por segundo con respuestas inferiores a 100 ms a escala de cientos de miles de millones de nodos, con recorrido de múltiples saltos y razonamiento de cadenas causales.

Colapsar los almacenes elimina una categoría de trabajo de sincronización. También significa aceptar la versión de un solo proveedor para tres cargas de trabajo diferentes. Un equipo que necesita un índice vectorial especializado, o un motor de grafos construido para un patrón de recorrido concreto, renuncia a la opción de incorporar un sistema dedicado.

Dentro de la ruta de escritura

El contenido de la conversación tiene que procesarse antes de convertirse en memoria. PolarDB ofrece tres operadores de modelo: un operador LLM que extrae hechos de largo plazo, preferencias y tripletas de entidades; un operador de embedding que convierte el contenido en vectores; y un operador de reranking que reordena los resultados de recuperación para que llegue menos material irrelevante al contexto del modelo.

Las llamadas a modelos priorizan Model Studio, el servicio de modelos de Alibaba Cloud, con los operadores dentro de la base de datos actuando como respaldo durante la alta carga. El respaldo es una medida de estabilidad, no una afirmación de que las dos rutas rindan de forma idéntica, y la fuente no las compara.

La recuperación se ejecuta en tres etapas. L1 realiza un cribado vectorial con filtrado de atributos y coincidencia de etiquetas, con una latencia declarada normalmente por debajo de 50 ms. L2 se expande a través del grafo desde los nodos candidatos hasta memorias relacionadas, manteniendo un P95 de ruta principal en el rango de 10 ms. L3 reordena los candidatos y hace que un LLM juzgue relaciones causales, conflictivas y condicionales, descartando duplicados y contenido irrelevante.

Multitenencia y la aritmética del coste

El aislamiento se corresponde con primitivas de base de datos. Un clúster de PolarDB es la frontera física, una base de datos separa líneas de negocio, un esquema contiene un MemCube, y las tablas o grafos almacenan nodos, vectores y aristas. Dentro de un solo MemCube, PolarDB particiona los subgrafos por UserID, lo que según la fuente mejora la eficiencia de recuperación en más del 50% a escala equivalente y admite espacios de memoria separados para decenas de millones de usuarios.

El argumento del coste se mantiene cualitativo. Las empresas dicen que los ciclos de integración se reducen de semanas a días, que almacenar nodos de memoria destilada en lugar de transcripciones en bruto recorta los tokens enviados al modelo, y que la separación entre almacenamiento y cómputo permite a la infraestructura seguir el uso real en lugar de la capacidad reservada. Ninguna cifra acompaña a ninguna de esas tres afirmaciones.

Lo que la fuente deja abierto

Varias preguntas necesitan respuesta antes de que los números tengan peso. La fuente atribuye el benchmark a MemOS Cloud y no ofrece verificación independiente, por lo que las cifras de latencia siguen siendo afirmaciones del proveedor hasta que un tercero las repita.

La identidad de la base de datos de comparación, su configuración y la versión de PolarDB probada quedan sin revelar. Sin ellos, 9,27x es una afirmación y no una medición que alguien pueda auditar.

Luego está la cuestión de quién tiene algo que ganar. Esta es una página de Alibaba Cloud que anuncia que el sistema de gestión de memoria PolarDB y MemOS está activo y que MemOS es de código abierto, con una consola, una API REST y SDKs de cliente. Se lee tanto como un lanzamiento de producto como un informe técnico. Eso no hace que la arquitectura sea errónea, y el problema que aborda, memoria duradera para agentes que funcionan durante meses, es real. Sí significa que los números más contundentes merecen una segunda prueba independiente antes de que las empresas reconstruyan una pila de memoria en torno a ellos.