雜談：到底要怎麼使用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的結果表現更好吧。繼續努力。
