很多團隊做 AI，最容易高估的是模型，最容易低估的是文件。

PDF 不是文字檔，簡報不是純段落，掃描件更不是把 OCR 打開就算結束。真正麻煩的不是「有沒有把檔案讀進來」，而是你在讀進來的那一刻，常常已經把文件最重要的脈絡弄丟了。標題層級不見了，表格欄位被打散了，頁面閱讀順序亂了，圖表和說明脫鉤了。後面就算接再強的模型，答案也很容易建立在壞資料上。

這也是 Docling 現在值得看的原因。

它厲害的不是又做了一個 PDF 轉 Markdown 工具，而是把文件前處理這件事，從「先抽成字再說」往可供 GenAI 使用的文件理解層推了一步。根據 README 與官方文件，Docling 支援 PDF、DOCX、PPTX、XLSX、HTML、圖片、音訊、影片、WebVTT、LaTeX、Markdown、XBRL 等多種格式，能輸出 Markdown、HTML、純文字、WebVTT、lossless JSON，核心中介格式則是它自己的 DoclingDocument。它也支援 OCR、VLM、MCP server，最近還把 Heron layout model、結構化抽取 beta、多語 OCR 等能力持續往前推。

先講結論，Docling 很值得現在看，尤其是你已經不只想把文件餵進 LLM，而是想把文件變成可工程化處理的資料層。 但另一面也要先講清楚，它不是萬能文件真相機。 如果你的期待是任何掃描 PDF、任何複雜表格、任何圖文混排都能零誤差還原，那很容易失望。

截至 2026-05-03 前後，GitHub 頁面顯示 Docling 約有 5.9 萬 stars、4.1 千 forks、171 個 releases、225 位 contributors，主分支在 2026-04-30 仍有更新，最新 release 為 v2.92.0，內容包括多語 OCR、docx checkbox parsing、模組化 docling-slim 套件，以及多個格式修正。這至少說明一件事，它不是停在研究 demo，而是明顯還在高速演進。

English TL;DR:

• Docling is an open-source document AI pipeline that turns PDFs, Office files, images, audio, and more into structured outputs such as Markdown, JSON, HTML, and WebVTT.
• Its real value is not simple text extraction, but preserving layout, reading order, tables, and document structure for downstream GenAI workflows.
• It is especially useful for RAG ingestion, enterprise knowledge pipelines, document extraction, and agent toolchains that need better document grounding.
• But Docling is not a perfect OCR engine, not a guaranteed high-fidelity layout replica, and not enough by itself for high-risk workflows like legal or financial review.
• The practical way to use it is as a document understanding layer, then add validation, chunking, access control, and human review where needed.

Docling 真正站的位置，不只是 parser，而是文件理解入口層

如果只用一句話講，Docling 是把多種文件格式轉成 AI 可處理結構的開源文件理解工具鏈。

但這句話還不夠準。

比較務實的理解是，Docling 想解的不是「你能不能把 PDF 讀出文字」，而是「你能不能在進入 RAG、抽取、摘要、agent 之前，先保住文件原本的結構脈絡」。

這件事看起來像前處理細節，實際上很常決定後面整條流程能不能上線。因為很多 AI 系統失敗，不是敗在模型太弱，而是敗在前面這幾件事：

• 標題和正文沒有被正確區分
• 表格被抽成亂序文字，欄位關係消失
• 掃描 PDF 的閱讀順序被打亂
• 同一份文件中的圖片、公式、註解、內文被拆成彼此無關的碎片
• 不同格式文件各自走不同 parser，最後整個 pipeline 很難維護

Docling 值得看的地方，就是它很明確地把這些問題當成本體，而不是把它們當成「之後再補」的小事。

為什麼這件事現在開始變重要

很多人以為文件前處理只是 RAG pipeline 的第一步，但更現實的是，它常常是整條 AI 系統裡最容易被低估、也最容易累積技術債的一段。

去年很多團隊還能接受「先抽文字，再讓模型自己想辦法理解」。今年不太行了。因為大家開始真的拿 AI 去碰更硬的內容：

• 企業內部 SOP、規格書、會議簡報
• 合約、採購文件、法遵手冊
• 財報、研究報告、XBRL 文件
• 掃描 PDF、圖片型文件
• 語音逐字稿、影片字幕、跨媒體文件包

這些內容有一個共同點，真正重要的不是字有沒有抓出來，而是結構有沒有保住。

你把一份財報的表格欄位拆散，後面的問答就會開始亂答。 你把投影片標題、內文、頁尾、備註混在一起，摘要看起來再流暢也可能失焦。 你把掃描合約的段落順序弄錯，後面的欄位抽取就可能直接誤判。

所以 Docling 代表的其實不是「文件轉換工具又多一個」，而是這條趨勢開始成形了：AI 文件處理正在從抽字工具，升級成結構理解工具。

哪些團隊會很有感，哪些其實先不用急

適合的團隊

1. 正在做 RAG 或企業知識庫，而且文件格式很多的團隊 如果你的知識來源不是乾淨資料庫，而是一堆 PDF、PPTX、Word、掃描件，Docling 很適合放在 ingestion 最前面。它先把文件統一成 DoclingDocument，再匯出 Markdown 或 JSON，後面 chunking、metadata 保留、索引與檢索都會比較穩。

2. 想做文件抽取，但不想一開始就全押在商業 API 上的團隊 Docling 支援本地執行、air-gapped 環境、OCR 與 VLM 擴充，對有敏感資料顧慮的團隊很有吸引力。它不是幫你把抽取問題一次做完，但能把底層文件理解層先建立起來。

3. 想把文件處理接進 agent 工作流的團隊 官方已經把 MCP server 納入主線敘事，這很關鍵。因為這代表它不只想做 parser，而是想成為 agent 可以呼叫的文件能力模組。

不太適合的團隊

1. 文件量很小、格式很單純的團隊 如果你只有少量文字檔、HTML 或很乾淨的 PDF，直接用輕量工具就夠了。Docling 的價值通常要在文件複雜度與格式異質性夠高時才會明顯。

2. 想要像設計稿一樣精準還原版面的團隊 Docling 強的是理解與結構，不是做出版級版面重建。如果你的需求是視覺排版還原、字體位置精準重現，那是另一類問題。

3. 高風險文件流程裡不能容忍誤差的團隊 法律、醫療、財報審閱、內控稽核這些場景，Docling 可以當前處理層，但不應是唯一真相來源。你還是要有驗證、對照、人工覆核。

三個具體場景，最能看出 Docling 的價值

場景一：把研究報告與財報，真的整理成可問答的知識庫

很多團隊做投研、顧問、產業研究，資料都不是乾淨 API，而是 PDF 報告、附表、年報、簡報。

這種場景真正麻煩的不是文件拿不到，而是文件雖然拿到了，進到模型前已經失真。尤其財報或研究報告常有：

• 多欄排版
• 表格與註解互相依賴
• 圖表搭配段落說明
• 頁首頁尾噪音很多

Docling 的價值在這裡，不是保證你一鍵做出完美 RAG，而是先把閱讀順序、表格結構、文件區塊整理得更像一份可機器處理的內容。這會直接影響後面的 chunk 品質、檢索命中率，甚至 prompt 裡能不能保住上下文。

場景二：把法務與營運部門收到的多格式附件，收斂成同一條處理流程

很多公司的文件入口很亂。合約草案是 DOCX，客戶掃描件是 PDF，簡報是 PPTX，佐證資料可能又是圖片或表格。

如果每一種格式都各自找 parser，各自做清洗，最後你會養出一整片很難維護的工具森林。

Docling 的務實價值是，先把多格式收斂到同一份中介表示，再決定要輸出 Markdown、JSON 還是接抽取流程。

對營運流程來說，這代表後面的分類、欄位抽取、摘要、風險提示，終於有機會走比較一致的處理路徑，而不是每一種副檔名都寫一套分支邏輯。

場景三：讓 agent 讀文件時，不是直接對原始格式硬上

現在很多人想讓 agent 幫忙讀文件、查規格、抽摘要、回答內部問題。但 agent 直接處理原始 PDF、簡報、掃描件，通常既不透明，也很難 debug。

Docling 搭 MCP 的意義就在這裡。它可以扮演中間的文件能力層，先把資料轉成可觀察、可輸出、可追查的結構，再交給 agent 使用。

這樣做的好處是：

• 工具輸入輸出更一致
• 出錯時比較容易查問題發生在哪一層
• 權限與能力邊界比較清楚
• 不同 agent framework 比較容易共用同一份文件處理能力

這個方向很像在做 AI 版的文件 middleware，而不是單點小工具。

從底層結構看，Docling 為什麼比「抽 PDF 文字」更完整

官方 architecture 文件講得很清楚，Docling 的核心不是單一 parser，而是一套「格式對應 backend 與 pipeline」的結構。

幾個重點值得特別看：

1. 先轉成 DoclingDocument，不是直接綁死某種輸出格式

這是一個很重要的設計。

因為你真正需要的，未必永遠都是 Markdown。有時你要 JSON 做結構抽取，有時要 HTML 保留較多資訊，有時要純文字進某個舊系統。Docling 先把文件統一成自己的中介表示，這讓下游選項變多，也比較有工程彈性。

2. PDF 不是單一處理路徑，而是可調整的 backend 與 pipeline

官方文件明講，Document Converter 有預設 mapping，但 PDF 這類格式的 backend 與 pipeline options 是可參數化的。這代表它不是把所有 PDF 都用同一把槌子敲。

這很重要，因為真實世界的 PDF 本來就差很多。數位原生 PDF、掃描 PDF、圖文混排 PDF，難度完全不同。

3. 它的野心不是只做 PDF

支援格式裡除了 PDF 與 Office，還包括圖片、音訊、影片、WebVTT、LaTeX、XBRL、JATS、USPTO XML。這說明它的定位不是單點 PDF 工具，而是想變成廣義的 document-to-AI structure 層。

4. OCR、VLM、ASR、MCP 都被納入同一個敘事

這代表團隊理解得很清楚，AI 時代的「文件」早就不只是靜態 PDF。圖片、字幕、音訊、表格、甚至影片音軌，最後都可能是同一條知識處理鏈的一部分。

這種整合視角，是 Docling 比許多單格式工具更有延展性的地方。

但它的限制，比優點更值得先講清楚

1. 它保的是結構，不是保證真相

Docling 比一般抽字工具更懂文件，這是真的。 但這不等於它輸出的每一個欄位、每一個閱讀順序、每一張表格都一定正確。

尤其碰到：

• 低品質掃描件
• 複雜跨欄版面
• 手寫或蓋章干擾
• 非典型表格與圖文混排
• 特殊語言或專有符號

你都應該預期需要驗證，而不是直接把輸出當黃金答案。

2. 功能很強，也代表依賴與成本可能不輕

OCR、VLM、ASR 這些能力不是沒有代價。它們可能需要額外套件、模型、算力，甚至不同部署條件。官方也明講 Python 3.9 已不再支援，需使用 3.10 以上。

如果團隊只是想做很輕量的文件轉換，Docling 有時反而會比需求本身更重。

3. 支援格式很廣，不等於每一種成熟度都一樣

這點一定要務實。支援面廣是優勢，但廣度本來就不代表每一個格式都同樣成熟。最穩健的做法不是看到支援清單就全面採用，而是先用自己的主力文件類型跑測試集。

4. 結構化抽取雖然很吸引人，但目前仍是 beta

官方把 structured information extraction 標成 beta，這其實是好事，代表他們沒有把能力包裝得過頭。對使用者來說，這也意味著你可以關注，但不要過早把它當作高風險業務的唯一依賴。

5. MCP 很方便，但也把權限與資料邊界問題帶了進來

只要一個工具能讀本地文件、讀 URI、接 agent，你就不能只把它當成方便功能，而要把它當成權限設計的一部分。這不是 Docling 的缺點，而是所有 agent 文件工具都會遇到的現實。

如果不用 Docling，還可以看哪些替代方案

1. MarkItDown

如果你的需求比較偏「快速把多格式內容轉成 Markdown，給 LLM 吃」，MarkItDown 會更輕、更直覺。它很適合當文件入口層，但在版面、閱讀順序、文件理解深度上，Docling 的企圖更大。

2. Unstructured

如果你想走 element-based 文件處理路線，Unstructured 仍然是很有代表性的選項。它對很多文件切分與元素處理流程更成熟，但導入與心智負擔通常也更高。

3. LlamaParse 或其他商業文件 API

如果你最在意的是省時間、少維運，商業 API 會更快。但代價通常是成本、資料邊界與可控性。Docling 的優勢則是本地化、可擴充與開源透明度。

結論

Docling 值得現在看，不是因為它又替文件處理做了一層漂亮包裝，而是因為它點出了一個很現實的事實：

AI 系統真正吃的不是檔案，而是被你整理過的結構。

如果你今天碰到的問題是，PDF 很多、格式很亂、表格常壞、RAG 不穩、agent 讀文件很難控，那 Docling 很可能比你再換一顆模型更值得先看。

但比較務實的採用判斷也要一起講清楚：

• 如果你需要的是更好的文件理解入口層，Docling 很值得試
• 如果你需要的是零誤差文件真相，高風險場景仍要加驗證與人工覆核
• 如果你的文件其實很簡單，先用更輕的工具可能更划算

結論不是「所有團隊都該上 Docling」，而是：

當你的 AI 問題其實卡在文件結構，而不是卡在模型智商時，Docling 會是一個很對題的答案。