Executando verificação de segurança...
16
MatheusDevMP
2 min de leitura ·

Apresento: DREAM: Uma nova arquitetura para memória em sistemas de IA

Recentemente publiquei um paper propondo uma arquitetura de memória para IAs que resolve um problema real: LLMs não têm memória de longo prazo que seja útil, barata e escalável.
A arquitetura chama DREAM — Dynamic Retention Episodic Architecture for Memory e tem DOI oficial.

O que é o DREAM?
É um design pattern para construir memória em sistemas de IA combinando:

  • memória episódica (capítulos de interação)
  • memória semântica (resumos + banco vetorial)
  • retenção dinâmica (TTL aumenta quando o usuário revisita o tema)
  • orquestrador para decidir o que buscar, guardar ou descartar

A ideia é simples:
lembrar só o que importa, quando importa.
Por que isso importa?

  • LLMs hoje sofrem com:
  • contexto limitado
  • histórico caro
  • memória que não escala
  • dificuldade em manter personalização
    O DREAM resolve isso usando tecnologias já existentes, sem depender de AGI.

Por que decidi publicar aqui
Sou um pesquisador independente, estudo programação há 4 anos e arquitetura de software há 1.
Agora decidi entrar de cabeça no mundo das IAs. Mesmo não vindo da academia tradicional.
Compartilho aqui porque acredito que a comunidade brasileira de tecnologia tem muito potencial e gostaria de propor discussões mais profundas sobre arquitetura de IA.
Então quero trazer a ideia, ouvir críticas, receber sugestões e aprender com quem já vive esse ecossistema.

O PDF contém diagrama, fluxo completo, trade-offs de banco de dados e implementação:
🔗 https://doi.org/10.5281/zenodo.17619917
Deixo aqui também o link para o repositório do GitHub onde criei uma versão de demonstração do que foi pensado para a arquitetura: https://github.com/MatheusPereiraSilva/dream-architecture

Se você trabalha com IA, RAG, agentes ou arquiteturas, quero muito ouvir seu feedback.

Carregando publicação patrocinada...
3
macnator

Matheus, parabéns pela iniciativa e pelo paper 👏

Achei muito legal você tratar memória como um design pattern em vez de só “botar um vector DB” e chamar de dia. A separação entre memória episódica, memória semântica + retenção dinâmica faz bastante sentido, principalmente com a ideia de “lembrar só o que importa, quando importa” – isso ataca bem o problema de contexto limitado e histórico caro dos LLMs.

Tenho trabalhado em uma solução de memória de longo prazo em produção, e queria compartilhar algumas percepções conceituais que convergem e divergirem um pouco do DREAM:

Memória como serviço externo, não acoplada a um modelo
Em vez de desenhar a memória como parte interna de um único sistema/LLM, eu tratei a memória como um componente externo e agnóstico de modelo.
Na prática, qualquer LLM capaz de chamar ferramentas consegue “plugar” nessa memória e reutilizar o mesmo repositório de conhecimento.
Essa solução nasceu justamente para servir como um “servidor de memória” para empresas que querem ter o seu próprio cérebro de longo prazo: uma camada de memória persistente, sob controle da empresa, independente de provedor de IA e reutilizável por vários agentes diferentes.

Resumos hierárquicos + modelo local como orquestrador de relevância
Assim como você, eu também uso resumos para não deixar o histórico explodir.
A diferença é que eu uso um modelo local próprio que decide:

o que deve ser promovido para níveis mais altos de resumo;

o que pode ficar apenas registrado em forma comprimida;

o que vale a pena recuperar em cada nova pergunta.
Em vez de uma política de TTL muito manual, esse modelo funciona como um “sistema executivo de memória”: ele observa o uso real e toma decisões de compressão/seleção com base no contexto, resumindo eu tenho um modelo local especializado que sumariza automaticamente e busca em base de dados vetorial o sumário relevante de memorias entrelaçadas de acordo com o que esta sendo pedido.

Foco em memória gigantesca e específica de domínio
Outro ponto onde eu segui um caminho diferente foi na forma de escalar:
ao invés de limitar fortemente o que é guardado, eu privilegio uma abordagem onde a memória pode ser muito grande e bem específica de um domínio (empresa, produto, área, etc.), explorando armazenamento em disco e compressão semântica.
A camada “inteligente” fica em como organizar, resumir e recuperar, não tanto em descartar agressivamente.

DREAM como padrão, não como concorrente
No fim das contas, eu não vejo a sua proposta e a minha como opostas, mas como camadas diferentes:

o DREAM descreve como um sistema deveria pensar memória (episódica, semântica, retenção dinâmica);

soluções como a que estou usando resolvem onde essas memórias vivem e como modelos diferentes podem consumi-las com baixo custo (Isso pode rodar com 3MB de memoria ram e processador de 4 núcleos, lento mas utilizável, e hd para guardar. Se colocar mais infra melhor ainda).
Dá tranquilamente pra imaginar um “DREAM rodando em cima” de uma infraestrutura de memória compartilhada, por exemplo.

Curti bastante ver esse tipo de discussão em português e com DOI público. Se você for evoluir o trabalho, acho que seria bem interessante explorar mais cenários em que o próprio modelo participa das decisões de promoção/compactação da memória (não só como consumidor, mas como curador).

Valeu por compartilhar, e tomara que venham mais textos nessa linha 🙌

2
MatheusDevMP
  • Autor
    Autor

Cara, obrigado demais por esse comentário, de verdade. Seu ponto de enxergar a memória como um serviço externo, desacoplado de modelo, é exatamente o tipo de insight que ajuda a enriquecer o trabalho. E faz total sentido: quando várias aplicações ou vários LLMs conseguem acessar a mesma “camada de memória persistente”, a arquitetura ganha longevidade, independência e reutilização. É uma direção muito madura.

A tua abordagem com modelo local como orquestrador de relevância também me chamou muito a atenção. No DREAM eu parti para uma política de retenção mais explícita (TTL adaptativo), mas a tua camada executiva de promoção/compactação automática é uma extensão natural. Inclusive, acho que esse tipo de decisão orientada pelo próprio modelo pode facilmente ser plugado como uma evolução do ARM, e você me deu uma baita ideia de “ARM orientado por agente”.

Sobre a diferença de escala, você tocou num ponto chave: meu foco inicial foi reduzir ruído e controlar a retenção para evitar poluição semântica, enquanto sua solução explora o oposto, memórias gigantescas e domínio-específico, onde o problema não é guardar demais, mas sim curar e orquestrar. As duas linhas se complementam muito bem.

E aqui entra a parte que mais gostei do que você disse: não é uma arquitetura contra a outra. É camada sobre camada.
Dá perfeitamente para imaginar o DREAM operando por cima da infraestrutura que você descreveu:

  • o seu sistema como provedor de memória persistente, independente de modelo
  • o DREAM como padrão de como essa memória deve ser organizada (episódica, semântica, adaptativa)
  • e o ARM (ou um futuro ARM curado por modelo) como “motor” de retenção

Essa combinação fecha um ciclo muito poderoso: armazenamento massivo + organização inteligente + consumo multi-LLM.

Vou incorporar essas sugestões na evolução do trabalho sim, especialmente a parte de um modelo local participando ativamente das decisões de promoção, compressão e curadoria. Isso adiciona exatamente o que faltava para fechar o loop entre memória e raciocínio.

Valeu demais pelo feedback e pela troca. É esse tipo de conversa que faz a área avançar. 🙌

2
2
faelpinho

Opa Matheus, tudo bem?

Passei pelo seu artigo anteontem, e ontem vi no Instagram um vídeo falando do Dhravya Shah, um jovem que criou o "supermemory" para IAs.

Acho que vale a pena dar uma olhada e ver se suas ideias podem se complementar.

3
MatheusDevMP
  • Autor
    Autor

Opa, tudo certo!

Valeu demais pelo comentário e por lembrar do Supermemory também.

Inclusive, depois que conheci a solução do Dhravya, fiz uma análise e propus uma forma de integrar o Supermemory dentro da minha arquitetura como uma camada opcional.

A integração já está disponível no GitHub do projeto, caso queira dar uma olhada:
https://github.com/MatheusPereiraSilva/dream-architecture

Qualquer feedback é super bem-vindo!

1
Oletros

Meus 2 cents,

Obrigado por compartilhar !

Achei o paper interessante - alguns comentarios:

  • Como o proprio paper avisa, um dos grandes limitadores eh a qualidade do sumario: se esta qualidade for boa, a memoria retorna dados mais condizentes - caso contrario fica contaminada.

  • O TTL precisaria ser ajustado pela data do ultima acesso ao assunto geral, e nao somente pela data do acesso ao EU em si. Veja, digamos que pesquisei sobre "meningite" e isso gerou varios EUs e foram para a memoria. Mas fiquei sem acessar o assunto por um tempo superior ao TTL - neste caso, o EU seria retornado e desprezado, mesmo que tenha relevancia, simplesmente porque o TTL expirou.

  • No paper cita o Cassandra - ate entendi o porque (p.ex. pela facilidade de particionar) mas tenho duvidas se vale a pena entrar neste merito sem discutir outros aspectos das tecnologias a serem utilizadas.

  • A busca eh feita apenas pelos embending (semantica) - talvez seja interessante aqui implementar/possibilitar outros tipos de pesquisa (graphRAG/agenticRAG) e/ou reranking para determinar o resultado/EU mais adequado.

Recentemente teve um post sobre o assunto:

https://useskald.com/
O que descobrimos ao tentar fazer nossos agentes de IA entenderem a própria empresa

Excelente iniciativa, parabens pelo trabalho.

Por favor, continue postando sobre o assunto - diversas pessoas (inclusive eu) temos muito interesse neste tipo de artigo.

Saude e Sucesso !

2
MatheusDevMP
  • Autor
    Autor

Muito obrigado pelo comentário, esse tipo de análise é exatamente o motivo pelo qual resolvi compartilhar o paper publicamente. Fico feliz de ver que você realmente leu o material com profundidade e levantou pontos extremamente relevantes.

Sobre as observações:

• Qualidade do sumário
Perfeito, esse é, de fato, um dos fatores mais sensíveis em qualquer arquitetura de memória baseada em compressão. O DREAM tenta mitigar isso ao tratar cada Episodic Unit como um artefato explícito, com opt-in e possíveis metadados (topic, importance score). Mas concordo totalmente: modelos de sumarização mais robustos e pipelines de validação podem elevar bastante a qualidade final.
Isso é algo que pretendo expandir na próxima revisão.

• TTL baseado apenas no EU, e não no assunto geral
Excelente ponto, e faz total sentido.
O ARM 1.0 calcula retenção com base nas revisitas do EU individual, mas realmente existe espaço para um mecanismo complementar no nível do tópico, onde vários EUs relacionados compartilham um contador de relevância mais global.
Gostei muito da sua observação e pretendo registrar isso como proposta para o ARM 2.0.

• Citação ao Cassandra
Você tem razão ao notar o risco de entrar em detalhes de tecnologia sem abrir a discussão para alternativas. O Cassandra foi citado apenas como exemplo de uma tecnologia distribuída compatível com o sharding natural do padrão, mas concordo que vale deixar mais claro que o DREAM é totalmente agnóstico a storage e pode ser implementado sobre diversas arquiteturas (Cassandra, Scylla, DynamoDB, pgvector, Qdrant etc.).
Vou ajustar isso na próxima versão do documento.

• Busca exclusivamente semântica (embeddings)
Ótima observação também.
O DREAM define o lifecycle da memória — mas não restringe o método de busca. A implementação base usa embeddings apenas como baseline, mas o padrão é totalmente compatível com:
GraphRAG (eu estou estudando uma variação disso para ligar EUs por tema)
Agentic RAG
reranking neural (cross-encoder)
multi-vector search
híbrido BM25 + embeddings
A sua sugestão faz bastante sentido e é uma área que quero aprofundar melhor num capítulo dedicado.

Mais uma vez, obrigado por dedicar tempo para analisar o paper e levantar pontos tão sólidos. Esse tipo de feedback é extremamente valioso nesta fase inicial, e me ajuda muito a evoluir o padrão tecnicamente.

Se você tiver interesse, estou revisando alguns pontos para a versão 1.1 e ficaria feliz em ouvir ainda mais insights.

Aproveito de deixo aqui também o link para o repositório do GitHub onde criei uma versão de demonstração do que foi pensado para a arquitetura: https://github.com/MatheusPereiraSilva/dream-architecture

Saúde e sucesso para você também! 🙏🚀

1
Oletros

Meus 2 cents extendidos,

Fico contente se meus comentarios agregaram algo - no final o objetivo do 'build in public' eh esse: permitir que a comunidade trabalhe de forma colaborativa no projeto.

Continue postando - sempre eh gratificante acompanhar este tipo de atividade.

Saude e Sucesso !