Semantic Search

Semantic Search, Built Into Your Database

Keyword search matches strings. Semantic search matches meaning. Montycat builds vector search directly into a self-hosted NoSQL database, so you can query your data the way you think about it — no separate search service, no external embedding API. Built in, self-hosted, yours.

Read the docs

What is semantic search?

Semantic search represents text as vectors (embeddings) so that similar meanings sit close together in vector space. A query is embedded the same way, and the database returns its nearest neighbors. The result: searching for "cancel my subscription" surfaces "end recurring billing" even though they share no keywords.

It is the retrieval technique behind RAG, AI-agent memory, recommendations, deduplication, and semantic product search — anywhere matching by meaning beats matching by string.

Semantic search vs. keyword search

Keyword (full-text) search and semantic search solve different problems:

  • Keyword search matches exact tokens; semantic search matches meaning, so synonyms and paraphrases still hit.
  • Keyword search fails on vocabulary mismatch between the query and the content; semantic search bridges it.
  • Keyword search ranks by term frequency; semantic search ranks by vector similarity (cosine distance).
  • Semantic search understands intent — "affordable laptop for coding" finds relevant products without those exact words.

How Montycat does it

Montycat embeds your data on-device using a built-in engine and indexes it in an approximate nearest-neighbor graph (HNSW) for sub-linear search. You enable it once, DB-wide, and every keyspace is embedded in the background as data is written — the write path never blocks on embedding.

Queries return hits ranked by cosine similarity, with an optional minimum-score cutoff. Records and vectors share one engine, so there is nothing to sync and no second service to run.

Choosing an embedding model

Montycat ships a small registry of quantized, on-device models, downloaded on demand and cached locally. You pick the trade-off:

  • BGE-small (default) — strong English retrieval, small and fast.
  • MiniLM — tiny and very fast, a solid baseline.
  • BGE-base — higher quality, larger and slower.
  • Multilingual E5 — for non-English and mixed-language corpora.

Tuning your results

Two knobs shape what comes back, and two result shapes fit different needs:

  • top-k — how many nearest neighbors to return.
  • min_score — a cosine-similarity floor that drops weak matches so you only act on confident results.
  • get_values — full {__key__, __score__, __value__} hits when you need the data immediately.
  • get_keys — lightweight {__key__, __score__} hits to page or filter before fetching.

Where semantic search helps

Any product that searches text benefits from meaning-aware retrieval:

  • Site and in-app search that understands what users mean, not just what they typed.
  • Product and content recommendations by similarity.
  • Deduplication and clustering of near-identical records.
  • The retrieval step in RAG pipelines and AI-agent memory.

Search by meaning (Python)

# semantic search is on by default in the montycat-semantic edition
hits = await products.semantic_search_get_values("Show all Bluetooth devices", limit=5)
# -> [{__key__, __score__, __value__: {"name": "Wireless Headphones"}}, ...]  (matched by meaning, not keywords)

# optional: drop weak matches by cosine similarity
strong = await products.semantic_search_get_keys(
    "Show all Bluetooth devices", limit=5, min_score=0.35
)

FAQ

Is this full-text search or semantic search?

Semantic search. Montycat ranks results by meaning using vector embeddings and kNN similarity, not keyword matching.

Do I need a separate vector database?

No. The vector index lives inside Montycat alongside your records, so there is no separate service to run or sync.

Which embedding models are supported?

A small on-device registry — MiniLM, BGE (small/base), and multilingual E5 — downloaded on demand and cached locally. The default is BGE-small.

Is semantic search fast enough for real-time use?

Yes. Search runs over an approximate nearest-neighbor (HNSW) index for sub-linear latency, and embedding happens off the write path, so queries stay fast even as data grows.

Can I combine semantic search with exact filters?

Yes. Use exact-match lookups for structured filters and semantic search for meaning-based ranking, all within the same engine and keyspace.

Explore