PipeANN-Filter: SSD-Optimized Filtered ANN

• The paper introduces speculative filtering that uses a no-false-negative approximate predicate, enabling efficient SSD-resident ANN graph traversal.
• It combines in-memory Bloom filters and quantized summaries to dramatically reduce expensive SSD attribute reads during neighbor search.
• Empirical evaluations demonstrate significant throughput gains and lower latency compared to strict filtering methods on large-scale datasets.

Searching arXiv for the target paper and closely related work to ground the article. arxiv_search(query="(Guo et al., 18 May 2026)", max_results=5) PipeANN-Filter is an SSD-resident filtered approximate nearest neighbor system whose defining design choice is deliberately non-strict filtering during search. Rather than requiring every explored vector to be known in advance to satisfy an attribute predicate, it traverses a superset of the valid vectors via a no-false-negative approximate predicate and postpones exact attribute verification until after the nearest candidates have been identified. In the formulation of "PipeANN-Filter: An Efficient Filtered Vector Search System on SSD" (Guo et al., 18 May 2026), this shifts filtered search on SSD away from exact attribute reads during traversal and toward compact in-memory probabilistic summaries, with the explicit tradeoff of a small amount of false-positive vector exploration for a large reduction in SSD attribute I/O.

1. Problem setting and motivation

PipeANN-Filter addresses filtered vector search over datasets large enough that vectors, graph structure, and attributes must reside on SSD. The task is to return the top-$k$ nearest vectors satisfying an attribute predicate, where predicates may include label membership, numeric ranges, Boolean combinations such as AND and OR, and potentially user-defined constraints. The central difficulty is that ANN graph traversal prefers a small search path over a sparse graph, whereas strict attribute filtering requires exact predicate evaluation over explored vectors, which is particularly expensive when attributes are SSD-resident (Guo et al., 18 May 2026).

The motivating argument is storage-centric. The paper emphasizes that attribute footprints can be substantial: LAION400M’s attributes occupy 58.6 GB for 400 million vectors, while compressed vectors use only 24 GB; for 500 million e-commerce items, attributes may require around 300 GB. Under these conditions, keeping all attributes in DRAM undermines the purpose of SSD-based vector search. This makes filtered ANN on SSD fundamentally different from filtered ANN in memory-rich settings.

The paper organizes prior SSD-relevant mechanisms into three classes. Post-filtering performs ANN first and filters only the returned candidates; it is efficient at high selectivity because verification can be piggybacked on vectors already fetched for reranking, but it fails at low selectivity because too much of the graph must be traversed to find enough valid vectors. Pre-filtering identifies valid IDs first and then performs brute-force nearest-neighbor search over that subset; it works only at very low selectivity and becomes bottlenecked by SSD scans over attributes and by many in-memory distance computations once the valid set is no longer tiny. In-filtering expands only neighbors satisfying the predicate during graph traversal; on SSD this is especially costly because each vector typically has 32–128 neighbors, randomly scattered, so strict validation induces heavy random SSD I/O, and the paper reports throughput below 50 QPS in its motivating experiment.

A second motivation is graph connectivity. When selectivity is low, restricting traversal to only valid nodes can disconnect the effective search graph. Because the underlying ANN graph is sparse, with about 100 neighbors per node, many nodes may have no valid outgoing path. The paper argues that allowing exploration of some invalid-but-plausible nodes can improve access to valid regions. This suggests that false positives are not purely overhead; under some regimes they act as bridge nodes that preserve traversability.

2. Speculative filtering as the central abstraction

The system formalizes its core idea as speculative filtering. During search, PipeANN-Filter uses an approximate predicate is_member_approx that returns a superset of the valid vectors. Its contract is asymmetric: if is_member_approx(id) returns false, the vector is definitely invalid; if it returns true, the vector may or may not be valid. The crucial requirement is no false negatives. Exact filtering is delegated to is_member, which is applied only after ANN has produced the nearest candidates (Guo et al., 18 May 2026).

This abstraction is the basis for the system’s three selectable execution modes: speculative pre-filtering, speculative in-filtering, and post-filtering. PipeANN-Filter is built on top of PipeANN, and the name reflects both that implementation base and a pipelined SSD-search philosophy in which filtering is integrated into PipeANN-style traversal rather than treated as an external stage. The paper presents the system as choosing among those mechanisms via a cost model that incorporates selectivity, approximate-filter precision, SSD I/O, and compute.

A key systems observation makes deferred verification practical. SSD ANN already fetches the top candidates’ full-precision vectors for reranking, and PipeANN-Filter co-locates attributes with the vector record. If vectors and attributes lie in the same SSD page, exact verification can be piggybacked on reranking reads and may add essentially no extra I/O. This design is central to the system’s claim that exact filter semantics can be preserved without enforcing exact filtering during traversal.

The paper’s analysis identifies strict filtering as the common failure mode of conventional pre-filtering and in-filtering in SSD settings. Both require exact knowledge of validity before further progress can be made, so both force early and repeated SSD attribute reads. PipeANN-Filter replaces that requirement with a false-negative-free approximation boundary: vectors can be explored speculatively, but valid vectors must never be excluded. That is the system’s correctness-preserving relaxation.

3. Predicate approximation mechanisms

For label predicates, PipeANN-Filter uses a per-vector Bloom filter stored in memory, together with an SSD inverted index per label. The inverted index stores vector IDs containing each label; in memory the system keeps label offsets and counts plus a lightweight Bloom filter for each vector. During speculative in-filtering, the queried label predicate is tested against that vector’s Bloom filter. The memory footprint for label filters is fixed at 4 bytes per vector (Guo et al., 18 May 2026).

The Bloom-filter semantics follow the standard asymmetry required by speculative filtering. False negatives are impossible, assuming correct construction, so a valid vector is never excluded by the Bloom filter; false positives may occur due to hash collisions, in which case an invalid vector may be explored. Exact final verification preserves correctness. The paper notes that its cost model is parameterized by precision $p$, and writes the false-positive rate as $1-p$.

PipeANN-Filter does not rely on Bloom filters alone for labels. A pure Bloom-filter design can become inaccurate for vectors with many labels, whereas a pure inverted-list approach is accurate but expensive for high-frequency labels. The system therefore adopts a hybrid design. Before speculative in-filtering, it fetches SSD inverted lists for rare queried labels only and merges the IDs in memory, using intersection for LabelAndSelector and union for LabelOrSelector. For the remaining frequent labels, it falls back to the per-vector Bloom filters. If an ID is absent from the pre-merged rare-label list, LabelOrSelector consults the Bloom filter, whereas LabelAndSelector can safely return false. This hybridization is intended to bound SSD I/O while improving precision relative to Bloom filters alone.

For numeric range predicates, the approximate structure is not a Bloom filter but a coarse in-memory quantization. On SSD, PipeANN-Filter stores a sorted flat array of <vector_ID, value> pairs. In memory, it stores a 1-byte quantized bucket ID per vector, the 256 bucket boundaries, and a separate 1000-quantile summary for selectivity estimation. During speculative in-filtering, is_member_approx tests whether the vector’s bucket overlaps the query interval $[l,r)$. Because a bucket may straddle the interval boundary, this can produce false positives but not false negatives.

Speculative pre-filtering uses different approximations. For labels, pre_filter_approx generally scans SSD inverted indexes and merges them, since pre-filtering is selected mainly for low-selectivity queries; for Boolean AND, high-selectivity branches may be skipped entirely if intersecting only low-selectivity labels already yields a safe superset. For ranges, pre_filter_approx uses the exact SSD sorted index, locating the relevant region with the in-memory bucket boundaries and then sequentially scanning that region. This suggests that PipeANN-Filter treats speculative filtering not as a single mechanism but as a family of predicate-specific superset-generation techniques.

4. Index architecture, storage layout, and query execution

PipeANN-Filter has two principal components: a vector index and an attribute index. The vector index follows a DiskANN/PipeANN-style graph layout with PQ-compressed vectors in memory and graph records on SSD. Each SSD record stores four elements: the full-precision vector, the direct neighbor IDs, the vector’s attributes, and a subset of 2-hop neighbor IDs. Attributes are stored row-wise in the record for exact verification and post-filtering; the 2-hop neighbors, inspired by ACORN, are used only for speculative in-filtering (Guo et al., 18 May 2026).

The paper gives concrete density guidance for the graph records. Direct neighbors may be 96, and stored 2-hop neighbors around 1000; more generally, the 2-hop count is 10–20× the direct-neighbor count. For LAION100M, the original record size is 4056 bytes and the record with dense neighbors is 8068 bytes. The system chooses $R_d$ so that the densified record occupies one extra 4 KB page relative to the original record. The significance of this design is that it increases connectivity for filtered traversal while preserving page-aligned SSD access patterns.

The attribute index is built only for attributes whose filtering benefits from indexing. Label attributes are stored column-wise as SSD inverted lists with sorted contiguous IDs, while range attributes are stored as a sorted <ID, value> array. The paper notes that indexed attributes are effectively duplicated: once in columnar SSD indexes for pre-filter scans, and again inside the row-wise vector records for exact final verification. The design objective is not deduplication but execution-path specialization.

Each query contains the query vector, $k$, query attributes, and a Selector. The Selector abstraction exposes is_member, is_member_approx, pre_filter_approx, and estimation functions for selectivity and precision. Built-in selectors include label filtering, range filtering, AND, and OR. The system estimates the expected cost of speculative pre-filtering, speculative in-filtering, and post-filtering, then selects the mechanism with the lowest weighted objective

$$\text{Total Cost} = \alpha \times \text{Est.\ I/O} + \beta \times \text{Est.\ Compute},$$

with default weights $\alpha = 10$ and $\beta = 1$, and default $\gamma = 0.05$ for the relative cost of is_member_approx to a distance computation.

If speculative pre-filtering is selected, pre_filter_approx generates a superset of valid vector IDs, brute-force ANN is run over that superset using in-memory PQ-compressed vectors, the top-$p$0 candidates are fetched from SSD for reranking, and exact is_member is applied to those fetched records. If speculative in-filtering is selected, the system performs best-first traversal from the entry point, reading each explored node’s SSD record, examining both direct and stored 2-hop neighbors, evaluating is_member_approx in memory, collecting up to $p$1 neighbors satisfying the approximate predicate, filling any remainder with invalid direct neighbors, and preferring “possibly valid” nodes even when slightly farther than invalid alternatives. If post-filtering is selected, standard SSD ANN is run without filtering during traversal, followed by reranking and exact verification. In all three paths, additional rounds occur if the current candidate batch yields fewer than $p$2 valid results.

5. Correctness, approximation, and empirical behavior

PipeANN-Filter preserves exact filter semantics in the final output provided that is_member_approx has no false negatives and the final candidates are verified with exact is_member. The paper distinguishes two kinds of approximation. The first is the ordinary ANN approximation inherited from DiskANN/PipeANN-style graph search, which can reduce recall. The second is speculative-filter false positives, which add explored candidates but do not exclude valid answers. The latter are therefore a performance and trajectory phenomenon, not a logical correctness failure (Guo et al., 18 May 2026).

This distinction addresses a common misconception: Bloom-filter false positives do not change the predicate semantics of returned results. They only alter the search path and the amount of work done. The paper further argues that false positives may improve recall by helping reconnect filtered subgraphs. Under that interpretation, speculative filtering is not merely a storage optimization; it also modifies traversal dynamics in sparse ANN graphs.

The evaluation uses a single server with $p$3 28-core Intel Xeon Gold 6330 @ 2.00GHz, 512 GB RAM, a Samsung PM9A3 3.84 TB SSD, and Ubuntu 22.04, Linux 5.15. Datasets are YFCC10M, YT5M, and LAION100M, with workloads including single-label, label-AND, label-OR, range, and hybrid (LabelOr OR Range). Baselines are PipeANN-BaseFilter, Milvus v2.6.11 with HNSW and IVFPQ, and Filtered-DiskANN for the single-label workload.

On million-scale datasets at 0.9 recall, PipeANN-Filter achieves 1.91× and 1.71× the throughput of PipeANN-BaseFilter on YT5M and YFCC10M. Compared with Milvus, the abstract reports at least 89.5% lower latency and at least 32.3× higher throughput. At higher recall, the throughput advantage over PipeANN-BaseFilter grows to 3.95× on YT5M at 0.95 recall and 2.03× on YFCC10M at 0.99 recall. On LAION100M single-label filtering at 0.9 recall, PipeANN-Filter achieves 1.44× the throughput of PipeANN-BaseFilter and reduces latency to 45.5% of the baseline; at 0.99 recall, the throughput gain is 1.14× and latency is 55.1% of baseline. Against Filtered-DiskANN, PipeANN-Filter reduces latency by 77.6%, achieves 4.35× higher throughput, and reaches higher recall, while Filtered-DiskANN fails to exceed 0.8 recall in the reported setup. For range filtering on LAION100M at 0.9 recall, PipeANN-Filter achieves 9.78× the throughput of PipeANN-BaseFilter and reduces latency to 12.5% of the baseline.

The paper also reports on model fidelity and false-positive behavior. For speculative in-filtering on YT5M, estimated I/O is 0.74× to 1.04× actual; on LAION100M, it can be overestimated by up to 2.05×, which the paper attributes to early termination effects not modeled. False-positive rates in speculative in-filtering range from 0.8% to 69.4%, with 23.6% average and 17.1% median; the worst case is the LAION100M single-label workload, which averages 63.5% false-positive rate across recall targets 0.85–0.99. Yet the system still outperforms the strict baseline in that regime. This is one of the paper’s strongest empirical supports for the thesis that, on SSD, extra vector explorations can be substantially cheaper than exact attribute reads.

6. Position in the literature, limitations, and implications

PipeANN-Filter is positioned against two families of prior work. Relative to earlier filtered ANN systems, it remains in the attribute-agnostic camp, using one general vector index rather than a predicate-specialized index, but changes the filtering philosophy by allowing approximate filtering during traversal with exact verification later. Relative to prior SSD ANN systems such as DiskANN, SPANN, Starling, and PipeANN, it targets the additional attribute-I/O bottleneck introduced by filtered search rather than generic SSD ANN traversal alone (Guo et al., 18 May 2026).

The paper frames its conceptual novelty as importing probabilistic filtering to avoid expensive storage accesses into SSD-based filtered ANN. In that sense, the Bloom-filter component is not an isolated data structure choice; it is an SSD-systems strategy. The comparison points in the paper sharpen that claim. Against Milvus / Faiss-style filtered search, PipeANN-Filter avoids expensive strict pre-filter scans for many queries. Against Filtered-DiskANN, it does not require all labels in memory and does not rely on a label-customized graph remaining connected. From ACORN, it borrows the idea of densifying graph records with 2-hop neighbors, but combines it with speculative filtering and SSD-aware verification.

The limitations are explicit. The demonstrated efficient predicate support is strongest for labels, ranges, and Boolean combinations, even though the Selector interface is broader. Correctness depends on selector implementations satisfying the no-false-negative contract. Selectivity sensitivity remains significant, and although the cost model mitigates it, the model assumes uniformity in places and ignores data-distribution-dependent early termination. Combined selectivity and precision estimation assumes independent predicates, following database-style estimation practice, which may be inaccurate under correlated real data. Memory overhead remains nonzero even if small relative to full attributes: Table 3 reports 39 MB for YFCC10M label (3.5% of SSD attribute index), 20 MB for YT5M label (28.9%), 384 MB for LAION100M label (15.8%), and 96 MB for LAION100M range (12.5%).

The main future direction proposed in the paper is a data-distribution-aware cost model that better captures early termination and clustered valid-vector distributions. A plausible implication is that PipeANN-Filter’s core abstraction is broader than the specific label and range selectors implemented in the paper: if a predicate admits a compact, false-negative-free in-memory summary and an efficient batched superset generator, then the same speculative design could be extended without changing the system’s fundamental search architecture. The implementation is open source at https://github.com/thustorage/PipeANN, reinforcing its role as both a research contribution and a systems substrate.