企業在落地 RAG 知識庫時， Dify 和 RAGFlow 這兩個開源框架應該選擇哪個？

這也是我一直以來做RAG咨詢時，經常被企業方問到的問題之一。一般來說，如果需要處理特別復雜的文檔和非結構化數據，RAGFlow 是優選。而對于需要多模型協作和復雜業務流程的場景，Dify 更為適合。

但這并非是個，非此即彼的問題。

這篇試圖說清：

如何將 Dify 作為主框架使用其 agent 和工作流組件，同時通過 API 調用 RAGFlow 的知識庫組件。從而將 Dify 的用戶友好界面和工作流能力與 RAGFlow 的深度文檔處理能力結合起來。

注：除了 Dify+RAGFlow 的組合外，也可以結合具體業務場景選擇添加更多開源框架，如 LlamaIndex、LigthtRAG 等。

以下，enjoy:

1、從優勢互補說起

1.1 Dify 的主要優勢:

易用性高，無需花費大量時間閱讀文檔就能快速上手

快速部署，可在 30 分鐘內部署原型

模塊化設計，便于開發者進行二次開發

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

跨知識庫檢索支持，能自動選擇合適的知識庫，這點 RAGFlow 目前不支持

1.2 RAGFlow 主要的優勢

文件精細解析能力強，在處理 PDF、掃描件、表格等復雜文檔方面表現出色

擁有 DeepDoc 技術，可以處理非結構化文檔

支持 OCR、內置多種文檔切分模板

對延遲敏感的應用時表現出色，可以輕松應對繁重的工作負載

1.3 優勢互補的好處

通過 Dify+RAGFlow 的混合架構，可以實現如下好處:

利用 Dify 強大的工作流編排和 Agent 能力構建復雜應用

同時獲得 RAGFlow 優秀的文檔處理和解析能力

通過 API 集成保持系統的靈活性和可擴展性

2、端口修改的準備工作

2.1 端口概念解析

在 Docker Compose 的端口映射中，格式為 A:B，其中 A 代表宿主機端口，B 代表容器內部端口。因此，80:80 表示宿主機的 80 端口映射到容器的 80 端口，443:443 則表示宿主機的 443 端口映射到容器的 443 端口。通常，容器中的 80 端口就是用來處理 HTTP 請求，而 443 端口處理 HTTPS 請求。

2.2 端口修改

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

注意修改的是左側的數字（宿主機端口），但要確保新端口未被其他程序占用。此外，修改后需要保存 docker-compose.yml 文件，并重啟容器，使新配置生效。通常可以使用 docker-compose down 和 docker-compose up -d 重新啟動服務。

這種方法可以確保你同時部署 Ragflow 和 Dify 時，不會出現宿主機端口沖突，同時內部服務依然使用原有的 HTTP/HTTPS 端口設置。

注：有盆友可能會疑問 Ragflow 和 Dify 都有 Redis 服務，是否也需要對應修改 RAGFlow 的端口號。回答是不用的。Dify 的 Redis 僅僅在內部使用，即其 Redis 容器沒有將服務端口映射到宿主機，因此僅供其它容器訪問，不會與外部產生端口沖突。

2.3 Dify啟動命令修改

因為Docker Compose 使用項目名稱來隔離不同的項目環境。 默認情況下，項目名稱是docker-compose.yml文件所在目錄的名稱。由于Ragflow和Dify的docker-compose.yml目錄的docker目錄下，導致兩個服務的容器未能被有效隔離，從而引發沖突。

解決方案也很簡單，RAGFlow基礎docker服務啟動方式不變。但是Dify啟動時候要通過﹣p參數顯式指定項目名稱。參考圖示中的docker compose -p dify_docker up -d。

2.4 修改驗證

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

需要注意的是，在我上篇介紹的在 RAGFlow 中通過圖片服務器容器化實現問答中渲染本地圖片的腳本，因為上述修改的 RAGFlow 端口號，所以需要修改 ragflow_build.py中初始化 RAGFlow 客戶端的代碼，默認 base_url 參數是"http://localhost" ， 沒有指定端口號。由于已將原來的 80 端口映射修改為 8080:80，現在需要相應更新 base_url 參數。

RAGFlow如何實現圖片問答：原理分析+詳細步驟（附源碼） 

需要查看源代碼的請移步知識星球，加入后請后臺私信我進會員群。

3、詳細操作步驟

3.1 URL 配置注意

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

3.2 創建知識庫

完成 Dify 和 RAGFlow 的 API 連接之后，就可以緊接著創建知識庫，需要注意的是，需要點擊的是“連接外部知識庫”這個按鈕。下一步會提示需要輸入外部知識庫 ID，這個信息需要在大家 RAGFlow 對應的知識庫頁面，在瀏覽器的地址后綴上能看到完整的 ID 數字，直接復制過來填下。

3.3 連通測試

在創建完知識庫后，可以大家這個知識庫進行召回測試，這個類似 RAGFlow 的檢索測試功能，主要是為了檢驗下上述的兩步配置是否成功。需要注意的是，在這一步還不需要配置 LLM 即可進行測試。

3.4 模型供應商配置

在創建具體的 ChatBot 之前，我們需要現在設置頁面配置 LLM 的來源。這里既可以選擇 Ollama 本地部署的模型，也可以直接選擇商業 API。

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

3.5 創建 ChatBot

這一步很簡單，就是輸入系統提示詞，綁定上述的第二步創建的知識庫，再在右上角選擇使用的相關模型即可進行問答測試。我這里為了測試效果，輸入的提示詞和 RAGFlow 中的保持一致，大家可以做個參考。單就 ChatBot 功能，初步測試下來準確率沒有明顯差別，圖片也能正常顯示。

但有所不同的是，Dify 中的 ChatBot 提供了更豐富的配置選項。比如為了測試不同問答模型的回答效果，可以同時添加多個 LLM 進行同一個問題的對比回答。但是這個入口其實有點小深，各位參考圖示操作。

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

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

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

4、創建工作流

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

4.1 應用類型比較

Chatbot：基礎聊天助手，適合簡單的問答交互

Chatflow：面向對話類情境，支持多步邏輯和對話歷史記憶，包括客戶服務、語義搜索等場景

Workflow：面向自動化和批處理場景，適合高質量翻譯、數據分析、內容生成、電子郵件自動化等

Agent：智能助手，能自主對復雜任務進行規劃、拆解、工具調用和迭代

Chatflow 相比 Workflow 增加了對話特性支持，如對話歷史記憶、標注回復和 Answer 節點等。Workflow 則專注于復雜業務邏輯處理，提供豐富邏輯節點和定時/事件觸發能力。

4.2 功能塊（Block)解析

LLM：核心處理節點，利用大語言模型處理各類任務

Knowledge Retrieval：從知識庫檢索與用戶問題相關的內容

Answer：定義回復內容的格式和展示

Agent：智能助手節點，可自主規劃和執行任務

Question Understand：理解用戶意圖

Question Classifier：對問題進行分類，引導不同處理邏輯

IF/ELSE：條件分支節點，基于條件將工作流分為兩個分支

Iteration/Loop：循環處理節點

Code：執行自定義代碼邏輯的節點

Template：使用 Jinja2 模板進行數據轉換

Variable Aggregator：聚合多分支變量

Parameter Extractor：從自然語言提取結構化參數

4.3 工具(Tool)組件解析

第一方工具：Dify 生態提供的內置工具，如 Audio、Code Interpreter、CurrentTime、WebScraper 等

自定義工具：可導入符合 OpenAPI/Swagger 或 OpenAI Plugin 規范的自定義 API 工具

這些工具可以擴展 LLM 的能力，如聯網搜索、科學計算、繪圖等，使 AI 應用能連接外部世界。通過自定義工具，還可以實現內容審查、敏感詞過濾等功能。有一說一，自定義工具這個很強，后續我考慮專門出一期內容介紹這個。

5、工作流應用示例

泵作為工廠常見通用設備，其突發故障往往會導致整條生產線停擺，造成重大經濟損失。下面介紹一個我近期實施過的泵類設備預測性維護智能系統，其中充分利用了 Dify 的各種功能模塊和工具節點，整合靜態知識庫、MCP 鏈接外部數據源、問答分類和維保報告生成功能。

5.1 系統架構圖

+----------------------------------+
|            用戶界面層            |
|  Web界面 | 移動App | 企業微信集成  |
+----------------------------------+
              |
+----------------------------------+
|          Dify核心平臺層          |
| 工作流編排 | Agent | RAG | 知識庫 |
+----------------------------------+
        |             |
+----------------+ +------------------+
|  MCP連接層    | |    外部系統集成    |
|  數據收集接口  | | ERP | MES | CMMS |
+----------------+ +------------------+
        |
+----------------------------------+
|           設備物聯網層           |
| 振動傳感器 | 溫度傳感器 | 壓力傳感器 |
+----------------------------------+

5.2 工作流程設計

A. 狀態監控工作流

該工作流通過傳感器持續監控泵的振動、溫度、壓力等參數，使用 IF/ELSE 節點對異常狀態進行判斷，發現異常時觸發告警。 

B. 故障預測工作流

將收集的數據與歷史故障模式進行比對，使用 LLM 和 Knowledge Retrieval 節點分析數據趨勢，預測可能的故障時間和類型。 

C. 維保建議工作流

根據預測結果，生成具體的維護建議和計劃，包括所需備件、維修時長和最佳維修時間窗口，通過 Template 節點生成標準化工單。

D. 閉環反饋工作流

收集實際維修結果與預測的對比，通過 Agent 節點分析差異并不斷優化模型，形成閉環反饋，持續提升預測準確性。 

5.3 關鍵節點配置示例

設備狀態監控節點配置：

- HTTP Request節點：
  接口URL: http://iot-platform/api/pump/status
  參數: {"pumpId": "{{pumpId}}", "timeRange": "{{timeRange}}"}


- Code節點（數據處理）:
  處理振動、溫度等數據，計算偏差值


- IF/ELSE節點：
  條件: vibration > threshold || temperature > limit
  是分支: 觸發告警流程
  否分支: 正常記錄數據

故障預測 LLM 節點提示詞：

系統提示: 你是一位專業的泵類設備故障預測專家。根據以下設備參數和歷史數據，分析可能存在的故障風險，預測故障類型和可能的發生時間。


用戶輸入: 
設備ID: {{pumpId}}
當前振動值: {{vibration}}
當前溫度: {{temperature}}
當前壓力: {{pressure}}
歷史故障模式: {{historyFailures}}

維保報告生成節點:

- Template節點:
  設備巡檢報告
  設備ID: {{pumpId}}
  巡檢時間: {{inspectionTime}}


  設備狀態: {{status}}
  預測壽命: {{remainingLife}}


  異常項:
  {% for issue in issues %}
  - {{issue.name}}: {{issue.description}}
  {% endfor %}


  維護建議:
  {{maintenanceSuggestions}}


  下次計劃維護時間: {{nextMaintenanceDate}}

6、寫在最后

RAG 自從 2020 年由 Meta 提出，23 年春 Nvidia GTC 大會后火熱之后，一直面臨著來自“微調”和“長上下文 LLM”的對比爭議。不過兩年下來，共識已經基本形成：

一方面是從成本和實時性角度，RAG 具有壓倒性優勢，而效果上相差也并不大，即使需要微調介入的場景，RAG 通常也不可或缺。另一方面，長上下文 LLM 依然面臨在上下文段落增加時準確率不斷下降的事實。所以，在任何情況下，提供高精度的搜索系統（RAG）都是極有價值的，RAG 當前也已經是一種事實上的落地標準架構。