embedding-index-tunerlisted

A vector index has knobs, and the defaults are a guess about a workload that isn't yours. HNSW graph parameters and quantization each trade **recall** against **latency** and **memory** — and the recall loss is invisible unless you measure it. This skill replaces "enable quantization and hope" with a sweep: hold the data and queries fixed, vary the index settings, and pick the configuration that hits your recall target at the lowest cost. ## When to use this skill - Vector search is too slow (p95 latency over budget) or uses too much memory, and you want to know which parameter to move. - Recall dropped after you enabled quantization or lowered an HNSW search parameter, and you need to find a safe setting. - Standing up a new index and you want defensible parameters instead of copy-pasted defaults. - Validating that an index still meets its recall target after a corpus or embedding-model change. ## Instructions 1. **Fix the ground truth.** Use a labeled query set (20–50+ queries with known-relevant document IDs). For an approximate index, the gold standard is the **exact** (brute-force / flat) nearest neighbours for each query — compute them once so you can measure recall *of the approximate index against exact search*, not just against human labels. 2. **State the budget.** Write down the recall target (e.g. recall@10 ≥ 0.95), the p95 latency ceiling, and the memory/storage ceiling. The sweep optimizes cost subject to these. 3. **Sweep HNSW build/search parameters.** Var