一、 MinerU 到底解决什么问题？
以前用 PyPDF2 等工具解析 PDF，遇到双栏排版、跨页表格、公式或扫描件，抽出来的文字全是乱序或乱码，喂给大模型根本没法用。
MinerU 的作用很简单：
把 PDF、Word、PPT、图片塞进去，它通过视觉模型看懂排版，按正常的阅读顺序重新理顺，去掉页眉页脚，最后吐出两样核心东西给你：
images/文件夹 +.md文件：把文档里的插图全扣出来放进文件夹，正文转成带图片链接的 Markdown。_content_list.json（最核心）：一份按阅读顺序排好的结构化数据清单，里面把每一段话、每一个标题、表格、图片都拆成了独立对象，还附带了它们在原 PDF 第几页（page_idx）以及具体坐标（bbox）。
跑法选择（看显卡决定）：
没显卡或只要纯文字：用
pipeline模式（纯 CPU 就能跑，速度快）。有 8G 以上显存的显卡：直接用默认的
hybrid模式（兼顾速度和复杂版面精度）。
二、 拿到解析结果后，怎么在工程上落地？
做 RAG 切记不要直接拿 .md 文件按字数硬切（容易把表格劈成两半，或者把图片和图注拆散）。直接解析 _content_list.json 是最稳的方案，整条链路分四步走：
第一步：图片上传与 URI 替换（别在库里写死域名）
MinerU 吐出来的图片路径是本地相对路径（比如 images/abc.jpg），直接入库前端肯定加载不出来。
上传去重：遍历
_content_list.json，把所有带img_path的图片找出来，去重后上传到你们自己的 OSS / MinIO，拿到存储路径，在内存里建一张映射表：{"images/abc.jpg": "oss://rag/doc1/abc.jpg"}。存自定义 URI，别存完整 HTTP 链接：
入库时：把 JSON 里的
img_path替换成你们自定义的内部逻辑路径（比如oss://rag/doc1/abc.jpg或/files/doc1/abc.jpg）。这样以后换域名、切内外网、或者加防盗链签名，不用重新洗向量库。返回给前端时：等检索命中、大模型生成完回答准备返回给前端之前，加一个统一拦截器，把回答里的
oss://...动态拼接域名或生成带签名的临时https://...URL。
第二步：照着 JSON 做动态切块（Chunking）
遍历 _content_list.json 里的每个元素，按类型（type）区别对待：
遇到标题（
text_level有值）：
立刻把前面攒的文本结算成一个 Chunk，然后记下当前标题。后面新攒的 Chunk 头部都自动带上这个标题（比如第一章 > 1.2 部署架构），这样检索的时候上下文更完整。遇到表格（
type == "table"）：
绝对不要拆分。把表注（table_caption）和 HTML 表格源码（table_body）拼在一起，直接单独作为一个 Chunk。如果表格实在太大超过向量模型长度限制，就先调大模型给表格写段摘要拿去做向量检索，把完整的 HTML 表格塞进 Metadata 里，搜出来后再喂给大模型回答。遇到图片（
type == "image"）：
纯图片没法直接做文本向量检索，必须给它“绑上文字”。把它的图注（image_caption）、前后相邻的一两段正文，连同刚才替换好的 Markdown 图片语法拼在同一个 Chunk 里。普通正文（
type == "text"）：
按顺序往当前 Chunk 里累加，凑够你们设定的字数上限（比如 500~800 字）就截断结算，开下一个块。
第三步：顺手把溯源坐标塞进 Metadata
在第二步把多个块合并成一个 Chunk 时，把这些块对应的 page_idx（页码）和 bbox（坐标）收集起来，存进向量数据库的 Metadata 字段里。
效果：前端拿到引用来源后，点一下就能直接跳转到原 PDF 的对应页，并在对应位置画个高亮框。
第四步：让大模型在回答里把图带出来
入库后，只要用户问到图片相关的内容，就会连带着把包含  的切片搜出来。
在系统 Prompt 里加一句约束：“如果参考资料里包含 Markdown 格式的图片链接且与问题相关，直接在回答的合适位置原样输出该图片链接。”
大模型输出后，经过第一步提到的拦截器把自定义 URI 转成真实 URL，前端渲染 Markdown 时就能直接看到图文并茂的回答了。
三、 踩坑提醒
生产部署：别在业务接口里直接同步调 MinerU，解析大文件很耗时，用官方自带的
mineru-api配合消息队列做成异步任务（上传 -> 排队解析 -> 回调入库）。协议注意：MinerU 是 AGPL-3.0 协议，公司内部自己搭知识库随便用；如果要把它包装成对外卖钱的 SaaS API，记得注意开源合规。