Boolean filter semantics
must expresses conditions that a point must satisfy, so multiple conditions inside the must set behave like an AND. must_not excludes points satisfying its conditions, providing NOT semantics.
should expresses alternatives: conditions can be satisfied as alternatives according to the filter semantics, rather than requiring every condition. A common use is allowing a point to match one of several categories or values.
The important engineering point is to read the complete filter structure rather than mapping every should mechanically to SQL OR. Nested conditions, minimum_should semantics, and combinations with must or must_not can affect the exact result set.
A common mistake is confusing must_not with a normal boolean field and assuming should always means 'optional preference.' In Qdrant filters, the surrounding structure and conditions determine whether a clause is required, optional, or used as an alternative. Check the version-specific filter documentation for advanced nested behavior.
must is used for required conditions
should represents alternatives within the filter structure
must_not excludes matching points
Nested and advanced filter semantics should be verified against the deployed Qdrant version
You need documents where tenant_id is A and document_type is either resume or profile. How would you structure the filter?
You must exclude documents marked confidential. Which filter clause would you use?
A filter unexpectedly returns points from a forbidden region even though the region condition is present. How would you inspect the must, should, and must_not nesting?
You need to require tenant_id while allowing several categories. How would you represent those boolean requirements?
A complex filter combines nested arrays, tenant constraints, exclusions, and alternatives. How would you test its logical correctness independently from vector relevance?
A query becomes slower after adding several should clauses. What would you measure before simplifying the filter?
You need to enforce security policy filters across many applications that construct Qdrant queries independently. Where would you place the boolean policy composition to prevent bypasses?
A shared query builder supports arbitrary nested filter expressions. What validation and testing strategy would you use to ensure policy semantics remain correct?