分阶段RAG架构实践：让检索失败变得显式可控

重新思考RAG的流水线设计

传统RAG（检索增强生成）往往把检索当成一个黑盒步骤：一次向量查询，取Top-K结果，直接塞进上下文交给大模型。这种做法简单，但也埋下隐患——当检索质量不佳时，模型会被迫在薄弱甚至错误的上下文上生成内容，产生幻觉却毫无预警。

一位开发者在Reddit上分享了他的实验性RAG架构，核心思路是把检索、重排、过滤和上下文构建拆分成独立阶段，而不是全部压缩进单一检索步骤。这套设计的关键价值在于：让检索失败变得显式（explicit）。

Reddit原帖：分阶段RAG架构讨论

完整的分阶段流水线

该项目（开源于 GitHub 的 mini-Rag）采用了一条职责明确的处理链路：

BGE-M3 → Dense + Sparse Embeddings → Qdrant
→ Hybrid Retrieval / RRF → BGE Reranker
→ Relevance Gate → Context Quality Filter
→ Context Builder → Local LLM

每个环节承担单一职责，下面拆解几个关键组件。

混合检索与RRF融合

流水线起点是 BGE-M3 模型，同时生成稠密（Dense）向量和稀疏（Sparse）向量，存入 Qdrant 向量数据库。稠密向量擅长捕捉语义相似度，稀疏向量则保留了关键词精确匹配的能力。

通过混合检索（Hybrid Retrieval）与 RRF（Reciprocal Rank Fusion，倒数排名融合） 将两类结果合并，兼顾语义理解与字面命中。这一组合在实际场景中往往比单纯的稠密检索更稳健，尤其面对专有名词、代码片段或精确术语时。

RRF（Reciprocal Rank Fusion）是一种无需额外参数训练的排名融合算法，其核心公式为：对每个候选文档，将其在各个排名列表中的名次取倒数（通常加一个平滑常数k，默认60）后求和，得分越高代表综合排名越靠前。这种方法的优势在于对极端排名不敏感——排名第1的文档得分约为1/61，第10的文档约为1/71，分差相对平缓，因此不会因为某一路检索的异常高分主导最终结果。相比直接对相似度分数加权平均，RRF无需校准不同检索方式输出的分数量纲，工程实现简洁且鲁棒性强。在密集向量检索与稀疏向量检索的分数分布差异较大时，这一特性尤为重要。

重排与相关性门控

初步检索的结果会经过 BGE Reranker 重排序，用更精细的交叉编码器模型对候选片段重新打分。重排之后是这套架构最具特色的一环——Relevance Gate（相关性门控）。

作者的核心理念在此体现：如果重排器没有找到足够相关的片段，系统会直接返回「信息不足」的响应，而不是把薄弱的上下文硬塞给模型。这相当于给RAG装上了一道安全阀，宁可诚实地说「我不知道」，也不制造看似合理实则编造的答案。

BGE Reranker 使用的交叉编码器（Cross-Encoder）与初步检索阶段的双塔编码器（Bi-Encoder）在架构上有根本区别：双塔模型分别独立编码查询和文档再计算相似度，速度快但精度受限；交叉编码器将查询与文档拼接后一起输入，允许两者在注意力层充分交互，得分更精准但计算成本也更高。正是这种精度差异，使得Reranker适合在初步检索缩小候选集之后进行二次精排，而非直接对全量文档使用。相关性门控的阈值通常基于Reranker输出的归一化分数设定，需要在准确率与召回率之间权衡调整，这也是作者在帖子中着重讨论的工程难点之一。

为什么「显式失败」如此重要

在生产环境中，RAG最危险的失败模式不是「答不出来」，而是「用错误的上下文自信地答错」。后者对用户的误导性远大于前者。

把检索失败显式化，意味着：

可观测性提升：门控和质量过滤的判定结果可以被记录、监控，帮助定位知识库覆盖的盲区；
信任度增强：面向用户的系统能明确区分「基于文档回答」和「无法回答」，避免幻觉污染；
责任边界清晰：每个阶段独立后，问题排查不再是对整个黑盒的猜测，而能精准定位到检索、重排还是上下文构建环节。

Context Quality Filter 和 Context Builder 进一步保障了最终喂给大模型的上下文质量——前者剔除低质量片段，后者负责组织上下文的结构。

本地化部署的选择

该架构在生成端选用了 DeepSeek^广告 R1 7B，通过 Ollama 在本地运行。这一选择体现了对隐私和成本的考量：整条流水线（从嵌入、向量库到大模型）都可以在本地闭环运行，无需依赖外部API。

对于企业内部知识库、代码检索或对数据敏感的场景，这种全本地方案有明显吸引力。7B规模的模型配合高质量的上下文筛选，也在一定程度上弥补了小模型推理能力的不足——毕竟上下文质量越高，模型编造的空间就越小。

Ollama 是一个专为本地运行大语言模型设计的开源工具，通过封装 llama.cpp 推理引擎，让用户能以单条命令拉取并运行量化后的开源模型（如 LLaMA、Mistral、DeepSeek 等），无需手动处理模型权重格式转换和底层推理配置。对于RAG场景，Ollama 还提供了兼容 OpenAI API 格式的本地端点，使现有基于 API 的代码可以几乎零改动地切换到本地推理。DeepSeek R1 7B 属于推理增强型小模型，其在数学和逻辑推理任务上经过专项训练，在参数规模受限的情况下对结构化上下文的利用效率相对较高，与分阶段RAG对上下文质量的严格筛选形成配合。

值得讨论的架构边界问题

作者在帖子中抛出了一个开放性问题，也是RAG工程中的经典难题：如何划分检索 → 重排 → 上下文准备 → 生成之间的边界？

这个问题没有标准答案。过度拆分会增加延迟和系统复杂度；拆分不足又会让失败模式变得不透明。相关性门控的阈值设置尤其微妙——阈值过高会频繁触发「信息不足」，影响可用性；过低则失去了安全阀的意义。

对于正在搭建生产级RAG系统的团队来说，这套分阶段设计提供了一个清晰的参考框架：把「单次检索」的黑盒，拆解成若干可测量、可调优、可失败的独立环节。检索质量的可控性，往往比单纯堆叠更强的模型更能决定RAG系统的可靠性。