dify+ragflow技术方案

1,182 阅读5分钟

一、知识库多方案处理现状

当前主流的AI知识库处理方案有Dify、钉钉AI助理、Coze、RAGFlow、ChatWiki等,各具特点:

1.    Dify:基于RAG技术,支持混合检索(向量+关键词)和动态更新知识库,提供可视化管理界面,适配多类型数据源,可用于搭建垂直领域问答应用,如智能客服、企业内部知识助手等。

2.    钉钉AI助理:依托钉钉组织架构,权限体系开箱即用,实现知识库无缝权限管理和精细化访问控制,适合企业内部分享与协作。

3.    Coze:以简洁易用为特色,支持知识库嵌入应用程序或网站,采用高效搜索引擎技术,满足不同场景下的即时知识查询需求,适合小型企业、创业团队或个人用户。但是Coze是闭源项目,不能本地化部署。

4.    RAGFlow:开源RAG引擎,支持复杂文档解析(PDF、图片、表格等),提供模板化分块和可视化处理流程,解决传统RAG的“幻觉”和拒答问题,适用于对文档理解精度要求高的场景,如学术论文解析或市场报告分析。

5.    ChatWiki:快速部署的云端方案,支持多模型灵活切换,适配微信公众号、H5渠道,可以购买服务,价格适中,但是知名度不高。

image.png

二、Dify在知识库方面的优缺点

  • 优点:

1.    混合检索优化:向量检索与关键词检索互补,并引入重排序模型,提升结果精准度。

2.    低代码开发:可视化界面,可快速完成知识库构建与应用集成。

  • 缺点:

    1.    依赖外部模型:需配置第三方API,本地处理能力有限,可能增加成本与延迟。

    2.    大文件处理限制:默认上传文件大小限制低,对非结构化数据支持不足。

    3.    知识库检索存在的不足

三、RAGFlow在知识库方面的优缺点

  • 优点:

    1.      深度文档解析:支持OCR、表格识别和布局分析,可处理复杂格式文档,提取结构化知识。

    2.      可解释性高:模板化分块技术允许用户自定义切片规则,提升处理透明度和可控性。

    3.      异构数据兼容:支持多类型数据源,适合跨部门知识整合。

  • 缺点:

    1.      部署复杂度高:需较高硬件配置且依赖Docker环境,对运维能力要求高。

    2.      资源消耗大:处理大规模数据时可能面临存储和计算压力,需优化分块策略。

四、Dify与RAGFlow知识库检索整合

Dify作为主框架,负责应用层逻辑构建和用户交互;RAGFlow作为知识库引擎,负责核心知识处理和检索。两者协同构建高效知识库应用系统。

利用Dify的Agent、工作流编排和多模型协作能力,处理复杂业务逻辑和对话流程。通过API调用RAGFlow深度文档解析和向量检索能力,弥补Dify原生知识库不足。具体包括知识库处理、Chatbot构建与交互、答案生成、用户界面与发布等环节。

image.png

五、方案详情

1、后端权限校验+Dify工作流+RAGFlow的知识库

权限校验集成在Dify中:用户输入用户名和密码,通过HTTP请求发送给后端,校验确定身份,之后确定走哪条工作流。 使用Dify自带的bot:利用其bot模板搭建知识库机器人基本框架。

Dify外接RAGFlow的知识库:本地部署RAGFlow,通过API实现数据交互和功能协同。

工作流拆分与组合:将大工作流拆分为多个小工作流,再组合成一个完整工作流处理复杂问题。

简单示例:

image.png

image.png

2、前后端全部自建+Dify工作流+RAGFlow的知识库

前端聊天组件开发:自行设计开发聊天组件,方便后期进行扩展。

后端调用Dify工作流:接收前端请求后,调用Dify工作流API进行处理。

综合管理平台集成:与企业现有综合管理平台集成,这样不需要再去写权限设置。

内部与外部bot的区分:根据不同的使用场景和权限要求,分别使用内部和外部bot。内部bot登录综合平台后使用,外部的bot可以使用Dify自带的(外部文件没有权限限制)。

六、考虑的难点

1.      本地部署的Dify是否需要升级:现在本地部署0.15.3,最新版是1.4.0版本,和1.的版本差距很大。

2.      RAGFlow的部署较为复杂:需投入时间精力学习实践,解决部署过程中的多种问题。 RAGFlow的运行依赖于多个服务组件,如ElasticSearch、MinIO、MySQL、Redis等。这些组件需要分别进行安装、配置和启动,并且它们之间存在复杂的依赖关系,需要确保各组件的版本兼容、网络连通等。

3.      Dify和RAGFlow两者可能存在兼容性问题:需在整合过程中进行充分的接口测试和联合调试,可能需要进行适配调整。

4.      Dify+RAGFlow虽然是较为主流的方案,但是观察Dify的issue,还是有很多相关问题等待解决,如RAGFlow开启知识图谱后和Dify的连接会失败,这些问题都得等实际使用时才会遇到。

七、成本

硬件成本: Dify已经本地部署完成,RAGFlow需要一台CPU≥4核,内存≥16GB,磁盘空间≥50GB的服务器。

软件成本:需要购买embedding、rerank、deepseek等模型的API。

运维成本:需要专业的运维人员来管理和维护RAGFlow系统,包括监控系统运行状态、处理故障等。

八、结尾

等服务器到位后,会持续更新RAGFlow与Dify结合的实战教程,敬请期待。