A multitenant Azure AI Search index serves many small tenants.

How it works

In Azure AI Search, a filter on a vector query restricts which documents count. vectorFilterMode decides when the filter runs relative to the HNSW nearest-neighbor search, which affects latency, recall and throughput. There are three modes:

• preFilter: applies the filter during HNSW traversal on each shard. It maximizes recall, but for highly selective filters it can traverse more of the graph, increasing CPU and latency.
• postFilter: runs traversal and filtering on each shard independently, intersects results, then aggregates each shard's top k into a global top k. It can create false negatives for highly selective filters or small k values.
• strictPostFilter (preview): finds the unfiltered global top k first, then filters. It has the highest risk of false negatives.

A filter on tenantId is highly selective for a small tenant, and k is 5. With postFilter, the top candidates per shard are mostly other tenants' documents. Filtering removes them, leaving fewer than five or none. preFilter only walks matching documents, so it returns that tenant's real nearest neighbors.

The cost is some extra CPU and latency on the most selective filters, usually a fine trade for correct results.

The other options, and when you'd use them

• Lower k to 1 with postFilter: Smaller k makes it worse. postFilter's false negatives grow with selective filters and small k values.
• Filters can't be combined with vector queries: They can. Vector fields themselves aren't filterable, but filters on other fields narrow the documents considered for vector search.
• strictPostFilter (preview): It filters after the unfiltered global top k, which has the highest false-negative risk.

Exam tip

Selective filters (per tenant) + small k on vector queries = preFilter. postFilter and especially strictPostFilter can return too few results.

References

• Add a filter to a vector query in Azure AI Search