如果所有企業文件都是乾淨的純文字 PDF，RAG 會簡單很多。但真實世界通常不是這樣。制度文件可能是掃描檔，月報的關鍵資訊可能藏在圖表裡，簡報頁面可能只有幾個文字框與一張截圖，甚至同一份 PDF 裡，同時混著文字、圖片與表格。

這些內容對人類來說可能看一眼就懂，但對傳統文字解析器而言，其中一部分資訊可能根本不存在。這也是企業真正導入 RAG 時，很容易遇到的一個落差：文件明明就在那裡，不代表 AI 真的讀得到裡面的內容。

掃描 PDF：看得到，不代表抽得到文字

一般 PDF 通常包含可以直接擷取的文字層，因此程式可以把其中的文字讀出來。但掃描 PDF 本質上可能只是一張張圖片。你在螢幕上雖然可以看到文字，程式卻無法像處理一般 PDF 一樣直接取得內容。

這時候就需要使用 OCR（Optical Character Recognition，光學字元辨識），把圖片裡的文字辨識成可以搜尋與處理的內容。原本只有一張掃描影像的頁面，經過 OCR 後，才有機會轉換成後續 Chunking、Embedding 與 Retrieval 可以使用的文字。

不過 OCR 並不是「有做就一定正確」。低解析度、頁面傾斜、模糊影像、特殊字型，甚至中文與英文混排，都可能造成辨識錯誤。假設原始文件寫著「退貨期限 30 天」，OCR 卻辨識成「退貨期限 80 天」，後面的 RAG 流程即使完全正常，最後得到的答案仍然可能是錯的。

因此，OCR 完成之後仍然需要抽樣檢查，而不是只確認程式有成功跑完。這和前面提過的 Parse 原則一樣：成功取得文字，不代表取得的是正確文字。

表格：數字讀到了，關係可能不見了

除了掃描頁面之外，企業文件裡另一個常見問題就是表格。

假設一份月報裡有下面這張表：

人類很自然會知道「150 萬」屬於 3 月，也知道「25%」是 3 月的成長率。但如果 PDF Parser 只是按照畫面上的文字位置依序抽出內容，最後可能變成：

月份
銷售額
成長率
1 月
2 月
3 月
100 萬
120 萬
150 萬
20%
25%

每一個數字都成功被讀出來了，但原本最重要的欄列關係已經消失。

這就是為什麼處理表格時，不能只問「文字有沒有抽出來」，還要確認資料之間的結構是否保留下來。比較理想的做法，是盡可能把表格保存成 Markdown、CSV、JSON 或其他結構化格式，讓後面的模型仍然能理解「哪一個數字屬於哪一個欄位」。

圖表：真正重要的是數字之間的關係

圖表的問題又更進一步。一張趨勢圖的價值，通常不只是圖上有哪些數字，而是這些數字之間發生了什麼變化。

例如一張折線圖可能要表達的是：前三個月銷售持續成長，但第四個月開始下滑，而且線上通路下降幅度比實體門市更大。如果我們只是使用 OCR 把圖上的「100、120、150、130」幾個數字抽出來，最重要的趨勢關係可能完全沒有被保留下來。

這時就可以考慮使用具備視覺理解能力的多模態模型（Multimodal Model）。它不只是讀取圖片裡有哪些文字，而是進一步理解圖表、畫面配置與視覺關係，再把內容整理成文字摘要。

例如原始圖表經過視覺理解後，可以轉換成：

2026 年第一季銷售逐月成長，3 月達到最高點。
4 月開始下降，其中線上通路下降幅度高於實體門市。
來源：2026_Q2_Business_Review.pdf，第 12 頁。

這份摘要之後就可以和一般文件 Chunk 一樣建立索引。當使用者詢問「第二季銷售下降主要發生在哪個通路？」時，RAG 才有機會找回原本只存在於圖表中的資訊。

系統截圖與流程圖，比 OCR 更複雜

企業文件中還有另一類常見內容：流程圖、系統畫面與操作截圖。

例如一張流程圖可能描述：

申請送出 → 主管審核 → 通過 → 財務核銷
                     ↓
                    拒絕
                     ↓
                  退回申請人

OCR 可以讀出「申請送出」、「主管審核」、「通過」、「拒絕」、「財務核銷」與「退回申請人」這些文字，但它不一定知道箭頭往哪裡走，也不一定知道「拒絕」是主管審核之後的另一條分支。

結果看起來像是「所有文字都讀到了」，實際上卻失去了這張圖最重要的流程語意。

因此，OCR 比較適合回答「圖片裡寫了什麼」，但如果真正的問題是「這些元素之間有什麼關係」，就可能需要視覺理解能力。這也是 OCR 與多模態模型很重要的差別之一。

不要讓所有文件都走同一條處理流程

看到這裡，可以開始理解企業 RAG 很重要的一個設計觀念：不同型態的內容，不一定需要走完全相同的 Ingestion Pipeline。

例如可以先把文件頁面大致分成幾種情況：

整體流程可以理解成：

PDF / 文件
     ↓
判斷頁面內容
     ↓
┌──────────────┬──────────────┬──────────────┐
│ 一般文字頁面 │   掃描頁面   │ 圖表 / 圖片  │
│              │              │              │
│    Parse     │     OCR      │ 視覺理解     │
└──────────────┴──────────────┴──────────────┘
     ↓
整理成可搜尋內容
     ↓
Chunk
     ↓
Embedding
     ↓
Index

這種設計不只是為了提升準確度，也和成本有關。一般文字解析通常比 OCR 或多模態模型便宜，也更快。如果一份 100 頁的報告只有其中 5 頁包含重要圖表，就沒有必要讓全部 100 頁都使用最昂貴的視覺模型處理。

Data Machi 的開源實作可以先從乾淨的文字 PDF 開始，因為我們現在的目的，是先把完整 RAG 流程建立起來。但知道這個邊界很重要，否則未來換成真正的企業文件時，很容易把「文件沒有被正確處理」誤認成「模型能力不夠」。

建立知識庫前，先做資料品質檢查

前面幾篇一直提到 Retrieval 品質，但在真正開始 Retrieval 之前，其實還有一個更基本的問題：進入知識庫的資料本身是否正確？

一個很實用的做法，是在建立索引之前先抽查幾份文件與幾個頁面，確認文字是否完整、段落順序是否合理、頁碼與來源是否保留、表格有沒有被拆亂，以及圖片中的重要資訊是否有被保留下來。

如果文件本身沒有正確轉換，這時候先不要急著調整 Embedding Model、Chunk Size 或 Top-k。因為問題如果發生在資料入口，後面再精密的 Retrieval 設定都無法把不存在的資訊找回來。

可以把 RAG 的資料品質想成一條連續的流程：

原始文件品質
      ↓
解析品質
      ↓
Chunk 品質
      ↓
Embedding
      ↓
Retrieval 品質
      ↓
Generation 品質

前面的步驟出現問題，往往會一路影響最後的答案。因此當 AI 找不到資料時，不要第一時間就怪模型，而是沿著這條流程往前檢查。

進階理解｜OCR 讀到文字，不代表讀懂關係

OCR 與視覺理解之間的差異，可以再用一個簡單的例子理解。

假設公司有一張組織圖，上面寫著：

CEO
├── Sales
│   ├── Retail
│   └── E-commerce
└── Finance

如果只使用 OCR，最後可能取得：

CEO
Sales
Retail
E-commerce
Finance

每個字都正確，但原本「Retail 與 E-commerce 都屬於 Sales，而 Sales 與 Finance 都向 CEO 報告」的組織關係已經不見了。

多模態模型的價值就在這裡。它不只是問「圖片裡有哪些字」，而是嘗試理解文字的位置、箭頭、區塊與視覺結構，再把它轉換成人類可以閱讀的描述。

因此，我們可以把企業文件的處理方式簡單分成三層：有文字層的頁面直接解析、掃描頁面使用 OCR，而圖表、流程圖與系統截圖則視需求加入多模態視覺理解。

重點不是所有內容都使用最強、最昂貴的方法，而是為不同資料選擇適合的處理方式。

延伸閱讀｜什麼是 Lazy OCR？

假設一份 200 頁的企業文件，其中只有 20 頁是掃描頁面。如果一開始就把全部 20 頁做 OCR，技術上當然可行，但使用者未必真的會查詢這些內容。

另一種思路叫做 Lazy OCR。系統先辨識並標記哪些頁面無法直接取得文字，但暫時不進行昂貴的 OCR 或視覺處理。當使用者的查詢真的碰到這些內容時，再進一步處理需要的頁面，並把處理結果保存起來供下一次使用。

流程可以簡單理解成：

文件進入系統
      ↓
偵測頁面類型
      ↓
發現掃描頁面
      ↓
先標記，不立即 OCR
      ↓
查詢真的需要該頁面
      ↓
執行 OCR / 視覺理解
      ↓
保存結果供後續使用

它背後真正重要的觀念並不是「Lazy OCR」這個名詞，而是：

把運算成本留到真正需要的時候再支付。

當文件數量從十份增加到幾千、幾萬份之後，這種成本控制就會變得非常重要。

今天的重點：
RAG 的上限，很大程度取決於文件進入知識庫之前的品質。AI 找不到的內容，很多時候不是資料不存在，而是從一開始就沒有被正確解析。

下一篇，我們會第一次真正動手，把 Gemini、文件索引與查詢流程接起來，完成 Data Machi 的第一個 PDF RAG。

我們下集見囉！