跳到正文

RAG 架构：检索到生成全链路

组件功能与数据流转详解,从检索到生成全链路

原题：请详细描述RAG（Retrieval-Augmented Generation）系统的具体实现架构，包括各个组件的功能设计和数据流转过程。

重排与优化 · 字节真题

30 秒回答

  1. 离线知识库构建流程（文档解析、分块、向量化、索引存储）
  2. 在线检索生成流程（查询改写、向量检索、重排序、上下文拼接、LLM生成）
  3. 关键设计决策（分块策略、检索top-k数量、上下文长度控制）
  4. 系统优化点（混合检索、缓存机制、多路召回）

回答与解析

答案要点

  • 离线知识库构建流程（文档解析、分块、向量化、索引存储）
  • 在线检索生成流程（查询改写、向量检索、重排序、上下文拼接、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 粗粒度综述）

口语版讲法(约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和模型选择。

关键一句:动态分块：根据问题粒度调整chunk大小，宏观问题用大块，具体问题用小块

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你们在做企业知识库问答，用户问“第三季度的财报数据”，文档里既有表格又有段落。你从拿到原始PPT到最终生成答案，中间要经过哪些步骤？数据是怎么一步步流过去的？

  2. 问法 2 · 层层追问

    RAG 系统你了解吧？离线索引和在线查询两部分……那离线构建时文档怎么切分？切完怎么存？……在线来了一个 query，怎么从库里找到相关片段再给大模型？具体说说数据流转。

  3. 问法 3 · 直球架构

    详细描述一下 RAG 系统的实现架构，包括离线知识库构建和在线检索生成两个流程，各组件功能是什么，数据如何流转？

同模块相关题目