05-Dify社区版搭建RAG：零代码从零搭建企业级RAG应用

第 5 篇：Dify 社区版搭建 RAG——零代码从零搭建企业级 RAG 应用

本文为「从零到落地：RAG 检索增强生成实战系列」第 5 篇，完整系列持续更新中。

---

前言

本篇聚焦 Dify 社区版本地部署实战，从 Docker 一键部署到模型接入、知识库搭建、应用创建、API 调用，完整走一遍零代码 RAG 系统的全流程。

在第 4 篇里，你用原生 Python 手写了最简 RAG，5 个步骤、几十行代码，跑通了整个流程。但你肯定也感受到了——分块太粗糙、没有可视化界面、不支持多轮对话、非技术同事根本用不了。

这一篇换一种方式：Dify 社区版，一个开源免费的低代码 AI 应用平台，Docker 三条命令就能部署到本地，点几下鼠标就能完成知识库搭建、对话应用创建、检索参数调优。你在原生代码里手写的那些步骤，Dify 全部帮你封装好了。

本篇学完你将掌握：

• Dify 社区版的本地部署流程（Docker Compose 一键启动）
• 模型接入配置（商业 API + 本地 Ollama 两种方式）
• 知识库搭建：文档上传、分块规则配置、检索参数设置
• 对话应用创建：绑定知识库、Prompt 模板、对话测试
• 核心功能使用：检索溯源、Rerank 重排、多轮对话记忆
• API 调用与外部系统集成
• Dify 的优缺点和适用边界

---

一、Dify 社区版是什么

1.1 定位与核心能力

Dify 是一个开源的 LLM 应用开发平台，社区版（Community Edition）基于 Apache 2.0 协议开源免费，可以完全本地部署。它不是简单的”聊天机器人框架”，而是一套覆盖RAG 知识库、工作流编排、Agent 智能体、多模型管理的全链路 AI 应用开发环境。

本篇聚焦它的 RAG 知识库能力，这也是 Dify 最被广泛使用的功能之一。

核心能力	说明
知识库管理	上传文档 → 自动分块 → 向量化 → 检索，全程可视化
多种检索模式	向量检索、全文检索、混合检索 + Rerank 重排
分块策略	自动分段 / 自定义分段 / 父子分段，可按文档类型灵活配置
对话应用	绑定知识库创建对话助手，内置多轮对话记忆和流式输出
模型管理	统一接入商业 API（DeepSeek、OpenAI 等）和本地模型（Ollama 等）
API 优先	每个应用自动生成 RESTful API，可直接集成到业务系统

1.2 与原生手写 RAG 的对比

在第 4 篇手写 RAG 时我们踩过的那些坑，Dify 是怎么解决的：

原生手写的缺陷	Dify 的解决方案
固定字符数分块，容易切断语义	支持自动分段、自定义分段、父子分段，分块结果可视化
只支持 .md 文件	支持 PDF、Word、Markdown、TXT、HTML、CSV、XLSX 等多种格式
没有 Rerank 重排	内置 Rerank 模型支持，检索后自动重排提升精度
不支持多轮对话记忆	内置会话管理，自动维护对话历史
没有混合检索	向量检索 + 全文检索混合，可配置权重
纯命令行，非技术人员无法使用	完整的 Web 管理界面和聊天界面
内存存储，重启丢失	PostgreSQL + Weaviate/Qdrant 持久化存储

1.3 Dify 的系统架构

Dify 社区版 Docker 部署后，内部由以下组件构成：

浏览器访问（http://localhost）
        ↓
    Nginx（反向代理）
        ↓
┌───────────────────────────────────────────────┐
│              Dify 后端服务                      │
│   Web API（Flask）  +  Worker（Celery 任务队列） │
├──────────┬──────────┬──────────┬──────────────┤
│PostgreSQL│  Redis   │ Weaviate │   Nginx      │
│（元数据） │（缓存/队列）│（向量库） │ （静态资源）  │
└──────────┴──────────┴──────────┴──────────────┘

💡 提示：PostgreSQL 存储用户、知识库、对话历史等元数据；Redis 用于缓存和 Celery 异步任务队列；Weaviate 是默认的向量数据库（也支持切换为 Qdrant、Milvus 等）。这些组件全部由 Docker Compose 自动拉起，你不需要单独安装。

---

二、环境准备与部署

2.1 硬件和软件要求

环境项	最低要求	推荐配置
CPU	2 核	4 核+
内存	4 GB	8 GB+
磁盘	20 GB	50 GB+（文档多时需要更多空间）
Docker	>= 24.0.0	最新版
Docker Compose	>= v2.20.0	最新版
Git	任意版本	最新版

💡 提示：Dify 的资源消耗比 RAGFlow 小得多，普通的 4C8G 笔记本或云服务器就能流畅运行。

2.2 克隆仓库并配置

# 克隆 Dify 仓库
git clone https://github.com/langgenius/dify.git

# 进入 Docker 配置目录
cd dify/docker

# 复制环境配置文件
cp .env.example .env

打开 .env 文件，以下几个关键配置项可以按需修改：

# 关键配置项（大部分默认即可）
EXPOSE_PORT=80                  # Web 访问端口，默认 80
EXPOSE_NGINX_PORT=80            # Nginx 端口
EXPOSE_NGINX_SSL_PORT=443       # HTTPS 端口
SECRET_KEY=your-secret-key      # 建议修改为随机字符串

# 向量数据库（默认 Weaviate，可切换为 Qdrant）
VECTOR_STORE=weaviate

# 如果需要切换向量库为 Qdrant，修改以下配置：
# VECTOR_STORE=qdrant
# QDRANT_URL=http://qdrant:6333

💡 提示：对于大多数场景，保持默认的 Weaviate 向量库即可。如果你的企业已有 Qdrant 或 Milvus 集群，可以在这里切换。

2.3 启动服务

# 一键启动所有服务
docker compose up -d

首次启动会拉取所有 Docker 镜像（总计约 2-3GB），耐心等待。

2.4 验证部署成功

# 查看容器运行状态
docker compose ps

正常情况下应该看到以下容器全部处于 Up 状态：

NAME                STATUS
docker-api-1        Up
docker-worker-1     Up
docker-web-1        Up
docker-db-1         Up
docker-redis-1      Up
docker-weaviate-1   Up
docker-nginx-1      Up
docker-ssrf-proxy-1 Up
docker-sandbox-1    Up

在浏览器访问 http://localhost（如果修改了端口则为 http://localhost:你的端口），首次访问会进入管理员账号设置页面，填写邮箱和密码即可完成初始化。

⚠️ 注意：首次启动后需要等待约 1-2 分钟让所有服务完全就绪，如果浏览器访问显示”502 Bad Gateway”，稍等片刻再刷新即可。

踩坑记录：部署常见问题

问题一：端口 80 被占用

现象：启动时报 Bind for 0.0.0.0:80 failed: port is already allocated

原因：本机 80 端口已被其他服务占用（如 Nginx、Apache、IIS）

解决方案：修改 .env 文件中的 EXPOSE_PORT 为其他端口（如 8080），然后访问 http://localhost:8080

---

问题二：国内拉取镜像超时

现象：docker compose up -d 卡住或报 Error response from daemon: Get https://registry-1.docker.io/v2/... timeout

原因：Docker Hub 在国内访问不稳定

解决方案：配置 Docker 镜像加速器。编辑 Docker 的 daemon.json（Docker Desktop 在设置 → Docker Engine 中）：

{
  "registry-mirrors": [
    "https://mirror.ccs.tencentyun.com",
    "https://docker.mirrors.ustc.edu.cn"
  ]
}

修改后重启 Docker，重新执行 docker compose up -d。

---

问题三：内存不足导致容器 OOM

现象：容器反复重启，docker compose logs 中出现 OOMKilled 或 out of memory

原因：Dify 全套服务至少需要 4GB 内存，Docker Desktop 默认分配的内存可能不够

解决方案：Docker Desktop → Settings → Resources → 将 Memory 调至 4GB 以上，Apply & Restart。

---

三、模型接入配置

部署完成后，第一步是接入大模型。Dify 支持同时接入多个模型供应商，可以灵活切换。

3.1 接入商业 API（推荐新手）

进入后台 → 点击右上角用户头像 → Settings → Model Provider，可以看到所有支持的模型供应商列表。

以 DeepSeek 为例（国内性价比最高的选择）：

配置项	填写说明
供应商	选择 DeepSeek
API Key	从 platform.deepseek.com 获取
模型名称	deepseek-chat（默认，即 DeepSeek-V3）

💡 提示：Dify 支持的国内模型供应商包括 DeepSeek、通义千问（Qwen）、智谱 GLM、百度文心、讯飞星火、MiniMax 等，配置方式类似——填入 API Key 即可，不需要写任何代码。

如果用的是 OpenAI 兼容接口的其他模型，选择 OpenAI-API-Compatible 供应商：

配置项	填写说明
供应商	OpenAI-API-Compatible
API Endpoint URL	你的 API 地址，如 https://api.deepseek.com/v1
API Key	你的 API Key
Model Name	如 deepseek-chat、qwen-turbo 等

3.2 接入本地 Ollama（完全离线）

如果你的服务器完全不能访问外网，或者对数据隐私有极高要求，可以用 Ollama 部署本地模型：

# 安装 Ollama（Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 拉取模型（以 Qwen2.5 7B 为例）
ollama pull qwen2.5:7b

# 启动 Ollama 服务（确保监听所有网络接口）
OLLAMA_HOST=0.0.0.0 ollama serve

在 Dify 后台添加模型时：

配置项	填写说明
供应商	Ollama
Base URL	http://host.docker.internal:11434（Docker 内访问宿主机）
模型名称	qwen2.5:7b

⚠️ 注意：Docker 容器内访问宿主机的 Ollama，地址要用 host.docker.internal（Windows/Mac Docker Desktop）或宿主机局域网 IP（Linux），不能写 localhost。同时 Ollama 必须设置 OLLAMA_HOST=0.0.0.0 允许外部访问。

3.3 接入 Embedding 模型

Embedding 模型决定了知识库向量检索的精度。Dify 支持多种 Embedding 模型供应商：

Embedding 模型	接入方式	适用场景
text-embedding-3-small	OpenAI API	英文为主，精度高
BGE-large-zh-v1.5	通过 Ollama 本地部署	中文场景首选，开源免费
通义千问 Embedding	阿里云 DashScope API	国内商用，中文适配好

如果用 Ollama 本地部署 Embedding 模型：

# 拉取 BGE Embedding 模型
ollama pull bge-large-zh-v1.5

在 Model Provider 页面添加 Ollama Embedding 模型，模型名称填 bge-large-zh-v1.5，模型类型选择 Text Embedding。

3.4 设置系统默认模型

添加完模型后，进入 Settings → Model Provider → 在顶部设置系统默认模型：

• System Reasoning Model：默认对话推理模型（如 deepseek-chat）
• Embedding Model：默认 Embedding 模型（如 bge-large-zh-v1.5）

后续创建知识库和应用时会自动使用默认模型，也可以在具体应用里单独覆盖。

---

四、知识库搭建（核心）

知识库是 Dify 的 RAG 核心模块。所有文档的上传、分块、向量化、检索都在这里完成。

4.1 创建知识库

进入左侧菜单 → Knowledge → Create Knowledge，填写名称和描述。

创建完成后进入知识库设置页，最关键的配置是 索引方式：

索引方式	说明	适用场景
High Quality（推荐）	使用 Embedding 模型生成向量，语义检索精度高	大多数场景
Economy	仅使用关键词索引，不消耗 Embedding Token	预算有限、对精度要求不高

选择 High Quality 后，需要指定 Embedding 模型（默认使用系统默认模型，也可以在这里切换）。

4.2 文档上传

Dify 支持多种文档格式：

格式	说明
TXT / Markdown	纯文本，解析最直接
PDF	支持文本型 PDF（非扫描件效果最好）
DOCX	Word 文档
HTML	网页内容
CSV / XLSX	表格数据
Epub	电子书

点击 Add File → 上传文档 → 系统自动开始处理。

💡 提示：Dify 还支持通过 URL 抓取网页内容——在上传页面选择 “Sync from website”，输入 URL 即可自动抓取并导入，适合将在线文档、Wiki 页面直接纳入知识库。

4.3 分块规则配置

分块（Segmentation）是影响 RAG 效果最关键的环节。Dify 提供三种分段策略：

策略一：Automatic（自动分段）

Dify 根据文档结构自动切分，适合快速上手。系统会按段落、标题等自然结构进行切分。

适用场景：文档结构清晰（有标题、段落层次），对精度要求不极端。

策略二：Custom（自定义分段）

手动设置分块参数，精细控制切分质量：

参数	说明	建议值
Chunk Size（切片大小）	每个文本块的最大 Token 数	500-1000（中文文档建议 500 左右起步）
Chunk Overlap（重叠长度）	相邻块之间的重叠 Token 数	50-100（防止关键信息被截断）
分隔符	分块的切分标识	默认 \n\n（段落分隔符），可按需添加 \n、。等

💡 建议：Chunk Size 不要设太小。块太小（如 200 Token），语义不完整，检索出来的片段信息量不够；块太大（如 2000 Token），噪声多，LLM 处理效率低。中文文档从 500 Token 开始试，根据对话效果调整。

策略三：Parent-Child（父子分段）

Dify 的特色功能之一。大段作为父节点保留完整上下文，小段作为子节点用于精准检索：

父节点（800 Token）：完整的年假制度段落
  ├── 子节点（200 Token）：年假天数说明
  ├── 子节点（200 Token）：申请流程说明
  └── 子节点（200 Token）：补休规则说明

检索时命中子节点，但送给 LLM 的是父节点的完整内容，兼顾了检索精度和上下文完整性。

核心价值：父子分段特别适合长文档场景——一个段落可能包含多个知识点，自动分段可能把相关内容切到不同的块里，父子分段能确保检索到任何一个细节时，LLM 都能看到完整的上下文。

4.4 检索参数配置

在知识库设置中，还有几个直接影响检索效果的参数：

参数	说明	建议值
检索模式	向量检索 / 全文检索 / 混合检索	混合检索（生产环境标配）
Top-K	每次检索返回的最相关片段数	3-5（知识库小可设 3，大库设 5）
Score 阈值	低于此分数的片段不返回	0.3-0.5（太高会漏召回，太低会引入噪声）

混合检索是生产环境的标配。向量检索擅长语义理解（”年假”和”带薪休假”能匹配），全文检索擅长精确匹配（产品型号、专有名词等），两者互补效果最好。

4.5 分块结果检查

文档处理完成后，可以在知识库中直接查看每个分块的文本内容。Dify 的分块结果可视化展示，你可以：

• 查看每个分块的完整文本和 Token 数
• 手动编辑分块内容（修正错误、补充信息）
• 删除无关分块（噪声内容、页眉页脚等）
• 新增分块（手动添加高频问答对等）

核心价值：这种”可视化 + 可修正”的分块管理方式，让你能直观看到 RAG 检索到的每一段内容是什么，而不是黑盒——出了问题你能精准定位到是哪个分块有问题，而不是只能调参数碰运气。

---

五、应用创建与对话测试

5.1 创建对话应用

进入左侧菜单 → Studio → Create App → 选择 Chatbot 类型，填写应用名称。

创建后进入应用编排页面，左侧是 Prompt 和配置区域，右侧是对话预览区域。

5.2 绑定知识库

在应用配置中，找到 Context（上下文） 部分，点击添加知识库——可以选择一个或多个已创建的知识库。绑定后，用户在对话中提问时，系统会自动从知识库中检索相关内容作为上下文。

5.3 Prompt 模板编写

Dify 支持在系统提示词中引用知识库检索结果。推荐的 Prompt 模板：

你是 {{company_name}} 的内部知识助手。

请严格根据上下文（Context）中的资料回答用户问题。

规则：
1. 只基于提供的资料回答，不要编造信息
2. 如果资料中没有相关内容，请明确告知"根据现有资料暂时无法回答该问题"
3. 回答简洁准确，必要时引用来源文档名称
4. 如果用户的问题涉及多个方面，请分点回答

其中 {{company_name}} 是自定义变量，可以在应用启动时通过对话变量设置，同一个 Prompt 模板可以复用于不同部门或场景。

5.4 模型参数调优

在应用配置中可以调整 LLM 的推理参数：

参数	说明	建议值
Temperature	控制回答的随机性	0.1-0.3（知识库问答需要准确，低温度更稳定）
Top-P	核采样，控制词汇多样性	0.7-0.9
Max Tokens	最大生成长度	512-1024（根据回答复杂度调整）
上下文轮数	保留多少轮对话历史	5-10（太多会浪费 Token，太少影响连续性）

💡 建议：知识库问答场景下 Temperature 设低一点（0.1-0.3），让回答更稳定、更忠于检索结果。如果是创意写作类应用，可以调高到 0.7-0.9。

5.5 对话测试与检索溯源

在右侧对话预览区直接提问，测试效果。Dify 的回答会附带引用来源——点击引用标记可以看到具体来自哪个文档的哪个分块。

用户：公司年假有几天？

AI 回答：根据公司年假制度：
- 入职满一年：5 天带薪年假
- 入职满三年：8 天带薪年假
- 入职满五年：10 天带薪年假
年假需提前 3 天在 OA 系统提交申请。[引用1]

[引用1] 来自：company_faq.md - 第3段

这个溯源能力在企业场景非常重要：用户需要知道答案来自哪里，不能只给一个”AI 说”的结论。

5.6 开启 Rerank 重排

Rerank 是提升检索精度的关键步骤——对初次检索返回的 Top-K 个片段，用专门的 Rerank 模型重新打分排序，把真正最相关的排到前面。

在应用配置的 Context 部分，开启 Rerank Model，选择一个已添加的 Rerank 模型：

Rerank 模型	接入方式	说明
bge-reranker-v2-m3	通过 Ollama 本地部署	开源免费，中英文效果都不错
Cohere Rerank	Cohere API	商用模型，多语言效果好
Jina Reranker	Jina AI API	开源团队提供商用 API

💡 提示：Rerank 是生产环境的必选项。没有 Rerank 时，向量检索的 Top-1 不一定是最相关的（向量距离只是近似语义匹配）；开启 Rerank 后，专门的重排模型会对每个片段做更精细的相关性判断，显著提升最终回答的准确度。

---

六、进阶功能

6.1 多轮对话记忆

Dify 内置了对话记忆管理，不需要写任何代码就能实现连续追问：

用户：公司年假有几天？
AI：入职满一年 5 天，满三年 8 天，满五年 10 天。

用户：那怎么申请？（AI 知道"那"指的是年假）
AI：年假需提前 3 天在 OA 系统提交申请，由直属领导审批。

用户：没休完怎么办？（AI 知道问的是年假）
AI：未休完的年假可在次年 3 月底前补休，过期作废。

在应用配置中，上下文轮数控制保留多少轮历史对话。建议设为 5-10 轮——太少则连续追问容易丢失上下文，太多则每次请求携带大量历史 Token，浪费成本。

6.2 标注功能（Annotation）

对于高频问题，可以手动设置标准答案。用户提问时如果匹配到已标注的问题，系统直接返回预设答案，不经过 LLM 生成——既提升准确性又降低成本。

进入应用 → Annotation → 添加标注：

问题	标准答案
公司年假有几天？	入职满一年 5 天，满三年 8 天，满五年 10 天。需提前 3 天在 OA 申请。
报销流程是什么？	差旅报销需在出差结束后 5 个工作日内提交，附发票原件和出差审批单。

💡 提示：标注功能特别适合 FAQ 类场景——那些被反复问到的固定问题，用标注直接返回精确答案，比每次都让 LLM 从知识库生成更稳定、更省钱。

6.3 权限管理

Dify 社区版支持基本的团队协作：

• 管理员：可以管理所有知识库、应用和用户
• 普通成员：根据授权访问特定的知识库和应用
• API Key 隔离：每个 API Key 绑定特定应用，权限独立控制

在 Settings → Members 中管理团队成员和权限。

---

七、高阶配置

7.1 API 调用

Dify 的每个应用都会自动生成 RESTful API，可以将知识库问答能力集成到企业内部系统。

进入应用 → API Access → 创建 API Key，然后用 Python 调用：

import requests

# Dify API 配置
DIFY_API_URL = "http://localhost/v1"       # Dify API 地址
API_KEY = "app-xxxxxxxxxxxxxxxx"          # 从 API Access 页面获取

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

# 发送对话请求
response = requests.post(
    f"{DIFY_API_URL}/chat-messages",
    headers=headers,
    json={
        "inputs": {},                      # 对话变量（如有）
        "query": "公司年假有几天？",         # 用户问题
        "response_mode": "blocking",       # blocking=等待完整回答，streaming=流式输出
        "user": "test-user"                # 用户标识
    }
)

result = response.json()
print(result["answer"])

如果需要实现多轮对话，在第二次请求时传入上一次的 conversation_id：

# 第一轮对话
first_response = requests.post(
    f"{DIFY_API_URL}/chat-messages",
    headers=headers,
    json={
        "query": "公司年假有几天？",
        "response_mode": "blocking",
        "user": "test-user"
    }
)
conversation_id = first_response.json()["conversation_id"]

# 第二轮对话（传入 conversation_id 实现上下文连续）
second_response = requests.post(
    f"{DIFY_API_URL}/chat-messages",
    headers=headers,
    json={
        "query": "那怎么申请？",            # 追问
        "conversation_id": conversation_id, # 关联上一轮对话
        "response_mode": "blocking",
        "user": "test-user"
    }
)
print(second_response.json()["answer"])

7.2 流式输出（Streaming）

Dify API 支持 SSE（Server-Sent Events）流式输出，实现打字机效果的实时响应：

import requests

response = requests.post(
    f"{DIFY_API_URL}/chat-messages",
    headers=headers,
    json={
        "query": "公司报销流程是什么？",
        "response_mode": "streaming",       # 流式输出模式
        "user": "test-user"
    },
    stream=True                             # 开启流式接收
)

# 逐块接收响应
for line in response.iter_lines():
    if line:
        decoded = line.decode("utf-8")
        if decoded.startswith("data: "):
            print(decoded[6:], end="", flush=True)

7.3 外部系统对接

Dify API 可以对接各种外部系统：

对接场景	实现方式
企业微信/钉钉/飞书机器人	在机器人后端调用 Dify API，员工在群里@机器人即可获得知识库回答
企业 OA/工单系统	在 OA 页面嵌入 Dify 的 Web App（iframe 嵌入），一行代码集成
客服系统	通过 API 对接在线客服平台，用户提问自动检索知识库回答
内部网站/Portal	使用 Dify 提供的嵌入式组件，将 AI 助手嵌入企业网站

Dify 还提供了嵌入式 Web App功能——在应用的 Overview 页面获取 iframe 嵌入代码：

<!-- 一行代码将 Dify 对话助手嵌入你的网站 -->
<iframe
  src="http://localhost/chatbot/xxxxxxxx"
  style="width: 100%; height: 500px; border: none;"
></iframe>

7.4 多知识库联动

一个对话应用可以绑定多个知识库。Dify 在检索时会同时查询所有绑定的知识库，合并结果后送入大模型。

适用场景：企业有多个部门（产品、技术、HR、财务）的文档，每个部门一个知识库，但对话助手需要跨部门检索回答综合性问题。

---

八、Dify 优缺点与适用边界

8.1 优势

优势	说明
部署极简	Docker Compose 三条命令启动，几分钟完成部署
零代码操作	知识库搭建、应用创建、参数调优全部可视化操作
功能全面	RAG 知识库 + 工作流编排 + Agent + 多模型管理，一站式覆盖
模型灵活	商业 API 和本地模型自由切换，支持多供应商负载均衡
API 优先	每个应用自动生成 API，天然适合集成到企业系统
社区活跃	13 万+ GitHub Stars，社区活跃，文档完善，迭代速度快

8.2 局限

局限	说明
文档解析深度有限	基础文本提取，不支持 PDF 布局分析、表格 OCR 等深度解析（RAGFlow 在这方面更强）
分块策略不够丰富	自定义分块参数较基础，没有按文档类型（论文/法律/代码）的专用模板
深度定制受限	复杂检索策略（多路并行检索、RRF 融合排序、知识图谱增强）需要通过工具节点间接实现
社区版功能边界	SSO、审计日志、多租户管理等企业级功能仅在企业版提供

8.3 适用场景

场景	是否适合 Dify	说明
企业内部知识库问答	✅ 非常适合	快速搭建，非技术人员也能操作
客服机器人	✅ 适合	内置多轮对话、标注功能
快速原型验证	✅ 非常适合	零代码搭建，30 分钟内跑通
多模型切换与管理	✅ 适合	统一管理多家模型供应商
深度文档解析（复杂 PDF/扫描件）	⚠️ 部分适合	文本型 PDF 没问题，复杂排版建议用 RAGFlow
复杂检索策略定制	⚠️ 有限	基础检索没问题，深度定制需借助工具节点或代码框架
涉密内网全栈私有化	⚠️ 部分适合	搭配本地 Ollama 可以实现，但 RAGFlow 的私有化更彻底

核心价值：Dify 最大的价值在于让非技术人员也能参与 AI 应用的搭建和运营。产品经理可以调整 Prompt，运营可以管理知识库，开发可以通过 API 集成到业务系统——每个人都能在自己擅长的环节发挥作用，而不是所有事情都压在开发身上。

---

常见问题踩坑汇总

Q：上传 PDF 后分块效果很差，内容被切得支离破碎？
A：Dify 对 PDF 的解析是基础文本提取，如果 PDF 排版复杂（多栏、嵌套表格、图片文字），提取出来的文本结构可能混乱。建议：①先用工具将 PDF 转为 Markdown 格式再上传；②使用”自定义分段”策略手动控制 Chunk Size 和分隔符；③如果文档解析质量是核心需求，考虑用 RAGFlow（第 8 篇会讲）。

Q：知识库检索结果不相关，回答和问题对不上？
A：按顺序排查：①检查分块质量（在知识库中查看每个分块的内容是否完整）；②切换为混合检索模式；③开启 Rerank 重排；④确认 Embedding 模型是否适合你的文档语言（中文建议用 BGE 系列）；⑤适当增大 Top-K 值。

Q：本地 Ollama 模型接入后调用报错？
A：Docker 容器内无法直接访问宿主机的 localhost。Windows/Mac 用 host.docker.internal:11434，Linux 用宿主机局域网 IP。同时确认 Ollama 已设置 OLLAMA_HOST=0.0.0.0 允许外部访问。

Q：对话应用响应很慢？
A：主要瓶颈通常在 LLM 调用环节。排查方向：①如果用 API，检查网络延迟和 API 配额；②如果用本地模型（Ollama），检查 GPU 显存是否充足；③减少 Top-K 值（减少上下文长度）；④降低 Max Tokens 限制。

Q：怎么让 Dify 的对话助手嵌入到我们公司的网站里？
A：在应用的 Overview 页面获取 iframe 嵌入代码，复制到你的网站 HTML 中即可。如果需要更深的集成，使用 Dify API + 你自己的前端页面实现。

---

总结与回顾

知识点	关键要点
Dify 定位	开源低代码 AI 应用平台，RAG 是核心功能之一
部署方式	Docker Compose 一键启动，4C8G 即可流畅运行
模型接入	商业 API（DeepSeek 等）和本地 Ollama 两种方式，界面配置无需写代码
知识库搭建	支持多种文档格式，三种分块策略（自动/自定义/父子分段），结果可视化可修正
检索配置	混合检索是生产标配，Rerank 重排显著提升精度
应用创建	绑定知识库 + Prompt 模板 + 参数调优，右侧实时预览对话效果
进阶功能	多轮对话记忆、标注高频问答、团队协作权限管理
API 调用	自动生成 RESTful API，支持阻塞式和流式输出，可集成到企业系统
核心优势	部署简单、零代码操作、功能全面、API 优先
核心局限	文档解析深度有限、复杂检索定制受限

---

下篇预告

第 6 篇：LangGraph 代码编排 RAG —— 在 Dify 里你体验了低代码的便利，但如果需要深度定制检索策略、实现复杂的分支逻辑和 Agent 融合，就需要回到代码世界。下一篇基于 LangGraph 的状态机 + 节点编排能力，搭建可定制化的 RAG 流程，并在末尾与 Dify 做详细的取舍对比。

---

参考资料

资源	链接
Dify 官方文档	docs.dify.ai
Dify GitHub 仓库	langgenius/dify
Dify Marketplace	marketplace.dify.ai
Ollama 官网	ollama.com
DeepSeek 开放平台	platform.deepseek.com
Weaviate 向量数据库	weaviate.io

---

本文为「从零到落地：RAG 检索增强生成实战系列」第 5 篇，完整系列持续更新中。