*圖 1｜不同 PDF 內容需要文字擷取、OCR、圖表理解與視覺摘要*
如果所有企業文件都是乾淨的純文字 PDF，RAG 會簡單很多。但真實世界通常不是這樣。制度文件可能是掃描檔，月報的關鍵資訊可能藏在圖表裡，簡報頁面可能只有幾個文字框與一張截圖，甚至同一份 PDF 裡同時混著文字、圖片與表格。 這些內容對人類來說看一眼就懂，但對傳統文字解析器而言，可能根本不存在。 ## 掃描 PDF：看得到，不代表抽得到文字 掃描 PDF 本質上常常只是一張張圖片。你可以在螢幕上看到文字，但程式無法像一般 PDF 一樣直接抽取。這時就需要 OCR，把影像裡的文字辨識成可搜尋內容。 不過光學字元辨識（OCR）不是「有做就一定正確」。低解析度、傾斜、中文表格、特殊字型都可能造成錯字。若後續直接把錯誤文字拿去做向量化（Embedding），搜尋品質自然會跟著下降。因此 OCR 完成後仍需要抽樣檢查，而不是只確認流程有跑完。 ## 圖表與表格：只抽文字可能失去關係 一張趨勢圖的重點不是圖上有哪些數字，而是數字之間的變化；一個表格的價值也不只是每個儲存格，而是欄列的對應關係。如果把內容拆成沒有結構的純文字，模型可能看得到數字，卻不知道哪個數字屬於哪個月份或品類。 因此對表格可以考慮保留 Markdown 或結構化資料；對圖表與截圖，則可以使用多模態模型先產生視覺摘要，再把摘要連同來源頁面放進索引。 ## 不要所有文件都走同一條 ingestion pipeline 這也是企業 RAG 很重要的設計觀念。純文字文件、掃描件、表格與圖片的處理方式不同，不需要為了「架構統一」硬塞進同一套解析流程。系統可以先辨識文件型態，再決定走文字解析、OCR 或視覺理解。 Data Machi 的開源實作可以先從乾淨 PDF 做起，但知道這個邊界很重要。否則未來換成真正的企業文件時，很容易把搜尋失敗誤認為模型問題。 ## 建立知識庫前，先做資料品質檢查 一個很實用的做法，是在索引前先抽查幾頁：文字是否完整？頁碼與來源是否保留？表格有沒有被拆亂？如果文件本身沒有被正確轉換，就先不要急著調 embedding 或 top-k。 ## 進階理解｜OCR 讀到文字，不代表讀懂關係 以流程圖為例，畫面裡可能寫著「申請送出 → 主管審核 → 通過 → 財務核銷」，旁邊還有「拒絕 → 退回申請人」的分支。光學字元辨識（OCR）可以把這些文字抽出來，但箭頭方向、分支關係與版面位置可能全部消失。結果看起來像「有讀到字」，實際上卻失去最重要的流程語意。 因此可以把文件處理分成三層：有文字層的頁面直接解析；掃描頁需要 OCR；圖表、流程圖與系統截圖則可能需要多模態模型產生視覺摘要。**不是所有頁面都值得用最昂貴的處理方式。**