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 🙌