如何平衡向量检索的召回率与延迟?

向量检索的召回率与延迟并不是“二选一”，而是要先明确系统允许在哪个环节花时间。客服知识库这类场景里，漏掉正确证据的代价通常高于多返回几个候选；但若每次查询都做高成本的全库搜索，响应体验又会迅速恶化。合理目标不是追求单项极值，而是在可接受延迟内稳定找到足够好的候选。

最先应检查的往往不是索引参数，而是数据与分块。片段切得过短，语义容易断裂，检索虽然看似更精确，却可能因上下文缺失而漏召回；片段过长则会把无关内容一并带入候选，增加后续计算和噪声。按语义边界组织文本，并针对核心问题集比较不同分块方式，才能判断召回下降究竟来自索引，还是来自知识本身的表达不完整。

索引层面需要把“候选规模”和“搜索成本”分开看。HNSW更适合低延迟检索，IVF+PQ更侧重节省空间，但后者需要通过参数调节来避免过度牺牲召回。任何参数调整都不应凭感觉：在同一批已知问题上，同时记录召回率、MRR与平均响应时延，观察曲线变化，再确定可上线的区间。

更稳妥的做法是分层检索。先利用关键词或元数据过滤缩小范围，再执行向量检索；向量阶段优先保证候选集合的覆盖度，随后交给cross-encoder或小型双塔进行重排。这样不必让高成本排序参与全量搜索，也避免只依赖初始向量相似度决定最终结果。

缓存同样是平衡延迟的有效手段。高频、重复的问题可以复用已有检索结果，把更完整的检索预算留给长尾查询。与此同时，嵌入模型、索引参数和文档快照应保持版本化；一旦某次优化让召回或延迟异常，就能定位变化来源，而不是在不断叠加的配置中猜测问题。