What is a predicate in search filtering?

A predicate, in the context of search filtering, is the actual condition being checked when a filtered nearest-neighbor search decides whether a given item qualifies for inclusion — a rule like “category equals electronics” or “price is less than fifty” that evaluates to either true or false for any given item, independent of that item’s vector or its distance to the query. Predicates are the building blocks filtered search is actually made of, and understanding them precisely helps clarify exactly what kind of information a filtering system needs and how that information relates to the vector data HNSW searches over.

What makes something count as a predicate, specifically?

A predicate is any function that takes an item and returns a simple true-or-false answer about whether that item satisfies some condition. This is a deliberately narrow, precise definition: a predicate doesn’t rank items, doesn’t produce a numeric score, and doesn’t care about degrees of satisfaction — an item either passes the predicate or it doesn’t, with nothing in between. This binary nature is exactly what distinguishes predicate-based filtering from the vector-similarity ranking HNSW performs, which produces a continuous distance value rather than a simple pass-or-fail judgment. A filtered nearest-neighbor search combines these two fundamentally different kinds of evaluation: a continuous, ranked similarity score from the vector search, and a binary, all-or-nothing pass-or-fail judgment from one or more predicates applied on top.

Predicates can be combined using ordinary logical operations, exactly the way conditions are combined in a traditional database query — an item might need to satisfy several predicates joined together with “and,” meaning every one of them has to hold, or it might need to satisfy just one predicate out of several joined with “or.” A search for a product might apply a predicate requiring the category to be electronics, combined with another requiring the price to fall under some threshold, both needing to hold simultaneously for an item to qualify — two simple predicates combined into a more elaborate compound filtering condition.

Where does the information a predicate checks actually come from, relative to the vector data itself?

This is an important distinction to be precise about: a predicate almost always evaluates metadata attached to an item — structured fields like category, price, date, or ownership — rather than anything derived from the item’s vector representation. The vector captures a notion of semantic or geometric similarity, useful for ranking how alike two items are, while the metadata a predicate checks captures separate, usually more concrete and structured facts about the item that have nothing directly to do with its position in the embedding space. A product’s embedding vector reflects what it’s semantically similar to; its price is a completely separate piece of information stored alongside that vector, checked by an entirely different mechanism than the distance calculations HNSW performs.

This separation between vector similarity and predicate-based metadata filtering is exactly why combining the two well is a genuinely nontrivial engineering problem, as covered in more depth on the filtered-nearest-neighbor-search glossary page — the graph structure HNSW builds is organized entirely around vector proximity, with no inherent awareness of the metadata predicates might later be checking, which is precisely the mismatch that makes pre-filtering, post-filtering, and the more sophisticated filter-aware approaches each carry their own distinct trade-offs.

Why does the specific shape of a predicate — how selective or complex it is — matter so much in practice?

Not all predicates behave the same way when it comes to how they interact with vector search performance, and this is where the more practical, engineering-focused side of filtered search comes into play. A predicate that very few items in the dataset satisfy is described as highly selective, and highly selective predicates tend to be exactly the ones that stress a filtered search system the hardest, since a pre-filtering approach might be left searching a tiny handful of matching items, while a post-filtering approach might have to discard almost everything a normal vector search returns before finding anything that actually satisfies the predicate. A predicate that most items satisfy, described as having low selectivity, tends to cause far fewer practical problems, since a normal vector search is likely to return several qualifying items without much special handling needed at all. This concept of filter selectivity, covered in more depth on its own glossary page, is one of the central practical concerns that shapes how a real filtered search system actually gets engineered and tuned.

Having established what a predicate actually is and how it differs fundamentally from vector-similarity ranking, the pre-filtering and post-filtering glossary pages are worth revisiting with this more precise vocabulary in mind, since both strategies exist specifically to reconcile predicate-based filtering with vector search. From there, the filter-selectivity and vector-predicate-correlation glossary pages, under filtered and hybrid search concepts, dig into exactly how the shape and behavior of a predicate influences which filtering strategy actually performs well for a given workload.