在实际的 RAG 检索增强生成问答系统中检索质量往往比 Prompt 技巧更早决定答案上限。很多项目第一次跑通时用的是“文档切块 向量化 向量数据库召回 拼接 Prompt 让大模型回答”这条链路。演示环境里效果不错一旦换成真实知识库问题立刻出现用户输入一个产品型号向量检索返回一堆语义类似但型号不对的文档用户换一种更自然的说法提问关键词匹配又召回不到内容。这是因为单路检索有边界稀疏向量检索擅长精确关键词稠密向量检索擅长语义相似。要让问答系统更稳通常把这两路结果合并到一起而 RRF 倒数排名融合算法是实践中很常见的合并方式。下面从概念、环境、代码、验证、排错五个方面完整梳理一套 RAG 检索增强生成问答系统的落地思路。文章会提供可直接运行的 Python 示例包括 BM25 稀疏检索、Embedding 稠密检索、RRF 融合、FastAPI 服务和本地大模型调用接口。适合正在做知识库问答、RAG 项目原型验证或者想把检索层做扎实的开发者。1. 先倒推问题为什么 RAG 需要多路检索1.1 从“幻觉”说起理解 RAG 为什么多一个检索器大模型在训练时学到的知识有时间截止点也无法覆盖企业内部的私有文档。用户提问时模型如果只凭参数里的记忆回答就容易出现知识点过期、编造细节、引用了不存在的来源等情况。RAG 的思路不是让模型记住更多知识而是在回答前先做一次检索把相关资料作为临时上下文交给模型再让模型基于资料生成答案。RAG 全称是 Retrieval-Augmented Generation中文叫检索增强生成。它通常分成四个阶段文档解析和切块把知识库拆成适合检索的文本单元。检索从文本单元中召回与用户问题相关的候选内容。增强把召回结果拼接到 Prompt 中附加上下文和生成规则。生成大模型基于上下文输出答案并尽量引用来源。这里的核心矛盾是检索结果好不好直接决定大模型看到什么。如果召回的前三名文档本身就离题Prompt 写得再好大模型也很难给出准确回答。所以在 RAG 项目里检索器的质量比生成环节的调参更值得投入。1.2 稠密向量检索的边界不是“有没有用”而是“精确匹配”稠密向量检索是目前 RAG 项目里最常见的一路检索。它用 Embedding 模型把文本编码成固定长度的连续向量再用余弦相似度或内积找最相似的文本。它对同义改写、语义相近但关键词不同的查询更友好。例如用户说“怎么处理发票金额填错”文档里写的是“发票金额录入错误如何处理”查询和文档没有完全相同的关键词但语义接近稠密检索能把它找出来。不过稠密向量检索在精确匹配场景下并不稳定。产品型号、合同编号、身份证号、人名、案号这类内容本质上是“精确字符串”而不是“语义概念”。向量模型在编码这类字符串时很容易把相近但不相同的编号推向相邻区域。结果就是用户输入“HT-2024-0001”检索系统把“HT-2024-0002”也当成高度相似内容排在前面。另一个问题是不同 Embedding 模型产出的分数区间差异很大。某个模型的余弦相似度 0.78 可能已经很高另一个模型的 0.78 可能只是普通水平。如果直接拿这些分数和 BM25 分数做加权求和需要先做大量分数校准。1.3 混合检索与 RRF 融合的整体定位混合检索的思路很直接两路检索各自解决不同的问题最后再合成一个候选列表。常见组合是 BM25 稀疏检索加上稠密向量检索合并策略可以用 RRF也可以用学习出来的 reranker。整体流程可以按下面这条链路理解用户问题 - 稀疏检索BM25 关键词精确匹配 - 稠密检索Embedding 语义相似召回 - RRF 倒数排名融合 - 取 TopK 文档 - 拼接 Prompt - 大模型生成答案RRF 不直接比较两路分数而是把每个文档在各自检索结果里的“排名”作为唯一的融合依据。这样天然避开了 BM25 分数和向量余弦分数不可比的问题。下面从代码开始逐步搭建这条链路。2. 准备环境与可复现示例数据2.1 Python 环境与依赖推荐使用 Python 3.10 或更高版本。先创建虚拟环境再安装依赖。下面命令里的包名和版本是示例实际项目落地