mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-30 00:18:32 +02:00
Fix ANN precision tutorial: tune hnsw_ef, not build-time params
The Search Quality tab uses the Query Points API, so it can only tune search-time SearchParams. Replace the m/ef_construct walkthrough with hnsw_ef and link to the Essentials course for the build-time trade-offs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.7
parent
ac9f77d9f3
commit
b7b2865e14
+6
-11
@@ -11,8 +11,7 @@ weight: 5
|
||||
| Time: 15 min | Level: Beginner | | |
|
||||
|--------------|---------------------|--|----|
|
||||
|
||||
This tutorial focuses on **ANN precision**: how closely approximate nearest-neighbor (ANN) search matches exact kNN search.
|
||||
To measure ANN precision, you compare Qdrant's approximate top-k against the exact kNN top-k using `precision@k`, then tune HNSW parameters to trade memory and build time for higher precision.
|
||||
This tutorial focuses on **ANN precision**: how closely approximate nearest-neighbor (ANN) search matches exact kNN search, measured with `precision@k`.
|
||||
|
||||
**Prerequisites.** A Qdrant collection populated with your documents as points (vectors + optional payload).
|
||||
|
||||
@@ -33,23 +32,19 @@ Qdrant's Web UI includes a Search Quality tab that measures the gap between appr
|
||||
|
||||

|
||||
|
||||
The tab reports average **precision@k** (1.0 = perfect overlap; 0.95+ is typical for well-tuned HNSW). HNSW has tunable parameters that trade memory and index build time for higher precision.
|
||||
The tab reports average **precision@k** (1.0 = perfect overlap; 0.95+ is typical for well-tuned HNSW).
|
||||
|
||||
## Tuning the HNSW Parameters
|
||||
## Tuning Search Precision
|
||||
|
||||
HNSW is a hierarchical graph where each node has a set of links to other nodes. The `m` parameter controls the number of edges per node: higher `m` means higher precision at the cost of more memory. The `ef_construct` parameter controls how many neighbors are considered during index building: higher `ef_construct` means higher precision at the cost of longer indexing time. The defaults are `m=16` and `ef_construct=100`.
|
||||
|
||||
For the full list of HNSW parameters, including on-disk storage and precision/memory trade-offs, see [Optimize Performance](/documentation/ops-optimization/optimize/).
|
||||
|
||||
Toggle **advanced mode** in the Search Quality tab to tune these parameters inline. To see the effect, try raising `m` and `ef_construct` (for example, to 32 and 200), then run the evaluation again.
|
||||
Toggle **advanced mode** in the Search Quality tab to tune search-time parameters inline. The main one is `hnsw_ef`: the number of candidates evaluated during a search. Raising it explores more of the graph, improving precision at the cost of higher query latency. To see the effect, raise `hnsw_ef` (for example, to 256) and run the evaluation again.
|
||||
|
||||

|
||||
|
||||
Precision should increase at the cost of higher build time and memory.
|
||||
Precision should increase at the cost of higher query latency.
|
||||
|
||||

|
||||
|
||||
Tune until the balance between precision and cost matches your targets.
|
||||
If `hnsw_ef` alone does not get you to your precision target, the build-time parameters `m` and `ef_construct` set the ceiling on how precise approximate search can be. Changing them requires rebuilding the HNSW index. For the trade-offs and how to choose values, see [HNSW Indexing Fundamentals](/course/essentials/day-2/what-is-hnsw/) in the Qdrant Essentials course.
|
||||
|
||||
## Automate in CI with Python
|
||||
|
||||
|
||||
Reference in New Issue
Block a user