完整题目
请详细描述RAG（Retrieval-Augmented Generation）系统的具体实现架构，包括各个组件的功能设计和数据流转过程。
本文目录
答案要点
- 离线知识库构建流程（文档解析、分块、向量化、索引存储）
- 在线检索生成流程（查询改写、向量检索、重排序、上下文拼接、LLM生成）
- 关键设计决策（分块策略、检索top-k数量、上下文长度控制）
- 系统优化点（混合检索、缓存机制、多路召回）
一、整体架构：离线+在线双链路
┌─────────────────┐ ┌─────────────────┐
│ 离线知识库构建 │ │ 在线检索生成 │
│ (Index Pipeline)│ │ (Query Pipeline)│
└─────────────────┘ └─────────────────┘二、离线知识库构建（Index Pipeline）
| 步骤 | 功能 | 关键设计 |
|---|---|---|
| 文档解析 | 处理PDF/Word/网页等多格式 | 保留结构信息（标题层级、表格位置） |
| 文本分块 | 将长文档切分为chunk | 策略：固定长度/语义分块/递归分块；chunk size通常256-512 tokens |
| 向量化 | Embedding模型编码为稠密向量 | 选用领域适配的模型（如BGE、M3E）；考虑稀疏向量（BM25）做混合 |
| 索引存储 | 写入向量数据库 | Milvus/Pinecone/Elasticsearch；构建HNSW索引加速ANN检索 |
三、在线检索生成（Query Pipeline）
用户Query → 查询改写 → 多路检索 → 重排序 → 上下文组装 → LLM生成| 环节 | 说明 |
|---|---|
| 查询改写 | 扩展同义词、纠错、指代消解（如"它"→具体实体） |
| 多路检索 | 向量检索（语义匹配）+ 关键词检索（精确匹配）+ 可能的知识图谱召回 |
| 重排序（Rerank） | 用Cross-Encoder（如BGE-Reranker）精排Top-K，提升相关性 |
| 上下文组装 | 按相关性排序拼接chunk，控制总长度（通常占LLM上下文30%-50%） |
| LLM生成 | 构造Prompt："基于以下信息回答问题：[context]\n问题：[query]" |
四、关键优化点
- 混合检索：稠密向量+稀疏向量+倒排索引，兼顾语义和精确匹配
- 检索缓存：高频Query直接走缓存，降低延迟
- 多路召回融合：不同检索策略结果用RRF（Reciprocal Rank Fusion）合并
- 动态分块：根据Query意图调整chunk粒度（细粒度事实 vs 粗粒度综述）
换一种问法，检查是否真正理解
场景切入
假设你们在做企业知识库问答，用户问“第三季度的财报数据”，文档里既有表格又有段落。你从拿到原始PPT到最终生成答案，中间要经过哪些步骤？数据是怎么一步步流过去的？
层层追问
RAG 系统你了解吧？离线索引和在线查询两部分……那离线构建时文档怎么切分？切完怎么存？……在线来了一个 query，怎么从库里找到相关片段再给大模型？具体说说数据流转。
直球架构
详细描述一下 RAG 系统的实现架构，包括离线知识库构建和在线检索生成两个流程，各组件功能是什么，数据如何流转？
练习口述回答 · 约4分钟
- 一句话定位：RAG本质是让LLM带个外部知识库，解决事实更新与幻觉问题
- 离线构建：文档解析、分块、向量化、存库，重点说分块策略和边界
- 在线流程：查询改写、多路检索、重排序、组装上下文给LLM
- 落地风险与优化：混合检索、缓存、动态分块，以及常见失败场景
- 收尾：个人取舍和延伸可延伸点
这道题问的是[[RAG]]的实现架构，其实本质上是在问：你怎么让大模型在回答时能拿到最新、最准确的外部知识，而不是完全依赖它训练时记住的那些东西。RAG和微调的区别就在这里，微调是往模型脑子里塞知识，但更新成本高、容易遗忘；RAG是把知识挂在外面，需要时再查，这样知识更新和模型解耦。
整体架构分两条线：离线把知识库建好，在线做检索和生成。先说离线部分，核心就是把文档变成可检索的向量。文档解析这块，PDF、网页、Word格式不一样，我一般会保留标题层级和表格位置，因为这些对后面[[分块]]很重要。分块是个关键决策，固定长度切分最简单，比如512个token一块，但容易把逻辑相关的句子拆散；语义分块效果好，但依赖模型且慢。真实落地时我倾向用递归分块，先按段落切，超过上限再按句子切，这样既保留结构又控制长度。分完块后用[[Embedding]]模型编码成向量，存到[[Vector Database]]里，比如Milvus，索引用[[HNSW]]，兼顾速度和召回。
在线流程从用户提问开始。先做查询改写，比如用户说“它怎么退款”，得把“它”还原成具体商品或订单号，不然检索会偏。然后是多路检索，这里我强调一下边界：向量检索擅长语义匹配，比如用户说“手机屏幕碎了”能召回“碎屏险理赔流程”；关键词检索擅长精确匹配，比如订单号、错误码。所以真正落地我都是两条路一起上，用[[Hybrid Search]]把向量和[[BM25]]的结果合并。检索完top-K结果后，用[[Rerank]]模型精排，把最相关的几条提到前面，这一步对最终质量影响很大。排完序后组装上下文，注意控制长度，一般不超过LLM上下文的30%到50%，太长会稀释注意力。最后构造Prompt让LLM基于上下文回答。
这里有个常见的失败场景：如果知识库里根本没有正确答案，再好的检索也白搭。所以上线前我会特别关注分块质量，用[[RAGAS]]这类工具评估召回率和[[忠实度]]。还有就是缓存，高频问题直接走缓存，能省掉检索和生成的开销。
还有一个方向是动态分块，根据问题的粒度调整块的大小。比如问“公司年假政策”这种宏观问题，需要大块上下文；问“某天请假扣多少钱”这种具体问题，小块就够。如果面试官有兴趣，可以聊聊怎么用query分类来决定分块策略。
所以整体上，我更倾向于把RAG看成一个检索系统加一个生成系统的组合，检索的精度决定了生成的上限。在工程落地上，我会先保证检索的召回和排序不出大问题，再优化生成侧的Prompt和模型选择。