Docling 常常被拿來跟網頁爬蟲相提並論，但它其實不是。它是 IBM Research 開發的文件轉換工具組——現在已成為 LF AI & Data Foundation 的專案——可把你手上既有的檔案（PDF、DOCX、PPTX、XLSX、HTML、圖片）轉成 Markdown 或 JSON。它自己的標語就直接寫著：「讓你的文件為生成式 AI 做好準備。」
所以這篇是一篇針對轉換器的實測評測，不是爬蟲測試。以下所有結果都在同一台僅使用 CPU 的機器上量測（macOS arm64、Python 3.14.2、Docling 2.111.0），以腳本評分，失敗就是失敗。這個 repo 非常龐大，而且每天都在變動——63,069 顆星、4,449 個 fork，以及我抓取 metadata 當天剛好又有一次 push——所以本文提到的任何 issue 數量或版本號，都請把它當作某個時間點的快照，不是固定值。
Docling 到底是什麼，又不是什麼
Docling 裡所有東西的基本單位都是 DoclingDocument：先把檔案解析成這個結構，再輸出 Markdown、HTML、DocTags，或無損 JSON。程式碼採用 MIT 授權（各個模型的授權則可能不同），最早源自 IBM Research Zurich；截至我撰寫時，最新版是 v2.112.0，發布時間是我測試前兩天。
它最主打的能力是 PDF 與圖片路徑。這條路徑不是做字串解析，而是一整套機器學習模型：RT-DETR 版面模型、TableFormer 表格結構模型、可選的 vision-language model，以及用來處理掃描檔的 RapidOCR。這些模型負責還原頁面版面、閱讀順序與表格結構。這才是值得檢視的核心，也是純 HTML 測試永遠看不到的部分。
有一個區分可以幫你省掉一週的誤會：Docling 不會幫你抓資料。它不會渲染 JavaScript，不會對抗反爬機制，也不會做爬取。你把檔案交給它，它負責理解內容。爬取是別的工具的工作，這點之後很重要，因為很多人會問 Docling 能不能取代 Firecrawl（答案是不行——兩者是互補的，我後面會說原因）。
第一次執行時，沒人先提醒你的事
在 Python 3.14.2 下執行 pip install docling 會順利完成。接著你看虛擬環境，會發現它有 1.3 GB。即使你最後只轉一個 HTML 檔，Docling 仍會把完整的 ML 堆疊當成強制依賴一起裝下來：
| 相依套件 | 磁碟占用大小（MiB，du） |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr（+ 內建模型） | 75.6 |
| docling_parse | 30 |
這還是在你轉第一個 PDF 之前。真正的摩擦點出現在第一次 PDF 轉換時，因為模型會在這時下載。若是全新的、隔離的 HuggingFace cache，第一次 PDF 轉換大約花了 224 秒——而且幾乎全部時間都花在下載，不是運算。版面模型加上 TableFormer 模型的磁碟占用約為 506 MiB（TableFormer 342 MiB + layout 164 MiB，經 du 驗證），而 RapidOCR 會把約 40 MB 的 PP-OCRv4 權重抓到 site-packages。同一檔案第二次轉換呢？0.55 秒。 模型已快取，這筆成本只付一次。
有一個數字你不該拿去當 footprint：coldstart 腳本印出的 model_download_mb 是 1060.2。不要把它當成實際占用大小。那是因為 os.walk 會跟著 symlink 走，而 HuggingFace cache 會先把模型檔只存一次在 blobs/，再透過 snapshots/ 的 symlink 重新暴露出來——所以這個掃描把 14 個模型檔算了兩次。與 du 相符、且去除 symlink 重複計算後的數字是 約 506 MiB（只算 blobs 則是 505.4 MiB）。對任何想替 Docling 做 benchmark 的人來說，重點是：下載量和磁碟占用要分開報，因為它們本來就不是同一件事。
還有另一個坑，會咬到任何想把 Docling 做成容器的人。權重分成兩個位置，而且更新時程也不同。layout 與 TableFormer 模型會遵守 HF_HOME，在第一次 PDF 轉換時下載；但 RapidOCR 的模型不會——它們會直接落到 …/site-packages/rapidocr/models/，完全繞過你的 cache 設定。如果你要預先打包映像檔，或是在離線環境使用，就得同時處理這兩套 cache，單靠設定 HF_HOME 擋不住第二種。
公平地說，Docling 早期版本的問題已經有部分解法。專案後來推出了 docling-slim——一個大約 50 MB 的核心版本，讓你可以用 pip install docling-slim[format-html] 來處理 HTML，而不用把 torch 一起拖進來。所以預設 docling metapackage 的 1.3 GB 成本是真的，但現在已經可以選擇不裝。這次我測的是預設套件，因為 pip install docling 目前拿到的就是它；不過這種重量感並不是無解的缺陷——模組化的修正方案已經存在，並且被追蹤在 issue #2393。
設定環境時，我還遇到一個小刺點，值得提一下：import docling; docling.__version__ 會丟出 AttributeError: module 'docling' has no attribute '__version__'。這個 module 根本沒有對外暴露版本號。可用的查法是 importlib.metadata.version("docling")，回傳 '2.111.0'。這只是小小的開發體驗不便，且 自 2026 年 7 月起已在 upstream 以 issue #3733 開著。
表格還原度：TableFormer 的價值所在
表格是大家會從普通 PDF 轉文字工具轉向 Docling 的主要原因，所以我做了七個帶有機器可讀 ground truth 的表格 PDF，並逐格評分。這裡有兩個重要指標，而且它們不一樣：cell recall 是 ground truth 的值有多少比例被找到了，不管位置在哪裡；in-row rate 則是這些值有多少比例被放到正確的列。把這兩者混為一談會過度美化工具，所以這裡兩個都列出來：
| 表格（壓力測試） | 是否偵測到 | Cell recall | In-row rate | 備註 |
|---|---|---|---|---|
| T1 單獨放在頁面上的簡單有框線網格（5×8） | 否 | 0.0 | — | 被判成 <!-- image -->，所有儲存格都被丟掉 |
| T2 無框線（只有表頭分隔線） | 是 | 1.00 | 1.00 | 完美，格線完全正確 |
| T3 兩層 colspan 合併表頭 | 是 | 1.00 | 0.97 | 所有值都有找回；但有一個表頭值掉到下一列 |
| T4 合併 rowspan 的列標籤，單獨放在頁面上 | 否 | 0.0 | — | 被判成 <!-- image --> |
| T5 colspan 表頭 + 無框線 | 是 | 1.00 | 0.97 | 所有值都有找回；和 T3 一樣有表頭列偏移 |
| T6 財務表、空白欄、右對齊 | 是 | 1.00 | 1.00 | 空白欄有保留，沒有被位移 |
| T7 寬版 12 欄網格 | 是 | 1.00 | 1.00 | 寬表格沒有發生欄位偏移 |
在 Docling 有成功偵測到的五個表格裡，所有 ground-truth 值都被還原出來——cell recall 全部都是 1.00。其中有三個表格，所有值也都落在正確列上。至於兩個多層表頭案例（T3 和 T5），有一個表頭值會從原本那列滑掉，導致 in-row rate 降到 0.97——資料都在，只是堆疊式表頭的列歸屬會晃一下。
那些結構比較難的案例，其實表現比我原本預期還好。兩層 colspan 表頭會正確攤平成 GitHub-flavored Markdown（"Q1 2026" 標籤會跨兩個欄位重複顯示，這就是把 colspan 轉成 GFM 的正確方式）。只有表頭分隔線的無框線表格（T2）也能完全正確還原。12 欄寬表格（T7）沒有欄位偏移。完全空白的財務欄（T6）則是以空儲存格形式保留下來，而不是被刪掉或壓縮掉。這和 官方 TableFormer 的 TEDS 分數 一致——simple 95.4、complex 90.1、all-tables 93.6——模型卡上的 benchmark 也明顯高於 Camelot（73.0）與 EDD（88.3）。
不過要注意合併儲存格，因為有一個開放中的 issue 說的是相反的狀況。Issue #3698 回報 V1 與 V2 對合併列與欄的處理有問題。在我的測試樣本中，簡單的 colspan（T3/T5）和 rowspan 值都能正確攤平，只有上面提到的多層表頭列偏移例外。但 #3698 的失敗案例是較不規則的多列／多欄合併，以及 跨頁表格——那是病理性最難的端點。我測的是比較簡單的端點。所以比較精準的說法應該是：這裡的簡單 colspan 和 rowspan 能被成功還原（但多層表頭可能會偏一列）；複雜且不規則的合併仍是已知的開放問題。不是「合併儲存格都沒問題」，也不是「合併儲存格完全不能用」。
陷阱：單獨一整頁的表格可能直接消失
回頭看那張表——T1 和 T4 根本沒被偵測到。Docling 直接輸出 <!-- image -->，然後把所有儲存格丟掉，也沒有報錯。T1 是一個非常正常的有框線 5×8 網格。這種情況警訊夠大，讓我不敢直接把它歸因於表格解析弱，我先把真正的觸發條件隔離出來，所以做了腳本化的 A/B 測試。
首先，我先排除最直覺的說法。文字層其實是完整的——pypdfium2 讀得到 T1 的 327 個字元、T4 的 221 個字元，所以這些都是真的數位 PDF，不是掃描圖片。把 OCR 關掉（do_ocr=False）也沒用；表格還是會消失。直接檢查 DoclingDocument 也一樣，len(doc.tables) == 0 但 len(doc.pictures) == 1 ——版面模型把整個表格區塊判成了 Picture。
接著就是關鍵測試。我把完全相同的 T1 和 T4 重新排版，這次在它們周圍加上幾段正常的內文，再轉一次。兩者都完美通過：len(doc.tables) == 1、正確輸出 GFM 表格，而且 T4b 的 rowspan 標籤 "North" 也正確跨過三列重複顯示。表格一樣，唯一改變的變數就是它是孤零零地站在稀疏頁面上，還是嵌在文字中。
所以真正的 caveat 不是 TableFormer 很脆弱，而是 Docling 的 RT-DETR 版面模型會利用頁面上下文；如果一個小表格獨自放在幾乎空白的頁面上，它很可能被當成 Picture，然後默默丟掉。這在實務上很容易碰到，因為發票、規格表、裁切匯出檔常常就是這種樣子：一頁一張表，沒有任何上下文文字。解法很樸實也有效——給版面模型更多頁面上下文，或者在轉換後檢查 doc.tables，把表格數量為零的頁面標記出來。這件事和 issue #3495（同一張表同時被判成 Table 和 Picture）很接近，但我沒看到任何已公開的資料明確寫出這個「頁面太空」的觸發條件——同一張表，孤立時會掉，嵌入文字時又會轉成功。這是我實測出來的，不是先前早就有的紀錄；也不是沒人知道的 bug。
真實掃描檔上的 OCR：RapidOCR，不是 EasyOCR
掃描版 PDF 常常是轉檔工具悄悄翻車的地方，所以我拿兩份真正的掃描檔餵給 Docling，且它們的文字層經量測為 0 字元——pypdfium2 回報沒有任何可回收字元，這能確認輸出若有文字，全部都來自 OCR，而不是附帶的隱藏文字層。
單頁的 ocr_test.pdf 在 CPU 上 14.3 秒就乾淨輸出：「Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,」而且與原文完全一致。四頁的 nemotron_multipage.pdf 則在總共 70.1 秒內把四頁都跑完 OCR（每頁 17.5 秒），每頁都輸出重複的測試句子。預設 OCR 會自動啟動——不用額外參數，也不用設定。
有一個細節是很多文章會寫錯的：預設 OCR 引擎其實是 RapidOCR，不是 EasyOCR。我是看著第一次執行時下載 PP-OCRv4 的 .pth 權重，才確認這點。很多現有部落格和舊版 Docling FAQ 仍然寫 EasyOCR 是預設值，那是過時資訊。現在 EasyOCR 只是你可以選擇加裝的額外套件。仍然成立的 caveat 是：OCR 在大規模使用時會是慢路徑，而且這裡的一切都只是在 CPU 下跑出的上限；如果用 GPU，時間會明顯縮短。
真實 PDF、閱讀順序與每頁耗時
合成測試可以證明特定行為；真實 PDF 才能證明它真的能用。我測了兩份原生數位化的學術論文——9 頁的 Docling 技術報告，以及 15 頁的 "Attention Is All You Need"，兩者都是雙欄排版，裡面還有表格和公式。
在 15 頁的 Attention 論文中，所有五個章節標記——Abstract、Introduction、Background、Conclusion、References——都在線性化後的 Markdown 中以文件順序出現。所有內容探針（Transformer、encoder、BLEU、multi-head）也都找得到，而那幾個著名的多欄結果表則被辨識成四個表格。這是真正的閱讀順序與欄位合併還原，這也是 RAG 分塊的核心價值——如果線性化器把雙欄頁面切成交錯亂碼，你根本無法合理切 chunk。
時間上還帶來一個反直覺的觀察：每頁耗時不是由頁數決定，而是由每頁的結構密度決定。較密集的 9 頁報告每頁花了 14.95 秒——比 15 頁論文的 5.99 秒/頁 還慢——因為它塞了更多表格與圖，這些都會觸發更多版面與 TableFormer 推論。所以在 CPU 上看「每頁幾秒」，其實反映的是結構密度，不是長度。這是單次 CPU 測試；只能代表上限，不是生產環境數字。
多格式支援與無損 JSON 的說法
Docling 主打統一的多格式解析，所以我做了一個 DOCX、一個 XLSX 和一個 PPTX，裡面都放了已知內容與 ground-truth 探針，然後檢查兩件事：這些探針有沒有出現在 Markdown 裡，以及經由 export_to_dict() 轉回 JSON 之後，內容有沒有保留下來。
| 檔案 | 轉換時間 s | Markdown 探針命中 | Markdown 裡的表格數 | JSON 是否保留探針 |
|---|---|---|---|---|
report.docx（標題 + 合併「Total」表格 + 項目符號） | 0.137 | 7/7 | 1 | 是 |
workbook.xlsx（2 個工作表，空白欄） | 0.016 | 6/6 | 2 | 是 |
deck.pptx（3 張投影片，項目符號 + 表格） | 0.038 | 6/6 | 1 | 是 |
所有內容探針都進了 Markdown，表格也都有還原（包含 DOCX 裡合併的 "Total" 那列，以及 XLSX 的兩個工作表），而且每一個探針在 export_to_dict() 之後也都還在 JSON 裡——至少在乾淨輸入上，這就是支撐無損 DoclingDocument 主張的證據。這些格式走的是原生格式後端，不靠 ML 模型，所以才會在幾十毫秒內跑完，而且能完整離線執行。這個範圍說得很誠實：每種格式各拿一個乾淨檔案，只能證明廣度，不代表對病理性的 Office 檔做了壓力測試。
HTML：忠實，但不乾淨
這是會決定 Docling 要不要進你的 RAG pipeline 的關鍵 caveat，所以請仔細看。Docling 會轉換整份 HTML 文件，它不會像 readability 那樣只抽主內容。我用統計 Docling 輸出中 nav、TOC、cookie 與 footer 標記行的方式，量化有多少網站外殼內容被保留下來。
| 頁面 | 非空 Markdown 行數 | 模板雜訊行數 | 雜訊比例 | 文章開始於第幾行 |
|---|---|---|---|---|
| Wikipedia「Web scraping」 | 255 | 34 | 13.3% | 28 |
| scrapethissite/forms | 63 | 1 | 1.6% | — |
| books.toscrape | 65 | 0 | 0.0% | — |
| quotes.toscrape | 35 | 0 | 0.0% | — |
在像 Wikipedia 這種外殼很多的頁面上，大約 13% 的 Markdown 行數都是 nav/TOC/footer 的模板內容，而真正的文章要到第 28 行才開始——輸出一開頭就是「move to sidebar / Contents / Toggle the table of contents」，結尾則是「CS1 maint… / Search Wikipedia。」在乾淨內容頁（books、quotes）上，雜訊比例接近 0%，所以這是模板外殼問題，不是每頁都要付出的稅。Docling 給你的是忠實的整份文件 Markdown，不是乾淨的主文章抽取。上游針對 HTML 外殼問題，有 issue #1865（已關閉）與 #1930（開啟中）在追蹤。
這裡有兩點可以讓評論更公平。第一，Docling 在 HTML 模式下其實完全沒有跑 ML 模型——它只是走一條簡單 pipeline 裡的 BeautifulSoup 後端。那些「vision model 在讀你的頁面」的說法，只適用於 PDF 和圖片；把 HTML 丟給 Docling 時，版面與 TableFormer 那套機制根本不會啟動。第二，PDF 路徑確實會嘗試做 header/footer 的雜訊分類，所以如果說它「完全不做 boilerplate removal」又太過頭了——真正把外殼原樣帶回來的，是 HTML 後端，特別是它。
跟其他工具怎麼比，以及 Thunderbit 的位置
大家最常拿來跟 Docling 比的基準工具是 Firecrawl，所以這裡先放一個定位表。先說一個重要 caveat：這是文件層級的比較，不是同機 benchmark。我沒有在這些 fixtures 上跑 Firecrawl。這裡只有 Docling 欄位是實測；Firecrawl 欄位則來自它公開文件。
| 面向 | Firecrawl（依其文件） | Docling（本文實測） |
|---|---|---|
| 核心工作 | 爬取 + 擷取即時網頁 → Markdown | 將你已擁有的文件 → Markdown/JSON |
| 抓取 / JS 渲染 / 反爬 | 有（託管瀏覽器） | 沒有——你要自己提供檔案 |
| 主內容抽取 | 有 | 沒有——忠實輸出整份文件（Wikipedia 約 13% 為外殼雜訊） |
| PDF 表格結構（ML） | 有限 | 有——TableFormer（官方 TEDS 93.6；本文 fixtures 上 cell recall 1.00、in-row 0.97–1.00） |
| 掃描 PDF / OCR | 有限 | 有——預設 RapidOCR（可還原 0 文字層掃描檔） |
| 格式廣度 | 網頁 | PDF/DOCX/PPTX/XLSX/HTML/EPUB/圖片 |
| 部署方式 | 託管 API（+ 可自架） | 本機 pip 函式庫、離線可用、無需 API key |
| 安裝成本 | API key / 輕量 client | 預設安裝 1.3 GB + 約 506 MiB 模型（或 docling-slim） |
| 授權 | 商業 / source-available | MIT |
一句話版本：如果你的資料在即時網路上，而且需要爬取、JS 渲染與主內容清理，那就用 Firecrawl。若你已經拿到文件——尤其是 PDF、掃描檔與表格很多的 Office 檔——而你要的是忠實、離線、保留結構的轉換，還要真的懂表格和 OCR，那就用 Docling。兩者是互補的。現實中的 pipeline，常常是一個負責爬取，另一個負責轉文件。
說到這裡，我也直接講清楚 Thunderbit 的位置，因為我人在這裡工作，如果假裝完全客觀，反而更可疑。Thunderbit 和 Docling 做的不是同一件事，我不會硬把它們說成等價。對開發者來說，Thunderbit 是 AI scraping API + MCP server + CLI，它處理的單位是即時網頁：POST /distill 會把 URL 轉成乾淨、可供 LLM 使用的 Markdown（處理 JS 渲染、反爬與 CAPTCHA，這些都是 Docling 明確不碰的），而 POST /extract 則會透過你定義的 JSON Schema 回傳符合結構的 JSON。這是 RAG pipeline 中「抓取並清理」的那一端。Docling 則是本機文件端——PDF、掃描檔、以及你硬碟裡已經存在的試算表。如果你的語料是網頁，請用 Thunderbit 的 API、MCP 工具（thunderbit_suggest_fields、thunderbit_distill、thunderbit_extract）或 CLI（npx @thunderbit/thunderbit-cli）。如果是 PDF 和掃描檔，請用 Docling。如果兩者都有——這其實是大多數真實 pipeline 的情況——那就兩個一起用，彼此都不是要模仿對方。
結論：先給暫定判斷，後面還有功課
我不會直接給你一個 0–100 的單一分數，因為在這裡做加權總分，會把 Docling 從來沒宣稱要做的事（例如爬取）也算進去，假裝它們能互比。分項來看，這些是我測試 fixtures 上的結果：
- 安裝 / 第一次執行： 很重——1.3 GB 虛擬環境、約 506 MiB 模型、第一次 PDF 約 224 秒、warm run 約 0.55 秒——但
docling-slim提供了避開重量包的選項。 - 表格還原度： 當表格有被偵測到時表現很強（5/5 的 cell recall 都是 1.00，in-row 介於 0.97–1.00），和官方 TEDS 的說法一致。
- 表格偵測穩定性： 稀疏頁面陷阱很明顯——孤立表格可能會被當成 Picture 丟掉。請在轉完後檢查
doc.tables。 - 掃描檔 / OCR： 可以用，預設是 RapidOCR；但大規模時速度偏慢。
- 多格式： 表現穩定，JSON round-trip 也能保留內容。
- HTML： 忠實，但不乾淨——不會自動抽主內容。
- 開發體驗： API 乾淨，
DoclingDocument也很整齊，但少了__version__。
適合誰：在 PDF、掃描檔與 Office 檔上建立 RAG 或資料管線，且希望離線、保留結構，並真正理解表格與 OCR 的團隊。不適合誰：需要即時網頁爬取或乾淨主文章 HTML 抽取的人——那是不同的工具。
而且因為這是評測，不是新聞稿，所以限制條件我也會老實標在前面。這是一個針對性的探測——7 個合成表格加上 2 份真實 PDF，只在一台僅 CPU 的機器上測——不是 TEDS 級的大型精度 benchmark。還有幾件我沒測，但你在把管線賭在 Docling 上之前應該先測：可選的 VLM（GraniteDocling）路徑、docling-slim 的實際體積、GPU 執行、複雜與不規則合併儲存格加上跨頁表格、公式轉 LaTeX 的保真度，以及——最可能在生產環境讓你意外的——批次記憶體成長、thread/GIL 擴展性，以及跨數千次轉換時物件生命週期的穩定性。Docling 在它聲稱的領域裡很強，這是經過量測而不是行銷包裝的結果，但它也有真正的邊界，正式採用前你最好先把它們摸清楚。了解稀疏頁面 caveat、預留首次下載成本，並親自驗證大規模表現。
試用 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
Docling 是網頁爬蟲或爬網工具嗎？ 不是。Docling 是把你已經擁有的文件——PDF、DOCX、PPTX、XLSX、HTML、圖片——轉成 Markdown 或 JSON。它不會抓 URL、不會渲染 JavaScript，也不會處理反爬機制。抓取即時網路是像 Firecrawl 或 Thunderbit 網頁 API 這類工具的工作；Docling 是從你提供的檔案開始。
Docling 安裝後有多大？第一次執行又會下載多少？
預設的 docling metapackage 會讓虛擬環境大約達到 1.3 GB，因為它把完整 ML 堆疊當作硬依賴一起裝進去（光是 torch 就有 536 MiB）。第一次 PDF 轉換時，會再下載約 506 MiB 的 layout 與 TableFormer 模型到磁碟，外加約 40 MB 的 RapidOCR 權重，而且大約要 224 秒——幾乎都花在下載。第二次轉換約 0.55 秒。如果你只需要輕量格式，docling-slim（核心約 50 MB）可以避開重型路徑。
Docling 會做 OCR 嗎？用的是哪個引擎？ 會。對沒有文字層的掃描 PDF，Docling 的 OCR 會自動啟動，而我測試時也成功乾淨地還原文字。預設引擎是 RapidOCR，不是 EasyOCR——這是舊文章很常寫錯的地方。EasyOCR 現在只是可選的額外套件。OCR 在大規模情境下會是慢路徑，尤其是在 CPU 上。
為什麼 Docling 把我的表格變成圖片，或直接丟掉？
最可能的原因是稀疏頁面效應。Docling 的 RT-DETR 版面模型會看頁面上下文，小表格如果單獨放在幾乎空白的頁面上，可能會被判成 Picture，然後沒有任何錯誤地被丟掉。只要同一張表周圍加上正文，就能正常轉出。解法是給版面模型更多頁面上下文，或是在轉換後檢查 doc.tables，把表格數量為零的頁面標記出來。
Docling 跟 Firecrawl，該選哪個？ 這兩個做的是不同工作，所以通常不是二選一。Firecrawl 負責爬即時網路、渲染 JavaScript，並擷取主內容。Docling 負責把你手上的文件轉出來，且對 PDF 表格結構與 OCR 有真正的理解，而且完全離線。如果你的來源是網頁，就用網頁工具（Firecrawl，或 Thunderbit 的 API/MCP/CLI）。如果是 PDF、掃描檔或 Office 檔，就用 Docling。大多數真實 pipeline 兩個都會用。
