Product quantization accelerates large private vector collections by splitting embeddings into subspaces and replacing each subvector with a compact learned centroid code.
This is a specific mechanism inside the broader vector-quantization family. Instead of reducing every coordinate independently, PQ learns several smaller codebooks and represents one high-dimensional embedding as a sequence of code IDs. A home search server can keep far more of those codes in memory and estimate query distances from precomputed tables, which reduces both stored vector bytes and the amount of full-precision arithmetic needed during a broad candidate scan.
PQ Divides One High-Dimensional Embedding Into Several Subvectors
Suppose an embedding has dimension `d`. PQ chooses `M` subquantizers and partitions the coordinates into `M` lower-dimensional blocks, so each block can be modeled separately.
The number of subquantizers determines how many lower-dimensional blocks the original embedding is divided into and therefore how many code IDs form one PQ representation.
This factorization is what gives product quantization its name: the full approximation is assembled from choices made independently in several subspaces rather than from one enormous codebook over the complete vector. The subspaces must divide the vector dimensions in a compatible way. Their size and number affect compression, codebook training cost, distance accuracy, and how well the data distribution fits the factorized representation.
Each Subspace Learns a Codebook of Representative Centroids
PQ is normally trained on a representative sample of the collection. For every subspace, clustering finds centroid vectors that stand in for groups of similar subvectors.
A typical product quantizer uses k-means to learn centroids within each subspace, minimizing the approximation error between training subvectors and their assigned representatives.
After training, the database no longer needs to store all original coordinates in the compact search code. It only needs the identifier of the nearest centroid from each subspace.
If the training sample poorly represents future household documents, the learned centroids can approximate later vectors badly. Codebook quality is therefore an implementation boundary, not a one-time detail that can be ignored.
The Stored Vector Becomes a Short Sequence of Code IDs
For each subvector, the encoder finds the nearest centroid and stores that centroid's index. Concatenating the `M` indexes forms the PQ code for the complete embedding.
Storing m subvector codes with configurable bits replaces a long float array with a short sequence of centroid identifiers plus shared codebooks.
For example, eight bits per subquantizer can represent 256 centroid choices in that subspace. The total vector code then grows with the number of subquantizers rather than with 32-bit precision for every original dimension. Codebooks and index overhead still consume memory, so the complete collection is larger than the code bytes alone. The savings become most meaningful when the vector count is large enough for those shared codebooks to be amortized.
A Query Builds Distance Lookup Tables for Every Subspace
When a query arrives, the system splits it into the same subspaces and computes its distance to every centroid in each codebook. Those values form small lookup tables.
A query-to-centroid distance table precomputes the query distance to each centroid in every subspace, so candidate distances can be assembled from small lookups instead of full-vector arithmetic.
To estimate the distance to a stored database vector, search no longer reconstructs every full coordinate. It reads each code ID, looks up the corresponding subspace distance, and sums those values.
This table-driven path is often called asymmetric distance computation because the query can remain high precision while the database vectors are represented by quantized codes.
Compact Codes Improve Cache Locality as Collections Grow
Large vector scans are frequently limited by moving candidate data through memory rather than by the mathematical complexity of one distance operation.
Short codes let more candidates fit in CPU caches and reduce bandwidth per comparison.
The compressed distance-computation path can be accelerated with SIMD-friendly table lookups because product-quantized search repeatedly reads compact codes and accumulates subspace distances.
On a private home collection, that can make the difference between an index whose active search representation stays in RAM and one that continually competes with the local LLM, database, and filesystem cache.
The benefit becomes smaller when the collection is tiny, when metadata filtering reduces every query to a handful of vectors, or when another index layer dominates latency.
PQ Usually Trades Some Recall for Compression and Speed
Centroid codes approximate the original subvectors, so two candidates can change order when their true distances are close. More aggressive compression generally leaves less information to distinguish them.
Treating product quantization as lossy compression makes the boundary clear: smaller codes reduce vector memory, but quantization error can change the ordering of close neighbors.
Increasing the number of subquantizers or bits can preserve more detail but enlarges each code and the lookup structures. Smaller codes save more memory but raise the chance of quantization error. The useful configuration is corpus-specific. Closely related manuals, duplicated document versions, and fine-grained code search can require more precision than broad semantic retrieval over diverse household notes.
A Compact First Pass Can Be Followed by Full-Precision Rescoring
PQ does not require the final answer to trust the compressed distance order blindly. A system can retrieve a wider candidate set with PQ and then rescore only those candidates using original vectors stored elsewhere.
Within semantic vector retrieval, PQ changes the representation used for candidate comparison; provenance, metadata filtering, reranking, and RAG still operate around that vector stage.
This two-stage approach spends memory and compute asymmetrically: compressed codes handle the large candidate space, while exact vectors are touched only for a small shortlist.
Product quantization accelerates a private collection when compact codes materially reduce the working set and distance traffic without lowering measured recall below the evidence quality the local RAG system requires.
Tech & AI HUB
More to Read

Runtime State vs Persistent State in Home Assistant: What Must Survive Restart?
Home Assistant does not persist every live value; config, registries, selected restored states, history, and deployment data play different restart roles.

How Does Home Assistant Authenticate Local and Remote Sessions?
Local and remote Home Assistant sessions use the same server-side identity model; remote access changes the route and TLS boundary, not the core token...

Why Can Home Assistant History Queries Slow as Recorder Data Grows?
Recorder growth can raise History query cost when the requested range touches more rows, cache misses increase, or storage and index work become slower.

