Memory Storage s'appuie sur Tablestore et offre aux agents d'IA des fonctionnalités Serverless pour l'écriture de la mémoire, l'extraction automatique et la récupération sémantique. Il prend en charge l'isolation des données à l'échelle de millions de locataires et la réutilisation de la mémoire entre les sessions.
Qu'est-ce que Memory Storage
Memory Storage s'appuie sur Tablestore et offre aux agents d'IA des fonctionnalités Serverless pour l'écriture de la mémoire, l'extraction automatique et la récupération sémantique. Les développeurs écrivent des messages de conversation ou du texte dans un magasin de mémoire ; le service conserve les messages bruts sous forme de mémoire à court terme et extrait automatiquement des unités de mémoire à long terme récupérables, qui sont persistées dans Tablestore. Lors de la récupération, le service combine la recherche sémantique et la recherche textuelle (avec une option de reclassement) pour renvoyer les mémoires à long terme pertinentes qu'un agent peut rappeler lors des conversations ultérieures selon les besoins.
Par rapport au développement autonome de l'extraction et de la récupération de la mémoire, ce service permet aux développeurs de se passer du provisionnement des appels LLM, de la recherche vectorielle ou en texte intégral, ainsi que des capacités d'isolation des données et d'audit. Le service prend en charge l'isolation des données à l'échelle de millions de locataires et la réutilisation de la mémoire entre les sessions.
Pour plus d'informations sur la facturation de Memory Storage, consultez Facturation du produit. Pour essayer rapidement Memory Storage, consultez Écrire et rappeler votre première mémoire.
Memory Storage est actuellement disponible dans les régions suivantes : Chine (Pékin), Chine (Shanghai), Chine (Hangzhou), Chine (Shenzhen), Chine (Hong Kong) et Singapour. Choisissez une région proche pour accéder au service.
Principaux avantages
-
Serverless et élastique
Architecture Serverless entièrement gérée : les utilisateurs n'ont pas à se soucier du déploiement ni de l'exploitation des ressources sous-jacentes. La tarification au paiement à l'utilisation implique un coût nul en l'absence d'utilisation. L'architecture distribuée permet une mise à l'échelle horizontale pour répondre aux besoins de scénarios impliquant des millions de locataires et des milliards de mémoires.
-
Extraction automatique de la mémoire, sans développement supplémentaire
Après l'écriture des messages de conversation ou du texte, les faits clés et les préférences sont automatiquement extraits pour générer des unités de mémoire structurées. Les développeurs n'ont pas besoin d'écrire de logique d'extraction supplémentaire ni de gérer eux-mêmes l'extraction et l'organisation de la mémoire. Vous pouvez utiliser des instructions d'extraction personnalisées au niveau du magasin de mémoire (
extractInstructions) pour orienter l'extraction vers les informations critiques pour l'activité. -
Récupération sémantique précise, économie de tokens
Un mode de récupération hybride combinant la recherche vectorielle et la recherche en texte intégral est pris en charge, utilisant le langage naturel comme entrée de requête pour rappeler les mémoires pertinentes. Par rapport à l'injection de l'historique complet des conversations, cette approche permet d'économiser environ 95 % des tokens, évitant ainsi la croissance en O(N²) et la dégradation des performances liée au phénomène « Lost in the Middle ».
-
Isolation massive des locataires
L'isolation des données est assurée par un périmètre (Scope) à quatre niveaux composé de
appId,tenantId,agentIdetrunId. Les développeurs peuvent organiser les limites des données de mémoire par application, locataire, agent et session, répondant ainsi aux exigences d'isolation multi-locataires à l'échelle de millions de locataires. -
Lecture via une vue fichier
La mémoire structurée gérée par le service prend en charge deux méthodes de lecture : une lecture structurée via le SDK, la CLI et d'autres interfaces, ou une lecture par répertoire et fichier via une vue fichier. La vue fichier présente les données de mémoire sous forme de fichiers en lecture seule. Les applications continuent d'écrire ou de modifier la mémoire source via des interfaces structurées, ce qui empêche les conflits entre les opérations sur les fichiers et la mémoire structurée.
-
Mémoire fichier
Si vous disposez déjà de fichiers Markdown ou d'autres fichiers texte UTF-8, ou si vous devez organiser vous-même les répertoires de mémoire, vous pouvez écrire directement des fichiers dans un magasin de mémoire fichier. L'application contrôle les chemins d'accès aux fichiers et peut créer, lire, mettre à jour, renommer et supprimer des fichiers, ainsi que consulter les versions historiques. La fonction Dream de la mémoire fichier peut également fusionner, corriger et réorganiser des fichiers texte entre différents périmètres (Scopes), et écrire automatiquement les résultats dans un périmètre de sortie spécifié.
-
Compilation des connaissances et consolidation de la mémoire
Wiki construit de manière asynchrone des documents sources en pages Markdown interconnectées pour une réutilisation entre les sessions. Un agent peut d'abord rechercher dans le Wiki, puis lire les pages correspondantes par leur chemin, réutilisant ainsi les connaissances persistantes du même agent entre différentes sessions. La consolidation de la mémoire (Dream) s'exécute en arrière-plan pour effectuer un affinage secondaire du contenu ingéré, notamment la fusion, la déduplication, la mise à jour et l'extraction de profils de compétences.
Scénarios d'application typiques
|
Scénario |
Description |
|
Continuité des conversations multi-tours |
Dans les scénarios de conversation longue, les messages historiques sont écrits dans le magasin de mémoire. Le service conserve les messages bruts et extrait les faits clés. Les conversations ultérieures ne rappellent que les mémoires pertinentes selon les besoins, évitant ainsi d'injecter l'historique complet dans le contexte. |
|
Rétention des préférences entre les sessions |
Les préférences, habitudes et contraintes exprimées par l'utilisateur entre plusieurs sessions sont extraites sous forme d'unités de mémoire à long terme. Lors de nouvelles sessions, elles sont rappelées via la recherche sémantique, permettant à l'agent de maintenir un style de réponse cohérent à différents moments et points d'entrée. |
|
Partage des connaissances entre plusieurs agents |
En utilisant un caractère générique pour |
|
Graphe de connaissances de l'agent |
Les descriptions de produits, les manuels d'utilisation et les conventions de projet sont maintenus en continu en tant que sources Wiki. Le service transforme ces documents en pages consultables et interconnectées avec des références aux sources. Différentes sessions peuvent partager le Wiki du même périmètre d'agent tout en ne lisant que les quelques pages nécessaires à la tâche actuelle. |
|
Accumulation du profil utilisateur |
Les comportements, attributs et faits historiques de l'utilisateur sont écrits en continu dans le magasin de mémoire. Le service les fusionne automatiquement en unités de profil structurées que les agents en aval (recommandation, service client, marketing) peuvent rappeler et utiliser directement. |
L'extraction de la mémoire est un processus asynchrone effectué automatiquement par le système. Les scénarios nécessitant une réactivité d'écriture en temps réel extrêmement élevée ou des stratégies d'extraction entièrement personnalisées doivent être évalués en conséquence.
Pour les requêtes portant uniquement sur des données structurées, utilisez le modèle de table large de Tablestore ou une base de données relationnelle.
Pour les scénarios ne nécessitant que la gestion de la fenêtre de contexte sans mémoire persistante, utilisez directement la fenêtre de contexte du LLM.
Glossaire
Les données d'un magasin de mémoire sont organisées dans les entités suivantes.
|
Entité |
Description |
|
MemoryStore |
Le magasin de mémoire, conteneur de niveau supérieur pour la gestion des données de mémoire |
|
Memory |
Mémoire à long terme, informations récupérables extraites des conversations ou du texte |
|
Message |
Mémoire à court terme, enregistrements originaux des messages de conversation écrits dans le magasin |
|
Item |
Fichier de mémoire avec un chemin d'accès et une version |
|
Wiki |
Collection de pages de graphe de connaissances organisées par périmètre d'agent à trois segments |
|
Tâche Dream / Action |
Tâche de consolidation asynchrone et ses enregistrements structurés de modifications de mémoire ou de fichiers |
MemoryStore
Un MemoryStore est le magasin de mémoire, le conteneur de niveau supérieur pour la gestion des données de mémoire. Vous créez d'abord un magasin de mémoire, puis vous y écrivez des messages, récupérez des mémoires ou interrogez les enregistrements d'audit. Vous pouvez diviser les magasins de mémoire par application, environnement (développement, test, production) ou ligne métier. Le nom ne peut contenir que des lettres, des chiffres et des traits de soulignement, avec un maximum de 32 caractères.
Memory
Une Memory est une mémoire à long terme. Après l'écriture des messages de conversation ou du texte, le service extrait les informations pouvant être stockées de manière persistante et récupérées, et génère des unités de mémoire. Chaque unité contient généralement un ID de mémoire, du texte, un périmètre (Scope), des métadonnées, une heure de création et des informations de gestion des versions.
Message
Un Message est une mémoire à court terme, c'est-à-dire l'enregistrement original du message de conversation écrit dans le magasin de mémoire. Les messages peuvent être interrogés via ListMemoryStoreMessages. Pour les règles de périmètre de la mémoire à court terme, consultez la section Gestion de la hiérarchie des périmètres.
Item
Fichier de mémoire avec un chemin d'accès et une version. Dans un magasin de mémoire fichier, les fichiers texte (tels que Markdown) sont organisés par chemin d'accès, prenant en charge la création, la lecture, la mise à jour, la suppression et l'interrogation des versions historiques. Pour la fusion, la correction et la réorganisation entre périmètres dans la fonction Dream de la mémoire fichier, consultez la section Consolidation de la mémoire dans Agentic Task.
Wiki
Collection de pages de graphe de connaissances organisées par périmètre d'agent à trois segments, permettant au même agent de réutiliser les connaissances persistantes entre différentes sessions. Pour plus de détails, consultez Compilation des connaissances (Wiki).
Tâche Dream / Action
Tâche de consolidation asynchrone (Dream Task) pour le contenu ingéré, produisant des mémoires structurées ou des enregistrements de modifications de fichiers (Dream Action). Pour plus de détails, consultez Memory Dream.
Gestion de la hiérarchie des périmètres
Un périmètre (Scope) représente la propriété et la limite d'isolation des données de mémoire. Le service de mémoire utilise un périmètre à quatre niveaux composé de appId, tenantId, agentId et runId.
|
Champ |
Description |
|
|
Identifiant de l'application, correspondant généralement à une application métier ou un produit |
|
|
Identifiant du locataire ou de l'utilisateur |
|
|
Identifiant de l'agent |
|
|
Identifiant de la session, de l'exécution ou de la tâche |
La hiérarchie des périmètres est la suivante :
appId > tenantId > agentId > runIdRègles principales :
Lors de l'écriture,
appIdest obligatoire. Les autres champs prennent par défaut la valeur__default__lorsqu'ils sont vides. Les caractères génériques*ne sont pas autorisés lors de l'écriture.Lors de la récupération de la mémoire,
appIdest obligatoire et ne peut pas être*. Les autres champs prennent par défaut la valeur__default__lorsqu'ils sont omis ; la transmission explicite de*indique un caractère générique.Lors de l'interrogation de la mémoire à court terme, les quatre champs sont obligatoires et les caractères génériques ne sont pas autorisés.
Exemples courants de périmètres de récupération
|
Périmètre de récupération |
Paramètres du périmètre |
Scénario applicable |
|
Au sein de la session actuelle |
|
Souhaite utiliser uniquement l'historique de la session actuelle |
|
Entre les sessions |
|
Le même agent réutilise les préférences de l'utilisateur entre plusieurs sessions |
|
Entre les agents et les sessions |
|
Plusieurs agents partagent la mémoire utilisateur |
Périmètre et choix entre plusieurs magasins de mémoire
MemoryStore permet de créer des magasins de mémoire indépendants par application, environnement ou ligne métier. Lorsque les données appartiennent à différents utilisateurs ou agents au sein de la même application, il est recommandé d'utiliser le périmètre pour l'isolation au sein du même magasin de mémoire, afin de réduire les coûts de gestion et de prendre en charge la récupération avec caractères génériques entre les périmètres. Lorsque différents domaines métier nécessitent des espaces de données totalement indépendants, il est recommandé de créer plusieurs magasins de mémoire.
Gestion des données de mémoire
Écriture de la mémoire
Le service de mémoire prend en charge les deux méthodes d'écriture suivantes :
Écriture des messages de conversation : Écriture via l'API
AddMemoriesen transmettant le tableaumessages. Le service enregistre les messages bruts sous forme de mémoire à court terme et génère une mémoire structurée, des fichiers de mémoire en lecture seule, ou les deux, en fonction du paramètreoutputTypesdu magasin de mémoire.Écriture de texte : Écriture via l'API
AddMemoriesen transmettant le champtextpour soumettre directement du contenu en texte brut et générer la sortie configurée pour le magasin de mémoire.
Les informations de périmètre doivent être spécifiées lors de l'écriture, où appId est obligatoire. tenantId, agentId et runId prennent par défaut la valeur __default__ lorsqu'ils sont vides. Les caractères génériques * ne sont pas autorisés lors de l'écriture.
Les écritures sont asynchrones par défaut (sync=false) : les messages bruts sont persistés en premier et peuvent être immédiatement interrogés en tant que mémoire à court terme, tandis que la sortie configurée est générée en arrière-plan. Vous pouvez utiliser l'identifiant requestId renvoyé par AddMemories pour appeler GetMemoryTask afin de suivre l'état de la tâche. Les magasins de mémoire incluant une sortie file ne prennent en charge que les écritures asynchrones. Le magasin de mémoire prend également en charge des instructions d'extraction personnalisées (extractInstructions), définies lors de la création ou de la mise à jour du magasin de mémoire, pour injecter des invites d'extraction qui orientent l'extraction de la mémoire à long terme du magasin vers les informations critiques pour l'activité.
Récupération de la mémoire
SearchMemories permet de récupérer la mémoire à long terme en utilisant le langage naturel. Le service combine les capacités de recherche sémantique et de recherche textuelle et prend en charge le reclassement (Rerank), activé par défaut.
Lors de la récupération, appId et tenantId sont des champs obligatoires. agentId et runId peuvent utiliser le caractère générique * pour élargir le périmètre de récupération.
Les résultats de récupération renvoient à la fois un score de fusion (score) et une similarité normalisée (similarity). Vous pouvez filtrer les résultats peu pertinents en utilisant minSimilarity. Définissez includeEvidence=true pour inclure les fragments de message originaux (evidence) correspondant aux mémoires trouvées dans les résultats, améliorant ainsi l'explicabilité du modèle de réponse.
La mémoire à long terme prend en charge l'ajout de métadonnées. Les métadonnées peuvent être utilisées pour stocker des informations métier personnalisées telles que la source de la mémoire, les tags et la priorité. Les métadonnées sont stockées conjointement avec l'unité de mémoire, et les champs de métadonnées correspondants sont renvoyés dans les résultats de récupération.
Agentic Task
Consolidation de la mémoire (Dream)
La consolidation de la mémoire (Dream) est une fonctionnalité asynchrone permettant un affinage secondaire des données existantes dans un magasin de mémoire. Les magasins de mémoire structurée et les magasins de mémoire fichier accessibles en écriture utilisent des modèles d'entrée et d'écriture différents.
Dream de la mémoire structurée
Le service analyse en arrière-plan la mémoire à long terme et les messages bruts pour produire des actions de consolidation applicables. Les cibles de consolidation se répartissent en trois catégories :
Consolidation de la mémoire (memory) : Déduplication, réécriture et fusion des mémoires à long terme, et suppression des entrées obsolètes.
Extraction de compétences (skill) : Extraction de compétences réutilisables à partir des interactions historiques.
Extraction de profil (profile) : Accumulation de profils utilisateur structurés.
La consolidation de la mémoire structurée prend en charge les modes proposal, safe_auto et plan à haute intensité. Le mode proposal génère des propositions qui sont appliquées après confirmation manuelle ou programmatique ; le mode safe_auto les applique automatiquement lorsqu'un seuil de confiance est atteint ; le mode plan attend d'abord l'approbation du plan, puis exécute la portée de suppression autorisée.
Dream de la mémoire fichier
Pour les magasins de mémoire avec inputType=file et outputTypes=["file"], Dream fige les versions des fichiers texte à partir d'un ou plusieurs périmètres d'entrée et écrit automatiquement les résultats complets consolidés dans un périmètre de sortie déterministe. Les actions sur les fichiers incluent la création, la mise à jour, le renommage et la suppression. Toutes les mises à jour et suppressions sont protégées par des préconditions de version pour garantir la sécurité des écritures concurrentes.
Le Dream de la mémoire fichier utilise un mode automatique fixe à haute intensité et ne produit pas de propositions en attente d'application manuelle. L'interrogation des tâches et des actions utilise toujours GetMemoryDreamTask, ListMemoryDreamTasks et ListMemoryDreamActions. Pour le processus détaillé, consultez Memory Dream.
Compilation des connaissances (Wiki)
Agent Wiki construit de manière asynchrone les fichiers sources situés sous /.wiki/raw/ en pages Markdown interconnectées. Chaque Wiki appartient exclusivement à un magasin de mémoire et à un périmètre appId / tenantId / agentId à trois segments. Différentes sessions du même agent partagent les pages.
Les applications utilisent GetWiki pour interroger ou créer automatiquement un Wiki, IngestWiki pour construire le Wiki, et ListWikiPages, SearchWikiPages et GetWikiPage pour consommer les pages publiées. Avant la publication d'une nouvelle construction, l'ancien ensemble de pages reste lisible. Pour le processus détaillé, consultez Compilation des connaissances (Wiki).
Fonctionnalités entreprise
Audit des requêtes
Le service enregistre les requêtes adressées au magasin de mémoire, qui peuvent être interrogées via ListMemoryStoreRequests. Les enregistrements d'audit incluent des champs tels que le type d'opération, le statut de la réponse, la latence et la raison de l'échec, ce qui convient au dépannage des opérations d'écriture, de récupération et de gestion.
Tâches et observabilité
L'écriture de la mémoire et la consolidation de la mémoire sont toutes deux des tâches asynchrones. Le service fournit des capacités d'interrogation complémentaires :
GetMemoryTasketListMemoryTasks: Interrogation du statut et de la sortie des tâches d'extraction de mémoire.GetMemoryDreamTask,ListMemoryDreamTasksetListMemoryDreamActions: Interrogation des tâches et actions de consolidation de la mémoire.ListMemoryStoreScopes: Utilisation d'unscopeà quatre niveaux ou d'unfilterstructuré pour lister les périmètres de conversation enregistrés. Renvoie une cléscopeKeystable pour découvrir et paginer les plages de sessions.ListMemoryStoreRequests: Interrogation des journaux d'audit des requêtes.
Référence des performances
Le service de mémoire Tablestore a été évalué selon trois dimensions — précision de la récupération, latence de la récupération et échelle de stockage — et comparé à Mem0, une solution de mémoire grand public dans l'industrie.
|
Dimension |
Service de mémoire Tablestore |
Comparaison industrielle |
|
Précision globale de la récupération |
88,25 % |
Environ 37,4 % supérieur à Mem0 (64,20 %) |
|
Latence P50 de la récupération |
~155 ms |
Les solutions similaires affichent généralement 200–500 ms, soit une réduction d'environ 75 % |
|
Échelle de stockage vérifiée |
Des centaines de millions d'entrées de mémoire, mise à l'échelle horizontale sans limite supérieure |
Les solutions similaires se situent généralement au niveau du million à quelques dizaines de millions |
|
Économie de tokens |
95 % |
Économie d'environ 95 % par rapport au Plan A (injection complète) |
Les données ci-dessus illustrent les limites des capacités du service. Les performances réelles sont affectées par l'échelle des données, les modèles de requête, les conditions réseau, la configuration du modèle et la distribution des données métier. Vous trouverez ci-dessous les évaluations détaillées pour chaque dimension.