[RAG (geração aumentada de recuperação)](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) aumenta um LLM recuperando passagens relevantes de um corpus externo, geralmente por meio de incorporações e pesquisa por similaridade, e então alimentando-as como contexto para que o modelo possa responder a partir de dados atualizados ou específicos do domínio.

Funciona bem para pesquisa de documentos. Para a memória do agente, ela desmorona.

Um novo artigo, "Beyond RAG for Agent Memory: Retrieval by Decoupling and Aggregation" (Hu et al., fevereiro de 2026; [ver artigo](https://arxiv.org/abs/2602.02007)), do King's College London e do Alan Turing Institute, explica o porquê e aponta para uma abordagem melhor.

## Por que o RAG é insuficiente para a memória do agente

O RAG padrão assume um corpus grande e misto: incorporar texto, recuperar [top-k](https://en.wikipedia.org/wiki/Nearest_neighbor_search) por similaridade, concatenar como contexto.

A memória do agente é o oposto: um fluxo limitado e coerente onde o mesmo fato aparece em muitas frases. Aplicar RAG aqui cria três problemas:

1. **Top-k redundante.** Você pergunta "Quando foi a última vez que fui ao dentista?" Em um corpus de documento, top-k pode retornar alguns parágrafos relevantes de diferentes fontes. Na memória do agente, muitos trechos dizem quase a mesma coisa (“Dentista agendado para 15 de março”, “Consulta ao dentista para 15 de março”, “Dentista agendado para 15 de março”). Top-k é preenchido com repetição. O artigo chama isso de “colapso em uma única região densa”. A similaridade não consegue separar o que é *necessário* do que é meramente *semelhante*.
2. **A remoção quebra as cadeias de evidências.** Você pergunta "Resolvemos a disputa da fatura?" A resposta depende de uma cadeia: “A fatura nº 123 foi contestada”, depois “Concordamos com um reembolso parcial” e depois “Pagamos o valor acordado”. A poda post-hoc pode manter a "fatura paga #123" e eliminar os turnos anteriores. A modelo então responde “Sim, resolvido” sem saber que houve uma disputa. A poda fragmenta evidências vinculadas temporalmente e produz respostas erradas.
3. **A semelhança ignora a estrutura.** Você pergunta "Qual é o status da viagem a Barcelona?" Você precisa do projeto, da tarefa (por exemplo, reservar voos) e do resultado. Similaridade retorna pedaços que mencionam "Barcelona" ou "viagem": talvez uma menção aleatória, uma viagem passada, uma tarefa de um projeto diferente. Você precisava de um caminho estrutural (este projeto, estas tarefas, estes resultados). A similaridade não codifica isso. A estrutura sim.

## Estrutura acima da similaridade

Uma abordagem melhor é usar a estrutura para conduzir o que é carregado, não a similaridade. Digite entidades (tarefas, contatos, transações, eventos) e recupere por esquema, IDs de entidade, relacionamentos e cronogramas. Mantenha as observações e os resultados derivados como unidades inteiras; não limpe dentro dos blocos de evidências. A mesma entrada e o mesmo esquema produzem a mesma saída. Nenhum LLM no caminho crítico.

## O que o jornal mostra

O sistema do artigo (xMemory) constrói uma hierarquia de quatro níveis (mensagens para episódios, semântica para temas) com incorporações e resumos LLM. Ele supera cinco outros sistemas (Naive RAG[^1], A-Mem[^2], MemoryOS[^3], LightMem[^4], Nemori[^5]) em LoCoMo e PerLTQA, os conjuntos de dados de referência para memória de conversação longa e resposta a perguntas pessoais de longo prazo. O artigo não requer incorporações ou LLMs; requer estrutura. Você pode chegar lá com uma hierarquia aprendida (xMemory) ou com um design determinístico que prioriza o esquema. O artigo também documenta fragilidade na estrutura gerada pelo LLM (A-Mem, MemoryOS): desvios de formatação, falhas nas atualizações. A estrutura determinística que prioriza o esquema é uma base mais confiável.

## xMemory vs Neotoma

Neotoma é a [camada de memória estruturada](/posts/truth-layer-agent-memory) que estou construindo: esquema primeiro, determinístico, construído para proveniência e reprodução. Ambos os sistemas vão além do RAG; eles diferem na forma como constroem a estrutura.

**xMemory** cria uma hierarquia de quatro níveis (mensagens para episódios, semântica para temas) com incorporações e resumos LLM. Os episódios são blocos contíguos; a semântica são fatos reutilizáveis; semântica de grupo de temas para acesso de alto nível. Um objetivo de semântica de dispersão equilibra o tamanho do tema. Muito grande causa recuperação redundante; evidências de fragmentos muito pequenos. A recuperação é feita de cima para baixo: selecione um conjunto compacto de temas e semântica e depois expanda para episódios intactos (e opcionalmente mensagens) somente quando isso reduzir a incerteza do modelo do leitor. Nenhuma poda dentro das unidades. Nesses benchmarks, ele supera as cinco linhas de base em qualidade e uso de tokens. O artigo observa que a estrutura gerada pelo LLM (por exemplo, em A-Mem, MemoryOS) é frágil: desvios de formatação, falhas nas atualizações. Como o xMemory constrói sua hierarquia com resumos LLM, ele adota a mesma fragilidade.

**Neotoma** constrói estrutura sem LLMs no caminho crítico. As entidades são digitadas; relacionamentos e prazos são explícitos; a recuperação usa esquema, IDs de entidade, relacionamentos e intervalos de tempo. A mesma entrada e esquema produzem a mesma saída. Os esquemas ainda evoluem. Campos desconhecidos pousam em camada de preservação. Um pipeline determinístico pode promover campos de alta confiança ao esquema. Um LLM pode sugerir novos campos ou tipos como recomendações pendentes, aplicadas somente por meio de ferramentas ou aprovação humana. A inferência permanece consultiva: as mudanças no esquema passam por ferramentas ou aprovação humana; extração e redução permanecem determinísticas; o esquema permanece fonte da verdade. A crítica do artigo se aplica quando o modelo *orienta* a estrutura, e não quando sugere a aplicação de humanos ou ferramentas. A ingestão para recuperação permanece determinística.

### Comparação

| | xMemória | Neotoma |
|--|--------|----|
| Fonte da estrutura | Embeddings + resumos LLM (episódios, semântica, temas) | Esquema primeiro, extração e redutores determinísticos |
| Hierarquia | Quatro níveis (mensagens, episódios, semântica, temas), orientados pelo objetivo semântico-dispersivo | Entidades digitadas, relacionamentos, cronogramas (sem "níveis" fixos) |
| Recuperação | De cima para baixo: seleção representativa no gráfico e, em seguida, expansão dependente da incerteza para episódios/mensagens intactos | Por esquema, IDs de entidade, relacionamentos, cronogramas |
| Controle de redundância | Seleção representativa + expansão somente quando a incerteza diminui | As consultas estruturais retornam o que você pede; sem colapso de semelhança |
| Unidades intactas | Sim (sem remoção dentro de episódios/mensagens) | Sim (observações e entidades mantidas inteiras) |
| Determinismo | Não (a estrutura gerada pelo LLM varia) | Sim (mesma entrada, mesmo esquema, mesma saída) |
| Fragilidade | Artigo cita desvios de formatação do LLM e falhas nas atualizações em sistemas semelhantes | Esquema e código são explícitos; nenhum LLM no caminho crítico |

### Vantagens relativas

**xMemory** é excelente quando a entrada é um fluxo de conversa e você deseja estrutura sem definir esquemas. Exemplo: chat de longa duração com um assistente onde você pergunta “o que decidimos sobre a viagem?” ou "quando mencionei o orçamento pela última vez?" xMemory constrói episódios, semântica e temas; a recuperação é eficiente em termos de token. Ele também se adapta a protótipos rápidos (tíquetes de suporte, notas de reuniões) onde você ainda não deseja criar esquemas. Você aceita desvios de hierarquia e não precisa de auditabilidade ou consulta de primeira classe por entidade.

**Neotoma** é excelente quando você precisa de rastreabilidade ou seus dados já estão estruturados. Exemplo: decisões auditáveis ​​(pagamentos, acordos, resultados de tarefas) onde as mesmas entradas e esquema devem produzir o mesmo instantâneo. As alterações de esquema são versionadas e aplicadas de forma determinística; nenhum LLM no caminho. Também é adequado para entidades digitadas (tarefas, contatos, transações, eventos) com relacionamentos e cronogramas. Consulta por tipo de entidade, ID, relacionamento ou intervalo de tempo. Neotoma os trata como nativos; xMemory exigiria serialização para texto e perderia acesso de primeira classe.

## Estruturação iterativa na conversa

A estrutura muitas vezes surge no diálogo: “adicione uma tarefa para isso”, “registre que concordamos em pagar 500”, e o agente age. Os dois sistemas lidam com isso de maneira diferente.

**xMemory:** A conversa é o objeto principal. O que o agente faz (por exemplo, “Criei uma tarefa para o dentista”) permanece no fluxo de mensagens e flui em episódios, semântica e temas. Você obtém uma hierarquia melhor aprendida, mas nenhum gráfico de entidade separado e consultável. A estrutura vive dentro da hierarquia.

**Neotoma:** A conversa é uma fonte de observações. Quando o agente cria ou atualiza uma tarefa, contato ou transação, essas operações produzem observações e instantâneos de entidade. Novos campos do diálogo podem chegar a uma camada de preservação e ser promovidos ao esquema quando a confiança for alta. O diálogo e o gráfico estruturado permanecem sincronizados porque ambos escrevem no mesmo armazenamento.

**Recuperação diferente.** O xMemory oferece suporte à recuperação semântica na hierarquia. Perguntas de linguagem natural (“o que decidimos sobre o dentista?”) retornam temas, semântica ou episódios intactos. Não oferece suporte à recuperação estrutural (sem tipos de entidade com IDs e relacionamentos). Isso leva a falhas esperadas em três tipos de casos:

- **Evidências espalhadas pelos turnos.** "Resolvemos a disputa da fatura?" A disputa, a negociação e o pagamento podem viver em episódios ou temas diferentes; a recuperação pode trazer à tona um ou dois e perder o resto, então o modelo responde incorretamente ou de forma incompleta.
- **Definir consultas.** "Quais tarefas vencem antes de sexta-feira?" ou "Mostrar todos os pagamentos para entrar em contato com X." Não há entidades de tarefas ou transações para filtrar; você obtém correspondências semânticas (mensagens que mencionam "tarefa" e "sexta-feira" ou "contato X"), não uma lista definitiva, portanto os resultados são parciais ou barulhentos.
- **Travessia de relacionamento.** "Quais tarefas no projeto Y ainda estão pendentes?" Sem um gráfico de tarefas do projeto, a recuperação retorna trechos de conversas que podem omitir algumas tarefas ou projetos; você não pode enumerar com segurança por relacionamento.

Neotoma suporta ambos. Você pode fazer perguntas de estilo semântico quando os dados estiverem no armazenamento. Você também obtém recuperação estrutural por tipo de entidade, ID, relacionamento e janela de tempo, portanto, definir consultas e travessia de relacionamento retorna resultados completos e de primeira classe. A desvantagem é que você precisa de esquemas e de um armazenamento que aceite essas observações.

## Estrutura acima da similaridade, esquema acima da fragilidade

Para a memória do agente, a similaridade com o texto bruto falha. A recuperação deve ser orientada pela estrutura: como você decompõe e organiza o fluxo, e não quantos pedaços correspondem a uma consulta. O artigo mostra que uma hierarquia aprendida (xMemory) supera o RAG ingênuo e que a estrutura gerada pelo LLM é frágil.

No entanto, um caminho determinístico que prioriza o esquema oferece a mesma vantagem estrutural sem essa fragilidade. Estou construindo [Neotoma](https://github.com/markmhendrickson/neotoma) no último para que a ingestão e a recuperação permaneçam reproduzíveis e o esquema continue sendo a fonte da verdade.

[^1]: **Naive RAG:** incorporar memórias, recuperar top-k fixo por similaridade, sem hierarquia. Nenhum projeto separado; linha de base definida no [artigo](https://arxiv.org/abs/2602.02007).
[^2]: **A-Mem:** memória agente para agentes LLM; Links no estilo Zettelkasten e atualizações orientadas por agente para uma rede de memória. [Projeto](https://github.com/agiresearch/A-mem).
[^3]: **MemoryOS:** armazenamento hierárquico de curto/médio/longo prazo com módulos de atualização, recuperação e geração para agentes personalizados. [Projeto](https://github.com/BAI-LAB/MemoryOS).
[^4]: **LightMem:** memória leve inspirada nos estágios de Atkinson-Shiffrin; consolidação com reconhecimento de tópico e atualizações off-line de longo prazo. [Projeto](https://github.com/zjunlp/LightMem).
[^5]: **Nemori:** memória episódica auto-organizada com segmentação de eventos e calibração de previsão para conhecimento adaptativo. [Projeto](https://github.com/nemori-ai/nemori).