自行架設大型語言模式應用程式：Dify / Self-Hosting a Large Language Model Application: Dify

9月 23, 2024 AI , Dify , LLM 6 Comments Edit Copy Download

Coze開始收費之後，Dify會是更好的替代方案嗎？事情原來沒有我自己想象中的這麼簡單！

When Coze began to charge fees, what is the next solution for Large Language Model (LLM) application? Will Dify be a better alternative? The actual situation is not as simple as I had imagined!

Coze的轉變 / The Transformation of Coze

過去一段時間我大量使用Coze製作各種客製化的AI助手。有的助手可以發出聲音與人對話，有的助手可以用來擬定投影片大綱，甚至有的助手是用來協助改考卷。

雖然很多人可能比較在意AI助手可以講話的這點 (當時是用Coze串接Cici)，但其實使用Coze最大的價值是在於它內建了RAG知識庫的功能。這能夠讓我們指定要給學習的大型語言模型的專業知識，而不會讓大型語言模型憑自己內建的世界知識隨意亂答。

然而，在7月初Coze開始收費之後，原本的AI助手們也跟著停擺了。當時我在「使用Coze建置聊天機器人的經驗」的最後講到了Dify，那實際上Dify用起來會是如何呢？

Dify：開發 LLM 應用程式的平台 / Dify: A Platform for Developing LLM Applications

https://dify.ai/zh 

Dify 是一個開放原始碼的 LLM (大型語言模型) 應用程式開發平台，它提供直覺的介面，整合了 AI 工作流程、RAG (檢索增強生成) 流程、代理功能、模型管理以及可觀察性等功能。使用者可以利用 Dify 更有效率地構建、部署和監控基於 LLM 的應用程式，例如聊天機器人或 AI 助手。

Dify 提供基於網頁的資訊視覺化介面，讓使用者可以輕鬆地設計 AI 應用程式的對話流程，並透過拖拉元件的方式設定模型、資料庫以及其他功能模組。此外，Dify 還支援將開發好的應用程式部署到不同的平台，並提供監控工具以追蹤應用程式的效能。

從雲端到落地 / From the Cloud to the Ground

https://dify.ai/pricing 

一開始看到Dify的時候，大多時候會讓人以為它跟Coze一樣，是以提供雲端服務為主。Dify本身也的確有提供雲端伺服器的服務，在此稱為雲端版Dify。雲端版Dify的免費版本最多只能建置10個應用程式，也就是不同設定的AI機器人。好處是它提供了對外網址，建置完成的應用可以直接傳送給其他人使用。

https://github.com/langgenius/dify/blob/main/README.md 

然而雲端版Dify的免費版本的10個應用程式限制，實際使用時真的是太過綁手綁腳。我在雲端上建置了幾個應用程式之後，便毅然決然地決定鑽研Dify的開放原始碼程式，改在自己電腦上架設Dify，並成為了我現在使用的本機版Dify。

讓我轉向自行架設Dify的主要原因，是因為雲端版Dify跟本機版Dify其實差異並沒有大家想象中的大。或著是說，雲端版Dify其實提供的功能非常地少，跟Coze那種已經將大部分整合完成的平臺有著極大的差異。

乍看之下，不論是雲端版Dify還是本機版Dify，它們都有大量的工具可供使用。然而事實上這些工具都只是對應供應商的接口，我們還需要進一步到各個供應商去註冊、申請API金鑰、回到Dify設定，這樣才能開始使用工具。而每個供應商提供服務的額度又有各自的政策。有些是必定要收費，有些是每個月有一定額度的使用量。我們得要自行衡量才行。

大型語言模型的使用也是一樣的道理。跟Coze那種已經將各個模型的API串接好、統一收費的方式不同，Dify就真的只是個「平臺」。每個模型都需要自行設定才能使用。

上述這些細節不僅是本機版Dify需要設定，雲端版Dify也要進行同樣的設定。既然如此，那在本機架設Dify好像就是理所當然的合理選擇了。

環境 / Environment

附帶一提，我用來架設Dify的電腦只是一臺筆電。作業系統是Kubuntu 22.04。CPU是Intel Core i71185G7，記憶體16GB。最重要的是，沒錯，顯示卡只有Intel內建的Intel Xe，沒有NVIDIA顯示卡。

Dify其實只是一個平臺，它的主要工作是串接各種不同的API，而大多數API都是在雲端上透過網際網路存取。因此就算不在我的筆電上運作大型語言模型，我們還是可以把Dify架設起來。

應用程式 / Applications

目前為止我使用Dify 0.6.14在本機架設了12個應用程式。有些應用程式是以聊天機器人的形式構成，可以用來跟AI作細部的調整。有些應用程式是以工作流(workflow)的形式設定，除了主要用來完成目的明確的任務之外，也可以跟其他應用程式整合在一起。

在Dify建立的應用程式可以用多種形式來提供服務。最基本的就是單純的網頁。如上圖所示，Trans to English背後使用了Gemini 1.5 Pro大型語言模型來回答，使得它跟Google翻譯不大相同。除了網頁顯示之外，Dify也提供了整合到網頁裡面的iframe、浮動的聊天框、Google Chrome外掛的功能，還有用RESTful API呼叫的方式。光是有API呼叫，那就可以跟各種其他系統結合，發展出無限可能了。

值得注意的是，我在Dify建置的應用程式背後大多整合了RAG的檢索生成增強機制，這使得最終輸出的結果會參考我之前的特定用詞或寫法來調整，讓成果更像是「我個人寫出來的用詞」。對我來說，這是個人AI助理最重要的核心功能。這也是一般大家在網頁或APP使用ChatGPT、Gemini所無法達到的效果。

關於RAG的介紹，可以看看我另外一篇的內容「資訊檢索的AI革新：從資訊檢索到檢索增強生成」。

模型設定 / Configuration

上述的應用程式看起來似乎很簡單，不過背後有許多細節需要設定。Dify的確提供了很多不錯的工具，讓我們能夠用Low Code的形態開發應用程式。但就如前面所說的，大部分功能都必須要先設定好對應的API才能使用。

到目前為止，我主要使用了大型語言模型、文字嵌入、網路爬蟲、Google搜尋引擎的這幾種工具的API。這些API目前都有免費版本可供使用。以下就讓我們一個一個來看看這些API的使用狀況。

大型語言模型：Gemini / Large Language Model: Gemini

https://ai.google.dev/ 

第一個是最重要的大型語言模型API。這邊我選擇的是Google的Gemini API。在目前Dify的設定中，Gemini API主要支援了無數字的1.0版本跟1.5版本，而每個版本又可細分為Flash跟Pro兩種版本。Flash模型速度較快，而Pro模型推論能力比較強。我個人大多使用的是Gemini 1.5 Pro版本。根據Geimini API Pricing的說明，在一定用量底下可免費使用。

為了避免太過頻繁取用API而超出免費額度的限制，我在Dify設定應用程式時刻意加入了延遲功能，讓回應速度稍微慢一點，以此使得應用程式能在符合Gemini API免費額度底下的使用條件。

文字嵌入：Hugging Face / Text Embedding: Hugging Face

Dify的RAG提供了「語意向量」(High Quality)跟「字詞」(Econimical)的兩種方式運作。後者「字詞」的運作方式較接近資訊檢索中的全文檢索功能，但它缺乏完善的資料前處理，使得「字詞」功能在處理中文時表現並不理想。因此在Dify使用RAG時，比較建議使用的是它推薦的語意向量功能。

https://huggingface.co/settings/tokens 

語意向量功能需要搭配對應的模型，這些模型會標示著「Text Embedding」(文字向量)。在對應文字向量的模型中，我選擇的是有提供免費額度，也是人工智慧研究最重要的平臺之一：Hugging Face。

Hugging Face有著各種不同功能與目的的模型，但Dify裡目前設定好的功能中，主要是提供LLM (大型語言模型)和TEXT EMBEDDING(文字向量)模型的串聯。前者我已經有Google Gemini可供使用了，現在主要是要設定後者Text Embedding的部分。

https://huggingface.co/intfloat/multilingual-e5-large 

這裡我選擇的是Wang等人在2024年發佈的Multilingual E5 Text Embeddings。在Hugging Face的模型名稱為「intfloat/multilingual-e5-large」。選擇此模型的理由是因為它具備了能夠處理100種不同語言的能力。如果要在Dify的應用程式中使用不同語言的話，具備多語言能力的模型會是一個基本的選擇準則。

https://huggingface.co/docs/api-inference/faq 

Hugging Face的API本身可以免費使用，但也有呼叫頻率限制(rate limit)，不過網路上找不到明確的限制規則。我想這可能是Hugging Face想要隨著使用量動態調整吧。除了Hugging Face API自身的限制之外，使用的模型本身也有自己的侷限。在「intfloat/multilingual-e5-large」的說明有提到，它能夠處理的文本長度最多僅為512個token，超過此限制的文本將不會被納入處理。

這兩個限制的結果，就表示我們在Dify裡面建置Knowledge (知識庫)的時候，不能一口氣輸入過多、過長的資料。目前我的規劃是將長文本以100個片段切割成多個文本，每個文本逐一建立索引。這樣操作雖然繁瑣，但可以在符合Hugging Face API的限制底下建置索引。在索引不需要頻繁更新的情況下，這是一個可行的方案。

用網路爬蟲作為知識庫文本：Firecrawl / Using Web Crawler As Knowldge Data Source: Firecrawl 

Dify設定知識庫內容的方法大致上有手動建立、Notion整合跟網站抓取。雲端版Dify的Notion整合已經設定完成，大致上還算可以用。不過本機版Dify則需要另外設定Notion整合，我就沒有進一步研究。目前看來比較合理的做法應該是第三個：網站抓取。

https://www.firecrawl.dev/ 

Dify的網站抓取功能也是使用外部供應商的API，目前選擇的供應商是Firecrawl。Firecrawl雖然是個網路爬蟲，但它的重點是在於將爬蟲的結果整理成結構化的格式，方便提供各種大型語言模型作後續的使用。簡單來說，Firecrawl抓的資料是給機器人看的，不是給人閱讀的。

申請Firecrawl的API並不麻煩，拿到API金鑰之後，我們就可以在Dify裡面設定好Firecrawl。從收費說明裡面可以看到，Firecrawl的雲端版本firecrawl.dev提供了每個月500次抓取的額度，API的呼叫頻率限制也不允許你太過頻繁地抓取。

在Dify設定Firecrawl的時候，你可以注意到除了API Key之外，我們還要設定Base URL。預設的情況下是設定「https://api.firecrawl.dev」即可，不過這也意味著我們可以不要使用firecrawl.dev，而選擇其他的Firecrawl版本。

https://www.youtube.com/watch?v=UAfPpnOHmbY 

01Coder介紹了它如何使用Docker來架設Firecrawl的服務。未來有機會的話，我也打算嘗試把Firecrawl架設在本機端，這樣就能跟本機版Dify一起運作了。

Google搜尋引擎：SerpAPI / Google Search Enging: SerpAPI

在Coze裡建置應用程式的時候，如果要請大型語言模型取得網路搜尋結果來產生解釋，我們只需要在Plugins加上Google Web Search即可。但到了Dify裡，要把Google搜尋引擎的結果交給大型語言模型，那就只能在Workflow (工作流)裡面設定，而且還需要經過一定程度的資料前處理才行。

不過在進行上述配置之前，我們還需要設定好API，才能順利Google搜尋引擎的查詢結果。就如同前面所述，Dify並沒有內建網路爬蟲功能，當然更不可能內建爬取Google搜尋引擎結果的功能。而且自行架設的搜尋引擎搜尋結果爬蟲其實很容易被Google的防止機器人工具擋下，實際上並沒有那麼容易實作。

https://serpapi.com/manage-api-key 

Dify的Google搜尋引擎功能使用的是SerpApi。這是一個能跟Google搜尋引擎串接好的API功能。SerpApi的申請很簡單，取得金鑰之後只要儲存在Dify的Google工具裡面即可。SerpApi的免費版本提供了每個月100次的搜尋，對我來說已經足夠使用。

除了Google搜尋引擎之外，Dify也有內建注重隱私、強調無痕的DuckDuckGo搜尋功能，看起來也沒有收費上的限制。至於實際上跟Google的結果有什麼區別嘛，未來有機會用用看再說吧。

結語：建設個人使用的AI助手 / Conclusion: Building a Personal AI Assistant 

整體而言，使用Dify建置AI助手的過程比Coze還要複雜許多。除了上述API需要額外設定之外，使用建置好的應用程式時也常常遭遇各種問題：

• 提示詞太短的時候，Gemini 1.5 Pro的推理會明顯受到Dify預設提示詞跟RAG的影響，常常就直接給我回答「I don't know.」。
• 呼叫模型的速度非常緩慢。由於大部分應用程式都結合了RAG，而RAG會呼叫Hugging Face API。但第一次呼叫Hugging Face API的時候需要非常久的時間，這可能要有心裡準備。第二次之後就快多了。
• RAG搜尋結果最多也只有Top 10。這是Dify框架的限制，也是避免資料量過多導致大型語言模型無法處理的規範。但這意味著有些時候你以為透過RAG可以讓AI根據你的知識庫進行調整，但實際上RAG根本就沒有找到你預想中的那份資料的問題。使用RAG的時候還是要謹慎檢查才行。
• 本篇介紹的方案基本上都是免費，但也伴隨著各種限制。如果想要讓其他人一起使用的話，建議進一步研究付費模型的選擇。

儘管如此，本機版Dify已經可以省下很多我原本手動處理的工作了。整體來看還是一個很不錯的個人AI助手方案啊。

不過要我吹毛求疵的話，那大概是就是Dify的網頁客製化功能太少了。為什麼不能將希希助教圖片作為頭像呢？

那麼這篇關於自行架設本機版Dify的介紹就到此為止了。文章最後要來問大家的是，你是怎麽使用大型語言模型(現在很多人都直接稱之為AI)，例如ChatGPT、Gemini、Claude呢？

• 1. 我把AI當作查詢工具，問它一些我不知道的事情。
• 2. 我把AI當作寫作助手。有時候請它幫我摘要文件，有時候請它幫我寫程式。
• 3. 我把AI當作導師，請它指點我寫作或講話上的問題，或著是人生道路上的煩惱。
• 4. AI會毀滅人類，我們應該避而遠之。

如果你有任何想法，歡迎在下面留言分享喔！