MinerU vs PaddleOCR vs RAGFlow 对比分析

调研日期:2026-04-20 | 项目:RAG 客服系统

一、MinerU 与 PaddleOCR:层级关系图

PDF
DOCX
图片
MinerU 文档解析框架(应用层)
版面检测
mAP 97.5
PaddleOCR OCR 引擎(工具层)
文字检测
DB++
文字识别
SVTR
版面分析 表格识别 公式识别
也可独立使用 — pip install paddleocr
元素分类
text/table/image
关系建模
caption 关联
MinerU 输出
content_list.json
结构化 JSON
类型 + 页码 + bbox + caption
PaddleOCR 单独输出
识别文字 + 坐标 + 置信度
无结构化,无关系建模

核心区别

维度 PaddleOCR OCR 引擎 MinerU 文档解析框架
定位图片/扫描件 → 文字识别PDF/DOCX → 结构化数据(端到端)
能力边界检测 + 识别 + 版面分析解析 + 分类 + 关系建模 + 输出
关系MinerU 内置 PaddleOCR 作为 OCR 引擎 — 上下游关系,不是竞品
独立使用可以 — 只做 OCR 识别可以 — 端到端文档解析
输入图片 / numpy arrayPDF / DOCX / 图片 / 电子书
输出文字 + 坐标 + 置信度Markdown + content_list.json(结构化)
框架PaddlePaddle(百度)PyTorch
OmniDocBench92.86(第 1)90.67(第 3)
安装pip install paddleocr依赖链复杂(torch + sglang)
Windows原生支持2.0+ 受限(sgl-kernel 无 wheel)
macOS Intel可用不可用(torch 限制)

一句话总结

PaddleOCR 是螺丝刀(专做 OCR 识别),MinerU 是工具箱(端到端文档解析,内含 PaddleOCR 这把螺丝刀)。

二、MinerU 与 RAGFlow:架构定位图

graph LR
    subgraph MinerU2["MinerU
文档解析引擎"] direction TB MA["PDF / DOCX 输入"] MB["版面分析 + OCR"] MC["结构化输出
content_list.json"] MA --> MB --> MC end subgraph RAGFlow2["RAGFlow
端到端 RAG 平台"] direction TB R1["文档解析
python-docx / Deepdoc"] R2["智能分块
模板 + 可视化编辑"] R3["向量化 + 混合检索
Dense + BM25"] R4["精排 Reranker"] R5["LLM 生成回答
多模态输出"] R6["API / 聊天界面"] R1 --> R2 --> R3 --> R4 --> R5 --> R6 end MC -.->|"可作为 RAGFlow 的解析层"| R1 subgraph Scope["覆盖范围"] S1["MinerU:只负责
文档 → 结构化数据"] S2["RAGFlow:负责
文档 → 检索 → 回答
(全链路)"] end style MinerU2 fill:#ede9fe,stroke:#7c3aed,stroke-width:2px style RAGFlow2 fill:#fef3c7,stroke:#d97706,stroke-width:2px style Scope fill:#f0fdf4,stroke:#059669,stroke-width:1px

定位差异

维度 MinerU 文档解析引擎 RAGFlow 端到端 RAG 平台
定位文档解析(Pipeline 的第一步)完整 RAG 系统(从文档到回答)
覆盖范围文档 → 结构化数据文档 → 分块 → 检索 → 精排 → 生成 → 输出
可类比发动机整辆车
DOCX 解析python-docx + mammoth(~2700 行)
表格最强,公式/超链接/文本框全提取
python-docx(~400 行)
文本+表格+图片,简洁够用
图片处理提取 blob,不做 OCR发给 Vision LLM(GPT-4V/Qwen-VL)做描述
分块策略不负责分块模板分块 + 可视化编辑 + TOC 提取
检索不负责Dense + BM25 混合检索 + Reranker
LLM 集成多模型支持 + Agentic RAG
多模态输出ContentBlock 数组(文本+图片+表格)
部署pip / DockerDocker Compose(含 ES/Redis/MinIO)
开箱即用需自建后续链路带 Web UI,上传文档即可问答
GitHub Stars~25k~30k

三、三者关系总览

graph TB
    subgraph Layer1["工具层 — 单一能力"]
        PO["PaddleOCR
图片 → 文字"] PD["python-docx
DOCX → XML 遍历"] MM["mammoth
DOCX → HTML"] end subgraph Layer2["引擎层 — 文档解析"] MU["MinerU
PDF/DOCX → 结构化 JSON
内置 PaddleOCR + mammoth"] DD["Deepdoc
RAGFlow 自研解析"] end subgraph Layer3["平台层 — 端到端 RAG"] RF["RAGFlow
文档 → 检索 → 回答
带 Web UI + API"] end subgraph Layer4["我们的项目"] OUR["自研 RAG Pipeline
python-docx + 图片内联
+ 混合检索 + LLM 生成"] end PO -.-> MU PD -.-> MU MM -.-> MU PD -.-> DD DD -.-> RF PD -.-> OUR style Layer1 fill:#dbeafe,stroke:#2563eb,stroke-width:1px style Layer2 fill:#ede9fe,stroke:#7c3aed,stroke-width:1px style Layer3 fill:#fef3c7,stroke:#d97706,stroke-width:1px style Layer4 fill:#d1fae5,stroke:#059669,stroke-width:2px

四、为什么参考 RAGFlow 而非 MinerU

选型逻辑

具体借鉴点

借鉴内容来源用在哪里
body 遍历保序(图文位置保持)RAGFlow docx_parser.pyDocxParser _walk_body
pic:pic XPath 图片提取RAGFlowDocxParser _extract_images_from_paragraph
ContentBlock 数组输出协议RAGFlow 多模态输出08 文档 ContentBlock 规范
表格注入标题作为 captionRAGFlow 表格处理待实现
mammoth 全文档预解析表格MinerU(非 RAGFlow)待实现(P2 优先级)
TOC 锚点预收集MinerU(非 RAGFlow)待实现(P1 优先级)

不选 RAGFlow 直接部署的原因

原因说明
部署太重Docker Compose 需 ES + Redis + MinIO + MySQL,运维成本高
定制性不足意图识别、查询改写、置信度评估等环节需要深度定制
图片 OCR 依赖 LLM APIRAGFlow 图片处理需要 GPT-4V/Qwen-VL API,我们新方案不需要 OCR
学习价值手搓 RAG 全链路是项目目标之一