理解了 RAG 的核心定义与设计思想后，本节将完整拆解一套标准 RAG 系统从接受用户提问到输出最终答案的全链路流程。流程分为两个阶段：离线准备阶段（知识入库）和在线服务阶段（实时问答）。每个环节都有明确的输入、输出和工程要点，下面逐一说明。
2.2.1 离线准备阶段：知识入库
这一阶段的目的是将业务文档转化为可被高效检索的向量化知识片段，只在知识库首次构建或内容更新时执行，不占用在线请求资源。
步骤一：文档收集与清洗
首先需要明确知识来源。典型的来源包括：公司内部 Wiki、PDF 政策文件、产品说明书、客服对话记录整理、外部合规文件等。收集后要做基础清洗：
- 剔除页眉页脚、水印、多余空行等噪声；
- 处理特殊格式：将表格、列表转换为可读的纯文本或结构化标记；
- 统一编码与路径，方便后续更新时溯源。
实用做法：使用例如 Python 的 pdfplumber（处理 PDF 表格）、markdown 库等工具提取文本，保留关键元数据（文件名、章节标题、页码）并存储为 JSON 或 Markdown 格式。
步骤二：文本切块（Chunking）
大模型输入窗口有限，直接送整篇文档会超限，检索精度也会下降。因此需要将长文档切分成大小合适的“块”（chunk）。
- 常用大小：每块 256～1024 个 token（中文通常 300～800 字）。太小会丢失上下文，太大会稀释关键信息。
- 重叠设计：相邻块之间保留 10%~20% 的重叠内容，防止关键句子恰好被切断。
- 结构化切分：尽量按段落、章节等自然边界切分，而不是机械地在固定字数处一刀切。
实用建议：使用 LangChain 的 RecursiveCharacterTextSplitter 或自研按固定分隔符切分工具。每个分块都要保留来源文件名、页码、段落标题等元数据，这就是后续溯源的基础。
步骤三：向量嵌入与索引存储
将每个文本块通过嵌入模型（embedding model）转化为一个固定长度的数值向量，这个向量能编码该文本的语义信息。
- 嵌入模型选择：通用场景可使用
text-embedding-3-small（OpenAI）、bge-large-zh（中文开源模型）等。针对垂直领域（如法律、医学）可考虑使用领域微调的嵌入模型。 - 向量数据库存储：将向量与对应文本块、元数据一起存入向量数据库（如 Milvus、Pinecone、Weaviate、Chroma 等）。向量数据库支持高效的近似最近邻（ANN）搜索，是检索速度的保障。
工程要点：
- 记录每次入库的文档版本号，便于回滚或部分更新。
- 对于需要频繁更新的知识（如价格），可以按文档级别建立索引，删除旧文档对应的所有向量，再插入新向量即可。
2.2.2 在线服务阶段：实时问答
用户在系统界面提出问题后，以下步骤实时执行，通常在 1～3 秒内完成。
步骤四：用户查询处理与向量化
收到用户自然语言问题后，先做必要的预处理：统一大小写、去除无关特殊字符（保留关键标点）。然后用与离线阶段完全相同的嵌入模型将问题转换为查询向量。保持嵌入模型一致性至关重要，否则向量空间不匹配，检索结果会完全失效。
步骤五：相似度检索
将查询向量送入向量数据库，通过余弦相似度或欧氏距离找出最相近的 top‑k 个文本块（通常 k 取 3～8）。这一步返回的结果不仅包括文本内容，还包括其携带的元数据（来源、页码等）。
实用调优：
- 根据业务场景调整 k 值：事实型问答 k 取 3～5 即可；开放式分析类问题可适当增大到 8～10。
- 引入相似度阈值过滤：如果所有片段的相似度分数都低于某个阈值（如 0.65），说明知识库可能没有相关信息，触发“未找到”回复，避免模型胡编。
步骤六：上下文组装与提示词构建
将检索到的文本块按一定顺序（通常按相似度降序）拼接，连同用户原始问题，填充到一个预定义的提示词模板中。模板需要明确指示模型的角色、行为边界、引用格式。一个典型的模板示例如下：
你是一个基于公司内部资料回答问题的助手。请严格根据以下提供的资料片段回答用户问题，不要添加任何外部知识。如果资料不足以回答问题，请直接说“根据现有资料无法确定”。每个要点后标明资料出处。
【资料片段】
{检索结果文本，每段前标注来源}
【用户问题】
{用户输入}
【回答】实用建议：通过 A/B 测试不同提示词模板，观察生成质量变化。加入“逐条依据”的要求能显著减少幻觉。
步骤七：大模型生成回答
将组装好的提示词发送给大语言模型（如 GPT‑4、Claude、开源模型如 Qwen、DeepSeek 等）。模型基于提供的资料“开卷作答”，生成自然语言回答。因为所有事实依据都已附在上下文中，模型只需理解、归纳并引用。
步骤八：后处理与溯源呈现
拿到模型回复后，根据需要进行格式化后处理：
- 提取并美化引用标记：将回复中的来源信息自动转为可点击链接，例如 “[员工手册第3.2条]” 点击后可打开 PDF 对应页面。
- 敏感信息过滤：如果企业要求，可以扫描回复中是否包含邮箱、手机号等隐私内容，决定是否脱敏或拦截。
- 记录日志：将用户问题、检索到的片段 ID、最终答案以及用户反馈（如有）存入数据库，用于后续评估与优化。
最终将答案与出处一起返回给用户。用户看到的不仅是一个回答，还是一个可验证、可追溯的有据结论。
2.2.3 全链路流程总览
| 阶段 | 步骤名称 | 输入 | 输出 | 负责组件 |
|--------|------------------|----------------------------|----------------------------|----------------------------|
| 离线 | 文档清洗 | 原始业务文档 | 干净的结构化文本 | 预处理脚本 |
| 离线 | 文本切块 | 清洗后文本 + 元数据 | 若干带来源的文本块 | 切分器 (Splitter) |
| 离线 | 向量嵌入与索引 | 文本块 | 向量 + 向量索引 | 嵌入模型 + 向量数据库 |
| 在线 | 查询向量化 | 用户问题 | 查询向量 | 嵌入模型（同离线） |
| 在线 | 相似度检索 | 查询向量 | top‑k 相关文本块 + 元数据 | 向量数据库 |
| 在线 | 上下文组装 | 检索结果 + 问题 + 提示模板 | 完整提示词 | 提示词管理器 |
| 在线 | 生成回答 | 提示词 | 原始回答文本 | 大语言模型 (LLM) |
| 在线 | 后处理与呈现 | 原始回答 | 格式化且带溯源的最终答案 | 后处理模块 |
通过这条标准全链路流程，RAG 系统实现了“实时检索、按需生成、有据可查”的闭环。任何环节都可以独立优化，例如更换更好的嵌入模型提升检索命中率，或调整提示词模板降低幻觉，无需推倒重来。这种模块化设计正是 RAG 在工程落地中生命力强的重要原因。