企業(yè)在落地 RAG 知識(shí)庫(kù)時(shí)， Dify 和 RAGFlow 這兩個(gè)開源框架應(yīng)該選擇哪個(gè)？

這也是我一直以來(lái)做RAG咨詢時(shí)，經(jīng)常被企業(yè)方問到的問題之一。一般來(lái)說(shuō)，如果需要處理特別復(fù)雜的文檔和非結(jié)構(gòu)化數(shù)據(jù)，RAGFlow 是優(yōu)選。而對(duì)于需要多模型協(xié)作和復(fù)雜業(yè)務(wù)流程的場(chǎng)景，Dify 更為適合。

但這并非是個(gè)，非此即彼的問題。

這篇試圖說(shuō)清：

如何將 Dify 作為主框架使用其 agent 和工作流組件，同時(shí)通過(guò) API 調(diào)用 RAGFlow 的知識(shí)庫(kù)組件。從而將 Dify 的用戶友好界面和工作流能力與 RAGFlow 的深度文檔處理能力結(jié)合起來(lái)。

注：除了 Dify+RAGFlow 的組合外，也可以結(jié)合具體業(yè)務(wù)場(chǎng)景選擇添加更多開源框架，如 LlamaIndex、LigthtRAG 等。

以下，enjoy:

1、從優(yōu)勢(shì)互補(bǔ)說(shuō)起

1.1 Dify 的主要優(yōu)勢(shì):

易用性高，無(wú)需花費(fèi)大量時(shí)間閱讀文檔就能快速上手

快速部署，可在 30 分鐘內(nèi)部署原型

模塊化設(shè)計(jì)，便于開發(fā)者進(jìn)行二次開發(fā)

支持豐富的外部拓展工具和任務(wù)流編排，類似 Coze,但拓展性更好

跨知識(shí)庫(kù)檢索支持，能自動(dòng)選擇合適的知識(shí)庫(kù)，這點(diǎn) RAGFlow 目前不支持

1.2 RAGFlow 主要的優(yōu)勢(shì)

文件精細(xì)解析能力強(qiáng)，在處理 PDF、掃描件、表格等復(fù)雜文檔方面表現(xiàn)出色

擁有 DeepDoc 技術(shù)，可以處理非結(jié)構(gòu)化文檔

支持 OCR、內(nèi)置多種文檔切分模板

對(duì)延遲敏感的應(yīng)用時(shí)表現(xiàn)出色，可以輕松應(yīng)對(duì)繁重的工作負(fù)載

1.3 優(yōu)勢(shì)互補(bǔ)的好處

通過(guò) Dify+RAGFlow 的混合架構(gòu)，可以實(shí)現(xiàn)如下好處:

利用 Dify 強(qiáng)大的工作流編排和 Agent 能力構(gòu)建復(fù)雜應(yīng)用

同時(shí)獲得 RAGFlow 優(yōu)秀的文檔處理和解析能力

通過(guò) API 集成保持系統(tǒng)的靈活性和可擴(kuò)展性

2、端口修改的準(zhǔn)備工作

2.1 端口概念解析

在 Docker Compose 的端口映射中，格式為 A:B，其中 A 代表宿主機(jī)端口，B 代表容器內(nèi)部端口。因此，80:80 表示宿主機(jī)的 80 端口映射到容器的 80 端口，443:443 則表示宿主機(jī)的 443 端口映射到容器的 443 端口。通常，容器中的 80 端口就是用來(lái)處理 HTTP 請(qǐng)求，而 443 端口處理 HTTPS 請(qǐng)求。

2.2 端口修改

RAGFlow 和 Dify 官方都推薦使用 Docker 部署，為了防止與 Dify 發(fā)生端口沖突，建議把 RAGFlow 的宿主機(jī)的端口修改為其他值，而保留容器端口不變。比如，可以將 80:80 改為 8080:80，即將原有的 80 端口映射改為 8080（宿主機(jī)）對(duì) 80（容器）；同理，將 443:443 改為 8443:443。

注意修改的是左側(cè)的數(shù)字（宿主機(jī)端口），但要確保新端口未被其他程序占用。此外，修改后需要保存 docker-compose.yml 文件，并重啟容器，使新配置生效。通?？梢允褂?docker-compose down 和 docker-compose up -d 重新啟動(dòng)服務(wù)。

這種方法可以確保你同時(shí)部署 Ragflow 和 Dify 時(shí)，不會(huì)出現(xiàn)宿主機(jī)端口沖突，同時(shí)內(nèi)部服務(wù)依然使用原有的 HTTP/HTTPS 端口設(shè)置。

注：有盆友可能會(huì)疑問 Ragflow 和 Dify 都有 Redis 服務(wù)，是否也需要對(duì)應(yīng)修改 RAGFlow 的端口號(hào)。回答是不用的。Dify 的 Redis 僅僅在內(nèi)部使用，即其 Redis 容器沒有將服務(wù)端口映射到宿主機(jī)，因此僅供其它容器訪問，不會(huì)與外部產(chǎn)生端口沖突。

2.3 Dify啟動(dòng)命令修改

因?yàn)镈ocker Compose 使用項(xiàng)目名稱來(lái)隔離不同的項(xiàng)目環(huán)境。 默認(rèn)情況下，項(xiàng)目名稱是docker-compose.yml文件所在目錄的名稱。由于Ragflow和Dify的docker-compose.yml目錄的docker目錄下，導(dǎo)致兩個(gè)服務(wù)的容器未能被有效隔離，從而引發(fā)沖突。

解決方案也很簡(jiǎn)單，RAGFlow基礎(chǔ)docker服務(wù)啟動(dòng)方式不變。但是Dify啟動(dòng)時(shí)候要通過(guò)﹣p參數(shù)顯式指定項(xiàng)目名稱。參考圖示中的docker compose -p dify_docker up -d。

2.4 修改驗(yàn)證

在瀏覽器中訪問 http://localhost:8080 ，檢査 RAGFlow 是否正常運(yùn)行。如果服務(wù)正常啟動(dòng)，你應(yīng)該能夠看到 RAGFlow 的 Web 界面。 完成以上步驟后，RAGFlow 的默認(rèn)端口將從 80 修改為 8080。

需要注意的是，在我上篇介紹的在 RAGFlow 中通過(guò)圖片服務(wù)器容器化實(shí)現(xiàn)問答中渲染本地圖片的腳本，因?yàn)樯鲜鲂薷牡?RAGFlow 端口號(hào)，所以需要修改 ragflow_build.py中初始化 RAGFlow 客戶端的代碼，默認(rèn) base_url 參數(shù)是"http://localhost" ， 沒有指定端口號(hào)。由于已將原來(lái)的 80 端口映射修改為 8080:80，現(xiàn)在需要相應(yīng)更新 base_url 參數(shù)。

RAGFlow如何實(shí)現(xiàn)圖片問答：原理分析+詳細(xì)步驟（附源碼） 

需要查看源代碼的請(qǐng)移步知識(shí)星球，加入后請(qǐng)后臺(tái)私信我進(jìn)會(huì)員群。

3、詳細(xì)操作步驟

3.1 URL 配置注意

在 Dify 中配置 RAGFlow 的知識(shí)庫(kù)時(shí)，需要在 RAGFlow 的基礎(chǔ) Base url 后增加 “api/v1/dify”，這是 Dify 特定的 API 路徑，它承擔(dān)版本控制、模塊劃分等作用。當(dāng)然這也很符合 RESTful 的設(shè)計(jì)思想。

3.2 創(chuàng)建知識(shí)庫(kù)

完成 Dify 和 RAGFlow 的 API 連接之后，就可以緊接著創(chuàng)建知識(shí)庫(kù)，需要注意的是，需要點(diǎn)擊的是“連接外部知識(shí)庫(kù)”這個(gè)按鈕。下一步會(huì)提示需要輸入外部知識(shí)庫(kù) ID，這個(gè)信息需要在大家 RAGFlow 對(duì)應(yīng)的知識(shí)庫(kù)頁(yè)面，在瀏覽器的地址后綴上能看到完整的 ID 數(shù)字，直接復(fù)制過(guò)來(lái)填下。

3.3 連通測(cè)試

在創(chuàng)建完知識(shí)庫(kù)后，可以大家這個(gè)知識(shí)庫(kù)進(jìn)行召回測(cè)試，這個(gè)類似 RAGFlow 的檢索測(cè)試功能，主要是為了檢驗(yàn)下上述的兩步配置是否成功。需要注意的是，在這一步還不需要配置 LLM 即可進(jìn)行測(cè)試。

3.4 模型供應(yīng)商配置

在創(chuàng)建具體的 ChatBot 之前，我們需要現(xiàn)在設(shè)置頁(yè)面配置 LLM 的來(lái)源。這里既可以選擇 Ollama 本地部署的模型，也可以直接選擇商業(yè) API。

這里需要提示的是，為了后續(xù)更好進(jìn)行分塊和檢索策略的調(diào)優(yōu)，如果你的電腦上沒有部署DeepSeek-R1-Distill-Qwen-32B或同等水平的開源模型，建議這一步還是先用商業(yè) API。

3.5 創(chuàng)建 ChatBot

這一步很簡(jiǎn)單，就是輸入系統(tǒng)提示詞，綁定上述的第二步創(chuàng)建的知識(shí)庫(kù)，再在右上角選擇使用的相關(guān)模型即可進(jìn)行問答測(cè)試。我這里為了測(cè)試效果，輸入的提示詞和 RAGFlow 中的保持一致，大家可以做個(gè)參考。單就 ChatBot 功能，初步測(cè)試下來(lái)準(zhǔn)確率沒有明顯差別，圖片也能正常顯示。

但有所不同的是，Dify 中的 ChatBot 提供了更豐富的配置選項(xiàng)。比如為了測(cè)試不同問答模型的回答效果，可以同時(shí)添加多個(gè) LLM 進(jìn)行同一個(gè)問題的對(duì)比回答。但是這個(gè)入口其實(shí)有點(diǎn)小深，各位參考圖示操作。

我這里是測(cè)試了 DeepSeek-R1-Distill-Qwen-32B 和 Qwen2.5-32B-Instruct 兩個(gè)模型，測(cè)試了幾個(gè)問題后，回答速度和效果基本沒有明顯差別，都還夠用。

這里也解釋下為啥要用這兩個(gè)開源模型，雖然我并不推薦中小企業(yè)在 POC 階段剛過(guò)早的做 LLM 的本地化部署，但是實(shí)際真的要部署這兩個(gè)尺寸的開源模型也基本夠用了。所以我日常在給一些企業(yè)方做項(xiàng)目 Demo 的時(shí)候也會(huì)傾向于直接使用這兩款來(lái)進(jìn)行測(cè)試，從而保證實(shí)際本地部署后的效果一致性。

另外這個(gè) ChatBot 還有個(gè)特性是，你可以根據(jù)業(yè)務(wù)需求增加更多的個(gè)性化功能，例如 Conversation Opener、Follow-up、Text to Speech、Speech to Text 等，具體大家可以自行測(cè)試。需要說(shuō)明的是，Citations and Attributions 這個(gè)回答的出處引用是默認(rèn)打開的。

4、創(chuàng)建工作流

Dify 中 Studio 模塊提供了 Chatbot、Agent、Completion、Chatflow、Workflow 等多種選擇，然后在工作流中又包含了很多 Blocks 和 tools 的選項(xiàng)，這些看起來(lái)似乎讓人眼花繚亂。

4.1 應(yīng)用類型比較

Chatbot：基礎(chǔ)聊天助手，適合簡(jiǎn)單的問答交互

Chatflow：面向?qū)υ掝惽榫?，支持多步邏輯和?duì)話歷史記憶，包括客戶服務(wù)、語(yǔ)義搜索等場(chǎng)景

Workflow：面向自動(dòng)化和批處理場(chǎng)景，適合高質(zhì)量翻譯、數(shù)據(jù)分析、內(nèi)容生成、電子郵件自動(dòng)化等

Agent：智能助手，能自主對(duì)復(fù)雜任務(wù)進(jìn)行規(guī)劃、拆解、工具調(diào)用和迭代

Chatflow 相比 Workflow 增加了對(duì)話特性支持，如對(duì)話歷史記憶、標(biāo)注回復(fù)和 Answer 節(jié)點(diǎn)等。Workflow 則專注于復(fù)雜業(yè)務(wù)邏輯處理，提供豐富邏輯節(jié)點(diǎn)和定時(shí)/事件觸發(fā)能力。

4.2 功能塊（Block)解析

LLM：核心處理節(jié)點(diǎn)，利用大語(yǔ)言模型處理各類任務(wù)

Knowledge Retrieval：從知識(shí)庫(kù)檢索與用戶問題相關(guān)的內(nèi)容

Answer：定義回復(fù)內(nèi)容的格式和展示

Agent：智能助手節(jié)點(diǎn)，可自主規(guī)劃和執(zhí)行任務(wù)

Question Understand：理解用戶意圖

Question Classifier：對(duì)問題進(jìn)行分類，引導(dǎo)不同處理邏輯

IF/ELSE：條件分支節(jié)點(diǎn)，基于條件將工作流分為兩個(gè)分支

Iteration/Loop：循環(huán)處理節(jié)點(diǎn)

Code：執(zhí)行自定義代碼邏輯的節(jié)點(diǎn)

Template：使用 Jinja2 模板進(jìn)行數(shù)據(jù)轉(zhuǎn)換

Variable Aggregator：聚合多分支變量

Parameter Extractor：從自然語(yǔ)言提取結(jié)構(gòu)化參數(shù)

4.3 工具(Tool)組件解析

第一方工具：Dify 生態(tài)提供的內(nèi)置工具，如 Audio、Code Interpreter、CurrentTime、WebScraper 等

自定義工具：可導(dǎo)入符合 OpenAPI/Swagger 或 OpenAI Plugin 規(guī)范的自定義 API 工具

這些工具可以擴(kuò)展 LLM 的能力，如聯(lián)網(wǎng)搜索、科學(xué)計(jì)算、繪圖等，使 AI 應(yīng)用能連接外部世界。通過(guò)自定義工具，還可以實(shí)現(xiàn)內(nèi)容審查、敏感詞過(guò)濾等功能。有一說(shuō)一，自定義工具這個(gè)很強(qiáng)，后續(xù)我考慮專門出一期內(nèi)容介紹這個(gè)。

5、工作流應(yīng)用示例

泵作為工廠常見通用設(shè)備，其突發(fā)故障往往會(huì)導(dǎo)致整條生產(chǎn)線停擺，造成重大經(jīng)濟(jì)損失。下面介紹一個(gè)我近期實(shí)施過(guò)的泵類設(shè)備預(yù)測(cè)性維護(hù)智能系統(tǒng)，其中充分利用了 Dify 的各種功能模塊和工具節(jié)點(diǎn)，整合靜態(tài)知識(shí)庫(kù)、MCP 鏈接外部數(shù)據(jù)源、問答分類和維保報(bào)告生成功能。

5.1 系統(tǒng)架構(gòu)圖

+----------------------------------+
|            用戶界面層            |
|  Web界面 | 移動(dòng)App | 企業(yè)微信集成  |
+----------------------------------+
              |
+----------------------------------+
|          Dify核心平臺(tái)層          |
| 工作流編排 | Agent | RAG | 知識(shí)庫(kù) |
+----------------------------------+
        |             |
+----------------+ +------------------+
|  MCP連接層    | |    外部系統(tǒng)集成    |
|  數(shù)據(jù)收集接口  | | ERP | MES | CMMS |
+----------------+ +------------------+
        |
+----------------------------------+
|           設(shè)備物聯(lián)網(wǎng)層           |
| 振動(dòng)傳感器 | 溫度傳感器 | 壓力傳感器 |
+----------------------------------+

5.2 工作流程設(shè)計(jì)

A. 狀態(tài)監(jiān)控工作流

該工作流通過(guò)傳感器持續(xù)監(jiān)控泵的振動(dòng)、溫度、壓力等參數(shù)，使用 IF/ELSE 節(jié)點(diǎn)對(duì)異常狀態(tài)進(jìn)行判斷，發(fā)現(xiàn)異常時(shí)觸發(fā)告警。 

B. 故障預(yù)測(cè)工作流

將收集的數(shù)據(jù)與歷史故障模式進(jìn)行比對(duì)，使用 LLM 和 Knowledge Retrieval 節(jié)點(diǎn)分析數(shù)據(jù)趨勢(shì)，預(yù)測(cè)可能的故障時(shí)間和類型。 

C. 維保建議工作流

根據(jù)預(yù)測(cè)結(jié)果，生成具體的維護(hù)建議和計(jì)劃，包括所需備件、維修時(shí)長(zhǎng)和最佳維修時(shí)間窗口，通過(guò) Template 節(jié)點(diǎn)生成標(biāo)準(zhǔn)化工單。

D. 閉環(huán)反饋工作流

收集實(shí)際維修結(jié)果與預(yù)測(cè)的對(duì)比，通過(guò) Agent 節(jié)點(diǎn)分析差異并不斷優(yōu)化模型，形成閉環(huán)反饋，持續(xù)提升預(yù)測(cè)準(zhǔn)確性。 

5.3 關(guān)鍵節(jié)點(diǎn)配置示例

設(shè)備狀態(tài)監(jiān)控節(jié)點(diǎn)配置：

- HTTP Request節(jié)點(diǎn)：
  接口URL: http://iot-platform/api/pump/status
  參數(shù): {"pumpId": "{{pumpId}}", "timeRange": "{{timeRange}}"}


- Code節(jié)點(diǎn)（數(shù)據(jù)處理）:
  處理振動(dòng)、溫度等數(shù)據(jù)，計(jì)算偏差值


- IF/ELSE節(jié)點(diǎn)：
  條件: vibration > threshold || temperature > limit
  是分支: 觸發(fā)告警流程
  否分支: 正常記錄數(shù)據(jù)

故障預(yù)測(cè) LLM 節(jié)點(diǎn)提示詞：

系統(tǒng)提示: 你是一位專業(yè)的泵類設(shè)備故障預(yù)測(cè)專家。根據(jù)以下設(shè)備參數(shù)和歷史數(shù)據(jù)，分析可能存在的故障風(fēng)險(xiǎn)，預(yù)測(cè)故障類型和可能的發(fā)生時(shí)間。


用戶輸入: 
設(shè)備ID: {{pumpId}}
當(dāng)前振動(dòng)值: {{vibration}}
當(dāng)前溫度: {{temperature}}
當(dāng)前壓力: {{pressure}}
歷史故障模式: {{historyFailures}}

維保報(bào)告生成節(jié)點(diǎn):

- Template節(jié)點(diǎn):
  設(shè)備巡檢報(bào)告
  設(shè)備ID: {{pumpId}}
  巡檢時(shí)間: {{inspectionTime}}


  設(shè)備狀態(tài): {{status}}
  預(yù)測(cè)壽命: {{remainingLife}}


  異常項(xiàng):
  {% for issue in issues %}
  - {{issue.name}}: {{issue.description}}
  {% endfor %}


  維護(hù)建議:
  {{maintenanceSuggestions}}


  下次計(jì)劃維護(hù)時(shí)間: {{nextMaintenanceDate}}

6、寫在最后

RAG 自從 2020 年由 Meta 提出，23 年春 Nvidia GTC 大會(huì)后火熱之后，一直面臨著來(lái)自“微調(diào)”和“長(zhǎng)上下文 LLM”的對(duì)比爭(zhēng)議。不過(guò)兩年下來(lái)，共識(shí)已經(jīng)基本形成：

一方面是從成本和實(shí)時(shí)性角度，RAG 具有壓倒性優(yōu)勢(shì)，而效果上相差也并不大，即使需要微調(diào)介入的場(chǎng)景，RAG 通常也不可或缺。另一方面，長(zhǎng)上下文 LLM 依然面臨在上下文段落增加時(shí)準(zhǔn)確率不斷下降的事實(shí)。所以，在任何情況下，提供高精度的搜索系統(tǒng)（RAG）都是極有價(jià)值的，RAG 當(dāng)前也已經(jīng)是一種事實(shí)上的落地標(biāo)準(zhǔn)架構(gòu)。