Pre-submission checklist | 提交前检查
Bug Description | 问题描述
memory_search can retrieve relevant candidates in the Initial Retrieval stage, but the final result becomes empty after the LLM Filter stage, even for queries that should obviously match existing memories.
In the logs, the pattern looks like this:
- Initial Retrieval finds 10 candidates
- But the final output shows "LLM filter: none relevant"
- As a result, the user gets no usable memory recall, even though relevant memories clearly exist in the candidate set
This makes recall quality look broken or inconsistent, especially after import/migration into MemOS.
Examples from the screenshots:
-
Query: 你搜一下试试
-
Initial Retrieval: 10 candidates
-
Final result: LLM filter: none relevant
-
Query: openclaw update
-
Initial Retrieval: 10 candidates
-
Final result: LLM filter: none relevant
-
Query: openclaw 原生记忆
-
Initial Retrieval: 10 candidates
-
Final result: LLM filter: none relevant
This suggests that the problem is not only in candidate retrieval, but also in the post-retrieval relevance filtering stage.
How to Reproduce | 如何重现
- Import or migrate native OpenClaw memories into MemOS.
- Open the MemOS Viewer and confirm that memories exist.
- Run
memory_search with queries that should clearly match imported memories, for example:
openclaw updateopenclaw 原生记忆你搜一下试试
- Open the Logs page and inspect the retrieval details.
- Observe:
- Initial Retrieval returns multiple candidates (for example 10)
- But the final result is still empty because the LLM filter marks all candidates as irrelevant
Environment | 环境信息
- OpenClaw
- MemOS local memory plugin
- Memory recall via
memory_search
- Issue observed after importing/migrating native OpenClaw memories into MemOS
- Logs inspected in MemOS Viewer
Relevant observed behavior:
- candidate retrieval is working
- LLM filtering appears over-aggressive or incorrect
- final recall result becomes empty despite plausible matches existing in the candidate pool
Additional Context | 其他信息
From the logs, this does not look like a pure retrieval failure.
Instead, it appears to be a two-stage issue:
- Initial Retrieval works
- candidates are found successfully
- the system is able to surface relevant-looking memories into the candidate list
- LLM Filter removes everything
- all candidates are judged as irrelevant
- final recall becomes empty
This creates a poor user experience because the system appears to "know" something relevant exists, but still returns nothing.
Possible causes:
- relevance filtering prompt is too strict
- summarizer/filter model is too conservative
- imported memories are summarized in a way that weakens relevance judgment
- query/candidate matching works at retrieval level but fails at LLM judgment level
Suggested improvements:
- expose a clearer final-state explanation in logs when Initial Retrieval succeeds but LLM Filter removes all results
- consider fallback behavior when the filter removes all candidates but top candidates are high-confidence
- consider making the filter less strict for imported memories
- consider showing both:
- Initial Retrieval results
- LLM-filtered results
in a more explicit/debuggable way
Attached screenshots show:
- queries with 10 initial matches
- but final result still reported as
LLM filter: none relevant
Willingness to Implement | 实现意愿
Pre-submission checklist | 提交前检查
Bug Description | 问题描述
memory_searchcan retrieve relevant candidates in the Initial Retrieval stage, but the final result becomes empty after the LLM Filter stage, even for queries that should obviously match existing memories.In the logs, the pattern looks like this:
This makes recall quality look broken or inconsistent, especially after import/migration into MemOS.
Examples from the screenshots:
Query:
你搜一下试试Initial Retrieval: 10 candidates
Final result:
LLM filter: none relevantQuery:
openclaw updateInitial Retrieval: 10 candidates
Final result:
LLM filter: none relevantQuery:
openclaw 原生记忆Initial Retrieval: 10 candidates
Final result:
LLM filter: none relevantThis suggests that the problem is not only in candidate retrieval, but also in the post-retrieval relevance filtering stage.
How to Reproduce | 如何重现
memory_searchwith queries that should clearly match imported memories, for example:openclaw updateopenclaw 原生记忆你搜一下试试Environment | 环境信息
memory_searchRelevant observed behavior:
Additional Context | 其他信息
From the logs, this does not look like a pure retrieval failure.
Instead, it appears to be a two-stage issue:
This creates a poor user experience because the system appears to "know" something relevant exists, but still returns nothing.
Possible causes:
Suggested improvements:
in a more explicit/debuggable way
Attached screenshots show:
LLM filter: none relevantWillingness to Implement | 实现意愿