做 RAG 项目这一年多最让我头疼的从来不是向量库选型也不是 Embedding 模型调参而是文档预处理这一步。尤其是 PDF还是那种从系统里导出来、带目录、带页眉页脚、带扫描图片甚至数学公式的复杂 PDF——用传统库提取文本切出来的分块几乎没法看。直到我把 MinerU 4.0 部署到 Windows 本地才算是把这根刺拔掉了一部分。这篇内容不是给你念官方文档是我在实际项目中踩完坑之后整理出来的一套可复现流程。我会把 Windows 上从零装好 MinerU 4.0、跑通离线 PDF 解析、再把结果接进 RAG 预处理脚本的完整链路写清楚包括命令行参数、Python 调用方式、输出目录结构、分块策略、以及我遇到的几个典型问题。适合正在搭知识库、搞 RAG 检索增强、或者被 PDF 解析质量折磨到睡不着的同学参考。1. 为什么是 MinerU而不是那堆免费 PDF 库1.1 大多数 RAG 应用都倒在切出来读不懂很多人一开始做 RAG 时都会顺手用 pdfplumber 或者 PyPDF2 把 PDF 文本抽出来然后丢给一个固定长度的文本分割器。这种方案在小规模、排版简单的文档上没问题一旦遇到论文、两栏排版、复杂表格、页脚页码、或者扫描件问题立刻就出来了。这类库本质上只是按页面物理顺序把字符捞出来根本不管版面。PDF 在视觉上明明是左右两栏抽取结果却是一列文字读完后跳到右侧切出来的 chunk 语义支离破碎。表格更惨行和列的边界信息全部丢失抽出来就是一行行碎片。公式就更不用提了PDF 里的数学符号被拆成 Unicode 字符之后基本不可读。这个阶段的痛点不在于检索算法而在于第一公里的提质量。检索召回的上限基本是分割前就定死的喂进去的是垃圾向量化再精细也白搭。1.2 MinerU 4.0 在管线里到底做了什么MinerU 做的事情其实是一整套文档版面还原的活它不是一个简单的文本抽取器而是一个视觉规则的混合管线。输入端是 PDF 文件输出端是结构化的 Markdown 文件和对应的 JSON 元数据。它的核心工作流程大致是这样的先做版面检测识别页面里的标题、正文、图片、表格、页眉页脚、公式等区域而不是傻乎乎地把整页当成一段文本。然后对检测到的区域分别处理文本块走 OCR 或者原生文本提取表格块走专门的表格结构识别公式块会转成 LaTeX 语法。最后根据版面检测结果重组阅读顺序把多栏排版还原成符合人类阅读顺序的线性文本再导出成 Markdown。这一步很关键。经过 MinerU 处理之后我从 PDF 里拿到的是一个干净版文档而不是一堆长得像文本的碎片。1.3 适用的场景和不适合的场景我自己的项目里最适用 MinerU 的几类文档论文 PDF、技术手册、产品说明书、合同扫描件、带图片的培训资料、以及包含大量公式的学术材料。这些文档的共同特点是版面结构复杂纯文本抽取根本扛不住。不太适合的场景也有。比如你要处理的是一堆只有几行字的简单 PDF用 MinerU 有点杀鸡用牛刀解析速度反而不如轻量库快。另外如果你只有 CPU 机器且需要大量实时解析那也得慎重离线解析不是不能跑但是速度会明显偏慢更适合做成批处理任务而不是在线服务。2. Windows 部署环境、安装、模型初始化2.1 版本选型与环境准备先说结论Windows 上我推荐用 Python 3.10 搭配独立的虚拟环境来装 MinerU不要直接怼到系统 Python 里。这个项目依赖的 PyTorch、布局检测模型、OCR 组件都比较大依赖树也比较长放进全局环境以后很容易跟别的项目打架。创建虚拟环境这一步我会用 conda 而不是 venv。原因很实际conda 在 Windows 上管理 CUDA 相关依赖和 Python 版本切换更省心尤其是当你机器上同时有多个 Python 版本的时候。conda create -n mineru python3.10 conda activate mineru接下来确认 PyTorch 的安装方式。如果你机器上有 NVIDIA 显卡并且能跑 CUDA那就装 GPU 版解析速度会有数量级的提升。没有显卡也没关系CPU 版能跑只是慢一些后面我会专门说性能相关的优化。# GPU 版示例cuda 版本以你本地 nvidia-smi 显示的为准 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121装完之后用python -c import torch; print(torch.cuda.is_available())验证一下。如果输出 True说明环境正常后面跑起来会顺很多。2.2 安装 MinerU 与基础校验MinerU 4.0 已经把主要的解析能力整合到一个 pip 包里安装命令比旧版本清爽不少pip install mineru老读者如果接触过早期的 magic-pdf 那套东西应该知道之前还需要额外装模型仓库、跑安装脚本之类的事情。4.0 版本把流程简化了包装好之后直接用mineru-cli这个命令来干活。装完先别急着解析文件跑一下版本和环境自检mineru-cli --version mineru-cli probeprobe会检查你的运行环境是否满足要求包括 PyTorch 是否正常、是否能检测到 GPU、模型目录是否可写等。这一步能提前暴露很多问题不要跳过。2.3 模型的离线下载与缓存策略MinerU 的解析依赖几个深度学习模型权重这些模型在第一次使用时需要下载。官方默认会从 HuggingFace 拉模型下载好的模型放在~/.cache/huggingface这种系统默认缓存目录里。这里就是离线部署的关键点了。如果你所在的网络环境访问外网不稳定或者你压根就是要在一台离线的机器上部署我建议你在一台能联网的机器上先把模型下载完整然后把整个模型缓存目录拷贝到离线机器上再用环境变量指过去。具体操作# 先设置缓存目录不设置就默认 set HF_HOMED:\models\hf首次执行一次解析命令让 MinerU 把模型全部拉到D:\models\hf目录里。之后你把整个hf文件夹拷贝到离线机器上同样设置HF_HOME指向它就可以完全离线运行。需要注意模型总量不小小几个 G 的量级很正常拷贝时用移动硬盘或者内网传输都行但不建议用 U 盘这种容易出坏道的介质反复折腾。3. CLI 实操将 PDF 转为 Markdown3.1 一条命令入手先说明一点MinerU 4.x 的 CLI 入口是mineru-cli如果你在网上搜到旧教程里的magic-pdf命令那大概率是历史版本别照着敲。同一条功能在 4.0 里的对应操作是这样的。先看命令行自带帮助mineru-cli extract --help我平时最常用的解析命令长这样mineru-cli extract -i input.pdf -o output_dir -p 4 -f md参数含义我整理在下面这张表里参数作用我的建议-i指定输入 PDF 路径也可以是目录目录模式下会批量处理里面所有 PDF-o指定输出目录建议每次解析单独建一个目录别混-p并行进程数CPU 机器建议 2-4GPU 机器可以拉到 8 甚至更高-f输出格式可选md、json、或者both-b批量模式开关配合-i指向的目录使用一个比较稳妥的起步命令是mineru-cli extract -i D:\data\docs\sample.pdf -o D:\data\parsed -p 4 -f md执行过程中会看到类似layout detect、table predict之类的日志在滚动说明版面检测和表格识别正在跑。等日志完全停下来去输出目录里看结果。3.2 批量处理生产目录下的全部 PDF实际项目里很少只处理一个文件我一般会建一个raw_docs目录把所有待解析 PDF 扔进去然后这样跑mineru-cli extract -i D:\data\raw_docs -o D:\data\parsed -p 4 -f both -b-b开启批量模式之后输出目录里每个 PDF 都会得到一个独立的子目录里面放着各自的 Markdown 和 JSON 文件。这样元数据不会串后续做增量索引也方便。有一点要说清楚批量解析非常吃资源。如果你用 CPU 跑一次丢进去二三十个 PDF并行数又拉满机器基本处于满载状态这时候别同时干别的重活。建议分批或者降低-p。3.3 输出目录结构里的门道跑完一次解析之后你会发现输出目录里不止一个文件。典型的结构是这样的output_dir/ sample.pdf/ images/ 1.jpg 2.png sample.md sample.jsonsample.md是最终的可读版本表格被转换成了 Markdown 表格公式变成了 LaTeX 文本图片则以相对路径的形式嵌在 Markdown 里。sample.json才是真正精细的东西。它记录了每个页面的版面检测结果包括每个文本块、表格、图片的坐标框、页面序号、类型标签和原始内容。做 RAG 的时候我会用 JSON 里的元信息来辅助切块比如知道某一块内容来自第几页、属于标题还是正文、是否处于表格区域。images目录则是所有的图片资产里面可能是 PDF 里本来就有的图片也可能是通过版面检测被单独拆出来的图形区域。这些图片在后面的多模态 RAG 场景里会用到我先放个引子后面展开说。4. Python API 集成到 RAG 预处理流水线4.1 直接调用 MinerU 的最小代码CLI 适合人工操作和批处理但如果你想把它嵌进自己的数据管道里还是得走 Python API。MinerU 4.0 的最小调用不是很复杂大致结构如下。from mineru import MinerU mineru MinerU( model_sourcehuggingface, devicecuda, output_formatmd, ) result mineru.run(D:/data/raw_docs/sample.pdf)device参数可以设为cuda或者cpu。在我的 Windows 机器上GPU 调用和 CLI 模式的表现一致。如果你不确定参数细节先执行一遍解析再打印result的结构看看它里面有哪些字段比看文档更直观。有一个小坑某些配置项在不同小版本里名字可能微调如果你装的版本报参数错误直接把MinerU(...)里的参数删掉只保留 PDF 路径用默认配置跑一遍。这样最稳。4.2 针对 RAG 优化的 Markdown 分块示例MinerU 拿到的是结构良好的 Markdown但 RAG 切块还得自己设计。我自己的策略是按标题层级分块保护表格段落完整性。举例来说MinerU 导出的 Markdown 有明确的标题层级我可以用标题作为天然的分块边界。同时对表格单独处理不让一个表格被拦腰切成两半。下面是我项目里实际用的一套轻量分块代码。import re import json def split_markdown_by_heading(md_text, max_len1200, overlap100): lines md_text.splitlines() chunks [] buffer [] buffer_len 0 heading for line in lines: # 判断是不是标题行 m re.match(r^(#{1,4})\s(.*), line) if m and buffer_len 200: if buffer: chunks.append({ heading: heading, text: \n.join(buffer).strip(), }) heading m.group(2).strip() buffer [line] buffer_len len(line) else: buffer.append(line) buffer_len len(line) 1 if buffer_len max_len: if buffer: chunks.append({ heading: heading, text: \n.join(buffer).strip(), }) # 用尾部 overlap 保证上下文连续 buffer buffer[-overlap:] buffer_len sum(len(x) 1 for x in buffer) if buffer: chunks.append({ heading: heading, text: \n.join(buffer).strip(), }) return chunks这段代码不算精致但胜在简单可控。核心思想是以 Markdown 的标题结构作为语义边界标题变了就切一段段落太长则按最大长度截断同时保留尾部部分文本作为和下一段的 overlap。4.3 与嵌入模型和向量库的对接建议切块之后下一步就是把文本向量化存入向量库。这部分可选方案很成熟了比如 Ollama 本地跑 Embedding 模型、FastEmbed 这种轻量库或者企业场景里把文本灌给线上的 Embedding API。我的建议是在 MinerU 解析出来的 Markdown 基础上切块不要把 Raw PDF 文本直接做向量化。你可以在向量库的 metadata 里记录来源文件、页码、标题、块类型这样检索出来之后能反查到原文位置。4.4 图片资产与多模态 RAG 的配合很多人问过一个比较普遍的问题RAG 知识库能存储图片吗要做到能存图片一个关键前提是你的解析工具能把图片从原文档里完整体地扒出来而不只是把 OCR 结果变成一行文字。MinerU 在这点上有天然优势。它解析时会把版面检测到的图片单独保存到 images 目录并且在 Markdown 里用相对路径引用。这样你的分块文本里如果带这种引用你就可以在构建索引的时候把图片文件路径也记录下来。后续如果接一个多模态 Embedding 或者视觉语言模型就可以真正做到文字检索到图片、还能返回图片内容。哪怕暂时只做纯文本 RAG图片路径也值得保留因为检索结果页面反馈时可以展示缩略图体验完全不一样。5. 真实现场Windows 上常见的坑与排查5.1 慢得像拖拉机性能问题怎么解CPU 在没有 GPU 的情况下跑 MinerU速度真的会让人焦虑。一份 100 页的 PDFCPU 跑可能要几分钟到十几分钟而在 GPU 上可能只要一两分钟。排查思路很简单。先跑mineru-cli probe看环境是否正常识别到了 GPU再确认 PyTorch 是不是 CUDA 版本。如果这两项都没问题那就是并行数设置的问题-p参数尽量往高了给但要给系统留出余量。我的经验是CPU 机器上-p 2到-p 4可控GPU 机器上-p 4到-p 8效果不错。还有一种常见情况是你的 PDF 里扫描页占比大OCR 阶段会吃掉大量 CPU基本等于是按分钟计费的了。5.2 模型下载失败或网络受限这是我在公司内网环境踩得最深的坑。MinerU 首次运行要下载模型但内网经常连不上外网或者 HuggingFace 的连接极不稳定导致模型下载到一半就断掉。推荐的解决办法是在一台能联网的机器上先跑一次 Probe 或随便解析一个小 PDF确保模型完整下载。然后把模型缓存目录整体打包传到内网机器设置环境变量后就可以完全离线跑了。set HF_HOMED:\models\mineru_hf这里有个经验性的细节缓存目录拷贝完之后不要只拷贝看起来像模型文件的那些目录HuggingFace 的缓存体系里有一堆 hash 命名的子目录和 json 索引文件缺一个都可能导致重新下载。最稳妥的做法是整个mineru_hf目录原封不动地搬过去。5.3 Windows 路径、长路径与中文目录Windows 上另一个高频问题就是路径。MinerU 解析过程中会有大量临时文件的读写如果输入路径或者输出路径包含了中文、空格、以及超长嵌套目录就容易莫名其妙报错。我遇到过的报错很多时候压根不提示路径问题而是表现出执行到一半断开找不到模型输出文件为空这种迷惑症状。我的规避方案很直白所有任务相关目录都改成英文短路径比如D:\mineru_data\raw、D:\mineru_data\out避免中文目录和深层嵌套。如果你已经有中文路径下的文件先复制到英文目录再解析不要抱着侥幸心理。另外 Windows 10/11 默认的路径长度限制也可能在解析过程中爆出来。可以在注册表或者组策略里开启长路径支持但我个人更建议从路径规划上绕开而不是去挑战系统限制。5.4 依赖冲突与版本锁定MinerU 的依赖项里有 PyTorch、NumPy、OpenCV、PaddleOCR 相关的组件这些都是出了名的版本敏感户。装完 MinerU 之后我强烈建议立刻导出环境锁定文件。pip freeze requirements_mineru.txt之后如果因为其他项目动过环境导致 MinerU 跑不起来直接重建一个虚拟环境再装一遍锁定文件几分钟就能恢复。Windows 上 conda 环境创建便宜出了问题重建总是比排查依赖树要快。还有一类比较隐蔽的问题Min 环境下多个项目共享site-packages有时候明明是同一个 Python 解释器但装了一个库之后把另一个库的依赖挤掉了。虚拟环境隔离这个原则在 MinerU 上尤其重要因为它吃到的依赖版本范围很窄碰不得。5.5 大 PDF 内存与临时文件解析超大 PDF 时Windows 任务管理器能看到 Python 进程内存飞快上涨。如果遇到内存不足导致崩溃可以尝试分章节处理或者先只解析需要的页码范围。MinerU 的-i参数是支持传具体页码范围还是只支持整份 PDF不同版本表现不同我一般干脆从源头做拆分拿 PyPDF 把大文件拆成几个子文件再逐个解析虽然多一步操作但稳定性显著提升。6. 从 MinerU 延伸出去的一些生产经验6.1 把 MinerU 输出当作中间层来管理我建议不要把 MinerU 的解析结果直接扔进向量库就完事而是把 Markdown 和 JSON 当做一个中间产物统一管理起来。比如每个 PDF 解析完之后把sample.md、sample.json和images目录整体归档这样即使日后要更换嵌入模型、调整切块策略都能直接基于已解析的 Markdown 重新处理不需要重新解析 PDF。这能节省大量成本。6.2 后处理清理脏 MarkdownMinerU 出来的 Markdown 已经不错但距离完美还有距离。我实际处理时发现三类小问题偶尔有重复页眉在正文里残留合并单元格较多的复杂表格会被切成奇怪的 Markdown 结构罕见情况下公式转换会有符号错位。我会在写入向量库前做一层轻量的清洗比如删除页眉页脚固定模式、合并多余空白行、对表格做一次 Markdown 合法性校验。这步不需要很复杂几个正则就能解决大部分问题。6.3 后续还可以这样扩展这个思路并不止步于 MinerU 本身。等你的 PDF 解析管线跑通之后后续可以把同样的处理思路延伸到 Word、PPT甚至 HTML 抓取的正文清洗。RAG 的复杂度从来不在单一环节而在于整个链路是否稳定可复现。MinerU 在 Windows 本地的这一步部署本身就是把这条链路最脆弱的一个环节补上了。我个人把 MinerU 跑通之后最直观的感受是检索体验上升了不止一个档次以前做了向量化还是搜不到答案的文档现在能精准切到正确段落。文档预处理这块投入的时间永远都是 RAG 项目里性价比最高的一笔。
做 RAG 项目这一年多最让我头疼的从来不是向量库选型也不是 Embedding 模型调参而是文档预处理这一步。尤其是 PDF还是那种从系统里导出来、带目录、带页眉页脚、带扫描图片甚至数学公式的复杂 PDF——用传统库提取文本切出来的分块几乎没法看。直到我把 MinerU 4.0 部署到 Windows 本地才算是把这根刺拔掉了一部分。这篇内容不是给你念官方文档是我在实际项目中踩完坑之后整理出来的一套可复现流程。我会把 Windows 上从零装好 MinerU 4.0、跑通离线 PDF 解析、再把结果接进 RAG 预处理脚本的完整链路写清楚包括命令行参数、Python 调用方式、输出目录结构、分块策略、以及我遇到的几个典型问题。适合正在搭知识库、搞 RAG 检索增强、或者被 PDF 解析质量折磨到睡不着的同学参考。1. 为什么是 MinerU而不是那堆免费 PDF 库1.1 大多数 RAG 应用都倒在切出来读不懂很多人一开始做 RAG 时都会顺手用 pdfplumber 或者 PyPDF2 把 PDF 文本抽出来然后丢给一个固定长度的文本分割器。这种方案在小规模、排版简单的文档上没问题一旦遇到论文、两栏排版、复杂表格、页脚页码、或者扫描件问题立刻就出来了。这类库本质上只是按页面物理顺序把字符捞出来根本不管版面。PDF 在视觉上明明是左右两栏抽取结果却是一列文字读完后跳到右侧切出来的 chunk 语义支离破碎。表格更惨行和列的边界信息全部丢失抽出来就是一行行碎片。公式就更不用提了PDF 里的数学符号被拆成 Unicode 字符之后基本不可读。这个阶段的痛点不在于检索算法而在于第一公里的提质量。检索召回的上限基本是分割前就定死的喂进去的是垃圾向量化再精细也白搭。1.2 MinerU 4.0 在管线里到底做了什么MinerU 做的事情其实是一整套文档版面还原的活它不是一个简单的文本抽取器而是一个视觉规则的混合管线。输入端是 PDF 文件输出端是结构化的 Markdown 文件和对应的 JSON 元数据。它的核心工作流程大致是这样的先做版面检测识别页面里的标题、正文、图片、表格、页眉页脚、公式等区域而不是傻乎乎地把整页当成一段文本。然后对检测到的区域分别处理文本块走 OCR 或者原生文本提取表格块走专门的表格结构识别公式块会转成 LaTeX 语法。最后根据版面检测结果重组阅读顺序把多栏排版还原成符合人类阅读顺序的线性文本再导出成 Markdown。这一步很关键。经过 MinerU 处理之后我从 PDF 里拿到的是一个干净版文档而不是一堆长得像文本的碎片。1.3 适用的场景和不适合的场景我自己的项目里最适用 MinerU 的几类文档论文 PDF、技术手册、产品说明书、合同扫描件、带图片的培训资料、以及包含大量公式的学术材料。这些文档的共同特点是版面结构复杂纯文本抽取根本扛不住。不太适合的场景也有。比如你要处理的是一堆只有几行字的简单 PDF用 MinerU 有点杀鸡用牛刀解析速度反而不如轻量库快。另外如果你只有 CPU 机器且需要大量实时解析那也得慎重离线解析不是不能跑但是速度会明显偏慢更适合做成批处理任务而不是在线服务。2. Windows 部署环境、安装、模型初始化2.1 版本选型与环境准备先说结论Windows 上我推荐用 Python 3.10 搭配独立的虚拟环境来装 MinerU不要直接怼到系统 Python 里。这个项目依赖的 PyTorch、布局检测模型、OCR 组件都比较大依赖树也比较长放进全局环境以后很容易跟别的项目打架。创建虚拟环境这一步我会用 conda 而不是 venv。原因很实际conda 在 Windows 上管理 CUDA 相关依赖和 Python 版本切换更省心尤其是当你机器上同时有多个 Python 版本的时候。conda create -n mineru python3.10 conda activate mineru接下来确认 PyTorch 的安装方式。如果你机器上有 NVIDIA 显卡并且能跑 CUDA那就装 GPU 版解析速度会有数量级的提升。没有显卡也没关系CPU 版能跑只是慢一些后面我会专门说性能相关的优化。# GPU 版示例cuda 版本以你本地 nvidia-smi 显示的为准 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121装完之后用python -c import torch; print(torch.cuda.is_available())验证一下。如果输出 True说明环境正常后面跑起来会顺很多。2.2 安装 MinerU 与基础校验MinerU 4.0 已经把主要的解析能力整合到一个 pip 包里安装命令比旧版本清爽不少pip install mineru老读者如果接触过早期的 magic-pdf 那套东西应该知道之前还需要额外装模型仓库、跑安装脚本之类的事情。4.0 版本把流程简化了包装好之后直接用mineru-cli这个命令来干活。装完先别急着解析文件跑一下版本和环境自检mineru-cli --version mineru-cli probeprobe会检查你的运行环境是否满足要求包括 PyTorch 是否正常、是否能检测到 GPU、模型目录是否可写等。这一步能提前暴露很多问题不要跳过。2.3 模型的离线下载与缓存策略MinerU 的解析依赖几个深度学习模型权重这些模型在第一次使用时需要下载。官方默认会从 HuggingFace 拉模型下载好的模型放在~/.cache/huggingface这种系统默认缓存目录里。这里就是离线部署的关键点了。如果你所在的网络环境访问外网不稳定或者你压根就是要在一台离线的机器上部署我建议你在一台能联网的机器上先把模型下载完整然后把整个模型缓存目录拷贝到离线机器上再用环境变量指过去。具体操作# 先设置缓存目录不设置就默认 set HF_HOMED:\models\hf首次执行一次解析命令让 MinerU 把模型全部拉到D:\models\hf目录里。之后你把整个hf文件夹拷贝到离线机器上同样设置HF_HOME指向它就可以完全离线运行。需要注意模型总量不小小几个 G 的量级很正常拷贝时用移动硬盘或者内网传输都行但不建议用 U 盘这种容易出坏道的介质反复折腾。3. CLI 实操将 PDF 转为 Markdown3.1 一条命令入手先说明一点MinerU 4.x 的 CLI 入口是mineru-cli如果你在网上搜到旧教程里的magic-pdf命令那大概率是历史版本别照着敲。同一条功能在 4.0 里的对应操作是这样的。先看命令行自带帮助mineru-cli extract --help我平时最常用的解析命令长这样mineru-cli extract -i input.pdf -o output_dir -p 4 -f md参数含义我整理在下面这张表里参数作用我的建议-i指定输入 PDF 路径也可以是目录目录模式下会批量处理里面所有 PDF-o指定输出目录建议每次解析单独建一个目录别混-p并行进程数CPU 机器建议 2-4GPU 机器可以拉到 8 甚至更高-f输出格式可选md、json、或者both-b批量模式开关配合-i指向的目录使用一个比较稳妥的起步命令是mineru-cli extract -i D:\data\docs\sample.pdf -o D:\data\parsed -p 4 -f md执行过程中会看到类似layout detect、table predict之类的日志在滚动说明版面检测和表格识别正在跑。等日志完全停下来去输出目录里看结果。3.2 批量处理生产目录下的全部 PDF实际项目里很少只处理一个文件我一般会建一个raw_docs目录把所有待解析 PDF 扔进去然后这样跑mineru-cli extract -i D:\data\raw_docs -o D:\data\parsed -p 4 -f both -b-b开启批量模式之后输出目录里每个 PDF 都会得到一个独立的子目录里面放着各自的 Markdown 和 JSON 文件。这样元数据不会串后续做增量索引也方便。有一点要说清楚批量解析非常吃资源。如果你用 CPU 跑一次丢进去二三十个 PDF并行数又拉满机器基本处于满载状态这时候别同时干别的重活。建议分批或者降低-p。3.3 输出目录结构里的门道跑完一次解析之后你会发现输出目录里不止一个文件。典型的结构是这样的output_dir/ sample.pdf/ images/ 1.jpg 2.png sample.md sample.jsonsample.md是最终的可读版本表格被转换成了 Markdown 表格公式变成了 LaTeX 文本图片则以相对路径的形式嵌在 Markdown 里。sample.json才是真正精细的东西。它记录了每个页面的版面检测结果包括每个文本块、表格、图片的坐标框、页面序号、类型标签和原始内容。做 RAG 的时候我会用 JSON 里的元信息来辅助切块比如知道某一块内容来自第几页、属于标题还是正文、是否处于表格区域。images目录则是所有的图片资产里面可能是 PDF 里本来就有的图片也可能是通过版面检测被单独拆出来的图形区域。这些图片在后面的多模态 RAG 场景里会用到我先放个引子后面展开说。4. Python API 集成到 RAG 预处理流水线4.1 直接调用 MinerU 的最小代码CLI 适合人工操作和批处理但如果你想把它嵌进自己的数据管道里还是得走 Python API。MinerU 4.0 的最小调用不是很复杂大致结构如下。from mineru import MinerU mineru MinerU( model_sourcehuggingface, devicecuda, output_formatmd, ) result mineru.run(D:/data/raw_docs/sample.pdf)device参数可以设为cuda或者cpu。在我的 Windows 机器上GPU 调用和 CLI 模式的表现一致。如果你不确定参数细节先执行一遍解析再打印result的结构看看它里面有哪些字段比看文档更直观。有一个小坑某些配置项在不同小版本里名字可能微调如果你装的版本报参数错误直接把MinerU(...)里的参数删掉只保留 PDF 路径用默认配置跑一遍。这样最稳。4.2 针对 RAG 优化的 Markdown 分块示例MinerU 拿到的是结构良好的 Markdown但 RAG 切块还得自己设计。我自己的策略是按标题层级分块保护表格段落完整性。举例来说MinerU 导出的 Markdown 有明确的标题层级我可以用标题作为天然的分块边界。同时对表格单独处理不让一个表格被拦腰切成两半。下面是我项目里实际用的一套轻量分块代码。import re import json def split_markdown_by_heading(md_text, max_len1200, overlap100): lines md_text.splitlines() chunks [] buffer [] buffer_len 0 heading for line in lines: # 判断是不是标题行 m re.match(r^(#{1,4})\s(.*), line) if m and buffer_len 200: if buffer: chunks.append({ heading: heading, text: \n.join(buffer).strip(), }) heading m.group(2).strip() buffer [line] buffer_len len(line) else: buffer.append(line) buffer_len len(line) 1 if buffer_len max_len: if buffer: chunks.append({ heading: heading, text: \n.join(buffer).strip(), }) # 用尾部 overlap 保证上下文连续 buffer buffer[-overlap:] buffer_len sum(len(x) 1 for x in buffer) if buffer: chunks.append({ heading: heading, text: \n.join(buffer).strip(), }) return chunks这段代码不算精致但胜在简单可控。核心思想是以 Markdown 的标题结构作为语义边界标题变了就切一段段落太长则按最大长度截断同时保留尾部部分文本作为和下一段的 overlap。4.3 与嵌入模型和向量库的对接建议切块之后下一步就是把文本向量化存入向量库。这部分可选方案很成熟了比如 Ollama 本地跑 Embedding 模型、FastEmbed 这种轻量库或者企业场景里把文本灌给线上的 Embedding API。我的建议是在 MinerU 解析出来的 Markdown 基础上切块不要把 Raw PDF 文本直接做向量化。你可以在向量库的 metadata 里记录来源文件、页码、标题、块类型这样检索出来之后能反查到原文位置。4.4 图片资产与多模态 RAG 的配合很多人问过一个比较普遍的问题RAG 知识库能存储图片吗要做到能存图片一个关键前提是你的解析工具能把图片从原文档里完整体地扒出来而不只是把 OCR 结果变成一行文字。MinerU 在这点上有天然优势。它解析时会把版面检测到的图片单独保存到 images 目录并且在 Markdown 里用相对路径引用。这样你的分块文本里如果带这种引用你就可以在构建索引的时候把图片文件路径也记录下来。后续如果接一个多模态 Embedding 或者视觉语言模型就可以真正做到文字检索到图片、还能返回图片内容。哪怕暂时只做纯文本 RAG图片路径也值得保留因为检索结果页面反馈时可以展示缩略图体验完全不一样。5. 真实现场Windows 上常见的坑与排查5.1 慢得像拖拉机性能问题怎么解CPU 在没有 GPU 的情况下跑 MinerU速度真的会让人焦虑。一份 100 页的 PDFCPU 跑可能要几分钟到十几分钟而在 GPU 上可能只要一两分钟。排查思路很简单。先跑mineru-cli probe看环境是否正常识别到了 GPU再确认 PyTorch 是不是 CUDA 版本。如果这两项都没问题那就是并行数设置的问题-p参数尽量往高了给但要给系统留出余量。我的经验是CPU 机器上-p 2到-p 4可控GPU 机器上-p 4到-p 8效果不错。还有一种常见情况是你的 PDF 里扫描页占比大OCR 阶段会吃掉大量 CPU基本等于是按分钟计费的了。5.2 模型下载失败或网络受限这是我在公司内网环境踩得最深的坑。MinerU 首次运行要下载模型但内网经常连不上外网或者 HuggingFace 的连接极不稳定导致模型下载到一半就断掉。推荐的解决办法是在一台能联网的机器上先跑一次 Probe 或随便解析一个小 PDF确保模型完整下载。然后把模型缓存目录整体打包传到内网机器设置环境变量后就可以完全离线跑了。set HF_HOMED:\models\mineru_hf这里有个经验性的细节缓存目录拷贝完之后不要只拷贝看起来像模型文件的那些目录HuggingFace 的缓存体系里有一堆 hash 命名的子目录和 json 索引文件缺一个都可能导致重新下载。最稳妥的做法是整个mineru_hf目录原封不动地搬过去。5.3 Windows 路径、长路径与中文目录Windows 上另一个高频问题就是路径。MinerU 解析过程中会有大量临时文件的读写如果输入路径或者输出路径包含了中文、空格、以及超长嵌套目录就容易莫名其妙报错。我遇到过的报错很多时候压根不提示路径问题而是表现出执行到一半断开找不到模型输出文件为空这种迷惑症状。我的规避方案很直白所有任务相关目录都改成英文短路径比如D:\mineru_data\raw、D:\mineru_data\out避免中文目录和深层嵌套。如果你已经有中文路径下的文件先复制到英文目录再解析不要抱着侥幸心理。另外 Windows 10/11 默认的路径长度限制也可能在解析过程中爆出来。可以在注册表或者组策略里开启长路径支持但我个人更建议从路径规划上绕开而不是去挑战系统限制。5.4 依赖冲突与版本锁定MinerU 的依赖项里有 PyTorch、NumPy、OpenCV、PaddleOCR 相关的组件这些都是出了名的版本敏感户。装完 MinerU 之后我强烈建议立刻导出环境锁定文件。pip freeze requirements_mineru.txt之后如果因为其他项目动过环境导致 MinerU 跑不起来直接重建一个虚拟环境再装一遍锁定文件几分钟就能恢复。Windows 上 conda 环境创建便宜出了问题重建总是比排查依赖树要快。还有一类比较隐蔽的问题Min 环境下多个项目共享site-packages有时候明明是同一个 Python 解释器但装了一个库之后把另一个库的依赖挤掉了。虚拟环境隔离这个原则在 MinerU 上尤其重要因为它吃到的依赖版本范围很窄碰不得。5.5 大 PDF 内存与临时文件解析超大 PDF 时Windows 任务管理器能看到 Python 进程内存飞快上涨。如果遇到内存不足导致崩溃可以尝试分章节处理或者先只解析需要的页码范围。MinerU 的-i参数是支持传具体页码范围还是只支持整份 PDF不同版本表现不同我一般干脆从源头做拆分拿 PyPDF 把大文件拆成几个子文件再逐个解析虽然多一步操作但稳定性显著提升。6. 从 MinerU 延伸出去的一些生产经验6.1 把 MinerU 输出当作中间层来管理我建议不要把 MinerU 的解析结果直接扔进向量库就完事而是把 Markdown 和 JSON 当做一个中间产物统一管理起来。比如每个 PDF 解析完之后把sample.md、sample.json和images目录整体归档这样即使日后要更换嵌入模型、调整切块策略都能直接基于已解析的 Markdown 重新处理不需要重新解析 PDF。这能节省大量成本。6.2 后处理清理脏 MarkdownMinerU 出来的 Markdown 已经不错但距离完美还有距离。我实际处理时发现三类小问题偶尔有重复页眉在正文里残留合并单元格较多的复杂表格会被切成奇怪的 Markdown 结构罕见情况下公式转换会有符号错位。我会在写入向量库前做一层轻量的清洗比如删除页眉页脚固定模式、合并多余空白行、对表格做一次 Markdown 合法性校验。这步不需要很复杂几个正则就能解决大部分问题。6.3 后续还可以这样扩展这个思路并不止步于 MinerU 本身。等你的 PDF 解析管线跑通之后后续可以把同样的处理思路延伸到 Word、PPT甚至 HTML 抓取的正文清洗。RAG 的复杂度从来不在单一环节而在于整个链路是否稳定可复现。MinerU 在 Windows 本地的这一步部署本身就是把这条链路最脆弱的一个环节补上了。我个人把 MinerU 跑通之后最直观的感受是检索体验上升了不止一个档次以前做了向量化还是搜不到答案的文档现在能精准切到正确段落。文档预处理这块投入的时间永远都是 RAG 项目里性价比最高的一笔。
