夜雨聆风今天上午看一个内部知识库复盘，团队一开始怀疑是模型不够好，后来把原始 PDF 和解析后的 Markdown 对了一遍，问题就很清楚了：表格被拆散，页眉页脚混进正文，多栏 PDF 的阅读顺序也乱了。
这时候继续调 prompt、换向量库、改 chunk size，效果都有限。因为模型看到的不是原始 PDF，而是解析后的文本和结构。上游文档一乱，下游检索和问答就会跟着乱。
今天不讲完整 RAG 架构，只讲一个更靠前的环节：用 MinerU 把 PDF、图片、DOCX、PPTX、XLSX 先解析成 Markdown / JSON，再进入知识库或 Agent 工作流。
这也是今天值得写它的原因。MinerU 6 月刚连续更新，3.4 聚焦 OCR 能力、OCR 处理速度和模型下载体验，3.3 聚焦 Hybrid 解析性能和 VLM 模型能力。它不是一个“新名词”，而是正好卡在企业知识库的数据准备层。
第一层问题：文档并不等于文本
很多企业文档不是干净的 Markdown。它们可能是扫描版合同、两栏排版的 PDF、带公式和表格的论文、PPT 里的流程图，或者 Excel 里跨行跨列的业务表。
这些内容直接进知识库，常见结果是：文本有了，结构没了；段落有了，顺序错了；表格还在，但语义断了。
所以 RAG 的第一张检查表，不应该从模型开始，而应该从文档解析开始。
MinerU 放在哪一层
MinerU 更像“文档进入 AI 系统前的数据生产线”。
这条链路里，MinerU 不替代向量库，也不替代搜索引擎。它解决的是“进入检索系统前，文档能不能被正确理解”。
Docker 部署前先过三项
MinerU 官方 Dockerfile 使用 vllm/vllm-openai 作为基础镜像。部署前，我会先把镜像、GPU 和端口过一遍。
nvidia-smi
docker version
docker pull docker.1ms.run/vllm/vllm-openai:v0.21.0在镜像供应链这一层，用毫秒镜像（1ms.run）先做基础镜像预检，目的是把 docker pull 这类不确定因素提前排掉。后面真正要看的，是 MinerU 服务、模型缓存和解析输出。
官方 Docker 示例里会映射这些端口：
如果只是先验收解析质量，7860 的 WebUI 更直观；如果要接入内部系统，再考虑 8000 API 或 8002 Router。
不要只看服务有没有启动
文档解析系统最容易误判的地方，是容器启动成功并不等于解析质量合格。
先放一份普通 PDF，看标题和段落顺序。 再放一份扫描件，看 OCR 是否稳定。 再放一份表格密集文档，看 HTML 表格是否可用。 再放一份公式文档，看 LaTeX 输出是否能保留语义。 最后放一份 PPT 或 Excel，看 Office 文档是否适合进入后续切分。
只有这些样本过了，才值得把 MinerU 接到批量任务里。
这里还要留一个边界：官方性能数字不要直接套到所有文档。扫描件、手写内容、跨页表格、复杂图表，都可能让解析结果出现差异。文档解析系统一定要先做样本验收。
一张上线前清单
这张表比“换一个更强模型”更早，也更便宜。
收个尾
RAG 效果差的时候，先别把问题都推给模型。很多时候，模型看到的材料已经被解析坏了。
MinerU 值得写，是因为它站在知识库链路更前面：先把文档变成 AI 可以使用的数据，再谈检索、排序、问答和 Agent。镜像拉取、GPU、端口只是部署层；真正决定后续效果的，是解析后的 Markdown / JSON 质量。
