MemPalace atinge 96,6% no LongMemEval. Rodamos o mesmo benchmark. A extração estruturada pontuou mais alto.

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:

1. 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.

2. 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.

3. 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.

4. 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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

1. Modelos de embedding de contexto mais longo (bge-large, nomic-embed-text) para ver se o armazenamento cru alcança quando o truncamento é removido.
2. Extração baseada em LLM (Gemini Flash para resumir sessões) versus nossa extração baseada em regras.
3. Reforço temporal para recuperação com consciência de data na categoria de perguntas de raciocínio temporal.
4. 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.