datalab-to/marker

GitHub: datalab-to/marker

Marker 是一款基于深度学习的高精度文档转换工具,可将 PDF 及多种文档格式快速转换为 Markdown、JSON 等结构化输出。

Stars: 37497 | Forks: 2637

Datalab Logo

Datalab

State of the Art models for Document Intelligence

Code License Model License Discord

Homepage Docs Public Playground


# Marker Marker 能够快速准确地将文档转换为 markdown、JSON、chunks 和 HTML 格式。 - 支持转换所有语言的 PDF、图片、PPTX、DOCX、XLSX、HTML、EPUB 文件 - 格式化表格、表单、公式、行内数学公式、链接、参考文献和代码块 - 提取并保存图片 - 移除页眉/页脚及其他杂乱元素 - 可通过自定义格式和逻辑进行扩展 - 在给定 JSON schema 的情况下支持结构化提取 (beta) - 可选择通过 LLM(以及您自己的 prompt)提升准确率 - 支持 GPU、CPU 或 MPS 运行 ## 体验 Datalab 托管平台 我们的托管平台运行我们最新的开源模型 [Chandra](https://github.com/datalab-to/chandra) —— 准确率比 Marker 更高,默认零数据留存,具备 SOC 2 Type 2 认证,并支持自定义 BAA。 商业用途的自托管需要许可证 —— 请参阅[商业用途](#commercial-usage)。如需本地部署许可,请[联系我们](https://www.datalab.to/contact?utm_source=gh-marker-onprem)。 ## 性能表现 与 Llamaparse 和 Mathpix 等云服务以及其他开源工具相比,Marker 在基准测试中表现优异。 上述结果为串行处理单个 PDF 页面。在批处理模式下,Marker 的速度要快得多,在 H100 上的预期吞吐量可达 25 页/秒。 有关详细的速度和准确率基准测试,以及如何运行您自己的基准测试的说明,请参阅[下文](#benchmarks)。 ## 混合模式 为了获得最高的准确率,请传入 `--use_llm` 标志以在 marker 之外结合使用 LLM。这将执行诸如合并跨页表格、处理行内数学公式、正确格式化表格以及从表单中提取值等操作。它可以使用任何 gemini 或 ollama 模型。默认情况下,它使用 `gemini-2.0-flash`。详情请参阅[下文](#llm-services)。 以下是将 marker、单独的 gemini flash 以及结合 use_llm 的 marker 进行表格基准测试的对比: 如您所见,use_llm 模式比单独使用 marker 或 gemini 提供了更高的准确率。 ## 示例 | PDF | 文件类型 | Markdown | JSON | |-----|-----------|------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------| | [Think Python](https://greenteapress.com/thinkpython/thinkpython.pdf) | 教科书 | [查看](https://github.com/VikParuchuri/marker/blob/master/data/examples/markdown/thinkpython/thinkpython.md) | [查看](https://github.com/VikParuchuri/marker/blob/master/data/examples/json/thinkpython.json) | | [Switch Transformers](https://arxiv.org/pdf/2101.03961.pdf) | arXiv 论文 | [查看](https://github.com/VikParuchuri/marker/blob/master/data/examples/markdown/switch_transformers/switch_trans.md) | [查看](https://github.com/VikParuchuri/marker/blob/master/data/examples/json/switch_trans.json) | | [多列 CNN](https://arxiv.org/pdf/1804.07821.pdf) | arXiv 论文 | [查看](https://github.com/VikParuchuri/marker/blob/master/data/examples/markdown/multicolcnn/multicolcnn.md) | [查看](https://github.com/VikParuchuri/marker/blob/master/data/examples/json/multicolcnn.json) | # 商业用途 我们的模型权重使用修改版的 AI Pubs Open RAIL-M 许可证(对研究、个人使用以及融资/收入低于 200 万美元的初创公司免费),我们的代码遵循 GPL 协议。如需更广泛的商业许可或移除 GPL 要求,请访问我们的定价页面[此处](https://www.datalab.to/pricing?utm_source=gh-marker)。 # 安装说明 您需要 python 3.10+ 和 [PyTorch](https://pytorch.org/get-started/locally/)。 安装命令: ``` pip install marker-pdf ``` 如果您想在 PDF 以外的文档上使用 marker,您需要通过以下命令安装额外的依赖项: ``` pip install marker-pdf[full] ``` # 使用方法 首先,是一些配置说明: - 您的 torch device 将被自动检测,但您也可以手动覆盖。例如,`TORCH_DEVICE=cuda`。 - 某些 PDF,甚至是数字 PDF,其中的文本可能存在乱码。设置 `--force_ocr` 可强制对所有行进行 OCR,或者使用 `strip_existing_ocr` 保留所有数字文本并移除现有的 OCR 文本。 - 如果您关心行内数学公式,请设置 `force_ocr` 将行内数学公式转换为 LaTeX。 ## 交互式应用 我包含了一个 streamlit 应用程序,让您可以通过一些基本选项交互式地尝试 marker。运行命令: ``` pip install streamlit streamlit-ace marker_gui ``` ## 转换单个文件 ``` marker_single /path/to/file.pdf ``` 您可以传入 PDF 或图片。 选项: - `--page_range TEXT`:指定要处理的页面。接受以逗号分隔的页码和范围。例如:`--page_range "0,5-10,20"` 将处理第 0 页、第 5 到 10 页以及第 20 页。 - `--output_format [markdown|json|html|chunks]`:指定输出结果的格式。 - `--output_dir PATH`:保存输出文件的目录。默认为 settings.OUTPUT_DIR 中指定的值。 - `--paginate_output`:对输出进行分页,使用 `\n\n{PAGE_NUMBER}` 并在后面加上 `-` * 48,然后是 `\n\n` - `--use_llm`:使用 LLM 提高准确率。您需要配置 LLM 后端 - 请参阅[下文](#llm-services)。 - `--force_ocr`:强制对整个文档进行 OCR 处理,即使是那些可能包含可提取文本的页面。这也能正确格式化行内数学公式。 - `--block_correction_prompt`:如果 LLM 模式处于激活状态,此可选 prompt 将用于纠正 marker 的输出。这对于您想应用于输出的自定义格式或逻辑非常有用。 - `--strip_existing_ocr`:移除文档中所有现有的 OCR 文本,并使用 surya 重新进行 OCR。 - `--redo_inline_math`:如果您想要绝对最高质量的行内数学公式转换,请将此选项与 `--use_llm` 结合使用。 - `--disable_image_extraction`:不要从 PDF 中提取图片。如果您同时指定了 `--use_llm`,则图片将被替换为描述。 - `--debug`:启用 debug 模式以获取额外的日志和诊断信息。 - `--processors TEXT`:通过提供完整的模块路径(以逗号分隔)来覆盖默认的处理器。例如:`--processors "module1.processor1,module2.processor2"` - `--config_json PATH`:包含额外设置的 JSON 配置文件的路径。 - `config --help`:列出所有可用的构建器、处理器和转换器及其相关配置。这些值可用于构建 JSON 配置文件,以便进一步微调 marker 的默认设置。 - `--converter_cls`:可选 `marker.converters.pdf.PdfConverter`(默认)或 `marker.converters.table.TableConverter`。`PdfConverter` 将转换整个 PDF,而 `TableConverter` 将仅提取并转换表格。 - `--llm_service`:如果传入了 `--use_llm`,则指定要使用的 llm 服务。默认为 `marker.services.gemini.GoogleGeminiService`。 - `--help`:查看可以传递给 marker 的所有标志。(它支持比上面列出的多得多的选项) surya OCR 支持的语言列表在[这里](https://github.com/VikParuchuri/surya/blob/master/surya/recognition/languages.py)。如果您不需要 OCR,marker 可以处理任何语言的文档。 ## 转换多个文件 ``` marker /path/to/input/folder ``` - `marker` 支持上述 `marker_single` 的所有相同选项。 - `--workers` 是同时运行的转换 worker 数量。默认情况下这是自动设置的,但您可以增加它以提高吞吐量,代价是增加 CPU/GPU 的使用率。在峰值时,Marker 每个 worker 将使用 5GB 的 VRAM,平均使用 3.5GB。 ## 在多个 GPU 上转换多个文件 ``` NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out ``` - `NUM_DEVICES` 是要使用的 GPU 数量。应该为 `2` 或更大。 - `NUM_WORKERS` 是在每个 GPU 上运行的并行进程数。 ## 从 python 中使用 请查看 `marker/converters/pdf.py` 中的 `PdfConverter` 类,了解可以传递的其他参数。 ``` from marker.converters.pdf import PdfConverter from marker.models import create_model_dict from marker.output import text_from_rendered converter = PdfConverter( artifact_dict=create_model_dict(), ) rendered = converter("FILEPATH") text, _, images = text_from_rendered(rendered) ``` `rendered` 将是一个 pydantic basemodel,根据请求的输出类型具有不同的属性。使用 markdown 输出(默认)时,您将拥有 `markdown`、`metadata` 和 `images` 属性。对于 json 输出,您将拥有 `children`、`block_type` 和 `metadata`。 ### 自定义配置 您可以使用 `ConfigParser` 传递配置。要查看所有可用选项,请执行 `marker_single --help`。 ``` from marker.converters.pdf import PdfConverter from marker.models import create_model_dict from marker.config.parser import ConfigParser config = { "output_format": "json", "ADDITIONAL_KEY": "VALUE" } config_parser = ConfigParser(config) converter = PdfConverter( config=config_parser.generate_config_dict(), artifact_dict=create_model_dict(), processor_list=config_parser.get_processors(), renderer=config_parser.get_renderer(), llm_service=config_parser.get_llm_service() ) rendered = converter("FILEPATH") ``` ### 提取块 每个文档由一个或多个页面组成。页面包含块,块本身也可以包含其他块。可以通过编程方式操作这些块。 以下是从文档中提取所有表单的示例: ``` from marker.converters.pdf import PdfConverter from marker.models import create_model_dict from marker.schema import BlockTypes converter = PdfConverter( artifact_dict=create_model_dict(), ) document = converter.build_document("FILEPATH") forms = document.contained_blocks((BlockTypes.Form,)) ``` 查看处理器以获取更多提取和操作块的示例。 ## 其他转换器 您还可以使用其他定义了不同转换 pipeline 的转换器: ### 提取表格 `TableConverter` 将仅转换并提取表格: ``` from marker.converters.table import TableConverter from marker.models import create_model_dict from marker.output import text_from_rendered converter = TableConverter( artifact_dict=create_model_dict(), ) rendered = converter("FILEPATH") text, _, images = text_from_rendered(rendered) ``` 它采用与 PdfConverter 相同的配置。您可以指定配置 `force_layout_block=Table` 以避免布局检测,并假定每一页都是一个表格。设置 `output_format=json` 可同时获取单元格边界框。 您也可以通过 CLI 运行此命令 ``` marker_single FILENAME --use_llm --force_layout_block Table --converter_cls marker.converters.table.TableConverter --output_format json ``` ### 仅 OCR 如果您只想运行 OCR,也可以通过 `OCRConverter` 完成。设置 `--keep_chars` 以保留单个字符和边界框。 ``` from marker.converters.ocr import OCRConverter from marker.models import create_model_dict converter = OCRConverter( artifact_dict=create_model_dict(), ) rendered = converter("FILEPATH") ``` 它采用与 PdfConverter 相同的配置。 您也可以通过 CLI 运行此命令 ``` marker_single FILENAME --converter_cls marker.converters.ocr.OCRConverter ``` ### 结构化提取 (beta) 您可以通过 `ExtractionConverter` 运行结构化提取。这需要先设置 llm 服务(详情请参阅[此处](#llm-services))。您将获得包含提取值的 JSON 输出。 ``` from marker.converters.extraction import ExtractionConverter from marker.models import create_model_dict from marker.config.parser import ConfigParser from pydantic import BaseModel class Links(BaseModel): links: list[str] schema = Links.model_json_schema() config_parser = ConfigParser({ "page_schema": schema }) converter = ExtractionConverter( artifact_dict=create_model_dict(), config=config_parser.generate_config_dict(), llm_service=config_parser.get_llm_service(), ) rendered = converter("FILEPATH") ``` Rendered 将包含一个 `original_markdown` 字段。如果您下次运行转换器时将其作为 `existing_markdown` 配置键传入,则可以跳过重新解析文档。 # 输出格式 ## Markdown Markdown 输出将包含: - 图片链接(图片将保存在同一文件夹中) - 格式化的表格 - 嵌入的 LaTeX 公式(由 `$$` 标记) - 由三个反引号标记的代码 - 脚注的上标 ## HTML HTML 输出类似于 markdown 输出: - 图片通过 `img` 标签包含 - 公式由 `` 标签标记 - 代码位于 `pre` 标签中 ## JSON JSON 输出将被组织成树状结构,其叶节点即为块。叶节点的示例包括单个列表项、一段文本或一张图片。 输出将是一个列表,每个列表项代表一个页面。在内部 marker schema 中,每一页都被视为一个块。有不同类型的块来表示不同的元素。 页面具有以下键: - `id` - 块的唯一 id。 - `block_type` - 块的类型。可以在 `marker/schema/__init__.py` 中查看可能的块类型。截至撰写本文时,它们为 ["Line", "Span", "FigureGroup", "TableGroup", "ListGroup", "PictureGroup", "Page", "Caption", "Code", "Figure", "Footnote", "Form", "Equation", "Handwriting", "TextInlineMath", "ListItem", "PageFooter", "PageHeader", "Picture", "SectionHeader", "Table", "Text", "TableOfContents", "Document"] - `html` - 页面的 HTML。请注意,这将包含对子节点的递归引用。如果需要完整的 HTML,必须将 `content-ref` 标记替换为子内容。您可以在 `marker/output.py:json_to_html` 中查看相关示例。该函数将从 JSON 输出中获取单个块,并将其转换为 HTML。 - `polygon` - 页面的四角多边形,格式为 (x1,y1), (x2,y2), (x3, y3), (x4, y4)。(x1,y1) 是左上角,坐标按顺时针方向排列。 - `children` - 子块。 子块还有两个额外的键: - `section_hierarchy` - 指示该块所属的章节。`1` 表示 h1 标签,`2` 表示 h2,依此类推。 - `images` - base64 编码的图片。键将是块 ID,数据将是编码后的图片。 请注意,页面的子块本身也可以有自己的子节点(一种树状结构)。 ``` { "id": "/page/10/Page/366", "block_type": "Page", "html": "", "polygon": [[0.0, 0.0], [612.0, 0.0], [612.0, 792.0], [0.0, 792.0]], "children": [ { "id": "/page/10/SectionHeader/0", "block_type": "SectionHeader", "html": "

Supplementary Material for Subspace Adversarial Training

", "polygon": [ [217.845703125, 80.630859375], [374.73046875, 80.630859375], [374.73046875, 107.0], [217.845703125, 107.0] ], "children": null, "section_hierarchy": { "1": "/page/10/SectionHeader/1" }, "images": {} }, ... ] } ``` ## Chunks Chunks 格式类似于 JSON,但它将所有内容展平为一个列表,而不是树状结构。每页中只有顶层块会显示出来。它还包含每个块内部的完整 HTML,因此您不需要遍历树来重建它。这使得 RAG 的分块处理变得灵活且简单。 ## 元数据 所有输出格式都将返回一个元数据字典,包含以下字段: ``` { "table_of_contents": [ { "title": "Introduction", "heading_level": 1, "page_id": 0, "polygon": [...] } ], // computed PDF table of contents "page_stats": [ { "page_id": 0, "text_extraction_method": "pdftext", "block_counts": [("Span", 200), ...] }, ... ] } ``` # LLM 服务 在使用 `--use_llm` 标志运行时,您可以选择要使用的服务: - `Gemini` - 默认情况下将使用 Gemini 开发者 API。您需要在配置中传入 `--gemini_api_key`。 - `Google Vertex` - 这将使用 vertex,可能会更可靠。您需要传入 `vertex_project_id`。要使用它,请设置 `--llm_service=marker.services.vertex.GoogleVertexService`。 - `Ollama` - 这将使用本地模型。您可以配置 `--ollama_base_url` 和 `--ollama_model`。要使用它,请设置 `--llm_service=marker.services.ollama.OllamaService`。 - `Claude` - 这将使用 anthropic API。您可以配置 `--claude_api_key` 和 `--claude_model_name`。要使用它,请设置 `--llm_service=marker.services.claude.ClaudeService`。 - `OpenAI` - 支持任何类似 openai 的 endpoint。您可以配置 `--openai_api_key`、`--openai_model` 和 `--openai_base_url`。要使用它,请设置 `--llm_service=marker.services.openai.OpenAIService`。 - `Azure OpenAI` - 使用 Azure OpenAI 服务。您可以配置 `--azure_endpoint`、`--azure_api_key` 和 `--deployment_name`。要使用它,请设置 `--llm_service=marker.services.azure_openai.AzureOpenAIService`。 这些服务可能还有其他可选配置 —— 您可以通过查看这些类来了解。 # 内部机制 Marker 易于扩展。Marker 的核心单元是: - `Providers`,位于 `marker/providers`。它们提供来自源文件(如 PDF)的信息。 - `Builders`,位于 `marker/builders`。它们使用来自 providers 的信息生成初始文档块并填充文本。 - `Processors`,位于 `marker/processors`。它们处理特定的块,例如表格格式化器就是一个处理器。 - `Renderers`,位于 `marker/renderers`。它们使用块来渲染输出。 - `Schema`,位于 `marker/schema`。所有块类型的类。 - `Converters`,位于 `marker/converters`。它们运行整个端到端的 pipeline。 要自定义处理行为,请覆盖 `processors`。要添加新的输出格式,请编写新的 `renderer`。对于额外的输入格式,请编写新的 `provider.` 处理器和渲染器可以直接传递给基础的 `PDFConverter`,因此您可以轻松指定您自己的自定义处理。 ## API 服务器 有一个非常简单的 API 服务器,您可以像这样运行: ``` pip install -U uvicorn fastapi python-multipart marker_server --port 8001 ``` 这将启动一个 fastapi 服务器,您可以在 `localhost:8001` 访问它。您可以转到 `localhost:8001/docs` 查看 endpoint 选项。 您可以像这样发送请求: ``` import requests import json post_data = { 'filepath': 'FILEPATH', # Add other params here } requests.post("http://localhost:8001/marker", data=json.dumps(post_data)).json() ``` 请注意,这不是一个非常健壮的 API,仅供小规模使用。如果您想使用此服务器,但需要更健壮的转换选项,您可以使用托管的 [Datalab API](https://www.datalab.to/plans)。 # 故障排除 如果运行结果未达到预期,以下设置可能会对您有所帮助: - 如果您遇到准确率问题,请尝试设置 `--use_llm` 以使用 LLM 提高质量。您必须将 `GOOGLE_API_KEY` 设置为 Gemini API 密钥才能使其正常工作。 - 如果看到乱码文本,请确保设置 `force_ocr` —— 这将对文档重新进行 OCR。 - `TORCH_DEVICE` - 设置此项可强制 marker 使用指定的 torch 设备进行推理。 - 如果您遇到内存不足错误,请减少 worker 数量。您也可以尝试将较长的 PDF 拆分为多个文件。 ## 调试 传入 `debug` 选项以激活 debug 模式。这将保存每页检测到的布局和文本的图像,并输出一个包含额外边界框信息的 JSON 文件。 # 基准测试 ## 整体 PDF 转换 我们通过从公共爬取数据中提取单个 PDF 页面,创建了一个[基准测试集](https://huggingface.co/datasets/datalab-to/marker_benchmark)。我们基于将文本与真实文本段对齐的启发式方法,以及 LLM 作为裁判的评分方法来进行打分。 | 方法 | 平均时间 | 启发式得分 | LLM 得分 | |------------|----------|-----------------|-----------| | marker | 2.83837 | 95.6709 | 4.23916 | | llamaparse | 23.348 | 84.2442 | 3.97619 | | mathpix | 6.36223 | 86.4281 | 4.15626 | | docling | 3.69949 | 86.7073 | 3.70429 | 基准测试是在 H100 上针对 markjer 和 docling 运行的 —— llamaparse 和 mathpix 使用了它们的云服务。我们还可以按文档类型查看结果: | 文档类型 | Marker 启发式 | Marker LLM | Llamaparse 启发式 | Llamaparse LLM | Mathpix 启发式 | Mathpix LLM | Docling 启发式 | Docling LLM | |----------------------|------------------|------------|----------------------|----------------|-------------------|-------------|-------------------|-------------| | 科学论文 | 96.6737 | 4.34899 | 87.1651 | 3.96421 | 91.2267 | 4.46861 | 92.135 | 3.72422 | | 书籍页面 | 97.1846 | 4.16168 | 90.9532 | 4.07186 | 93.8886 | 4.35329 | 90.0556 | 3.64671 | | 其他 | 95.1632 | 4.25076 | 81.1385 | 4.01835 | 79.6231 | 4.00306 | 83.8223 | 3.76147 | | 表单 | 88.0147 | 3.84663 | 66.3081 | 3.68712 | 64.7512 | 3.33129 | 68.3857 | 3.40491 | | 演示文稿 | 95.1562 | 4.13669 | 81.2261 | 4 | 83.6737 | 3.95683 | 84.8405 | 3.86331 | | 财务文档 | 95.3697 | 4.39106 | 82.5812 | 4.16111 | 81.3115 | 4.05556 | 86.3882 | 3.8 | | 信函 | 98.4021 | 4.5 | 93.4477 | 4.28125 | 96.0383 | 4.45312 | 92.0952 | 4.09375 | | 工程文档 | 93.9244 | 4.04412 | 77.4854 | 3.72059 | 80.3319 | 3.88235 | 79.6807 | 3.42647 | | 法律文档 | 96.689 | 4.27759 | 86.9769 | 3.87584 | 91.601 | 4.20805 | 87.8383 | 3.65552 | | 报纸页面 | 98.8733 | 4.25806 | 84.7492 | 3.90323 | 96.9963 | 4.45161 | 92.6496 | 3.51613 | | 杂志页面 | 98.2145 | 4.38776 | 87.2902 | 3.97959 | 93.5934 | 4.16327 | 93.0892 | 4.02041 | ## 吞吐量 我们使用[单个长 PDF](https://www.greenteapress.com/thinkpython/thinkpython.pdf) 测试了吞吐量。 | 方法 | 每页耗时 | 每份文档耗时 | 使用的 VRAM | |---------|---------------|-------------------|---------- | | marker | 0.18 | 43.42 | 3.17GB | 在 H100 上的预期吞吐量为每秒 122 页 —— 考虑到所使用的 VRAM,我们可以运行 22 个独立进程。 ## 表格转换 Marker 可以使用 `marker.converters.table.TableConverter` 从 PDF 中提取表格。表格提取性能的衡量方法是将提取的表格 HTML 表示与使用 [FinTabNet](https://developer.ibm.com/exchanges/data/all/fintabnet/) 测试集的原始 HTML 表示进行比较。使用基于树编辑距离的指标来比较 HTML 表示,以判断结构和内容。Marker 检测并识别 PDF 页面中所有表格的结构,并取得以下分数: | 方法 | 平均得分 | 表格总数 | |------------------|-----------|--------------| | marker | 0.816 | 99 | | marker w/use_llm | 0.907 | 99 | | gemini | 0.829 | 99 | 正如您所见,`--use_llm` 标志可以显著提高表格识别性能。 我们过滤掉了无法与真实情况对齐的表格,因为 fintabnet 和我们的布局模型检测方法略有不同(这会导致某些表格被拆分/合并)。 ## 运行您自己的基准测试 您可以在您的机器上对 marker 的性能进行基准测试。手动安装 marker: ``` git clone https://github.com/VikParuchuri/marker.git poetry install ``` ### 整体 PDF 转换 在[此处](https://drive.google.com/file/d/1ZSeWDo2g1y0BRLT7KnbmytV2bjWARWba/view?usp=sharing)下载基准数据并解压。然后像这样运行整体基准测试: ``` python benchmarks/overall.py --methods marker --scores heuristic,llm ``` 选项: - `--use_llm` 使用 llm 来改善 marker 的结果。 - `--max_rows` 指定基准测试要处理多少行。 - `--methods` 可以是 `llamaparse`、`mathpix`、`docling`、`marker`。以逗号分隔。 - `--scores` 指定要使用哪些评分函数,可以是 `llm`、`heuristic`。以逗号分隔。 ### 表格转换 处理后的 FinTabNet 数据集托管在[此处](https://huggingface.co/datasets/datalab-to/fintabnet-test),并会自动下载。使用以下命令运行基准测试: ``` python benchmarks/table/table.py --max_rows 100 ``` 选项: - `--use_llm` 结合 marker 使用 llm 以提高准确率。 - `--use_gemini` 同时对 gemini 2.0 flash 进行基准测试。 # 工作原理 Marker 是一个由深度学习模型组成的 pipeline: - 提取文本,必要时进行 OCR(启发式方法,[surya](https://github.com/VikParuchuri/surya)) - 检测页面布局并找到阅读顺序([surya](https://github.com/VikParuchuri/surya)) - 清理并格式化每个块(启发式方法,[texify](https://github.com/VikParuchuri/texify),[surya](https://github.com/VikParuchuri/surya)) - 可选择使用 LLM 提高质量 - 合并块并对完整文本进行后处理 它仅在必要时才使用模型,从而提高了速度和准确率。 # 限制 PDF 是一种复杂的格式,因此 marker 并不总是能完美运行。以下是路线图中计划解决的一些已知限制: - 非常复杂的布局,包含嵌套的表格和表单,可能无法正常工作 - 表单可能无法很好地渲染 注意:传入 `--use_llm` 和 `--force_ocr` 标志将主要解决这些问题。 # 用法与部署示例 您始终可以在本地运行 `marker`,但如果您想将其作为 API 公开,我们有几个选项:
标签:AI风险缓解, Kubernetes, Markdown, OCR, PDF转换, 凭据扫描, 数据提取, 文档智能, 深度学习, 逆向工具