Select Page

企業知識庫和 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 使用。