別再把 OCR 當成純文字辨識：PaddleOCR 如何把 PDF 變成 LLM 能用的資料

如果你曾經把掃描 PDF 接進 RAG，應該很快就會遇到一個尷尬問題：文字明明被抽出來了，回答品質卻沒有因此變好。表格欄位被打散、標題層級消失、雙欄文件閱讀順序錯亂，公式和圖片也只剩下一串難以使用的字元。對 LLM 來說，這不是「有沒有 OCR」的問題，而是輸入資料是否保留了文件原本的結構。

我認為 PaddleOCR 最值得注意的地方，正是它沒有把 OCR 停在文字辨識終點。PaddlePaddle 團隊把它定位成能將 PDF 與影像轉成結構化資料的 OCR toolkit 與 Document AI engine，輸出可以是 JSON、Markdown，甚至 Word。這讓它不只是影像轉文字函式庫，而是 RAG、文件問答與 Agent 工作流前面的資料整理層。

先講結論：它解決的是「文件進入 LLM 前的最後一公里」

PaddleOCR 適合處理三種常見任務。第一種是一般 OCR，也就是從照片、掃描件或自然場景中找出文字並辨識內容。第二種是文件解析，除了字串之外，還要理解版面、表格、公式、圖片和閱讀順序。第三種是視覺語言模型導向的文件理解，讓複雜頁面可以被整理成更接近人類閱讀方式的 Markdown 或 JSON。

這三者的差異很重要。若需求只是辨識發票上的幾個欄位，一個輕量 OCR pipeline 可能已經足夠；若需求是讓企業知識庫回答「第二頁表格中，去年第四季的毛利率是多少」，你就需要保留表格座標、欄位關係和跨頁結構。PaddleOCR 的多層 pipeline 設計，讓團隊可以依任務選擇，不必一開始就把最重的模型全部搬進服務。

PaddleOCR 的四層能力

1. PP-OCR：先把文字可靠地找出來

一般 OCR pipeline 由文件方向分類、文字影像去扭曲、文字行方向分類、文字偵測與文字辨識等模組組成。其中前幾個模組可以依場景開關，真正的文字偵測與辨識則是核心路徑。官方目前將 PP-OCRv6 列為預設模型系列，並提供 tiny、small、medium 等層級，讓部署可以在邊緣裝置、一般 CPU 與伺服器之間取捨。

這個層級的輸出適合搜尋索引、簡單欄位擷取、相片文字辨識和批次數位化。如果資料本身是單欄、排版簡單的影像，先從 PP-OCR 開始通常是最合理的工程選擇。

2. PP-StructureV3：把版面變成可用的結構

文件問答真正困難的地方通常不是字被認錯，而是字和字之間的關係被破壞。PP-StructureV3 的重點是文件版面解析，可以處理標題、段落、表格、公式、圖片等元素，並提供更細的座標資訊。官方範例顯示，它可以將結果儲存成 JSON、Markdown 或 Word。

對 RAG 而言，這一層可以視為 ingestion pipeline 的核心。你可以先用 JSON 保留座標、類型與頁碼，再依檢索需求產生 Markdown chunk。這比把所有文字直接串成一個長字串更容易做頁碼引用、表格重建、標題分層與錯誤追蹤。

3. PaddleOCR-VL：處理複雜頁面與多模態內容

當文件中有複雜圖表、手寫字、歷史文件或表格跨頁情況，單純的偵測加辨識 pipeline 可能不夠。PaddleOCR-VL 提供文件解析導向的 vision language model pipeline，能將輸出整理成 JSON、Markdown 與 Word。官方文件也提供 restructure_pages，可在多頁結果之間合併表格、重建多層標題與串接頁面。

這個能力很適合接在企業文件匯入流程後面，但也代表更高的模型與硬體成本。它比較像「高品質文件解析服務」，不是每一張收據都需要啟用的預設 OCR。

4. 多語、推論引擎與部署後端

PaddleOCR 不只提供 Python API。官方文件列出 PaddlePaddle、Transformers 與 ONNX Runtime 等推論方向，也提供 CPU、GPU 與多種 AI accelerator 的部署選項。一般文字辨識可從最小依賴開始，文件解析、資訊抽取、文件翻譯與 doc2md 等能力則用 optional dependency group 個別安裝。

這種設計的優點是可以把「功能選擇」和「硬體選擇」拆開。缺點是環境矩陣也會變得更複雜，尤其是 GPU、CUDA、PaddlePaddle、Transformers 和 FlashAttention 等依賴版本互相牽動時，不能只看一行 pip 指令就認定可以直接上線。

為什麼它對 RAG 特別有用？

我會把 PaddleOCR 放在 RAG 的 ingestion 邊界，而不是把它當成向量資料庫的替代品。一個比較完整的流程可以拆成六步：先接收 PDF 或影像；再做方向與版面處理；接著辨識文字、表格、公式與圖片；將結果保存為帶有頁碼和元素類型的 JSON；依標題與段落產生 Markdown chunks；最後才交給 embedding、vector store 和 reranker。

這樣的分層有三個實際好處。第一，OCR 錯誤可以追溯到原始頁面與座標，而不是等到 LLM 回答錯誤才猜原因。第二，同一份解析結果可以同時服務關鍵字搜尋、向量檢索、表格查詢和人工預覽。第三，當你替換 embedding model 或 LLM 時，不需要重新解析所有原始文件。

另一個常被忽略的好處是負責任的引用。若 chunk 保留頁碼、標題路徑和表格位置，回答就能附上「第幾頁、哪個區塊」的證據。這不會自動消除幻覺，但會讓評估、除錯與人工覆核有明確落點。

如何開始：先做最小可驗證流程

官方安裝文件把 paddleocr 核心套件和 optional capabilities 分開。基本 OCR 可以先安裝：

python -m pip install paddleocr

若要使用文件解析相關能力，官方列出的 dependency group 是 doc-parser；若需要把 Word、Excel 和 PowerPoint 轉成 Markdown，則可考慮 doc2md；要一次安裝完整能力才使用 all。實際推論前，還要依使用的後端安裝 PaddlePaddle 或其他 inference engine。

最小的 Python OCR 範例如下，程式碼採用官方文件目前的 pipeline API：

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
)

result = ocr.predict("./document.png")
for res in result:
    res.print()
    res.save_to_img("output")
    res.save_to_json("output")

如果目標是文件結構而不是純文字，可以改用 PP-StructureV3：

from paddleocr import PPStructureV3

pipeline = PPStructureV3()
output = pipeline.predict("./document.png")
for res in output:
    res.print()
    res.save_to_json(save_path="output")
    res.save_to_markdown(save_path="output")
    res.save_to_word(save_path="output")

若要快速試 PaddleOCR-VL，官方文件提供 CLI 與 Python API。以 Python API 為例：

from pathlib import Path
from paddleocr import PaddleOCRVL

output_dir = Path("./output")
output_dir.mkdir(parents=True, exist_ok=True)

pipeline = PaddleOCRVL()
output = pipeline.predict("./document.pdf")
for res in output:
    res.print()
    res.save_to_json(save_path=output_dir)
    res.save_to_markdown(save_path=output_dir)

第一次執行時要預留模型下載與初始化時間。官方也提醒，快速驗證用的本地方法不一定符合生產環境對速度、記憶體與穩定性的要求；真正上線時，應把模型服務、併發控制、批次大小、超時與監控一起設計。

導入時最容易踩到的五個坑

坑一：把 OCR 結果直接當成乾淨資料

OCR 輸出只是模型推論結果，不是事實資料。低解析度掃描、斜拍、印章、手寫字、表格線和特殊字體都可能造成錯誤。導入後要建立抽樣集，分開量測文字辨識、表格結構、欄位抽取和最終問答，不要只看一個總準確率。

坑二：所有文件都使用同一個 pipeline

一頁收據、雙欄研究報告、跨頁財務表格和含圖表的簡報，根本不是同一種輸入。可以先用文件分類器決定走 PP-OCR、PP-StructureV3 或 PaddleOCR-VL，並把高成本模型留給真正需要的頁面。

坑三：忽略模型下載與硬體相容性

PaddleOCR 會依 pipeline 自動取得官方模型，但這不代表 production container 裡可以無限制連外網。部署前應固定模型來源與版本，預先下載或建立快取，並確認 CPU、GPU、CUDA、PaddlePaddle 與推論引擎的組合。不要同時安裝互斥的 CPU 與 GPU PaddlePaddle 套件。

坑四：只把 Markdown 丟進向量資料庫

Markdown 很適合閱讀與初步切 chunk，但 JSON 中的頁碼、元素類型、座標與表格資訊不應丟掉。建議把可檢索文字和 provenance metadata 分開保存，讓向量檢索只負責找到候選內容，回答層再用 metadata 組合引用和頁面預覽。

坑五：用 benchmark 數字取代自己的驗證

官方 README 和文件提供許多模型、速度與 benchmark 資訊，但它們會受到資料集、硬體、推論模式和前後處理方式影響。你的文件格式、語言和掃描品質可能完全不同。最可靠的做法仍是拿真實資料建立 golden set，並記錄 latency、記憶體、失敗率和人工修正成本。

我會怎麼評估它是否適合團隊？

若團隊已經有 Python 服務、需要處理多語文件，而且 RAG 品質被 PDF 和掃描件拖累，PaddleOCR 值得先做一個小型 proof of concept。第一個 PoC 不要直接挑最難的全自動 Agent，而是選一個可量測的資料流，例如把一批供應商 PDF 轉成帶頁碼的 Markdown 和 JSON，再比較導入前後的檢索命中率與人工查找時間。

如果需求是少量簡單文字辨識，PaddleOCR 可能顯得太重；如果團隊沒有能力處理模型服務、硬體相容性和文件品質治理，也不應只因為 GitHub 星數高就直接替換現有 SaaS。它的開源和可部署性是優勢，但也意味著版本、模型、資源與監控責任要由使用者承擔。

對 AI Chain 這類重視實作的團隊，我會把它看成一個可組合的 document intelligence building block。它不會替你完成整個 RAG，也不會自動保證答案正確；它真正提供的是一條從非結構化文件到可被下游系統消費的資料管線。只要把這個邊界定清楚，後面的 embedding、檢索、引用和 Agent 工具才有穩定的地基。

結語：先修好輸入，才有資格討論模型

很多 RAG 專案把注意力放在換 embedding、調 chunk size 或比較不同 LLM，卻沒有先檢查文件進入系統時是否已經失去結構。PaddleOCR 的意義在於提醒我們，Document AI 並不是 RAG 旁邊的一個小工具，而是決定知識能不能被正確檢索的前置工程。

我會建議從最小路徑開始：先用 PP-OCR 建立可重現的文字辨識基線，再用 PP-StructureV3 加入版面和表格資訊，遇到複雜頁面時才引入 PaddleOCR-VL。每一步都保留原始檔、模型版本、頁碼、輸出格式和評估結果。這樣做看似慢，卻比一開始把所有模型接上 Agent，再用幾個錯誤答案追查整條鏈路可靠得多。

參考資料