RAGFlow 的理解和使用

本文基于 RAGFlow 官方 GitHub 仓库、官方 Quickstart，以及我在 Windows + Docker Desktop 环境中的真实实践整理。

一、RAGFlow 是什么

RAGFlow 是一个开源的 RAG（Retrieval-Augmented Generation，检索增强生成）引擎。它不只是把 PDF 文本抽出来再做问答，而是强调：

• 深度文档理解；
• 复杂 PDF、Word、Excel、PPT、图片等格式解析；
• 表格、版面、OCR 和阅读顺序识别；
• 基于模板的可控切块；
• 全文检索与向量检索融合；
• Rerank 重排；
• 回答引用溯源；
• API 与 Agent 工作流。

官方对它的定位是：为大模型提供上下文层，将复杂数据转化为可信、可溯源的 AI 知识系统。

二、部署

部署方式跟着官方文档一步步来即可，这里不展开，直接看 GitHub 源码地址。

三、配置

进入主题配置——因为 RAGFlow 本身是 RAG 引擎，不带云端大模型，需要自己配置。

模型类型	作用	是否必需
Chat / LLM	根据检索上下文生成最终答案	必需
Embedding	将文档块和问题转换为向量	必需
Rerank	对召回块进行精排	推荐
Vision	理解图片、复杂视觉内容	按需
ASR	音频转文字	按需

我配置了两个：一个 OpenAI 主要做 Chat/LLM，千问的做 Embedding。

注意：因为我接的是中转站，中转站没有嵌入大模型，所以这里如果你们接的是中转，要确认你们的中转是否支持 Embedding 模型。

配置完要验证一下模型是否连接成功。之后在知识库位置上传文档——这里我没配 Rerank 模型，但这个模型挺影响检索准确度的，有的话建议配上。

支持上传的文件类型：

PDF、DOC、DOCX、TXT、MD、MDX
CSV、XLSX、XLS
JPEG、JPG、PNG、TIF、GIF
PPT、PPTX

文件上传成功不等于已经可以检索，只有完成下面这条链路才行：

解析 → 切块 → Embedding → 写入索引

最后在对话部分选择刚检索好的知识库，就可以开始问答了。

一句话总结：RAGFlow 是把复杂数据加工成高质量知识上下文，再提供检索、问答、引用和 API 服务的知识引擎。

四、我的理解：RAGFlow 强在哪里

1. 复杂文档解析

这是它的招牌能力。普通 RAG 系统解析 PDF 往往只是提取文本，然后按固定长度切块，复杂文件容易出现：

• 双栏内容阅读顺序错乱；
• 表格拆成碎片；
• 标题和正文分离；
• 页眉页脚反复混入；
• 扫描件无法提取文字；
• 图片、代码块、图注丢失。

RAGFlow 强在先理解文档结构：版面分析、OCR、表格结构识别、多栏阅读顺序恢复、标题/正文/图片区域识别、代码块和公式处理、原文位置记录。这部分在 PDF 上最能体现优势。

2. 支持的不只是 PDF

类型	示例
普通文档	PDF、Word、TXT、Markdown
表格	Excel、CSV
演示文稿	PPT、PPTX
图片	JPG、PNG、扫描件
网页	HTML、网站内容
通信资料	Email
多媒体	图片、音频等
结构化数据	数据库、表格记录

而且会根据内容类型选择不同的解析流程，如 General、Table、Paper、Book、Laws 等。

3. 可控、可解释的切块

RAGFlow 不只是把内容切成向量。它允许你：查看每个知识块、查看块对应的原文位置、检查表格有没有被拆散、修改块内容、给块添加关键词、给块添加相关问题、根据不同文档类型选择切块模板。

这对企业很重要，因为 RAG 出错时可以判断问题发生在哪一层：

文档没解析对？切块不完整？向量没有召回？正确块排序太靠后？还是大模型没有按资料回答？

4. 检索不是单纯关键词搜索

BM25 全文检索 + 向量语义检索 + 多路召回融合 + Rerank 精排

5. 给企业系统提供知识中间层

企业可以不使用 RAGFlow 自带的聊天页面，而是通过 API 调用：

企业后端
  ↓ 用户问题
RAGFlow 检索 API
  ↓
相关知识块 + 相似度 + 文档来源 + 引用位置
  ↓
企业后端拼 Prompt、权限和业务数据
  ↓
调用大模型生成答案

这样，RAGFlow 负责：文档上传、文档解析、知识切块、向量索引、混合检索、Rerank、引用溯源。

企业自己的后端负责：用户权限、多租户隔离、业务流程、实时数据库、Prompt、模型选择、内容审核、Agent 工具执行。

6. 与普通「PDF 问答工具」的区别

	普通 PDF 问答	RAGFlow
文档处理	上传一个 PDF 后聊天	管理大量知识库和异构数据
解析能力	简单文本提取	深度版面、OCR、表格理解
切块方式	固定长度切块	模板化、可见、可人工调整
检索方式	通常只有向量检索	全文检索 + 向量检索 + 融合排序 + Rerank
引用能力	有限	强调原文快照和引用溯源
使用场景	主要面向个人	支持 API 和企业私有化集成
长期价值	一次性问答	可以成为长期知识基础设施

五、RAGFlow 和 Dify 的区别

RAGFlow 和 Dify 的功能已经有不少重叠：都能创建知识库、都支持关键词检索/向量检索/Rerank、都有可视化处理流程、都能构建 Agent、都能通过 API 对外提供能力。

真正的区别不是“一个能做、另一个不能做”，而是二者的产品起点和默认重心不同：

RAGFlow 从高质量知识上下文出发；Dify 从 AI 应用和业务工作流出发。

一句话概括：RAGFlow 负责把知识加工好、找得准、引得明白；Dify 负责把模型、知识和工具编排起来，做成应用。

核心能力对比

维度	RAGFlow	Dify
核心定位	RAG 引擎、企业知识上下文层	通用 AI 应用开发和工作流平台
默认起点	先把资料解析、切块和索引做好	先搭聊天应用、Agent 或业务流程
文档解析	突出复杂版面、OCR、表格、扫描件	也支持知识流水线，可配置解析、切块和索引
分块能力	多种文档模板，强调可视化、可解释和人工干预	支持 General、父子分段及可编排知识流水线
检索能力	全文检索 + 向量检索 + 融合排序 + Rerank + Agentic Retrieval	关键词检索 + 向量检索 + 多知识库召回 + Rerank
引用溯源	核心卖点，强调原文快照、证据和引用	支持引用与归属展示
工作流支持	Agent 画布和文档摄入流水线	Workflow、Chatflow 更成熟，业务节点更丰富
工具生态	围绕 RAG、检索、数据处理和 Agent	插件、HTTP、代码、工具、MCP、触发器更丰富
应用发布	Chat、Agent、HTTP/Python API	Web App、API、MCP、模板、DSL
典型用途	企业知识库、法务、财报、手册、复杂文档问答	客服、自动化、内容生成、多工具 Agent、业务流程
学习和部署成本	相对较重，更偏知识基础设施	更偏低代码应用开发平台

RAGFlow 强在哪里

RAGFlow 更关注下面这条链路：

复杂资料
  ↓
深度解析
  ↓
结构化切块
  ↓
全文与向量索引
  ↓
多路召回和重排
  ↓
生成带引用的可靠上下文

Dify 强在哪里

Dify 更关注下面这条链路：

用户输入或触发器
  ↓
意图分类与条件分支
  ↓
知识检索 / LLM / 代码 / HTTP / 工具
  ↓
迭代、人工审核和异常处理
  ↓
发布为 Web App、API 或 MCP

Dify 的优势还包括：快速发布 Web App、生成 API、发布为 MCP 工具、导入导出 DSL、调试每个节点、查看运行日志和中间变量、管理应用版本、接入更多外部插件和服务。所以 Dify 首先是一个 AI 应用和业务流程平台，知识库是其中的一项核心能力。

需要修正的旧印象

过去可以简单理解为「RAGFlow：知识库强；Dify：工作流强」。这个结论仍有参考价值，但已经不够完整。

目前：Dify 已支持可视化 Knowledge Pipeline，可以编排数据源、Extractor、Chunker、索引和检索策略；RAGFlow 也已支持 Agent 画布、工具调用和 MCP，不只是文档问答。

所以更准确的说法是：

RAGFlow 的默认优势仍然在知识加工与检索；Dify 的默认优势仍然在应用交付与业务编排。

两者的能力有交集，但产品重心不同。

六、典型场景如何选择

场景一：企业制度、合同和财报问答

优先考虑 RAGFlow。原因：资料复杂、表格和扫描件较多、回答必须有引用、需要追溯原文、需要人工检查知识块。

场景二：客服机器人

优先考虑 Dify。典型流程：

识别用户意图
  ↓
查询知识库
  ↓
查询订单 API
  ↓
判断是否退款或转人工
  ↓
生成答复

这类需求更强调业务节点、条件分支和工具调用。

场景三：多 Agent 业务工作流

例如淘宝商品套图工作流：

商品分析 → SKU 校验 → 套图方案规划 → 人工确认
→ 调用 Agent 生成样图 → 质量审核 → 批量生成 → 详情页合成

这种需求的核心是状态流转、条件分支、人工确认、工具调用、异步任务、幂等和恢复，更适合用 Dify 或 LangGraph。

如果后续还需要查询淘宝平台规范、商品说明书、品牌设计规范、广告合规要求、历史优秀案例等，可以用 RAGFlow 建立专业知识库，再由 Dify 或 LangGraph 调用 RAGFlow 的检索 API。

七、RAGFlow 和 Dify 能否组合

可以。典型组合架构如下：

RAGFlow
负责文档解析、知识索引、检索、重排和引用
        ↓ Retrieval API
Dify
负责用户交互、流程编排、工具调用和应用发布
        ↓
企业业务系统

组合后的职责划分：

系统	主要职责
RAGFlow	复杂文档解析、切块、索引、检索、Rerank、引用
Dify	Chatflow、Workflow、条件分支、工具、插件、应用发布
企业后端	用户权限、业务数据、多租户、审计和核心业务逻辑
大模型	根据知识上下文生成答案或执行推理任务

总结

RAGFlow 和 Dify 不是二选一的对立关系，而是可以互补的：

• 需要处理复杂文档、保证回答可溯源 → 选 RAGFlow；
• 需要快速搭应用、编排业务流程 → 选 Dify；
• 两者都要 → 用 RAGFlow 做知识底座，用 Dify 做应用层。

参考链接

• RAGFlow 官方 GitHub 仓库
• 本文 CSDN 原文