Pre-Filtering

The defining characteristic of pre-filtering is the strict sequential execution. The system first applies boolean metadata constraints (e.g., year=2023, category=electronics) to reduce the candidate set, then performs the computationally expensive vector similarity search only on the surviving documents.

• Workflow: Index → Apply Filters → Reduce Scope → ANN Search
• Contrast: Opposite of post-filtering, where the ANN search runs first on the full index
• Benefit: Guarantees that every document scored by the vector engine satisfies the hard constraints

Pre-filtering ensures that if the filtered subset contains at least K documents, the final result set will always return exactly K results. This predictability is critical for pagination and user experience consistency.

• Guarantee: COUNT(filtered_set) >= K → COUNT(results) = K
• No post-hoc trimming: Unlike post-filtering, you never face the 'fewer than K' problem
• Critical for faceted search: Users navigating category filters expect full page counts

Efficient pre-filtering requires specialized index architectures that can combine metadata constraints with vector search without scanning the entire vector space. Naive implementations that filter row-by-row destroy ANN performance.

• Filterable vector indexes: HNSW with label-based partitioning or IVF with predicate pushdown
• Bitmap pre-filtering: Construct a bitset of valid document IDs, then restrict ANN traversal to only those IDs
• Trade-off: Requires more sophisticated index engineering than simple post-filtering approaches

Pre-filtering performs best when filter predicates have low to moderate cardinality. Highly selective filters (e.g., a single user ID) create tiny candidate pools where ANN search overhead may exceed brute-force distance computation.

• Optimal range: Filters that reduce the corpus by 50-99%
• Anti-pattern: Pre-filtering on a unique document ID before ANN search
• Adaptive strategy: Switch to brute-force scoring when filtered_count < threshold (e.g., < 1000 documents)
• Example: Filtering by country=US (high reduction) is ideal; filtering by user_id=xyz (near-unique) is wasteful

The total query latency in pre-filtering is the sum of the filter application time plus the ANN search time on the reduced set. The filter step must be extremely fast to avoid negating the ANN speed advantage.

• Latency formula: T_total = T_filter + T_ANN(filtered_set)
• Filter acceleration: Inverted indexes, bitmap indexes, or columnar stores for sub-millisecond predicate evaluation
• Risk: Complex boolean expressions with many OR clauses can make the filter step the bottleneck
• Mitigation: Pre-computed join tables or denormalized filter fields

Because the vector similarity score is computed only on documents that satisfy the filter, the relevance scores are pure and undistorted. There is no risk of a semantically perfect but categorically wrong document outranking a valid one.

• Score meaning: Cosine similarity reflects semantic closeness within the constrained domain
• No normalization artifacts: Scores don't need adjustment for filter mismatch
• Comparison integrity: All scored documents share the same metadata context, making relative scores directly comparable
• Use case: E-commerce where 'red shoes' must only return products in the 'shoes' category with 'red' color attribute

The inverse architectural pattern where vector similarity search is executed first on the full index, and metadata filters are applied after retrieving the top K results. This approach risks returning fewer than K results if many semantically relevant documents are eliminated by the filter, creating empty or sparse result pages. Post-filtering is simpler to implement but fails catastrophically when the semantic neighborhood of a query does not overlap with the filter criteria.

A storage optimization where separate vector indexes are maintained for each discrete metadata partition (e.g., one index per product category). This allows the system to route a query to the relevant index and perform an unconstrained ANN search within that partition. While this avoids runtime filtering overhead, it introduces index management complexity and can lead to data fragmentation if the partitioning scheme is too granular or changes frequently.

A preprocessing step that analyzes a user's search query to determine its structural type before applying pre-filters. For example, a navigational query for a specific product ID may bypass semantic search entirely, while an informational query triggers pre-filtering on a category. This dynamic routing prevents unnecessary computational overhead and ensures that exact-match constraints are applied with the correct retrieval strategy.

The process of combining the unique document identifiers retrieved by separate sparse and dense pipelines into a single, deduplicated set before final ranking. In a pre-filtering context, both pipelines apply the same metadata constraints independently, ensuring that the merged candidate pool contains only valid documents. This deduplication step is critical for preventing score inflation during subsequent fusion algorithms like RRF.

A query-time technique that dynamically increases the fusion weight of dense vector similarity scores for queries identified as conceptual or intent-heavy. When combined with pre-filtering, semantic boosting ensures that within the constrained candidate set, documents with high semantic relevance are prioritized over those that merely match keywords. This prevents the filter from reducing the query to a purely lexical matching exercise.

A predefined retrieval logic path that activates when the primary pre-filtered search pipeline returns zero or low-confidence results. The fallback may relax metadata constraints (e.g., broadening a date range), revert to pure lexical search, or apply post-filtering as a secondary attempt. Designing robust fallback strategies is essential to prevent empty result pages when strict pre-filters are too aggressive for the user's intent.