---
title: Filtered Vector Search (FVS)
url: https://www.emergentmind.com/topics/filtered-vector-search-fvs
type: topic
---

# Filtered Vector Search (FVS)

Searching arXiv for recent papers on filtered vector search to ground the article.
Filtered Vector Search (FVS), also called filtered approximate nearest neighbor search and filtered nearest neighbor search, is the problem of retrieving the top-\(k\) nearest vectors to a query subject to a metadata predicate over the indexed objects. Common formulations model a filtered query as \((Q,P,k)\), or as top-\(k\) search over \(\mathcal D'=\{(v_i,a_i)\in \mathcal D \mid p(a_i)=\mathrm{true}\}\); more general treatments pair each point \(x_p\) with an attribute \(a_p\) and search over points satisfying \(g(a_p,f_q)=1\) [2602.17914][2510.27141][2602.10258]. Recent work treats FVS as a systems problem spanning graph traversal, partitioned indexes, relational predicate evaluation, SSD I/O, GPU execution, and query planning, because the presence of a predicate changes both the effective search space and the execution order that is optimal for a given workload [2601.01937][2603.23710].

## 1. Formal models and predicate semantics

The formal core of FVS is stable across papers even when notation differs. In one formulation, a filtered ANN query is the triple \((Q,P,k)\), where \(Q\) is the query vector, \(P\) is a predicate over metadata, and \(k\) is the number of desired results [2602.17914]. In another, the dataset is \(\mathcal D=\{(v_i,a_i)\mid v_i\in\mathbb R^d,\ a_i\in\mathcal A\}\), the query is \(Q=(q,p)\), and the exact target is \(S_k^*=\operatorname*{Top-}k\{(v_i,a_i)\in\mathcal D' \text{ ranked by } \delta(q,v_i)\}\) with \(\mathcal D'=\{(v_i,a_i)\in\mathcal D\mid p(a_i)=\text{true}\}\) [2510.27141]. JAG states the objective as
\[
\arg_{p \in P:\; g(a_p,f_q)=1} \operatorname{dist}(x_p,x_q),
\]
which makes explicit that vector similarity is evaluated only on filter-satisfying points [2602.10258].

The supported predicate families are broader than simple label equality. JAG formalizes four filter families—Label, Range, Subset, and Boolean—and defines them through corresponding attribute domains \(\mathcal A\), filter domains \(\mathcal F\), and binary match functions \(g(a,f)\) [2602.10258]. The learning-based query-planning framework supports categorical/keyword predicates, numeric range predicates, and mixed predicates containing both [2602.17914]. PipeANN-Filter treats predicates through an `is_member` abstraction that supports label predicates, range predicates, and Boolean compositions such as `AND` and `OR` [2605.17992]. Compass presents arbitrary conjunctions, disjunctions, range predicates, and multi-attribute predicates as the intended scope of “general filtered search” [2510.27141].

A security-framed special case is policy-aware vector search, where the predicate is an authorization condition rather than an application-level filter. In that setting, FGAC policies are represented as \(P_i=[oc,sc,act]\), with object constraints \(oc\), subject constraints \(sc\), and action \(act\in\{\text{allow},\text{deny}\}\); the authorized search space is \(V_P=\{(v,m)\in\mathbb D \mid \exists P_j\in P_S: P_j(v,m)=\text{True}\}\) [2606.19803]. This is still FVS, but the filter semantics are security-critical rather than merely preference-oriented.

## 2. Selectivity, correlation, and structural difficulty

The dominant workload variable in FVS is selectivity, usually defined as the fraction of indexed points satisfying the predicate. NaviX writes global selectivity as
\[
\sigma = |S|/|V|,
\]
where \(S\subseteq V\) is the selected subset [2506.23397]. Curator defines filter selectivity as \(|\mathcal P_\sigma|/|S|\) for a qualifying set \(\mathcal P_\sigma\) [2601.01291]. JAG emphasizes that high-selectivity queries admit many valid points, while low-selectivity queries admit few, and that the difficult regime is the middle one, where the valid subset is too large for cheap exact pre-filtering but too sparse for efficient post-filtering [2602.10258].

Correlation between query geometry and predicate satisfaction is a second structural variable. NaviX defines
\[
\text{ce}=\sigma_{v_q}/\sigma,
\]
with \(\sigma_{v_q}\) derived from the overlap between the query’s nearest neighbors and the selected subset; \(\text{ce}\approx 1\) indicates no correlation, \(\text{ce}\gg 1\) positive correlation, and \(\text{ce}\ll 1\) negative correlation [2506.23397]. A system-oriented alternative is Global-Local Selectivity (GLS), which compares global selectivity
\[
\sigma_g = \frac{|\{v \in \mathcal D \mid \phi(v)=1\}|}{N}
\]
to local selectivity
\[
\sigma_l = \frac{|\{v \in \mathcal N_q \mid \phi(v)=1\}|}{k},
\]
forms \(r=\sigma_l/\sigma_g\), and then maps it to
\[
\rho_q=\frac{r-1}{r+1}\in[-1,1)
\]
to measure enrichment or depletion of valid points in the query neighborhood [2602.11443].

Low selectivity is difficult because it changes the topology of the effective search space. Curator calls this **graph connectivity breakdown**: if the search is logically restricted to the subgraph induced by qualifying vectors, the induced subgraph becomes sparse and fragmented as selectivity decreases [2601.01291]. RACORN-1 makes the same point in ACORN-style traversal with the approximation that expected passing one-hop neighbors are \(M\cdot s\) and expected passing two-hop neighbors are \(M^2\cdot s\), so the frontier collapses as \(s\) becomes very small [2607.00768]. GateANN expresses the storage consequence directly: if selectivity is \(s\), post-filtering wastes roughly a \((1-s)\) fraction of SSD reads on nodes that are invalid as answers, so at \(s=0.1\) about 90% of reads can be wasted [2603.21466].

This combination of selectivity and correlation explains why FVS is not reducible to ordinary ANN plus a predicate. The valid subset can be small globally, depleted locally, disconnected in the graph, or badly aligned with storage layout. A plausible implication is that any robust FVS system must reason not only about the number of valid points, but also about where those points sit relative to query neighborhoods, partitions, and storage tiers.

## 3. Execution strategies and query planning

The standard execution taxonomy is pre-filtering, runtime- or inline-filtering, and post-filtering [2602.11443]. Pre-filtering applies the predicate first and then searches the surviving subset. Post-filtering runs ANN first and removes invalid results afterward. Runtime-filtering evaluates metadata lazily as candidates are touched during search. Production systems frequently add hybridization on top of these basic patterns, including exact fallback, candidate expansion, and planner-driven switching [2602.17914][2510.27141].

| Strategy | Execution order | Typical consequence |
|---|---|---|
| Pre-filtering | filter first, then search filtered subset | can use brute-force KNN over survivors; preserves correctness but can be slow [2602.17914] |
| Post-filtering | ANN first, then apply predicate | operationally simple, but recall degrades under low selectivity unless the engine over-fetches [2602.17914] |
| Runtime / inline-filtering | interleave filtering with traversal | supports arbitrary predicates, but can pay substantial filter and system overheads [2603.23710] |
| Cooperative / planner-based execution | choose or combine plans per query | exploits selectivity, local pass rate, or learned signals to switch plans [2510.27141] |

The trade-off between pre-filtering and post-filtering is explicit in the learned planning framework. Pre-filtering can be advantageous when only a small fraction of the corpus passes the filter, but constructing high-performance indexes such as HNSW on each filtered subset is prohibitively expensive; the implementation therefore uses brute-force KNN after filtering and reports that pre-filtering with an HNSW index could take more than 4000 seconds end-to-end, versus 850 seconds with brute-force search, due to index construction cost [2602.17914]. Post-filtering avoids per-predicate index construction by reusing a global ANN index, but it may waste computation and lose recall under low selectivity; the described implementation retrieves \(\alpha k\) candidates, filters them, and doubles \(\alpha\) if fewer than \(k\) valid results remain [2602.17914].

Several systems elevate plan choice to a first-class problem. The learning-based planner is a binary model that chooses between pre-filtering and post-filtering from features including dimensionality, corpus size, a vector distribution measure, and estimated filter selectivity, and reports up to \(4\times\) acceleration while maintaining \(\ge 90\%\) recall [2602.17914]. Compass instead uses cooperative execution: a graph index remains the main driver, but clustered B+-trees inject predicate-satisfying candidates when the local neighborhood passrate falls below a threshold, using default \(\beta=0.05\) for that handoff [2510.27141]. Policy-aware vector search studies the same choice space under authorization constraints and compares pre-filtering, post-filtering, iterative post-filtering, parallel post-filtering, and hybrid filtering as enforcement strategies [2606.19803].

## 4. Indexing and traversal designs

A large part of the literature redesigns navigation rather than only execution order. JAG introduces **attribute distance** \(dist_A\) and **filter distance** \(dist_F\), replacing binary filter checks with continuous navigational guidance, and then constructs a **Joint Attribute Graph** by combining multiple thresholded attribute neighborhoods in one graph [2602.10258]. NaviX evaluates the selection subquery first, materializes the subset \(S\), and then uses **adaptive-local** traversal, selecting among `onehop-s`, `directed`, and `blind` heuristics from local selectivity in the HNSW neighborhood [2506.23397]. FAVOR retains a standard HNSW graph but changes the effective distance seen by the search through an exclusion distance,
\[
\overline{Dis}(\bm q,\bm v)=
\begin{cases}
Dis(\bm q,\bm v^T), & A\in\mathcal F,\\
Dis(\bm q,\bm v^N)+D, & A\notin\mathcal F,
\end{cases}
\]
so non-target data remain traversable but are pushed away from the query; low-selectivity queries are routed to pre-filtering brute-force when estimated selectivity falls below \(\lambda=1\%\) [2605.07770]. RACORN-1 extends ACORN-1 with **Adaptive Search Fallback**, repurposing filter-failing nodes as transient bridges when passing two-hop candidates are insufficient, and RACORN-1+ adds **Adaptive Exact Fallback** for the extreme-low-selectivity regime [2607.00768].

A second line of work treats FVS as physical design. SIEVE argues that constraining traversal is the wrong direction for many workloads and instead builds many indexes, each serving different predicate forms, then uses a three-dimensional analytical model of index size, search time, and recall both during construction and at query time; the abstract reports up to \(8.06\times\) speedup, as low as 1% build time versus other indexes, and less than \(2.15\times\) memory of a standard HNSW graph [2507.11907]. Curator proposes a **dual-index architecture**: use a graph-based ANN index for high-selectivity queries and a partition-based index for low-selectivity queries, with label-specific buffers embedded in a shared hierarchical clustering tree and Bloom filters guiding traversal; integrated with ACORN, Curator reduces low-selectivity query latency by up to \(20.9\times\) relative to ACORN plus pre-filtering fallback while adding only 5.5% construction-time overhead and 4.3% memory overhead [2601.01291]. Compass occupies another design point: it avoids new fused indexes entirely and coordinates HNSW or IVF with clustered B+-trees through a shared candidate queue, preserving generality across conjunctions, disjunctions, and range predicates [2510.27141].

A third line pushes filtering into geometry. FCVI transforms each vector by
\[
\psi(v,f,\alpha)=[v^{(1)}-\alpha f,\dots,v^{(d/m)}-\alpha f],
\]
preserves distances exactly for items with identical filters, and reports \(2.6\)–\(3.0\times\) higher throughput than pre-filtering while maintaining comparable recall [2506.15987]. FusedANN uses a related transformation
\[
\Psi(v,f,\alpha,\beta)=\left[\frac{v^{(1)}-\alpha f}{\beta},\dots,\frac{v^{(d/m)}-\alpha f}{\beta}\right]
\]
and reranks with \(\text{score}(o_i)=\alpha s_f+\beta s_v\), where \(s_f\) is attribute distance and \(s_v\) is content distance; unlike strict Boolean filtered search, part of the paper explicitly broadens the semantics to relaxed hybrid retrieval when exact matches are insufficient [2509.19767]. This suggests a split inside FVS between strict predicate enforcement and geometric relaxation of metadata constraints.

## 5. Storage architecture, SSD systems, and GPU execution

Storage architecture changes which FVS bottlenecks dominate. The tutorial on vector search architectures argues that memory-resident systems are mainly constrained by computation and navigational efficiency, whereas heterogeneous memory–SSD systems are dominated by random I/O and the placement of “lightweight structures for routing and coarse pruning” versus “space-intensive raw vectors and fine-grained indexes” [2601.01937]. For FVS, the tutorial explicitly points to **Filtered-DiskANN** as a graph-based heterogeneous-storage method supporting FANN, and to **Hybrid-IVFFlat**, which colocates vector identifiers and filterable attributes within posting-list entries so filtering and candidate pruning can happen in a single sequential pass [2601.01937].

Two SSD-native designs illustrate how strongly filtering interacts with I/O. GateANN decouples graph traversal from vector retrieval: if a node fails the predicate, the system does not read its SSD record but instead **tunnels** through it using an in-memory neighbor store and PQ distances, preserving graph connectivity without SSD I/O for non-matching nodes [2603.21466]. PipeANN-Filter makes a different trade-off, using **speculative filtering** over a no-false-negative superset of valid vectors, with Bloom filters for labels and 1-byte quantized buckets for ranges, then verifying attributes only after reranking; the design routes among speculative pre-filtering, speculative in-filtering, and post-filtering using a cost model that weights I/O by \(\alpha=10\) and compute by \(\beta=1\) [2605.17992].

GPU work shows that the same FVS problem can lead to a different index decomposition. VecFlow builds a **label-centric** inverted structure in which each label defines a posting list \(C_l=\{i\mid l\in L_{X_i}\}\), then routes large lists to label-local graph search and small lists to brute-force scan on an interleaved GPU layout [2506.00812]. On SIFT-1M, it reports 5M QPS at 90% recall for \(K=10\), and on YFCC-10M it reaches 2.6M QPS at 90% recall; persistent kernels improve small-batch performance by \(5.68\times\) average QPS on SIFT and \(6.72\times\) on YFCC [2506.00812]. The GPU setting therefore does not remove the FVS trade-off; it changes which partitions and execution kernels are effective.

## 6. Empirical patterns and recurrent misconceptions

One recurring misconception is that minimizing vector distance computations is the dominant objective. The PostgreSQL study rejects that premise directly, arguing that in a production-grade database system the optimal algorithm is not dictated by the cost of distance computations alone, because system-level overheads from both distance computations and filter operations—such as page accesses and data retrieval—play a significant role [2603.23710]. The same study shows that graph-based methods can incur prohibitive numbers of filter checks and system-level overheads, and that clustering-based ScaNN can outperform graph approaches by \(2\)–\(3\times\) on low-dimensional datasets inside PostgreSQL-compatible execution [2603.23710].

A second misconception is that graph-based filtered search is uniformly superior. The vector-database study reports that partition-based indexes (IVFFlat) outperform graph-based indexes (HNSW) for low-selectivity queries, and that Milvus achieves superior recall stability through hybrid approximate/exact execution rather than through raw HNSW behavior alone [2602.11443]. The same paper shows that pgvector’s cost-based optimizer frequently selects suboptimal execution plans, often preferring approximate index scans even when exact sequential scans would yield perfect recall at comparable latency [2602.11443]. In other words, engine behavior and plan selection can dominate the nominal index family.

A third misconception is that one static strategy suffices across workloads. The learned query planner reports up to \(4\times\) acceleration with \(\ge 90\%\) recall by choosing between pre-filtering and post-filtering on a per-query basis [2602.17914]. RACORN-1 identifies a “sweet spot” of roughly 1%–0.3% selectivity for bridge-augmented graph search, while RACORN-1+ switches to exact fallback in the extreme-low-selectivity tail and reports recall 1.00 with \(20\)–\(75\times\) speedup at 1M scale for \(\le 0.1\%\) selectivity, and \(13\times\) speedup at 40M scale for 0.01% selectivity [2607.00768]. Curator’s central lesson is even more explicit: the low-selectivity regime deserves its own index design rather than further graph densification [2601.01291].

These results jointly imply that FVS should be understood as a workload-adaptive search problem. Selectivity, query–filter correlation, vector dimensionality, requested \(k\), storage architecture, and DBMS execution overhead all change the preferred design point. This suggests that comparisons that isolate only one of these variables are structurally incomplete.

## 7. Open problems and research directions

Several open directions recur across the literature. One is **cost modeling**. PipeANN-Filter notes that distribution-aware cost models remain future work, because current analysis assumes approximate uniform distribution of valid vectors [2605.17992]. Compass says its relational-side planning is heuristic rather than cost-based and that clustered B+-tree predicate evaluation for arbitrary Boolean combinations is not yet fully optimized [2510.27141]. The PostgreSQL study similarly points to the need for optimizer rules that reason jointly about selectivity, exact-scan cost, and filtered ANN behavior inside a production engine [2603.23710].

A second direction is **updates, drift, and workload shift**. The learning-based planner is trained independently per dataset and may require retraining when distributions shift [2602.17914]. VecFlow identifies index construction efficiency for many labels as future work and does not study multi-GPU scaling [2506.00812]. PipeANN-Filter duplicates attributes in row-wise and column-wise forms and leaves maintenance of Bloom filters, quantized summaries, and duplicated indexes under frequent writes as an open issue [2605.17992]. FCVI explicitly identifies separate indexes per filter field combination as a main limitation [2506.15987].

A third direction is **semantics**. Policy-aware vector search asks for a formal contract for approximate but policy-compliant top-\(k\) retrieval and highlights soundness, security, and maximality as criteria that need reinterpretation for vector databases [2606.19803]. FusedANN, by contrast, intentionally broadens strict filtering into relaxed hybrid retrieval in part of the paper, which sharpens the distinction between exact predicate enforcement and soft metadata-aware ranking [2509.19767]. A plausible implication is that future FVS systems will need clearer semantic tiers: strict filtered ANN, approximate filtered ANN with exact verification, and relaxed hybrid retrieval.

A fourth direction is **architecture-aware co-design**. The storage tutorial identifies tier-aware index co-design, adaptive and predictive caching, efficient querying from object storage, elasticity and auto-scaling, and cost optimization as open research opportunities for future large-scale vector retrieval systems [2601.01937]. FVS adds a further requirement: the placement of vectors, metadata, summaries, and traversal structures must align with predicate selectivity and query locality, not only with vector similarity. This suggests that the next generation of FVS research will be shaped as much by storage architecture and query optimization as by ANN data structures themselves.

Source: https://www.emergentmind.com/topics/filtered-vector-search-fvs