The HNSW index is configured through three primary parameters: M, efConstruction, and efSearch. Each parameter influences the balance between index size, build time, query speed, and recall. Here’s how they work:
1. M (Maximum Connections per Node)
M determines the maximum number of edges each node can have in the graph layers. A higher M increases the density of connections, which improves search efficiency (fewer hops to traverse the graph) and recall (better chance of finding true neighbors). However, larger M values directly increase index size, as more edges are stored, and raise build time due to the computational cost of connecting each node to more neighbors. For example, setting M=32 instead of M=16 might double the index size but reduce query latency by 20–30% in some scenarios. The trade-off here is between memory/construction cost and search performance.
2. efConstruction (Construction-Time Search Depth)
efConstruction controls the size of the candidate list used during index construction. A higher efConstruction (e.g., 200 vs. 100) allows the algorithm to explore more potential neighbors when inserting nodes, leading to a better-optimized graph structure. This improves recall and query speed because the graph is more navigable. However, increasing efConstruction significantly extends build time. For instance, doubling efConstruction might quadruple construction time in some cases, as distance calculations grow quadratically. The trade-off is between build time and the quality of the resulting graph.
3. efSearch (Query-Time Search Depth)
efSearch determines the size of the priority queue maintained during search queries. A higher efSearch (e.g., 200 vs. 50) increases recall by considering more candidates, reducing the chance of missing true neighbors. However, this comes at the cost of slower query speeds due to additional distance computations. For example, increasing efSearch from 100 to 400 might improve recall from 90% to 98% but double query latency. This parameter directly balances recall against query speed, allowing users to prioritize accuracy or responsiveness based on their use case.
Practical Example
In a recommendation system requiring high recall, you might set M=24, efConstruction=400, and efSearch=200. This configuration would yield a large, well-optimized index with slower build times but accurate results. Conversely, for real-time applications, M=12, efConstruction=100, and efSearch=50 would reduce memory usage and latency at the cost of lower recall. Adjusting these parameters requires benchmarking on representative data to find the optimal balance for your workload.