Questions
7 of 18
1Why did Qdrant consolidate search, recommend, and discovery operations into the Universal Query API?
2What is a prefetch stage in Qdrant's Universal Query API, and why would you use multiple prefetches?
3How do Reciprocal Rank Fusion and Distribution-Based Score Fusion differ when combining Qdrant prefetch results?
4How would you retrieve 500 candidates with dense vectors and rerank them using a ColBERT multivector?
5What is Qdrant's recommend query mode, and how is it different from plain similarity search?
6How does Qdrant combine vector similarity search with structured payload filters?
7What are must, should, and must_not clauses in a Qdrant payload filter?
8Why can filtering after an ANN search return too few results when the filter is highly selective?
9How does Qdrant's filtered vector search avoid the classic post-filtering problem?
10How would you implement a geo-radius search for similar items within 5 km of a location in Qdrant?
11Why should you create payload indexes for fields that are filtered frequently at scale?
12What payload index types does Qdrant support, and how would you choose one for tags versus price?
13What is a full-text payload index used for, and how does it differ from an exact-match keyword index?
14What is the cost of creating too many payload indexes on a high-write Qdrant collection?
15Why should point uploads be batched instead of sending one upsert request per point?
16What is Qdrant's Scroll API used for, and why is it preferable to vector search when iterating through matching points?
17How does Qdrant Scroll pagination avoid the main performance problem of large SQL OFFSET pagination?
18What is a realistic batch size for bulk-loading millions of Qdrant points, and what factors should influence it?
07 / 18

What are must, should, and must_not clauses in a Qdrant payload filter?

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.

javascript
  1. 1

    must is used for required conditions

  2. 2

    should represents alternatives within the filter structure

  3. 3

    must_not excludes matching points

  4. 4

    Nested and advanced filter semantics should be verified against the deployed Qdrant version

Difficulty: 3/10
Topics: Payload filters, Boolean logic

Scenario Questions

0-2 years experience
  1. 1

    You need documents where tenant_id is A and document_type is either resume or profile. How would you structure the filter?

  2. 2

    You must exclude documents marked confidential. Which filter clause would you use?

2-5 years experience
  1. 1

    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?

  2. 2

    You need to require tenant_id while allowing several categories. How would you represent those boolean requirements?

5-8 years experience
  1. 1

    A complex filter combines nested arrays, tenant constraints, exclusions, and alternatives. How would you test its logical correctness independently from vector relevance?

  2. 2

    A query becomes slower after adding several should clauses. What would you measure before simplifying the filter?

8+ years experience
  1. 1

    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?

  2. 2

    A shared query builder supports arbitrary nested filter expressions. What validation and testing strategy would you use to ensure policy semantics remain correct?

Follow-up Questions

  • How would you express category A OR category B?
  • How would you combine a required tenant condition with an exclusion condition?