[AI 分享] PDF型RAG處理思路

 [AI 分享] PDF型RAG處理思路

摘要 : PDF做RAG不能只轉文字切片，重點在辨識類型、保留結構、語意切分、可追溯引用與多工具協作。

內容:

當 agent 做 RAG 時，知識庫裡是一堆 PDF 該怎麼處理，不能只回答「先轉文字、再切片、再丟向量庫」。這種答案太表面，因為真實專案裡的 PDF 往往不是乾淨的純文字，而是充滿各種複雜結構與格式問題。

實務上，PDF 可能是合約、財報、掃描件、技術文件，裡面會包含條款、表格、圖表、圖片、雙欄排版、流程圖、程式碼區塊、註腳、頁首頁尾等內容。若直接把它當成一般文本抽取，後續很容易出現切片斷裂、表格結構混亂、頁首頁尾重複召回、圖片資訊遺失等問題。最終模型雖然能回答，但常常無法正確引用原文，來源也難以對應。

這題真正考的，不是會不會把 PDF 存進向量庫，而是有沒有理解 PDF 型 RAG 的難點在於：能不能正確讀懂、正確切分、正確引用。

第一步是先判斷 PDF 類型，而不是急著抽文字。若是原生文字型 PDF，例如說明書、產品文件、論文，可以直接做文字解析；若是掃描型 PDF，例如紙本合約、發票或拍照轉成的檔案，就必須先透過 OCR 做文字辨識；若是圖文混排、表格密集或含大量流程圖與截圖的 PDF，就不能只靠文字抽取，而要搭配版面分析、視覺理解，甚至多模態模型一起處理。因為一開始類型判斷錯了，後面的切片、檢索與回答都會跟著失真。

第二步是盡量還原文件結構。PDF 處理很常見的錯誤，就是把整份文件抽成一大段純文字，這樣雖然快，但會犧牲掉很多關鍵上下文。例如合約中的章節、條款、附件編號，或財報中的表格名稱、年份、指標欄位，這些資訊如果遺失，模型即使抽到一句內容，也不知道它屬於哪一頁、哪一章、哪一個條文，自然難以驗證與追溯。

因此在生產環境中，應盡量保留頁碼、標題層級、章節關係、段落邊界、表格位置、圖片說明、註腳與頁首頁尾等結構資訊。更重要的是，每一段內容都要知道自己在原文中的位置，這樣後續才能支援引用、校驗與來源追蹤。

第三步是按語意切片，而不是機械式固定字數切分。很多人習慣每 500 字或 800 字切一段，但 PDF 的內容通常不適合這樣做。標題和正文不能隨便拆開，合約條款最好保持完整，表格也不能當一般段落切開，圖表內容更不能直接忽略。

更好的方式是根據語意與結構切分，例如同一標題下的數個段落可以組成一個 chunk，合約中的單一條款盡量完整保留，表格可以單獨轉為結構化文本，圖表則可先生成摘要，再連同頁碼與標題一起保存。每個 chunk 都應附上 metadata，例如文件 ID、頁碼、章節標題、條款編號、表格編號、圖片描述與版本時間等，讓檢索結果不只是孤立句子，而是帶著上下文與來源資訊的內容單元。

若要做得更精細，還可以為每個 chunk 補充一段上下文說明，例如註記這段內容來自某份合約的付款條款，主要說明尾款支付條件。這樣模型在檢索回來後，不只看到片段，還能更快理解它在整份文件中的語意角色。

第四步才是 agent 層的工具設計。到了 agent 使用階段，不建議把整份 PDF 一次塞進上下文，這樣既浪費 token，也容易讓模型抓不到重點。更合理的方法，是把 PDF 處理能力拆成多個工具，讓 agent 根據問題類型按需呼叫。

例如可以設計 Search PDF 來做片段檢索，Read Page 用來讀取指定頁內容，Extract Table 專門抽取表格，Chart Analysis 或視覺分析工具用來理解圖表，Citation Source 則負責返回頁碼與原文引用。這樣當使用者問簡單問題時，agent 可以先檢索相關段落；當使用者問跨年度比較、數據變化趨勢等複雜問題時，agent 就能進一步定位章節、抽取表格、做整理與歸納；如果問的是流程圖或圖片內容，就要交給視覺分析工具，而不是只靠文字搜尋。

回答這題，最後最好補充生產級細節：PDF 型 RAG 一定要做到可追溯引用，也一定要建立評測機制。回答內容最好附上頁碼、章節、原文片段，甚至表格編號，否則模型說得再自然，也很難確認它是不是憑空編造。

而評測也不能只看最後答案對不對，還要往下拆成更細的品質指標，例如檢索片段是否正確、頁碼是否準確、表格有沒有被解析錯亂、OCR 是否漏字、圖表資訊是否被正確理解、原文引用是否真的能支撐最終回答。這些細節，才是真實業務裡最容易出問題的地方。

總結來說，這題的成熟回答不是「PDF 轉文字後向量化」而已，而是先辨識 PDF 類型，再選擇合適的解析方式；接著保留文件結構，依語意進行切片；對表格、圖片與圖表做專門處理；最後讓 agent 透過工具鏈按需檢索、讀頁、抽表、看圖，並全程保留引用與評測閉環。這樣的回答，才能讓面試官知道你不是只做過簡單 demo，而是真的理解 PDF RAG 在生產環境中的核心難點。