Todos os produtos
Search
Central de documentação

Tablestore:Memory Storage Service

Última atualização: Oct 21, 2026

O Memory Storage é um service de memória serverless criado no Tablestore da Alibaba Cloud para AI Agents. Ele oferece recursos de gravação de memória, extração automática e busca semântica. O Memory Storage suporta isolamento de dados multilocatário na escala de milhões de locatários e reutilização de memória entre sessões.

O que é o Memory Storage

Você grava mensagens de conversa ou texto em um repositório de memória. O Memory Storage retém as mensagens originais como memória de curto prazo e extrai automaticamente unidades de memória de longo prazo recuperáveis, persistindo-as no Tablestore. Durante a recuperação, o Memory Storage combina busca semântica e busca de texto, com suporte à classificação Rerank, para retornar memórias de longo prazo relevantes que um Agent pode recordar conforme necessário nas conversas subsequentes.

Em comparação com a construção da sua própria extração e recuperação de memória, você não precisa provisionar chamadas de LLM, busca vetorial, busca de texto completo, isolamento de dados ou recursos de auditoria. O Memory Storage fornece esses recursos como parte do service.

Principais benefícios

O Memory Storage oferece os seguintes benefícios principais:

  • Serverless e elasticidade — A arquitetura serverless totalmente gerenciada elimina a necessidade de implantar ou manter recursos subjacentes. Com o modelo de pagamento conforme o uso, não há cobrança quando não há utilização. A arquitetura distribuída faz dimensionamento horizontal para cenários com milhões de locatários e dezenas de bilhões de memórias.

  • Extração automática de memória sem desenvolvimento adicional — Após gravar mensagens de conversa ou texto, o Memory Storage extrai automaticamente fatos e preferências-chave para gerar unidades de memória estruturadas. Você não precisa escrever lógica de extração adicional nem gerencie a extração e organização de memória por conta própria. É possível usar instruções de extração personalizadas no nível do repositório de memória para focar a extração em informações críticas para o negócio.

  • Busca semântica precisa que economiza tokens — O Memory Storage suporta um modo híbrido de busca vetorial e busca de texto completo que usa linguagem natural como entrada de consulta para recordar memórias relevantes. Em comparação com a inclusão do histórico completo de conversas, ele economiza aproximadamente 95% dos tokens e evita o crescimento O(N²) e a degradação de desempenho "Lost in the Middle", na qual um modelo presta menos atenção às informações no meio de um contexto longo.

  • Isolamento de locatários em grande escala — O Memory Storage usa um Scope de quatro níveis para isolar dados. Você pode organizar os limites de dados de memória por aplicação, locatário, Agent e sessão para atender aos requisitos de isolamento multilocatário no nível de milhões de locatários. Para mais detalhes, consulte Scope hierarchy management.

  • Acesso por visualização de arquivos — A memória estruturada gerenciada pelo service suporta dois métodos de acesso: acesso estruturado por meio de um SDK, cli ou outra interface, e acesso baseado em diretórios e arquivos por meio de uma visualização de arquivo. A visualização de arquivo apresenta os dados de memória como arquivos somente leitura. Você continua gravando ou modifique as memórias de origem por meio de interfaces estruturadas, o que evita conflitos entre operações de arquivo e memórias estruturadas.

  • Memória de arquivos — Se você já possui arquivos de texto Markdown ou outros arquivos UTF-8, ou precisa organizar diretórios de memória por conta própria, pode gravar arquivos diretamente em um repositório de memória de arquivos. Você controla os caminhos dos arquivos. crie, leia, atualize, renomeie e exclua arquivos, e consulte versões históricas. O File Memory Dream também pode mesclar, corrigir e reorganizar arquivos de texto entre Scopes, e gravar automaticamente os resultados em um Scope de saída especificado.

  • Compilação de conhecimento (Wiki) e Consolidação de memória (Dream) — O Wiki compila documentos de origem de forma assíncrona em páginas Markdown interligadas para reutilização entre sessões. Um Agent pode pesquisar primeiro no Wiki e depois ler as páginas correspondentes por caminho, reutilizando o conhecimento persistente do mesmo Agent entre sessões. A Consolidação de Memória (Dream) refina o conteúdo ingerido de forma assíncrona em segundo plano, incluindo mesclagem, deduplicação, atualizações e extração de perfil de habilidades. Para mais detalhes, consulte Agentic Task.

Cenários comuns

A tabela a seguir descreve cenários comuns para o Memory Storage:

Cenário

Descrição

Continuidade de conversa em múltiplas rodadas

Em conversas longas, as mensagens históricas são gravadas no repositório de memória. O Memory Storage retém as mensagens originais e extrai fatos-chave. As conversas subsequentes recordam apenas as memórias relevantes conforme necessário, evitando a injeção do histórico completo no contexto.

Reutilização de preferências entre sessões

Preferências, hábitos e restrições que um usuário expressa em várias sessões são extraídos como unidades de memória de longo prazo. Novas sessões os recordam por meio de busca semântica, permitindo que o Agent mantenha um estilo de resposta consistente em diferentes momentos e pontos de entrada.

Compartilhamento de conhecimento entre múltiplos Agents

Ao usar um curinga para agentId no Scope de quatro níveis, múltiplos Agents podem compartilhar a mesma memória de usuário dentro de um locatário, evitando a extração e manutenção repetidas dos mesmos fatos em cada Agent.

Grafo de conhecimento do Agent

Descrições de product, manuais de operação e convenções de projeto podem ser mantidos como sources do Wiki. O Memory Storage os compila em páginas pesquisáveis e interligadas com referências de origem. Diferentes sessões podem compartilhar o Wiki no mesmo Scope do Agent, lendo apenas as páginas necessárias para a tarefa atual.

Acumulação de perfil de usuário

Comportamentos, atributos e fatos históricos do usuário são gravados continuamente no repositório de memória. O Memory Storage os consolida automaticamente em unidades de perfil estruturadas para que os Agents downstream possam recordar e usar em recomendações, atendimento ao cliente e marketing.

Limites

Nota

O Memory Storage está disponível atualmente nas seguintes regiões: china (Beijing), china (Shanghai), china (Hangzhou), china (Shenzhen), china (Hong Kong) e Singapore. selecione uma região próxima para acessar o service.

Antes de usar o Memory Storage, observe os seguintes itens:

  • Extração assíncrona — A extração de memória é assíncrona e realizada automaticamente pelo sistema. Se o seu cenário exige latência de gravação extremamente baixa ou estratégias de extração totalmente personalizadas, avalie o Memory Storage cuidadosamente antes da adoção.

  • Consultas de dados estruturados — Para consultas de dados puramente estruturados, use o modelo de tabela ampla do Tablestore ou um banco de dados relacional.

  • Cenários apenas com janela de contexto — Para cenários que exigem apenas o gerenciamento da janela de contexto e nenhuma memória persistente, use diretamente a janela de contexto do LLM.

  • Nomes de repositório de memória — Um nome de repositório de memória pode conter apenas letras, números e sublinhados, e ter até 32 caracteres.

Glossário

Os dados em um repositório de memória são organizados nas seguintes entidades.

MemoryStore

Um MemoryStore é um repositório de memória, o contêiner de nível superior para gerencie dados de memória. crie um repositório de memória antes de gravar mensagens nele, recuperar memórias dele ou consultar registros de auditoria. Você pode separar os repositórios de memória por aplicação, ambiente (como desenvolvimento, teste ou produção) ou linha de negócio.

Memory

Um Memory é a memória de longo prazo. Após a gravação de mensagens de conversa ou texto, o Memory Storage extrai informações que podem ser armazenadas e recuperadas ao longo do tempo e gera unidades de memória. Cada unidade geralmente contém um ID de memória, texto, Scope, metadados, horário de criação e informações de gerenciamento de versão.

Message

Um Message é a memória de curto prazo: um registro de mensagem de conversa original gravado em um repositório de memória. Você pode consultar mensagens usando ListMemoryStoreMessages. Para as regras de Scope para memória de curto prazo, consulte Scope hierarchy management.

Item

Um Item é um arquivo de memória com um caminho e versão. Um repositório de memória de arquivos organiza arquivos de texto, como arquivos Markdown, por caminho. crie, leia, atualize, exclua e visualize versões históricas. Para mesclagem, correção e reorganização entre Scopes no File Memory Dream, consulte Memory Consolidation (Dream) em Agentic Task.

Wiki

Um Wiki é uma coleção de páginas de grafo de conhecimento organizadas por um Scope de Agent de três segmentos (appId, tenantId e agentId). Um Wiki permite que o mesmo Agent reutilize conhecimento persistente entre sessões. Para mais detalhes, consulte Knowledge Compilation (Wiki).

Dream Task / Action

Um Dream Task é uma tarefa de consolidação assíncrona para conteúdo ingerido. Ele produz memória estruturada ou registros de alteração de arquivo chamados Dream Actions. Para mais detalhes, consulte Memory Consolidation (Dream).

Gerenciamento de hierarquia de Scope

Um Scope representa a propriedade e o limite de isolamento dos dados de memória. O Memory Storage usa um Scope de quatro níveis que compreende appId, tenantId, agentId e runId.

Campo

Descrição

appId

Identificador da aplicação, geralmente correspondente a uma aplicação ou product de negócio

tenantId

Identificador do locatário ou usuário

agentId

Identificador do Agent

runId

Identificador da sessão, execução ou tarefa

A hierarquia do Scope é:

appId > tenantId > agentId > runId

Regras principais

  • Gravação — O appId é obrigatório. Outros campos assumem o valor padrão __default__ quando estão vazios. Curingas (*) não são permitidos.

  • Recuperação de memória — O appId e o tenantId são obrigatórios, e o appId não pode ser *. O agentId e o runId assumem o valor padrão __default__ quando omitidos. Passar * explicitamente indica um curinga.

  • Consultas de memória de curto prazo — Todos os quatro campos são obrigatórios e curingas não são permitidos.

A tabela a seguir lista exemplos comuns de escopo de recuperação:

Escopo de recuperação

Configurações do Scope

Cenário aplicável

Dentro da sessão atual

Especifique todos os campos appId, tenantId, agentId e runId

Use apenas o histórico da sessão atual

Entre sessões

appId + tenantId + agentId + runId="*"

O mesmo Agent reutiliza as preferências do usuário entre sessões

Entre Agents e entre sessões

appId + tenantId + agentId="*" + runId="*"

Múltiplos Agents compartilham a memória do usuário

Scope e múltiplos repositórios de memória

O MemoryStore suporta a criação de repositórios de memória independentes por aplicação, ambiente ou linha de negócio. Quando os dados pertencem a diferentes usuários ou Agents na mesma aplicação, use o Scope para isolar os dados no mesmo repositório de memória. Essa abordagem reduz os custos de gerenciamento e suporta buscas com curingas entre Scopes. Quando diferentes domínios de negócio exigem espaços de dados totalmente independentes, crie múltiplos repositórios de memória.

Gerenciamento de dados de memória

Gravação de memória

O Memory Storage suporta as seguintes duas formas de gravar memórias:

  • Gravar mensagens de conversa — Chame AddMemories com o array messages. O Memory Storage retém as mensagens originais como memória de curto prazo e gera memória estruturada, arquivos de memória somente leitura, ou ambos, de acordo com os outputTypes do repositório de memória.

  • Gravar texto — Chame AddMemories com o campo text para envie conteúdo de texto simples diretamente e gerar a saída configurada para o repositório de memória.

Ao gravar memórias, especifique as informações do Scope. Para os campos obrigatórios do Scope e valores padrão, consulte Scope hierarchy management.

As gravações são executadas de forma assíncrona por padrão (sync=false). As mensagens originais são armazenadas primeiro e podem ser consultadas imediatamente como memória de curto prazo, enquanto as saídas configuradas são geradas em segundo plano. Use o requestId retornado por AddMemories para chamar GetMemoryTask e rastrear o status da tarefa. Repositórios de memória que incluem saída file suportam apenas gravações assíncronas.

Além disso, defina instruções de extração personalizadas (extractInstructions) ao crie ou atualize um repositório de memória. Essas instruções são injetadas no prompt de extração para focar a extração de memória de longo prazo desse repositório em informações críticas para o negócio.

Recuperação de memória

O SearchMemories suporta a recuperação de memórias de longo prazo usando linguagem natural. O Memory Storage combina busca semântica e busca de texto e suporta a classificação Rerank, que é ativada por padrão.

Você pode usar o curinga * para agentId e runId para ampliar o escopo de recuperação. Para os campos obrigatórios do Scope e regras de curinga, consulte Scope hierarchy management.

Os resultados da recuperação retornam tanto uma pontuação fusionada (score) quanto uma similaridade normalizada (similarity). Use minSimilarity para filtrar resultados de baixa relevância. Defina includeEvidence=true para incluir os fragmentos de mensagem original (evidence) correspondentes às memórias compatíveis nos resultados, o que ajuda a tornar as respostas mais explicáveis.

As memórias de longo prazo suportam metadados adicionais (metadata). Use metadados para armazenar informações específicas do negócio, como a source, tags e prioridade de uma memória. Cada campo de metadado é armazenado com sua unidade de memória e retornado como um campo de dados nos resultados de recuperação.

Agentic Task

Consolidação de Memória (Dream)

A Consolidação de Memória (Dream) executa de forma assíncrona um refinamento secundário nos dados já armazenados em um repositório de memória. Repositórios de memória estruturados e repositórios de memória de arquivos graváveis usam modelos de entrada e gravação diferentes.

Dream de memória estruturada

O Memory Storage analisa memórias de longo prazo e mensagens originais em segundo plano e produz ações de consolidação aplicáveis. Existem três categorias de alvos de consolidação:

  • **Consolidação de memória (memory)** — Deduplique, reescreva e mescle memórias de longo prazo, e exclua itens desatualizados.

  • **Extração de habilidades (skill)** — Extraia habilidades reutilizáveis de interações históricas.

  • **Extração de perfil (profile)** — crie perfis de usuário estruturados.

A consolidação de memória estruturada suporta os modos proposal, safe_auto e plan:

  • O modo proposal gera propostas que são aplicadas após você confirmar manual ou programaticamente.

  • O modo safe_auto aplica propostas automaticamente quando o nível de confiança atinge o limiar.

  • O modo plan é um modo de alta intensidade que aguarda a aprovação do plano antes de execute o escopo de exclusão autorizado.

File Memory Dream

Para repositórios de memória com inputType=file e outputTypes=["file"], o Dream congela versões de arquivos de texto de um ou mais Scopes de entrada e grava automaticamente o resultado consolidado completo em um Scope de saída específico. As ações de arquivo incluem criação, atualizações, renomeações e exclusão. Todas as atualizações e exclusões usam pré-condições de versão para proteger contra gravações simultâneas.

O File Memory Dream sempre usa um modo automático de alta intensidade e não gera propostas que aguardam aplicação manual. Você ainda pode consultar tarefas e ações usando GetMemoryDreamTask, ListMemoryDreamTasks e ListMemoryDreamActions. Para o fluxo de trabalho detalhado, consulte Memory Consolidation (Dream).

Compilação de Conhecimento (Wiki)

O Agent Wiki compila de forma assíncrona arquivos source em /.wiki/raw/ em páginas Markdown interligadas. Cada Wiki pertence a exatamente um repositório de memória e a um Scope de três segmentos appId / tenantId / agentId. Diferentes sessões do mesmo Agent compartilham as páginas.

Use as seguintes operações para compilar e consumir um Wiki:

  1. Chame GetWiki para consultar um Wiki ou crie um automaticamente.

  2. Chame IngestWiki para compilar o Wiki.

  3. Chame ListWikiPages, SearchWikiPages e GetWikiPage para consumir páginas publicadas.

Antes que uma nova compilação seja publicada, o conjunto anterior de páginas permanece disponível para leitura. Para o fluxo de trabalho detalhado, consulte Knowledge Compilation (Wiki).

Recursos empresariais

Auditoria de requisições

O Memory Storage registra requisições do repositório de memória. Você pode execute uma consulta de log através de ListMemoryStoreRequests. Os registros de auditoria contêm o tipo de operação, status de resposta, latência, motivo da falha e outras informações, ajudando você a solucionar problemas de operações de gravação, recuperação e gerenciamento.

Tarefas e observabilidade

A gravação de memória e a consolidação de memória são tarefas assíncronas. O Memory Storage fornece os seguintes recursos de consulta:

  • GetMemoryTask e ListMemoryTasks: Consulte o status e a saída das tarefas de extração de memória.

  • GetMemoryDreamTask, ListMemoryDreamTasks e ListMemoryDreamActions: Consulte tarefas e ações de consolidação de memória.

  • ListMemoryStoreScopes: Liste Scopes de conversa registrados usando o scope de quatro níveis ou um filter estruturado. Ele retorna um scopeKey estável para descobrir e paginar intervalos de sessão.

  • ListMemoryStoreRequests: Consulte logs de auditoria de requisições.

Referência de desempenho

O Memory Storage foi avaliado em precisão de recuperação, latência de recuperação, escala de armazenamento e custo de tokens. A avaliação de precisão de recuperação compara o Memory Storage com a solução de memória Mem0.

Dimensão

Memory Storage

Comparação com o setor

Precisão geral de recuperação

88,25%

Aproximadamente 37,4% maior que o Mem0 (64,20%), com base nos resultados de avaliação pública do Mem0

Latência de recuperação P50

155–222 ms, dependendo do topK (medido com Rerank desativado na escala de 100 milhões de entradas)

Soluções semelhantes geralmente levam de 200 a 500 ms

Escala de armazenamento verificada

Mais de 100 milhões de entradas de memória e 1,2 milhão de locatários em um único repositório de memória, com dimensionamento horizontal e sem limite superior

Soluções semelhantes geralmente suportam de milhões a dezenas de milhões de entradas

Economia de tokens

95%

Aproximadamente 95% menor que o Plano A, que injeta o histórico completo de conversas em cada rodada

Nota

A latência de recuperação P50 é medida com o Rerank desativado. O Rerank é ativado por padrão e aumenta a latência de recuperação em 200–300 ms.

Esses resultados ilustram os limites de capacidade do service. Os resultados reais são afetados pelo volume de dados, padrões de consulta, condições de rede, configuração do modelo e distribuição de dados de negócio. As seções a seguir fornecem avaliações detalhadas para cada dimensão.

Precisão de recuperação

Benchmark: conjunto de dados LoCoMo

O LoCoMo é um benchmark para avaliar sistemas de memória. Ao contrário dos conjuntos de avaliação anteriores que cobrem apenas de três a cinco rodadas de conversas curtas, cada pacote de dados de teste do LoCoMo tem uma média de 300 rodadas de conversa em 35 sessões, o que se assemelha muito às interações de longo prazo do mundo real entre usuários e assistentes de IA.

O LoCoMo define cinco categorias de resposta a perguntas de raciocínio: single-hop, multi-hop, raciocínio temporal, domínio aberto e perguntas adversariais. A avaliação usa quatro dessas categorias e exclui perguntas adversariais.

Dimensão de avaliação

Significado

Cenário típico em conversas diárias

Raciocínio single-hop

Encontrar diretamente um fato em uma única sessão

"O que eu disse que gostava de beber da última vez?"

Raciocínio multi-hop

Combinar informações de múltiplas sessões para derivar uma resposta

"Com base nas minhas preferências alimentares e relatório de check-up de saúde, recomende um almoço."

Raciocínio temporal

Entender pistas temporais e sequência

"Primeiro eu disse que queria mudar de emprego, depois disse que ficaria. Qual é a minha visão atual?"

Domínio aberto

Combinar o histórico do usuário com raciocínio de senso comum externo

"Eu disse que sou alérgico a amendoim. Posso comer molho satay?"

A tabela a seguir lista os resultados da avaliação:

Solução de memória

Single-hop

Multi-hop

Temporal

Domínio aberto

Precisão geral

Memory Storage

88,94%

90,78%

88,16%

75,00%

88,25%

Mem0

68,97%

61,70%

58,26%

50,00%

64,20%

Em todas as quatro categorias de raciocínio, o Memory Storage apresenta uma taxa de precisão maior que o Mem0. A vantagem é de aproximadamente 20 pontos percentuais para o raciocínio single-hop, que recupera um único fato diretamente. As lacunas são maiores para o raciocínio multi-hop e temporal, com aproximadamente 29 e 30 pontos percentuais, respectivamente. Para perguntas que exigem que uma IA conecte múltiplas conversas e entenda a ordem dos eventos antes de fazer um julgamento, o Memory Storage fornece maior qualidade de recuperação.

Nota

Metodologia: A avaliação do Memory Storage usa todas as 10 conversas do LoCoMo e 1.540 perguntas em quatro categorias de raciocínio. O teste usa o prompt de resposta oficial mais recente do LoCoMo do Mem0. Tanto o modelo de resposta quanto o modelo juiz são qwen-max, e o teste usa o juiz tolerante fornecido pelo Mem0. Os dados de comparação do Mem0 vêm de seus resultados de avaliação pública.

Latência de recuperação

O teste usa um cenário de grande escala com um repositório de memória, 1,2 milhão de locatários e mais de 100 milhões de entradas de memória, com o Rerank desativado. Na tabela a seguir, topK é o número de principais resultados que a recuperação retorna.

topK

Latência média

Latência P50

Latência P95

5

164 ms

155 ms

269 ms

10

198 ms

174 ms

288 ms

50

234 ms

222 ms

384 ms

Na escala de 100 milhões de entradas, a latência P50 permanece estável em torno de 200 ms em todos os valores de topK. Mesmo quando o service retorna os 50 principais resultados, o P95 permanece dentro de 384 ms. Mesmo que todas as memórias de usuário em um aplicativo com um milhão de usuários ativos diários sejam armazenadas em um único repositório de memória, a recuperação de memória em cada conversa ainda é concluída em até 200 ms. Ativar o Rerank, que está ativado por padrão, aumenta a latência de recuperação em 200–300 ms.

Escala de armazenamento

Um único repositório de memória foi verificado para suportar armazenamento e recuperação para 1,2 milhão de locatários e mais de 100 milhões de entradas de memória. A arquitetura distribuída do Tablestore suporta dimensionamento horizontal sem limite superior teórico. Você não precisa de planejamento de capacidade que fragmente bancos de dados e tabelas por contagem de locatários. A camada de armazenamento faz dimensionamento automático conforme o negócio cresce.

Custo de tokens

O Plano A injeta o histórico completo de conversas em cada rodada. O Plano B executa uma extração única e injeta apenas memórias recuperadas em cada rodada. Os tokens de conversa são contados com precisão através do campo usage retornado pelo model service. Os tokens de extração são calculados reproduzindo o prompt de extração de produção, portanto, os dados são conservadores.

Na tabela a seguir, os tokens de conversa por consulta representam o número médio de tokens de conversa por pergunta. Os tokens de extração de memória são os tokens de extração única para as quatro conversas e aplicam-se apenas ao Plano B. Os tokens de conversa completa com contexto representam o consumo total extrapolado de 827 perguntas nas quatro conversas.

Dimensão de avaliação (com base em quatro conversas LoCoMo)

Plano A

Plano B

Tokens de conversa por consulta

24.985

823

Tokens de extração de memória

N/D

320.667

Tokens de conversa completa com contexto

20.662.543

1.001.153

Economia apenas de conversa

N/D

96,7%

Economia total incluindo extração

N/D

95,1%

A avaliação de tokens é baseada em quatro conversas LoCoMo e 827 perguntas. A avaliação de precisão abrange todas as 10 conversas e 1.540 perguntas.

Próximos passos

  • Para detalhes de faturamento do Memory Storage, consulte Billing.

  • Para começar a usar o Memory Storage, consulte Quick start.