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

圖片來源：

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

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

以下，enjoy:

1、三種類型解析工具

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

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

1.1開源文檔解析庫

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

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

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

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

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

1.2云端 API

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

圖片來自于Mistral OCR官網

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

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

2、MinerU vs Deepdoc

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

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

2.1MinerU

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

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

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

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

出處同上

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

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

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

OCR-rec Predict: 對檢測到的文本行或字符區域進行圖像到文本的轉換，即執行 OCR。 

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

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

2.2Deepdoc

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

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

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

識別: 識別文檔的整體布局和 結構，區分不同的內容區域，如標題、段落、表格、圖像、頁眉、頁腳、公式等。這是理解文檔結構的關鍵一步。日志中提到的 Layout Predict 在 DeepDoc 中也有對應的模塊。 

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

表格結構識別 : 專門針對檢測到的表格區域，識別表格的行、列、單元格以及合并單元格等復雜結構，并將表格內容結構化提取（例如轉換為 HTML 格式）。日志中的 MFD Predict 和 MFR Predict 對應 DeepDoc 的這一能力。

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

出處  同上

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

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

簡歷解析: 將簡歷這種非標準化文檔解析為結構化數據字段（如姓名、工作經歷等），而不是簡單地分塊。 

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

2.3孰優孰劣

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

關于優劣的具體對比，文檔解析是一個復雜任務，不像圖像分類有 ImageNet，文本識別有 ICDAR 等相對標準化的數據集。端到端的文檔解析涉及到布局、文本、表格、公式等多種元素的識別和結構化，很難定義一個普適的評測指標和數據集來公平衡量所有系統。不同的文檔類型（掃描、電子、復雜布局、多語言等）會導致評測結果差異巨大。

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

醫學paper中的豎向表格識別的很好

醫學領域的特殊符號也能正常解析

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

我在針對手頭目前在做的兩個設備維保場景和醫學 paper 三個文檔進行對比發現，MinerU 確實整體表現優異，但是也有些無法處理的情況。

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

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

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

3、MinerU 如何本地配置

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

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

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

3.1軟硬件環境要求

實測純 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

關于創建虛擬環境這一步，windows 用戶可以使用:

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

3.3下載模型權重文件

# 有條件的也可以選擇 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

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

注：如此前通過 HuggingFace 或 Model Scope 下載過模型，可以重復執行此前的模型下載 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，處理結果會保存在 {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

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

4、RAGFlow + MinerU 圖片服務方案

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

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

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

4.1系統架構

系統主要包含兩個交互的 Docker 容器：

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

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

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

4.2項目文件說明

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

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

4.3處理流程說明

python RAGFlow+MinerU_test.py


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

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

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

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

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

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

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

評估與選擇:

為什么不直接讓 MinerU 輸出 <img> 標簽? 

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

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

遵循庫標準: 它利用了 magic-pdf 庫的標準輸出，代碼更清晰，與庫的耦合度更低。

關注點分離: MinerU 負責解析和生成帶占位符的結構化文本，而鏈接替換邏輯則獨立出來，易于修改和調試。比如，如果以后 URL 格式需要改變，只需要修改 replace_img_placeholders_with_urls 函數。

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

結論

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

5、寫在最后

5.1特別說明

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

5.2項目升級預告

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