# PathSeer: Adaptive Filtered Vector Search

By Steven Van · 2026-10-14

PathSeer, a new HNSW filter strategy in Weaviate 1.40, blends sweeping and ACORN for 1.10× build time and 1.06× memory.

Weaviate has added PathSeer, a new HNSW filter strategy for filtered vector search, to [Weaviate](<https://creatorstoolbox.com/tools/weaviate>). It comes from Zhiyue Li, Guangyan Zhang and colleagues at Tsinghua University, whose SIGMOD 2026 paper describes it. Li contributed the implementation in a [pull request](<https://github.com/weaviate/weaviate/pull/12137>), and Weaviate's blog covers how to use it in Weaviate 1.40.

## Where it sits between sweeping and ACORN

Weaviate already offers two HNSW filter strategies, sweeping and ACORN. ACORN became the default in 1.34. Weaviate says it performs well when filters are negatively correlated with the query, but loses recall on very sparse filters. Above 40% selectivity its two-hop expansion costs more than it saves, so its use is restricted by selectivity.

PathSeer is a hybrid of the two. It aims to keep the graph navigability of sweeping while cutting unnecessary distance computations under restrictive filters. The pull request says it is not meant to replace either strategy, but to perform consistently well across more workloads.

## How the search works

PathSeer splits layer-0 neighbours into two areas:

- **Sparse area:** the normal HNSW connections kept by the existing heuristic neighbour selection. Distances are computed first, then the allow-list filter is applied, as in sweeping.

- **Extended area:** extra neighbours that were pruned during selection but are kept separately. The filter is checked first, and distance is computed only for candidates that pass, as in ACORN.

With no filter, only the sparse area is visited, so unfiltered search behaves like sweeping. On a single layer, PathSeer is treated as equivalent to sweeping.

## Benchmarks and overhead

The pull request reports tests on 500K BEIR vectors, with filters built from dataset-source labels. Workloads used NQ and MSMARCO, plus multi-dataset mixes, with positive and negative query-filter correlation and selectivity of 0.1 and 0.4. HNSW used maxConnections 32, efConstruction 256 and flatSearchCutoff 0. PathSeer showed a consistently strong recall-throughput trade-off, while the best existing strategy alternated between sweeping and ACORN depending on the workload.

The extra neighbours cost some build time and memory:

- Build time: 474.4s against 429.4s for sweeping or ACORN (1.10×).

- Memory: 5.12GB against 4.82GB (1.06×).

The extended area is capped at 2 × maxConnections, and the change adds no new user-facing tuning settings.

## Persistence and safety

Extended-neighbour data is saved through the commit log, snapshots and compaction. A flag ensures PathSeer is only active when the index was built with that data, and PathSeer-built indexes are detected automatically on cold start. The pull request notes that documentation had not yet been updated when it was opened.

![Weaviate](<https://www.google.com/s2/favicons?domain=weaviate.io&sz=128>)

Weaviate

Bring AI-native applications to life with less hallucination, data leakage, and vendor lock-in

[View Weaviate →](<https://creatorstoolbox.com/tools/weaviate>)

Sources

[Original source](<https://weaviate.io/blog/pathseer-filtered-vector-search>)

[Read PathSeer: Adaptive Filtered Vector Search on Creators Toolbox](<https://creatorstoolbox.com/blog/weaviate-pathseer-adaptive-filtered-vector-search>)

---
Canonical source: https://creatorstoolbox.com/blog/weaviate-pathseer-adaptive-filtered-vector-search