[Dify] 導入的血淚後續
Dify 雖然介面漂亮、整合了 RAG(知識庫),但在深度自動化和本地部署的玩家眼中,它有幾個讓人崩潰的「坑」: 1. 記憶體食蟻獸 (Memory Hog) 這是自架玩家最大的血淚。Dify 不是一個單一程式,它是 一群 服務的集合: 前端 (Web) + 後端 (Api) + Worker (非同步處理) + Redis (快取) + PostgreSQL (資料庫) + Vector DB (向量庫) + Sandboxed Code Executor 。 血淚點 :如果你要在 Pi4 上跑 Dify,基本是「自殺行為」。即便有 8GB RAM,光啟動這堆 Docker 容器就會卡死,更別提執行時的 Swap 噴發。相較之下,n8n 一個容器就能跑完九成功能。 2. 「假」工作流的挫折感 Dify 的 Workflow 雖然看起來像 n8n,但邏輯封閉很多: 資料傳遞 :在 n8n 你可以隨意用 JavaScript 揉捏 JSON;在 Dify,變數型態檢查極其嚴格,常常為了傳一個字串弄到整條 Flow 報錯。 循環與邏輯 :Dify 早期版本幾乎沒辦法做複雜的 Loop(循環),如果你要批次處理 50 筆 539 的歷史數據,Dify 會讓你寫到想哭,而 n8n 的 Split In Batches 才是真正的自動化工具。 3. RAG 的「黑盒子」陷阱 Dify 強調「上傳文件就能對話」,這很吸引人,但: 血淚點 :當 AI 回答錯誤時,你很難調試它是「檢索不到」、「切片太碎」還是「Prompt 太爛」。 成本 :Dify 的自動切片(Chunking)會消耗大量 Embedding Token,如果你頻繁更換文件測試,帳單會讓你心痛。 4. 版本更新的「驚喜」 Dify 更新極快,這本來是好事,但: 血淚點 :經常發生更新後 Docker Compose 啟動失敗,或是舊的 Workflow 節點突然不相容。對於追求「設定完就讓它自動跑 24 小時」的開發者(像你打算在 Pi4 上做的那樣)來說,Dify 的維護成本遠高於 n8n。