在前一篇文章的最後面,我們介紹了 RAG 的架構分層有分為 1. 資料處理與知識庫模組和 2. 使用者查詢與生成模組。
接下來,我們要開始進入資料處理與知識庫模組中的資料處理。
這個階段的目標是將文件轉換為可被檢索的結構化知識,並最終存入向量資料庫中。今天的重點會放在 PDF Parsing 與 Chunking 策略。
在真實場景中,企業知識大多以 PDF 文件 形式存在,例如:合約、研究報告、產品規格書、財務文件。而要讓你的RAG讀懂這些知識,我們需要先將這些檔案的內容萃取出來,為放入向量資料庫做準備,我們稱為PDF Parsing。
筆者認為裡面的關鍵技術有兩個:
為什麼沒提到圖片呢?因為筆者的經驗中,許多知識文件的圖是用來讓人更好理解文字的,但要描述的內容其實文件都會提到,因此比較少遇到真的需要對圖片做提取的狀況。
市面上有許多不同的,非常推薦ihower大大做的筆記:
Parsing PDF
筆者在這邊不對所有工具做介紹,有興趣的可以參考上面的連結,這邊只先推薦一下自己在地端運作時主要使用的PDF Parsing套件,在週末的實作中也會實際操作示範:
PyPDF
img2table
📌 建議策略:混合使用 —— 先判斷表格和圖,將文字與其分開處理。用 PyPDF 抽文字,用img2table處理表格。
在處理 PDF 或其他大型文件時,光是完成 parsing 還不夠,我們還需要將長文 切分(chunking),才能讓後續的向量化與檢索更精準。這個步驟的設計會直接影響 RAG 的檢索品質與效能,大家都非常在意,但還沒有一個通用的最佳解法。
RecursiveCharacterTextSplitter
#
、##
、###
)<div>
、<p>
沒有一種策略能通吃所有場景,通常會依 文件特性與應用需求 來調整,筆者甚至會直接用頁數來做chunking,或是直接將文字和表格分開,周末實作我們再一起看一些範例。
👉 接下來,當我們有了合適的 Chunking 結果,就能進入下一步:將文字轉換成向量(Embedding),並存入向量資料庫中。這會是下一篇的主題,再請大家一起前進囉!