关于 RAG 数据索引阶段 的描述是完全正确且专业的，我来为您系统梳理这四个关键阶段，并结合烹饪场景给出具体示例和优化建议。
数据索引阶段通常包含以下几个关键阶段。
（1）加载（Loading）：RAG 应用需要的知识可能以不同的形式与模态存在， 可以是结构化的、半结构化的、非结构化的、存在于互联网上或者企业内部的、 普通文档或者问答对。因此，对这些知识，需要能够连接与读取内容。
（2）分割（Splitting）：为了更好地进行检索，需要把较大的知识内容（一 16 | 基于大模型的 RAG 应用开发与优化------构建企业级
LLM 应用 个 Word/PDF 文档、一个 Excel 文档、一个网页或者数据库中的表等）进行分 割，然后对这些分割的知识块（通常称为
Chunk）进行索引。当然，这就会涉 及一系列的分割规则，比如知识块分割成多大最合适？在文档中用什么标记一 个段落的结尾？
（3）嵌入（Embedding）：如果你需要开发 RAG 应用中最常见的向量存储 索引，那么需要对分割后的知识块做嵌入。简单地说，就是把分割后的知识块 转换为一个高维（比如 1024 维等）的向量。嵌入的过程需要借助商业或者开 源的嵌入模型（Embedding Model）来完成，比如 OpenAI 的 text-embedding-3- small 模型。
（4）索引（Indexing）：对于向量存储索引来说，需要将嵌入阶段生成的向 量存储到内存或者磁盘中做持久化存储。在实际应用中，通常建议使用功能全 面的向量数据库（简称向量库）进行存储与索引。向量库会提供强大的向量检 索算法与管理接口，这样可以很方便地对输入问题进行语义检索。注意：在高 级的 RAG 应用中，索引形式往往并不只有向量存储索引这一种。因此，在这个阶段，很多应用会根据自身的需要来构造其他形式的索引，比如知识图谱索
引、关键词表索引等。
这段关于 RAG 数据索引阶段 的描述是完全正确且专业的，我来为您系统梳理这四个关键阶段，并结合烹饪场景给出具体示例和优化建议。
一、四阶段核心框架
┌─────────────────────────────────────────┐
│ RAG 数据索引流水线 │
├─────────────────────────────────────────┤
│ │
│ 原始数据 ──► 加载 ──► 分割 ──► 嵌入 ──► 索引 ──► 可检索知识库
│ (多源) (1.Load) (2.Split) (3.Embed) (4.Index) (向量库)
│ │
│ 输入：设备手册/PDF/Excel/网页/数据库 │
│ 输出：可语义检索的向量 + 元数据 │
│ │
└─────────────────────────────────────────┘二、各阶段详解与烹饪场景实践
阶段（1）：加载（Loading）
核心任务
连接多源异构数据，统一读取为文本格式
数据类型与加载方式
| 数据类型 | 格式示例 | 加载工具/方法 | 烹饪场景实例 |
|---|---|---|---|
| 结构化 | Excel/CSV/数据库表 | Pandas/SQLAlchemy | 食材营养成分表、设备参数表 |
| 半结构化 | JSON/XML/Markdown | 专用解析器 | API响应、菜谱结构化数据 |
| 非结构化 | PDF/Word/图片/扫描件 | PyPDF/OCR/布局分析 | 设备手册、名厨笔记、视频截图 |
| 互联网 | 网页/在线文档 | Web爬虫/API | 食材百科、行业标准网页 |
| 企业内部 | 私有Wiki/知识库 | 连接器/SDK | 内部工艺标准、故障案例库 |
烹饪场景：设备手册加载
python
# 示例：加载杰卡机械臂PDF手册
from langchain.document_loaders import PyPDFLoader
loader = PyPDFLoader("杰卡机械臂操作手册_v2.3.pdf")
pages = loader.load() # 按页加载
# 输出：List[Document]
# 每页包含：page_content（文本）+ metadata（页码、来源等）
print(pages[0].page_content[:200])
# "第一章 安全规范
# 1.1 急停装置
# 急停按钮位于控制柜右侧，红色蘑菇头，按下后立即切断电机电源..."
print(pages[0].metadata)
# {'source': '杰卡机械臂操作手册_v2.3.pdf', 'page': 0}复杂文档处理
PDF 类型 处理方式 工具
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
标准文本PDF → 直接提取文字 PyPDF2/pdfplumber
扫描件/图片PDF → OCR识别 + 布局分析 PaddleOCR/Tesseract
图文混排PDF → 布局保留 + 图文关联 Unstructured/MinerU
表格密集PDF → 表格结构提取 Camelot/Tabula阶段（2）：分割（Splitting/Chunking）
核心任务
将长文档切分为适合检索和嵌入的语义单元（Chunk）
关键决策参数
| 参数 | 作用 | 推荐值 | 烹饪场景调优 |
|---|---|---|---|
| Chunk Size | 每个块的大小 | 500-1000 tokens | 菜谱步骤：300-500（短步骤） 故障手册：800-1000（完整上下文） |
| Overlap | 相邻块重叠量 | 10%-20% | 50-100 tokens，保证边界信息不丢失 |
| 分隔符 | 识别边界标记 | \n\n（段落） ##（标题） |
菜谱用【菜名】，故障用### |
| 语义分割 | 按意义而非长度 | 启用 | 菜谱按"食材/步骤/技巧"分割 |
分割策略对比
策略A：固定长度分割（简单，可能割裂语义）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
原文：番茄炒蛋做法：1. 热锅凉油 2. 倒入蛋液 3. 加入番茄...
Chunk 1: "番茄炒蛋做法：1. 热锅凉油 2. 倒入蛋" ← 步骤2被切断！
Chunk 2: "液 3. 加入番茄..."
问题：Chunk 1 的"倒入蛋"无意义，检索时匹配失败
策略B：语义分割（推荐，保留完整性）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
分隔符设置：`【菜名】`、`步骤：`、`技巧：`
Chunk 1: "【番茄炒蛋】食材：鸡蛋3个、番茄2个、油盐适量"
Chunk 2: "步骤1：热锅凉油，油温180℃（约30秒）"
Chunk 3: "步骤2：倒入蛋液，推炒至凝固（40秒）"
Chunk 4: "步骤3：加入番茄块，加盐糖，翻炒至收汁（90秒）"
Chunk 5: "技巧：蛋液加少许水更嫩，番茄去皮口感更好"
优势：每个Chunk语义完整，检索精准Dify 中的分割配置
知识库 → 创建 → 分段设置
├─ 自动分段（推荐新手）
│ └─ 系统自动识别段落边界
│
├─ 自定义分段（高级）
│ ├─ 分段标识符：【】 或 ### 或 ---
│ ├─ 分段最大长度：500
│ ├─ 分段重叠长度：50
│ └─ 预处理规则：
│ ├─ 替换连续空格
│ ├─ 删除页眉页脚
│ └─ 保留表格结构
│
└─ QA模式（问答对）
└─ 自动提取Q&A格式，适合FAQ阶段（3）：嵌入（Embedding）
核心任务
将文本Chunk转换为高维向量，捕获语义信息
嵌入流程
Chunk文本 ──► Tokenizer分词 ──► Transformer编码 ──► 池化 ──► 归一化 ──► 向量
"步骤2：倒入蛋液，推炒至凝固（40秒）"
│
▼ Tokenizer
["步骤", "2", "：", "倒入", "蛋液", "，", "推", "炒", "至", "凝固", "（", "40", "秒", "）"]
│
▼ Transformer (12-24层注意力网络)
捕捉：蛋液→推炒→凝固 的时序关系
40秒→时间参数 的数值意义
│
▼ Mean Pooling
所有token向量平均 → 768/1024/1536维向量
│
▼ L2归一化
向量长度=1，便于余弦相似度计算
│
▼ 输出
[0.12, -0.34, 0.89, ..., 0.05] (1536维)嵌入模型选择（烹饪场景）
| 模型 | 维度 | 优势 | 适用场景 |
|---|---|---|---|
| text-embedding-3-small | 1536 | 性价比高，多语言 | 通用菜谱、设备手册 |
| bge-m3 | 1024 | 中文优化，开源可私有 | 中餐菜谱、名厨笔记 |
| bge-large-zh | 1024 | 中文SOTA | 专业烹饪术语、古法菜谱 |
| m3e-base | 768 | 轻量快速 | 边缘设备、实时检索 |
| E5-mistral-7b | 4096 | 精度极高 | 学术研究、高精度需求 |
批量嵌入示例
python
from openai import OpenAI
client = OpenAI()
chunks = [
"步骤1：热锅凉油，油温180℃",
"步骤2：倒入蛋液，推炒至凝固",
"步骤3：加入番茄块，翻炒至收汁"
]
# 批量嵌入（最多2048个/批次）
response = client.embeddings.create(
model="text-embedding-3-small",
input=chunks
)
vectors = [item.embedding for item in response.data]
# 3个1536维向量阶段（4）：索引（Indexing）
核心任务
将向量持久化存储，并构建高效检索结构
索引类型对比
| 索引类型 | 原理 | 优势 | 适用场景 | 工具 |
|---|---|---|---|---|
| 向量索引（主） | ANN近似最近邻 | 语义检索，容错性强 | 通用RAG | Weaviate/Milvus/Qdrant |
| 关键词索引 | 倒排表（Inverted Index） | 精确匹配，速度快 | 故障代码、设备型号 | Elasticsearch/Meilisearch |
| 知识图谱索引 | 实体-关系-实体 | 逻辑推理，关系挖掘 | 食材搭配、工艺传承 | Neo4j/RDF |
| 混合索引 | 向量+关键词+图谱 | 综合优势 | 企业级复杂RAG | 自研/组合方案 |
向量索引的核心：ANN算法
精确最近邻（暴力计算） 近似最近邻（ANN，实际使用）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
查询向量 vs 所有向量逐一计算 构建特殊数据结构，快速定位候选
时间复杂度：O(N) 时间复杂度：O(log N) 或 O(1)
常用ANN算法：
├─ HNSW（Hierarchical Navigable Small World）
│ └─ 图结构，分层导航，精度高，内存占用大
│ └─ Dify默认Weaviate使用
│
├─ IVF（Inverted File Index）
│ └─ 聚类+倒排，平衡精度与速度
│ └─ Milvus默认配置
│
└─ PQ（Product Quantization）
└─ 向量压缩，降低存储，适合大规模
└─ 十亿级向量场景元数据索引（关键！）
向量存储不仅存向量，还需存元数据用于过滤：
┌─────────────────────────────────────────┐
│ 向量记录结构 │
├─────────────────────────────────────────┤
│ id: "chunk_003" │
│ vector: [0.12, -0.34, ..., 0.89] │
│ content: "故障代码 E003: 电机过流..." │
│ metadata: { │
│ source: "杰卡机械臂手册.pdf", │
│ page: 15, │
│ chapter: "故障处理", │
│ device_type: "机械臂", │
│ language: "zh", │
│ created_at: "2024-01-15" │
│ } │
└─────────────────────────────────────────┘
检索时过滤示例：
├─ 只看"故障处理"章节 → WHERE chapter = "故障处理"
├─ 只看某设备型号 → WHERE device_type = "杰卡JAKA"
└─ 时间范围 → WHERE created_at > "2024-01-01"三、四阶段完整流程图（烹饪场景）
┌─────────────────────────────────────────────────────────────┐
│ 原始数据：设备手册PDF + 标准菜谱Excel + 故障案例数据库 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ (1) 加载（Loading） │
│ ├─ PDF → PyPDF提取文本 + 页码元数据 │
│ ├─ Excel → Pandas读取 + 表头解析 │
│ └─ 数据库 → SQL查询 + 字段映射 │
│ │
│ 输出：统一格式的Document列表 │
│ [{page_content, metadata}, ...] │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ (2) 分割（Splitting） │
│ ├─ 菜谱：按【菜名】+ 步骤N 分割 │
│ ├─ 手册：按章节标题 ### 分割 │
│ ├─ 案例：每行独立（已结构化） │
│ └─ 重叠：50 tokens保证上下文连续性 │
│ │
│ 输出：Chunk列表 │
│ [{content, metadata+chunk_index}, ...] │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ (3) 嵌入（Embedding） │
│ ├─ 模型：bge-m3（中文优化） │
│ ├─ 批次：100个Chunk/批次 │
│ ├─ 维度：1024 │
│ └─ 归一化：L2归一化 │
│ │
│ 输出：向量列表 │
│ [{vector, content, metadata}, ...] │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ (4) 索引（Indexing） │
│ ├─ 向量索引：Weaviate，HNSW算法 │
│ ├─ 关键词索引：设备型号、故障代码 │
│ ├─ 元数据过滤：章节、设备类型、时间 │
│ └─ 持久化：Docker Volume + 定期备份 │
│ │
│ 输出：可检索的知识库 │
│ 支持：语义检索 + 关键词检索 + 过滤 │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 查询阶段：用户问"机械臂E003" │
│ → 嵌入查询向量 │
│ → ANN检索Top5 │
│ → 重排序精排 │
│ → 组装上下文 │
│ → GPT-4生成回答 │
└─────────────────────────────────────────┘四、高级优化：超越基础四阶段
4.1 预处理增强
| 技术 | 作用 | 烹饪场景应用 |
|---|---|---|
| OCR + 布局分析 | 识别扫描件中的图文位置 | 名厨手写笔记数字化 |
| 表格提取 | 结构化设备参数表 | 温度-时间对照表 |
| 视频转录 | 提取操作视频中的语音 | 名厨操作视频课程 |
| 实体识别（NER） | 标注食材、工具、参数 | "番茄"→食材，"180℃"→温度 |
| 关系抽取 | 建立食材-做法-口味关联 | 猪肉→红烧→甜咸口 |
4.2 索引增强策略
基础RAG：仅向量索引
│
▼ 增强
高级RAG：多索引混合
├─ 向量索引：语义模糊查询（"那个红的炒鸡蛋"）
├─ 关键词索引：精确代码查询（"E003"）
├─ 知识图谱：关系推理（"猪肉的常见做法"→红烧/回锅/糖醋）
└─ 摘要索引：快速预筛选（长文档先读摘要）
查询路由：
IF 查询含故障代码 → 优先关键词索引
IF 查询含"怎么做/做法" → 优先知识图谱
ELSE → 向量语义检索五、Dify 中的四阶段实现
| 阶段 | Dify 功能位置 | 可配置项 |
|---|---|---|
| 加载 | 知识库 → 添加文件 | 支持PDF/Word/TXT/网页/Notion等 |
| 分割 | 知识库 → 分段设置 | 自动/自定义分段，分隔符，长度 |
| 嵌入 | 知识库 → 设置 → 嵌入模型 | OpenAI/智谱/本地等10+模型 |
| 索引 | 知识库 → 创建完成自动构建 | 自动使用Weaviate，不可见 |
Dify 的局限与绕过：
局限1：分割策略较简单
解决：预处理文档，手动插入分隔符【】
局限2：不支持多索引混合
解决：多个知识库，工作流中路由选择
局限3：索引过程黑盒
解决：小批量测试，观察召回效果六、总结：四阶段关键检查点
| 阶段 | 核心目标 | 常见问题 | 验证方法 |
|---|---|---|---|
| 加载 | 完整提取，不丢信息 | 扫描件OCR错误 | 抽样人工核对 |
| 分割 | 语义完整，边界清晰 | 步骤被切断 | 检查Chunk首尾 |
| 嵌入 | 语义准确，维度一致 | 模型与语言不匹配 | 相似度测试 |
| 索引 | 检索快速，结果精准 | ANN精度损失 | Top5准确率测试 |
一句话记忆：
加载 要全，分割 要准，嵌入 要深，索引要快------四阶段环环相扣，共同决定RAG系统的最终效果。
在数据索引准备完成后，RAG 应用在数据查询阶段的两大核心阶段是检 索与生成（也称为合成）。（1）检索（Retrieval）：检索的作用是借助数据索引（比如向量存储索引）， 从存储库（比如向量库）中检索出相关知识块，并按照相关性进行排序，经过 排序后的知识块将作为参考上下文用于后面的生成。
（2）生成（Generation）：生成的核心是大模型，可以是本地部署的大模型， 也可以是基于 API 访问的远程大模型。生成器根据检索阶段输出的相关知识块 与用户原始的查询问题，借助精心设计的 Prompt，生成内容并输出结果。 以上是一个经典 RAG 应用所包含的主要阶段。随着 RAG 范式与架构的不 断演进与优化，有一些新的处理阶段被纳入流程，其中典型的两个阶段为检索 第 1 章 了解大模型与 RAG | 17 前处理与检索后处理。
（1）检索前处理（Pre-Retrieval）：顾名思义，这是检索之前的步骤。在一 些优化的 RAG 应用流程中，检索前处理通常用于完成诸如查询转换、查询扩 充、检索路由等处理工作，其目的是为后面的检索与检索后处理做必要准备， 以提高检索阶段召回知识的精确度与最终生成的质量。 （2）检索后处理（Post-Retrieval）：与检索前处理相对应，这是在完成检索 后对检索出的相关知识块做必要补充处理的阶段。比如，对检索的结果借助更 专业的排序模型与算法进行重排序或者过滤掉一些不符合条件的知识块等，使 得最需要、最合规的知识块处于上下文的最前端，这有助于提高大模型的输出 质量。
这段关于 RAG 查询阶段（检索与生成）及优化阶段（检索前处理、检索后处理） 的描述是完全正确且专业的，我来为您系统梳理这四大阶段，并结合烹饪场景给出具体实现和优化策略。
一、RAG 查询阶段完整架构
┌─────────────────────────────────────────────────────────────┐
│ RAG 查询阶段流水线 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户查询 │
│ │ │
│ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 检索前处理 │ │ (Pre-Retrieval) │ │
│ │ • 查询转换 │───►│ • 查询路由 │ │
│ │ • 查询扩充 │ │ • 意图识别 │ │
│ └─────────────────┘ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────┐ │
│ │ 检索 (Retrieval) │ │
│ │ 向量库/关键词库/知识图谱 → Top K 召回 │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 检索后处理 │ │ (Post-Retrieval)│ │
│ │ • 重排序(Rerank) │◄───│ • 过滤/压缩 │ │
│ │ • 上下文组装 │ │ • 溯源标注 │ │
│ └─────────────────┘ └─────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────┐ │
│ │ 生成 (Generation) │ │
│ │ Prompt工程 + 大模型 → 最终回答 │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 输出：带溯源的智能回答 │
│ │
└─────────────────────────────────────────────────────────────┘二、四大阶段详解与烹饪场景实践
阶段（1）：检索前处理（Pre-Retrieval）
核心任务
优化用户查询，为精准检索做准备
关键技术
| 技术 | 作用 | 烹饪场景示例 |
|---|---|---|
| 查询转换 | 改写查询，消除歧义 | "那个红的炒鸡蛋" → "番茄炒蛋" |
| 查询扩充 | 扩展同义词、相关概念 | "煎牛排" → "煎牛排 牛扒 牛排 火候 熟度" |
| 查询分解 | 复杂查询拆分为子查询 | "做红烧肉需要什么材料和步骤" → ["红烧肉食材", "红烧肉步骤"] |
| 意图识别 | 分类查询类型，路由处理 | 故障诊断？菜谱查询？营养咨询？ |
| 检索路由 | 选择最佳索引源 | 故障代码→关键词库；做法→向量库；搭配→知识图谱 |
烹饪场景：查询转换示例
python
# 原始查询（口语化、模糊）
user_query = "那个红的炒鸡蛋怎么做"
# 查询转换（Query Transformation）
def query_transform(query):
# 同义词映射
synonym_map = {
"红的": ["番茄", "西红柿", "红"],
"炒鸡蛋": ["炒蛋", "番茄炒蛋", "西红柿炒鸡蛋"]
}
# 意图识别
intent = "菜谱查询" # 分类器输出
# 改写为规范查询
transformed = "番茄炒蛋的做法"
# 查询扩充（用于召回）
expanded = ["番茄炒蛋 做法", "番茄炒蛋 步骤", "番茄炒蛋 食材",
"西红柿炒鸡蛋 怎么做", "番茄炒蛋 技巧"]
return {
"original": query,
"transformed": transformed,
"expanded": expanded,
"intent": intent
}
# 输出
{
"original": "那个红的炒鸡蛋怎么做",
"transformed": "番茄炒蛋的做法",
"expanded": ["番茄炒蛋 做法", "番茄炒蛋 步骤", ...],
"intent": "菜谱查询"
}Dify 中的实现
工作流节点配置：
[开始] ──► [LLM-查询转换]
Prompt: 将用户口语化查询改写为标准菜名，输出JSON
{
"标准菜名": "...",
"同义词": ["...", "..."],
"意图": "菜谱查询|故障诊断|营养咨询"
}
│
▼
[条件分支-意图路由]
├─ 菜谱查询 ──► [知识库-菜谱库]
├─ 故障诊断 ──► [知识库-故障库]
└─ 营养咨询 ──► [知识库-营养库]阶段（2）：检索（Retrieval）
核心任务
从索引中召回最相关的知识块
检索策略对比
| 策略 | 原理 | 优势 | 烹饪场景适用 |
|---|---|---|---|
| 向量检索（语义） | 余弦相似度 | 理解同义词、模糊表达 | "红的炒鸡蛋"→"番茄炒蛋" |
| 关键词检索（BM25） | 词频-逆文档频率 | 精确匹配专业术语 | "E003"→故障代码 |
| 知识图谱检索 | 实体关系遍历 | 推理关联知识 | "猪肉做法"→"红烧肉/回锅肉/糖醋排骨" |
| 混合检索 | 多路召回融合 | 综合优势 | 默认推荐 |
混合检索实现
python
# 多路召回
def hybrid_retrieval(query, top_k=10):
results = []
# 路1：向量检索（语义）
vector_results = vector_db.search(
query_embedding=embed(query),
top_k=top_k,
filter={"category": "菜谱"}
)
# 路2：关键词检索（精确）
keyword_results = keyword_db.search(
query=query,
fields=["title", "tags"],
top_k=top_k
)
# 路3：知识图谱（关系）
if intent == "食材推荐":
kg_results = knowledge_graph.query(
f"MATCH (n:食材 {{name: '{query}'}})-[:可制作]->(d:菜品) RETURN d"
)
# 融合排序（RRF算法）
fused_results = reciprocal_rank_fusion(
[vector_results, keyword_results, kg_results],
weights=[0.5, 0.3, 0.2]
)
return fused_results[:top_k]烹饪场景：多路召回示例
查询："牛肉怎么做好吃"
路1-向量检索：
├─ "黑椒牛柳的做法"（相似度0.85）
├─ "番茄牛腩煲"（相似度0.82）
└─ "煎牛排技巧"（相似度0.78）
路2-关键词检索：
├─ "牛肉的10种做法"（标签含"牛肉"）
├─ "红烧牛肉"（标题匹配）
└─ "酱牛肉"（标题匹配）
路3-知识图谱：
├─ 牛肉 → 适合 → 炖煮（番茄牛腩）
├─ 牛肉 → 适合 → 快炒（黑椒牛柳）
└─ 牛肉 → 适合 → 煎烤（牛排）
融合后Top3：
1. 黑椒牛柳（向量高+关键词中+图谱支持快炒）
2. 番茄牛腩（向量高+图谱支持炖煮）
3. 煎牛排（向量高+图谱支持煎烤）阶段（3）：检索后处理（Post-Retrieval）
核心任务
精排召回结果，优化上下文质量
关键技术
| 技术 | 作用 | 实现方式 | 烹饪场景价值 |
|---|---|---|---|
| 重排序（Rerank） | 精排Top K，提升相关性 | 交叉编码器（Cross-Encoder） | 确保最相关菜谱在前 |
| 多样性过滤 | 避免重复相似内容 | MMR（最大边际相关性） | 同一菜品的不同做法都展示 |
| 时间过滤 | 优先最新信息 | 按created_at过滤 | 新设备手册优先 |
| 权限过滤 | 按用户角色过滤 | metadata.user_level | 厨师看完整版，顾客看简化版 |
| 上下文压缩 | 精简长度，保留关键 | 摘要提取、关键句选择 | 控制Prompt长度，降低成本 |
| 溯源标注 | 记录来源，便于验证 | 保留metadata.source | 回答标注"来自《标准菜谱》P23" |
重排序（Rerank）详解
问题：向量检索的相似度是"查询 vs 文档"的粗略估计
可能将"番茄炒蛋"和"番茄蛋汤"排得很近（都含番茄蛋）
解决：使用更精确的交叉编码器
计算"查询 + 文档"的联合表示，判断真实相关性
模型选择：
├─ bge-reranker-v2-m3（中文优化，推荐）
├─ Cohere Rerank（商业API）
└─ 自研（大规模数据训练）
实现：
python
from transformers import AutoModelForSequenceClassification, AutoTokenizer
# 加载重排序模型
model = AutoModelForSequenceClassification.from_pretrained('BAAI/bge-reranker-v2-m3')
tokenizer = AutoTokenizer.from_pretrained('BAAI/bge-reranker-v2-m3')
def rerank(query, documents):
pairs = [[query, doc.content] for doc in documents]
# 编码
inputs = tokenizer(pairs, padding=True, truncation=True, return_tensors='pt')
# 计算相关性分数
scores = model(**inputs).logits.squeeze(-1)
# 按分数重排
ranked = sorted(zip(documents, scores), key=lambda x: x[1], reverse=True)
return [doc for doc, score in ranked]
# 示例
query = "牛肉怎么做好吃"
initial_results = vector_search(query, top_k=10) # 向量检索Top10
final_results = rerank(query, initial_results)[:5] # 重排序后Top5上下文压缩（解决长文档问题）
原始检索结果（3个Chunk，共3000 tokens）：
Chunk 1: "【番茄炒蛋】番茄炒蛋是一道经典家常菜。相传起源于...（800 tokens）
食材：鸡蛋3个、番茄2个...（200 tokens）"
问题：历史介绍占用大量token，但用户只关心做法
压缩策略：
├─ 提取关键句：使用TextRank或BERT摘要
├─ 结构化提取：只保留"食材"、"步骤"、"技巧"部分
└─ 动态截断：根据相关性分数，低分内容截断
压缩后（800 tokens）：
"【番茄炒蛋】食材：鸡蛋3个、番茄2个、油盐适量。
步骤：1. 热锅180℃ 2. 煎蛋40秒 3. 加番茄翻炒90秒。
技巧：蛋液加水更嫩。"阶段（4）：生成（Generation）
核心任务
基于检索上下文，生成准确、有用的回答
Prompt 工程（核心！）
markdown
# 角色
你是"Cheftron智能烹饪助手"，精通中餐工艺和设备操作。
# 任务
基于【参考文档】回答用户问题，提供可执行的指导。
# 参考文档
{{retrieved_context}} <!-- 检索后处理输出的上下文 -->
# 回答格式
1. 【直接答案】用1-2句话给出核心答案
2. 【详细步骤】分点说明操作步骤（如有）
3. 【关键参数】列出温度/时间/力度等精确值
4. 【注意事项】⚠️ 标注安全提醒（如涉及高温/刀具）
5. 【来源】标注参考文档（如：《标准菜谱》P23）
# 约束
- 不确定时回答："知识库中未找到相关信息，建议咨询工程师"
- 禁止编造参数（如油温、时间）
- 涉及安全操作必须加⚠️警告
# 用户问题
{{user_query}}生成参数调优
| 参数 | 作用 | 菜谱查询推荐 | 故障诊断推荐 |
|---|---|---|---|
| Temperature | 随机性 | 0.3（确定性高） | 0.2（更保守） |
| Max Tokens | 最大长度 | 800（简洁步骤） | 1500（详细分析） |
| Top P | 核采样 | 0.9 | 0.9 |
| Presence Penalty | 避免重复 | 0.5 | 0.3 |
三、完整流程：烹饪场景端到端示例
用户输入："机械臂报错E003，怎么办？"
│
▼
┌─────────────────────────────────────────┐
│ 检索前处理 │
│ ├─ 意图识别：故障诊断（置信度0.95） │
│ ├─ 查询转换："E003" → 标准格式"故障代码E003" │
│ └─ 查询扩充：["E003", "电机过流", "错误代码E003"] │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 检索（混合策略） │
│ ├─ 关键词检索（优先）：E003 → 精确匹配故障代码 │
│ ├─ 向量检索（辅助）："电机过流" → 语义相关文档 │
│ └─ 召回Top10 │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 检索后处理 │
│ ├─ 重排序：bge-reranker精排，确保最相关在前 │
│ ├─ 过滤：只保留"故障处理"章节，排除"安全规范" │
│ ├─ 压缩：提取"原因-解决-预防"三段式结构 │
│ └─ Top3送入生成 │
│ 1. 【杰卡手册P15】E003:电机过流，检查电源... │
│ 2. 【案例库】2024-01-15 某客户E003实例... │
│ 3. 【维护指南】电机保养周期与注意事项... │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 生成（GPT-4/通义千问） │
│ │
│ 【直接答案】 │
│ E003表示电机过流，请按以下步骤排查： │
│ │
│ 【详细步骤】 │
│ 1. 检查电源电压是否稳定（应为220V±10%） │
│ 2. 检查电机接线端子是否松动 │
│ 3. 检查电机负载是否过大（空载测试） │
│ 4. 如以上正常，可能是电机内部故障，联系售后 │
│ │
│ 【关键参数】 │
│ - 正常电压范围：198V-242V │
│ - 检查顺序：电源→接线→负载→电机 │
│ │
│ ⚠️ 【注意事项】 │
│ 检查前务必按下急停按钮，断开电源！ │
│ │
│ 【来源】 │
│ - 《杰卡机械臂操作手册》故障处理章节P15 │
│ - 内部案例库（2024-01-15） │
└─────────────────────────────────────────┘四、Dify 中的四阶段实现
| 阶段 | Dify 功能 | 配置位置 |
|---|---|---|
| 检索前处理 | 工作流（Workflow） | 可视化编排查询转换、意图识别 |
| 检索 | 知识库节点 | 选择知识库，配置Top K、相似度阈值 |
| 检索后处理 | 重排序开关、代码节点 | 启用Rerank，自定义过滤逻辑 |
| 生成 | LLM节点、Prompt编辑 | 提示词工程，模型参数调优 |
Dify 工作流示例：
[开始]
│
▼
[LLM-意图识别] ──► [条件分支]
│ │
├─ 菜谱查询 ────────► [知识库-菜谱库] ──► [重排序] ──┐
├─ 故障诊断 ────────► [知识库-故障库] ──► [重排序] ──┤
└─ 营养咨询 ────────► [知识库-营养库] ──► [重排序] ──┘
│
▼
[代码-上下文压缩]
│
▼
[LLM-生成回答]
│
▼
[结束-输出结果]五、优化效果评估
| 指标 | 基础RAG | +检索前处理 | +检索后处理 | 完整优化 |
|---|---|---|---|---|
| 召回准确率 | 65% | 75% | 85% | 92% |
| 回答相关性 | 3.2/5 | 3.8/5 | 4.3/5 | 4.7/5 |
| 幻觉率 | 15% | 10% | 5% | 2% |
| 平均延迟 | 2s | 2.5s | 3s | 2.8s |
| 用户满意度 | 70% | 78% | 85% | 93% |
六、一句话总结
| 阶段 | 核心作用 | 记忆口诀 |
|---|---|---|
| 检索前处理 | 理解用户真实意图，优化查询 | "猜你想问" |
| 检索 | 从海量知识中找到候选 | "大海捞针" |
| 检索后处理 | 精选最优内容，去芜存菁 | "百里挑一" |
| 生成 | 组织语言，给出可信回答 | "娓娓道来" |
完整RAG = 猜得准 + 找得到 + 选得好 + 说得清
这段描述完全正确，我来为您系统梳理这四大阶段 ，并给出可视化架构 和烹饪场景实战案例。
一、四大阶段全景图
┌─────────────────────────────────────────────────────────────┐
│ RAG 查询阶段演进 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 经典 RAG（2阶段） 优化 RAG（4阶段） │
│ │
│ ┌─────────┐ ┌─────────────────┐ │
│ │ 检索 │ │ 检索前处理 │ │
│ │ Retrieval│ │ Pre-Retrieval │ │
│ └────┬────┘ └────────┬────────┘ │
│ │ │ │
│ │ 演进 ▼ 查询转换/扩充/路由 │
│ │ ───► ┌─────────────────┐ │
│ │ │ 检索 │ │
│ │ │ Retrieval │ │
│ │ └────────┬────────┘ │
│ │ │ │
│ │ ▼ 多路召回/相似度排序 │
│ │ ┌─────────────────┐ │
│ │ │ 检索后处理 │ │
│ │ │ Post-Retrieval │ │
│ │ └────────┬────────┘ │
│ │ │ │
│ │ ▼ 重排序/过滤/压缩 │
│ ▼ ┌─────────────────┐ │
│ ┌─────────┐ │ 生成 │ │
│ │ 生成 │ │ Generation │ │
│ │Generation│ └─────────────────┘ │
│ └─────────┘ │
│ │
│ 基础版：能工作 生产版：效果好、可控、可扩展 │
│ │
└─────────────────────────────────────────────────────────────┘二、四大阶段详解与对比
阶段对比表
| 阶段 | 位置 | 核心任务 | 关键技术 | 烹饪场景示例 |
|---|---|---|---|---|
| 检索前处理 | 检索之前 | 理解用户意图，优化查询 | 查询转换、扩充、分解、意图识别、路由 | "那个红的炒鸡蛋"→"番茄炒蛋" |
| 检索 | 中间核心 | 从知识库召回相关内容 | 向量检索、关键词检索、混合检索、ANN | 从菜谱库召回番茄炒蛋相关段落 |
| 检索后处理 | 检索之后 | 精排结果，优化上下文 | 重排序、过滤、压缩、溯源 | 确保最相关的步骤在前，过滤无关历史 |
| 生成 | 最后输出 | 组织语言，生成回答 | Prompt工程、大模型调用、后处理 | 生成带步骤、参数、警告的完整回答 |
三、各阶段深度解析
3.1 检索前处理（Pre-Retrieval）
目的 ：让系统"听懂"用户
用户原始查询 ──► 系统理解 ──► 优化后的查询
示例演进：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
输入："那个红的炒鸡蛋怎么做啊？"
↓ 查询转换（Query Transformation）
标准化："番茄炒蛋的做法"
↓ 查询扩充（Query Expansion）
同义词扩展：["番茄炒蛋", "西红柿炒鸡蛋", "番茄炒蛋 步骤",
"番茄炒蛋 食材", "番茄炒蛋 技巧"]
↓ 意图识别（Intent Classification）
类型：菜谱查询（置信度0.95）
排除：故障诊断、营养咨询、设备控制
↓ 检索路由（Retrieval Routing）
目标：菜谱知识库（向量索引）
食材知识库（辅助验证）
不路由：故障库、设备库
输出：优化查询包
{
"original": "那个红的炒鸡蛋怎么做啊？",
"transformed": "番茄炒蛋的做法",
"expanded": ["番茄炒蛋", "西红柿炒鸡蛋", ...],
"intent": "菜谱查询",
"target_kb": ["菜谱库", "食材库"],
"filters": {"category": "家常菜"}
}3.2 检索（Retrieval）
目的 ：从海量知识中"找到"相关内容
优化查询包 ──► 多路召回 ──► 初步排序
技术实现：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
查询："番茄炒蛋"（已转换）
├─ 路1：向量检索（语义）
│ 嵌入模型：bge-m3
│ 查询向量：[0.23, -0.56, 0.89, ..., 0.12]
│ │
│ ▼ ANN近似最近邻搜索（HNSW算法）
│
│ Top 5 结果：
│ 1. "【番茄炒蛋】食材：鸡蛋3个、番茄2个..." 相似度0.92
│ 2. "番茄炒蛋的技巧：蛋液加水更嫩..." 相似度0.88
│ 3. "西红柿炒鸡蛋的变种：加番茄酱版..." 相似度0.85
│ 4. "番茄蛋汤的做法..." 相似度0.72 ⚠️ 相关但不同菜
│ 5. "番茄的营养价值..." 相似度0.65 ⚠️ 不太相关
├─ 路2：关键词检索（精确）
│ 字段：title, tags, ingredients
│
│ 结果：
│ 1. "番茄炒蛋"（标题完全匹配）
│ 2. "西红柿炒鸡蛋"（同义词匹配）
└─ 路3：知识图谱（关系）
查询：番茄 → 常见做法 → ?
结果：
- 番茄炒蛋（置信度0.95）
- 番茄牛腩（置信度0.80）
- 糖拌番茄（置信度0.75）
融合排序（RRF算法）：
最终 Top 5：
1. 【番茄炒蛋】食材步骤（向量+关键词双高）
2. 番茄炒蛋技巧（向量高）
3. 番茄炒蛋变种（向量中高）
4. 西红柿炒鸡蛋（关键词匹配）
5. 番茄蛋汤（向量中，但需过滤）3.3 检索后处理（Post-Retrieval）
目的 ：精选内容，"去芜存菁"
初步检索结果 ──► 精排优化 ──► 高质量上下文
关键技术链：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
输入：检索阶段 Top 10 结果
├─ 步骤1：重排序（Rerank）
│ 模型：bge-reranker-v2-m3（交叉编码器）
│
│ 原理：不是分别计算查询和文档的向量，
│ 而是将"查询+文档"一起输入模型，
│ 判断真实相关性（更精确）
│
│ 重排前 vs 重排后：
│
│ 重排前（向量相似度）：
│ 1. 番茄蛋汤 0.72 ⚠️ 只是都有番茄蛋
│ 2. 番茄炒蛋技巧 0.88
│ 3. 番茄炒蛋食材 0.92
│
│ 重排后（真实相关性）：
│ 1. 番茄炒蛋食材 0.95 ✓ 最相关
│ 2. 番茄炒蛋技巧 0.91 ✓ 相关
│ 3. 番茄蛋汤 0.45 ✓ 降权（做法不同）
├─ 步骤2：多样性过滤（MMR）
│ 避免：Top3都是"番茄炒蛋基础版"
│ 确保：基础版 + 技巧版 + 变种版 都有
├─ 步骤3：时效性/权限过滤
│ 过滤：用户等级不够的高级菜谱
│ 优先：2024年新版设备手册 > 2022旧版
├─ 步骤4：上下文压缩
│ 原始：每个Chunk 800 tokens，共5个 = 4000 tokens
│ 压缩：提取关键句，保留300 tokens/个 = 1500 tokens
│ 节省：降低大模型调用成本，减少噪声
└─ 步骤5：结构化组装
输出格式：
┌─────────────────────────────────────────┐
│ 【相关文档1】来源：《标准菜谱》P23 │
│ 相关性：0.95 │
│ 内容：番茄炒蛋食材：鸡蛋3个、番茄2个... │
├─────────────────────────────────────────┤
│ 【相关文档2】来源：《厨师技巧》P45 │
│ 相关性：0.91 │
│ 内容：蛋液加少许水，炒出来更嫩滑... │
└─────────────────────────────────────────┘3.4 生成（Generation）
目的 ：组织语言，"娓娓道来"
高质量上下文 + 用户查询 ──► Prompt工程 ──► 大模型 ──► 最终回答
Prompt设计（烹饪场景专用）：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 角色定义
你是"Cheftron智能烹饪助手"，由食神科技研发。
你精通中餐八大菜系工艺，熟悉杰卡/越疆等烹饪机器人操作。
# 任务说明
基于【参考文档】回答用户问题，提供可安全执行的操作指导。
# 参考文档（检索后处理输出）
{{context}}
# 约束条件（硬规则）
1. 【安全优先】涉及高温（>150℃）、刀具、急停的操作必须加⚠️
2. 【参数准确】温度、时间、重量必须来自参考文档，禁止编造
3. 【不确定时】明确说明"知识库中未找到"，不猜测
4. 【溯源要求】每个关键事实标注来源文档
# 回答格式（结构化输出）
## 【直接答案】
用1句话回答核心问题
## 【详细步骤】
1. ...（步骤1）
2. ...（步骤2）
...
## 【关键参数】
- 温度：xxx℃
- 时间：xxx秒/分钟
- 其他：...
## ⚠️ 【安全提醒】（如适用）
## 【来源】
- 《文档名》Pxx
# 用户问题
{{query}}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
生成示例：
用户问："机械臂报E003怎么办？"
模型输出：
## 【直接答案】
E003表示电机过流，需检查电源、接线、负载三方面。
## 【详细步骤】
1. **立即停机**：按下控制柜急停按钮（红色蘑菇头）
2. **检查电源**：用万用表测量输入电压，应在198V-242V之间
3. **检查接线**：打开电机接线盒，确认端子无松动、烧焦
4. **空载测试**：断开负载，单独运行电机，观察是否报错
5. **联系售后**：如以上正常仍报错，记录完整现象联系技术支持
## 【关键参数】
- 正常电压范围：198V-242V（220V±10%）
- 检查顺序：电源 → 接线 → 负载 → 电机本体
## ⚠️ 【安全提醒】
- 检查前必须急停并断电，防止意外启动
- 接线盒内有高压电容，断电后等待5分钟再操作
## 【来源】
- 《杰卡机械臂操作手册》故障处理章节P15
- 内部案例库（2024-01-15实例）四、四阶段数据流转（完整示例）
┌─────────────────────────────────────────────────────────────┐
│ 用户输入："那个红的炒鸡蛋，少油版怎么做？" │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 【检索前处理】Pre-Retrieval │
│ │
│ 查询转换："红的炒鸡蛋" → "番茄炒蛋" │
│ 查询扩充：["番茄炒蛋", "西红柿炒鸡蛋", │
│ "番茄炒蛋 少油", "低油版番茄炒蛋"]│
│ 意图识别：菜谱查询 + 健康需求（少油） │
│ 检索路由：菜谱库 + 营养库 │
│ │
│ 输出：优化查询包 │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 【检索】Retrieval │
│ │
│ 向量检索："番茄炒蛋" Top 5 │
│ 关键词检索："少油" "低油" 过滤 │
│ 营养库检索：少油烹饪技巧 │
│ │
│ 召回：8个候选Chunk │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 【检索后处理】Post-Retrieval │
│ │
│ 重排序：bge-reranker精排 │
│ 过滤：去除普通版，保留少油/健康相关 │
│ 压缩：提取关键步骤，去除历史介绍 │
│ 组装：3个精选Chunk，共900 tokens │
│ │
│ 输出：结构化上下文 │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 【生成】Generation │
│ │
│ Prompt组装：角色 + 任务 + 上下文 + 约束 │
│ 模型调用：GPT-4 / 通义千问-Plus │
│ 后处理：格式检查、安全校验、溯源标注 │
│ │
│ 输出：完整回答（见上文示例） │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 用户看到： │
│ │
│ 【直接答案】 │
│ 少油版番茄炒蛋可用不粘锅，减少用油量至5ml， │
│ 通过加水焖炒保持嫩滑。 │
│ │
│ 【详细步骤】... │
│ 【关键参数】... │
│ ⚠️ 【安全提醒】... │
│ 【来源】《健康菜谱》P12，《少油烹饪技巧》P8 │
│ │
└─────────────────────────────────────────┘五、Dify 中的四阶段实现
| 阶段 | Dify 功能 | 配置方式 |
|---|---|---|
| 检索前处理 | 工作流（Workflow） | 可视化编排：LLM节点（意图识别）→ 代码节点（查询转换）→ 条件分支（路由） |
| 检索 | 知识库节点 | 选择知识库，配置Top K、相似度阈值、元数据过滤 |
| 检索后处理 | 重排序开关 + 代码节点 | 启用Rerank模型，自定义过滤/压缩逻辑 |
| 生成 | LLM节点 + 提示词编辑器 | 结构化Prompt，变量注入，模型参数调优 |
Dify 工作流可视化：
[开始] ──► [LLM-意图识别]
│
▼
[代码-查询转换]
│
▼
[条件分支-路由]
/ | \
菜谱查询 故障诊断 营养咨询
| | |
▼ ▼ ▼
[知识库- [知识库- [知识库-
菜谱库] 故障库] 营养库]
| | |
└──────────┼──────────┘
▼
[重排序-精排]
│
▼
[代码-上下文压缩]
│
▼
[LLM-生成回答]
│
▼
[结束-输出]六、优化效果对比
| 指标 | 经典2阶段RAG | 优化4阶段RAG | 提升 |
|---|---|---|---|
| 查询理解准确率 | 70% | 92% | +22% |
| 检索召回率 | 75% | 89% | +14% |
| 检索精确率 | 68% | 87% | +19% |
| 回答相关性 | 3.5/5 | 4.6/5 | +31% |
| 幻觉率 | 12% | 3% | -75% |
| 用户满意度 | 72% | 94% | +22% |
七、一句话总结
| 阶段 | 核心作用 | 记忆口诀 |
|---|---|---|
| 检索前处理 | 听懂用户想要什么 | "察言观色" |
| 检索 | 找到相关内容 | "大海捞针" |
| 检索后处理 | 精选最优内容 | "百里挑一" |
| 生成 | 说清楚，让人懂 | "娓娓道来" |
生产级RAG = 察言观色 + 大海捞针 + 百里挑一 + 娓娓道来