完整完成 PDF 转 Markdown：Marker 的三种模式与真实基准数据

完整完成 PDF 转 MarkdownMarker 的三种模式与真实基准数据【免费下载链接】markerConvert PDF to markdown JSON quickly with high accuracy项目地址: https://gitcode.com/GitHub_Trending/ma/marker500 页论文一键转 Markdown公式全变乱码、表格散成一地碎片——这种翻车现场多数人经历过。Marker 是一款开源 PDF转Markdown 工具一条命令转出论文公式保留成 LaTeX表格保留成结构官方基准里纯 CPU 路径能达到 23.7 页/秒。先别急着上手看看你转 PDF 时最常撞上的几个症状对照一下有没有中过招。PDF转Markdown 最容易踩的四个坑症状后果扫描件或老文档的文本层坏了抽出来全是乱码你得逐页手动重读重录双栏论文被读成单栏阅读顺序全乱摘要会插到正文末尾表格跨行跨列被合并200 页财务报表只能手动重排公式输出一串特殊符号复制不了、渲染不了、也搜不到这几项几乎是所有开源文档转换工具的共性难题。Marker 的思路不同它默认走 PDF 里已有的文本层只在文本层坏掉、遇到公式、表格重建置信度低时才动用视觉大模型VLM速度和质量都留了余地。能力总览从开箱即用到深度定制分三层开箱即用装完一条命令就完成 PDF转Markdown页眉页脚默认清理图片提取到本地顺带生成含目录的元数据文件指定一个目录就能整库批量转换。进阶调优balanced / fast / disable_ocr三种转换模式再叠加可选的 LLM 增强模式按文档类型和质量要求在质量与速度之间取舍。深度定制处理器、渲染器、输入提供者都可替换你能写自己的输出格式、接入新的输入文件类型也可以直接用 Python 取出特定块做程序化提取。说快说准总归是空话先看数字。 基准数据Marker 和同类工具差多少质量分数来自第三方基准 olmOCR-bench1403 份 PDF、约 8400 个判定用例吞吐量是单台 B200 机器上持续并发处理的页数/秒。系统总分百分制纯数字PDF得分吞吐量页/秒Marker — balancedGPU76.083.52.9MinerUGPU72.783.30.54Marker — fastGPU66.671.67.4doclingGPU50.364.02.1在官方基准测试中Marker 的 balanced 模式比 MinerU、docling 两条开源流水线分数更高、吞吐也更快只统计纯数字 PDF 时差距更大。fast 模式则用一点质量换约 2.5 倍的速度。一个细节值得留意fast 模式的公式是从文本层读的所以公式类得分比 balanced 低不少——公式密集的论文直接上 balanced 就好。数字只是底子接下来真刀真枪试一遍。️ 分级实操从第一次 PDF转Markdown 到进阶调优第一级5 分钟跑通 PDF转Markdown需要 Python 3.10安装就一行pip install marker-pdf如果还要转 PPTX、DOCX、XLSX、EPUB 这类非 PDF 文件把安装命令换成带[full]后缀的版本。然后跑核心命令传入文件路径PDF 或图片都行marker_single /path/to/file.pdf跑完你会得到三类东西输出目录里一份同名.md表格是 Markdown 表格、公式带$$围栏、代码用围栏块、页眉页脚默认已清理一份同名_meta.json元数据文件含计算出的目录和逐页统计以及同目录下提取出的图片。文档很长时用--page_range限定范围比如0,5-10,20。另外第一次运行会自动拉起本地推理服务器首跑明显偏慢属正常现象后续会快很多。第二级按场景调参对照表你的场景推荐参数组合为什么这样配公式、行内数学多论文--mode balanced --use_llmbalanced 用 VLM 识别行内公式LLM 负责跨页表格和疑难块的修正大批量纯数字 PDF、没有 GPU--mode fast --disable_ocr纯 CPU 文本层路径基准约 23.7 页/秒公式和扫描页会跳过只要表格数据TableConverter--output_format json只提取表格JSON 输出带页码和边界框方便后续程序处理上图对应第二个场景纯数字文档在纯 CPU 条件下带布局模型的路径分数明显高于普通文本抽取工具。再补两个批量细节批量时把路径换成目录即可--workers控制并行数--skip_existing会跳过已转换的文件方便断点续跑--max_files可以先跑一部分试试水。第三级三种进阶组合拳组合一只提表格的流水线。对以数据表为主的文档用--converter_cls marker.converters.table.TableConverter --output_format json只抽表格如果你确定整页都是表格再加--force_layout_block Table跳过布局检测。取舍正文不会被转换适合我就要数据的场景。组合二本地模型做 LLM 增强。数据不能出内网的文档可以开 LLM 增强并指向本地 Ollamamarker_single file.pdf --use_llm --llm_service marker.services.ollama.OllamaService配合--ollama_model和--ollama_base_url指定模型与地址。取舍本地模型的速度和质量通常不如云端 API但数据不出域。组合三Python 里直接取块。要写程序拿特定块比如所有表单、所有表格不必渲染完整文本用PdfConverter.build_document建出文档树再用contained_blocks按块类型过滤。取舍得先读一下marker/schema里的块类型但读通之后能做到 CLI 做不到的定制。源码定位上这两处最常被人翻表格、公式等细调逻辑marker/processors/LLM 服务接入代码marker/services/排障是每个批量任务都会碰上的事官方列的高频问题先整理成表。排障速查六个高频现象现象可能原因解法转换后文字乱码PDF 文本层本身质量差加--force_ocr强制整页 OCR混入旧 OCR 文本文档里残留老 OCR 层--strip_existing_ocr丢弃旧 OCR 层重新识别公式识别不准fast 模式默认从文本层读公式换--mode balanced或叠加--use_llm内存不足报 OOM并行 worker 太多调小--workers或把长 PDF 拆成多个文件整体很慢没有 GPU 且扫描页多纯数字文档可走--disable_ocr文本层路径跳过 VLM看不出哪一步识别错默认没有诊断输出加--debug会导出每页布局检测图和边界框数据想再看深一点源码的话记住这棵目录树就够用了。架构一瞥按目录定位源码marker/ ├── providers/ # 读取 PDF、图片等输入文件提供原始页面数据 ├── builders/ # 生成初始文档块填充文本与布局 ├── processors/ # 细化特定块类型表格、公式、代码等 ├── renderers/ # 渲染 markdown、JSON、HTML、chunks 等最终输出 ├── schema/ # 所有块类型的数据结构定义 ├── converters/ # 组装端到端转换流水线 └── services/ # 各种 LLM 服务的接入层扩展思路很直接改处理行为就覆写 processor加输出格式就写新 renderer支持新输入文件就写新 provider。道理讲得差不多了下面三件事今天就能动手做。✅ 行动清单今天就能做的三件事挑一份含双栏和至少一张表格的工作 PDF跑一遍marker_single打开产出的 md 数一数表格错位了几处建立你自己的基准线。对同一份文件加--use_llm再跑一遍需配 API key 或本地 Ollama对比表格和公式两处的差异。把 10 个文件放进一个目录用批量命令加--workers跑完记录实际页/秒和文中的基准数字对照。遇到问题或有想法时入口在这。 社区入口issue、讨论区、贡献Issue提交时附上可复现的 PDF 样例以及期望输出 / 实际输出转换类问题这样报更容易被定位。讨论区官方 Discord 讨论区是团队讨论未来方向的地方使用问题也可以在那里问。贡献项目为 Apache 2.0 许可代码贡献走标准流程Fork 仓库、建功能分支、提 Pull Request 并参与审查。收尾下次再遇到那 500 页的论文先跑一遍marker_single看看它转出什么表格错位的地方再加--use_llm跑第二遍。这是验证成本最低的路径。【免费下载链接】markerConvert PDF to markdown JSON quickly with high accuracy项目地址: https://gitcode.com/GitHub_Trending/ma/marker创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考