RAG 技术图解：从基础链路到工程扩展
用架构图解释 Retrieval-Augmented Generation 的索引、检索、重排和生成链路。
RAG（Retrieval-Augmented Generation，检索增强生成）是一种让 LLM 在回答时使用外部知识的架构模式。它的价值不在于让模型“记住”更多内容，而是在生成前检索可追溯证据，并把答案约束在这些证据之上。
什么是 RAG？
大模型的训练知识有截止时间，也无法天然访问企业私有文档、产品手册、代码仓库或业务数据。RAG 通过外部检索系统把相关证据送入上下文，用来降低知识过期、事实错误和不可追溯的问题。
如上图所示，RAG 通常位于用户问题和模型生成之间，负责把问题转化为可检索请求，并把检索结果整理成模型可使用的上下文。
一张图看懂核心链路
RAG 不是一个单点能力，而是一条离线索引链路和一条在线问答链路的组合。离线链路决定知识是否能被正确召回，在线链路决定答案是否能被正确约束。
核心工作流
-
知识入库 (Indexing)：
- 将 PDF、网页、代码、表格等文档解析为稳定文本。
- 按语义边界分块，保留标题、层级、来源和权限元数据。
- 将文本转化为向量或稀疏表示，写入向量库、搜索引擎或混合索引。
-
检索召回 (Retrieval)：
- 对用户问题做改写、扩展、路由或拆解。
- 同时使用 BM25、Dense Vector、Sparse Vector、Graph 或业务 API 召回候选证据。
-
增强生成 (Generation)：
- 对候选证据重排、去重、过滤权限和压缩上下文。
- 将证据、引用、回答格式和拒答规则一起交给模型。
- 输出答案时给出来源，方便用户和系统做追溯。
每一层解决什么问题
| 层级 | 关键问题 | 常见技术 | 失败时表现 |
|---|---|---|---|
| 文档解析 | 内容是否被正确提取 | OCR、PDF parser、HTML cleaner、table extraction | 表格丢失、段落错乱、标题缺失 |
| Chunking | 知识是否可被召回 | semantic chunk、parent-child、hierarchical index | 召回片段太碎或太长 |
| Retrieval | 相关证据是否进入候选集 | BM25、embedding、hybrid search、query rewriting | 答非所问、漏召回 |
| Rerank | 最有用证据是否排在前面 | cross-encoder、LLM rerank、RRF | 有证据但被挤出上下文 |
| Context | 模型是否能使用证据 | compression、citation packing、dedupe | 上下文噪声过大 |
| Generation | 答案是否可信 | grounded prompt、引用、拒答 | 幻觉、无引用、过度自信 |
| Evaluation | 系统是否可迭代 | golden set、Recall@K、faithfulness、bad case trace | 只能靠感觉调参 |
工程扩展：不仅仅是向量检索
基础向量检索只能解决一部分问题。企业级 RAG 通常还需要查询改写、混合检索、重排、权限过滤、引用校验和评测闭环。
工程判断
生产级 RAG 的核心不是“接一个向量库”，而是把知识处理、检索排序、权限安全、答案引用和评测回归串成一条可观测链路。
RAG 的真实架构
从文档摄取到可引用答案，拆解离线索引、在线检索、生成引用和观测评测。
查询路由
根据问题类型选择全文检索、向量检索、图检索、SQL 或业务 API。
混合检索与重排
同时使用 BM25、向量召回和稀疏向量，再用 reranker 筛选可回答证据。
RAG Bad Case 分析
把线上坏例拆成可复现、可归因、可修复、可回归的工程资产。
上线前检查清单
继续阅读
如果你已经理解这条基础链路，可以继续进入完整专题：
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。