What Happened
Weaviate 1.40 added PathSeer, a filtered vector-search strategy that adapts between distance-first and filter-first exploration as filter selectivity changes. It uses existing HNSW indices, so teams can test filterStrategy: pathseer without reindexing. ACORN remains the default, and the existing flat-search cutoff still applies [1].
In Weaviate’s tests, PathSeer was generally fastest at 0.90 recall@10 across the filters examined. On six wiki-dpr conjunction filters, it was 1.1–1.4 times faster than the better alternative. It was not uniformly better: ACORN was 8.7 times faster on one filter negatively correlated with the query’s nearest neighbors. The tests disabled the flat-search cutoff, so their very sparse-filter results may not match a default deployment [1].
Why It Matters to Businesses
Production retrieval-augmented generation (RAG) rarely searches an entire corpus. It filters by tenant, permissions, document type, region, or freshness before supplying evidence to a model. A search strategy that performs well on broad queries may slow down or miss relevant results when those filters narrow the candidate set. That affects response latency and answer quality, even if the language model is unchanged.
For teams using LlamaIndex, LangChain, or Haystack, this is a retrieval-layer decision, not a reason to rewrite orchestration. For teams evaluating Weaviate alongside Pinecone, Qdrant, Milvus, Elasticsearch, or Vespa, the practical question is whether the chosen system meets recall and latency targets under their actual filters, not which engine wins a generic vector benchmark.
Kimbodo Engineering Perspective
We would treat PathSeer as a workload-specific optimization, not a new default. Its ability to reuse an HNSW index lowers the cost of an experiment, but the ACORN counterexample shows why filter-to-query correlation matters [1]. A benchmark should include restrictive permission filters, multi-clause filters, and queries whose nearest semantic matches are deliberately excluded.
Higher search recall is useful only if retrieved passages are relevant and authorized. We would evaluate search recall separately from citation accuracy and final-answer quality, then tune candidate count, reranking, and context size against end-to-end latency and cost.
How We Would Implement It
- Build a representative test set: sample real query patterns and filter combinations; include known relevant documents and permission-denied documents.
- Benchmark the current path: measure recall@k, p50 and p95 latency, and resource use by filter selectivity. Record index settings and whether flat-search cutoff is active so comparisons are reproducible.
- Run a controlled comparison: test PathSeer against ACORN on the same Weaviate collection and hardware, including negatively correlated filters. Roll out only where the combined recall and latency results improve.
- Keep the RAG pipeline modular: enforce authorization before retrieval, pass structured filters to the search service, optionally rerank authorized candidates, and provide the model with traceable document identifiers and citations.
Risks, Costs and Security
A faster search path does not replace access control. Tenant and document permissions must be enforced by trusted application and search-service logic, not by instructions to the model. Test for cross-tenant leakage, malformed filters, and stale access metadata.
Index memory, query CPU, reranking, and longer model contexts all affect total cost. Because PathSeer’s published Weaviate results used a 16-vCPU machine with flat-search cutoff disabled, budget and capacity decisions should rely on measurements from the intended deployment configuration [1].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our RAG Development Services practice, or Estimate My RAG System.
