完整题目
请基于传统文档处理系统的两阶段架构，详细描述RAG（检索增强生成）系统中各个核心模块的功能以及数据在整个系统中的流转过程。
本文目录
答案要点
- 清晰区分离线索引阶段和在线检索生成阶段
- 准确描述文档解析、分块、Embedding、向量存储等离线模块
- 准确描述Query理解、检索召回、重排序、上下文融合、LLM生成等在线模块
- 能说明数据流转的完整链路
RAG两阶段架构核心模块与数据流转
第一阶段：离线索引（Indexing）
目标：将原始文档转化为可检索的向量知识库
| 模块 | 功能 | 输出 |
|---|---|---|
| 文档解析 | 处理PDF/Word/网页等多格式，提取结构化文本 | 原始文本 |
| 文档分块（Chunking） | 按语义/固定长度/递归等方式切分，平衡粒度与上下文 | 文本块集合 |
| Embedding编码 | 用BGE、M3E等模型将文本转为稠密向量 | 向量表示 |
| 向量存储 | 写入Milvus/Faiss/Elasticsearch等，构建索引 | 可检索向量库 |
关键设计：分块策略直接影响检索质量——太粗易噪声，太细丢上下文。
第二阶段：在线检索生成（Retrieval & Generation）
数据流转链路：
用户Query → Query理解（改写/扩展） → 向量检索（Top-K召回）
→ 重排序（Rerank精排） → 上下文融合（Prompt组装）
→ LLM生成 → 返回结果核心模块：
- 检索召回：基于向量相似度（cosine/IP）快速筛选候选，可用倒排索引混合召回
- 重排序：用Cross-Encoder（如bge-reranker）精排，弥补双塔模型语义鸿沟
- 上下文融合：将检索文档按相关性排序，截断后填入Prompt模板，控制token预算
- 生成模块：LLM基于"检索上下文+原始Query"生成答案，需处理"找不到答案"的拒答场景
数据流转全景
离线：原始文档 → 解析 → 分块 → Embedding → 向量DB
↑
在线：用户Query ──────────────┘（检索）→ 重排 → 组装Prompt → LLM → 答案工程要点：离线追求覆盖全、更新快；在线追求召回准、延迟低。两者解耦，可独立迭代优化。
换一种问法，检查是否真正理解
场景切入
假设你在做一个企业知识库问答系统，用户上传了一批PDF和Word文档。你怎么把这些文档变成能检索的知识？从文档进来到最后能回答用户问题，整个流程是怎么走的，关键模块有哪些？
层层追问
RAG系统你知道吧？通常分两阶段……那离线阶段具体要做哪些事情？……文档解析完怎么处理？分块和向量化……那在线阶段用户提问后，数据怎么流转才能找到最相关的文档然后生成答案？
直球架构
请你详细描述RAG系统的两阶段架构，包括离线索引和在线检索生成各自的核心模块，以及数据从原始文档到最终答案的完整流转过程。重点说清楚每个模块的功能和输入输出。
练习口述回答 · 约4分钟
- 一句话定位：RAG本质是给LLM外挂知识库
- 离线阶段：文档解析、分块、Embedding、向量存储
- 在线阶段：Query理解、检索、重排、上下文融合、生成
- 边界划分：RAG vs 微调，关键词 vs 向量，固定分块 vs 语义分块
- 落地风险：分块策略、检索质量、拒答处理
- 可延伸点：分块粒度对检索的影响
这道题问的是[[RAG]]的两阶段架构，说白了就是给大模型外挂一个知识库，让它在生成答案时能参考外部文档，而不是完全依赖自己的参数记忆。我把它拆成离线和在线两个阶段来讲。
先说离线阶段，目标是把原始文档转成机器能快速检索的[[向量库]]。第一步是文档解析，处理PDF、Word、网页这些乱七八糟的格式，把文本抽出来。这一步看着简单，但PDF里经常有表格、图片、页眉页脚，处理不好就会带进很多噪声。第二步是[[分块]]，把长文档切成小块。这里有个核心矛盾：块太大，一个块里混了多个主题，检索时容易带进不相关的信息；块太小，上下文不完整，LLM没法理解。所以分块策略很关键，常见做法是按固定长度切，但更鲁棒的是按语义边界切，比如自然段或者章节。第三步是把每个块用 [[Embedding]] 模型转成向量，比如用BGE或者M3E。第四步是存到 Vector Database 里，像Milvus、[[Faiss]]或者Elasticsearch，同时建好索引方便快速检索。离线阶段追求的是覆盖全、更新快，通常用定时任务或者事件驱动来增量更新，而不是全量重建。
在线阶段就是用户来了一个Query，怎么用这个知识库生成答案。流程是这样的：用户Query进来，先做Query理解，比如改写或者扩展，因为用户可能输入得很随意，比如“退款多久到账”和“退货钱什么时候退”其实是一个意思。然后去向量库做检索，用向量相似度召回Top-K个候选文档。这里有个坑：纯向量检索容易漏掉精确匹配的场景，比如订单号或者错误码。所以落地时我通常会把向量检索和关键词检索结合起来做 [[Hybrid Search]]，比如用 [[BM25]] 做关键词召回，再融合排序。召回的文档不一定都相关，所以下一步是[[重排]]，用 [[Cross-Encoder]] 模型精排，把最相关的文档排到前面。重排之后就是上下文融合，把检索到的文档按相关性排序，截断到LLM能接受的token长度，然后组装成Prompt。最后交给LLM生成答案。这里要特别注意拒答场景，如果检索到的文档跟Query完全不相关，LLM应该明确说“没有找到相关信息”，而不是硬编一个答案。
说到边界划分，RAG适合场景是知识库频繁更新、需要引用外部证据的，比如企业内部的SOP文档或者合规政策；而微调适合让模型学会固定的格式或风格，比如客服话术模板。检索层面，关键词搜索适合精确匹配，比如订单号；向量搜索适合语义匹配，比如“退款政策”和“退货规则”意思相近。分块层面，固定切分简单但容易断掉语义，语义切分更准但计算成本高。真正落地的系统往往是混合策略，比如用固定长度切块，同时保留段落边界做软约束。
落地时我特别关注几个风险。一是分块策略必须跟业务场景匹配，比如客服场景里，退款政策是一个完整段落，如果切成两半，LLM可能只看到一半的政策，回答就不准。二是检索质量，如果Top-K召回的文档里混了噪声，LLM会被带偏。所以上线前我会用一批历史Query做回放，对比Recall@K和答案准确率。三是延迟，在线阶段每一步都有开销，尤其是重排和LLM生成，所以我会用缓存和异步处理来优化。