如上篇文章最后所言，進一步優(yōu)化原始文檔解析和分塊策略是控制變量法下，提高最后檢索效果天花板的務(wù)實做法。從這篇開始，在對歷史項目進行迭代的同時，會陸續(xù)對不同的文檔解析方法和動態(tài)分塊策略給出更多的原理解析和案例參考。

圖片來源：

https://liduos.com/ai-develope-tools-series-2-open-source-doucment-parsing.html

這篇以MinerU為由，試圖說清楚文檔解析工具大致構(gòu)成，MinerU 和 Deepdoc 對比，MinerU 部署，以及如何和圖片服務(wù)方案結(jié)合使用。

以下，enjoy:

1、三種類型解析工具

在 RAG 流程中，文檔解析是第一步，主要任務(wù)是將各種格式的原始文檔轉(zhuǎn)化為一種統(tǒng)一的、易于處理的中間格式。文檔解析這一步的輸出格式應(yīng)該盡可能地通用和靈活，使得后續(xù)的分塊、向量化等步驟不需要高度依賴于特定的解析工具或其內(nèi)部實現(xiàn)細節(jié)。

除了以 Deepdoc 為代表的集成解析器外，還有開源文檔解析庫(MinerU 屬于這種，后文單獨介紹）和云端 API 兩種。

1.1開源文檔解析庫

Unstructured.io：專注于簡化各種數(shù)據(jù)格式（包括圖像和文本文件，如 PDF、HTML、Word 文檔等）的攝取和預(yù)處理，以便用于大型語言模型 。它提供模塊化的功能和連接器，可以無縫地協(xié)同工作，將非結(jié)構(gòu)化數(shù)據(jù)高效地轉(zhuǎn)換為結(jié)構(gòu)化格式，同時還具有適應(yīng)各種平臺和用例的靈活性。

PyMuPDF： 是一款輕量級且高效的庫，用于處理 PDF 文檔、XPS 文件和電子書。它提供了提取文本、圖像和元數(shù)據(jù)的功能，使得開發(fā)人員能夠輕松地操作和分析 PDF 文檔。PyMuPDF 基于成熟的 MuPDF 庫開發(fā)，支持多種文檔格式，并提供文檔頁面渲染、文本提取（包括 Markdown 格式）、表格提取、向量圖形提取等功能 [25]。

Marker： 旨在快速準(zhǔn)確地將文檔轉(zhuǎn)換為 Markdown、JSON 和 HTML 格式。它支持包括 PDF、圖像、PPTX、DOCX、XLSX、HTML 和 EPUB 在內(nèi)的多種文件格式，能夠處理各種語言，并格式化表格、公式、鏈接、參考文獻和代碼塊，同時還可以提取和保存圖像，移除頁眉頁腳等干擾元素。Marker 尤其在處理書籍和科學(xué)論文方面表現(xiàn)出色，并且可以通過 LLM 來提高準(zhǔn)確性 。

與使用集成解析器相比，集成和配置這些庫 需要更多的開發(fā)工作 。某些庫可能具有外部依賴項（例如 Unstructured.io 中的 Tesseract 用于 OCR），這些依賴項需要單獨管理 。

另外需要考慮許可證的問題，不同的開源許可證對軟件的發(fā)布和修改有不同的要求，某些許可證（例如 PyMuPDF 的 AGPL）可能會對商業(yè)使用產(chǎn)生影響，在特定條件下需要開源衍生作品 。

1.2云端 API

云服務(wù)商提供的文檔智能 API 也是文檔解析的重要選擇，它們通常具有高精度的 OCR 能力和處理大規(guī)模文檔的潛力。

圖片來自于Mistral OCR官網(wǎng)

Mistral OCR 是其中的一個典型代表 ，其他知名的服務(wù)商還包括 Google Cloud Document AI 和 Azure AI Document Intelligence 。根據(jù) Mistral AI 分享的基準(zhǔn)測試，Mistral OCR 的總體準(zhǔn)確率達到了 94.89%，超過了 Google 的 83.42% 和 Azure 的 89.52% 。

Mistral OCR我也在測試過程中，后續(xù)會專門寫篇文章結(jié)合案例進行介紹。

2、MinerU vs Deepdoc

說實話，我最早也是在知識星球內(nèi)有星友提問才知道 MinerU 這個開源項目，之前是花了比較多時間研究 Deepdoc 和 PyMuPDF 的一些優(yōu)化技術(shù)。 后來在公眾號、B 站也搜到很多介紹 MinerU 的文章和視頻。

我在常逛的 Reddit 的 RAG sub reddit 上也看到有用戶評論稱，在使用過 llamaparse、docling、pymupdf4llm、unstructured 等工具后，發(fā)現(xiàn) MinerU 是迄今為止最好的 。在 GitHub 上，有用戶表示 MinerU 提供了最佳結(jié)果，甚至可以識別公式，并且其表格解析和布局檢測也更好 。

2.1MinerU

MinerU是一款由上海人工智能實驗室的大模型數(shù)據(jù)基礎(chǔ)團隊（OpenDataLab）開發(fā)的開源數(shù)據(jù)提取工具，專門用于高效地從復(fù)雜的 PDF 文檔、網(wǎng)頁和電子書中提取內(nèi)容 。其設(shè)計目標(biāo)是提供高質(zhì)量的內(nèi)容提取，并對包括圖片、表格、公式等在內(nèi)的多模態(tài)文檔具有強大的處理能力 。

為了更好理解 MinerU 的工作原理，從上述命令行啟動日志可以看到多個獨立的“Predict”階段，這表明 MinerU 的解析流程是分解成了多個步驟或模塊。

圖片來自于上海人工智能實驗室的共享飛書文檔，感興趣的點擊下方鏈接移步自?。篽ttps://aicarrier.feishu.cn/file/SknGbA2nqoYodbxNjYRcqeUsngf 

Layout Predict (版面分析): 識別頁面上的主要區(qū)域，如文本塊、圖片、表格、標(biāo)題、頁眉頁腳等。這是后續(xù)處理的基礎(chǔ)。 

出處同上

MFD Predict (可能指 Master Feature Detection): 在版面分析的基礎(chǔ)上，進一步檢測特定對象，日志中緊隨其后的是表格相關(guān)的步驟，因此這里很可能是專門的表格區(qū)域檢測。 

MFR Predict (可能指 Master Feature Recognition): 在檢測到特定對象后，對對象內(nèi)容進行識別或提取。緊隨 MFD 之后，很可能是對檢測到的表格區(qū)域進行結(jié)構(gòu)和內(nèi)容識別。 

OCR-det Predict: 在文本塊內(nèi)，檢測具體的文本行或單個字符的位置。 

OCR-rec Predict: 對檢測到的文本行或字符區(qū)域進行圖像到文本的轉(zhuǎn)換，即執(zhí)行 OCR。 

Table Predict (表格處理): 在 MFD 和 MFR 的基礎(chǔ)上，進一步處理表格數(shù)據(jù)，可能包括結(jié)構(gòu)化提取、單元格合并、跨頁表格處理等。 

Processing Pages (后處理): 整合所有步驟的結(jié)果，生成最終的結(jié)構(gòu)化輸出（如 Markdown, JSON 等）。

2.2Deepdoc

RAGFlow 的文檔解析核心組件被稱為 DeepDoc。這并不是一個單一的黑箱，而是一個利用視覺信息和解析技術(shù)對文檔進行深度理解的系統(tǒng)，其功能模塊化地包含了多個部分，這與 MinerU 的模塊化思路也是相似的，或者說是殊途同歸。

DeepDoc 的主要解析邏輯和模塊包括：

OCR: 將圖片或掃描文檔中的文字識別出來。支持多種語言和字體，并能處理復(fù)雜的布局和圖像質(zhì)量。這是基礎(chǔ)步驟，將非文本內(nèi)容轉(zhuǎn)化為可處理的文本信息。 

識別: 識別文檔的整體布局和 結(jié)構(gòu)，區(qū)分不同的內(nèi)容區(qū)域，如標(biāo)題、段落、表格、圖像、頁眉、頁腳、公式等。這是理解文檔結(jié)構(gòu)的關(guān)鍵一步。日志中提到的 Layout Predict 在 DeepDoc 中也有對應(yīng)的模塊。 

圖片來自：https://github.com/infiniflow/ragflow/blob/main/deepdoc/README_zh.md

表格結(jié)構(gòu)識別 : 專門針對檢測到的表格區(qū)域，識別表格的行、列、單元格以及合并單元格等復(fù)雜結(jié)構(gòu)，并將表格內(nèi)容結(jié)構(gòu)化提取（例如轉(zhuǎn)換為 HTML 格式）。日志中的 MFD Predict 和 MFR Predict 對應(yīng) DeepDoc 的這一能力。

解析器: 針對不同類型的文檔格式（如 PDF, DOCX, EXCEL, PPT, TXT, MD, JSON, EML, HTML, IMAGE 等），DeepDoc 提供了相應(yīng)的解析器來處理。PDF 解析器通常需要結(jié)合上述的 OCR、版面分析和表格識別結(jié)果來還原文檔內(nèi)容和結(jié)構(gòu)。

出處  同上

后處理: 在各個模塊識別和提取信息后，需要進行后處理，例如合并段落、過濾分頁信息、清理噪音內(nèi)容（如頁眉頁腳、版權(quán)聲明等），最終生成用于分塊和向量化的文本及結(jié)構(gòu)化數(shù)據(jù)。

對于 PDF 文檔，DeepDoc的處理流程通常包括：文檔轉(zhuǎn)圖片 -> 版面分析 -> 表格識別 -> 文字識別 -> 合并段落 -> 后處理。這個流程與從 MinerU 日志推斷的步驟非常相似。此外，DeepDoc 還針對一些特殊文檔類型提供了專門的處理邏輯，例如： 

簡歷解析: 將簡歷這種非標(biāo)準(zhǔn)化文檔解析為結(jié)構(gòu)化數(shù)據(jù)字段（如姓名、工作經(jīng)歷等），而不是簡單地分塊。 

特定格式分塊: RAGFlow 提供了多種針對不同文檔結(jié)構(gòu)（如通用、問答、表格、論文、書籍、法律、演示文稿、圖片、簡歷等）的模板化分塊方法。這些方法會利用 DeepDoc 解析出的文檔結(jié)構(gòu)信息，按照更符合文檔邏輯的方式進行切分，而不是簡單的固定長度或標(biāo)點符號分塊。

2.3孰優(yōu)孰劣

DeepDoc 和 MinerU 在處理復(fù)雜文檔時都采取了模塊化、多步驟的策略，這是解決文檔理解難題的一種常見且有效的方法。它們的主要差異可能在于各模塊使用的具體算法、模型的訓(xùn)練數(shù)據(jù)、工程實現(xiàn)細節(jié)以及針對不同文檔類型的優(yōu)化側(cè)重點。

關(guān)于優(yōu)劣的具體對比，文檔解析是一個復(fù)雜任務(wù)，不像圖像分類有 ImageNet，文本識別有 ICDAR 等相對標(biāo)準(zhǔn)化的數(shù)據(jù)集。端到端的文檔解析涉及到布局、文本、表格、公式等多種元素的識別和結(jié)構(gòu)化，很難定義一個普適的評測指標(biāo)和數(shù)據(jù)集來公平衡量所有系統(tǒng)。不同的文檔類型（掃描、電子、復(fù)雜布局、多語言等）會導(dǎo)致評測結(jié)果差異巨大。

社區(qū)成員對解析效果的評價往往是基于他們在自己的文檔集上的使用體驗，而這些文檔集往往具有特定行業(yè)的特點和固有的復(fù)雜性，某個系統(tǒng)在某個用戶的特定文檔集上表現(xiàn)更好，并不能代表它在所有文檔集上都更好。

醫(yī)學(xué)paper中的豎向表格識別的很好

醫(yī)學(xué)領(lǐng)域的特殊符號也能正常解析

設(shè)備維保的PPT布局也能正常識別，而且自動去除了頁眉和頁腳

我在針對手頭目前在做的兩個設(shè)備維保場景和醫(yī)學(xué) paper 三個文檔進行對比發(fā)現(xiàn)，MinerU 確實整體表現(xiàn)優(yōu)異，但是也有些無法處理的情況。

從截圖中可以明顯看到表格中間部分的圖片沒有被MinerU正確識別。這是MinerU在處理某些特定情況下的一個局限性。這種情況可能有以下幾個原因：

1. 表格內(nèi)嵌圖片的識別挑戰(zhàn)MinerU在處理嵌入在表格單元格內(nèi)的圖片時，有時會將其視為表格的一部分，而非獨立的圖像元素，這在復(fù)雜布局中是常見的挑戰(zhàn)。
2. 模型識別邊界版面分析模型可能將表格整體作為一個單元處理，沒有正確區(qū)分出表格中的圖片區(qū)域與文本區(qū)域的邊界。
3. 圖片質(zhì)量和邊界如果圖片與表格邊界融合得比較緊密，沒有明顯的分隔線或邊框，模型可能難以正確區(qū)分。
   不過我也檢索了下MinerU的Github歷史迭代記錄, 他們確實提供了對這類問題的持續(xù)改進，但這個問題顯然還沒有解決的很徹底。

但是這個corner case實際通過PyMuPDF可以很好的被解決，具體請參考歷史文章：RAGFlow框架優(yōu)化經(jīng)驗分享（附代碼）：圖文識別+動態(tài)分塊 、API調(diào)優(yōu)+源碼修改

3、MinerU 如何本地配置

看完上述介紹后，感興趣的盆友可以在 MinerU 官網(wǎng)或者參照流程本地部署下 MinerU 進一步測試。注意，沒有哪個絕對更好，能解決你業(yè)務(wù)需求的更加實際。

以下配置說明節(jié)選自官方教程，我做了一定的整理和說明，逐步操作即可。

https://github.com/opendatalab/MinerU/blob/master/README_zh-CN.md 

3.1軟硬件環(huán)境要求

實測純 CPU 能跑，但是很慢，有條件的建議剛開始就修改下下方提到的 magic-pdf.json使用 GPU 加速。

3.2安裝 magic-pdf

conda create -n mineru 'python>=3.10' -y  
conda activate mineru
pip install -U "magic-pdf[full]" -i https://mirrors.aliyun.com/pypi/simple

關(guān)于創(chuàng)建虛擬環(huán)境這一步，windows 用戶可以使用:

python -m venv venv
venv\\Scripts\\activate

3.3下載模型權(quán)重文件

# 有條件的也可以選擇 Hugging Face鏡像
pip install modelscope https://gcore.jsdelivr.net/gh/opendatalab/MinerU@master/scripts/download_models.py -O download_models.py
python download_models.py

完成下載模型權(quán)重文件步驟后，腳本會自動生成用戶目錄下的 magicpdf.json 文件，并自動配置默認模型路徑。可以選擇修改該文件中的部分配置實現(xiàn)功能的開關(guān)，如表格識別功能，為節(jié)省篇幅這部分不做展開討論。

注：如此前通過 HuggingFace 或 Model Scope 下載過模型，可以重復(fù)執(zhí)行此前的模型下載 python 腳本，將會自動將模型目錄更新到最新版本。

3.4兩種打開方式

命令行

# show version
magic-pdf -v


# command line example
magic-pdf -p {some_pdf} -o {some_output_dir} -m auto

注意，輸入的文件需要是以下后綴：.pdf .png .jpg .ppt .pptx .doc .docx

{some_pdf} 可以是單個 pdf 文件，也可以是一個文件夾包含多個 PDF，處理結(jié)果會保存在 {some_output_dir}文件夾中，文件列表為：

├── some_pdf.md                          # markdown file
├── images                               # directory for storing images
├── some_pdf_layout.pdf                  # layout diagram
├── some_pdf_middle.json                 # MinerU intermediate processing result
├── some_pdf_model.json                  # model inference result
├── some_pdf_origin.pdf                  # original PDF file
├── some_pdf_spans.pdf                   # smallest granularity bbox position information diagram
└── some_pdf_content_list.json           # Rich text JSON arranged in reading order

使用 API

官方提供了標(biāo)準(zhǔn)的 python 示例代碼，只需要簡單修改即可直接使用，這里也不做贅述。下面重點介紹 RAGFlow+MinerU 整合使用版本。

4、RAGFlow + MinerU 圖片服務(wù)方案

在使用 RAGFlow 框架結(jié)合 MinerU 進行 PDF 文檔解析和問答時，MinerU 會智能地提取文檔中的文本和圖片。為了在 RAGFlow 的問答結(jié)果中能夠展示這些由 MinerU 提取的圖片，我們需要一個可靠的機制來提供圖片的網(wǎng)絡(luò)訪問。本項目沿用并改進了原有的獨立圖片服務(wù)器容器方案，使得 RAGFlow 容器能夠通過 Docker 網(wǎng)絡(luò)訪問 MinerU 輸出的圖片資源。

原有獨立圖片服務(wù)器容器方案文章請移步：

RAGFlow如何實現(xiàn)圖片問答：原理分析+詳細步驟（附源碼）

4.1系統(tǒng)架構(gòu)

系統(tǒng)主要包含兩個交互的 Docker 容器：

RAGFlow 容器：負責(zé)知識庫管理、問答流程和與大模型交互。

圖片服務(wù)器容器：使用 FastAPI 搭建，提供 MinerU 提取出的圖片資源的 HTTP 訪問。

兩個容器通過 Docker 自定義網(wǎng)絡(luò) (rag-network) 連接。RAGFlow+MinerU_test.py 腳本使用 MinerU 解析 PDF，將提取的圖片存儲到映射給圖片服務(wù)器容器的卷中。腳本隨后將 MinerU 輸出的 Markdown 中的[IMG::...]占位符替換為完整的 HTML<img> 標(biāo)簽（包含指向圖片服務(wù)器的 HTTP URL），然后將處理后的文本上傳到 RAGFlow。RAGFlow 在生成回答時，如果需要引用圖片，會依賴其知識庫中已經(jīng)包含的 HTML <img> 標(biāo)簽。

4.2項目文件說明

1.  `RAGFlow+MinerU_test.py`: 核心腳本，整合了 MinerU PDF 解析和 RAGFlow 資源創(chuàng)建。
2.  `image_server.py`: 圖片服務(wù)器的 FastAPI 主程序。
3.  `Dockerfile`: 用于構(gòu)建圖片服務(wù)器容器的配置文件。
4.  `requirements.txt`: 項目所需的 Python 依賴包列表。
5.  `README.md`: 本說明文件。
6.  `images/`: (可選) 存放 README 中引用的圖片。
7.  `output_mineru/images/`: MinerU 默認輸出圖片的目錄 (運行腳本后生成)。
8、`download_models.py`: MinerU模型下載文件。

項目源碼老規(guī)矩同步更新在知識星球內(nèi)， 接著上面提到的Reddit帖子預(yù)告下，五月初我會在知識星球會員微信群內(nèi)引入RAG日報機器人，每天自動    搜索匯總國內(nèi)外公開的行業(yè)最佳實踐案例。

4.3處理流程說明

python RAGFlow+MinerU_test.py


此腳本將執(zhí)行以下操作：
1.  使用 MinerU (`magic-pdf`) 讀取并解析指定的 PDF 文件。
2.  提取文本內(nèi)容和圖片，圖片保存到配置的輸出目錄 (`output_mineru/images`)。
3.  生成包含圖片占位符 (`[IMG::...]`) 的 Markdown 格式增強文本。
4.  將 Markdown 文本中的 `[IMG::...]` 占位符替換為包含完整 HTTP URL 的 HTML `<img>` 標(biāo)簽。
5.  調(diào)用 RAGFlow API：
    *   創(chuàng)建數(shù)據(jù)集 (知識庫)。
    *   將包含 HTML `<img>` 標(biāo)簽的文本上傳到數(shù)據(jù)集中。
    *   觸發(fā)文檔解析 (分塊和向量化)。
    *   創(chuàng)建聊天助手，關(guān)聯(lián)到該數(shù)據(jù)集。
    *   配置助手的 Prompt，使其能理解并按要求在回答中包含 HTML `<img>` 標(biāo)簽。

4.4MinerU 占位符替換 vs. PyMuPDF 直接生成

相比上一版本的獨立圖片服務(wù)器容器方案，新腳本在處理圖片鏈接生成的方式上確實有所不同，做說明如下：

PyMuPDF_test.py 的邏輯 (舊方法):

這個腳本是直接使用 fitz (PyMuPDF) 庫來解析 PDF。它在代碼中手動遍歷頁面元素，提取圖片，并在組裝最終輸出文本時，直接在代碼中構(gòu)建 完整的 <img> HTML 標(biāo)簽，包含 http://... 格式的 URL。這種方式給予了開發(fā)者完全的控制權(quán)，可以在提取的同時就生成最終格式。

RAGFlow+MinerU_test.py的邏輯 (新方法):

這個腳本使用了 magic-pdf (MinerU) 庫。magic-pdf 庫的設(shè)計是將文檔解析和 Markdown 輸出封裝起來。它的標(biāo)準(zhǔn) pipe_result.get_markdown() 方法輸出的是包含 [IMG::...] 占位符 的 Markdown。為了得到最終需要的 HTML <img> 標(biāo)簽和完整 URL，我們在獲取 MinerU 的輸出后，增加了一個后處理步驟（即 replace_img_placeholders_with_urls 函數(shù)），專門負責(zé)查找這些占位符并將其替換為完整的 <img> 標(biāo)簽。

評估與選擇:

為什么不直接讓 MinerU 輸出 <img> 標(biāo)簽? 

修改 magic-pdf 庫內(nèi)部的 get_markdown 邏輯來直接輸出帶完整 URL 的 <img> 標(biāo)簽是不推薦的。這會破壞庫的標(biāo)準(zhǔn)輸出，使得代碼更難維護，并且未來升級 magic-pdf 庫時可能會遇到兼容性問題。

為什么當(dāng)前方法 (占位符 -> 替換) 更合適?

遵循庫標(biāo)準(zhǔn): 它利用了 magic-pdf 庫的標(biāo)準(zhǔn)輸出，代碼更清晰，與庫的耦合度更低。

關(guān)注點分離: MinerU 負責(zé)解析和生成帶占位符的結(jié)構(gòu)化文本，而鏈接替換邏輯則獨立出來，易于修改和調(diào)試。比如，如果以后 URL 格式需要改變，只需要修改 replace_img_placeholders_with_urls 函數(shù)。

可調(diào)試性: 可以先檢查 MinerU 輸出的帶占位符的 Markdown 文件 (_placeholders.md)，再檢查替換后的文件 (_with_urls.md)，方便排查問題。

結(jié)論

雖然 PyMuPDF_test.py的直接生成方式看起來更一步到位，但在當(dāng)前使用 magic-pdf 庫的場景下，采用“先獲取帶占位符的輸出，再進行后處理替換”的方式是更合理、更健壯、更易于維護的選擇。RAGFlow+MinerU_test.py當(dāng)前的實現(xiàn)方式是推薦的。

5、寫在最后

5.1特別說明

本篇所介紹的 MinerU 的測評是針對特定案例材料的介紹，不管如何， MinerU 無疑是值得關(guān)注和嘗試的一個文檔解析框架，但是具體效果各位還要結(jié)合手頭項目文檔做仔細橫評。我后續(xù)會繼續(xù) 針對 PaddleOCR、Mistra OCR 等 工具進行具體案例測試后寫文章出來供參考。

5.2項目升級預(yù)告

上一期介紹到 Dify+RAGFLow：基于占位符的圖片問答升級方案中，接下來我會在兩個方面進行迭代。一方面，計劃移除 image_server.py 和對應(yīng)的 Docker 容器，統(tǒng)一用 MinIO 來解決映射關(guān)系和圖片的存儲問題，解決了本地部署的需求。其次，關(guān)于工作流設(shè)計 Code 節(jié)點批處理限制導(dǎo)致無法流式輸出影響體驗的問題，計劃通過 Tampermonkey 用戶腳本為本地 Dify 添加前端圖片占位符替換功能。