:::

雜談:到底要怎麼使用RAGFlow呢? / TALK: RAGFlow Drained All My Resources

3月 14, 2025 , , , 0 Comments Edit Copy Download

2025-0216-081952.png

由於這次RAGFlow看起來又無法順利完成任務了,我還是來記錄一下目前的狀況吧。


專注做好RAG的RAGFlow / RAGFlow: Focusing on RAG

https://ragflow.io/

https://ragflow.io/ 

在眾多LLM DevOps的方案中,RAGFlow也絕對可以算得上是重量級的那邊。相較於其他方案,RAGFlow一直積極加入各種能夠改進RAG的特殊技術,使得它在RAG的應用方面出類拔萃。

RAGFlow的主要特色包括了:

  1. 文件複雜排版分析功能:能夠解讀表格,甚至能分析PDF裡面圖片的文字。
  2. 分層摘要RAPTOR。能改善RAG用分段(chunking)切斷資訊的問題。
  3. 結合知識圖譜的GraphRAG跟LightRAG。讓回答著重與命名實體,而且還可能找到詞彙之間的隱含關係。
  4. 能作為Dify外部知識庫使用

不過,除了第四點之外,要做到前三項功能,目前看起來還有很多問題需要克服。

硬體要求 / Hardware Requirements

2025-0215-225550.png

由於運作RAGFlow會使用OCR來分析文件的排版,記憶體最好是給到16GB之多,硬碟空間也需要準備50GB。這真的是重量級的方案。

如果這些準備好的話,要做到分析複雜排版文件的這件事情就不是很難了。

2025-0215-230012.png

只要做到這個程度,RAGFlow就能在回答引用時顯示來源的文件位置。這樣幫助就很大了呢。

大量請求的難題 / The Challenge of Numerous Requests

2025-0215-230206.png

相較於排版分析是RAGFlow組件中的功能,RAPTOR跟Knowledge Graph都要搭配大型語言模型才能解析跟查詢資料。而RAGFlow在處理資料的時候會在短時間內發送大量的API請求,很容易就被rate limit限流。

2025-0215-230636.png

既然直接連接LLM API會因為太多請求而被限流,我就試著改轉接到Dify上,並在API請求的時候加上排隊等候的機制。Dify裡面雖然可以寫程式碼,但他其實也是在沙盒裡面運作的程式,還是有著不少的限制。其中一個限制就是不能讓我直接修改系統上的檔案。因此如果要在Dify內用程式讀寫資料,用HTTP請求傳送可能是比較好的做法。

2025-0215-230446.png

這些做法花了很多時間調整。

2025-0215-230954.png

調整了老半天,總算能夠讓它正常運作。

2025-0215-231016.png

不過過了一陣子,LLM API連回應沒有反應了。我猜想可能是連接的Gemini API已經超過用量而被禁止吧。

2025-0216-070609.png

RAGFlow還是會繼續作Knowledge Graph Extraction。但裡面的資料應該都已經是空白不能使用了。

2025-0216-071333.png

此時Knowledge graph按鈕已經顯示出來了,不過點進去後會出現大量錯誤,這是因為大部分的資料都是空值的緣故。基本上可以當作已經無法使用了。


本地Ollama連接不順 / Local Ollama Connection Issues

2025-0216-070318.png

如果Gemini不能跑的話,那我用Ollama架設Gemma2:9b來跑跑看呢?簡單的測試看起來是能夠運作,不過實際上給RAGFlow處理資料的話,其實是完全不能用的。

2025-0216-070723.png

只要遇到query長度過大的情況,Ollama會直接當掉。

2025-0216-071018.png

https://github.com/ollama/ollama/blob/main/docs/faq.md

這個原因似乎是因為Ollama預設可接受的token長度是2048,但RAGFlow傳送的資料長度大多時候都超過了這個字數限制,我也無法設定RAGFlow來改善。

於是接下來的問題就是要怎樣修正Ollama,或是減緩Ollama的請求頻率,看看能不能讓RAGFlow混慢地請Ollama處理知識圖譜吧。


聊天中的檢索 / Retrieval in Chat 

2025-0216-071500.png

目前我使用RAGFlow成功製作知識圖譜的文件,只有一份一頁A4都不到的BLOG草稿。RAGFlow雖然有知識圖譜的顯示功能,但顯示功能本身意義不大,也無法做到瀏覽文件的功能,RAGFlow主要是拿它改善RAG的機制。

2025-0216-075621.png

而且仔細看的話,你還可以注意到有些「命名實體」看起來好像不太正確。但在社群演算法的分析之下,它們也會自然地被孤立在社群之外,不容易影響搜尋結果。

2025-0216-074348.png

即使知識圖譜能夠順利產生,在檢索的時候也無法順利用它來找尋資料。如果把「Multi-turn optimization」關掉則可以改善這個問題,讓結果順利產生。

2025-0216-074519.png

從對話記錄裡面可以看到,RAGFlow一樣是作RAG,但檢索結果是來自知識圖譜的搜尋內容,包括了命名實體(Entities)、關係(Relations)、社群報告(Community Report),以及基本的文件片段(chunk)。

2025-0216-074753.png

社群報告是由多個命名實體組成的摘要。相較於RAPTOR用前後片段來構成摘要,這裡可以看到知識圖譜著重的是用命名實體之間的關係來構成摘要。

2025-0216-075015.png

相較於片段本身,知識圖譜的檢索內容還要多上很多。這也難怪RAGFlow在宣傳自家的知識圖譜時會用回應時資訊的長度大增來作為賣點。


小結 / In Closing

就目前的狀況來說,知識圖譜應用在RAG時,的確能夠讓LLM獲得更多線索來產生回應。然而,知識圖譜的建立需要頻繁請求LLM,也需要傳送大量資料給LLM處理,這些都會造成LLM負荷量過大而崩潰。

另一方面,LLM所建立的知識圖譜,在精確程度上也有待驗證。命名實體跟關係的抽取,其背後應該是要有很多對應的專有名詞跟領域知識,光靠LLM能做到什麼程度,其實我內心一直難以信服。

儘管如此,如果能夠順利駕馭RAGFlow,我想應該確實可以讓RAG的結果表現更好吧。繼續努力。