文章目录
一、关于 marker
Marker 快速准确地将PDF转换为 markdown。
- github : https://github.com/VikParuchuri/marker
- discord : https://discord.gg//KuZwXNGnfH
- datalab 主页：https://www.datalab.to/
特点
- 支持广泛的文档（针对书籍和科学论文进行了优化）
- 支持所有语言
- 删除页眉/页脚/其他工件
- 格式化表和代码块
- 提取和保存图像以及降价
- 将大多数方程转换为乳胶
- 适用于GPU、CPU或MPS
它是如何工作的
Marker是深度学习模型的管道：
- 提取文本，必要时进行OCR（启发式、surya、tesseract）
- 检测页面布局并查找阅读顺序（surya）
- 清理和格式化每个块（启发式，texify
- 组合块和后处理完整文本（启发式，pdf_postprocessor）
它只在必要时使用模型，从而提高速度和准确性。
例子
| 类型 | marker | 牛轧糖 | |
|---|---|---|---|
| Think Python | Textbook | 查看 | 查看 |
| Think OS | Textbook Textbook | 查看 | 查看 |
| Switch Transformers | arxiv 论文 | 查看 | 查看 |
| Multi-column CNN | arxiv 论文 | 查看 | 查看 |
性能
上述结果带有marker和牛轧糖设置，因此它们各自在A6000上占用约4GB的VRAM。
有关详细的速度和精度基准测试以及如何运行您自己的基准测试的说明，请参阅下文。
商业用途
我希望marker尽可能广泛地使用，同时仍然资助我的开发/培训费用。研究和个人使用总是可以的，但是商业使用有一些限制。
模型的权重是cc-by-nc-sa-4.0许可的，但是对于最近12个月总收入低于500万美元和终身风险投资/天使基金筹集不到500万美元的任何组织，我将放弃这一点。
如果你想取消GPL许可要求（双许可）和/或在商业上使用超过收入限制的权重，请查看此处的选项。
托管API
这里有一个用于marker的托管API：
- 支持PDF、word文档和幻灯片
- 领先的基于云的竞争对手价格的1/4
- 利用Modal实现高可靠性，没有延迟峰值
限制
PDF是一种棘手的格式，因此marker并不总是完美工作。以下是路线图上要解决的一些已知限制：
- Marker不会将100%的方程转换为 LaTeX。这是因为它必须检测然后转换。
- 表格格式并不总是100%正确-文本可能在错误的列中。
- 空格和缩进并不总是得到尊重。
- 并非所有行/跨度都将正确连接。
- 这在不需要大量光学字符识别的数字PDF上效果最好。它针对速度进行了优化，有限的光学字符识别用于修复错误。
二、安装
您需要 python 3.9+ 和 PyTorch。如果您不使用Mac或GPU机器，您可能需要先安装torch的CPU版本。有关更多详细信息，请参阅此处。
Install with:
pip install marker-pdf
Optional: OCRMyPDF
仅当您想使用可选的ocrmypdf作为ocr后端时才需要。请注意，ocrmypdf包含Ghostscript，一个AGPL依赖项，但通过CLI调用它，因此它不会触发许可条款。
请参阅说明这里
三、用法
1、配置
首先，一些配置：
- 检查
marker/settings.py中的设置。您可以使用环境变量覆盖任何设置。 - 您的 torch device 将被自动检测到，但您可以覆盖此设置。例如，
TORCH_DEVICE=cuda- 如果使用GPU，请将
INFERENCE_RAM设置为GPU VRAM（每个GPU）。例如，如果您有 16 GB的VRAM，则设置INFERENCE_RAM=16。 - 根据您的文档类型，marker 每个任务的平均内存使用量可能略有不同。如果您注意到任务失败并出现GPU内存溢出错误，您可以配置
VRAM_PER_TASK进行调整。
- 如果使用GPU，请将
- 默认情况下，marker 将使用
surya进行OCR。Surya 在CPU上速度较慢，但比tesseract更准确。
如果您想要更快的OCR，请将OCR_ENGINE设置为ocrmypdf。这也需要外部依赖项（见上文）。
如果您根本不想要OCR，请将OCR_ENGINE设置为None。
转换单个文件
marker_single /path/to/file.pdf /path/to/output/folder --batch_multiplier 2 --max_pages 10 --langs English
--batch_multiplier是如果您有额外的VRAM，将默认批处理大小乘以多少。数字越高，需要更多的VRAM，但处理速度更快。默认设置为2。默认批处理大小将需要约3GB的VRAM。--max_pages–是要处理的最大页数。省略此项以转换整个文档。--langs是文档中以逗号分隔的语言列表，用于OCR
确保DEFAULT_LANG设置适合您的文档。OCR支持的语言列表在这里。
如果您需要更多语言，您可以使用Tesseract支持的任何语言，如果您将OCR_ENGINE设置为ocrmypdf。
如果您不需要OCR，marker可以使用任何语言。
转换多个文件
marker /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。--min_length是在考虑处理之前需要从pdf中提取的最小字符数。如果您正在处理大量pdf，我建议设置此设置以避免OCRing主要是图像的pdf。（减慢一切）--metadata_file是一个json文件的可选路径，其中包含关于pdf的元数据。如果您提供它，它将用于设置每个pdf的语言。如果没有，将使用DEFAULT_LANG。格式为：
{
"pdf1.pdf": {"languages": ["English"]},
"pdf2.pdf": {"languages": ["Spanish", "Russian"]},
...
}
您可以使用语言名称或代码。确切的代码取决于OCR引擎。
有关surya代码的完整列表，请参阅此处，有关tesseract，请参阅此处。
在多个GPU上转换多个文件
MIN_LENGTH=10000 METADATA_FILE=../pdf_meta.json NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
METADATA_FILE是json文件的可选路径，其中包含有关pdf的元数据。格式见上文。NUM_DEVICES是要使用的GPU数量。应该是2或更大。NUM_WORKERS是在每个GPU上运行的并行进程数。每个GPU的并行度不会超过INFERENCE_RAM / VRAM_PER_TASK。MIN_LENGTH是在考虑处理之前需要从pdf中提取的最小字符数。如果您正在处理大量pdf，我建议设置此设置以避免OCRing主要是图像的pdf。（减慢一切）
请注意，上面的env变量特定于此脚本，不能在local.env中设置。
三、故障排除
如果事情没有按照您期望的方式工作，您可能会发现一些设置很有用：
OCR_ALL_PAGES-将此设置为true以强制所有页面进行OCR。如果默认情况下无法正确识别表格布局，或者存在乱码文本，这将非常有用。TORCH_DEVICE-将此设置为强制marker使用给定的手电筒设备进行推理。OCR_ENGINE-可以将此设置为surya或ocrmypdf。DEBUG-将此设置为True会在转换多个pdf时显示光线日志- 验证您是否正确设置了语言或传入了元数据文件。
- 如果出现内存溢出错误，请减少工作计数（增加
VRAM_PER_TASK设置）。您还可以尝试将长PDF拆分为多个文件。
一般来说，如果输出不是您所期望的，尝试OCR PDF是很好的第一步。并非所有PDF都嵌入了良好的文本/bbox。
四、有用的设置
这些设置可以提高/更改输出质量：
OCR_ALL_PAGES将强制OCR整个文档。由于使用较旧的OCR引擎，许多PDF嵌入了错误的文本。PAGINATE_OUTPUT将在页面之间放置水平规则。默认值：假。EXTRACT_IMAGES将提取图像并单独保存。默认值：真。BAD_SPAN_TYPES指定要从降价输出中删除的布局块。
五、基准测试
基准PDF提取质量很难。我通过查找具有pdf版本和 latex 源的书籍和科学论文创建了一个测试集。我将 latex 转换为文本，并将引用与文本提取方法的输出进行比较。它很嘈杂，但至少方向正确。
基准测试表明，marker比 nougat 快4倍，并且在arxiv之外更准确（牛轧糖是在arxiv数据上训练的）。我们展示了朴素的文本提取（无需处理即可从pdf中提取文本）进行比较。
速度
| 方法 | 平均得分 | 时间每页 | 时间每个文档 |
|---|---|---|---|
| marker | 0.613721 0. | 631991 | 58.1432 |
| 牛轧糖 | 0.406603 | 2.59702 238. | 926 |
精度
前3本是非arxiv书籍，后3本是arxiv论文。
| 方法 | multicolcnn. pdf | switch_trans | .pdf thinkpython.pdf | thinkos.pdf | thinkdsp.pdf | 人群.pdf |
|---|---|---|---|---|---|---|
| marker | 0.536176 | 0.516833 | 0.70515 | 0.710657 | 0.690042 | 0.523467 |
| 牛轧糖 | 0.44009 | 0.588973 | 0.322706 | 0.401342 | 0.160842 | 0.525663 |
基准测试期间，牛轧糖的GPU内存使用量峰值为4.2GB，marker为4.1GB。基准测试在A6000 Ada上运行。
吞吐量
Marker平均每个任务占用大约4GB的VRAM，因此您可以在A6000上并行转换12个文档。
六、运行自己的基准测试
您可以在您的机器上对marker的性能进行基准测试。手动安装marker：
git clone https://github.com/VikParuchuri/marker.git
poetry install
在此处下载基准数据并解压缩。然后像这样运行benchmark.py：
python benchmark.py data/pdfs data/references report.json --nougat
这将marker与其他文本提取方法进行基准测试。它为牛轧糖和marker设置批次大小，以便为每个设置使用相似数量的GPU RAM。
省略--nougat以从基准测试中排除nougat。我不建议在CPU上运行nougat，因为它非常慢。
七、感谢
如果没有惊人的开源模型和数据集，这项工作是不可能的，包括（但不限于）：
- Surya
- Texify
- pdfium2/pdfium
- DocLayNet从IBM
- 来自谷歌的ByT5
感谢这些模型和数据集的作者将它们提供给社区！
2024-08-02（五）
694
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
