[智能体-259]：Retrieval流程

connection→Source→Load→Transform→Embed→Store→Retrieve）

这张图是LangChain 标准 RAG 数据全生命周期流水线，分为「入库预处理链路（前 5 步：Source→Load→Transform→Embed→Store）」+「在线检索链路（Retrieve）」两大阶段，对应向量知识库从原始文件到召回文档全流程。

一、分步拆解（从左→右）

1. Data connection → Source（原始数据源接入）

• 数据源范围：PDF/Word/Excel、网页 HTML、Markdown、图片 OCR、聊天记录、邮件、API 接口、短视频文案、数据库文档等异构文件（图中各类图标）。
• LangChain 对应组件：各类DocumentLoader（PyPDFLoader、WebBaseLoader、CSVLoader、UnstructuredLoader），负责对接五花八门的数据源。
• 作用：把散落的多格式原始数据统一接入 RAG 系统。

2. Load（文档加载）

• 功能：Loader 读取源文件，把不同格式内容统一解析为 LangChain 标准Document(page_content, metadata)对象。
• 输出：批量原生完整文档文本，未做切割。
• 示例：PDFLoader 读取整本 PDF，生成一个完整 Document。

3. Transform（文本切分 & 预处理）

• 核心操作：文本拆分（Splitter）+ 清洗过滤
  1. 文本分片：RecursiveCharacterTextSplitter按字符 / 语义切块（chunk），解决超长文本向量化丢失细节；
  2. 数据清洗：剔除空行、乱码、无效符号、水印冗余内容；
• 输出：多段短文本 Chunk（小块文档），是后续 Embedding 的最小单元。

拓展优化：ParentDocumentRetriever 在这里做大小双切片：小切片用于向量检索、大切片留存原文。

4. Embed（向量化编码）

• 原理：调用 Embedding 模型（OpenAIEmbedding、BGE、text-embedding 系列），将自然语言 Chunk 转为多维浮点向量（如图中[0.5,0.2...]数字数组），语义相近的文本向量空间距离更近。
• 关键点：文字→数学向量，是向量相似度检索的数学基础。

5. Store（向量持久化入库）

• 功能：文本向量 + 原文档 + 元数据，一并存入向量数据库（Chroma/FAISS/Milvus/PGVector），永久落盘存储。
• 两种存储：
  1. 向量：存入向量库索引，用于相似度计算；
  2. 原文 Document：向量库 / 外置文档库留存，召回后返回原文。

前 5 步统称：RAG 知识库构建阶段（离线建库，一次性批量执行）

6. Retrieve（在线检索，用户提问阶段）

用户提问触发，在线实时执行（RAG 推理阶段）

1. 用户 Query → 同样经过 Embedding 生成提问向量；
2. 向量库做余弦相似度计算，召回 Top-K 最相似的 Chunk 文档；
3. 召回文档拼接进 Prompt，送入 LLM 生成答案；

• 两种落地形态✅ 固定 RAG：Retrieve 固定嵌入 LCEL 链路，所有提问强制检索； ✅ Agent-RAG：Retriever 封装 Tool，LLM 按需自主调用检索。

二、结合之前知识点关联💡

1. Retriever 本质：就是Retrieve环节的代码封装（BaseRetriever 所有子类：ChromaRetriever/BM25/Ensemble 等全部实现该步骤）；
2. RAG = 离线建库 (Source~Store)+ 在线检索 (Retrieve)；
3. Memory vs RAG：本流程产出的向量库 = RAG 长期硬盘记忆；LangChain Memory 是会话短期内存，不在本流程内。

三、工程优化节点（全流程可优化位置）

1. Transform：优化分片大小、重叠值，避免上下文断裂；
2. Embed：替换本地开源 Embedding 降低接口成本；
3. Retrieve：MultiQueryRetriever/ContextualCompression/Ensemble 多路召回，提升召回准确率。