雜談：什麼是RAG知識庫的必備條件？ / TALK: What Are the Prerequisites for a RAG Knowledge Base?
在陸陸續續地升級了Dify的各個元件後，赫然發現，目前作為RAG的知識庫，仍有許多不足之處。到底RAG知識庫應該具備什麼功能？這篇就來聊聊我的想法。
需求1. 能夠直接使用本地端的檔案 / Able to Directly Access Local Files
由於目前大多數大型語言模型(LLM)和檢索增強生成(RAG)應用都還是面向企業或組織的商業方案，這些情境中會由許多使用者共同使用LLM和RAG，因此目前的方案大多傾向是在雲端保存知識庫。
https://aws.amazon.com/tw/bedrock/
Amazon Bedrock就是其中的代表。我們可以將資料上傳到Amazon Bedrock的雲端服務上，然後再設定LLM去介接Bedrock進而實現RAG的功能。這個做法其實是預設你的所有應用都在Amazon上，那麼它們之間彼此的串接就顯得非常自然。
不過，如果是個人使用者的話，總不能一言不合地就找個企業級的知識庫來使用吧。而且大多情況下，我們個人使用的資料其實包含了許多隱私資料。如果可以的話，真不希望這些資料被上傳到其他伺服器上，最好能保留在我自己可以控制的機器上即可。
這個目標看起來很容易實現，但實際上，目前並沒有理想的解決方案。我目前能做的也只有將Dify這種RAG應用框架架設在本機端，然後打開瀏覽器，用上傳的方式把檔案傳上去。如果要更新檔案內容的話，那就得要再進行一次上傳，然後刪除舊版本的內容。儘管Dify是架設在我自己的伺服器上，而使用的相關服務也是自行架設，從資料儲存的架構來看，它的確是保存在本地端沒錯。然而，這些操作下來，讓人感到這跟上傳檔案其實也沒有太大差別。
那麼，什麼是能夠直接使用本地端檔案的做法呢？理想上應該是類似Nextcloud或Dropbox那種桌面應用程式，能夠讓我們直接指定一個資料夾，而知識庫的內容就直接從這個資料夾中進行索引。我們可以沿用原本的工作環境，在資料夾中打開檔案、編輯檔案、儲存，而程式應該偵測資料夾裡面有所變動的檔案，再為這些變動的檔案建立索引。
https://www.youtube.com/watch?v=akZJKQXSLlA
這件事情聽起來好像...NVIDIA的ChatRTX已經做了。然而，ChatRTX只是確實實作了部分的理想，但它並非單純的知識庫，而LLM跟RAG的功能也不算完善。重點是要使用ChatRTX的門檻並不低，你必須先擁有RTX 30系或40系的顯示卡，然後作業系統也只能用Mac跟Windows。我這個Linux使用者自然就只能在外面玩沙了。
總而言之，目前RAG的知識庫最多只能做到將系統架設在本機端，然後用上傳的方式傳到系統上而已。比較可能的做法，應該還是另外開發程式來呼叫Dify的API，以此更新知識庫吧。
需求2. 能夠處理各種文件 / Able to Analyse Any Document Format
目前Dify能夠支援分析的文件格式有TXT、MARKDOWN (MD)、MDX、PDF、HTML (HTM)、XLSX、XLS、DOCX、CSV。乍看之下好像已經很多了，至少比ChatRTX只能分析TXT、PDF、DOC，但實際上這些格式遠遠不能滿足我們的需求。
上述這些檔案內容大多都是能夠從檔案裡面抽取文字來進行分析的結構化資料。然而，現在我們面臨更多的資料類型是：
- 文件檔案包含了圖片和表格，需要用不同方式來處理。
- 掃描文件的圖片檔案：需要對圖片進行OCR識別文字。
- 照片：需要對照片增加情境描述跟物體辨識。
- 會議或對話錄音：訪談需要轉換成逐字稿。
- 影片：需要將字幕轉換成可以處理的文字。
- 投影片：需要分析投影片的內容，找出合適的投影片。
特別是投影片，我的投影片大多時候都是圖片和文字混雜的呈現。用人眼閱讀整張投影片，也許你能猜得到我想講什麼。但如果直接抽取裡面的文字，那大多時候都只能看到難以看出意義的單字。
https://www.sciencedirect.com/science/article/pii/S2213846324000920
別說是圖片、聲音、影片那種複雜的多媒體格式了，光是回到PDF這種常見的文件格式，現在的RAG其實處理起來都有困難。上圖是一份論文裡面的其中一頁，論文採用的是常見的雙欄格式，而文中穿插了圖片跟表格。這份PDF檔案對大多數人來說真的是習以為常，但目前的RAG頂多能處理PDF換行的問題，還不能保證能夠正確識別雙欄。至於表格跟圖片，那就只能直接舉雙手投降。
https://github.com/infiniflow/ragflow/blob/main/deepdoc/README.md
目前這一塊做的比較好的是RAGFlow裡面使用的DeepDoc。它能夠從視覺的角度識別文件的排版，並找出文字、標題、圖表、圖表標題、表格、表格標題、頁首、頁尾、參考文獻、公式等資訊，讓分析結果能夠貼緊人們理解文件的方式，這也能夠有效改善RAG的效果。然而代價就是，DeepDoc的運作成本比直接抽取文字還要來的高。
https://ragflow.io/blog/long-context-rag-raptor
RAGFlow另一這重要的特色是實作了RAPTOR功能。原本RAG在索引的時候是將長文件分成多個小段落(chunk)來分析，RAPTOR則會給這些分段用LLM加上摘要，最將分段和摘要一同納入向量資料庫來進行分析。這個做法能夠克服原本長文件的分段破壞了整體脈絡的問題，LLM的摘要能讓在零散的分段之間建立連結。RAPTOR在查詢較為整體、抽象的問題時，可能可以找出零散分段看不出的脈絡資訊。但RAPTOR也會造成知識庫容易充斥重複且抽象的資訊，有時候反而會讓人無法精確地找到想要的內容。
https://github.com/microsoft/markitdown
如果重點是在處理各種類型檔案的話，那麼微軟推出的MarkItDown可能會是簡單且有效的工具。它的特色在於處理PDF、PowerPoint、Word、Excel、圖片(使用EXIF後設資料跟OCR)、聲音(使用EXIF資料跟語音轉錄)、HTML、其他文字格式(CSV、JSON、XML)、ZIP檔案內的上述格式。其中最值得注意的是MarkItDown不僅能夠對圖片進行OCR、對聲音檔轉錄，在連接了LLM之後，我們還能用LLM來描述圖片的內容。聽起來很不錯，不過目前微軟推出的產品大多都得要連上他們家的服務才能運作。有些開發者會修改程式碼讓它能用本地端的服務，不過那就還需要更多設定才行，不是一般人能夠做到的程度。
總而言之，目前RAG知識庫在處理各種文件的能力上，其實還是十分薄弱。許多人都以為RAG應用能夠處理PDF就已經完美。殊不知真的要使用的時候，才發現原本完整的文字被斷在奇怪的地方，而導致想要的資訊一直沒辦法透過RAG取得，反而還因為錯誤的索引方式，把一堆無用的資訊塞給LLM去解讀。
需求3. 知識庫能夠配合RAG應用使用 / Knowledge Bases Can Be Used with RAG Applications
https://www.baihezi.com/post/222787.html
現今大部分RAG應用的做法都是將知識庫跟RAG應用的開發綁在一起使用。也許這種開箱即可用的方案的確是能讓很多人的方便入門，但這也代表了我們很難找到各方面都做得很好的六邊形解決方案。舉例來說，前面有提到RAGFlow在處理文件應用了DeepDoc，能夠更仔細地分析PDF等文件的內容。這是一件好事，但RAGFlow的LLM客製化功能，例如像是Workflow的Agent，設計上就沒有Dify來的容易使用。
https://z0yrmerhgi8.feishu.cn/wiki/DrUqwbIXmicVI4kzYzJcQesGnee
好消息是Dify後續版本加入了External Knowledge API的功能，這使得我們不僅能將Amazon Bedrock作為知識庫，也能連線到RAGFlow進行查詢。摘要我們取得RAGFlow的API Key，然後用RAGFlow的API網址「http://127.0.0.1:9380/api/v1/dify」就能連線。詳細操作可以參考「1 - Dify通过API调用RAGFlow外部知识库」的介紹。
我雖然成功讓Dify查詢到RAGFlow的內容，但最終結果我並不滿意。RAGFlow在大多時候會將中文轉換成簡體中文，而且除了DeepDoc能夠分析排版複雜的文件之外，上述提到的存取本地檔案、分析圖片和聲音等功能仍然無法很好的實作。而RAGFlow同樣也必須將檔案上傳到系統才能運作，並不能直接存取本機檔案。
另一方面，雖然ChatRTX能夠取用本地檔案了製作索引，但它本身的RAG功能非常薄弱，也無法直接讓它跟Dify介接。十分可惜。
看到這裡，其實我們應該要認識到RAG議題應該邁入到各司其職、專業分工的方向了。現在捆在一起實作各種功能的RAG應用已經夠多了，我們接下來要的是能夠讓各家功能整合在一起、互通有無的框架啊。
結語 / Conclusion
在不知不覺間，人們的流行用語從AI、LLM，轉入到了RAG。很多人都寄望RAG能夠處理他們的海量資料，但事實上，大多數人放到RAG知識庫的內容，都沒能順利交給LLM解讀。
我看到很多人都在跟我炫耀RAG多麼的棒，但如果認真去檢視，你會發現其實你認為應該要從知識庫取得的資料根本沒有交給LLM，一切都是LLM靠自己的知識(或是內建的搜尋引擎)來回答。由於許多人都自動帶著濾鏡看待AI跟LLM，對於RAG，看來大家也都是用同樣的看法。因此在這些模糊的濾鏡下，RAG依然被捧上天，成為號稱「能讓圖書館員失業」的殺手級應用。
但結果呢？你真的把自己的資料放入那些你熟悉的RAG，其實很快就會感受到我這篇所抱怨的各種困難。要嘛是上傳過程很繁瑣，上傳檔案完還要等待製作嵌入向量才能算是索引完成；要嘛是表格根本就無法解讀，LLM看一堆數字也不知道是啥意思；要嘛是RAG功能只提供「問問題」，其他輔助功能都沒有，你必須自己做好「Prompting Engneering」。
到就目前為止，我仍然沒能找到理想的RAG方案。雖然是這樣說，但並不代表我否定RAG的方向。現在我已經將整合到日常工作裡，也包括這篇BLOG的撰寫。儘管我一邊用一邊抱怨著上述問題，但不可否認的是RAG的確是資訊檢索的新世代發展方向。
那麼我們就繼續期待未來能變得更好吧。加油。
