🎯 本课目标
- 理解 RAG Pipeline 完整流程
- 掌握 Dify 的知识库功能细节
- 面试能深聊检索策略选型
- 产出：一个完整的 RAG 问答系统
一、RAG 是什么------先不急着看 Dify
为什么需要 RAG？
大模型有两大痛点：
- 知识截止 --- GPT-4 的知识只到某个时间点
- 幻觉 --- 没见过的内容会瞎编
RAG（Retrieval-Augmented Generation）= 检索增强生成，流程：
用户提问 → 检索知识库 → 拿到相关文档片段 → 拼到 Prompt 里 → LLM 回答RAG vs 微调（Fine-tuning）
| 对比维度 | RAG | 微调 |
|---|---|---|
| 成本 | 低（不需要重新训练） | 高（需要 GPU 训练） |
| 更新 | 加文档就行 | 得重新训练 |
| 知识精度 | 高（检索原文） | 可能遗忘或记忆偏差 |
| 适用范围 | 知识问答、客服、文档 | 风格模仿、指令遵循 |
面试高频题：「你什么时候选 RAG，什么时候选微调？」
→ 标准答案：要精准引用原文用 RAG，要学新能力/风格用微调，最佳实践往往是两者结合。
二、Dify RAG 完整 Pipeline
Dify 的 RAG 是一条完整链路，每一步都有对应配置：
文档上传 → 文档预处理（清洗）→ 分段（Chunking）
→ Embedding 向量化 → 存入向量库
→ 用户提问 → 检索（向量/全文/混合）
→ 重排序（Rerank）→ 注入 Prompt → LLM 生成① 文档预处理
Dify 支持的文档格式：
- 文本类：TXT, Markdown, PDF, DOCX, HTML, CSV, JSON
- 代码类：各种源码文件
- 网页：通过 API 抓取（也可以用 Notebook 爬了再传）
预处理做了什么：
- 空行/空格清理
- HTML 标签剥离
- PDF 解析（注意表格和图片的极限）
⚠️ 面试坑点：Dify 对复杂 PDF（多栏、表格）解析一般，生产环境建议先用 Unstructured.io 或 LlamaParse 预处理再喂给 Dify。
② 分段策略（Chunking）--- 这是核心知识点
Dify 提供三种分段模式：
a) 段落分段（默认）
- 按自然段落（连续换行）拆分
- 每个段落作为一个片段
- 优点：语义完整，不会打断内容
- 缺点：段落长度差异大，长段落会截断
b) N 元分段（N-gram）
- 按固定字符数拆分
- 参数：分段长度 + 重叠长度（滑动窗口）
- 优点：控制粒度均匀
- 缺点：可能把一句话切成两半
c) 滑动窗口分段
- 类似 N-gram 但带上下文重叠
- 比如每 500 字符一段，与上一段重叠 100 字符
- 平衡方案：保持粒度 + 保留上下文衔接
分段的面试考点
「分段的理想大小是多少？」
- 没有标准答案，取决于检索场景
- 通用建议：200-500 tokens/段
- 太短 → 丢失上下文
- 太长 → 噪声多，检索不精确
「如果有表格怎么办？」
- Dify 原生对表格支持一般
- 建议分段前把表格转成 Markdown 或自然语言描述
③ Embedding（向量化）
文档分好段后，每一段转成一个向量（浮点数数组）。
嵌入模型的选择：
- Dify 支持多种嵌入模型：OpenAI text-embedding-3-small/large、text-embedding-ada-002、通义千问 embedding、BGE 系列等
- 维度：OpenAI ada-002 使用 1536 维，text-embedding-3-small 可选 512/1536 维
- 维度越高 ≠ 越好，1000+ 维足够
面试考点：
- 「你的向量库选什么？」 → Dify 支持 Qdrant, Weaviate, Milvus, pgvector, Chroma 等
- 「中文场景用什么嵌入模型？」 → BGE（BAAI）系列（bge-large-zh）、通义千问 text-embedding-v2/v3
- 「Embedding 维度怎么选？」 → 根据数据量和查询精度，1536 维够用，降维可以减少存储和计算
④ 检索模式（Retrieval）
Dify 提供三种检索模式：
a) 向量检索
原理：用户问题转向量 → 向量库找最近邻（余弦相似度/内积/欧式距离）
优点：语义理解好，同义句也能匹配
缺点：冷门关键词可能召回差b) 全文检索（Keyword / BM25）
原理：传统倒排索引，关键字匹配（类似 Elasticsearch）
优点：精确匹配，关键词命中率高
缺点：语义理解弱，"苹果"搜不到"水果"c) 混合检索 + 重排序（Hybrid Search + Rerank）⭐
原理：先同时跑向量检索 + 全文检索
然后合并结果 → 用 Rerank 模型重新排序
取 Top K
优点：语义 + 关键词双保险
缺点：需要额外部署 Rerank 模型，多一步延迟这是面试绝对会问到的高频点。
面试题：「为什么需要 Rerank？」
→ 向量检索和全文检索各自算出来的分数尺度不同，直接合并排序不合理。Rerank 模型拿用户问题和候选文档做交叉编码（Cross-encoder），重新打分的精度远高于向量余弦相似度。
⑤ 检索参数
在 Dify 知识库里配置检索时你会看到的参数：
| 参数 | 作用 | 建议 |
|---|---|---|
| Top K | 返回前 K 个片段 | 3-5 够用，太多会稀释关键信息 |
| Score 阈值 | 低于此分数的片段丢弃 | 0.3-0.5，看你的嵌入模型 |
| 分段数量限制 | 限制最终进入 Prompt 的片段数 | 一般 ≤5 |
⑥ Prompt 注入
检索到的文档片段会拼到 Prompt 中：
请基于以下文档回答问题：
<context>
{检索到的文档片段}
</context>
问题: {用户问题}Dify 中可以在知识库配置中定制这段 Prompt 模板。
三、Dify 知识库功能实操要点
创建知识库流程
- 知识 → 创建知识库 → 选择文档
- 设置分段策略（推荐滑动窗口 500+100）
- 选择嵌入模型
- 索引完成后可以预览和删除片段
- 检索测试：输入问题看召回效果
多知识库策略
- Dify 支持一个应用绑定多个知识库
- 场景：技术文档库 + 客服问答库 + 产品说明库
- 每个知识库可以独立配置不同的检索模式
知识库的维护
- 文档更新：重新分片 → 重新嵌入（新向量覆盖旧向量）
- 面试题：「知识库更新后，旧向量怎么处理？」
→ Dify 会在重新处理时自动替换该文档下的所有分段向量
四、面试高频题（RAG 专场）
Q1：双检索（混合检索）为什么比单向量检索好？
向量检索擅长语义相似，但精确关键词（产品型号、订单号）需要 BM25 命中。混合检索取两者之长。
Q2：Rerank 在 Pipeline 的哪个环节？成本怎么样？
检索后、生成前。Rerank 模型（如 BGE-Reranker-v2）需要额外 GPU 资源，但能显著提升 Top-K 命中率。
Q3：RAG 的检索准确度怎么优化？
技术层面：分段策略调优 + 嵌入模型选型 + 混合检索 + Rerank。非技术层面：清洗文档质量比调参更重要。
Q4：Dify vs LangChain 做 RAG 的区别？
Dify 开箱即用，LangChain 灵活但需要自己搭 Pipeline。面试可以说「Dify 适合快速验证和中小规模生产，LangChain 适合需要深度定制的大规模场景」。
Q5：百万级文档的 RAG 怎么优化？
- 多层索引（先分类再检索）
- 分段大小和 Top K 数量控制
- 增加 Rerank 精排
- 考虑多级缓存（热门问答缓存命中直接返回）
💻 实操产出：搭建一个 RAG 问答系统
建议大王今天实操：
- 在 Dify 里创建一个知识库，上传一个你手头的技术文档（比如 Python 文档、产品说明）
- 试不同的分段策略，看看效果差异
- 配置混合检索 + Rerank
- 在应用里引用这个知识库，跑几个问答题验证召回质量
课后小测验
- Dify 支持哪三种检索模式？各自优缺点是什么？
- 为什么混合检索需要搭配 Rerank？
- 分段太小和分段太大分别有什么问题？
- 面试中被问到「RAG vs 微调」你怎么答？
- Dify 知识库嵌入模型选型，中文场景推荐什么？
好，逐个讲。
Q1：Dify 支持哪三种检索模式？各自优缺点是什么？
答案：
| 检索模式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 向量检索 | 用户问题→嵌入→向量库找最近邻（余弦相似度） | 语义理解强，同义句也能匹配 | 冷门关键词召回差，精确型号/编号匹配弱 |
| 全文检索 | 传统倒排索引，BM25 关键字匹配 | 关键词精确命中，速度快 | 语义理解弱，"苹果"搜不到"水果" |
| 混合检索 | 向量+全文 双通道 → 合并 → Rerank | 语义+关键词双保险，召回精度最高 | 需要额外部署 Rerank 模型，多一步延迟 |
面试加分点：
Dify 的混合检索是"检索时并行、排重用 Rerank 精排"。向量和全文各自独立的分数尺度不同，不能直接相加排序------这就是为什么必须加一层 Rerank 做交叉编码重打分。
Q2：为什么混合检索需要搭配 Rerank？
核心原因：分数不可比
- 向量检索输出的 cosine similarity 取值范围是 -1, 1
- 全文检索（BM25）的分数是无上限的原始词频分
- 两者分数尺度不同，不能直接合并排序
Rerank 干了什么：
用户问题 + 候选文档 K1
用户问题 + 候选文档 K2
...
用户问题 + 候选文档 K100
↓
Rerank（Cross-encoder）逐对编码，输出统一的 [0,1] 相关性分数
↓
按新分数重排，取 Top K面试深度回答：
Rerank 用的是 Cross-encoder，跟向量检索的 Bi-encoder 不同。Bi-encoder 把问题和文档各自编码成向量，用余弦算相似------快但精度有限。Cross-encoder 把"问题+文档"一起过 transformer，注意力能直接在问题和文档之间交互，精度高出一个档次，但速度也慢了十倍。所以架构上：Bi-encoder 粗筛 Top 50-100，Cross-encoder 精排到 Top 3-5。
Q3：分段太小和分段太大分别有什么问题？
分段太小（< 100 tokens）：
- 一段只包含一句话或半句话，上下文被切碎
- 用户问一个需要前后文理解的问题，检索到的片段信息不完整
- 比如一份文档的介绍段："该系统的核心架构由三个组件组成...分别负责..."，如果切成两段，第一段只看到"三个组件"，第二段只看到"分别负责"，各自都缺少上下文
分段太大（> 1000 tokens）：
- 一段包含多页内容，噪声太多
- 用户问"配置文件的格式是什么"，命中了一个大段落，但大段落里还包含安装步骤、API 说明、示例代码......LLM 容易被噪声干扰
- 检索命中率表面高，但真正相关的内容占比低
最佳实践：
通用建议：200-500 tokens / 段
滑动窗口重叠：50-100 tokens（避免上下文断裂）
特殊场景调整：
- 代码文档 → 200-300（粒度细，按函数/方法分）
- 技术手册 → 300-500（完整覆盖一个小节）
- FAQ/问答 → 100-200（一问一答一个片段）Q4：面试中被问到「RAG vs 微调」你怎么答？
结构化回答：
RAG（检索增强生成） 微调（Fine-tuning）
───────────── ─────────────
输入： 从知识库检索相关文档 在训练数据上训练
输出： 依赖 LLM + Prompt 中的上下文 模型本身学到了新知识/能力
更新： 加文档就行，秒级生效 得重新训练，几小时到几天
成本： 低（存储+检索） 高（GPU 训练）
幻觉： ⚠️ 仍有，但可引用原文溯源 ⚠️ 可能遗忘或过拟合
适用： 知识问答、客服、产品文档 风格模仿、指令遵循、特定任务选择标准：
- 需要引用原文、可溯源的 → RAG
- 需要模型学会新能力、新风格的 → 微调
- 最佳实践：RAG + 微调 两者结合------基座模型先微调成领域专家，再挂 RAG 知识库做实时检索
面试能拿分的收尾：
「在实际生产里，我从来不把 RAG 和微调对立。基座模型先做轻量 LoRA 微调，学会领域术语和表达方式；上面挂 RAG 知识库，提供实时、可溯源的业务知识。微调把回答的专业度拉高，RAG 保证准确性和实时性，两者互补不互斥。」
Q5：Dify 知识库嵌入模型选型，中文场景推荐什么？
推荐排序：
| 推荐 | 模型 | 维度 | 适合场景 |
|---|---|---|---|
| 🥇 | bge-large-zh-v1.5（BAAI） | 1024 | 中文场景综合最优，社区最成熟 |
| 🥇 | bge-m3（BAAI） | 1024 | 多语言（中英日韩等），检索精度更高 |
| 🥈 | text-embedding-3-small/large（OpenAI） | 512/1536/3072 | 英文为主时选，中文也不错但不如 BGE |
| 🥈 | 通义千问 text-embedding-v2/v3（阿里） | 1536 | 阿里云用户首选，国内调用延迟最低 |
| 🥉 | m3e-base/m3e-large | 768/1024 | 轻量开源，小项目够用 |
选型建议：
中文为主 + 精度优先 → bge-large-zh-v1.5（1024维）
多语言混合 → bge-m3（1024维，支持 100+ 语言）
阿里云生态 → 通义千问 text-embedding-v3
预算有限 → m3e 系列或 bge-small-zh面试深度补充：
「BGE 系列是 BAAI 开源的，中文 SOTA。bge-m3 支持稠密检索 + 稀疏检索 + 多向量三种检索方式，算力够的话一步到位。维度方面可以基于 Matryoshka 表示学习降维到 256 维，精度损失 < 2%，但检索速度和存储都能翻倍。」