调研日期:2026-04-20 | 项目:RAG 客服系统
pip install paddleocrcontent_list.json| 维度 | PaddleOCR OCR 引擎 | MinerU 文档解析框架 |
|---|---|---|
| 定位 | 图片/扫描件 → 文字识别 | PDF/DOCX → 结构化数据(端到端) |
| 能力边界 | 检测 + 识别 + 版面分析 | 解析 + 分类 + 关系建模 + 输出 |
| 关系 | MinerU 内置 PaddleOCR 作为 OCR 引擎 — 上下游关系,不是竞品 | |
| 独立使用 | 可以 — 只做 OCR 识别 | 可以 — 端到端文档解析 |
| 输入 | 图片 / numpy array | PDF / DOCX / 图片 / 电子书 |
| 输出 | 文字 + 坐标 + 置信度 | Markdown + content_list.json(结构化) |
| 框架 | PaddlePaddle(百度) | PyTorch |
| OmniDocBench | 92.86(第 1) | 90.67(第 3) |
| 安装 | pip install paddleocr | 依赖链复杂(torch + sglang) |
| Windows | 原生支持 | 2.0+ 受限(sgl-kernel 无 wheel) |
| macOS Intel | 可用 | 不可用(torch 限制) |
PaddleOCR 是螺丝刀(专做 OCR 识别),MinerU 是工具箱(端到端文档解析,内含 PaddleOCR 这把螺丝刀)。
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 / Docker | Docker 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
| 借鉴内容 | 来源 | 用在哪里 |
|---|---|---|
| body 遍历保序(图文位置保持) | RAGFlow docx_parser.py | DocxParser _walk_body |
pic:pic XPath 图片提取 | RAGFlow | DocxParser _extract_images_from_paragraph |
| ContentBlock 数组输出协议 | RAGFlow 多模态输出 | 08 文档 ContentBlock 规范 |
| 表格注入标题作为 caption | RAGFlow 表格处理 | 待实现 |
| mammoth 全文档预解析表格 | MinerU(非 RAGFlow) | 待实现(P2 优先级) |
| TOC 锚点预收集 | MinerU(非 RAGFlow) | 待实现(P1 优先级) |
| 原因 | 说明 |
|---|---|
| 部署太重 | Docker Compose 需 ES + Redis + MinIO + MySQL,运维成本高 |
| 定制性不足 | 意图识别、查询改写、置信度评估等环节需要深度定制 |
| 图片 OCR 依赖 LLM API | RAGFlow 图片处理需要 GPT-4V/Qwen-VL API,我们新方案不需要 OCR |
| 学习价值 | 手搓 RAG 全链路是项目目标之一 |