What is a recall-versus-latency trade-off curve?

A recall-versus-latency trade-off curve is a plot of measured search quality against response time across a sweep of index settings — typically showing how raising HNSW search effort lifts recall@k while stretching latency.

What does the curve show that a single number cannot?

One operating point answers “how fast and accurate is this config?” The curve answers “how does accuracy buy or sell speed as I turn the dials?” Each point is a full benchmark at fixed dataset, metric, and k: recall from ground truth on one axis, latency (mean or a percentile) on the other. Connecting those points reveals the shape of the trade-off — steep gains early, diminishing returns later, or flat regions where extra ef buys nothing. Without the curve, cherry-picked headlines and default settings both look equally justified. With it, you see whether your SLA sits on a gentle slope or a cliff.

Building the curve is a disciplined parameter sweep.

How do you construct a recall-versus-latency curve for HNSW?

Hold the graph build fixed (or sweep build settings as separate curves). Vary a query-time control — most often ef — over a wide range, and for each value measure recall@k and latency under the same load shape and cache policy. Plot latency on the horizontal axis and recall on the vertical (a common convention), or the reverse if your audience expects it — just label axes clearly. Optionally overlay p50 and p99 as two curves so tails are visible. Keep concurrency, batching, and warm-up identical across points so the only intentional change is search effort. Distance-computation counts can be plotted on a twin axis when you want an algorithm-centric view alongside wall-clock time.

Related plots swap latency for throughput; they tell a sibling story.

How does a recall-versus-QPS curve relate?

QPS is roughly capacity; latency is per-request wait. Under light load they move inversely, but under saturation locks and queueing bend the relationship. ANN literature and Weaviate-style charts often show recall versus QPS because multi-threaded capacity is the product question. A recall-versus-latency curve at fixed concurrency answers the user-experience question more directly. Publish both when you can: choose hardware from QPS-at-recall-floor, and tune ef from latency-at-recall-floor. Never mix singleton latency points with batch QPS points on one unlabeled line.

Weaviate’s tuning story is exactly this family of curves.

How does Weaviate use recall–speed trade-off curves?

Docs describe ef as the primary search-time balance between thoroughness and speed, and ANN result pages present recall beside QPS and latency across parameter grids. Compression studies plot recall against latency or QPS while sweeping ef or rescoring limits, and they discuss when one curve sits above another (better quality at the same speed, or better speed at the same quality). Configuration tips ask you to decide how high recall must be versus how many queries you need — which is choosing a region on the curve before locking an operating point. When quality changes with query limit under dynamic ef, you are implicitly sliding along the same trade-off without meaning to; fixed-ef curves make that motion visible.

Read the plot with product constraints drawn on top.

How should you interpret and act on the curve?

Mark the minimum acceptable recall and maximum acceptable latency as lines; the feasible segment is your candidate set. Prefer points on or near the Pareto frontier of the measured set — discard dominated interior dots. Watch for a knee where further latency buys little recall; that is often the practical default. Re-draw after quantization, filters, or hardware changes; the curve is workload-specific. Attach a reproducibility manifest and error bars so two overlapping curves are not mistaken for a winner.

A recall-versus-latency trade-off curve is the map of HNSW‘s quality–speed bargain across settings — the antidote to single-point marketing. Next, read “What is thread-count scaling?” to see how concurrency reshapes the latency and QPS you plot, then “What is hardware-environment reporting?” so every curve carries the machine context needed to compare it fairly.