IN THIS BREAKDOWN · 10 SECTIONS
You can read 17% of this breakdown.
The paper in one minute
A vector query often has two requirements: find semantically nearby records and return only records satisfying a metadata condition. The nearest records in the entire corpus may be invalid for that condition. Searching first and filtering afterward can therefore return too few results or miss the nearest valid ones.
This paper studies filtered approximate nearest-neighbor search inside FAISS, Milvus and pgvector. It separates filtering strategies, introduces a movie-and-review dataset with structured metadata, and examines how index parameters and system execution policies affect the recall-latency tradeoff.
Its Global-Local Selectivity metric compares the fraction of eligible records near a query with their fraction across the corpus. Two filters can accept the same number of records while creating very different search difficulty if one has eligible points nearby and the other does not.
The February 2026 experiments show why an index-family label is insufficient. Query planning, adaptive search and exact fallbacks can matter as much as the underlying index. The authors' benchmark extension provides the starting point for reproduction. The findings concern specific versions and an in-memory scalar-filter workload, not every current configuration of the named systems.
Research notes: the problem, approach and results
evaluated systems: FAISS, Milvus and pgvector
MoReVec embedding dimensions, section 6.3
GLS range for a nonempty global filter, equation 6
Metadata constraints change which neighbors are valid, so unfiltered ANN performance can misrepresent a production retrieval workload.
Evaluate filtering strategies inside complete systems and compare local filter prevalence with global selectivity.
The tested query plans and fallback policies materially affect recall and latency; no index family wins independently of the workload.
Why it matters to an FDE
A customer may report that search works in a demo but fails after adding account, date or product filters. Before changing the embedding model, inspect whether the vector-search plan finds enough eligible candidates. The relevant document may exist and have a good vector, yet never survive the chosen execution path.
This is also a measurement problem. Recall must be computed against the nearest valid records, not the unfiltered top results. Otherwise a benchmark can reward a system for finding records the application is not allowed or intended to return.
Use vector databases and RAG evaluation together. Establish a filtered exact-search reference, then compare approximate plans at a required quality level. The goal is reliable evidence under real constraints, rather than the highest query rate for a different, unfiltered problem.
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 199 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>2 runnable code blocks
- ▦3 results tables
- 03Key takeaways
Six distinctions for evaluating metadata-constrained vector search correctly
Free account - 04How it works
Follow the filtering taxonomy and the local-versus-global diagnostic
Premium - 05The numbers that matter
Preserve dataset sizes, tested versions and measurement conditions
Premium - 06Try it yourself
Hold global selectivity fixed and watch a post-filter candidate budget fail
Premium - 07Where it breaks
Avoid turning a useful diagnostic into an optimizer guarantee
Premium - 08Using it on a deployment
Build a filtered-search evaluation before choosing indexes or increasing search depth
Premium - 09Interview angles
Explain why filtering the global top-k is not the filtered top-k
Premium - 10Read next
Connect database execution with embedding limitations and end-to-end retrieval evaluation
Premium
