Vector index compression reduces RAM by storing lower-precision representations, but the resulting distance distortion can lower nearest-neighbor recall.
A home RAG index may fit comfortably at one hundred thousand chunks and become memory-bound after years of documents, photos, and transcripts. Quantization can keep more vectors resident, yet search quality depends on whether compressed distances preserve the same candidate ordering as full precision. The result changes with embedding distribution, compression ratio, index type, candidate breadth, and whether original vectors remain available for rescoring.
Compression Shrinks the Vector Payload, Not Every Index Cost
A vector index uses memory for the embedding values, graph or partition structures, identifiers, metadata, allocator overhead, and temporary query buffers. Compression primarily reduces the embedding representation. HNSW links and metadata may remain similar, so total RAM savings can be smaller than the vector compression ratio suggests.
high-dimensional vectors are expensive because each dimension stored as a full-precision value contributes to memory and distance-computation cost. Replacing those values with compact codes reduces the resident payload and can improve cache efficiency.
The practical saving therefore depends on index composition. High-dimensional float vectors usually offer a large target; small vectors with heavy graph connectivity may save less proportionally. Measure process resident memory and index files before and after compression rather than multiplying raw vector bytes by document count.
Quantization Introduces Distance Distortion
Scalar quantization maps each dimension to a smaller numeric range, while product quantization divides a vector into subspaces and stores codebook choices. Both replace exact coordinates with approximations. Query distance is then computed against reconstructed values or codebook distances rather than the original float vector.
Experiments with product quantization evaluate compression by measuring reconstructed-distance distortion and recall. More compact codes can lower latency or memory use, but they also make nearby candidates harder to order correctly when their true distances are close.
Recall falls when a relevant neighbor is pushed below the candidate cutoff, not simply because every distance is slightly wrong. Queries with a clear margin between relevant and irrelevant chunks may survive heavy compression; dense semantic neighborhoods with many near-ties are more sensitive.
Candidate Expansion and Rescoring Can Recover Recall
A two-stage search uses compressed vectors to find a broad shortlist, then recomputes distances with higher-precision vectors for those candidates. Oversampling gives relevant items more chances to survive the approximate first stage; rescoring restores ordering where compact codes blurred small distance differences.
higher compression levels typically reduce recall, while oversampling and rescoring can improve accuracy. The recovery consumes additional reads, memory, and query work, so compression shifts resources rather than eliminating the quality cost.
Keeping full vectors on disk can preserve a small RAM footprint but add storage latency during reranking. Keeping them in RAM improves latency but reduces the memory benefit. The useful configuration depends on whether the home server is limited by memory capacity, storage IOPS, or response-time targets.
Recall Must Be Measured on the Local Retrieval Task
Build a reference set by running exact or high-precision search for representative queries, then compare whether compressed search returns the same relevant neighbors within top-k. Include paraphrases, proper names, near-duplicate documents, rare terms, and queries whose answer depends on a small evidence distinction.
This complements retrieval grounding confidence: neighbor similarity and answer support are related but not identical. Measure Recall@k against the search baseline and also verify whether lost or reordered chunks change the evidence available to the generator.
There is no universal winner between maximum compression and maximum precision. Increase compression until RAM, latency, and task recall reach the desired balance, then retest after embedding-model or corpus changes. A configuration that works for broad photo similarity may be too lossy for technical document retrieval with many semantically adjacent passages.
Tech & AI HUB
More to Read

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

