Query Engine

Overview

The query engine decomposes a search request into per-dimension operations, routes each term to the dimension where it carries signal, executes BM25 sparse and dense legs in parallel for every routed dimension, and merges results into a single ranked list via Reciprocal Rank Fusion.

Queries are pure retrieval: every expansion tier runs at write time. Nothing here calls a model larger than the embedding encoder, and warm latency is ~5ms.

Query pipeline: SearchRequest flows into the Query Planner (rewrites, IDF/embedding routing, Prism), then the Executor runs BM25 sparse and dense legs in parallel per routed dimension, then RRF merge and the cross-dimension coherence filter with relaxation produce the SearchResponse


Query Planner

Input

FieldSource
Query stringClient request
Filters / temporal paramsClient request
Dimension schemaCollection metadata
Vocabulary + DF statsSQLite stats store

Output: Prism

A Prism is the query plan, named after the core metaphor. It specifies which dimensions the query touches, which terms route to each, and which extra channels (whole-query dense, residual boost) are active.

Query Rewrites (corpus-derived)

Before routing, zero-hit terms are repaired against the collection’s own vocabulary (no external dictionary):

  • Spell correction: banded Levenshtein against the corpus vocabulary, guarded by a ConceptNet real-word gate plus digit and first-letter checks ("leathr" → "leather", but real words are never rewritten).
  • Compound splitting: a token splits when its halves form a real corpus bigram ("redcell" → "red cell").
  • Adjacent merging: neighboring tokens merge when the compound spelling dominates the spaced bigram in the corpus ("deco art" → "DecoArt", both spellings kept in the BM25 query).

Term Routing

Each term routes to the dimension where it carries the most signal:

Query decomposition: IDF routing assigns terms lexically (leather to material, blue to color, shoes to style); embedding routing resolves remaining terms by dimension-centroid similarity; terms neither can route go to all dimensions

  • IDF routing, semantic-first: a term with a semantic home routes there over an exact home. Exact dimensions are routable via their derived enum tails (male, elderly).
  • DF guard: a term whose document frequency exceeds 2/3 of a dimension’s points produces no routing or constraint from that dimension (it carries no signal there).
  • Embedding-routing fallback: zero-IDF queries route to the dimension with the highest top-1 dense similarity, gated on that dimension’s dense top score.
  • Noise handling: terms still zero-hit after rewrites and unknown to ConceptNet are treated as noise; their fraction weights extra whole-query dense channels (zero noise → zero extra channels).

Each dimension’s BM25 and dense search then runs with only its routed terms, not the full query.


Lens Execution

Every dimension type has a fixed execution shape; there is no per-query strategy selection:

Dimension typeExecution
semanticBM25 sparse and dense 1024d legs run in parallel, fused by RRF. Both indices exist from the moment of insert.
exactEquality/containment matching over the value and its learned alias tails.

BM25 prefetch depth is IDF-weighted; dense prefetch is query-coverage-weighted. Dense legs are scoped to routed dimensions only.


Scoring: Reciprocal Rank Fusion (RRF)

Different lenses produce incomparable scores: BM25 returns unbounded term-frequency scores, dense search returns cosine similarity (0–1), exact returns binary match. RRF normalizes by using rank position instead of raw scores.

Formula

RRF_score(doc) = Σ  1 / (k + rank_in_source_i)

Where:

  • k = 60 (standard constant, dampens the contribution of low-ranked results)
  • The sum is over all sources (lenses) that returned the document

Example

Source A (BM25):   doc_X rank 1,  doc_Y rank 2,  doc_Z rank 3
Source B (dense):  doc_Z rank 1,  doc_X rank 2,  doc_W rank 3

doc_X: 1/(60+1) + 1/(60+2) = 0.01639 + 0.01613 = 0.03252
doc_Z: 1/(60+3) + 1/(60+1) = 0.01587 + 0.01639 = 0.03227
doc_Y: 1/(60+2) + 0         = 0.01613
doc_W: 0         + 1/(60+3) = 0.01587

Final ranking: X > Z > Y > W

Documents appearing in multiple sources rank higher. Position matters more than raw score. No normalization or tuning required.


Cross-Dimension Coherence

After RRF merge, a post-filter enforces coherence across the dimensions the query actually touched:

  • A candidate passes a dimension if it matched via BM25 or sits in that dimension’s dense top-15%.
  • Two routed dimensions → strict AND.
  • Three or more → N−1 (one weak dimension is forgiven, but emphatic dimensions can never be the dropped one).
  • Terms with multiple dimension homes get forgiveness across their homes.

Query execution: BM25 sparse (IDF-weighted prefetch) and dense (query-coverage-weighted prefetch) legs run in the unified qdrant-edge engine, merge via RRF, then pass the cross-dimension coherence filter (AND for 2 dims, N-1 for 3+, emphatic dims cannot be dropped) and relaxation with opt-in backfill

Relaxation: strict AND yielding 0 results falls back to N−1. Opt-in backfill: true pads the tail with gate rejects ordered by evidence; zero survivors stays zero, so the precision contract stays intact.

Mixed-query semantic-residual boost: when a routed core is joined by a dropped real-word phrase (≥2 ConceptNet-known zero-hit terms), survivors are reordered by rrf × (1 + 4·sim_norm), where the residual phrase is embedded alone and compared against each survivor’s stored per-dimension vectors. Negation markers disable the boost.


Search Diagnostics

The search response carries lightweight diagnostics alongside results:

FieldMeaning
matched_dimensionsWhich dimensions contributed to each hit
routed_countHow many query terms found a dimension home
residual_termsTerms handled by the residual/noise channels instead of routing
elapsed_msEnd-to-end latency

Roadmap

Learned routing: replacing the IDF heuristic with a trained per-field weighting model. A single-feature variant measured net-zero end-to-end and ships disabled (routing.learned_enabled: false); a multi-feature variant is under evaluation. Aggregations (GROUP BY over exact dimensions, semantic clustering over embedding space) are design-stage, not in the current API.