Azure AI Search vector filter returns too few results: check filter mode

An enterprise assistant answers well in a broad test but returns nothing for a specific tenant or collection. A Stack Overflow question asks how to scope retrieval by user and collection; the answer points to filterable metadata. That is necessary for access scoping, but retrieval quality also depends on when the vector filter runs.

Confirm the access predicate

Put tenant, collection and document visibility in filterable nonvector fields. Build the filter from trusted application identity, not from a user's prompt. First test a keyword or filter-only query to prove eligible documents exist and the expected IDs are returned. If this fails, repair indexing or entitlement data before tuning vector search.

Compare modes with the same query

Microsoft's vector filter guide distinguishes preFilter, postFilter and preview strictPostFilter. preFilter searches within the eligible set and is the recommended default when recall matters. postFilter can discard hits after each shard chooses candidates; a selective filter and small k can produce false negatives. strictPostFilter can return zero despite matching documents elsewhere. Compare exact eligible-document IDs under each mode, k and index version, then measure latency.

Preserve the security boundary

Increasing k may improve postfilter recall, but it is not a substitute for enforcing tenant authorization. The application should still reject any retrieved document outside the caller's allowed set before putting text into a model context or citation. Log query mode, filter hash, tenant, candidate count and final authorized count without leaking another tenant's content.

Adovo’s view

Retrieval is a two-part promise: the user sees only what they may see, and they can find what they should see. A filter that is secure but silently removes relevant answers still breaks the product. Test both properties with the same real queries.