hnswMaxConnections configures the number of connections between nodes in the HNSW graph (larger number = better connectivity but higher memory usage). hnswBeamWidth configures the search depth in the insertion phase (larger number = higher quality graph but slower indexing time).
Both are index-time parameters and need a re-index. The default values are relatively conservative. You could try 32/300 for a start. 10s sounds very slow, even for k=1000. Does the instance have enough memory? On Mon, Jul 7, 2025 at 10:41 AM Guillaume <gjac...@gmail.com> wrote: > Hello, > > I use Solr 9.8 vector search to find fragments of text to which I associate > vectors. > > To do this, I use the “knn Query Parser”. Until now, I used a “Top-K” of > 1000. The ratio between performance and relevance seemed perfect to me. > > > Now, I have just over a million vectors and the latency is becoming > prohibitive (over 10 seconds). So I've started lowering the “Top-K” (since > I don't really need 1,000 results). > > > Although response times are greatly improved by lowering the “Top-K”, I'm > finding that responses are less relevant: Very good answers are no longer > returned with a lower “Top-K”. > > > I assume that this type of “tradeoff” is intrinsically linked to the very > nature of the HNSW algorithm. However, I'd like to test the role of the > “hnswMaxConnections” and “hnswBeamWidth” parameters to see if they can help > me find a good relevance/performance balance. > > > Are these parameters involved in indexing? During search? At both stages? > Just to find out whether it's necessary to re-index all the vectors between > each test. > > > If not, what factors would be most significant in improving performance? It > seems to me that the Solr core doesn't consume much memory. Perhaps it's > possible to allocate more memory to the HNSW algorithm (or to the caches > linked to the vectors)? > > Thanks for your attention, > Guillaume >
