
社群是國內外知名的機器學習與自然語言處理社群,受眾覆蓋國內外NLP碩博生、高校老師以及企業研究人員。
越來越多人發現,完整 AGI 的構建之路有一個離不開的基石:文件處理
前段時間,DeepSeek-V3 的釋出在國內外掀起一波盛讚,很多朋友都在討論如何將其用於深度企業級搜尋、Agent 開發和 RAG(Retrieval Augmented Generation)等場景。

筆者自然也想好好體驗一把,但在實際測試中,我會發現,“文件處理” 是擺在我眼前的一道坎:
為什麼文件處理如此重要?
在構建 Agent/RAG/LLM 應用的過程中,我們往往會面臨以下痛點:
-
文件格式不統一企業內部、外部知識庫以及網際網路公開資料中,可能同時存在 PDF、DOCX、PPTX、掃描影像等多種格式。LLM 需要的是可以被統一解析、結構化後的文字或特定語義切分,而原始文件格式差異過大,直接傳給 LLM 識別往往得不到理想結果。
-
排版複雜 / 各種異常情況可能遇到雙欄、多欄排版;標題、頁首頁尾穿插;大量表格、公式、圖片;甚至整份文件都是掃描版圖片……如果沒有合適的文件解析工具,處理下來費時費力。
-
需求多樣,輸出格式不一在 Agent 或 RAG 系統中,有時候需要 Markdown 用作呈現給使用者;有時候需要 JSON 便於後端自動處理;或者還需要 CSV、XML 等。要想讓文件處理結果“隨取隨用”,就需要一個能靈活匯出多種結構化格式的解析工具。
-
對延遲和穩定性要求高不論是做即時問答、Agent 聊天還是批次構建知識庫,大家都很關心處理速度和穩定性。如果解析慢、或者報錯崩潰,就無法在實際生產環境中穩定落地。
以上這幾點組合在一起,就導致了一個尷尬的局面:如果文件的處理鏈路走不通,即便大模型本身能力再強,也難以在真實業務場景中充分發揮其價值。
就在這時,我發現 IBM 最新開源了一個文件解析神器——Docling,它僅需幾行程式碼,就可以將各類文件都轉換為 JSON/Markdown,釋出至今已經狂攬 16.8k 星!
這意味著,我們可以在一個管道里搞定所有格式的文件處理,然後再將結果餵給大模型進行各種問答、聊天、Agent 流程、RAG 等應用。

論文地址:
https://arxiv.org/pdf/2408.09869
開源專案:
https://github.com/DS4SD/docling
Docling 的五大特點
-
多格式支援:無需為 PDF、DOCX、PPTX、圖片等多種格式分別找工具,一個 Docling 統統搞定。
-
OCR 能力:針對掃描件也能精準提取文字,真正做到不遺漏任何重要資訊。
-
頁面佈局/表格還原:可保留原文的排版資訊、閱讀順序、表格行列結構,減少後續人工清洗的負擔。
-
可與 LLM 整合:結合 LlamaIndex、LangChain 這類工具,能輕鬆實現自動問答、檢索增強生成(RAG)等功能。
-
簡單易用:Python 程式碼或 CLI 命令列,批次處理、單檔案處理都能一鍵完成。
其中,docling 針對 pdf 有專門的處理邏輯:

Docling 的管道原理與核心流程
官方技術報告中介紹,Docling 整個處理流程大致分為以下階段:
-
PDF/DOCX/PPT 等後端解析
-
對於 PDF:可選擇他們自研的給予 qpdf 的 docling-parse 後端或者開源框架 pypdfium,也可以根據需要渲染 bitmap 影像,用於 OCR 視覺模型。
-
對於 DOCX/PPTX 等:可轉換為標準化後的段落、影像元素、表格單元格、版面座標等中間物件然後統一處理。
-
AI 模型推斷
-
佈局分析模型:識別段落、標題、列表、圖片、表格等區塊。
-
表格結構模型:對檢測出的表格進行更細化的行列、單元格識別。
-
OCR 引擎(可選):對掃描的頁面進行文字識別。
-
後處理 & 組裝
-
校正閱讀順序、匹配圖片與標題、識別文件語言、補充元資料等。
-
最終組裝得到可序列化的文件物件,支援 JSON、Markdown 等多種匯出方式。
簡而言之,Docling 在“文件格式 → 可用資料結構”的過程中做了大量底層工作,把文字、圖片、表格都重新“拆裝”了一遍。
同時,docling 可以透過簡單幾行程式碼就完成整個文件的處理,有超高的易用性。
比如,假設我們需要處理一個 pdf,只需要下面幾行程式碼:
from
docling.document_converter
import
DocumentConverter
# PDF 檔案可來自本地路徑,也可直接是 URL
source =
"https://arxiv.org/pdf/2408.09869"
converter = DocumentConverter()
result = converter.convert(source)
# 輸出文件的 Markdown 格式
print(result.document.export_to_markdown())
# 也可以這樣輸出 JSON
import
json
doc_json = json.dumps(result.document.export_to_dict(), indent=
4
)
print(doc_json)
那麼,實際效果如何呢,讓我來給它上上強度!
docling 解析效果實測
這裡以更通用的 markdown 格式為例。
單列排版

解析結果:

去掉了頁首頁尾,除了標題被拆分為兩行以外,整體文字識別都正確,還不錯!
單列排版 + 表格:

解析結果:

除了兩個年份識別為文字,其他都沒問題,有點小瑕疵,但是整體解析正確,這一關也算過 ~
雙列排版 + 表格:

解析結果:

除了表格的位置有點問題,表格的格式還原的完全正確,整體文字順序也是對的,還不賴!
單雙列混合排版 + 表格

解析結果:

這裡它就沒有成功識別出下半部分是雙列了,不過表格識別的還是非常準確
透過本文的簡單測評來看,它雖然帶有一些小瑕疵,在單雙列複雜情況下沒有成功還原閱讀順序,但是表格還原度非常高,可以適用於絕大部分場景了!
穩定性與延遲
在構建 Agent/RAG 系統時,處理速度與穩定性是大家非常關心的指標。特別是有些文件動輒上百頁,或者需要大量同時處理。Docling 官方報告給出了在 225 頁測試集上的效能資料(包括多執行緒與不同 PDF 解析後端):

其中:
-
TTS 是總處理時長(Time to Solution),涵蓋解析、模型推理、組裝等所有流程;
-
單執行緒速度更慢,多執行緒能顯著提升吞吐量;
-
pypdfium 作為備用後端速度更快,記憶體更低,但在表格處理方面精度可能略遜;
-
OCR 功能 預設關閉,若開啟,每頁會根據 OCR 模型和硬體效能提升處理時間。
穩定性與延遲實測
這裡選了一長一短兩個 pdf 簡單測試一下它的提取速度。
測試環境:1xL20
測試條件:單執行緒

可以發現,如果 pdf 是非掃描件,不開啟 OCR 會極大的提升解析速度,而如果這裡使用了 OCR 模型,整體速度都會出現嚴重的下降。
具體如何選擇,需要結合 pdf 的複雜程度和解析效果來判斷。
結語
不知不覺間,markdown/json 格式似乎已經成為了 AGI 時代的“新基建”。
各種各樣的文件經過解析工具快速提取並結構化輸出為這兩種格式後,給各類 Agent/RAG 框架提供穩定的原始文字輸入。
Docling 不僅具備多格式解析能力,且對版面和表格都有較高還原度,還能透過多執行緒或 GPU 加速來應對大批次處理場景,加上 MIT 許可開源,不失為大家解析文件的一個好選擇。

掃描二維碼新增小助手微信
關於我們
