现在我们已经搞懂了检索增强生成RAG的三大独立模块检索、增强与生成。接下来就来看这些组件在真实系统中是如何协同运作的。 我们一直在分步搭建政策智能助手系统但当所有模块对接完成、投入生产环境运行时整套系统实际是什么样的我们都清楚基础流程用户提问先进入检索环节再做上下文增强随后交由大模型生成内容最后输出回答。但这只是顶层极简流程。在真实落地系统中后台还有大量配套组件保障整套流程运行流畅、高效且稳定。 前文讲到的文本分块、向量嵌入生成、向量数据库存储等操作都需要在用户发起提问之前提前完成。因为加载数千份文档、对文本做切分、生成向量嵌入并入库、完成向量打分整套流程耗时很长这一系列前置工作统一归为 RAG 数据预处理流水线。 我们再细致拆解这套简易 RAG 预处理流水线 流水线读取政策文档采用 500 字符块长、50 字符重叠量的规则对文本分块随后调用 OpenAI 向量模型将文本块转为向量嵌入最后把向量与文本存入向量数据库。 当用户提出查询请求时系统会调用这套预处理好的 RAG 库检索匹配出相关文档片段。我们将检索到的文档片段和用户问题拼接完成提示词上下文增强再一并送入大语言模型由模型生成最终回答。 以上就是一套最基础、简化版的 RAG 完整工作流程。完整版基础 RAG 系统全流程拆解前置预处理 线上推理双阶段一、两大核心阶段划分整套 RAG 系统分为离线数据预处理流水线提前执行用户提问前完成、在线问答推理链路用户实时提问触发二者完全解耦分工明确离线预处理一次性 / 定时批量处理全部知识库文档生成可检索向量库不占用问答响应耗时在线推理用户提问实时执行仅做向量检索、Prompt 拼接、大模型生成保障响应速度。二、离线RAG 数据预处理流水线分步拆解输入本地 / 云端政策原始文档PDF、Word、TXT 等 完整执行步骤文档加载与清洗读取各类格式政策文件过滤空行、乱码、页眉页脚、重复水印、无效符号提取纯正文文本。文本分块Chunk 分割配置规则单块最大 500 字符块间重叠 50 字符。固定块长控制单段信息量避免过长超出向量模型、LLM 上下文窗口重叠块用于解决语义切割断裂问题保证相邻段落关联信息不会被拆分丢失提升检索召回完整性。向量嵌入编码调用 OpenAI Embedding 向量模型将每一个文本 Chunk 转换为固定维度稠密数值向量把文本语义转化为计算机可计算的向量表征。向量库持久化存储将「原始文本块 对应向量 文档来源 / 页码等元数据」成对存入向量数据库构建完整知识库索引。该流程特点批量离线执行文档新增 / 更新时重新跑流水线增量入库不影响线上问答服务。三、在线用户提问实时推理链路用户发起请求触发输入用户自然语言政策问题查询向量化复用同一套 OpenAI 向量模型把用户提问转换成查询向量和知识库内向量处于同一向量空间。相似度检索召回向量数据库计算查询向量与库内所有 Chunk 向量的余弦相似度按相似度分值排序取出 Top-N 高相关文档片段。上下文增强Prompt 构造拼接模板系统角色指令 召回的政策原文片段 用户原始问题完成上下文增强把外部知识库信息注入 Prompt约束大模型只能基于检索到的真实政策作答。大模型生成回答将增强后的完整 Prompt 送入 LLM模型结合外部检索资料生成贴合政策原文、有据可依的答案。结果返回输出把回答、配套引用的政策来源片段一并返回给用户完成一次问答。四、极简总流程总结离线前置政策文档 → 清洗分块 (500 字符 / 50 重叠) → OpenAI Embedding → 向量库入库线上实时用户提问 → 问题向量化 → 向量库相似度检索 → 检索文本拼接增强 Prompt → LLM 生成回答 → 输出结果补充极简版 RAG 核心逻辑提炼基础 RAG 本质是离线建语义索引在线借外部资料辅助生成解决大模型知识截止、幻觉、专业政策信息缺失问题预处理流水线负责 “建好知识库”检索 - 增强 - 生成三模块负责 “实时调用知识库回答问题”。
