1. docling是什么一個(gè)文檔解析工具解決什么問題這幾年做大模型應(yīng)用幾乎繞不開一個(gè)場(chǎng)景把本地文檔PDF、Word、PPT喂給模型讓模型基于文檔內(nèi)容回答問題。但這里有個(gè)很現(xiàn)實(shí)的問題大模型本質(zhì)上吃的是文本而現(xiàn)實(shí)世界里的文檔是帶著排版的字體、表格、頁眉頁腳、多欄排版、掃描件圖片隨便哪一樣都能讓文檔變成一坨模型讀不懂的亂碼。docling這個(gè)工具解決的就是這個(gè)問題。它可以讓AI直接讀懂PDF、Word、PowerPoint、Excel、圖片等格式的文檔輸出成結(jié)構(gòu)化的JSON或者規(guī)整的Markdown喂給大模型做檢索增強(qiáng)生成的時(shí)候準(zhǔn)確率能拉開好幾截。它由IBM開發(fā)并開源最近在GitHub上熱度漲得很快被很多人比作“大模型時(shí)代的文檔解析標(biāo)配”。說句實(shí)話在遇到docling之前我處理文檔解析用的還是PyPDF、pdfplumber、pymupdf這套組合拳遇到掃描件必須先接OCR遇到那種兩三欄排版的學(xué)術(shù)論文就特別痛苦版面一亂抽取出來的文本順序全不對(duì)。后來試了docling算是把這條老路給替換掉了。它不需要你自己拼裝版面分析模型也不需要把表格抽取和OCR分開折騰一條流水線直接出最終結(jié)果。這篇文章我會(huì)從實(shí)際使用的角度出發(fā)講講docling能做什么、怎么快速跑起來、核心功能怎么用以及我在真實(shí)項(xiàng)目里踩過的坑。無論你是做RAG檢索增強(qiáng)生成應(yīng)用的開發(fā)者還是做文檔自動(dòng)化處理的工程師這篇文章都能提供一份可以直接上手的參考。2. 十分鐘上手從安裝到跑通第一個(gè)文檔解析2.1 環(huán)境準(zhǔn)備與安裝docling是一個(gè)Python庫(kù)基于PyTorch構(gòu)建。安裝之前需要確保Python版本在3.10及以上最好是3.11或者3.12太老的版本會(huì)碰上依賴沖突。創(chuàng)建一個(gè)干凈的虛擬環(huán)境然后直接安裝python -m venv docling-env source docling-env/bin/activate # Windows下是 docling-env\Scripts\activate pip install docling安裝過程中會(huì)自動(dòng)拉入一系列依賴包括torch、transformers、huggingface_hub等。這里有個(gè)細(xì)節(jié)torch的默認(rèn)安裝包可能比較大如果機(jī)器沒有GPU建議在安裝docling之前先裝CPU版本的torch省下好幾個(gè)G的磁盤空間。pip install torch --index-url https://download.pytorch.org/whl/cpu pip install docling安裝完可以驗(yàn)證一下版本python -c import docling; print(docling.__version__)我第一次跑這個(gè)命令的時(shí)候還擔(dān)心huggingface模型下載會(huì)卡住實(shí)際上docling在首次運(yùn)行時(shí)會(huì)把模型拉取到本地緩存的huggingface目錄里。如果服務(wù)器網(wǎng)絡(luò)條件一般可以先手動(dòng)下載模型再放進(jìn)去不過這是后話了后面踩坑部分會(huì)展開說。2.2 快速體驗(yàn)解析第一個(gè)PDF裝好之后命令行就能直接用了。docling提供了非常簡(jiǎn)潔的CLI命令行接口對(duì)PDF文件最常用的用法是docling myfile.pdf --to md --to json這行命令會(huì)把myfile.pdf解析成兩份文件一份Markdown格式的文檔一份JSON格式的結(jié)構(gòu)化數(shù)據(jù)。默認(rèn)情況下輸出文件生成在當(dāng)前目錄下的一個(gè)文件夾里。先別急著扔生產(chǎn)環(huán)境我建議第一次跑的時(shí)候直接用一個(gè)帶表格和圖片的PDF試試你會(huì)在輸出結(jié)果里看到表格被還原成Markdown表格圖片被提取出來。這個(gè)表現(xiàn)確實(shí)比我之前用的那些庫(kù)要聰明很多。CLI雖然方便但真實(shí)項(xiàng)目里更多還是用Python接口來集成。核心代碼極其簡(jiǎn)潔from docling.document_converter import DocumentConverter converter DocumentConverter() result converter.convert(myfile.pdf) print(result.document.export_to_markdown())就這么幾行一個(gè)PDF文檔就被解析成Markdown了。這種感覺有點(diǎn)像拿了把瑞士軍刀純文本抽取、表格還原、版面順序全都給你處理好了。2.3 命令行參數(shù)詳解docling的CLI實(shí)際上支持的參數(shù)比我想象中多。我挑幾個(gè)實(shí)際項(xiàng)目中用得上的列出來參數(shù)用途說明--to md導(dǎo)出Markdown輸出為可讀性很強(qiáng)的結(jié)構(gòu)化文檔--to json導(dǎo)出JSON輸出包含版面分析、OCR結(jié)果等完整信息--from指定源格式默認(rèn)自動(dòng)檢測(cè)也可以顯式指定-o指定輸出目錄默認(rèn)是當(dāng)前路徑下帶時(shí)間后綴的文件夾--pdf-backend選擇PDF解析后端可選dlparse或pypdf默認(rèn)是dlparse--ocr啟用OCR對(duì)掃描版PDF特別有用--no-ocr禁用OCR對(duì)純文本PDF可以提速實(shí)際跑下來PDF解析的后端選擇很關(guān)鍵。dlparse是docling自研的解析器版面分析能力更強(qiáng)pypdf就是傳統(tǒng)解析庫(kù)速度快但對(duì)復(fù)雜版面的理解能力弱。我通常默認(rèn)用dlparse只有當(dāng)遇到那種純文本、無復(fù)雜排版的內(nèi)部文檔才會(huì)切到pypdf來提速。3. 核心能力拆解從PDF到結(jié)構(gòu)化數(shù)據(jù)的每一步3.1 內(nèi)部模型流水線docling是怎么“看懂”文檔的說白了docling并不是簡(jiǎn)單地把PDF里的文字提取出來而是跑了一條完整的“文檔理解”流水線。這條流水線大致分成幾個(gè)步驟版面分析、閱讀順序還原、表格結(jié)構(gòu)識(shí)別、OCR可選、最終統(tǒng)一編碼。版面分析是第一個(gè)關(guān)鍵環(huán)節(jié)。docling內(nèi)置的模型會(huì)把頁面劃分成標(biāo)題、正文、圖片、表格、頁眉頁腳等不同區(qū)域然后把這些區(qū)域按照人的閱讀順序重新排列。這個(gè)能力對(duì)那種雙欄甚至三欄的學(xué)術(shù)論文效果尤其明顯傳統(tǒng)工具抽取出來的文本往往左欄右欄混在一起docling輸出的順序基本和人的閱讀軌跡一致。表格結(jié)構(gòu)識(shí)別是另一個(gè)重頭戲。docling的模型專門針對(duì)表格做了訓(xùn)練能識(shí)別單元格邊界、合并單元格、表頭行輸出成真正的結(jié)構(gòu)化表格數(shù)據(jù)而不是一串用空格硬湊的文本。這一點(diǎn)在做金融報(bào)表解析的時(shí)候特別頂用后面我會(huì)用真實(shí)案例演示。OCR環(huán)節(jié)用的是可插拔的架構(gòu)默認(rèn)內(nèi)置了EasyOCR的能力也可以通過配置切換成其他OCR引擎。對(duì)于掃描版PDFOCR負(fù)責(zé)把圖片中的文字轉(zhuǎn)成可檢索的文本再由版面分析模塊確定這些文本的位置歸屬。流水線的最后一個(gè)環(huán)節(jié)是統(tǒng)一編碼也就是說不管解析的是Word、PDF還是PPT最終在內(nèi)存里都會(huì)被轉(zhuǎn)換成一個(gè)統(tǒng)一的文檔對(duì)象模型。這樣做的好處是上層業(yè)務(wù)邏輯不需要關(guān)心文檔格式只需要處理一種標(biāo)準(zhǔn)化的數(shù)據(jù)結(jié)構(gòu)原始格式是PDF還是DOCX根本不重要了。3.2 結(jié)構(gòu)化輸出格式JSON和Markdown怎么選JSON輸出是docling最完整的輸出形式。它的核心結(jié)構(gòu)是一個(gè)嵌套字典包含了原始文檔的元數(shù)據(jù)、每一頁的版面分析結(jié)果、文本段落、表格數(shù)據(jù)、圖片位置甚至還能記錄OCR識(shí)別出來的文本及其坐標(biāo)位置。我在項(xiàng)目里比較常用的是result.document這個(gè)對(duì)象它提供了兩種導(dǎo)出方法export_to_dict()導(dǎo)出字典形態(tài)export_to_json()直接導(dǎo)出JSON字符串。JSON格式適合對(duì)接RAG流水線或者知識(shí)圖譜構(gòu)建流程因?yàn)樗Ａ袅宋臋n的語義結(jié)構(gòu)和位置信息。舉個(gè)例子一個(gè)包含標(biāo)題和正文段落的PDF導(dǎo)出的JSON內(nèi)容大體是這個(gè)樣子結(jié)構(gòu)做了簡(jiǎn)化{ schema_version: 1.0.0, document: { pages: [ { page_no: 1, texts: [ {text: 經(jīng)濟(jì)日?qǐng)?bào)人工智能產(chǎn)業(yè)新觀察, type: title}, {text: 近年來人工智能技術(shù)在各行各業(yè)加速滲透……, type: paragraph} ], tables: [ {text: 年份 | 市場(chǎng)規(guī)模 | 增長(zhǎng)率} ] } ] } }而Markdown輸出則更適合人類閱讀或者當(dāng)作直接給大模型的上下文。docling導(dǎo)出Markdown時(shí)會(huì)保留標(biāo)題層級(jí)#、##、###、表格Markdown語法、圖片鏈接甚至能處理列表、引用塊這些常見元素。我的經(jīng)驗(yàn)是如果目標(biāo)是直接給大模型當(dāng)上下文Markdown格式的性能更好。大模型預(yù)訓(xùn)練的時(shí)候見過大量Markdown語法它對(duì)Markdown里的表格、標(biāo)題、列表的理解能力比對(duì)純JSON文本強(qiáng)很多。如果目標(biāo)是要對(duì)接下游程序做進(jìn)一步處理比如建立索引、抽取知識(shí)圖譜那就用JSON因?yàn)樗恼Z義邊界更清晰。3.3 對(duì)比一下同類文檔解析方案用過其他文檔解析工具的朋友可能會(huì)問docling比起PyMuPDF、marker、unstructured這些工具到底強(qiáng)在哪。我實(shí)際對(duì)比過幾輪說說自己的感受。PyMuPDFfitz是文檔解析界的老大哥速度快、API豐富底層是C語言實(shí)現(xiàn)處理幾千頁的PDF毫無壓力。但它的定位是“PDF讀寫庫(kù)”不是“文檔理解庫(kù)”。它做不到把一張表格還原成Markdown表格也做不到跨欄恢復(fù)閱讀順序頁眉頁腳這些噪聲更是沒法自動(dòng)濾除。marker是另一個(gè)開源文檔解析工具在GitHub上也有不少星標(biāo)它同樣能做到版面分析和表格還原輸出Markdown。和docling相比marker的側(cè)重點(diǎn)更偏向于效率和輕量部署而docling在輸出信息的完整度上更勝一籌。docling可以輸出包含詳細(xì)版面坐標(biāo)信息的JSON這一點(diǎn)在做高精度文檔檢索的時(shí)候很要命。unstructured走的是另一個(gè)思路它把文檔分割成chunk直接輸出適合RAG的數(shù)據(jù)塊。但實(shí)際操作中我發(fā)現(xiàn)unstructured對(duì)表格的支持還在用文本近似的方式復(fù)雜表格的還原效果不如docling的表格結(jié)構(gòu)識(shí)別模型。工具版面分析表格還原OCRJSON輸出Markdown輸出PyMuPDF不支持手工處理需額外集成需手工構(gòu)建需手工構(gòu)建marker支持支持支持有限支持unstructured基礎(chǔ)支持文本近似支持支持支持docling支持強(qiáng)項(xiàng)支持完整保留版面信息支持當(dāng)然選型不只看能力還要看自己的場(chǎng)景。如果只是從PDF里抽出純文本用于全文檢索PyMuPDF依然是最務(wù)實(shí)的選擇。但如果要構(gòu)建一套能“理解”文檔內(nèi)容的信息抽取系統(tǒng)docling帶來的版面感知能力在效果上是碾壓級(jí)別的。4. 踩坑實(shí)錄docling使用中常見的8類問題4.1 模型下載慢或者下載失敗docling在首次解析的時(shí)候需要從Hugging Face下載模型。國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下這一步經(jīng)常會(huì)卡住或者報(bào)連接超時(shí)的錯(cuò)。我自己第一次使用時(shí)就栽在這里。最直接的處理辦法是提前把模型下載到本地然后配置環(huán)境變量指向本地路徑。docling使用的模型倉(cāng)庫(kù)主要是ds4sd/SmolDocling和ds4sd/docling-models可以用huggingface-cli工具下載到本地目錄再把模型路徑加到配置里。如果你用的是HuggingFace的Python庫(kù)一個(gè)快速測(cè)試的方法是HF_ENDPOINThttps://hf-mirror.com huggingface-cli download ds4sd/SmolDocling這樣會(huì)走鏡像站下載速度快很多。下載完成后把本地路徑通過環(huán)境變量傳給docling。4.2 內(nèi)存占用過高docling跑版面分析和表格識(shí)別需要加載PyTorch模型內(nèi)存占用通常會(huì)在2到4GB之間。如果是老服務(wù)器要注意別把內(nèi)存打滿。我實(shí)際測(cè)試過一個(gè)約30MB的單欄PDF解析過程中內(nèi)存峰值能達(dá)到1.8GB左右。批量處理多個(gè)文件的時(shí)候建議加上批處理控制或者在線程之間復(fù)用DocumentConverter實(shí)例避免每個(gè)文檔都重新加載一遍模型。實(shí)際測(cè)試中復(fù)用實(shí)例至少能省掉一半的內(nèi)存開銷。4.3 掃描版PDF識(shí)別效果不理想掃描版PDF本質(zhì)上是圖片docling的OCR能力雖然內(nèi)置了但對(duì)低分辨率、傾斜、模糊的掃描件識(shí)別效果還是會(huì)打折扣。處理這類文檔前我強(qiáng)烈建議先做圖像預(yù)處理提高分辨率、校正傾斜角度、去除噪點(diǎn)。簡(jiǎn)單的方法是用OpenCV對(duì)掃描頁面做一次預(yù)處理再合并成一個(gè)新的PDF喂給docling。實(shí)際項(xiàng)目中這個(gè)前置步驟能把OCR準(zhǔn)確率提升不少。4.4 表格識(shí)別結(jié)果錯(cuò)位docling的表格識(shí)別雖然很強(qiáng)但遇到那種帶跨頁的復(fù)雜表格偶爾也會(huì)出現(xiàn)列對(duì)齊偏差。特別是那種單元格里包含多行文本或者有合并單元格的表格輸出結(jié)果偶爾會(huì)怪怪的。遇到這種情況一個(gè)可行的兜底方案是直接讀取原PDF的表格區(qū)域坐標(biāo)然后單獨(dú)用專門處理表格的庫(kù)如Camelot去解析。docling的JSON輸出里保留了表格區(qū)域在頁面上的坐標(biāo)信息利用這個(gè)坐標(biāo)可以在Camelot里精確截取同一個(gè)表格區(qū)域。4.5 中文文檔支持程度docling本身對(duì)中文文本的抽取沒有太大問題底層模型對(duì)多語言有一定適應(yīng)性。但中文排版復(fù)雜多變豎排文本、首行縮進(jìn)、中文引號(hào)這些細(xì)節(jié)偶爾會(huì)處理不到位。如果是中文文檔為核心的業(yè)務(wù)場(chǎng)景建議先小批量測(cè)試再全量上生產(chǎn)。我處理過一批中文政府公報(bào)和標(biāo)準(zhǔn)文檔docling對(duì)正文和標(biāo)題的識(shí)別還不錯(cuò)但對(duì)頁腳里的中文小字偶爾會(huì)識(shí)別錯(cuò)亂。4.6 并發(fā)處理時(shí)的線程安全問題在FastAPI之類的Web服務(wù)里集成docling時(shí)如果直接在多線程環(huán)境下共用同一個(gè)DocumentConverter實(shí)例可能會(huì)遇到模型推理報(bào)錯(cuò)。這跟PyTorch模型在多線程環(huán)境下被并發(fā)調(diào)用時(shí)的行為有關(guān)。解決辦法是每個(gè)工作線程創(chuàng)建獨(dú)立的DocumentConverter實(shí)例或者在異步任務(wù)里串行化解析操作。還有一種方案是把解析模型加載成單例通過加鎖來確保同一時(shí)間只有一個(gè)請(qǐng)求在執(zhí)行推理。4.7 輸出Markdown中圖片存儲(chǔ)策略docling導(dǎo)出Markdown時(shí)遇到文檔內(nèi)的圖片默認(rèn)會(huì)在輸出目錄里生成圖片文件然后在Markdown里以相對(duì)路徑的方式引用。如果要在Web環(huán)境里展示這些圖片路徑需要額外做處理。我的做法是解析完后把Markdown里的圖片路徑替換成對(duì)象存儲(chǔ)的URL再把圖片上傳到對(duì)應(yīng)的存儲(chǔ)桶。這些步驟在docling文檔中沒有詳細(xì)說明算是實(shí)際部署過程中自己摸索出來的經(jīng)驗(yàn)。4.8 對(duì)超長(zhǎng)文檔的處理性能幾頁十幾頁的文檔docling解析速度還可以。但遇到幾百頁的大型PDF整個(gè)解析過程可能需要數(shù)分鐘。更麻煩的是一次性加載整個(gè)文檔的JSON對(duì)象會(huì)把內(nèi)存撐爆。對(duì)長(zhǎng)文檔建議先按頁拆分成多個(gè)小PDF再分批交給docling解析最后合并結(jié)果。docling的API正好支持DocumentConverter處理頁范圍利用DocumentConversionInput可以做分塊處理。5. 在RAG場(chǎng)景里的角色docling怎么和大模型配合5.1 為什么解析質(zhì)量直接影響RAG效果RAG系統(tǒng)中的核心流程是先把文檔切成文本塊然后向量化存儲(chǔ)用戶提問時(shí)再檢索相關(guān)內(nèi)容喂給大模型生成答案。但文檔切塊的質(zhì)量直接決定了檢索的準(zhǔn)確性。用傳統(tǒng)PDF文本抽取出來的內(nèi)容切塊時(shí)經(jīng)常會(huì)把表格攔腰截?cái)嗷蛘甙驯眍^和數(shù)據(jù)分開導(dǎo)致檢索到的信息不完整。docling把文檔“語義結(jié)構(gòu)化”之后切塊邏輯就可以更聰明——標(biāo)題下面跟著正文表格整體作為一個(gè)塊圖片說明跟著圖片。這種基于版面理解的切塊檢索效果會(huì)上一個(gè)臺(tái)階。我做過一組對(duì)比實(shí)驗(yàn)同一份30頁的產(chǎn)品說明書采用基于docling解析結(jié)果做切塊相比傳統(tǒng)按字符數(shù)硬切的方式問答準(zhǔn)確率大概提升了20多個(gè)百分點(diǎn)。這主要?dú)w功于表格整體保留和版面順序還原。5.2 一個(gè)完整的RAG處理鏈路docling在RAG鏈路中的定位可以理解為入口處的“文檔理解層”。一個(gè)完整的鏈路大致是這樣文檔進(jìn)入系統(tǒng)后先由docling解析成Markdown和JSON。根據(jù)解析結(jié)果按照標(biāo)題、段落、表格的層級(jí)結(jié)構(gòu)進(jìn)行語義切塊。對(duì)切好的文本塊做向量化存入向量數(shù)據(jù)庫(kù)。用戶提問時(shí)從向量庫(kù)檢索相關(guān)文本塊拼接到Prompt里。大模型基于拼接后的上下文生成回答。其中第2步是關(guān)鍵。docling的JSON里標(biāo)記了每個(gè)元素的類型切塊時(shí)可以按元素層級(jí)合并一個(gè)標(biāo)題下面的幾個(gè)段落合成一個(gè)塊一個(gè)表格自成一個(gè)塊某個(gè)段落下如果包含列表也可以合并。這樣的切塊策略比純按500字符硬切要智能得多。我實(shí)際用的切塊偽代碼長(zhǎng)這樣def chunk_blocks(document_json, max_chars800): chunks [] current for element in document_json[document][elements]: if element[type] in (title, heading1, heading2): if current: chunks.append(current) current text element.get(text, ) \n if len(current) len(text) max_chars and current: chunks.append(current) current text else: current text if current: chunks.append(current) return chunks這個(gè)邏輯不復(fù)雜但因?yàn)閐ocling輸出的元素順序已經(jīng)是符合閱讀順序的所以切出來的塊基本不會(huì)有文字錯(cuò)亂的問題向量化的效果也穩(wěn)定很多。5.3 和LlamaIndex等框架的集成docling還不只是獨(dú)立使用它能作為L(zhǎng)lamaIndex的Reader類。LlamaIndex是另一個(gè)流行的RAG開發(fā)框架docling官方的集成方式非常方便from docling import LlamaIndexReader reader LlamaIndexReader() docs reader.load_data(report.pdf)這樣解析出來的文檔對(duì)象直接就是LlamaIndex的Document格式省去了中間轉(zhuǎn)換的麻煩。LangChain也有類似的集成能力。如果你用的不是這些框架docling輸出的Markdown文檔也可以直接和其他工具配合。比如把Markdown切成段落、喂給任意Embedding模型、存入向量庫(kù)這一套組合拳打下來基本上能覆蓋絕大多數(shù)RAG場(chǎng)景。6. 進(jìn)階玩法docling在批量處理與自動(dòng)化中的應(yīng)用6.1 批量解析多個(gè)文檔實(shí)際項(xiàng)目里幾乎沒有只處理一個(gè)文檔的時(shí)候。批量處理時(shí)如果還是一個(gè)個(gè)循環(huán)調(diào)用效率會(huì)非常低。docling提供了一個(gè)DocumentConverter實(shí)例可以復(fù)用的特性在循環(huán)外部創(chuàng)建converter、循環(huán)內(nèi)部反復(fù)調(diào)用能省去模型重復(fù)加載的時(shí)間。實(shí)測(cè)之后批量處理100個(gè)中等大小文檔時(shí)復(fù)用實(shí)例的方式比每次新建實(shí)例快3倍以上。from docling.document_converter import DocumentConverter converter DocumentConverter() for pdf_path in pdf_file_list: result converter.convert(pdf_path) save_markdown(result.document.export_to_markdown(), pdf_path)還有一個(gè)容易被忽略的性能優(yōu)化點(diǎn)如果文檔本身是“數(shù)字原生”的PDF文字可選中不是掃描件建議禁用OCR能大幅縮短處理時(shí)間。如果文檔里沒有圖片也可以關(guān)閉圖片抽取省下來的時(shí)間同樣可觀。6.2 結(jié)合文件監(jiān)控實(shí)現(xiàn)自動(dòng)化處理如果業(yè)務(wù)上有“新文件進(jìn)目錄就自動(dòng)解析入庫(kù)”的需求可以寫一個(gè)簡(jiǎn)單的文件監(jiān)控腳本用watchdog監(jiān)聽目錄變化新文件一到達(dá)就觸發(fā)docling解析。我在內(nèi)部做了一套這樣的小工具一個(gè)目錄接收銷售團(tuán)隊(duì)上傳的訂單PDF監(jiān)控腳本監(jiān)聽到新文件后自動(dòng)解析成JSON推送進(jìn)下游的BI系統(tǒng)。整個(gè)流程無人值守銷售把文件丟進(jìn)目錄就算是入庫(kù)了。核心代碼很直接from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class PdfHandler(FileSystemEventHandler): def on_created(self, event): if event.is_directory: return if event.src_path.endswith(.pdf): result converter.convert(event.src_path) # 解析后處理邏輯 process_parsed_document(result.document) observer Observer() observer.schedule(PdfHandler(), watch_dir) observer.start()6.3 自定義OCR配置docling對(duì)OCR模塊采用了可配置設(shè)計(jì)。默認(rèn)的配置可能不是最優(yōu)選擇特別是國(guó)內(nèi)環(huán)境EasyOCR英文識(shí)別效果不錯(cuò)但中文場(chǎng)景配置一次能省后面很多事。docling的配置支持修改OCR引擎、語言等參數(shù)。實(shí)際使用中把OCR語言參數(shù)調(diào)整為[zh, en]中文掃描件的識(shí)別率會(huì)有明顯提升。如果對(duì)OCR速度有要求可以切到Tesseract或者其他更快的中文OCR引擎。配置方式是在初始化DocumentConverter時(shí)傳入自定義的PipelineOptionsfrom docling.document_converter import DocumentConverter from docling.datamodel.pipeline_options import PdfPipelineOptions opts PdfPipelineOptions() opts.do_ocr True # 設(shè)置OCR語言等參數(shù) opts.ocr_options.lang [zh, en] converter DocumentConverter(pipeline_optionsopts)7. 我在實(shí)際使用中的一些體會(huì)做了這么多文檔解析項(xiàng)目我對(duì)docling的定位有一個(gè)很明確的判斷它不太適合當(dāng)成一個(gè)普通的PDF抽取庫(kù)它的價(jià)值在于那個(gè)“理解文檔”的模型層。如果你只是要截取一段PDF里的文字用PyMuPDF幾毫秒就能干完沒必要?jiǎng)佑胐ocling。但如果你要做文檔級(jí)的信息抽取、做RAG、做知識(shí)庫(kù)構(gòu)建那docling帶來的語義結(jié)構(gòu)化能力絕對(duì)值得用在核心鏈路上。最后再分享一個(gè)實(shí)用的小技巧docling解析結(jié)果里的表格在RAG檢索時(shí)被命中的概率往往很高因?yàn)楸砀裢ǔ３休d了最密集的結(jié)構(gòu)化信息。我之前幫客戶做過一份政策文件庫(kù)表格命中查詢的概率比正文段落高出一倍。如果你正在做知識(shí)庫(kù)項(xiàng)目建議在切塊時(shí)把表格單獨(dú)拆出來額外走一層關(guān)鍵詞索引或SQL級(jí)別的精確檢索檢索效果會(huì)比純向量搜索好很多。