1. Windows 本地部署 MinerU：RAG 文档预处理的正确姿势
先说个直白结论：很多 RAG 项目做不好，问题不在向量库、不在 embedding 模型，而在上游第一步——PDF 解析就是脏的。文档里明明是表格，解析出来变成一行行死文字；公式连符号都糊成一团；双栏论文被粗暴地按阅读顺序串成一段话。数据源是垃圾，后面的分块、向量化、检索就是垃圾上堆砌的高楼。MinerU（就是早期 magic-pdf 重构后的名字）是我目前用的比较顺手的离线 PDF 解析工具，基于深度学习模型做版面分析、公式识别、OCR 补全，把 PDF 还原成带结构的 Markdown。这篇文就围绕 Windows 本地部署 MinerU 4.0 展开，覆盖环境安装、命令行实操、输出产物解读、RAG 分块接驳，还有我在本机上踩过的坑，一步一步给你讲清楚。
先给读者画像：你大概率是正在搭本地知识库的开发者或研究者，手头有大量 PDF（论文、技术手册、行业报告），想搭一套离线、可控的文档预处理管线。MinerU 特别适合你，原因有三。第一，它本地跑，文档不出机器，机密资料不需要上传第三方接口；第二，输出是干净的 Markdown，保留标题层级、表格、公式 Latex，直接对接后续切分逻辑；第三，Windows 部署虽然有点琐碎，但一次配好，批量跑 PDF 只是命令行循环的事。我下面写的东西，就是按“零基础但懂 Python 环境”的水平来组织的，不会有没头没尾的跳步。
网上讨论 MinerU 的帖子不少，但大多侧重介绍能力，真正讲 Windows 端到端落地的还是少。我这篇会更偏工程：版本怎么选、模型怎么离线摆平、参数按什么逻辑定、输出目录哪些可以删、哪些要留、批量解析脚本怎么写。这都是一条条过出来的，不是抄官方 README。
1.1 为什么 RAG 的瓶颈往往在“文档预处理”
RAG 的完整链路是：文档解析 -> 分块 -> embedding -> 向量存储 -> 检索 -> 生成。大多数人把时间花在选 embedding 模型和调向量库参数上，可检索效果不好、生成答案驴唇不对马嘴，回溯溯源时才发现，问题从第一步就埋下了。
具体来说，用 pymupdf、pdfplumber 这些传统工具提取 PDF，本质上拿的是内部文本流，它对版式是无能为力的。一篇两栏排版的 PDF，如果不做特殊处理，文本流会把左栏第一行、右栏第一行交错混在一起；表格线的逻辑关系完全丢失，提取出来的单元格是一个接一个的裸文本；公式在 PDF 里常常是特殊字形或图片，传统工具要么拿到一串乱码，要么直接空白；扫描版 PDF 更是毫无办法，没有文本层，只能走 OCR。
这些解析产物直接进分块，就产生三种连锁问题。第一，语义被切断：原本一个标题下的内容散落到各块里，检索时丢了上下文。第二，块内噪音大：表格、公式、页眉页脚混在一起，embedding 拿这些向量去匹配 query，命中一堆无关内容。第三，溯源难：文档里引用的页码、图表编号都没了，检索结果给了你也难以定位。这也是为什么现在较成熟的 RAG 项目都在文档解析环节单独花力气。MinerU 这类工具的价值就在这儿：它不是简单抽文本，而是把版面、公式、表格、OCR 识别都做掉，输出一种适合机器理解的结构化中间文件，后面分块、检索的路就好走很多。
1.2 MinerU 的核心能力与定位
MinerU 的目标是把 PDF 转成 Markdown，但它的本质是数个模型的组合管道。官方 4.0 版本在架构上做了不少整合，核心链路大致是：文档解析器先把 PDF 按页切成图像或文本区域，版面模型（基于深度学习的 Layout 检测）识别每个区域的类型——标题、段落、表格、公式、页眉页脚、图片注；文本区域走文本提取，没有文本层或文字残缺的区域走 OCR；表格区域单独做表格结构还原；公式区域用专门的公式识别模型转成 Latex。最后把所有区域按版面顺序组装成 Markdown，同时生成一个多层级 JSON。
它在 RAG 预处理中的定位，简单说就是“厂商中立、离线可用、输出规范”的文档结构化引擎。对比在线解析 API，它没有数据出境风险；对比传统 PDF 提取库，它多了一层深度学习版面理解能力。输出方面，一份 40 页的 PDF 经它处理后，会得到一个完整 Markdown、一个内容 JSON、若干图片和表格附件。Markdown 可以直接拿去切分做 embedding；JSON 保留了更多细节（如坐标框、类型置信度），适合做质检和二次清洗；图片则可以作为独立资源管理，文本引擎吃不到的图表内容，RAG 日后也能以多模态方式扩展。它能做的事很清楚：把“不可读”的 PDF 变成“可读、可切、可检索”的文本结构。这个定位，正好卡在 RAG 管线的最前端，也决定了它比通用 OCR 工具更适合做知识库底座。
2. Windows 环境准备：依赖、安装与模型离线摆平
Windows 部署 MinerU，本质上就三件事：准备好 Python 环境、装对依赖、把模型文件放到机器上。前两件没弄对，后面 HTTPS 下载模型必报错；模型不提前规划，第一次运行可能卡在下载上大半天。我建议一开始就把“离线运行”作为目标来做，因为模型下载这步是很多新手在 Windows 上失败的重灾区。下面我按顺序讲，你照做就行。
2.1 Python 版本与虚拟环境要求
先说版本基线。MinerU 4.0 官方支持的 Python 是 3.10 到 3.12，超过 3.12 就警告说“某些 C 扩展编译可能失败”。Windows 上尤其如此，因为部分依赖（特别是 PyTorch 相关的 wheel）在新 Python 版本上选择面窄。我实测用的 Python 3.10.11，全程没什么坑。Python 3.13 我当时也试过，pip install 阶段就有一个编译报错，直接劝退，所以别图版本新，稳定第一。
然后是虚拟环境。MinerU 的依赖树很长，我数了下大概有几十个包，直接装进系统 Python 容易和已有的环境冲突。Windows 上装纯 CPU 版时，它依赖的 onnxruntime 和 PyTorch 体积都不小，如果日后再装别的深度学习工具，很容易发生版本冲突。我的建议是建一个独立的虚拟环境，用 venv 就行，不需要 conda 那套：
cd D:\tools python -m venv mineru_env mineru_env\Scripts\activate这里有个 Windows 特有的问题：powershell 默认可能不允许执行 activate 脚本，会报“禁止运行脚本”的错误。解决办法是用管理员身份打开 PowerShell 执行一次：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser或者干脆改用 Git Bash / CMD 来激活环境，就没这个困扰。我个人在 Windows 上一直搭配 Git Bash 用，日常命令体验比 cmd 舒服，后面命令行示例也统一用 bash 风格。
2.2 安装 MinerU：CPU 版与 CUDA 版的选择
MinerU 本身支持两种推理后端：CPU 和 CUDA。安装命令差别主要在 PyTorch 的 extra index 上。如果你是 NVIDIA 显卡且显存足够（建议至少 8G，实测 6G 跑大 PDF 会 OOM），可以装 CUDA 版，速度提升明显；否则就老老实实用 CPU 版，速度虽然慢，但一台普通办公电脑也能跑。
CPU 版命令：
pip install mineruCUDA 版（以 cu121 为例）：
pip install mineru --extra-index-url https://download.pytorch.org/whl/cu121装完以后，建议先验证 PyTorch 是否吃到了 CUDA：
python -c "import torch; print(torch.cuda.is_available())"如果输出 False，那你后面指定--device cuda必报错，不如直接装 CPU 版省心。这一步超多人忽略，好多人装完 CUDA 版 mineru，跑的时候一直报 CUDA error，多半是 PyTorch 和显卡驱动不匹配。
MinerU 安装包在 Windows 下还有一个坑：部分依赖的编译需要 MSVC Build Tools，如果 pip install 报到error: Microsoft Visual C++ 14.0 or greater is required，你就得去装 Visual Studio Build Tools，选“使用 C++ 的桌面开发”工作负载。装了以后重新开终端再 pip install 就行。
2.3 模型离线配置：别让首次运行卡死在下载上
MinerU 的模型是运行时按需从 Hugging Face 或 ModelScope 拉取的，默认缓存在用户目录下。第一次跑在线时，要下载约 1.5G 到 2G 的模型文件，包括版面检测模型、公式识别模型、OCR 模型等等。在大陆网络环境下，这一步失败率不低。你在 Windows 上如果直接跑，很常见的情况是：日志刷一堆下载进度，然后卡在某个模型上超时，整个命令就挂了。我的建议是事前把模型准备好，走“一次下载、永久离线”的路径。
具体做法是：先在一台能稳定联网的机器上，跑一遍官方提供的模型下载脚本，或者直接指定--download_models之类的参数让 MinerU 把模型拉到本地缓存目录，然后把缓存目录完整拷到目标机器的相同路径下。MinerU 支持通过环境变量指定模型缓存位置，比如：
export MINERU_MODEL_DIR=/d/models/mineru-models然后把所有模型文件放到这个目录。后续跑命令时，MinerU 检测到本地模型目录就不再去远端拉了。注意，模型目录结构有严格约定，不要随意改子文件夹名称。如果你只盯着某个模型缺失去单独下载，可能出现版本不匹配导致的推理失败。
还有一个常见问题：模型文件被 Windows Defender 当病毒隔离的案例不少，因为 ONNX 模型文件的二进制结构偶尔会触发杀软的“威胁检测”。建议把模型目录和后续的分析输出目录加入 Defender 排除列表，否则可能莫名其妙地“缓存损坏”。我这一步实测踩过，当时一个模型文件反复被隔离，我在日志里看到“PermissionError”才发现元凶是实时防护。排除之后，一切正常。
3. PDF 解析全流程：命令行上手、参数解读与输出产物
装好环境之后，真正开始干活之前，建议先摸清 MinerU 的命令行参数。说实话，它对参数的处理比早期版复杂不少，新版本把很多逻辑拆成了显式开关，理解每个开关的用途就是理解它的整个工作流程。我下面按照“从简单到复杂”的顺序讲，既适合快速上手，也方便后面批量解析。
3.1 命令行快速上手
一条最基本的解析命令长这样：
mineru -p "D:/docs/sample.pdf" -o "D:/docs/output" --device cpu --lang zh解释一下每个参数：
-p指定输入 PDF 文件路径，可以是单个文件，也可以是目录。目录模式下会批量解析目录下所有 PDF。-o指定输出目录，解析结果会按 PDF 文件名生成子目录。--device指定推理设备，可选cpu或cuda。--lang指定语言，中文文档写zh。这个参数直接影响 OCR 的语言模型，不设的话中文识别率会打折扣。
跑完后，输出目录里会出现以 PDF 文件名命名的子目录，里面有三个核心文件：sample.md就是完整的 Markdown 文档；sample.json是结构化的 JSON 内容文件；sample_ocr.json（如果走了 OCR 流程）是 OCR 明细。此外通常还有images/文件夹，存放 PDF 页面中抽取出来的图片资源，表格附件等。
跑一个 20 页的排版复杂 PDF，CPU 模式下大约要一到三分钟，取决于页面是否包含大量扫描图。CUDA 能快上不少，但对显存有要求。你可以在第一次跑的时候打开任务管理器看一下 CPU 或 GPU 的占用，确认推理确实在跑，免得以为卡死了。
3.2 关键参数选型：OCR 要不要全开？格式怎么定？
MinerU 4.0 里有一个关键选择，是“文本模式”和“OCR 模式”的取舍。简单说，PDF 分两类：有文本层的（可以选中文字，比如大部分用排版软件生成的文件），以及无文本层的（扫描件、图片型 PDF）。如果你对所有 PDF 都无脑走 OCR，速度和资源开销成倍上升，而且对于已经带文本层的文件，OCR 识别反而可能引入识别错误。我的建议是，先快速判断一下 PDF 是否有文本层，可以用 pymupdf 一行代码看：
import fitz doc = fitz.open("sample.pdf") page = doc[0] print(len(page.get_text()))如果 len 输出大于 100，说明文本层是完整的，MinerU 自动用文本模式，不用强制 OCR；反之，对于扫描件才考虑 OCR 模式。MinerU 在文本模式下遇到文字缺失区域也会自动补 OCR，不需要你全局打开 OCR 开关。这个细节很重要，它直接影响大批量文件的处理速度。
另外，Mind 别忽略语言参数。多语言混排文件（比如英文论文里夹了中文综述、中英对照手册）建议设--lang zh，因为它内部会加载一个支持中文的 OCR 模型，对中文字形识别更准确。纯英文文档可以设en，识别模型会走英文专用路径。
另外一个值得说的是表格解析。MinerU 能把表格还原成 Markdown 表格结构，这对 RAG 分块意义很大，因为表格是强结构化内容。但它对复杂表格（跨页表、合并单元格多、表头错位）的还原偶尔会走样，输出里会出现断裂的竖线或错位。我的建议是：解析完挑几页表格密集的 PDF 人工瞄一眼，对的直接用，错的就考虑在原 PDF 上做区域裁剪或者替换成截图作为多模态资源再入知识库。别指望一个模型包打天下，工程化时接受“部分内容需要人工抽检”，是成熟的预处理思路。
3.3 输出目录结构与 Markdown 质量判断
解析完成后，打开sample.md，看看内容组织是否正常，这是最直接的质检手段。一份高质量的解析结果应该有这几个特征：
标题层级清晰，一级标题、二级标题、正文段落合理分层，而不是一串连续的黑体字；页眉页脚被剔除或单独标注，不会出现在正文流里；公式以 Latex 形式嵌入，比如$E=mc^2$；表格被转成了正常的 Markdown 表格，列和列之间由|分隔。如果你看到内容之间出现大段空白、乱序段落、连续的=====之类的奇怪符号，说明版面模型在某些页上没处理好，这时要么调整参数，要么将这类 PDF 排除在自动管线之外。
关于 JSON 文件，它其实是调试时的第一手现场，记录了每个区域的类型、坐标和文本内容。比如你后来发现某页解析错了，打开 JSON 对照 PDF 原图，能直观看到模型当时把哪块误判成了什么。我用它做质量抽检的比例大概是每十份文档抽查两到三份，重点看表格和公式区域。如果 JSON 里该区域类型是table，但置信度只有 0.4 几，基本上表格还原质量都悬，我建议这类文档简单标记，后续人工处理。
3.4 补充一点模型原理：为什么它比传统 OCR 强
顺手说点原理层面的感想。传统 PDF 解析走的是“规则 + 字典”，本质是拿现成工具函数去抽文本，遇到布局就变通处理。MinerU 走的是“区域检测 + 分类识别”，模型先告诉你页面上哪个框是标题、哪个框是表格、哪个框是公式，然后针对不同区域调不同的识别引擎。这个思路在工程上优势明显：每个环节都有专门模型兜底，不必在一套通用规则里撞运气。你在实际部署时、遇到奇形怪状的 PDF，会明显体会到这种“识别+理解”式架构的鲁棒性。这也是我为什么愿意写这篇长文细聊它的部署细节。
4. 解析结果接进 RAG：分块策略、批量脚本与检索优化
MinerU 的输出只是预处理环节，它产出 Markdown 之后，能不能真正转化为 RAG 效果上的提升，完全取决于下游怎么用。我见过不少项目解析完直接把整个 Markdown 塞进向量库，这其实浪费了结构信息。下面我来拆一下怎么把这锅原料炒成菜。
4.1 从 Markdown 到分块：怎么切才不切碎语义
分块是 RAG 最微妙的一环，块太小，上下文不全，检索命中后生成质量差；块太大，向量表示被稀释，精确匹配率下降。一种比较稳的思路是：基于 Markdown 的标题层级来定分块边界。也就是说，一个二级标题及其下属内容，天然是一个逻辑块；块内再按段落或 token 数量二次细分。这比单纯按固定 token 长度硬切好很多，因为你避开了“一段话被拦腰截断”的情况。
实操时，我的建议是先用代码读入 Markdown，提取出标题的层级（#、##、###），把整篇文档展开为一棵大纲树。然后做两层切分：第一层按标题边界切，第二层对超长节点按 token 窗口二次切，并设置重叠（比如chunk_size=500、overlap=80）。这样分出来的块，既保留了语义完整体，又不会因目录标题级别太深导致块数爆炸。
对于 MinerU 标记出的公式区域，如果你用的 embedding 模型不支持 Latex 符号，那公式块中的关键词可能无法正确编码。我建议把“纯公式型块”单独存一个元数据字段，检索时不参与向量匹配，只在溯源时展示。这样不会拉低整体检索效果，也保留了原文可读性。
4.2 批量解析脚本与失败重试机制
单文件命令行玩明白之后，批量处理就很简单了。我在 Windows 上写了一个 Python 脚本，用系统调用的方式把mineru包装成子进程，遍历指定目录下所有 PDF，出错自动跳过并写日志。核心逻辑大致如下：
import subprocess, os, sys, time from pathlib import Path INPUT_DIR = Path(r"D:\docs\source") OUTPUT_DIR = Path(r"D:\docs\parsed") FAIL_LOG = Path(r"D:\docs\fail.log") pdf_files = list(INPUT_DIR.rglob("*.pdf")) print(f"共发现 {len(pdf_files)} 个 PDF") for i, pdf in enumerate(pdf_files, 1): out_sub = OUTPUT_DIR / pdf.stem if out_sub.exists() and (out_sub / f"{pdf.stem}.md").exists(): print(f"[{i}/{len(pdf_files)}] 跳过已完成: {pdf.name}") continue cmd = [ "mineru", "-p", str(pdf), "-o", str(OUTPUT_DIR), "--device", "cpu", "--lang", "zh", ] print(f"[{i}/{len(pdf_files)}] 解析: {pdf.name}") try: subprocess.run(cmd, check=True, timeout=600) except subprocess.TimeoutExpired: with open(FAIL_LOG, "a", encoding="utf-8") as f: f.write(f"timeout {pdf}\n") except subprocess.CalledProcessError as e: with open(FAIL_LOG, "a", encoding="utf-8") as f: f.write(f"error {pdf} {e}\n") time.sleep(1)这段脚本里值得说道的有几个设计。一是“先检查输出目录是否存在对应 md 文件，存在就跳过”，这是断点续跑的关键，万一中途断电或程序崩溃，重新运行不会重复处理已完成文件，能省下大量时间。二是timeout=600，单个 PDF 超过十分钟基本可以判定异常，直接跳过，避免进程卡死拖垮整个批次。三是失败日志写入 UTF-8 编码，Windows 控制台默认 GBK 容易乱码，指定编码是必要的习惯。
写这个循环时注意：MinerU 解析过程中会读入模型和大量中间文件，Windows 的杀毒软件可能实时扫描这些文件，影响性能。批量跑几小时后，如果发现越来越慢，可以考虑把模型目录和输出目录加入 Defender 排除列表。我后来加了排除列表后，批量速度提升了约 20%，这是实打实的时间收益。
4.3 解析结果怎么配合向量库与元数据
解析完成后的 Markdown 和 JSON，不要只用来生成文本块。JSON 里有页码信息、区域坐标、图片路径，这些都是高质量元数据。导入向量库时，我建议把以下几个字段一并写入每条 chunk 的 metadata：
- 源文件名和页码，方便定位引用；
- 标题层级路径，比如“3.2 关键参数选型”，可用于层级化检索展示；
- 该块的类型标签（正文、表格、公式、页眉页脚），用于检索时过滤或加权；
- 关联图片或表格的路径，后续若有需要可以扩展多模态检索。
在 embedding 之前，我会对 Markdown 内容做一层轻量清洗：去掉可能残留的空格缩进，把连续换行合并成单换行，把$...$行内的 Latex 转义检查一遍。不要过度清洗，太激进的清洗会丢掉结构符号，影响分块逻辑。这些细节看似繁琐，却往往是决定检索召回率高低的关键。同一份文档，用清洗后的结构化文本做 embedding 和用原始文本做 embedding，命中率差距肉眼可见。
5. Windows 常见问题排查与实操心得
到这一步，环境、解析、接驳都走通后，剩下的就是 Windows 特有的一些疑难杂症了。这些问题我没法全部在第一次就预判到，但经历了几个项目之后，我整理了一份排查清单，按爆率从高到低排列。你日后遇到问题，直接对照这一节来查，能省不少寻找时间。
5.1 CUDA 设备相关：torch.cuda.is_available() 为 False
这个报错的频率最高。很多人的机器装了 NVIDIA 驱动，但 PyTorch 用的 CUDA 工具包版本和驱动版本不兼容，导致is_available()返回 False。在安装 MinerU 之后，运行前先跑一次探测：
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"如果版本输出是2.x.x+cu121但is_available()是 False，优先检查驱动版本是否过旧，更新驱动，或者重新安装对应 cu118 / cu121 版本。另一种情况是显卡显存太小（比如 4G），MinerU 在 CUDA 模式下页面稍微复杂就直接 OOM。此时建议--device cpu而不是强行割裂显存，CPU 慢但至少稳定。倘若只是笔记本办公用途，尽量选 CPU 版安装，省去 CUDA 依赖带来的麻烦。
还有一个隐蔽坑：某些笔记本有双显卡（核显 + 独显），MinerU 跑在核显上时 CUDA 自然不可用。你可以通过 Windows 图形设置，把 Python 进程强制分配为“高性能”，指定给 NVIDIA 独显工作，然后再探测一次。
5.2 模型下载与离线部署：如何彻底避免网络问题
如果你按前面第 2.3 节的方法提前准备好了模型目录，这一步基本不会踩坑。但如果你在网络不稳的环境下直接开始跑，常见的报错是requests.exceptions.ConnectionError、Timeout、MaxRetryError等。解决办法是设置环境变量，把模型下载地址切到镜像源：
export HF_ENDPOINT=https://hf-mirror.com然后重跑 MinerU。注意这个环境变量只在当前终端生效，重启终端需要重新设置。嫌麻烦的，可以在 Windows 系统环境变量里加一个持久条目。另外，MinerU 也支持指定 ModelScope 作为模型来源，如果你在阿里云内网或有相关服务依赖，可以查对应文档。但最稳的方案还是“一台在线机器下载，拷贝到目标机器”，这也是离线部署的标准思路。
离线部署后，务必验证一下模型目录结构是否完整。MinerU 启动时会自检模型文件，如果缺了某个文件，日志里会有明确提示。常见问题是拷贝时漏掉了隐藏文件夹（以点开头），Windows 文件资源管理器默认不显示隐藏项目，你会看不见它们。建议用命令行dir /a查看或直接压缩再解压，确保文件夹不丢。
5.3 中文路径与杀毒软件问题
Windows 系统的路径分隔符、中文字符、长路径限制，在命令行工具里老生常谈了。MinerU 对中文路径的支持比预期好，但如果你用 PowerShell，中文路径偶尔会被编码搞坏，看起来像乱码。我的做法是：所有 PDF 解析前先统一复制到一个纯英文路径的临时目录，解析完再移回来。这个操作虽然多了一小步，却规避了 90% 的编码问题。
杀毒软件方面，前面提过 Defender 隔离模型文件的事情，这里再说一个隐患：当批量解析输出大量文件时，Defender 实时扫描会造成不小的性能损耗。我建议把模型目录、输入目录、输出目录加入排除列表，Windows 安全中心 -> 病毒和威胁防护 -> 排除项，添加三个路径。这样批量解析时间明显缩短。如果公司电脑有强制安装的杀软，可能要在关闭实时防护或更改设置上申请权限，权衡后确认是否愿意承担风险。
5.4 异常输出排查：打开日志，向前找第一个红字
最后说一个通用的排查思路。一旦 MinerU 解析异常，第一反应不是对着报错瞎猜，而是打开日志找第一个ERROR或Traceback。MinerU 在运行时会打印不少中间过程日志，但异常原因永远是第一个红字最靠前的那一行。笼统地讲，错误要么是模型路径不对，要么是文件权限问题，要么是显存/内存不足。显存不足时通常报CUDA out of memory，好判断；内存不足时 Windows 会出现进程被杀或系统卡顿，通常在任务管理器里能看到 Python 进程占用接近 100%。
如果日志里是PermissionError，多半是杀软拦截或文件被占用。如果是KeyError或JSONDecodeError，说明中间产物被污染，删掉输出目录重跑即可。这一套排查下来，绝大多数问题都能定位到根因。那种模糊的“解析失败”不外乎以上几种，经验之谈，听到报错先淡定，看日志，按常理推断，基本都能解决。
我在实际使用中还有一个习惯，就是每次解析完，先抽看 3 到 5 个 PDF 的 Markdown 输出，确认标题层级、表格、公式都没明显硬伤，才放心继续下一批。批量解析不是一锤子买卖，有质检环节的流程才能长期稳定运行。
MinerU 4.0 在 Windows 上跑熟了之后，我通常把它做成一个“文档流入 -> 解析 -> 质检 -> 入库”的半自动流水线。从一个普通的 Python 脚本开始，不断补充跳过已完成文件、失败重试、轮询目录这类小机制，稳稳服务了几十个项目。这也算是一个从“需要手动处理每一个文件”到“丢进去等结果”的转变。如果你手头的 PDF 量级已经到了几十上百份，别犹豫，花一下午部署一次，回报率远超预期。
分享一个我自己的小技巧：解析结果里的 JSON 文件别急着删。当你在 RAG 检索阶段发现某个知识块引用信息不对，回查 JSON 里的坐标和类型信息，通常能迅速定位问题源头。这个习惯帮我在多个场合省下大量排障时间，也值得你试一试。
