Summary
Add an exact-/keyword-match search path so users can find memories by literal terms (names, IDs, URLs, rare tokens) that semantic vector search misses.
Idea from OB1
OB1 pairs vector search with a schemas/text-search-trgm trigram full-text index, so queries can match on literal text in addition to embedding similarity. Vector search alone is weak for exact identifiers and rare tokens.
Why it fits memserv
- memserv is currently vector-only (PRD §1.2 lists graph memory as a non-goal, but keyword search over the existing payload is not — it's complementary).
- Qdrant supports payload full-text indexing and
match/text filters on the stored memory content, so this can be done on the existing collection without a second datastore.
Proposed approach
- Enable a Qdrant payload text index on the memory content field.
- Add a
mode (or keyword flag) to search that runs a Qdrant payload text filter instead of / in addition to the vector query, then merges results.
- Surface on both REST and MCP search; default stays pure-vector.
Notes / scope
Keep it within Qdrant — do not introduce Postgres/pgvector or a parallel store the way OB1 does. This is an additive search mode, not a backend change.
Source: https://github.com/NateBJones-Projects/OB1/tree/main/schemas
Summary
Add an exact-/keyword-match search path so users can find memories by literal terms (names, IDs, URLs, rare tokens) that semantic vector search misses.
Idea from OB1
OB1 pairs vector search with a
schemas/text-search-trgmtrigram full-text index, so queries can match on literal text in addition to embedding similarity. Vector search alone is weak for exact identifiers and rare tokens.Why it fits memserv
match/textfilters on the stored memory content, so this can be done on the existing collection without a second datastore.Proposed approach
mode(orkeywordflag) to search that runs a Qdrant payload text filter instead of / in addition to the vector query, then merges results.Notes / scope
Keep it within Qdrant — do not introduce Postgres/pgvector or a parallel store the way OB1 does. This is an additive search mode, not a backend change.
Source: https://github.com/NateBJones-Projects/OB1/tree/main/schemas