Dify,LLM,RAG,Talk

雜談：是時候該來處理一下Dify的問題了 : TALK: It's Time to Address the Issues with Dify

看看網頁版全文 ⇨ 雜談：是時候該來處理一下Dify的問題了 : TALK: It's Time to Address the Issues with Dify

https://blog.pulipuli.info/2024/12/talkits-time-to-address-the-issues-with-dify.html

在「自行架設大型語言模式應用程式：Dify」這篇裡面，我用Dify在筆電架設了可客製化、具備RAG的大型語言模型應用程式。

但這段期間用下來還是遭遇了很多問題。

以下就稍微列舉一下我遭遇的狀況。

----

# 呼叫外部API的限制 / Limitions of external API calls。

https://huggingface.co/docs/api-inference/rate-limits。

我在使用的Dify並沒有內建各種資料處理的核心功能，大多重要功能都要呼叫外部API，例如文字嵌入處理使用了Hugging Face、大型語言模型推理就用到Gemini、網頁爬蟲使用了Firecrawl、搜尋引擎則是使用SerpAPI。

每種API都有一定程度的免費額度，同時也有禁止短時間內大量取用的限流設定。

其中讓我感到最困擾的是在Hugging Face使用文字嵌入處理的這個環節。

由於Dify的RAG設定採用了向量(vector)形式來搜尋，從一開始建立知識庫(knowledge base)，到後面查詢這些知識庫的操作，全部都會用到文字嵌入的API。

這就讓Hugging Face API的限流成為了使用上最主要的瓶頸。

另一方面，Hugging Face API在第一次呼叫的時候，伺服器端的模型需要花一段時間才能載入，大概要等快一分鐘才能處理完成。

加上限流的限制，這讓我沒辦法真正地處理大量文件資料。

https://serpapi.com/plan。

說到免費流量的另一個限制，那就是搜尋引擎SerpApi僅提供了每個月100次的搜尋結果。

100次乍看之下似乎綽綽有餘，但這是在你很明確知道自己想要搜尋什麼的時候很有用。

但如果想要作一些探索、嘗試各種關鍵字的搜尋，那100次的數量很快就會用盡。

這也是讓我不敢在Dify用SerpApi作大量搜尋的原因。

# 檔案處理的困擾 / Unable to Process Files Quickly。

在Dify 0.6.14版本裡面，如果要分析文件檔案裡面的內容，做法是在知識庫裡匯入檔案，然後再進行切分(chunk)、建立索引等步驟。

但如果每次都要額外建立知識庫的話，看起來並不是合理的做法。

https://docs.dify.ai/guides/workflow/node/doc-extractor。

----

繼續閱讀 ⇨ 雜談：是時候該來處理一下Dify的問題了 : TALK: It's Time to Address the Issues with Dify

https://blog.pulipuli.info/2024/12/talkits-time-to-address-the-issues-with-dify.html