知识库到千万级文档，为什么只调向量库参数救不了召回？

先这样答

回答这个问题可以从单路召回的局限性、数据干扰增加以及评测失真三个角度切入。千万级文档规模下，相似内容海量增加导致embedding的区分度被严重稀释，同义问题的干扰项变多。此时排序的负担全部压给向量库内部的参数，比如调整ef_search或扩大top_k，已经超出了参数调整能解决的范围。单路向量检索在这个规模的天花板明显，语义相近但无关的文档会轻易挤占top-k的名额。

要解决千万级文档的召回问题，必须进行分层处理。首先是检索架构的升级，通过路由机制按类目、权限或时间对文档先分区再检索，直接缩小候选空间。同时引入混合检索，用字面匹配通道抓取精确命中。在粗排取出几百篇候选后，接入rerank模型进行精排，最后再截断取top_k。其次是数据侧治理，需要对近重复文档进行合并去重，利用质量分对低质文档降权，并完善类目标签。

在模型和评测层面，当通用embedding区分度不足时，需要更换更强的模型或在领域数据上进行微调。同时，评测口径不能停留在小库时代，必须按规模分层建立评测集，从而准确定位问题出在召回还是排序阶段。总结来说，规模化问题先是架构问题和数据问题，最后才是参数问题。

面试官会怎么追问

• 「RAG中召回的文档彼此冲突时，模型应该相信哪一份？」 可以从元数据维度回答。首先综合考虑文档的权威度、时效性以及与查询的相关度，比如给来源分级，新文档覆盖旧文档。在生成侧，将这些元数据显式传入提示词，让模型在引用时声明来源，而不是让模型自己去猜。
• 「混合检索中字面召回和向量召回的结果怎么融合？」 字面和向量两路召回的结果先进行去重合并，形成一个几百规模的粗排候选集。然后统一交给rerank模型进行打分精排，最后根据精排分数截断取top_k交给大模型。
• 「千万级规模下怎么做近重复文档的合并去重？」 在文档入库前计算相似度。对高度相似的文档，保留质量分高或时效性新的一份，或者将多份文档的内容进行结构化合并，避免语义相近但无关的文档挤占检索名额。

回答的坑

• 认为只要把向量库的top_k参数无脑调大就能解决漏召回问题。正确方向是指出top_k调大会导致语义相近但无关的文档挤占上下文窗口，必须引入重排机制。
• 遇到召回率下降直接去微调embedding模型。正确方向是先做数据去重、低质过滤和检索架构分区，数据侧和架构侧的治理优先级高于单纯微调模型。