RAG 组件化实战思维导图模板_ProcessOn思维导图、流程图

Function Call

为什么需要 Function Call

大模型只是一堆参数，很多事情它自身做不了

不知道今天的天气

不能调 IDE/编译器验证代码对不对

不能调计算器做复杂数学计算

完整流程

以"用户问：巴黎今天天气怎么样？"为例

第 1 步：用户 prompt 传入大模型（这次请求里带上了 tools 工具列表）

第 2 步：大模型【判断】：这个问题需不需要调用函数？

不需要 → 直接生成文本回答（和正常聊天一样）

需要 ↓

第 3 步：大模型【选函数 + 生成参数】：

根据每个工具的 description，决定调用哪个函数

输出： 函数名 get_weather 参数 {"latitude": 48.85, "longitude": 2.35}

第 4 步：我们的代码解析出函数名和参数 →【真正执行函数】

get_weather 内部发 HTTP 请求，拿到真实天气数据：18°C

第 5 步：把函数结果【追加到 messages 上下文】，再次传给大模型

第 6 步：大模型基于函数结果生成最终回答："巴黎今天 18 度"

代码逐段拆解

第 1 段：定义真正干活的函数

第 2 段：定义 tools（工具描述）⭐ 这是大模型决策的依据

description 决定大模型"什么时候选这个函数"

它就是大模型判断"哪个工具适合当前 query"的唯一依据，必须写清楚。

parameters 告诉大模型调这个函数需要传什么参数、什么类型

第 3 段：第一次调用——返回的不是回答，而是 tool_calls

第 4 段：解析参数，执行函数

第 5 段：结果追加进上下文，第二次调用，生成最终回答

扩展

Coze / Dify 这类平台已经集成好了函数调用，但 "作为开发者，还是希望从底层构建，更灵活"

只要 description 写清楚，任何函数都能让大模型调用：画图、调编译器执行代码、操作网页

Agent 和 RAG/普通工程的区别

Agent = 4 个模块：Memory（记忆）+ Function Call/Tool（工具）+ Planning（规划）+ Action（行动）

拿到任务 → 判断环境 → 给出 plan → 调不同工具执行 → 整合结果

什么是 RAG

Retrieval-Augmented Generation（检索增强生成）

先检索，再用检索到的知识增强生成

普通大模型 = 闭卷考试（纯靠脑子记的知识答题）

RAG = 开卷考试（带着整个图书馆进考场，先查书再作答）

流程

用户 query   → 去预先建好的数据库检索  → 找到相关背景知识  → 把"背景知识 + 问题"一起给大模型  → 生成准确回答。

为什么需要 RAG

三大优势

动态更新的知识

模型训练数据有时效性（如截止 2023/2024 年），2025 年两会发了什么文件模型不知道

RAG 知识库可随时更新，无需重新训练

提高生成质量、减少幻觉

改 bug 时直接把 GitHub 上相关 issue 检索给模型

它就能基于"这个 bug 该怎么改"的背景知识生成好结果

数据隐私与本地化

企业数据没参与过模型训练、也不能泄密给外部训练

RAG 可建企业本地私有化知识库，回答还能标注引用来源（基于哪个文件的哪一段）

一个 LLM 自身的局限

上下文长度有限

如果上下文无限长，直接把企业所有文档塞进 prompt 就行了，不需要 RAG

正因为上下文有限、且上下文越长推理成本越高，才需要"按 query 检索相关内容再拼接"

即使上下文变长 10 倍，生成速度也只降约 3%~5%，

且文档可以做成 prompt cache 缓存、不用重复 embedding

所以"文件多反应慢"不是核心问题，核心还是上下文窗口与成本

行业认知

RAG 是目前大模型领域少有的能真正挣钱、有业务驱动的产品类型

工程师的工作主要就是两件事：① 搭 RAG 系统 ② 特定场景做微调

应用场景

企业知识库智能问答

法律/医学咨询

代码生成与修复

Cursor 就是 RAG + 大模型

企业/个人知识库问答

RAG 的三大核心模块

数据（入库）模块

解析文档 → 分块（chunking） → 向量化 → 存数据库

不能把整个文档一股脑存进去（太长），必须切块入库

检索模块

用 query 去数据库找到相关的背景知识（chunk）

生成模块

把检索结果 + query 拼成提示词 → 输入大模型 → 输出答案

向量相似度与余弦相似度

词嵌入（Embedding）

高维空间中，每个词/每段文本都以向量形式存在（通过 embedding 模型把文本变成向量）

文字本身计算机无法理解语义，向量才能代表语义

语义相近的词，向量在空间中距离更近（聚类）

狗 ≈ 小狗（很近）；猫和狗（都是动物，较近）；手机 vs 狗（很远）

余弦相似度（Cosine Similarity）

用什么衡量两个向量的远近？→ 它们之间的夹角 θ

用两个向量的夹角衡量相似性

接近 0 → 垂直，无关

接近 1

夹角接近 0° → 非常相似（狗和小狗，夹角无限接近 0，cos 无限接近 1）

接近 -1 → 完全相反

Naive RAG 的完整流程

问题 query 经过 embedding 模型变成向量；

所有切好的 chunk 也都变成向量，存入向量数据库（比如 100 个向量）

query 向量和每个 chunk 向量算余弦相似度（算 100 个值）

取相似度最高的 top-K（如 top 5）个 chunk

把这 5 个 chunk 的原文文本（注意：不是向量！）和 query 拼接

一起输入大模型 → 生成答案

embedding 模型的输出维度（如 1536 维）和大模型没有任何关系

检索用向量，传给大模型的是文本，两者完全解耦，不存在"向量模型和大模型不匹配"的说法

LlamaIndex 框架

LlamaIndex 是目前最适合做 RAG 的框架（LangChain 耦合太重）

五大核心功能

Data Connectors（数据连接器）

把各种来源的数据（PDF、数据库、网页、API、音频知识库、自定义源……）解析成文本，连进系统

不用框架的话，每种格式都要自己写一套处理 pipeline；LlamaIndex 已经写好了，直接调

Data Indexes（数据索引）

把解析出来的文字做切分（chunk）→ embedding 向量化 → 加 metadata 标签 → 构建索引 → 入库

索引的目的：为了方便快捷地搜索

（Data Connectors 和 Data Indexes 中间夹着一个 data processing 数据处理环节：切块 + 打标签。）

Engines（引擎）

把整个流程驱动起来——query 进来 → 去库里检索 → 把结果拼接 → 回答 query。查询引擎、聊天引擎都在这

Data Agents（数据代理）

定义多条自动化工作流（不同链路），让大模型判断走哪条

例：你有 10 个文档，既有研报、又有公司规章制度。用户问"发票怎么报销"→ 走规章制度那条线；问"这个产品怎么卖"→ 走研报推理那条线。两条线的提示词和流程都不一样，分开才能获得更准确的结果

Application Integrations（应用集成）

把 RAG 能力接入生产环境——在 FastAPI 后端里直接调用封装好的接口，一行代码实现功能调用

数据模块（Data Connectors）

数据模块要处理 4 件事：数据解析 → 文档分块 → 向量存储 → 索引构建。

如何扩大数据来源

只解析了本地 PDF，网页、SQL/MongoDB 数据库能不能也拿进来做上下文

LlamaHub 生态 + 混合加载

LlamaHub

大量别的工程师集成好的工具（数据处理 pipeline、agent 工作流）

BeautifulSoupWebReader —— 输入网址 URL 就能读取网页内容，，还有异步网页读取、graph store（连 Neo4j 建知识图谱）等

代码（本地 + 网页混合加载）

图片、表格数据怎么处理

利用专业文档解析工具

工具清单

MinerU（开源，效果好）

Marker（开源）

DeepDoc（RAGFlow 底层的深度文档解析，实战项目就基于它改造）

LlamaCloud / LlamaParse（云服务，目前 SOTA）

每天约 1000 次免费解析，做 demo/原型完全够

原型做完再替换成 DeepDoc 等自部署方案

解析成 Markdown

有主/副标题层级

方便给 chunk 打标签

属于哪章哪节；子章节有 10 个 chunk，可以同时贴上子章节+大章节标签

段落之间有 markdown 标记分隔

段落提取、切分容易

表格用 markdown 表格语法保留结构

年份和净利润一一对应，大模型读得懂

工业上文档解析完一般就三个去处

Markdown

图数据库

ES

PDF 解析全流程

PDF 为什么最难

分栏、表格、图片、扫描件混杂，全是非结构化数据

阶段 1：预处理 + 内容分离

提取数据、清洗页眉页脚、无关链接

把内容分成三类：文字、表格、图像

文字识别分两种情况

普通 PDF

用 PyMuPDF 等 Python 库直接提取

扫描件（本质是图片）

必须用 OCR（光学字符识别，把图片里的文字识别出来）

阶段 2：表格识别 + 图像识别

表格是 PDF 中极难处理的格式

三大难点

跨页表格

一个表占 3 页，分页解析后彼此分离

且第 2、3 页没有表头 → 要写逻辑判断"哪两个表该连起来、哪些该分开"

复杂表头错位

表头占两列、内容只有一列 → 放进 markdown 就对不齐

表格间夹着页眉页脚

要识别并剔除

图像识别

把图片分离出来 → 调多模态大模型生成文字描述

阶段 3：版面布局分析（Layout Analysis）

三类内容分别处理完后，按原来的位置放回去

保留文档的逻辑结构和上下文顺序

表格的 markdown、文字的 markdown、图片描述的 markdown，各归其位

阶段 4：内容整合与输出

按规则清洗 → 得到干净的文档 → 切分成不同 chunk → 进入下一步

数据索引（Data Indexes）

切分、打标、索引、入库

Chunk 切分为什 么至关重要

检索精度和相关性

一个段落被从中间切断 → 语义不完整 → 检索不到完整信息

一个表格被拦腰截断 → 下半段没有表头 → 无法分析数据间关系

极端情况：一句至关重要的总结性的话被切成两块 → 这句话"没了"

向量表示与相似度计算（块大小的两难）

切得大 → 语义完整，但一个块里包含太多意思 → 向量和 query 难以精确匹配

切得小 → 每句语义精确，但块数量爆炸 → 检索效率大降

生成质量

残缺的句子、截断的表格传给大模型 → 不可能有好答案

不同领域策略不同

技术文档：多是 markdown → 直接按 markdown 结构切

医疗领域：很多"疾病—症状—药品"关系 → 适合知识图谱

法律文件：按条款切 + 打各种标签

切分策略

基于规则的切分

固定长度切分

每 1000 token 一刀切，不管内容

最原始

结构化切分

按段落、标题、markdown 标记切

常与固定长度结合：段落太长再按长度细分

滑动窗口切分

相邻两块之间保留重叠（overlap）：下一块不从上一块结尾开始，而是向前回退一段

保证没有一句话被切成两半，每句话都有完整语义

基于分隔符切分

识别 markdown/HTML 标签（如 <table>），把表格整体提出、不断行

保表格完整

分层递归切分

先按章节大单位切，再逐层细分到段落、句子

多级索引

基于语义的切分

相邻段落做 embedding 算余弦相似度：相似就合并、不相似就切开 → 保证一个块只表达一个意思（例：块 A 讲"2024 大模型发展迅速"，块 B 讲"但还存在很多困难"，该分开）

不断试探：往块里多加一句、两句后，embedding 相似度和原来比变化大不大？变化大 → 到了语义边界，在此切分

提取三元组（实体-关系-实体），以知识图谱方式保证相关实体关系在同一块（GraphRAG 思路）

工业中一般就用规则切分 + 分词信息 + 文本信息做规则召回

语义切分效果好，但整个过程太漫长——只有当规则切分效果不好时，才把语义加进来。

节点的 metadata（元数据）

每个节点（chunk）除了正文 text，还带一份 JSON 信息

file_path / file_name

用处是引用溯源

回答用户时告诉他"这个答案基于哪个文件"，用户还能点开原文件查看

这就是产品里"视觉交互、体验交互"的实现基础（呼应开头演示的"引用段落有据可依"）

metadata 不参与 embedding

excluded_embed_metadata_keys 里列的字段不进向量——embedding 只由 text 正文构成

metadata 是"构造数据"，随时取用但不参与语义

metadata 过滤的双重收益

例：问"同仁堂 2024 年股价趋势"→ 先按 metadata 过滤，只留同仁堂的文件，排除百果园等其他研报 → 再做相似度检索

收益 1：加速——相似度计算的复杂度远高于直接过滤；

索引类型

VectorStoreIndex（向量索引）

90% 的场景：向量 + metadata（PDF 等非结构化文档）

KnowledgeGraph（知识图谱索引）

结构化关系数据，GraphRAG 用

SummaryIndex（摘要索引）

"总结全文"类查询（后面 Agent 部分用到）

ListIndex（列表索引）

SQL 数据库类，顺序遍历

KeywordTableIndex（关键词索引）

基于关键词检索最快

向量数据库选型

Demo / 轻量

FAISS（近似最近邻检索，效率远超内置库）、Chroma

工业

Milvus（国内用得最多：本地 + 云端都支持，灵活）、Elasticsearch (ES)

图数据库

Neo4j

模型设置 + FAISS 入库检索六步

换模型（Settings）

LlamaIndex 默认内嵌 GPT-3.5 → 效果一般，要换成自己的模型（GPT-4o / DeepSeek / 千问，甚至自己微调后部署在本地或云端的模型——前两节课教过微调和部署云服务）

embedding 模型就是：输入"小猫小狗"（文本）→ 输出它在向量空间里的向量

FAISS 六步流程

第 1 步：创建 FAISS 索引

第 2 步：创建存储上下文

第 3 步：节点列表 → 向量索引（这一步对每个节点做 embedding，向量+metadata 一起入库）

第 4 步：创建向量检索器（similarity_top_k=5：召回相似度最高的 5 个 chunk）

第 5 步：创建查询引擎（定义好"query 进 → 答案出"的完整管道）

第 6 步：执行查询

代码

Debug 技巧：单独查看检索结果

retrieved_nodes = vector_retriever.retrieve("同仁堂安宫牛黄丸的市场价格") for i, node in enumerate(retrieved_nodes):     print(f"节点 {i+1} | 相似度得分: {node.score}")     print(node.node.text)

返回 top 5 节点的内容和分数，先看检索回来的东西对不对，再决定优化哪个环节。

查询引擎（Engines）与对话能力

Query Transformation（查询变换）三件套

Query Router（路由）

意图识别：不同类型问题走不同链路

"发票怎么报销"（查制度，直接答）vs"产品怎么卖"（需要推理）——想精确就必须走不同管道、不同提示词

Query Rewrite（改写）

用户输入不清晰 → 大模型重写 query；不健康内容（黄暴）→ 改写/拦截

口语化问题改写成规范检索语句

Query Planning（规划）

复杂问题拆成多步子问题，分别检索、汇总回答

"产品怎么卖"→ 拆成：① 产品信息 ② 政策利好利空 ③ 与竞品的优劣势 ④ 目标客户痛点 → 全部扩写后分别检索 → 综合回答更全面

检索和最终生成时，传的是做过 transformation 之后合成的 query，不是最初那句原始 query

常见问题

检索不到就拒答

默认模板下问"詹姆斯是谁"（知识库里没有）→ 直接拒绝回答

解法：自定义 system_prompt（提示词工程在这里用上）

要基于检索回来的信息回答问题，如果没有检索回来信息，根据你自身的能力回答，不要不回答问题。

没有记忆（多轮对话断裂）

先问"詹姆斯是谁"，再问"你能告诉我更多吗" → 它反问"你想了解什么" → 每个 query 完全割裂

ChatMemoryBuffer（记忆组件）

数据代理（Data Agents）—— 多条链路

不同类型的问题 → 不同的处理链路 → 把每条链路封装成一个工具 → 让大模型自己判断调哪个（和 Function Call 一个思路，Agent 和 RAG 分不开）。

链路 1：vector_tool（向量检索工具） —— 回答"具体数字类"问题

summary_tool（摘要工具） —— 回答"总结全文"类问题

让大模型自主选择链路

RAG 目前存在的问题

查询模块（Query Understanding）：意图识别偏差

案例："近三年研发投入增长率？"→ 系统只返回各年绝对值，没算增长率；"'三农'出现几次？"→ 返回含该词的段落而非统计。

优化：加意图识别层（事实检索/数值计算/统计分析分类）；模糊问题主动反问澄清；明确声明能力边界

数据处理入库模块：数据组织不当

案例：PDF 合同里的图片条款没 OCR → 提取不出违约金；新旧政策混杂无时间戳 → 推荐了已取消的窗口。

优化：实体关系抽取建三元组；图片表格 OCR + 结构化存储（PaddleOCR、Camelot）；加生效时间戳 + 版本控制；按业务场景主动降噪

检索匹配模块（Retrieval）：语义匹配与上下文理解不足

问《三体》"黑暗森林法则核心思想"→ 匹配到无关的早餐描写（纯向量检索不懂叙事逻辑）

语义动态分块；章节-段落-句子多级索引；混合检索（BM25 关键词 + 向量）；HyDE（让大模型生成假设文档，用它提升召回）；上下文扩展

知识回答模块（Generation）：信息整合与推理缺失

多轮对话断裂（"糖尿病能吃西瓜吗"答对了，追问"每天吃多少"却跳到水果种植）；数值推理编造结论

生成时融合外部工具（要计算 → 调计算器插件；要推理 → 思维链 + 知识图谱验证）；对话状态跟踪（DST）；设置对话边界约束

RAG 的瓶颈

强定制化依赖

很难有一个框架在所有场景都效果极好

做 to B 交付时，几乎每个场景都要大量定制

依赖大模型自身能力

法律/金融/医疗场景，即使检索内容是对的，模型不懂这个专业也答不对

给你一本医书，你能查资料，但病人说了症状，你依然诊断不出来。