Alibaba Cloud revendique un gain de 9,27x en mémoire IA face à un rival non nommé

MemOS Cloud a exécuté le benchmark, et les conditions divulguées sont celles que l'on attend d'un test contrôlé : configuration machine identique, jeux de données identiques, charge identique. Sur cinq points de charge entre 10 et 40 requêtes par seconde, PolarDB for PostgreSQL a affiché à chaque fois une latence P99 inférieure à celle de la base de données de comparaison. L'écart rapporté va de 1,79x à 9,27x, avec une médiane de 2,71x et une moyenne de 3,96x sur ces cinq points.

Aucune des deux entreprises ne nomme le rival. Cette omission compte, car un gain de 9,27x au sommet de la courbe de charge en dit autant sur l'adversaire que sur PolarDB. Un benchmark contre un système non identifié ne peut pas être reproduit en dehors des deux entreprises, et les lecteurs n'ont aucun moyen de vérifier si la base de données graphe a été dimensionnée, réglée ou configurée comme un utilisateur en production l'exploiterait.

Pourquoi la mémoire a cessé d'être un journal de conversation

La thèse de l'équipe ApsaraDB d'Alibaba Cloud et de MemTensor est que les fenêtres de contexte sont une fausse piste. Des fenêtres limitées et des informations perdues entre les sessions ne sont que des symptômes superficiels, soutient la source. Le problème plus difficile consiste à écrire, récupérer et faire évoluer la mémoire sur une infrastructure partagée à mesure que le volume d'utilisateurs croît, ce qui transforme ce qui ressemble à une fonctionnalité de modèle en un exercice de systèmes distribués.

Le passage des agents de la réponse à une question en un seul tour à des tâches de longue durée change la finalité de la mémoire. Une préférence exprimée une fois doit survivre des mois, des dizaines de sessions, et éventuellement plusieurs agents travaillant pour le même utilisateur. La source énumère ce que cela exige en production : accès à forte concurrence, isolation multi-locataires, reprise après incident, mise à l'échelle dynamique et gouvernance du cycle de vie qui décide quand un fait stocké doit être mis à jour ou supprimé.

Une base de données au lieu de trois

Une pile mémoire signifie généralement trois déploiements. Les données structurées telles que les identifiants utilisateur, les horodatages, les tags et les périmètres d'autorisation vont dans une base de données relationnelle. Les données sémantiques, comme une préférence exprimée pour des tons sourds ou une palette Morandi, vont dans un magasin vectoriel. Les relations entre entités et les chemins multi-sauts vont dans un magasin graphe. La synchronisation des trois incombe à la couche applicative.

PolarDB for PostgreSQL les fusionne en un seul système. Une extension PGVector optimisée gère la recherche sémantique, le moteur graphe PolarAGE gère les relations entre entités, et PostgreSQL natif couvre les données structurées. Alibaba Cloud affirme que PolarAGE atteint des dizaines de milliers de requêtes par seconde avec des réponses inférieures à 100 ms à l'échelle de centaines de milliards de nœuds, avec traversée multi-sauts et raisonnement en chaîne causale.

Fusionner les magasins élimine une catégorie de travail de synchronisation. Cela signifie aussi accepter la version d'un seul fournisseur pour trois charges de travail différentes. Une équipe qui a besoin d'un index vectoriel spécialisé, ou d'un moteur graphe conçu pour un schéma de traversée particulier, renonce à la possibilité d'intégrer un système dédié.

Au cœur du chemin d'écriture

Le contenu de la conversation doit être traité avant de devenir de la mémoire. PolarDB propose trois opérateurs de modèle : un opérateur LLM qui extrait les faits à long terme, les préférences et les triplets d'entités ; un opérateur d'embedding qui convertit le contenu en vecteurs ; et un opérateur de reclassement qui réordonne les résultats de rappel afin que moins de matériel non pertinent atteigne le contexte du modèle.

Les appels de modèle privilégient Model Studio, le service de modèles d'Alibaba Cloud, les opérateurs intégrés à la base de données servant de repli en cas de charge élevée. Ce repli est une mesure de stabilité, et non l'affirmation que les deux chemins se comportent de manière identique ; la source ne les compare pas.

Le rappel se déroule en trois étapes. L1 effectue un filtrage vectoriel avec filtrage d'attributs et correspondance de tags, avec une latence annoncée généralement inférieure à 50 ms. L2 s'étend à travers le graphe depuis les nœuds candidats vers les mémoires associées, maintenant un P95 du chemin principal de l'ordre de 10 ms. L3 reclasse les candidats et fait juger par un LLM les relations causales, conflictuelles et conditionnelles, en écartant les doublons et le contenu non pertinent.

Multi-tenance et arithmétique des coûts

L'isolation se mappe sur les primitives de la base de données. Un cluster PolarDB constitue la frontière physique, une base de données sépare les lignes métier, un schéma contient un MemCube, et les tables ou graphes stockent les nœuds, les vecteurs et les arêtes. À l'intérieur d'un même MemCube, PolarDB partitionne les sous-graphes par UserID, ce qui, selon la source, améliore l'efficacité du rappel de plus de 50 % à échelle équivalente et prend en charge des espaces mémoire distincts pour des dizaines de millions d'utilisateurs.

L'argument sur les coûts reste qualitatif. Les entreprises affirment que les cycles d'intégration passent de semaines à quelques jours, que stocker des nœuds de mémoire distillés plutôt que des transcriptions brutes réduit les tokens envoyés au modèle, et que la séparation stockage-calcul permet à l'infrastructure de suivre l'usage réel plutôt que la capacité réservée. Aucun chiffre n'accompagne aucune de ces trois affirmations.

Ce que la source laisse en suspens

Plusieurs questions demandent des réponses avant que les chiffres aient du poids. La source attribue le benchmark à MemOS Cloud et n'offre aucune vérification indépendante ; les chiffres de latence restent donc des affirmations de l'éditeur jusqu'à ce qu'un tiers les reproduise.

L'identité de la base de données de comparaison, sa configuration et la version de PolarDB testée restent non divulguées. Sans elles, 9,27x est une affirmation plutôt qu'une mesure que quiconque peut auditer.

Reste la question de savoir qui a à y gagner. Il s'agit d'une page d'Alibaba Cloud annonçant que le système de gestion de mémoire PolarDB et MemOS est en service et que MemOS est open source, avec une console, une API REST et des SDK clients. Elle se lit autant comme un lancement de produit que comme un rapport technique. Cela ne rend pas l'architecture fausse, et le problème qu'elle cible, une mémoire durable pour des agents qui tournent pendant des mois, en est un vrai. Cela signifie toutefois que les chiffres les plus forts méritent un second test indépendant avant que les entreprises ne reconstruisent une pile mémoire autour d'eux.