In this article
Sweeping, ACORN and PathSeer change graph traversal, while the filter must preserve the same eligible objects.
Filtered HNSW in Weaviate has several traversal strategies, so choosing ACORN is not simply enabling a generic filter. Compare the documented strategies under the same predicate and relevant-document set, especially when eligible records lie away from the nearest unfiltered neighborhood.
Keep eligibility separate from traversal
The filtering concepts describe precomputed eligible IDs used during vector search. The predicate defines which objects may be returned; traversal determines how the graph is explored. A faster route must not change that eligible population. Validate the allow-list semantics on known objects before interpreting latency or recall. Otherwise a wrong predicate can appear fast because it searches an easier, unintended set.
Explain the documented differences
Sweeping follows graph traversal with filter context. ACORN avoids distance work for nonmatching objects and uses additional neighborhood exploration and eligible entry points. PathSeer adapts neighbor handling as the result set fills. These mechanisms target different wasted-work patterns. They are not three names for the same post-filter. The documentation’s vendor benchmarks can motivate an experiment but cannot establish the fastest option on another corpus.
Check availability and actual configuration
The vector-index reference lists filterStrategy and its version scope. The checked pages identify ACORN as default from 1.34 and PathSeer as added in 1.40. Preserve the installed release and explicit configuration before comparing results. A client accepting a field does not prove that an older server implements the requested behavior. Avoid silently comparing a requested strategy with a different effective default.
Construct different filter shapes
Prepare an illustrative query set with a broad predicate, a restrictive predicate aligned with topic, and a restrictive predicate whose eligible records lie outside the query’s usual neighborhood. Keep the vectors and exact filtered reference fixed. Record which relevant IDs were recovered and how much work the run required. Selectivity alone does not capture the relationship between a predicate and the vector graph.
| Predicate property | Why it matters |
|---|---|
| Broad eligibility | Many graph neighbors remain useful |
| Topic correlation | Eligible objects may cluster near the query |
| Negative correlation | Matching objects may be difficult to reach |
Inspect the implementation boundary
The primary Weaviate repository and release context help distinguish implemented behavior from the algorithm paper inspiring it. Do not assume identical tuning or guarantees across independent implementations. Retain search-depth settings with each trial; varying those alongside strategy obscures the tradeoff. If a fixture returns the right count but misses judged evidence, count alone is not acceptance of the search path.
Choose for the workload you tested
Compare correctness and filtered recall first, then latency under the same request distribution. Report separate results for the different predicate shapes instead of only one pooled average. Preserve the chosen strategy, version and unresolved cases. A later change to tenant distribution or metadata can change the graph-filter relationship even without changing embeddings, which is a reason for targeted reevaluation rather than a universal strategy ranking.
Related reading: Vector-database memory: choosing RAM and storage for retrieval; A local RAG server: placing components around the GPU.