What does the query-time parameter ef (search breadth) control, and how would you use it to trade off recall against latency?

ef is the size of the dynamic candidate list maintained during the layer-0 best-first search. It is the single most important query-time knob in HNSW because it lets you trade recall for latency per request without touching the index. During search, the algorithm maintains two structures: a frontier of unexplored candidates ordered by distance, and a result set of the best nodes found so far, both bounded by ef. Larger ef means the search explores more of the graph before it terminates, which reduces the probability of missing a true nearest neighbor, at the cost of more distance computations. The result set is what gets returned as top-k, so ef must be at least as large as limit; Qdrant silently raises it to max(ef, limit) if you set it lower.

The reason this is the right knob to reach for is that it decouples recall from index structure. m and ef_construct are baked into the graph and changing them requires rebuilding; ef is evaluated fresh on every query and has essentially linear cost in distance computations and roughly linear cost in latency at a fixed vector size. That means you can have different ef for different endpoints: a search-as-you-type endpoint uses ef=32 for 3ms responses, while a nightly bulk scoring job uses ef=512 for maximum recall. The same collection serves both. The shape of the recall vs ef curve is concave and dataset-dependent: on most real datasets recall rises steeply between ef=16 and ef=128, then flattens. The knee of that curve is where you want your default; past it you are paying latency for fractions of a point of recall. You should measure this curve on your own data against exact ground truth, not assume the knee is at the same place as a blog post.