Executando verificação de segurança...
1

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 !

Carregando publicação patrocinada...
2

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

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 !