向量检索的召回率和延迟怎么平衡？向量量化有什么代价？
面试怎么回答
大规模向量检索用的是近似最近邻索引，本质是用一点召回率换延迟和成本。可调的有索引参数，比如 HNSW 的 M 和 efSearch、IVF 的 nlist 和 nprobe，越大召回越高越慢；还有量化，标量量化把 float32 压到 int8 内存降到四分之一、损失小，乘积量化和二值量化压缩更高损失更大；有的模型还支持截断降维。量化的补救是粗排加精排，先用量化向量召回较多候选，再用原始向量重新算距离；也可以用磁盘索引降内存。决策上先定召回和延迟的目标，用精确检索生成标准答案，测不同方案的召回、延迟、内存，选满足约束成本最低的，同时看最终回答准确率而不只是向量召回率。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
向量库从 100 万条涨到 1 亿条，查询延迟从 20 毫秒涨到 500 毫秒，内存也不够了。调参数能变快，但召回率掉了。面试官问这题，想看你是否理解近似检索的本质是用准确率换速度和成本，以及有哪些可以调的旋钮。
先理解：为什么是近似检索
精确的向量检索要和每一条向量算距离，1 亿条向量每次查询都全量计算，延迟和算力都扛不住。所以生产中用近似最近邻（ANN）索引，只计算一部分候选，代价是可能漏掉真正最相似的结果。
衡量指标：召回率（近似结果和精确结果的重合比例，比如 Recall@10）、延迟（P99）、吞吐（QPS）、内存。
可以调的旋钮
索引参数
- HNSW：
M（每个节点的连接数）越大，图越密，召回越高，内存越大、构建越慢；efSearch（查询时的候选列表大小）越大召回越高、延迟越高； - IVF：
nlist（聚类中心数）和nprobe（查询时搜索多少个聚类），nprobe越大召回越高、越慢。
向量量化（压缩）
- 标量量化（SQ）：把每个维度的 float32 压成 int8，内存降为四分之一左右，精度损失通常较小；
- 乘积量化（PQ）：把向量切成多段，每段用一个码本编号表示，压缩比可以很高，但精度损失更明显；
- 二值量化：每个维度只用 1 位，压缩比最高，损失最大，通常配合重排使用。
降维：有些 Embedding 模型支持截断成更短的维度（比如从 1024 维用前 256 维），存储和计算都会下降。
量化的代价和补救
- 召回下降：压缩后的距离计算不精确；
- 补救方法：粗排 + 精排：先用量化后的向量快速召回较多候选（比如 Top 100），再用原始精度的向量对这些候选重新计算距离排序（Top 10）。原始向量可以放在磁盘上，只读少量；
- 也可以用 DiskANN 这类基于磁盘的索引，把大部分数据放在 SSD 上，降低内存成本。
怎么做决定
- 先确定业务能接受的召回率和延迟，比如 Recall@10 不低于 95%、P99 不超过 100 毫秒；
- 准备一份查询样本，用精确检索算出标准答案；
- 在不同参数和量化方案下测召回、延迟、内存，画出取舍曲线；
- 选满足约束且成本最低的方案。
另外要记住：向量召回率高不等于业务效果好。RAG 里还要看最终回答的准确率，有时混合检索加重排带来的提升，比把向量召回从 95% 调到 99% 更大。