RAG 的完整链路是什么？

3 分钟速学卡

30 秒口述： 我会把 RAG（Retrieval-Augmented Generation）拆成离线建库和在线问答两条链路：离线完成清洗、切片、Embedding 与索引，在线完成 Query 改写、权限过滤、候选召回、重排、上下文拼装和生成。它的核心不是“接一个向量库”，而是让正确证据在正确权限和版本下进入模型上下文，并保留可引用、可评测的链路证据。它适合知识更新快、需要来源依据的问答；实时业务真值仍应查询受控 SQL 或 API，并通过分阶段指标验证。

• 本质： RAG 是让可验证证据经过建库、检索、排序和上下文治理后受控进入生成模型的完整系统。
• 核心机制： 离线建库和在线问答必须分别可追踪、可版本化；召回、重排和上下文选择承担不同职责。
• 关键判断： 权限、版本与 Token 预算都是正确性边界；评测要同时覆盖检索、答案、引用、系统与成本。
• 项目落地： 示例项目：企业制度问答先恢复标题层级并生成稳定 Chunk ID，在线使用 BM25 与 Dense 混合召回，再由 Cross-Encoder 重排。上线前用固定问题集分别测 Recall@K、引用支持率、空召回率、P95 延迟和单次成本。
• 边界与坑： “RAG 就是向量数据库加大模型。” 漏掉数据治理、ACL、关键词召回、重排、上下文与评测；应沿离线和在线链路回答；“召回越多越好。” 候选过多会增加延迟、噪声和 Token；应分开设置各阶段 K 并用标注集选择。

目录

• 面试官为什么问
• 小白先看懂
• 主题教学图片
• 核心原理
• 项目和生产视角
• 常见错误回答
• 递进追问
• 关联阅读
• 总结

面试官为什么问

这道题同时考察系统边界、数据流、检索排序、权限安全和生产排障。只回答“先检索再生成”，说明候选人可能没有真正做过建库、Trace、评测与版本治理。

小白先看懂

想象小周参加开卷考试：考前把资料去重、分章节并贴目录卡；答题时先理解题目，再按权限查目录，挑出候选页，复核相关性，最后只把有限的几页放到桌上组织答案。

生活场景	技术映射
整理资料、贴目录卡	清洗、Chunk、Embedding、索引
理解题意	Query 规范化与改写
按权限查目录	ACL/元数据过滤与召回
复核候选页	Reranker 与上下文选择
根据桌面资料答题	Prompt、LLM 与引用

专业机制是先从大语料中缩小候选集，再把有限、可追踪的证据交给模型生成。类比的边界是：向量近邻不等于真正理解，资料错误、权限错误或上下文截断都会让答案出错。

主题教学图片

图：教学图片｜RAG 的完整链路是什么？

替代文本： 围绕“RAG 的完整链路是什么？”组织的中文教学图，通过分区、箭头和标签解释核心机制。

读图结论： 正确答案依赖正确证据进入上下文；证据不足时不要强行生成。

这张图片用于建立主题机制的直觉。精确公式、参数、失败分支和事实边界仍以正文与 Mermaid 为准。

图片生成记录： model=gpt-image-2，generated=2026-07-15，prompt_version=v1，reviewed=2026-07-16，review_basis=user-confirmed；查看生成 Prompt。

图：技术调用流程｜RAG 从建库到回答的证据链

替代文本： 离线资料经过清洗、切片和索引，在线问题经过改写、权限过滤、混合召回、重排与上下文预算后进入模型；空召回、超时或证据不足会走降级而不是强行生成。

图表加载中…

读图结论： RAG 质量由一条可观测证据链共同决定，检索、权限、上下文和生成任一阶段都可能成为正确证据首次消失的位置。

图中上半支是离线数据链，下半支是在线查询链；两者在候选召回处汇合。失败分支强调：没有足够证据时应澄清或降级，而不是让模型凭参数知识补答案。

核心原理

离线链路至少区分来源版本、解析器版本、切片器版本、Embedding 版本和索引版本。在线链路建议显式维护 k_recall > k_rerank >= k_context：先扩大候选覆盖，再精排，最后受 Token 预算约束选上下文。

日志需要回答原始/改写 Query、租户与 ACL、各通道候选数、过滤原因、召回与重排分数、最终 Chunk、截断原因以及模型、Prompt、索引版本。RAG 的“正确”既包括检索命中，也包括答案受到引用证据支持。

项目和生产视角

示例项目： 企业制度问答先恢复标题层级并生成稳定 Chunk ID，在线使用 BM25 与 Dense 混合召回，再由 Cross-Encoder 重排。上线前用固定问题集分别测 Recall@K、引用支持率、空召回率、P95 延迟和单次成本；这些是设计建议，不是本仓库的已实测指标。

生产风险常见于撤权未传播、Embedding/索引版本混用、过滤条件过严、上下文被截断。止损可返回“证据不足”并回退关键词检索；长期修复要补版本校验、撤权 SLA、Trace 和回放集。

常见错误回答

• “RAG 就是向量数据库加大模型。” 漏掉数据治理、ACL、关键词召回、重排、上下文与评测；应沿离线和在线链路回答。
• “召回越多越好。” 候选过多会增加延迟、噪声和 Token；应分开设置各阶段 K 并用标注集选择。
• “检索到内容就不会幻觉。” 错误证据、冲突证据和模型不遵循上下文仍会失败；要测引用支持率。

递进追问

1. 为什么 k_recall、k_rerank 和 k_context 不能使用同一个 K？
2. 如何设计稳定 Chunk ID 和索引版本切换？
3. ACL 应该在召回前还是召回后执行，为什么？
4. 如何定位正确证据在哪一层首次消失？
5. 实时库存或余额为什么不应由历史向量库回答？

关联阅读

• 正式主题：RAG 基础链路
• 专项题库：RAG 基础链路
• 项目案例：AI 知识库项目

总结

一句话记忆： RAG 是让可验证证据经过建库、检索、排序和上下文治理后受控进入生成模型的完整系统。

• 离线建库和在线问答必须分别可追踪、可版本化；
• 召回、重排和上下文选择承担不同职责；
• 权限、版本与 Token 预算都是正确性边界；
• 评测要同时覆盖检索、答案、引用、系统与成本。