:::

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

9月 23, 2024 , , 0 Comments Edit Copy Download

2024-0727-182223.png

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

2024-0727-150452.png

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

2024-0727-151127.png

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

2024-0727-150810.png

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


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

https://dify.ai/zh

https://dify.ai/zh 

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

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


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

https://dify.ai/pricing

https://dify.ai/pricing 

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

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

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

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

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

2024-0727-160333.png

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

2024-0727-160721.png

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

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

環境 / Environment

2024-0727-182248.png

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

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


應用程式 / Applications

2024-0727-161112.png

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

2024-0727-161822.png

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

2024-0727-162017.png

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

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


模型設定 / Configuration

2024-0727-162227.png

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

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


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

https://ai.google.dev/

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的說明,在一定用量底下可免費使用。

2024-0727-163225.png

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


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

2024-0727-164041.png

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

2024-0727-163618.png

https://huggingface.co/settings/tokens 

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

2024-0727-164815.png

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

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

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

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

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

2024-0727-170146.png

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


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

2024-0727-171256.png

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

https://www.firecrawl.dev/

https://www.firecrawl.dev/ 

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

2024-0727-171742.png

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

2024-0727-172423.png

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

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

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

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


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

2024-0727-173759.png

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

2024-0727-174432.png

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

2024-0727-174220.png

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

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

2024-0727-174931.png

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


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

2024-0727-175458.png

整體而言,使用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_Lecture_Title_Namer_-_image1.png

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


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

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

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