A alegação viral: o armazenamento literal e cru vence tudo em memória de IA. Reproduzimos o benchmark e encontramos uma resposta diferente. O gargalo está no truncamento do embedding, não na perda por extração. Aqui estão os dados.
Por que rodamos este benchmark
O MemPalace (github.com/milla-jovovich/mempalace) foi lançado em 5 de abril de 2026 e chegou a 14.500 estrelas no GitHub em 48 horas. A tese central: armazene cada conversa de forma literal no ChromaDB, pule totalmente a extração por LLM, e você obtém 96,6% de recall no benchmark padrão de memória de IA (LongMemEval).
A implicação para a área: todo sistema que usa um LLM para extrair ou resumir memórias está superdimensionando o problema. Texto cru com bons embeddings vence.
Nós construímos sistemas de gestão do conhecimento baseados no modelo SECI (Nonaka & Takeuchi, 1995), onde a extração estruturada é uma operação central. Se o armazenamento cru realmente vence a extração, nossa arquitetura está errada. Então testamos.
O que testamos
Benchmark: LongMemEval_S (Wu et al., ICLR 2025). 500 perguntas testando cinco habilidades de memória de longo prazo: extração de informação, raciocínio entre sessões, atualizações de conhecimento, raciocínio temporal e abstenção. Cada pergunta inclui cerca de 48 sessões de conversa "palheiro", das quais 1 a 3 contêm a resposta.
Quatro abordagens de recuperação, mesmo modelo de embedding (all-MiniLM-L6-v2), mesmos dados:
| # | Abordagem | Descrição |
|---|---|---|
| 1 | Cru, todos os turnos | Armazena o texto completo da sessão (usuário + assistente), faz o embedding como está |
| 2 | Cru, só usuário | Método do MemPalace: armazena só os turnos do usuário, faz o embedding como está |
| 3 | Extração SECI | Condensa cada sessão em cerca de 500 caracteres de fatos estruturados |
| 4 | SECI híbrido + palavra-chave | Combina os escores cru + extraído via fusão de rank recíproco, adiciona reforço por sobreposição de palavras-chave |
Todas as abordagens usam ChromaDB com busca por similaridade de cosseno. Nenhum LLM envolvido na recuperação. A única diferença está no que é indexado.
Resultados
LongMemEval_S: recuperação em nível de sessão (500 perguntas, todos os 6 tipos)
| Abordagem | R@5 | R@10 | NDCG@5 | NDCG@10 |
|---|---|---|---|---|
| Cru, todos os turnos | 85,9% | 92,8% | 80,3% | 83,0% |
| Cru, só usuário (método MemPalace) | 92,1% | 96,3% | 86,8% | 88,5% |
| Extração SECI | 93,7% | 96,7% | 89,1% | 90,3% |
| SECI híbrido + palavra-chave | 93,9% | 96,6% | 89,7% | 90,8% |
O SECI híbrido superou o armazenamento cru no estilo MemPalace por 1,8 ponto percentual no R@5.
Detalhamento por tipo de pergunta
| Abordagem | Atual. Conhec. (n=72) | Multi-sessão (n=121) | SS-Usuário (n=64) | Temporal (n=127) |
|---|---|---|---|---|
| Cru, só usuário (MemPalace) | 98,6% | 90,6% | 92,2% | 86,9% |
| Extração SECI | 95,8% | 93,2% | 96,9% | 88,8% |
| SECI híbrido+pc | 96,5% | 93,7% | 96,9% | 88,4% |
A extração SECI lidera em 4 dos 6 tipos de pergunta. O método MemPalace vence na atualização de conhecimento (+2,1pp), onde a redação original dos fatos alterados importa. A vantagem do SECI é mais forte em perguntas de sessão única do usuário (+4,7pp), onde a resposta está enterrada bem no fundo de uma conversa longa.
Por que a extração vence: o problema do truncamento em 256 tokens
O resultado nos surpreendeu. A tese do MemPalace é intuitiva: a extração perde informação, o cru preserva tudo. Em teoria, o cru deveria vencer.
A margem é mais estreita do que sugeria nossa amostra inicial de 100 perguntas (+4,9pp reduziu para +1,8pp na escala completa de 500 perguntas). As perguntas de raciocínio temporal e de atualização de conhecimento aproximaram a diferença. É exatamente por isso que se roda o benchmark completo.
A realidade: o modelo de embedding não consegue ler o documento inteiro.
O all-MiniLM-L6-v2 (o padrão do ChromaDB, usado tanto pelo MemPalace quanto pelo nosso benchmark) tem um comprimento máximo de sequência de 256 tokens. Isso equivale a cerca de 1.000 caracteres.
As sessões do LongMemEval têm em média 10.000 caracteres. Algumas passam de 30.000.
Quando você armazena uma sessão crua e faz o embedding, o modelo lê os primeiros 1.000 caracteres e ignora o resto. 90% do conteúdo fica invisível para a recuperação.
Nossa extração SECI condensa a sessão inteira em cerca de 500 caracteres de fatos-chave estruturados. Cada fato extraído cabe dentro da janela de 256 tokens. Nada é truncado.
A tese do "cru sempre vence" só se sustenta quando seu modelo de embedding consegue de fato ler o documento inteiro. Com 256 tokens, ele não consegue.
Sessão crua (10.000 chars):
[████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
↑ embedado (1.000 chars) ↑ truncado (9.000 chars) ← invisível para a busca
Extração SECI (500 chars):
[████████████████████]
↑ conteúdo inteiro embedado ← nada perdido
Um modelo de embedding com contexto mais longo mudaria o resultado?
Provavelmente sim. Modelos como o bge-large-en-v1.5 (512 tokens) ou o nomic-embed-text-v1.5 (8192 tokens) permitiriam ao armazenamento cru fazer o embedding de mais partes de cada sessão. Os 96,6% publicados pelo MemPalace podem usar otimizações além do modelo padrão. Vamos testar embeddings de contexto mais longo em seguida.
O ponto se mantém: sua qualidade de recuperação é limitada pela sua janela de embedding, e a maioria dos desenvolvedores não verifica isso.
O que o MemPalace acertou
Reconhecimento devido:
-
Indexação só do usuário. Remover os turnos do assistente melhorou a recuperação crua de 85,9% para 92,1%, um salto de 6,2 pontos. As respostas do assistente adicionam ruído (genérico, prolixo) que dilui o embedding. Escolha de design inteligente.
-
Desempenho em atualização de conhecimento. O cru só do usuário pontua 98,6% em perguntas de atualização de conhecimento contra nossos 96,5%. Quando os fatos mudam com o tempo, ter a redação original ajuda. A extração pode suavizar o sinal de atualização.
-
Cultura de benchmarking. Publicar resultados reprodutíveis do LongMemEval com scripts, ser transparente sobre qual modo (cru vs AAAK vs rooms) produz qual escore e emitir correções honestas em até 48 horas após o lançamento. É assim que o código aberto deve funcionar.
-
A intuição central está parcialmente correta. Em escala e com o modelo de embedding certo, o armazenamento cru é uma base forte. A área vinha superdimensionando a extração com chamadas caras de LLM quando abordagens mais simples funcionam. A nuance: "mais simples" precisa levar em conta a janela de embedding.
O modelo SECI para memória de IA
Nossa abordagem de extração é baseada no modelo de gestão do conhecimento SECI (Nonaka & Takeuchi, 1995), adaptado para a memória de agentes de IA:
| Fase | Fluxo de conhecimento | Implementação |
|---|---|---|
| Socialização | Tácito → Tácito | A sessão acontece, o contexto é vivenciado |
| Externalização | Tácito → Explícito | /distill extrai fatos estruturados para markdown |
| Combinação | Explícito → Explícito | /consolidate mescla, deduplica, detecta decaimento |
| Internalização | Explícito → Tácito | /remember carrega o contexto relevante na próxima sessão |
O sistema armazena o conhecimento extraído como arquivos markdown planos em 10 namespaces (brain, patterns, solutions, research, content, voice, clients, projects, docs, quick-reference). Cada arquivo é legível por humanos e versionado.
Para este benchmark, adicionamos o ChromaDB por baixo dos arquivos markdown: indexação dupla tanto do texto cru quanto dos resumos extraídos, com fusão de rank recíproco no momento da consulta.
Metodologia
Conjunto de dados: LongMemEval_S (Wu et al., "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory," ICLR 2025). 500 perguntas, cerca de 48 sessões palheiro por pergunta, comprimento médio de sessão de 10.042 caracteres.
Modelo de embedding: all-MiniLM-L6-v2 (384 dimensões, comprimento máximo de sequência de 256 tokens). Padrão do ChromaDB.
Recuperação: granularidade em nível de sessão. Recuperação top-10. Métricas: Recall@5, Recall@10, NDCG@5, NDCG@10.
Método de extração: condensação baseada em regras (sem LLM). Extrai o tópico da primeira mensagem do usuário, o acompanhamento da última mensagem do usuário e a resolução da última mensagem do assistente. Cerca de 500 caracteres por sessão. Isso simula a estrutura de saída do nosso comando /distill.
Fusão híbrida: Fusão de Rank Recíproco (k=60) dos escores de recuperação cru e extraído, mais reforço por sobreposição de palavras-chave (até 30% para correspondências exatas de termos).
Amostra: 500 perguntas (470 avaliadas, 30 de abstenção puladas). Todos os 6 tipos de pergunta: single-session-user, single-session-assistant, single-session-preference, multi-session, temporal-reasoning, knowledge-update.
Código: seci_vs_mempalace.py
Ressalvas
- Recuperação top-10. O MemPalace faz benchmark com recuperação top-50 (n_results=50) e avalia R@5 a partir desse conjunto. Nosso top-10 é mais restrito. Comparação justa com parâmetros equiparados virá em breve.
- Extração baseada em regras. Nossa extração usa condensação por regex/heurística, não resumo por LLM. A extração baseada em LLM provavelmente melhoraria a qualidade, mas adicionaria custo e latência.
- Um único modelo de embedding. Os resultados são específicos ao all-MiniLM-L6-v2 (256 tokens). Modelos de contexto mais longo estreitariam a diferença entre as abordagens crua e extraída.
- A atualização de conhecimento é um ponto fraco. O método MemPalace pontua 98,6% contra nossos 96,5% em perguntas onde os fatos mudam com o tempo. A extração pode suavizar o sinal de atualização.
O que isso significa para quem constrói
Se você está construindo um sistema de memória de IA:
-
Verifique sua janela de embedding. Se seu modelo de embedding trunca em 256 ou 512 tokens e seus documentos são mais longos, você está perdendo informação na camada de embedding, independentemente da sua estratégia de armazenamento.
-
A extração nem sempre perde informação. Quando a extração condensa um documento longo em uma representação que cabe na janela de embedding, ela preserva mais informação recuperável do que o armazenamento cru que é truncado.
-
A indexação só do usuário ajuda. Remover os turnos do assistente da memória de conversa reduz o ruído. Uma melhora de 6,2 pontos de graça.
-
A recuperação híbrida adiciona qualidade de ranqueamento. Combinar os escores cru e extraído via RRF não melhora o recall em relação à extração sozinha, mas melhora o NDCG (qualidade de ranqueamento). Os documentos certos ranqueiam mais alto quando você combina ambos os sinais.
-
Faça benchmark do seu sistema. O LongMemEval é gratuito, bem projetado e reprodutível. Rodá-lo leva algumas horas. Os resultados podem surpreender você.
Reproduzindo estes resultados
# Instale as dependências
pip install chromadb sentence-transformers
# Baixe os dados do LongMemEval
mkdir -p data && cd data
curl -L -o longmemeval_s_cleaned.json \
https://huggingface.co/datasets/xiaowu0162/longmemeval-cleaned/resolve/main/longmemeval_s_cleaned.json
cd ..
# Rode o benchmark
python seci_vs_mempalace.py --dataset s --mode retrieval
Código completo: github.com/rankfor/ai-memory-benchmark
O que estamos testando a seguir
- Modelos de embedding de contexto mais longo (bge-large, nomic-embed-text) para ver se o armazenamento cru alcança quando o truncamento é removido.
- Extração baseada em LLM (Gemini Flash para resumir sessões) versus nossa extração baseada em regras.
- Reforço temporal para recuperação com consciência de data na categoria de perguntas de raciocínio temporal.
- Recuperação top-50 para igualar a configuração exata do MemPalace numa comparação justa.
O código é aberto. Reproduções são bem-vindas.
Dmitrij Żatuchin, Rankfor.AI. Abril de 2026.
Esta pesquisa é independente. Não temos nenhuma afiliação com MemPalace, LongMemEval ou ChromaDB. O código e os resultados do benchmark estão abertos para reprodução.