雜談:到底要怎麼使用RAGFlow呢? / TALK: RAGFlow Drained All My Resources
由於這次RAGFlow看起來又無法順利完成任務了,我還是來記錄一下目前的狀況吧。
- 專注做好RAG的RAGFlow / RAGFlow: Focusing on RAG
- 硬體要求 / Hardware Requirements
- 大量請求的難題 / The Challenge of Numerous Requests
- 本地Ollama連接不順 / Local Ollama Connection Issues
- 聊天中的檢索 / Retrieval in Chat
- 小結 / In Closing
專注做好RAG的RAGFlow / RAGFlow: Focusing on RAG
在眾多LLM DevOps的方案中,RAGFlow也絕對可以算得上是重量級的那邊。相較於其他方案,RAGFlow一直積極加入各種能夠改進RAG的特殊技術,使得它在RAG的應用方面出類拔萃。
RAGFlow的主要特色包括了:
- 文件複雜排版分析功能:能夠解讀表格,甚至能分析PDF裡面圖片的文字。
- 分層摘要RAPTOR。能改善RAG用分段(chunking)切斷資訊的問題。
- 結合知識圖譜的GraphRAG跟LightRAG。讓回答著重與命名實體,而且還可能找到詞彙之間的隱含關係。
- 能作為Dify外部知識庫使用。
不過,除了第四點之外,要做到前三項功能,目前看起來還有很多問題需要克服。
硬體要求 / Hardware Requirements
由於運作RAGFlow會使用OCR來分析文件的排版,記憶體最好是給到16GB之多,硬碟空間也需要準備50GB。這真的是重量級的方案。
如果這些準備好的話,要做到分析複雜排版文件的這件事情就不是很難了。
只要做到這個程度,RAGFlow就能在回答引用時顯示來源的文件位置。這樣幫助就很大了呢。
大量請求的難題 / The Challenge of Numerous Requests
相較於排版分析是RAGFlow組件中的功能,RAPTOR跟Knowledge Graph都要搭配大型語言模型才能解析跟查詢資料。而RAGFlow在處理資料的時候會在短時間內發送大量的API請求,很容易就被rate limit限流。
既然直接連接LLM API會因為太多請求而被限流,我就試著改轉接到Dify上,並在API請求的時候加上排隊等候的機制。Dify裡面雖然可以寫程式碼,但他其實也是在沙盒裡面運作的程式,還是有著不少的限制。其中一個限制就是不能讓我直接修改系統上的檔案。因此如果要在Dify內用程式讀寫資料,用HTTP請求傳送可能是比較好的做法。
這些做法花了很多時間調整。
調整了老半天,總算能夠讓它正常運作。
不過過了一陣子,LLM API連回應沒有反應了。我猜想可能是連接的Gemini API已經超過用量而被禁止吧。
RAGFlow還是會繼續作Knowledge Graph Extraction。但裡面的資料應該都已經是空白不能使用了。
此時Knowledge graph按鈕已經顯示出來了,不過點進去後會出現大量錯誤,這是因為大部分的資料都是空值的緣故。基本上可以當作已經無法使用了。
本地Ollama連接不順 / Local Ollama Connection Issues
如果Gemini不能跑的話,那我用Ollama架設Gemma2:9b來跑跑看呢?簡單的測試看起來是能夠運作,不過實際上給RAGFlow處理資料的話,其實是完全不能用的。
只要遇到query長度過大的情況,Ollama會直接當掉。
https://github.com/ollama/ollama/blob/main/docs/faq.md
這個原因似乎是因為Ollama預設可接受的token長度是2048,但RAGFlow傳送的資料長度大多時候都超過了這個字數限制,我也無法設定RAGFlow來改善。
於是接下來的問題就是要怎樣修正Ollama,或是減緩Ollama的請求頻率,看看能不能讓RAGFlow混慢地請Ollama處理知識圖譜吧。
聊天中的檢索 / Retrieval in Chat
目前我使用RAGFlow成功製作知識圖譜的文件,只有一份一頁A4都不到的BLOG草稿。RAGFlow雖然有知識圖譜的顯示功能,但顯示功能本身意義不大,也無法做到瀏覽文件的功能,RAGFlow主要是拿它改善RAG的機制。
而且仔細看的話,你還可以注意到有些「命名實體」看起來好像不太正確。但在社群演算法的分析之下,它們也會自然地被孤立在社群之外,不容易影響搜尋結果。
即使知識圖譜能夠順利產生,在檢索的時候也無法順利用它來找尋資料。如果把「Multi-turn optimization」關掉則可以改善這個問題,讓結果順利產生。
從對話記錄裡面可以看到,RAGFlow一樣是作RAG,但檢索結果是來自知識圖譜的搜尋內容,包括了命名實體(Entities)、關係(Relations)、社群報告(Community Report),以及基本的文件片段(chunk)。
社群報告是由多個命名實體組成的摘要。相較於RAPTOR用前後片段來構成摘要,這裡可以看到知識圖譜著重的是用命名實體之間的關係來構成摘要。
相較於片段本身,知識圖譜的檢索內容還要多上很多。這也難怪RAGFlow在宣傳自家的知識圖譜時會用回應時資訊的長度大增來作為賣點。
小結 / In Closing
就目前的狀況來說,知識圖譜應用在RAG時,的確能夠讓LLM獲得更多線索來產生回應。然而,知識圖譜的建立需要頻繁請求LLM,也需要傳送大量資料給LLM處理,這些都會造成LLM負荷量過大而崩潰。
另一方面,LLM所建立的知識圖譜,在精確程度上也有待驗證。命名實體跟關係的抽取,其背後應該是要有很多對應的專有名詞跟領域知識,光靠LLM能做到什麼程度,其實我內心一直難以信服。
儘管如此,如果能夠順利駕馭RAGFlow,我想應該確實可以讓RAG的結果表現更好吧。繼續努力。