Dify+RAGFlow:1+1＞2的混合架構(gòu)，詳細教程+實施案例
企業(yè)在落地 RAG 知識庫時， Dify 和 RAGFlow 這兩個開源框架應該選擇哪個？
這也是我一直以來做RAG咨詢時，經(jīng)常被企業(yè)方問到的問題之一。一般來說，如果需要處理特別復雜的文檔和非結(jié)構(gòu)化數(shù)據(jù)，RAGFlow 是優(yōu)選。而對于需要多模型協(xié)作和復雜業(yè)務流程的場景，Dify 更為適合。
但這并非是個，非此即彼的問題。
這篇試圖說清：
如何將 Dify 作為主框架使用其 agent 和工作流組件，同時通過 API 調(diào)用 RAGFlow 的知識庫組件。從而將 Dify 的用戶友好界面和工作流能力與 RAGFlow 的深度文檔處理能力結(jié)合起來。
注：除了 Dify+RAGFlow 的組合外，也可以結(jié)合具體業(yè)務場景選擇添加更多開源框架，如 LlamaIndex、LigthtRAG 等。
以下，enjoy:
1、從優(yōu)勢互補說起
1.1 Dify 的主要優(yōu)勢:
易用性高，無需花費大量時間閱讀文檔就能快速上手
快速部署，可在 30 分鐘內(nèi)部署原型
模塊化設計，便于開發(fā)者進行二次開發(fā)
支持豐富的外部拓展工具和任務流編排，類似 Coze,但拓展性更好
跨知識庫檢索支持，能自動選擇合適的知識庫，這點 RAGFlow 目前不支持
1.2 RAGFlow 主要的優(yōu)勢
文件精細解析能力強，在處理 PDF、掃描件、表格等復雜文檔方面表現(xiàn)出色
擁有 DeepDoc 技術(shù)，可以處理非結(jié)構(gòu)化文檔
支持 OCR、內(nèi)置多種文檔切分模板
對延遲敏感的應用時表現(xiàn)出色，可以輕松應對繁重的工作負載
1.3 優(yōu)勢互補的好處
通過 Dify+RAGFlow 的混合架構(gòu)，可以實現(xiàn)如下好處:
利用 Dify 強大的工作流編排和 Agent 能力構(gòu)建復雜應用
同時獲得 RAGFlow 優(yōu)秀的文檔處理和解析能力
通過 API 集成保持系統(tǒng)的靈活性和可擴展性
2、端口修改的準備工作
2.1 端口概念解析
在 Docker Compose 的端口映射中，格式為 A:B，其中 A 代表宿主機端口，B 代表容器內(nèi)部端口。因此，80:80 表示宿主機的 80 端口映射到容器的 80 端口，443:443 則表示宿主機的 443 端口映射到容器的 443 端口。通常，容器中的 80 端口就是用來處理 HTTP 請求，而 443 端口處理 HTTPS 請求。
2.2 端口修改
RAGFlow 和 Dify 官方都推薦使用 Docker 部署，為了防止與 Dify 發(fā)生端口沖突，建議把 RAGFlow 的宿主機的端口修改為其他值，而保留容器端口不變。比如，可以將 80:80 改為 8080:80，即將原有的 80 端口映射改為 8080（宿主機）對 80（容器）；同理，將 443:443 改為 8443:443。
注意修改的是左側(cè)的數(shù)字（宿主機端口），但要確保新端口未被其他程序占用。此外，修改后需要保存 docker-compose.yml 文件，并重啟容器，使新配置生效。通常可以使用 docker-compose down 和 docker-compose up -d 重新啟動服務。
這種方法可以確保你同時部署 Ragflow 和 Dify 時，不會出現(xiàn)宿主機端口沖突，同時內(nèi)部服務依然使用原有的 HTTP/HTTPS 端口設置。
注：有盆友可能會疑問 Ragflow 和 Dify 都有 Redis 服務，是否也需要對應修改 RAGFlow 的端口號。回答是不用的。Dify 的 Redis 僅僅在內(nèi)部使用，即其 Redis 容器沒有將服務端口映射到宿主機，因此僅供其它容器訪問，不會與外部產(chǎn)生端口沖突。
2.3 Dify啟動命令修改
因為Docker Compose 使用項目名稱來隔離不同的項目環(huán)境。 默認情況下，項目名稱是docker-compose.yml文件所在目錄的名稱。由于Ragflow和Dify的docker-compose.yml目錄的docker目錄下，導致兩個服務的容器未能被有效隔離，從而引發(fā)沖突。
解決方案也很簡單，RAGFlow基礎(chǔ)docker服務啟動方式不變。但是Dify啟動時候要通過﹣p參數(shù)顯式指定項目名稱。參考圖示中的docker compose -p dify_docker up -d。
2.4 修改驗證
在瀏覽器中訪問 http://localhost:8080 ，檢査 RAGFlow 是否正常運行。如果服務正常啟動，你應該能夠看到 RAGFlow 的 Web 界面。 完成以上步驟后，RAGFlow 的默認端口將從 80 修改為 8080。
需要注意的是，在我上篇介紹的在 RAGFlow 中通過圖片服務器容器化實現(xiàn)問答中渲染本地圖片的腳本，因為上述修改的 RAGFlow 端口號，所以需要修改 ragflow_build.py中初始化 RAGFlow 客戶端的代碼，默認 base_url 參數(shù)是"http://localhost" ， 沒有指定端口號。由于已將原來的 80 端口映射修改為 8080:80，現(xiàn)在需要相應更新 base_url 參數(shù)。
RAGFlow如何實現(xiàn)圖片問答：原理分析+詳細步驟（附源碼）
需要查看源代碼的請移步知識星球，加入后請后臺私信我進會員群。
3、詳細操作步驟
3.1 URL 配置注意
在 Dify 中配置 RAGFlow 的知識庫時，需要在 RAGFlow 的基礎(chǔ) Base url 后增加 “api/v1/dify”，這是 Dify 特定的 API 路徑，它承擔版本控制、模塊劃分等作用。當然這也很符合 RESTful 的設計思想。
3.2 創(chuàng)建知識庫
完成 Dify 和 RAGFlow 的 API 連接之后，就可以緊接著創(chuàng)建知識庫，需要注意的是，需要點擊的是“連接外部知識庫”這個按鈕。下一步會提示需要輸入外部知識庫 ID，這個信息需要在大家 RAGFlow 對應的知識庫頁面，在瀏覽器的地址后綴上能看到完整的 ID 數(shù)字，直接復制過來填下。
3.3 連通測試
在創(chuàng)建完知識庫后，可以大家這個知識庫進行召回測試，這個類似 RAGFlow 的檢索測試功能，主要是為了檢驗下上述的兩步配置是否成功。需要注意的是，在這一步還不需要配置 LLM 即可進行測試。
3.4 模型供應商配置
在創(chuàng)建具體的 ChatBot 之前，我們需要現(xiàn)在設置頁面配置 LLM 的來源。這里既可以選擇 Ollama 本地部署的模型，也可以直接選擇商業(yè) API。
這里需要提示的是，為了后續(xù)更好進行分塊和檢索策略的調(diào)優(yōu)，如果你的電腦上沒有部署DeepSeek-R1-Distill-Qwen-32B或同等水平的開源模型，建議這一步還是先用商業(yè) API。
3.5 創(chuàng)建 ChatBot
這一步很簡單，就是輸入系統(tǒng)提示詞，綁定上述的第二步創(chuàng)建的知識庫，再在右上角選擇使用的相關(guān)模型即可進行問答測試。我這里為了測試效果，輸入的提示詞和 RAGFlow 中的保持一致，大家可以做個參考。單就 ChatBot 功能，初步測試下來準確率沒有明顯差別，圖片也能正常顯示。
但有所不同的是，Dify 中的 ChatBot 提供了更豐富的配置選項。比如為了測試不同問答模型的回答效果，可以同時添加多個 LLM 進行同一個問題的對比回答。但是這個入口其實有點小深，各位參考圖示操作。
我這里是測試了 DeepSeek-R1-Distill-Qwen-32B 和 Qwen2.5-32B-Instruct 兩個模型，測試了幾個問題后，回答速度和效果基本沒有明顯差別，都還夠用。
這里也解釋下為啥要用這兩個開源模型，雖然我并不推薦中小企業(yè)在 POC 階段剛過早的做 LLM 的本地化部署，但是實際真的要部署這兩個尺寸的開源模型也基本夠用了。所以我日常在給一些企業(yè)方做項目 Demo 的時候也會傾向于直接使用這兩款來進行測試，從而保證實際本地部署后的效果一致性。
另外這個 ChatBot 還有個特性是，你可以根據(jù)業(yè)務需求增加更多的個性化功能，例如 Conversation Opener、Follow-up、Text to Speech、Speech to Text 等，具體大家可以自行測試。需要說明的是，Citations and Attributions 這個回答的出處引用是默認打開的。
4、創(chuàng)建工作流
Dify 中 Studio 模塊提供了 Chatbot、Agent、Completion、Chatflow、Workflow 等多種選擇，然后在工作流中又包含了很多 Blocks 和 tools 的選項，這些看起來似乎讓人眼花繚亂。
4.1 應用類型比較
Chatbot：基礎(chǔ)聊天助手，適合簡單的問答交互
Chatflow：面向?qū)υ掝惽榫常С侄嗖竭壿嫼蛯υ挌v史記憶，包括客戶服務、語義搜索等場景
Workflow：面向自動化和批處理場景，適合高質(zhì)量翻譯、數(shù)據(jù)分析、內(nèi)容生成、電子郵件自動化等
Agent：智能助手，能自主對復雜任務進行規(guī)劃、拆解、工具調(diào)用和迭代
Chatflow 相比 Workflow 增加了對話特性支持，如對話歷史記憶、標注回復和 Answer 節(jié)點等。Workflow 則專注于復雜業(yè)務邏輯處理，提供豐富邏輯節(jié)點和定時/事件觸發(fā)能力。
4.2 功能塊（Block)解析
LLM：核心處理節(jié)點，利用大語言模型處理各類任務
Knowledge Retrieval：從知識庫檢索與用戶問題相關(guān)的內(nèi)容
Answer：定義回復內(nèi)容的格式和展示
Agent：智能助手節(jié)點，可自主規(guī)劃和執(zhí)行任務
Question Understand：理解用戶意圖
Question Classifier：對問題進行分類，引導不同處理邏輯
IF/ELSE：條件分支節(jié)點，基于條件將工作流分為兩個分支
Iteration/Loop：循環(huán)處理節(jié)點
Code：執(zhí)行自定義代碼邏輯的節(jié)點
Template：使用 Jinja2 模板進行數(shù)據(jù)轉(zhuǎn)換
Variable Aggregator：聚合多分支變量
Parameter Extractor：從自然語言提取結(jié)構(gòu)化參數(shù)
4.3 工具(Tool)組件解析
第一方工具：Dify 生態(tài)提供的內(nèi)置工具，如 Audio、Code Interpreter、CurrentTime、WebScraper 等
自定義工具：可導入符合 OpenAPI/Swagger 或 OpenAI Plugin 規(guī)范的自定義 API 工具
這些工具可以擴展 LLM 的能力，如聯(lián)網(wǎng)搜索、科學計算、繪圖等，使 AI 應用能連接外部世界。通過自定義工具，還可以實現(xiàn)內(nèi)容審查、敏感詞過濾等功能。有一說一，自定義工具這個很強，后續(xù)我考慮專門出一期內(nèi)容介紹這個。
5、工作流應用示例
泵作為工廠常見通用設備，其突發(fā)故障往往會導致整條生產(chǎn)線停擺，造成重大經(jīng)濟損失。下面介紹一個我近期實施過的泵類設備預測性維護智能系統(tǒng)，其中充分利用了 Dify 的各種功能模塊和工具節(jié)點，整合靜態(tài)知識庫、MCP 鏈接外部數(shù)據(jù)源、問答分類和維保報告生成功能。
5.1 系統(tǒng)架構(gòu)圖
+----------------------------------+
| 用戶界面層 |
| Web界面 | 移動App | 企業(yè)微信集成 |
+----------------------------------+
|
+----------------------------------+
| Dify核心平臺層 |
| 工作流編排 | Agent | RAG | 知識庫 |
+----------------------------------+
| |
+----------------+ +------------------+
| MCP連接層 | | 外部系統(tǒng)集成 |
| 數(shù)據(jù)收集接口 | | ERP | MES | CMMS |
+----------------+ +------------------+
|
+----------------------------------+
| 設備物聯(lián)網(wǎng)層 |
| 振動傳感器 | 溫度傳感器 | 壓力傳感器 |
+----------------------------------+5.2 工作流程設計
A. 狀態(tài)監(jiān)控工作流
該工作流通過傳感器持續(xù)監(jiān)控泵的振動、溫度、壓力等參數(shù)，使用 IF/ELSE 節(jié)點對異常狀態(tài)進行判斷，發(fā)現(xiàn)異常時觸發(fā)告警。
B. 故障預測工作流
將收集的數(shù)據(jù)與歷史故障模式進行比對，使用 LLM 和 Knowledge Retrieval 節(jié)點分析數(shù)據(jù)趨勢，預測可能的故障時間和類型。
C. 維保建議工作流
根據(jù)預測結(jié)果，生成具體的維護建議和計劃，包括所需備件、維修時長和最佳維修時間窗口，通過 Template 節(jié)點生成標準化工單。
D. 閉環(huán)反饋工作流
收集實際維修結(jié)果與預測的對比，通過 Agent 節(jié)點分析差異并不斷優(yōu)化模型，形成閉環(huán)反饋，持續(xù)提升預測準確性。
5.3 關(guān)鍵節(jié)點配置示例
設備狀態(tài)監(jiān)控節(jié)點配置：
- HTTP Request節(jié)點：
接口URL: http://iot-platform/api/pump/status
參數(shù): {"pumpId": "{{pumpId}}", "timeRange": "{{timeRange}}"}
- Code節(jié)點（數(shù)據(jù)處理）:
處理振動、溫度等數(shù)據(jù)，計算偏差值
- IF/ELSE節(jié)點：
條件: vibration > threshold || temperature > limit
是分支: 觸發(fā)告警流程
否分支: 正常記錄數(shù)據(jù)故障預測 LLM 節(jié)點提示詞：
系統(tǒng)提示: 你是一位專業(yè)的泵類設備故障預測專家。根據(jù)以下設備參數(shù)和歷史數(shù)據(jù)，分析可能存在的故障風險，預測故障類型和可能的發(fā)生時間。
用戶輸入:
設備ID: {{pumpId}}
當前振動值: {{vibration}}
當前溫度: {{temperature}}
當前壓力: {{pressure}}
歷史故障模式: {{historyFailures}}維保報告生成節(jié)點:
- Template節(jié)點:
設備巡檢報告
設備ID: {{pumpId}}
巡檢時間: {{inspectionTime}}
設備狀態(tài): {{status}}
預測壽命: {{remainingLife}}
異常項:
{% for issue in issues %}
- {{issue.name}}: {{issue.description}}
{% endfor %}
維護建議:
{{maintenanceSuggestions}}
下次計劃維護時間: {{nextMaintenanceDate}}6、寫在最后
RAG 自從 2020 年由 Meta 提出，23 年春 Nvidia GTC 大會后火熱之后，一直面臨著來自“微調(diào)”和“長上下文 LLM”的對比爭議。不過兩年下來，共識已經(jīng)基本形成：
一方面是從成本和實時性角度，RAG 具有壓倒性優(yōu)勢，而效果上相差也并不大，即使需要微調(diào)介入的場景，RAG 通常也不可或缺。另一方面，長上下文 LLM 依然面臨在上下文段落增加時準確率不斷下降的事實。所以，在任何情況下，提供高精度的搜索系統(tǒng)（RAG）都是極有價值的，RAG 當前也已經(jīng)是一種事實上的落地標準架構(gòu)。
