TLDR
- 如果您需要一个简单、固定的需求，随便选用一个适合的编程语言调用LLM API即可
- 如果您是正在学习的AI的开发人员，能自己实现就自己实现，框架会变，底层原理不变
- 注重流程与扩展选Dify
- 注重知识库选RagFlow
一、背景
市面上目前工作流分为几种形式，一种是以Coze为代表的基于网页的工作流形式，另一种以langchain与llamaindex为主的基于代码框架的形式。
两种形式各有千秋，针对不同的技术与框架，我们需要针对自己的业务进行合理的判断，每一种场景、每一种业务、每一种使用的客户都会产生不同的答案。
所以我从多个角度，针对 Dify、FastGPT、RAGFLow这类基于webui 的工作流，进行一个对比。
先对比下Github Start🌟
二、测评维度
作为一个LLMIOps平台，包含几个基本的模块，所以我们也会从这些维度进行一个比较
测评维度
- 团队人员管理
- 模型管理
- 第三方工具
- 知识库管理
- 应用管理
- 对话管理
- 应用类型
- 开源协议与功能对比
- 部署难度
三、测评产品版本
- Dify v1.0.0
- FastGPT v4.8.20
- RAGFlow v0.17.0 slim
四、详细测评
4.1 团队人员管理
作为团队使用的平台，我们需要考虑人员管理的一些需求。
主要考虑两个方向：
- 工作空间
- 权限管理
维度 | Dify | FastGPT | RAGFlow |
空间数量 | 1个 | 无空间 | 多个支持邀请制 |
角色 | - 管理员
- 编辑
- 成员 | 无 | -管理员
-成员 |
加入多个团队 | 否 | 否 | 是 |
商业版 | 支持 | 支持 | ㅤ |
推荐值 | 🌟🌟 | 🌟 | 🌟🌟 |
4.2 模型管理
作为一个LLMOps的平台，是否支持完备的平台是一个非常重要的功能，模型管理需要考量三个方面，一个是支持的平台数量，一个是支持的模型类型，还有一个是可扩展性。
第一点保证了能够方便对接各类平台；
第二点保证在模型不断变化的情况，包括文本模型、视觉模型、视觉模型等都能方便接入；
第三点是否方便用户接入自定义或者其他平台的模型。
维度 | Dify | FastGPT | RAGFlow |
模型供应商 | 56 | 20 | 44 |
OpenAI兼容格式 | 支持 | 支持 | 支持 |
扩展接入 | 强，自定义插件 | 中，自定义配置 | 弱，不能自定义配置 |
支持模型类型 | - Text Generation
- Image Generattion
- Vision
- Audio Generation
- Text Embedding
- Speech2text
- TTS
- Rerank
- Moderation | - Text Generation
- Vision
- Text Embedding
- Speech2text
- TTS
- Rerank | - Text Generation
- Vision
- Text Embedding
- Rerank
- Moderation |
缺点 | - 负载均衡需要企业版
- 一个模型名称只能部署一个服务 | - 管理页面有点混乱 | - 不支持在提供商上增加模型
- 一个平台只支持一个key |
特点 | - 支持自己编写插件对接各类模型服务 | - 支持配置文件方式
- 可以设置别名 | / |
推荐值 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
4.3 第三方工具
一个平台如果无法很好的调用第三方的工具，就无法做到很好的扩展性，随着业务的不断发展，会越来越无法支撑，第三方工具方面需要考虑两个比较重要的点
- 自带工具的丰富度
- 工具扩展的难度与灵活度
维度 | Dify | FastGPT | RAGFlow |
自带工具数量 | - 工具：40
- Agent策略：2
- 扩展：6 | 系统插件：15 | 工具：21 |
特色工具 | - database：连接数据库
- Json处理
- ECharts图表生成 | - 数据库连接
- 飞书、钉钉
- BI图表 | - 谷歌学术 |
扩展 | - API扩展
- 支持插件开发 | 无 | 无 |
插件类型 | - 模型
- 工具
- Agent策略
- 扩展 | 无 | 无 |
自定义 | - 基于OpenAPI-Swagger创建接口
- 基于工作流转换为工具 | 无 | 无 |
兼容实现 | Http请求 | Http请求 | 无 |
推荐值 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
4.4 知识库
知识库是RAG技术的一个关键落地场景，所以针对知识库，需要从以下维度进行考虑
- 导入阶段：
- 考虑支持的格式是否丰富
- 导入的方式：如网页、文本、接口
- ETL数据清晰流程是否准确
- 创建阶段: 手动或自动构建知识库。
- 召回阶段: 检索相关信息的效率和准确性。
- 权限设置: 控制谁可以访问或编辑知识库。
维度 | Dify | FastGPT | RAGFlow |
导入阶段：支持格式 | TXT、 MARKDOWN、 MDX、 PDF、 HTML、 XLSX、 XLS、 DOCX、 CSV、 MD、 HTM | .txt, .docx, .csv, .xlsx, .pdf, .md, .html, .pptx | Word、PPT、Excel、TXT、PDF、HTML |
导入阶段：导入方式 | - 文本
- Notion
- Web站点
- API接口 | - 文本
- API
Web网站
- 飞书
- 语雀 | - 文本
- 网页 |
导入阶段：清洗方式 | - DIfy ETL
- Unstructured ETL
| - 自带 | - DeepDoc
- 简易
- 大模型 |
创建阶段：分段设置 | - 通用文本分块模式
- 使用父子模式时，子块用于检索，父块用作上下文 | - 直接分段
- 问题拆分 | - 自动创建关键词
- 自动创建问题 |
创建阶段：索引方式 | - 高质量：Text-Embedding
- 经济：关键词 | - Text-Embedding | - 召回增强RAPTOR策略
- 知识图谱
|
召回阶段：检索设置 | - 向量搜索
- 全文搜索
- 混合搜索 | - 向量搜索
- 全文搜索
- 混合搜索 | - 搜索 |
召回阶段：rerenk | - 支持rerank模型 | - 支持rerank模型
- 支持大模型理解 | - 支持rerank模型 |
召回测试 | - 支持多种召回测试 | 支持多种召回测试 | - 知识图谱 |
团队管理 | - 支持个人
- 支持团队
- 支持部分成员 | 商业版功能 | - 支持个人
- 支持团队 |
推荐值 | 🌟🌟 | 🌟 | 🌟🌟🌟 |
在知识库模块功能比较强大的的属于RAGFLow，支持模型理解也支持知识图谱创建，召回的效果应该算比较好，这是RAGFLow 的主打特点。
4.5 应用管理
应用是LLMOps平台的核心，所有的业务都是围绕应用进行开展，通过应用连接了模型、工具调用、Agent等一系列工作。
维度 | Dify | FastGPT | RAGFlow |
应用类型 | - 聊天助手
- Agent
- 文本生成应用
- Chatflow
- 工作流 | - 简单聊天
- 工作流聊天 | - 聊天
- Agent |
应用功能 | - 对话开场白
- 下一步问题简易
- 文字转语音
- 文件上传
- 引用与归属
- 内容审查 | - 文件上传
- 语音播放
- 语音输入
- 猜你想问
- 定时执行
- 自动执行
- 输入引导
- 对话开场白 | ㅤ |
变量 | - 环境变量
- 会话变量 | - 全局变量 | 无 |
工作流支持功能 | 基础功能
- LLM
- 知识检索
- 直接回复
Agent
问题理解
- 问题分类器
逻辑
- 条件分支
- 迭代
转换
- 代码执行
- 模板转换
- 变量聚合器
- 文档提取器
- 变量赋值
- 参数提取器
工具
- HTTP请求
- 列表操作
工具
- 工作流
- Api接口 | 基础功能
1. AI对话
2. 知识库搜索
3. 问题分类
4. 文本内容提取
工具箱
1. 工具调用
2. 交互
3. 用户选择
4. 表单输入
5. 工具
6. 文本拼接
7. 指定回复
8. 文档解析
9. HTTP请求
10. 判断器
11. 变量更新
12. 代码运行
13. 批量执行
14. 其他
团队应用
（未显示具体功能）
AI能力
1. 知识库搜索引用合并
2. 问题优化
3. Laf函数调用（测试）
4. 自定义反馈
工具 | 1. 知识检索
2. 生成回答
3. 对话
4. 问题分类
5. 静态消息
6. 问题优化
7. 关键词
8. 条件
9. 集线器
10. 模板转换
11. 循环
12. 注释 |
工作流特点 | - 迭代并发模式
- 错误响应
- 节点并行 | - 批量执行
- AI模型支持变量引用 | ㅤ |
是否支持扩展 | 支持 | 支持贡献插件 | 不支持 |
导入导出 | 支持 | 不支持 | 支持 |
测试历史 | 支持 | 支持 | ㅤ |
发布渠道 | - web应用
- Api接口
- 嵌入网站 | - Web网页
- Api接口
- 飞书机器人
- 钉钉机器人
- 微信公众号接入 | - 嵌入网站 |
日志与标注 | 支持
- 详细显示调用日志
- 针对问答可以进行标注 | 支持
- 详细显示调用日志
- 针对问答可以进行标注 | 无 |
监测 | 7大维度分析 | 不支持 | ㅤ |
ㅤ | ㅤ | ㅤ | ㅤ |
特色功能 | 错误响应 | 自动执行
定时任务 | 搜索 |
推荐值 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
从上述对比当中，Dify的应用方面吊打其他两家，无论是编排的方式，错误的处理还有未来的扩展上，都是第一位。并且搭配了丰富的日志，方便后续的追踪。
而且dify还可以的搭配LangSmith、Langfuse、opik进行LLM应用的生命周期监控。
4.6 开源协议
开源协议也是商业公司在使用的时候特别关注的部分，这一章，我们针对各个工作流进行协议的对比，看下哪个框架更适合企业使用
产品 | 协议 |
Dify | - Dify可以用于商业用途，包括作为其他应用程序的后端服务或企业应用开发平台。
- 不能使用Dify源代码来运营多租户环境。 |
FastGPT | - FastGPT可以用于商业化用途，包括作为“后端即服务”（backend-as-a-service）为其他应用程序提供服务，或作为应用开发平台交付给企业。
- 不能使用FastGPT.AI源代码运营与FastGPT类似的多租户SaaS服务。 |
RAGFlow | - 允许您复制、修改、公开显示、公开表演、分许可和分发作品及其衍生作品。 |
4.7 部署难度
一个平台功能是一方面，部署难度，依赖的技术栈都需要考量，下面总结下部署难度与依赖
维度 | Dify | FastGPT | RAGFlow |
Docker部署 | 支持 | 支持 | 支持 |
技术栈 | - Python flask
- Nextjs
- PostgresSQL
- Qdrant
- Redis
- Unstructured
- Sandbox
- Plugin Demon | - pg vector
- mongo
- sandbox
- mysql
- fastgpt | - es
- MySQL
- minio
- Redis |
五、汇总
维度 | Dify | FastGPT | RAGFlow |
团队人员管理 | 🌟🌟 | 🌟 | 🌟🌟 |
模型管理 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
第三方工具 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
知识库 | 🌟🌟 | 🌟 | 🌟🌟🌟 |
应用管理 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
六、结束
经过多方面你的对比，我们对基于web页面的工作流有了一定的了解。我们会发现每个框架都有自己的特点与用处，工作流知识我们解决问题的一个工具，不要痴迷工具。
我们需要更好的利用各个工具的特点，掌握AI工作流的核心才是最重要的
最后推荐几个几篇我与AI共创的文章