RAG 向量检索怎么调：查询向量、文档向量与召回指标的排查边界

线上知识库问答突然答非所问时，大家第一反应往往是直接换掉背后的大模型。之前我遇到的一次线上故障里，生成侧的模型完全没动，出问题的反而是最容易被忽略的检索环节：查询文本和文档切片被当成同一种任务拿去做编码，直接导致Recall@5指标从0.82跌到了0.54。做RAG调优最先碰的不该是提示词，得先确认「用户输入的查询」和「库里存的待检索文档」，两个内容在向量空间里的表达规则是对齐的。

先把查询向量、文档向量、切块长度和 topK 分开测试验证，再决定是修正编码任务配置、重新做切片，还是调整排序逻辑；别用最终生成答案的好坏，直接替代底层召回环节的指标评估。

先确认基线：问题到底出在召回还是生成

提前整理一批真实用户的提问，每条问题都提前绑定至少一个「必须要被召回」的目标文档片段。不要只靠用户反馈「回答有没有用」来判断效果，因为大模型可能靠自身通用知识蒙对答案，也可能拿到了错误的片段，靠润色能力输出看起来通顺但完全不对的内容。

query_id,expected_chunk,top1,top5,mrr
q-001,policy-17,0,1,0.2
q-002,api-timeout,1,1,1.0
q-003,refund-rule,0,0,0

Recall@K只负责统计「正确的目标片段有没有进入最终的候选集合」；MRR指标还会额外看这个正确片段在候选里的排名位置。要是你测出来Recall@5的数值已经很低，完全没必要先花时间改回答提示词模板。

查询向量和文档向量，任务类型绝对不能混用

普通语义相似度计算和检索场景的编码要求完全不一样。主流Embeddings工具的官方文档里，早就把检索场景拆成了查询和文档两种独立任务，前者对应用户输入的自然问题，后者对应库里存的待检索内容；代码检索、专业问答、事实核验这些细分场景，也都有各自对应的任务适配规则。工程落地的时候，最好把两个不同的编码前缀封装成独立函数，避免离线建索引的脚本和在线服务的接口各写一套逻辑，两边输出的规则对不上。

def make_query(text):
    return f"task: question answering | query: {text}"

def make_document(title, text):
    return f"title: {title} | text: {text}"

更换向量模型或者切换任务类型之后，旧版本的向量不能直接混在新的向量库里做距离比对。至少要用同一批标准测试问题，重建一份影子索引，同时记录清楚用到的模型版本、向量维度、切块器版本和所有过滤条件。

三组对照实验：topK、切块与过滤

把调优过程拆成三组独立实验，每次只改动一个变量。第一组固定切块规则和向量模型不变，分别对比topK=1、5、10三个档位的效果；第二组固定topK数值，分别对比按标题边界切块、按token上限切块两种不同的切片策略；第三组固定前面两项配置，开关产品版本号过滤这类元数据过滤逻辑，观察指标变化。

• Recall@1上涨、Recall@5没变化：说明排序模块的效果提升了，但整体候选集的覆盖度没有改善。
• Recall@5上涨、MRR反而下降：说明候选集数量变多了，但正确片段的排名反而往后掉了，这个时候优先排查重排器的配置。
• 所有指标都同步下跌：优先检查查询改写逻辑、文档切块规则、语料语言混杂、元数据过滤条件这几个环节。

上线前的边界设定与回滚点预留

生产环境不要只存最终返回给用户的答案内容。每次请求最好都落盘保存用户原始query、用到的过滤器规则、topK数值、返回的候选片段ID、每个片段的相似度分数和重排之后的分数，后续抽样复盘的时候，才能区分出问题是「压根没召回正确片段」还是「召回了但排序靠后没被生成环节用到」。新索引上线前先用影子流量做双跑对比，等Recall@5和接口延迟两个指标都同时达标的时候再切全量流量；如果换了新模型之后长尾问题的效果反而变差，要提前保留旧索引作为降级回退方案。

常见问题

topK数值越大，RAG效果一定越准吗？

不一定。候选集变多可能会提升内容覆盖度，但同时也会引入更多噪声，拉长后续生成环节的可用上下文长度，调大topK之后必须同时观察Recall、MRR、接口延迟和最终答案的引用正确率多个维度的表现。

查询和文档必须使用同一个embedding模型吗？

同一个向量空间下的比对结果通常更稳定。如果强行用两个不同的模型分别处理查询和文档，除非对应的产品明确支持跨空间检索能力，否则输出的距离分数没有实际可比性。

为什么两个片段的相似度测出来很高，最后生成的答案仍然错误？

相似度只能代表两段内容语义接近，不能代表这个片段包含完整的事实证据。遇到这类问题要检查对应文档的标题、版本号、时间范围相关的内容，还有关联的相邻片段有没有被错误的切块逻辑切断。

收尾：把检索当成可量化的系统迭代

RAG调优的核心不是找到一个万能的最优topK数值，而是让整个链路的每一层都能对应上明确的校验标准：编码规则是否匹配、候选集是否覆盖全、结果排序是否靠前、切片内容是否完整、生成环节是否引用了正确的证据。把指标和标准测试样例绑定在一起，下次遇到召回效果突然下跌的情况，就不会上来就盲目换大模型了。