RAG 漏召怎么优化？

先这样答

解决RAG漏召需要按顺序从查询改写、入库增强、混合检索和重排兜底四个环节入手。第一步做查询改写补充语义。用户提问经常包含指代不明或口语化的词汇。我们用模型做指代补全。系统还要把口语翻译成专业术语。第二步做假设性问题增强。文档入库时，我们为每个分块生成可能的提问。系统把这些生成的提问和原分块一起存入数据库。这种做法能缩小用户提问和文档片段之间的语义差距。

第三步引入混合检索。单纯的向量检索经常漏掉包含特定专有名词的文档。我们采用向量检索加上BM25算法。精确词匹配直接依靠BM25的关键词检索能力。第四步是扩大召回数量后靠重排兜住精度。前面三种手段会召回大量粗排结果。我们调大召回阶段的返回数量。系统接着引入专门的重排模型做精排。重排模型过滤掉不相关的文档。它负责保证最终送入大模型的上下文质量。

每个优化手段上线前都要验证有效性。工程师不能凭感觉做决定。团队需要构建一个固定的评测集。我们在评测集上跑各个优化方案。大家直接对比召回率指标。我们只把召回率上升的策略合入主线。

面试官会怎么追问

• 「口语转术语的具体实现逻辑是什么？」 我们调用语言模型处理用户原始输入。模型根据预设的业务词典执行替换。它把用户的口头表达改成文档里实际使用的标准词汇。改写后的查询再去执行后续的检索。

• 「为什么扩大召回数量后必须接重排？」 混合检索和假设性问题增强会带回很多相关度偏低的文档。如果不做精排，系统会直接把这些文档塞给生成模型。这会导致上下文超载。重排模型能对这些粗排结果做交叉计算。它负责准确剔除干扰项。

• 「怎么证明向量加BM25比纯向量检索效果好？」 我们拿固定的评测集做消融实验。系统先跑一遍纯向量检索并记录召回率。系统再跑一遍向量加BM25的混合检索。我们对比两次的召回率指标变化。

回答的坑

只罗列各种优化手段，不提在固定评测集上对比召回率的验证方法。 混淆粗排和精排的定位，没讲清楚精确词匹配要靠BM25来做。