一、先把两类参数分开看

向量检索的配置可以分成构建期与查询期两组。构建期参数决定索引以什么结构、什么数据组织方式落盘：是否做压缩或量化、用什么度量方式、图或簇结构的连接度与规模、是否需要训练码本。查询期参数决定单次检索走多宽：候选集大小、是否带回原始向量重排、提前终止的阈值。

两组参数并不独立。构建期一旦把结构固化，查询期只能在它划定的精度天花板下调节。很多“怎么调查询参数召回都上不去”的情况，根因在构建期选型，而不是查询参数没调好。

二、三类配置差异如何影响检索表现

  1. 量化与压缩。把高维浮点向量压缩成更低比特的表示，能明显降低内存占用、提高遍历速度，代价是引入近似误差。误差的典型表现不是“找不到”，而是“近似近邻排序偏移”——真正相关的条目被排到后面甚至被截断。常见应对是保留原始向量做二次重排：先用压缩索引扩大候选集，再用原始向量精算排序。

  2. 相似度度量。度量方式必须与 embedding 模型的训练目标保持一致。若模型是以余弦相似度训练的、向量已归一化，而索引按内积计算且向量未归一化，向量范数会主导排序，出现语义相近但长度不同的条目异常靠前。选度量之前，先确认向量是否归一化，再决定用余弦、内积还是欧氏距离，避免“度量与模型不匹配”被误判为索引效果差。

  3. 索引规模阈值。数据量很小时，暴力精确检索的开销本来就不高，套近似索引反而增加构建成本并损失精度；数据量上去后，图类或簇类索引的收益才显现。因此需要一个按当前数据规模判断“是否值得上近似索引”的阈值，并且在数据增长后重新评估，而不是一次选型长期不变。

三、用固定小样本集做配置对比

工程上可行的做法是把“调参”变成可回归的实验：

· 构造评测集：从真实业务查询中抽 100～500 条，为每条标注相关条目标识，形成固定集合。
· 固定变量：同一份向量、同一份评测集、同一套硬件，每次只改一个配置维度。
· 观测指标：Recall@k 看召回覆盖，MRR 或 NDCG 看相关结果是否靠前，同时记录 P95/P99 延迟、索引内存占用与构建耗时。
· 记录粒度：把“配置组合 + 全部指标”逐行记表，避免凭感觉反复试。
· 结果判读：召回够但排序差，优先查度量一致性与是否加了重排；延迟高，先降查询期候选规模，再评估是否更换压缩方案；构建慢或内存高，可以考虑更激进的压缩比，但必须复查召回损失。

四、与 embedding 模型、数据规模的适配

与模型适配：向量维度直接影响索引内存与遍历成本；度量方式与模型训练目标绑定；更换 embedding 模型相当于更换向量分布，原有索引选型与阈值结论通常不能直接沿用，需要重跑评测。

与规模适配：数据量、查询 QPS 与可接受延迟共同决定压缩比和索引类型的选择；写入频繁的场景还要把索引更新与重建成本算进去，否则线上延迟会被后台构建拖累。

变更流程上也应统一：任何配置改动（包括模型升级）都走同一条小样本评测流程，用指标回归而不是主观感受决定是否上线。

五、边界说明

本文只给出方法层面的框架：参数名称、取值范围、默认值与索引类型支持情况，请以你所使用的向量数据库官方文档为准；在官方资料未明确说明的情况下，不应把某个具体默认值当作通用结论直接套用。