What happened
Milvus published a guide to choosing among HNSW, HNSW_SQ, HNSW_PQ and HNSW_PRQ. Each uses the same hierarchical graph-search framework, but stores and compares vectors differently. The guide says those choices affect recall, query performance, memory use and index-build cost. It frames selection around the retrieval stage: an index that returns results directly has different requirements from one that supplies candidates to a downstream reranker. Memory constraints and index rebuild frequency also matter.
The tested baseline, HNSW, keeps full-precision FP32 vectors. HNSW_SQ uses scalar quantization, reducing precision dimension by dimension: the tested formats are SQ8, SQ6 and SQ4U. The article notes SQ4U is available in Milvus 2.6.8 and later, and uses 4-bit unsigned values with a shared global range, making it a candidate for normalized vectors or datasets whose dimensions have similar value distributions. Product quantization (PQ) divides vectors into subvectors represented by learned codebook indices. For 768-dimensional vectors, the test uses m=96 and nbits=8, yielding a theoretical 96-byte code per vector. Product residual quantization (PRQ) adds stages to encode approximation error; its tested m=96, nbits=8 and nrq=2 configuration produces a 192-byte code. These are payload figures, not total index sizes: graph data, codebooks, metadata and refinement data add overhead.
The guide describes refinement as a reranking step for quantized indexes. The base index retrieves candidates, then Milvus recomputes their distances using the chosen refine_type and returns the best TopK. The refine_k parameter controls candidate count: with TopK=100 and refine_k=4, the search requests up to 400 candidates for reranking. A larger candidate set may give the reranker more chances to recover neighbors, but adds retrieval, calculation and memory-access work. It cannot recover a neighbor absent from the candidate set. The guide distinguishes refine_k from ef: ef widens graph search, while refine_k increases the candidates sent to refinement.
The benchmark used Milvus 2.6.17 in Docker Standalone, PyMilvus 2.6.15, and VectorDBBench’s Cohere 1M dataset: one million 768-dimensional vectors and 1,000 queries. It measured cosine retrieval at TopK=100, with ef values of 128, 256 and 512; refinement sweeps used refine_k values of 1, 2, 4 and 8. Graph parameters were fixed at M=16 and efConstruction=200 rather than independently optimized for each representation. The test environment was a 16-vCPU KVM VM with 64 GB RAM, and client and server shared that machine. The article defines recall against cosine ground-truth top-100 results; it also measured latency, concurrent throughput, memory, index artifacts and build time. The supplied excerpt does not include the resulting measurements.
What the archive adds
This is a new Milvus index-comparison event, following the related SVS in Milvus: Reshaping the Recall–Memory–Speed Trade-off, which covered a different vector-search approach and its claimed operating trade-offs. The current guide adds a comparison framework for HNSW representations and refinement; it is not evidence that one index family is categorically superior.
Trend signal
No supplied SITE_PATTERNS thesis directly fits this vector-index configuration comparison. It is a practical systems evaluation, but does not establish a broader pattern about agent design, protocols, or verification.
Why it matters
For teams building retrieval into AI applications, vector representation is not an isolated memory knob. Compression can change distances and neighbor selection during both graph construction and search, so a smaller theoretical code does not guarantee acceptable recall or faster queries. Refinement shifts some of the cost into retaining a higher-precision representation and reranking a larger candidate set. That can be useful when a compact base index is attractive but recall needs recovery, yet it also changes the complete memory and latency budget.
The guide’s most transferable contribution is its evaluation discipline: distinguish serial latency from concurrent P95, define memory measurements carefully, and avoid comparing unlike compression budgets as if they were equivalent. The 96-byte PQ code and 192-byte PRQ code, for example, do not represent equal storage budgets. Teams should test against their own dataset, recall target, concurrency and rebuild cadence. The supplied material does not show which tested configuration met which target, so it is a framework for local evaluation rather than a ready-made deployment choice.
Limits and uncertainty
The available source material describes the benchmark design and configurations but cuts off before the comparison results. It therefore does not establish which index had the best recall, throughput, latency, memory consumption or build time, nor whether refinement produced a favorable trade-off. The measurements used one dataset, one virtualized machine and fixed graph parameters; client and server competed for CPU, and network latency between hosts was excluded. The guide itself warns that its memory metric includes container allocation, metadata and page-cache or memory-mapping effects, rather than strict process RSS. Its results should not be used directly to size another deployment.
Reader takeaway
Treat the guide as a map for a controlled retrieval experiment, not as proof that compression is a free win. Compare variants at the recall target and memory budget your application actually needs, account for refinement storage and candidate costs, and keep the workload and measurement definitions consistent. The supplied excerpt supports those cautions, but not a winner among the tested indexes.