RAG 检索增强生成完整流程

📅 2026/7/18 17:02:58
RAG 检索增强生成完整流程
RAG 检索增强生成完整流程本文基于《4_Retrieval_RAG检索增强生成.pdf》整理系统阐述 RAG 的完整数据流、核心环节与工程实践。一、前言为什么需要 RAG大语言模型LLM在自然语言处理上表现强大但存在四大核心局限局限说明影响知识滞后预训练与微调成本高模型知识难以实时更新无法回答最新事件知识缺失无法掌握所有专业领域细节专业领域回答不准确幻觉可能编造事实、错误推理可信度降低不可追溯生成答案无法追溯来源难以验证和审计RAGRetrieval-Augmented Generation检索增强生成的核心思想是将生成式大模型与实时信息检索结合在模型生成答案前先从外部知识库中检索相关上下文并补充给模型相当于“给大模型一本参考书”。相比提示词工程RAG 能提供 richer 的上下文相比模型微调RAG 成本更低、知识更新更快、可追溯性更强。二、RAG 完整流程总览典型的 RAG 系统分为两大阶段索引阶段离线加载文档 → 切分文本 → 生成嵌入 → 存储向量 → 构建索引。检索生成阶段在线接收用户查询 → 查询向量化 → 检索相关片段 → 重排序 → 构造 Prompt → 大模型生成答案。三、索引阶段离线3.1 文档加载企业知识分散在多种格式中TXT、Markdown、Word、PDF、网页、数据库等大模型无法直接使用。RAG 的第一步是通过文档加载器Loader将这些异构数据统一转换为 LangChain 的Document对象。Document对象统一结构属性说明page_content文本内容字符串metadata来源、页码、标题等元数据id可选文档标识符常用加载器文件类型推荐加载器MarkdownUnstructuredMarkdownLoaderWord (.docx)UnstructuredWordDocumentLoader/ MinerUPDFMinerU复杂版面/PyPDFLoader网页WebBaseLoader纯文本TextLoaderPDF 解析难点PDF 存在扫描版、电子文本版、多栏布局、表格、公式、图片等多种元素。MinerU 采用“先全局版面分析再局部内容识别”的两阶段策略能更准确地把 PDF 转为机器可读的 Markdown/JSON。3.2 文档切分完整文档通常超出 LLM 上下文窗口也无法做精准检索。因此需要把Document切分为更小的Chunk。切分需平衡三个维度维度说明过犹不及的后果长度控制每个块不能太大或太小太大噪声多太小语义不完整语义完整尽量不让句子被切断断句导致上下文断裂边界合理在自然分隔处切分强行截断会丢失信息常用切分策略对比策略原理优点缺点固定长度切分按固定字符/Token 数切分简单直接可能断句语义切分找语义变化大的位置切分语义完整速度慢、块大小不均递归字符切分按分隔符优先级逐级降级切分兼顾语义与大小控制需调整分隔符递归字符切分器RecursiveCharacterTextSplitter是最常用的折中方案优先按\n\n段落切分超限时降级为\n行、空格、字符并通过chunk_overlap在相邻块之间保留重叠防止边界信息丢失。3.3 文本嵌入切分后的 Chunk 仍是文本需要转换为计算机可计算的数值向量这就是Embedding嵌入。语义相近的文本在向量空间中距离更近。3.3.1 常用嵌入模型模型机构维度序列长度特点bge-large-zhBAAI1024512中文效果好bge-base-zhBAAI768512中文常用bge-m3BAAI10248192多语言支持稀疏向量text-embedding-3-smallOpenAI15368192多语言性价比高text-embedding-3-largeOpenAI30728192多语言精度更高3.3.2 稠密向量与稀疏向量特性稠密向量稀疏向量维度固定如 1024 维动态仅非零元素语义理解强同义词、近义词弱关键词匹配弱强精确命中适用场景语义检索关键词检索BGE-M3可同时输出稠密向量和稀疏向量为后续“混合检索”奠定基础。3.4 向量存储向量数据库专门解决高维向量的相似度检索问题。相比传统数据库的全表扫描向量数据库通过 ANN近似最近邻索引实现毫秒级检索。主流选型向量数据库特点FAISSMeta 开源高效相似性搜索库Chroma轻量级极简 API适合原型Milvus云原生支持百亿级向量原生支持稠密稀疏混合检索PgvectorPostgreSQL 扩展Elasticsearch统一管理结构化、非结构化和向量数据3.4.1 Milvus 核心概念Collection集合通过 Schema 定义字段包含一个主键、最多四个向量字段和若干标量字段。索引加速向量搜索的附加结构。稠密向量常用HNSW分层导航小世界索引。稀疏向量常用SPARSE_INVERTED_INDEX倒排索引。相似度度量IP内积方向长度的综合相似性。COSINE余弦相似度纯方向相似性。L2欧氏距离空间中的绝对距离。若向量已做 L2 归一化三者排序结果一致工程上优先选 IP 计算最快。3.4.2 HNSW 索引原理HNSW 构建多层图结构搜索时从粗到细逐层下降顶层少量采样节点连接跨度大快速定位方向。中间层逐步缩小范围。底层包含全部节点精确找到最近邻。将时间复杂度从暴力搜索的 O(n) 降到 O(log n)。3.4.3 数据插入完整流程加载文档 → 切分 Chunk → Embedding稠密稀疏 → 组装数据 → Milvus insert → 后台构建索引四、检索生成阶段在线4.1 检索方式Milvus 支持多种检索方式方式说明稠密向量检索基于语义相似度适合理解用户意图稀疏向量检索基于关键词匹配适合精确查询如法律条文编号混合检索稠密稀疏多路召回再用 Reranker 融合排序标量检索基于 metadata/text 等标量字段过滤重排序Reranker在初步召回的候选集上进行二次排序提升结果相关性。常用方法包括 RRFRanker、Cross-Encoder 等。4.2 生成检索到相关片段后将其与用户问题一起组织为 Prompt交给 LLM 生成最终答案。典型 Prompt 结构你是一个专业的问答机器人。请根据以下上下文回答问题。 当上下文无法回答问题时请回答“根据上下文无法回答该问题”。 上下文 [检索到的文本块1] [检索到的文本块2] ... 问题{用户问题}4.3 LCEL 构建 RAG 链LangChain Expression LanguageLCEL可将 RAG 流程组合为一条可执行的链{context: retriever | format_docs, question: RunnablePassthrough()} | rag_prompt | llm | StrOutputParser()流程说明RunnablePassthrough透传用户问题。retriever检索相关文档format_docs拼接上下文。rag_prompt构造包含上下文和问题的 Prompt。llm调用大模型生成回答。StrOutputParser()解析为字符串输出。来源引用可在format_docs中加入metadata.source让模型答案附带出处。4.4 端到端完整示例一个最简 RAG 流程# 1. 加载文档documentsTextLoader(./documents/sample.txt).load()# 2. 切分文档splitsRecursiveCharacterTextSplitter(chunk_size500,chunk_overlap50).split_documents(documents)# 3. 创建向量存储vectorstoreChroma.from_documents(documentssplits,embeddingOpenAIEmbeddings(),collection_namerag_demo)retrievervectorstore.as_retriever(search_kwargs{k:3})# 4. 构建 RAG 链rag_chain({context:retriever|format_docs,question:RunnablePassthrough()}|rag_prompt|llm|StrOutputParser())# 5. 查询responserag_chain.invoke(什么是 LangChain)五、RAG 调优基础版 RAG 跑通后通常需要系统优化以提升效果。5.1 高级技术一览技术说明效果混合检索向量检索 关键词检索提高召回率重排序对检索结果重新排序提高精准度查询重写优化用户查询表达提高检索质量元数据过滤根据 metadata 筛选精确控制检索范围父子索引父文档存储子文档检索返回更完整上下文多路召回多种策略并行检索综合提升效果5.2 性能与质量优化优化点方法效果调整 chunk_size500-800 字符提高检索精度调整检索数量 k3-10 个结果平衡准确性与效率混合检索向量 BM25提高召回率添加重排序交叉编码器 / RRF提高精准度上下文压缩去除无关内容减少 Token 消耗5.3 常见问题与解决方案问题原因解决方案检索不到相关内容chunk_size 太大或太小调整 chunk_size增加 overlap返回重复内容相似度检索过于集中使用 MMR 增加多样性Token 消耗过大检索结果过多减小 k 值使用压缩响应速度慢检索效率低使用更快的向量库缓存结果六、技术选型与学习路线6.1 场景推荐方案场景推荐方案原因快速原型Chroma OpenAIEmbeddings轻量级易上手生产环境Milvus BGE-M3性能好支持混合检索中文场景BGE 系列嵌入模型中文优化效果好多语言BGE-M3 / OpenAI支持多语言本地部署FAISS HuggingFace无需外部服务高精度混合检索 RRF 重排序召回和精准都优化6.2 学习路线入门阶段文档加载 → 文档切分 → 向量嵌入 → Chroma 存储 → 基础 RAG 链 ↓ 进阶阶段混合检索 → 元数据过滤 → 父子索引 → 上下文压缩 ↓ 高级阶段重排序 → 查询重写 → 多路召回 → RAG 评估优化 ↓ 实战阶段构建完整 RAG 应用 → 性能优化 → 生产部署 → 监控维护七、总结RAG 通过“先检索、再生成”的方式有效缓解了 LLM 的知识滞后、幻觉和不可追溯等问题。其完整流程可归纳为索引阶段文档加载 → 文档切分 → 文本嵌入 → 向量存储 → 索引构建。检索生成阶段查询向量化 → 向量检索稠密/稀疏/混合 → 重排序 → Prompt 构造 → LLM 生成答案。工程实践中需根据数据特点、性能要求和精度要求灵活选择加载器、切分策略、嵌入模型、向量数据库和检索策略并通过混合检索、重排序、查询重写等技术持续优化。参考资料LangChain Retrieval 文档LangChain Vector StoresLangChain Text SplittersMilvus 文档MinerU 项目仓库FAISS 官方文档Chroma 向量数据库《Lost in the Middle》论文