Dify + RAGFlow — 复杂文档场景的双层方案

这套方案在解决什么问题#

「Dify 自带知识库」适合 Markdown / Notion 导出，但碰到这些场景就力不从心：

文档类型	Dify 默认效果
含 12 个表格的产品手册 PDF	表格被切碎，参数检索 30-60% 命中
双栏排版的法律 / 政策文件	文字串行错乱
扫描件 / 老旧手册	0 命中（无 OCR）
含公式 / 图表的技术资料	严重信息丢失

RAGFlow 实测 表明，DeepDoc 引擎对这些复杂文档的检索准确率可以从 60% 拉到 90%+。但 RAGFlow 是「检索引擎」不是「应用平台」，所以最佳实践是：

Dify 做应用层（Prompt + 工作流 + 多 LLM）+ RAGFlow 做检索后端

架构#

组件与角色#

组件	角色	资源建议
RAGFlow	文档解析 + 检索	8C/16G + 100GB
Elasticsearch / Infinity	RAGFlow 后端检索	4C/8G + 50GB
Dify	工作流、Prompt、LLM 治理	8C/16G
Chatwoot	多渠道入口 + 坐席	4C/8G
PostgreSQL	两者元数据	2C/4G

部署步骤#

1. 起 RAGFlow#

git clone https://github.com/infiniflow/ragflow
cd ragflow/docker

# 推荐用「带嵌入模型」的完整镜像，省装 embedding 服务
docker compose -f docker-compose.yml up -d

打开 http://YOUR_IP:80，注册管理员，创建第一个 Knowledge Base：

• 文档语言：中文
• 分块方法：选「General」起步，复杂表格类选「Paper / Manual」
• Embedding：bge-m3
• 上传文档，等待 DeepDoc 解析完成（每页约 5-30 秒）

2. 测试 RAGFlow 检索效果#

在 RAGFlow 的「Retrieval Testing」面板用真实问题试一遍：

• 表格类问题：「型号 X-200 的最大输出功率」
• 双栏布局：「在第二章环境章节提到的温度限制」
• 扫描件：「附录 B 提到的安全规范」

如果 top-1 命中不理想：

• 调整分块策略
• 启用「Auto-keyword」与「Auto-question」预处理
• 加 Reranker（默认推荐 bge-reranker-v2-m3）

3. 把 RAGFlow 当 Dify 的检索后端#

Dify Workflow 用 HTTP 节点调用 RAGFlow Retrieval API：

节点：HTTP Request
URL: https://ragflow.example.com/api/v1/retrieval
Method: POST
Headers:
  Authorization: Bearer <RAGFlow API Key>
Body:
  {
    "question": "{{user_question}}",
    "dataset_ids": ["kb_uuid"],
    "top_k": 5,
    "similarity_threshold": 0.5,
    "rerank": true
  }

返回值是带 chunk_id + content + score 的数组，把它作为 LLM 节点的「上下文」输入。

4. Prompt 严格约束#

你是 [品牌] 的客服助手。仅基于「参考资料」回答，并在每个事实后附 chunk_id。

参考资料：
{% for chunk in retrieved_chunks %}
[{{chunk.chunk_id}}] {{chunk.content}}
{% endfor %}

用户问题：{{question}}

回答（带 chunk_id）：

5. Chatwoot 集成#

跟 Chatwoot + Dify 一样，把 Dify 应用配成 Agent Bot 即可。

关键调优点#

RAGFlow 分块策略#

文档特征	选哪种 chunking
通用 Markdown / Word	General
产品手册（多表格）	Paper / Manual
法律 / 合同	Laws
学术论文	Paper
简历 / 卡片式	Resume
书籍	Book

启用 GraphRAG#

文档里实体关系密集时（产品参数互联、医疗术语网络），开 RAGFlow 的 GraphRAG：

• 在 Knowledge Base 设置里勾「Knowledge Graph」
• 检索时同时返回图谱关系
• 答案的准确率与解释性都显著提升

多 KB 路由#

当文档分多个领域（产品 A / 产品 B / 政策）时，先用 Dify 的 LLM 节点分类，再路由到对应 RAGFlow KB：

用户问题 → LLM 分类(domain: A|B|policy) →
  ├─ A → RAGFlow KB_A
  ├─ B → RAGFlow KB_B
  └─ policy → RAGFlow KB_policy

成本估算#

资源	月费（自部署）
8C/16G 服务器（跑 RAGFlow + Dify）	$60-80
4C/8G 服务器（Chatwoot + Postgres）	$30
LLM tokens（5,000 月会话，Qwen 72B）	$50-150
Embedding（本地 GPU 不算 tokens）	$0
域名 + 邮件	$15
合计	$155-275 / 月

效果对比（同一份产品手册）#

测试集：30 道真实客户问题，含表格 / 双栏 / 扫描页

方案	Top-1 命中	答案 Faithfulness
Dify 自带 KB（默认）	17/30	0.78
Dify 自带 KB（调优）	23/30	0.85
Dify + RAGFlow（默认）	28/30	0.87
Dify + RAGFlow（调优 + GraphRAG）	30/30	0.94

何时不要选这套方案#

情况	建议改用
文档主要是 Markdown / Notion 导出	Chatwoot + Dify
资源紧张，4C/8G 单机	Chatwoot + Dify 起步
文档总量 < 100 篇且简单	AnythingLLM 副驾 + Chatwoot

常见坑#

1. RAGFlow 解析速度：扫描 PDF 一页 30 秒，100 页文档要等 50 分钟。建议夜间批量入库
2. Elasticsearch 内存：默认 1G 不够，生产环境改 4G+
3. Dify HTTP 节点超时：RAGFlow 检索有时 2 秒，把 Dify 节点超时调到 10 秒
4. 中文 OCR 弱：RAGFlow 内置 OCR 对手写 / 模糊扫描效果一般，建议先用 PaddleOCR 单独处理

相关阅读#

• RAGFlow vs Dify 知识库实测
• 知识库准备实战
• RAG 质量评估方法