前言
Marker 能够将 PDF、EPUB 和 MOBI 文件转换为 Markdown 格式。它比 nougat 快 10 倍，在大多数文档上更准确，并且具有较低的错误风险。
1. 支持各种 PDF 文档（优化用于书籍和科学论文）
2. 去除页眉、页脚和其他干扰元素
3. 将大多数方程式转换为 LaTeX
4. 格式化代码块和表格
5. 支持多种语言（尽管大部分测试都是用英语进行的）
6. 可在 GPU、CPU 或 MPS 上运行
如何运作
Marker 是一个由深度学习模型组成的处理流程：
1.提取文本，必要时进行 OCR（启发式方法，tesseract）2.检测页面布局（布局分割器，列检测器）3.清理并格式化每个块（启发式方法，nougat）4.合并块并对完整文本进行后处理（启发式方法，pdf_postprocessor）
依赖自回归的前向传递来生成文本既慢又容易产生幻觉/重复。从 nougat 论文中我们观察到：在测试集中有 1.5% 的页面出现了重复，但对于非领域（非 arXiv）文档，这种频率会增加。在我个人的测试中，非领域（非 arXiv）页面上重复的情况超过了 5%。
Nougat是一个惊人的模型，但我需要一个更快速且更通用的解决方案。Marker 的速度是 nougat 的 10 倍，并且因为它只通过 LLM 前向传递处理方程式块，所以具有较低的幻觉风险。
示例
类型 | Marker | Nougat | |
|---|---|---|---|
Think Python | 教科书 | 查看 | 查看 |
Think OS | 教科书 | 查看 | 查看 |
Switch Transformers | arXiv 论文 | 查看 | 查看 |
多列 CNN | arXiv 论文 | 查看 | 查看 |
性能
以上结果是在 A6000 上将 marker 和nougat 设置为各占用约 3GB VRAM 的情况下得到的。有关详细的速度和准确性基准测试，以及如何进行自己的基准测试的说明，请参见下文。
限制
PDF 是一种复杂的格式，因此 marker并不总是能完美工作。以下是一些已知的限制，它们正处于解决的规划中：
•Marker 转换为 latex 的方程式数量会少于 nougat。这是因为它首先需要检测方程式，然后在没有产生错误的情况下进行转换。•空白和缩进不总是得到尊重。•并非所有行/跨度都会被正确连接。•只支持与英语相似的语言（西班牙语、法语、德语、俄语等）。不支持具有不同字符集的语言（中文、日语、韩语等）。•这对数字 PDF 最有效，这些 PDF 不需要大量的 OCR。它针对速度进行了优化，并且使用有限的 OCR 来纠正错误。
安装
已在 Mac 和 Linux（Ubuntu 和 Debian）上进行了测试。你需要 python 3.9 和 poetry。首先，
克隆仓库：
•git clone https://github.com/VikParuchuri/marker.git•cd marker
Linux
•安装系统要求•可选：按照这些说明安装 tesseract 5 或运行 scripts/install/tesseract_5_install.sh。•按照这些说明安装 ghostscript > 9.55 或运行 scripts/install/ghostscript_install.sh。•通过 cat scripts/install/apt-requirements.txt | xargs sudo apt-get install -y 安装其他要求。•设置 tesseract 数据文件夹路径•使用 find / -name tessdata 找到 tesseract 数据文件夹 tessdata。如果你有多个版本，请确保使用与最新 tesseract 版本对应的文件夹。•在 marker 根文件夹中创建一个 local.env 文件，其中包含 TESSDATA_PREFIX=/path/to/tessdata•安装 python 要求•poetry install•poetry shell 激活你的 poetry venv•更新 pytorch，因为 poetry 与它不太兼容•仅 GPU：运行 pip install torch 安装其他 torch 依赖。•仅 CPU：卸载 torch，然后按照 CPU 安装说明进行操作。
Mac
•从 scripts/install/brew-requirements.txt 安装系统要求•设置 tesseract 数据文件夹路径•使用 brew list tesseract 查找 tesseract 数据文件夹 tessdata•在 marker 根文件夹中创建一个 local.env 文件，其中包含 TESSDATA_PREFIX=/path/to/tessdata•安装 python 要求•poetry install•poetry shell 激活你的 poetry venv
使用方法
首先，进行一些配置：
•在 local.env 文件中设置你的 torch 设备。例如，TORCH_DEVICE=cuda 或 TORCH_DEVICE=mps。默认为 cpu。•如果使用 GPU，请将 INFERENCE_RAM 设置为你的 GPU VRAM（每个 GPU）。例如，如果你有 16 GB 的 VRAM，设置 INFERENCE_RAM=16。•根据你的文档类型，marker 的平均内存使用量每个任务可能会略有不同。如果你注意到任务因 GPU 内存不足错误而失败，你可以配置 VRAM_PER_TASK 来调整这一点。•检查 marker/settings.py 中的其他设置。你可以在 local.env 文件中覆盖任何设置，或通过设置环境变量。•默认情况下，最终的编辑器模型是关闭的。使用 ENABLE_EDITOR_MODEL 打开它。•默认情况下，marker 将使用 ocrmypdf 进行 OCR，这比基础 tesseract 慢，但质量更高。你可以通过 OCR_ENGINE 设置来更改这一点。
转换单个文件 运行 convert_single.py，像这样： python convert_single.py /path/to/file.pdf /path/to/output.md --parallel_factor 2 --max_pages 10
•--parallel_factor 是增加批量大小和并行 OCR 工作的程度。更高的数字将占用更多的 VRAM 和 CPU，但处理速度更快。默认设置为 1。•--max_pages 是要处理的最大页面数。省略此项以转换整个文档。确保 DEFAULT_LANG 设置适合你的文档。
转换多个文件 运行 convert.py，像这样： python convert.py /path/to/input/folder /path/to/output/folder --workers 10 --max 10 --metadata_file /path/to/metadata.json --min_length 10000
•--workers 是同时转换的 pdf 数量。默认设置为 1，但你可以增加它以提高吞吐量，代价是更多的 CPU/GPU 使用。如果你使用 GPU，那么并行性不会超过 INFERENCE_RAM / VRAM_PER_TASK。•--max 是要转换的最大 pdf 数量。省略此项以转换文件夹中的所有 pdf。•--metadata_file 是指向包含 pdf 元数据的 json 文件的可选路径。如果提供，它将被用来为每个 pdf 设置语言。如果没有，将使用 DEFAULT_LANG。格式为：•--min_length 是从 pdf 中提取的字符数量的最小值，才会被考虑进行处理。如果你正在处理大量的 pdf，我建议设置此项以避免 OCR 处理大部分是图片的 pdf。（会拖慢整个过程） { "pdf1.pdf": {"language": "English"}, "pdf2.pdf": {"language": "Spanish"}, ... }
在多个 GPU 上转换多个文件 运行 chunk_convert.sh，像这样： MIN_LENGTH=10000 METADATA_FILE=../pdf_meta.json NUM_DEVICES=4 NUM_WORKERS=15 bash chunk_convert.sh ../pdf_in ../md_out
•METADATA_FILE 是指向包含 pdf 元数据的 json 文件的可选路径。格式请参见上文。•NUM_DEVICES是要使用的 GPU 数量。应该是 2 或更多。•NUM_WORKERS 是在每个 GPU 上运行的并行进程数量。每个 GPU 的并行性不会超过 INFERENCE_RAM / VRAM_PER_TASK。•MIN_LENGTH 是从 pdf 中提取的字符数量的最小值，才会被考虑进行处理。如果你正在处理大量的 pdf，我建议设置此项以避免 OCR 处理大部分是图片的 pdf。（会拖慢整个过程）
基准测试
对 PDF 提取质量进行基准测试是很难的。我通过找到有 pdf 版本和 latex 源码的书籍和科学论文来创建测试集。我将 latex 转换为文本，并将参考文本与文本提取方法的输出进行比较。基准测试显示，marker 比 nougat 快 10 倍，在 arXiv 之外更准确（nougat 是在 arXiv 数据上训练的）。我们展示了简单的文本提取（从 pdf 中提取文本，不进行任何处理）以作比较。
速度
方法 | 平均得分 | 每页时间 | 每个文档的时间 |
|---|---|---|---|
naive | 0.350727 | 0.00152378 | 0.326524 |
marker | 0.641062 | 0.360622 | 77.2762 |
nougat | 0.629211 | 3.77259 | 808.413 |
准确性
前三个是非 arXiv 书籍，后三个是 arXiv 论文。
方法 | switch_trans.pdf | crowd.pdf | multicolcnn.pdf | thinkos.pdf | thinkdsp.pdf | thinkpython.pdf |
|---|---|---|---|---|---|---|
naive | 0.244114 | 0.140669 | 0.0868221 | 0.366856 | 0.412521 | 0.468281 |
marker | 0.482091 | 0.466882 | 0.537062 | 0.754347 | 0.78825 | 0.779536 |
nougat | 0.696458 | 0.552337 | 0.735099 | 0.655002 | 0.645704 | 0.650282 |
基准测试期间峰值 GPU 内存使用量为 nougat 的 3.3GB 和 marker 的 3.1GB。基准测试在 A6000 上进行。
吞吐量
Marker 平均每个任务使用大约 2GB 的 VRAM，因此你可以在 A6000 上并行转换 24 个文档。
进行自己的基准测试
你可以在你的机器上对 marker 的性能进行基准测试。首先在这里下载基准测试数据并解压。然后像这样运行 benchmark.py： python benchmark.py data/pdfs data/references report.json --nougat
这将对 marker 和其他文本提取方法进行基准测试。它为 nougat 和 marker 设置批量大小，以使每个使用相似数量的 GPU RAM。省略 --nougat 以从基准测试中排除 nougat。我不建议在 CPU 上运行 nougat，因为它非常慢。
商业使用
由于底层模型如 layoutlmv3 和 nougat 的许可证，这只适用于非商业用途。我正在构建一个可以用于商业的版本，通过剥离以下依赖项。如果你想获得早期访问，请通过 marker@vikas.sh[1] 给我发送电子邮件。这里是非商业/限制性依赖项：
•LayoutLMv3：CC BY-NC-SA 4.0。来源•Nougat：CC-BY-NC。来源•PyMuPDF - GPL。来源 其他依赖/数据集是开放许可的（doclaynet, byt5），或以兼容商业使用的方式使用（ghostscript）。
感谢
没有令人惊叹的开源模型和数据集，这项工作是不可能完成的，包括（但不限于）：
•Meta 的 Nougat•微软的 Layoutlmv3•IBM 的 DocLayNet•谷歌的 ByT5 感谢这些模型和数据集的作者！
