Reasoning about facts and relationships

[armstrong-pv]

Hi, I'm just beginning to look into AI memory systems. Do you incorporate something like this - reasoning about facts and relationships? https://blog.dailydoseofds.com/p/openclaws-memory-is-broken-heres

[zc277584121]

Thanks for bringing this up! That blog post raises some interesting points about memory systems in general.

However, after a closer look, most of the criticisms mentioned in the article don't actually apply to memsearch — we've already addressed them:

Concern in the article	memsearch status
Cross-project contamination	Each project gets its own isolated Milvus collection (ms_<name>_<hash>), derived from the project path. No data leaks between projects.
Missing provenance / no traceability	We have a three-level progressive disclosure system: search → expand (full markdown section) → transcript (original conversation). Every memory chunk links back to its source file, line range, and even the original session/turn via anchor comments.
Isolation failures	Collection-level isolation is the default. Different Milvus URIs or collection names provide full physical separation.
Context compaction losing details	This is a token management concern of the host agent (e.g., Claude Code), not the memory system itself. memsearch's compact command does LLM-powered summarization, but the original markdown files are always preserved as source of truth.
No structural relationships	This is the one valid point — memsearch uses hybrid search (dense + BM25 + RRF reranking) rather than a knowledge graph. See below.

Regarding the Knowledge Graph approach specifically: it's a fascinating direction, but we think it's not the right fit for memsearch at this stage:

• memsearch is designed to be lightweight and markdown-first. The core value proposition is "zero-config semantic memory from your existing markdown files." Adding KG would require entity extraction (extra LLM calls), relation modeling, and a graph database — significantly increasing complexity, latency, and dependencies.
• The primary use case is session memory (daily logs, conversation summaries, project notes), which is inherently narrative/temporal rather than entity-relationship structured. KG shines for structured knowledge bases ("Alice manages the auth team"), but that's not the typical content shape here.
• Hybrid search already handles the examples well. The "Alice manages auth" → "who handles auth permissions?" scenario from the article actually works fine with good embedding models + BM25 keyword matching through RRF fusion.

That said, we appreciate the suggestion and will keep it in mind as the project evolves. If there's strong community interest or a concrete use case where hybrid search falls short, we'd be happy to revisit.

[KagaJiankui]

I'm beginning to work on RAG, Knowledge Engineering (especially KG) and the pipelines I'm been messing around almost always include a model based reranking.

Curious about this: Is there any benefit for introducing a reranking model as the replacement of the current RRF fusion, or the improvement is marginal?

[zc277584121]

Great question! Here's a quick comparison:

RRF (current): A simple rank-fusion formula that merges dense and BM25 results by reciprocal rank. It's lightweight, fast, and dependency-free — no extra model calls needed.

Model-based reranking (e.g., Cohere Rerank, BGE Reranker, cross-encoders): These use a dedicated model to score query-document relevance more precisely. In theory they produce better results, especially for nuanced or ambiguous queries, since they can attend to fine-grained semantic interactions between query and document.

The trade-off is that model reranking adds latency (an extra inference call per search), an additional dependency, and potentially cost (for API-based rerankers). For memsearch's typical use case — session memory recall where chunks are relatively short and queries are straightforward — RRF already works well in practice.

That said, we're open to introducing model-based reranking as an optional feature in the future. It could be a nice enhancement for users who need higher precision and are willing to accept the extra overhead. Thanks for raising this!