Docling 是什麼？PDF 轉 Markdown、OCR 與 VLM 文件解析實戰

by Rain Chu | 7 月 11, 2026 | Tool

企業知識庫和 AI Agent 最麻煩的地方，常常不是模型不夠聰明，而是資料進不來。PDF、掃描合約、研究報告、表格、圖片型文件，看起來都只是文件，但對 RAG 或 Agent 來說，它們必須先被轉成穩定、乾淨、可引用的結構化內容。

Docling 就是在解這個入口問題。它不是只把 PDF 拆成純文字，而是把文件版面、閱讀順序、表格、公式、圖片、OCR 結果整理成 AI 更容易消化的格式，例如 Markdown、HTML、JSON。對要做企業知識庫的人來說，這一層通常比後面換哪一個聊天模型更關鍵。

Docling 適合解決什麼問題

Docling 是 IBM Research Zurich 發起的開源專案，採用 MIT License。它支援 PDF、DOCX、PPTX、XLSX、HTML、EPUB、圖片與音訊等格式，官方也強調它能和 LangChain、LlamaIndex、CrewAI、Haystack 這類生成式 AI 工具鏈整合。

如果只是把少量文件轉成 Markdown，微軟的 MarkItDown 會很輕巧，之前我也整理過 MarkItDown 教學，但 Docling 的定位更偏向文件理解管線，尤其是 PDF 版面、表格、掃描文件、VLM 輔助解析這些較複雜的場景。

最基本的使用方式

Docling 的入門方式很直接，Python 環境建好後先安裝依賴：

pip install litellm google-generativeai docling

最小 Python 範例可以用 DocumentConverter 讀取 PDF，再輸出 Markdown：

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"
converter = DocumentConverter()
result = converter.convert(source)

markdown_text = result.document.export_to_markdown()
print(markdown_text)

也可以用命令列直接轉檔：

docling https://arxiv.org/pdf/2408.09869

這種方式很適合處理數位原生 PDF，例如論文、報告、產品文件。它能保留標題層級、段落、表格與部分版面資訊，後續要切 chunk、做向量化、放進 RAG 都比較順。

掃描 PDF 要接 VLM 才會真正好用

企業場景裡最痛的通常是掃描件。掃描合約、舊報紙、模糊文件、影印後再掃描的 PDF，傳統 OCR 很容易漏字、錯行、表格亂掉，Docling 的強項之一，是可以把解析流程接到視覺語言模型，讓 VLM 協助理解頁面。

本地部署路線可以用 LM Studio 載入 InternVL3-9B，讓 Docling 透過 OpenAI 相容 API 呼叫本機模型，這個做法的優點是資料不必送到外部雲端，適合公司內部文件、客戶資料、合約與敏感文件。缺點是需要顯卡資源，也要接受本地模型在模糊文字上的上限。

如果追求辨識品質，Gemini 2.5 Pro 這類雲端 VLM 的效果通常會更穩，尤其是模糊掃描、複雜版面、引用格式、符號與表情符號。代價就是 API 成本、資料外送與權限控管，真正落地時，我會把它分成兩條管線：一般文件走本地模型，低信心或高價值文件再送雲端模型複核。

一個實用的企業知識庫流程

1. 先把 PDF、Word、Excel、HTML、圖片掃描件集中到同一個資料夾或物件儲存。
2. 用 Docling 轉成 Markdown 或 JSON，保留頁碼、標題、表格與圖片資訊。
3. 針對掃描件啟用 OCR 或 VLM 管線，低品質文件可以標記信心分數。
4. 清理內容，移除頁首頁尾、重複頁碼、錯誤斷行，再依標題與段落切 chunk。
5. 把 chunk 放入向量資料庫，同時保存原始頁面來源，方便回答時回溯引用。
6. 接到 RAG、Agent 或 Notebook 型工具，讓使用者可以查詢、摘要、比對文件。

之前整理過 GraphRAG 使用本地端的 Ollama，或是 Open Notebook 這類私有研究工作流，前面都需要穩定的文件解析層。Docling 可以放在最前端，負責把混亂文件變成 AI 能讀的乾淨材料。

LM Studio、InternVL3、Gemini 怎麼選

如果資料敏感，先選 LM Studio 加 InternVL3。這種配置比較像私有 OCR 與文件理解服務，可以在內網跑，也能和既有 Python 管線整合。若你已經在評估 Qwen 或其他本地模型，也可以參考 Ollama Qwen 3.6 怎麼選 和 本地端多模態分析實戰 的思路。

如果文件很雜、品質很差、需要快速拿到高準確度結果，Gemini 2.5 Pro 會比較省心。尤其是頁面裡有表格、引用、符號、圖片文字混在一起時，雲端 VLM 的容錯能力會更好。我的建議不是二選一，而是分層使用：本地模型做第一輪，難件再升級到雲端模型。

導入前要注意的坑

第一，Python 版本要注意，Docling 近期版本已經不支援 Python 3.9，建議直接用 Python 3.10 以上，專案環境也要隔離，避免和舊套件衝突。

第二，不要只看 Markdown 有沒有產生，真正要檢查的是段落順序、表格欄位、頁碼引用、公式、圖片說明、錯字率。只要這些地方亂掉，後面的 RAG 回答就會變得不可信。

第三，VLM 不是魔法，模糊掃描、歪斜頁面、低解析度照片仍然會出錯。比較穩的做法是保存原始頁面圖、解析後文字、模型信心與人工校對狀態，讓知識庫能追蹤每一段內容從哪裡來。

結論

Docling 值得放進 AI 知識庫工具箱，原因不是它可以把 PDF 轉 Markdown 這麼簡單，而是它把文件解析變成一條可組合的管線。一般文件用基礎轉換，掃描件加 OCR，高難度文件再接 VLM，最後輸出成 RAG 可以使用的 Markdown 或 JSON。

如果你的資料來源大多是網頁和乾淨文字，Docling 不一定是第一個要上的工具。但只要公司文件裡有大量 PDF、掃描件、表格、舊報告，它就是很值得測的入口層。AI 系統的回答品質，很多時候從文件被讀進來的那一刻就決定了。

FAQ

Docling 和 MarkItDown 差在哪裡？

MarkItDown 很適合快速把常見文件轉成 Markdown。Docling 更偏向完整文件理解，強調 PDF 版面、表格結構、OCR、VLM 和 AI 工具鏈整合。

一定要用 Gemini 才能處理掃描 PDF 嗎？

不一定。本地可以用 LM Studio 搭配 InternVL3 這類視覺模型。Gemini 的優勢是複雜文件辨識品質通常更好，但需要考慮 API 成本和資料外送。

Docling 適合企業內部知識庫嗎？

很適合，特別是資料來源包含 PDF、掃描件、簡報、表格和舊文件時。它可以把文件轉成 AI 較容易處理的格式，再交給 RAG 或 Agent 使用。