大多數 RAG 教學都建立在一個很理想的前提上：PDF 裡有乾淨的文字層，系統可以直接解析文字、切成 Chunk，再建立 Embedding 與向量索引。

但真實的企業文件往往沒有這麼單純。

有些古老合約是掃描進系統的影像，操作手冊裡可能充滿流程圖與系統截圖，技術文件中的關鍵資訊藏在表格欄位關係裡，甚至有些 SOP 的真正操作步驟，是靠箭頭、框線與畫面位置才能理解。

這些內容對人類來說很直觀，但對只會讀取純文字的 RAG 系統而言，可能是一大片無法理解的黑洞。

因此，當我們開始處理真實企業知識時，問題就不再只是：

「怎麼把 PDF 文字抓出來？」

而是：

怎麼讓系統保留文件中的視覺結構與語意關係？

企業文件常見的三種「不好讀」情況

第一種最常見的情況，是 掃描型 PDF。這類文件表面上看起來是 PDF，但每一頁其實只是一張圖片，沒有可直接搜尋的文字層。對一般 PDF Parser 來說，整頁可能完全抓不到任何文字。

第二種是 版面本身就是資訊的一部分。例如表格中的欄位對應、兩欄式規格書、流程圖中的箭頭與分支、組織圖中的上下層關係。即使系統能辨識所有文字，只要排版關係消失，真正的語意也可能跟著消失。

第三種則是 圖片本身承載主要知識。例如操作手冊中的系統截圖、儀表板畫面、設備面板、錯誤訊息截圖，或圖表中的趨勢。這類資訊如果只抓取周圍文字，可能完全無法回答使用者真正的問題。

例如，一份操作手冊可能只寫：

「請依照下圖完成設定。」

如果系統看不到圖片，那麼這句話幾乎沒有任何實際資訊。

OCR 只是第一步，不是終點

處理掃描 PDF 時，最直覺的方法通常是 OCR。

OCR 的全名是 Optical Character Recognition（光學字元辨識），功能是把圖片裡看到的文字轉換成可以搜尋、儲存與向量化的字元。

例如一張掃描頁面原本是：

差旅申請應於出發日前五個工作天提出。

經過 OCR 後，系統就能取得這段文字，進一步做 Chunking、Embedding 與搜尋。

因此，OCR 是處理掃描文件非常重要的第一步。

但它也有一個根本限制：

OCR 抽取的是文字，不是語意關係。

為什麼只有 OCR 還不夠？

以一張流程圖為例，人類看到的可能是：

[申請送出]
      ↓
[主管審核]
   ↙      ↘
拒絕      通過
 ↓         ↓
[退回]   [財務核銷]

人類一眼就知道流程有兩條分支：主管核准後往財務核銷走，拒絕則退回申請人。

但 OCR 最後可能只抽出：

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

所有文字都成功辨識了，真正重要的資訊卻不見了。

例如：

• 誰先誰後
• 箭頭方向
• 哪個條件造成分支
• 「拒絕」對應哪條路徑
• 「通過」之後應去哪裡
• 哪些方框屬於同一條流程

如果直接把這段 OCR 結果存進知識庫，模型甚至可能比完全不知道還危險，因為它會看到一組真實文字，卻不知道文字之間真正的結構關係。

同樣的問題也會發生在表格中。

例如：

如果 OCR 最後只得到：

Priority SLA Escalation
High Medium Low
1 day 3 days 5 days
Director Manager Team Lead

模型知道頁面上有哪些字，卻不一定知道 High 對應 1 day 與 Director。

因此，企業多模態文件真正需要解決的，不只是文字辨識，而是：

如何保存文字之間的結構與關係。

Data Machi 的三層內容處理思路

在 Data Machi 中，不同類型的文件內容不應全部使用同一種方式處理。

比較合理的設計，是依照內容複雜程度分成不同層級。

第一層：原生文字直接解析

如果 PDF 本身已經有乾淨的文字層，就優先使用一般 Parser。

這類頁面處理速度快、成本低，而且文字通常最接近原始內容。例如一般政策文件、文字型報告、會議紀錄或條款文件，都很適合直接抽取文字。

處理流程可以保持簡單：

PDF
 ↓
Text Parser
 ↓
Chunk
 ↓
Embedding
 ↓
Index

第二層：掃描頁使用 OCR

如果某一頁沒有文字層，但主要內容仍然是文字，例如掃描合約、舊版規章或紙本表單，可以透過 OCR 補上可搜尋文字。

流程變成：

Scanned Page
 ↓
OCR
 ↓
Extracted Text
 ↓
Chunk
 ↓
Embedding

這一層的主要目標，是把原本完全不可搜尋的圖片文字轉成可搜尋內容。

第三層：視覺結構交給多模態模型理解

如果頁面中真正重要的是流程圖、表格、截圖、圖表或視覺位置關係，單純 OCR 就不足夠。

這時需要讓具備視覺理解能力的多模態模型，針對整頁內容產生一份結構化摘要。

例如，不只是說頁面上有哪些字，而是描述：

• 這張圖的主要目的
• 有哪些可見文字
• 哪些元素彼此連接
• 流程的先後順序
• 哪些條件造成分支
• 表格中的欄列關係
• 有哪些重要警告或例外
• 哪些關係只是推論，不能視為確定事實

這樣的結果才更接近人真正「讀懂這一頁」的方式。

視覺摘要可以長什麼樣子？

假設某一頁是一張費用申請流程圖，Data Machi 可以將視覺理解結果整理成結構化 Metadata：

{
  "page": 12,
  "content_type": "flowchart",
  "visual_summary": {
    "page_purpose": "說明費用申請的審核流程與分支條件",
    "visible_text": [
      "申請送出",
      "主管審核",
      "通過",
      "拒絕",
      "財務核銷",
      "退回申請人"
    ],
    "relationships": [
      "申請送出 → 主管審核（固定步驟）",
      "主管審核 → 通過 → 財務核銷（審核通過路徑）",
      "主管審核 → 拒絕 → 退回申請人（審核拒絕路徑）"
    ],
    "do_not_confuse": "此流程為一般費用申請，不適用於超過 10 萬元的專案採購"
  }
}

這份摘要的價值，不只是把圖片「翻譯成文字」，而是把原本只有人看得懂的空間與流程關係，轉換成模型可以理解的結構化語意。

相較之下，原始 OCR 可能只有：

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

兩者包含的文字差不多，但後者幾乎保留不了流程邏輯。

系統截圖也需要理解「畫面正在做什麼」

流程圖不是唯一需要視覺理解的內容。

企業操作手冊中常見大量系統截圖。例如文件可能寫：

「進入 Settings 後，點擊右上角的 Add User。」

真正的資訊可能全部存在截圖裡，包括：

• Settings 在哪裡
• Add User 按鈕的位置
• 哪個頁籤需要先被選中
• 按鈕是否可能是灰色狀態
• 畫面中有哪些必要欄位

如果只抽取圖片上的文字：

Settings
User Management
Add User
Role
Email
Save

仍然不知道操作順序。

更好的視覺摘要可能是：

畫面為 User Management 設定頁。

操作順序：
1. 進入 Settings。
2. 在左側選單選擇 User Management。
3. 點擊右上角的 Add User。
4. 填寫 Email 與 Role。
5. 點擊 Save 建立帳號。

這樣的內容才真正能支援之後的問答：

「我要在哪裡新增使用者？」

或：

「新增使用者前要先進哪個選單？」

表格的問題更複雜

表格也是 RAG 中非常容易被低估的內容類型。

人類閱讀表格時，會自然理解列、欄與標題之間的關係；但一般文字抽取後，這些關係很容易消失。

例如：

如果使用者問：

「日本市場超過多少金額需要 Director 核准？」

系統必須理解：

Japan
→ Budget Limit = 100,000
→ Approval = Director

這不是單純的文字相似度問題，而是資料結構理解。

因此，處理複雜表格時，較理想的做法通常不是把所有 cell 串成一段文字，而是保留結構，例如：

{
  "market": "Japan",
  "budget_limit": 100000,
  "approval": "Director"
}

這樣才能讓後續檢索與問答更穩定。

為什麼不是所有頁面都直接做多模態處理？

既然多模態模型可以看圖片、理解流程圖與表格，最簡單的做法似乎是：

所有 PDF 每一頁都直接丟給多模態模型處理。

技術上可以，但成本往往非常高。

假設企業一次上傳 100 份文件，每份平均 80 頁，就是：

100 × 80 = 8,000 頁

如果每一頁都進行：

• OCR
• 圖像解析
• 多模態模型摘要
• Embedding

即使絕大部分頁面最後從未被任何使用者查詢，系統仍然已經付出了所有計算與 API 成本。

因此，Data Machi 採用一個更偏向按需處理的設計思路：Lazy OCR。

Lazy OCR：真正需要時再付出成本

Lazy OCR 可以翻成「延遲 OCR」或「按需 OCR」。

它的核心概念是：

不要因為文件被上傳，就假設每一頁未來都一定會被使用。

文件上傳時，可以先進行相對便宜的處理：

文件上傳
   ↓
檢查頁面是否具有文字層
   ↓
有文字層
→ 直接 Parse、Chunk、Embed

沒有文字層
→ 標記為需要 OCR
→ 暫時不處理

接著，只有在後續查詢真的涉及這些頁面時，才觸發 OCR 或視覺理解。

概念上可以是：

使用者提出問題
   ↓
檢索相關文件區域
   ↓
發現候選頁面尚未完成 OCR
   ↓
即時執行 OCR / Visual Summary
   ↓
建立新的可搜尋內容
   ↓
回傳答案
   ↓
將結果快取

下一次再查詢同一頁時，就不需要重新執行。

Lazy OCR 真正省的是什麼？

Lazy OCR 主要在三個方面產生價值。

第一是 降低 API 與運算成本。只有真正被查詢到的掃描頁，才需要進行昂貴的視覺處理。

第二是 降低文件匯入時間。如果每次上傳文件都要等待所有頁面完成 OCR 與視覺摘要，大型文件可能需要很久才能開始使用。

第三則是 讓處理策略更有彈性。某些掃描頁可能只需要 OCR，某些流程圖才需要更昂貴的多模態模型；系統可以根據實際內容選擇處理層級，而不是全部使用最高成本的方法。

當然，Lazy OCR 也有代價：第一次查詢某個尚未處理的頁面時，回應時間可能比較長。

因此，它本質上是一個產品取捨：

預先支付所有成本，還是把部分成本延後到真正需要時？

在文件量很大的企業環境中，後者往往更有彈性。

踩坑筆記：圖和文字靠得近，不代表一定有關係

多模態文件還有一個很容易被忽略的風險：相鄰不代表相關。

例如，一張「錯誤示範」截圖可能出現在一段操作說明旁邊。如果模型沒有理解語境，就可能把錯誤操作當成正確步驟。

另一種情況是，文件中的流程圖仍然是舊版本，但旁邊的文字已經更新。如果模型把兩者直接合併，就可能產生一套根本不存在的混合流程。

表格也可能發生類似問題。某一列備註可能引用另一份文件，而不是補充目前這一列的規則。如果模型只是看到它們出現在附近，就直接推斷兩者有因果關係，也會產生錯誤。

因此，在設計視覺摘要時，不應只要求：

「描述這張圖片。」

而應要求模型明確區分：

圖中直接可見的事實

例如：

圖中有三個節點：
申請送出、主管審核、財務核銷。

可以確定的視覺關係

例如：

箭頭由「申請送出」指向「主管審核」。

根據上下文推測的關係

例如：

旁邊文字提到「特殊採購需財務長核准」，
但無法確認是否適用於圖中的一般費用流程。

這種區分非常重要。

好的多模態摘要，不只要告訴模型「看到了什麼」，也要告訴模型「哪些事情無法確定」。

多模態 RAG 可以處理哪些內容？

當文件中真的包含視覺知識時，多模態模型可以補足傳統純文字 RAG 的不足。

典型用途包括：

掃描文件

將沒有文字層的合約、規章與歷史文件轉換成可以搜尋的內容。

複雜表格

理解欄位名稱、列與欄之間的對應關係，而不是把所有 cell 變成一串文字。

流程圖

解析節點、箭頭、條件與分支關係，讓系統理解「下一步去哪裡」。

系統截圖

理解操作介面、按鈕位置、欄位與操作順序。

圖表

描述趨勢、比較、峰值與異常，例如：

2026 Q2 的需求量明顯高於前兩季，其中日本市場增幅最大。

架構圖

理解系統元件及彼此的連線關係，例如：

User
→ API Gateway
→ Agent
→ Tool Layer
→ Enterprise Systems

這些都是純 OCR 很難完整處理的知識。

不是所有圖片都值得進行多模態理解

多模態能力很強，但不代表每一張圖都值得花費相同成本處理。

例如：

• 公司 Logo
• 裝飾性圖片
• 頁面背景
• 重複圖示
• 沒有資訊價值的封面圖片

如果全部送進視覺模型，只會增加成本與雜訊。

因此，更成熟的流程應該先做內容分類：

Page / Image
   ↓
內容分類
   ↓
純文字？
→ Text Parser

掃描文字？
→ OCR

表格？
→ Table Parser / Vision Model

流程圖或系統截圖？
→ Multimodal Model

裝飾圖片？
→ Ignore

這種設計的核心精神，是讓每種內容使用最適合、成本也合理的處理方式。

成本、速度與品質之間的取捨

多模態 RAG 很容易出現一個工程上的矛盾：

處理得越完整，成本通常越高；處理得越便宜，又可能遺失重要資訊。

因此，實際設計時需要同時考慮三個維度：

對高價值、高查詢頻率的操作手冊，可以考慮在匯入時就完整處理；對數千份幾乎不會被查詢的歷史掃描文件，Lazy OCR 可能更合理。

因此，最佳方案通常不是單一技術，而是依文件價值與使用頻率做分層。

踩坑筆記：多模態模型也可能看錯

使用 Vision Model 並不代表視覺理解就百分之百正確。

它仍然可能：

• 看錯小字
• 誤解箭頭方向
• 將兩個區塊錯誤連接
• 忽略表格中的註腳
• 誤判圖表座標軸
• 把裝飾圖示當成流程元素
• 過度解讀圖片沒有明確表示的關係

因此，企業多模態 RAG 仍然需要保留：

• 原始頁碼
• 原始文件
• 圖片位置
• OCR 結果
• 視覺摘要
• 信心程度
• 可追溯的來源

當回答涉及高風險內容時，使用者應該能回到原始文件確認，而不是只能相信模型產生的視覺描述。

這其實和前面幾天一直強調的原則一致：

AI 可以協助理解，但事實來源仍然要能被追溯。

本日重點

今天只需要記住一件事：

OCR 能讓 AI 看到文字，但多模態理解才有機會讓 AI 看懂文件中的結構。

處理企業 PDF 時，不能假設所有知識都是乾淨文字。掃描頁面、表格、流程圖、截圖與圖表，都可能承載關鍵資訊。

因此，一套較完整的文件處理流程可能包含：

1. 優先解析原生文字
2. 對掃描文字執行 OCR
3. 對流程圖、表格與截圖進行視覺理解
4. 將視覺關係轉換成結構化摘要
5. 保留來源、頁碼與不確定性資訊
6. 透過 Lazy OCR 控制處理成本
7. 對昂貴的多模態能力採取按需使用

RAG 的目標不是單純讓所有文件都「變成文字」，而是盡可能保留原本文件中的真正知識。

下一篇，我們會進一步處理另一個更根本的問題：即使 RAG 成功找到了正確資料，這是否就代表 AI 已經可以完成工作？RAG 的能力邊界在哪裡，又為什麼企業 AI 最後一定會走向 Tool Use？