Skip to main content

​
Overview

Vector search alone misses exact identifiers like pg_hba.conf, because embeddings blur precise strings into approximate meaning. Keyword search alone misses the meaning. memloom runs three arms inside the database in a single SQL function and fuses the rankings. One query, one round trip, no reranker service. Saved memories and ingested chunks rank in the same pool, so “search my memories” and “search my files” are one operation.

​
The three arms

Both the entity and keyword arms abstain. The entity arm only fires above 0.60 query-to-entity cosine, so a vague query anchors to nothing rather than dragging in noise. No lexical match means no keyword votes.
The entity arm anchors on at most 10 entities per query, which is why duplicate spellings cost real recall quality: each one spends a slot. It also anchors on spellings that entity resolution folded away, counting a folded spelling and its canonical once between them.

​
Fusion

Arms are combined by rank, not score, because cosine distances and full-text ranks are not comparable.
A result two arms agree on beats one that tops a single arm. Every result carries both numbers: rrfScore is the order results arrive in, and similarity is the raw cosine on its own.

​
Getting good results

Use exact identifiers

memloom recall "pg_hba.conf" is precise in a way pure-vector systems cannot be.

Index your store

The entity arm only sees what memloom index processed. The other two work regardless.

Breadcrumbs are embedded

A chunk stores Guide > Setup > Postgres ahead of its text, so both arms see the heading.

Stale never surfaces

Every arm filters to active rows, so a superseded version cannot shadow the current one.
Offline, the vector arm runs on deterministic hash embeddings, so texts sharing words look similar. That is a real but weak signal. Keyword works at full quality; the entity arm needs indexing, which needs a model. For production recall, configure a key.