开源PDF剖析工具Marker深度剖析

开源PDF剖析工具Marker深度剖析

检索加强生成（RAG）系统的第一步就是做 pdf 剖析，从复杂多样的 pdf 中提取出干净正确的文本内容。现有的最优秀的开源工具有两个：Marker 和 MinerU。由于 Marker 是个人开发者做的，文档不美满，所以这里基于我个人的明白对它的代码举行剖析。
深度学习模型

在marker/models.py中可以看到，marker 用到了如下的深度学习模型:

1. def create_model_dict(device=None, dtype=None) -> dict:
2.     return {
3.         "layout_model": LayoutPredictor(device=device, dtype=dtype),
4.         "texify_model": TexifyPredictor(device=device, dtype=dtype),
5.         "recognition_model": RecognitionPredictor(device=device, dtype=dtype),
6.         "table_rec_model": TableRecPredictor(device=device, dtype=dtype),
7.         "detection_model": DetectionPredictor(device=device, dtype=dtype),
8.         "inline_detection_model": InlineDetectionPredictor(device=device, dtype=dtype),
9.         "ocr_error_model": OCRErrorPredictor(device=device, dtype=dtype)
10.     }

复制代码

这些模型都来自surya，作者没有直接先容这些模型的原理，但可推测
像检测相干的 DetectionPredictor 和 InlineDetectionPredictor 可能用 Faster R - CNN、YOLO 系列等目标检测模型；

• LayoutPredictor 或接纳 Mask R - CNN 、LayoutLM 等举行布局分析；
  
• OCRErrorPredictor 或许借助 RNN 变体或 BERT 类模型处置惩罚 OCR 错误；
  
• RecognitionPredictor 可能使用 CRNN 等做字符识别；
  
• TableRecPredictor 会用到基于 GNN 的模型处置惩罚表格；
  
• TexifyPredictor 可能接纳 Seq2Seq 或 Transformer - based 的 Seq2Seq 模型来生成 LaTeX 代码。
  

代码使用 PyTorch 框架，可指定设备和数据类型。
剖析流程

由于别的数据类型（docx，pptx，xlsx）都可以转成pdf，所以 pdf 是 marker 处置惩罚的紧张对象。从marker/converters/pdf.py可以看随处置惩罚pdf 的所有流程如下。marker 先通过以下游程，把pdf 剖析为 document（抽象语法树），然后将document 渲染为json，html 大概markdown 格式。

1. default_processors: Tuple[BaseProcessor, ...] = (
2.         OrderProcessor,
3.         LineMergeProcessor,
4.         BlockquoteProcessor,
5.         CodeProcessor,
6.         DocumentTOCProcessor,
7.         EquationProcessor,
8.         FootnoteProcessor,
9.         IgnoreTextProcessor,
10.         LineNumbersProcessor,
11.         ListProcessor,
12.         PageHeaderProcessor,
13.         SectionHeaderProcessor,
14.         TableProcessor,
15.         LLMTableProcessor,
16.         LLMTableMergeProcessor,
17.         LLMFormProcessor,
18.         TextProcessor,
19.         LLMInlineMathLinesProcessor,
20.         LLMComplexRegionProcessor,
21.         LLMImageDescriptionProcessor,
22.         LLMEquationProcessor,
23.         LLMHandwritingProcessor,
24.         LLMMathBlockProcessor,
25.         ReferenceProcessor,
26.         DebugProcessor,
27.     )

复制代码

通用格式处置惩罚

• OrderProcessor - 用于处置惩罚文档中元素的顺序，确保各部分内容按照正确的逻辑顺序排列，比如调解段落、列表项等的先后顺序。
  
• LineMergeProcessor - 对分割的行举行合并操纵。在OCR处置惩罚或文档剖析过程中，文本可能会被错误地分割成多行，该处置惩罚器会将相干的行合并成公道的段落或语句。
  
• LineNumbersProcessor - 处置惩罚文档中的行号信息。它可以识别、提取或添加行号，也可能对行号的格式和编号规则举行调解，以符合特定的输出要求。
  

特定元素处置惩罚

• BlockquoteProcessor - 专门处置惩罚文档中的块引用内容。它会识别块引用的起始和竣事位置，对其举行格式化，比方添加特定的缩进或标志来区分块引用与普通文本。
  
• CodeProcessor - 处置惩罚代码块。会识别代码块的边界，对代码举行语法高亮处置惩罚（如果需要），并确保代码的格式在转换过程中保持正确，比方保存缩进、换行等。
  
• ListProcessor - 处置惩罚列表元素，包括有序列表和无序列表。它会识别列表项的格式，确保列表的编号或标志正确显示，而且处置惩罚列表嵌套等复杂情况。
  
• PageHeaderProcessor - 处置惩罚文档页面的页眉部分。可以识别页眉内容，对其举行提取、格式化或去除不必要的信息，以包管页眉内容在输出中正确显示。
  
• SectionHeaderProcessor - 处置惩罚文档中的章节标题。它会识别差别级别的章节标题，根据标题的条理布局举行相应的格式化，比方设置差别的字体巨细、加粗等，以体现章节的主次关系。
  
• TableProcessor - 处置惩罚文档中的表格。会识别表格的布局，包括表头、表体、单位格等，对表格举行格式化，确保表格的布局和内容在转换后正确显示，可能还会处置惩罚表格的合并单位格等情况。
  

特定内容处置惩罚

• DocumentTOCProcessor - 生成文档的目次（TOC）。它会分析文档中的章节标题，根据标题的条理布局生成目次，并为每个目次项添加对应的页码或链接，方便读者快速定位文档内容。
  
• EquationProcessor - 处置惩罚文档中的数学公式。会识别公式的格式，可能会将公式转换为特定的体现形式，如LaTeX代码，以便在后续的渲染中正确显示数学内容。
  
• FootnoteProcessor - 处置惩罚文档中的脚注。它会识别脚注的引用标志和脚注内容，将脚注正确地放置在页面底部或文档末端，并处置惩罚脚注与正文的关联。
  
• TextProcessor - 对普通文本举行处置惩罚，包括文本的清理、更换、巨细写转换等操纵，以确保文本的质量和同等性。
  
• ReferenceProcessor - 处置惩罚文档中的参考文献。它会识别参考文献的格式，对其举行整理和格式化，使其符合特定的引用规范，如APA、MLA等。
  基于大语言模型（LLM）的处置惩罚
  
• LLMTableProcessor - 使用大语言模型对表格举行处置惩罚。可以对表格内容举行语义分析、增补缺失信息、优化表格布局等，以提高表格处置惩罚的质量和智能化程度。
  
• LLMTableMergeProcessor - 使用大语言模型来处置惩罚表格合并的情况。当文档中有多个相干表格需要合并时，该处置惩罚器借助大语言模型的明白本事，公道地合并表格内容，确保合并后的表格逻辑清晰。
  
• LLMFormProcessor - 使用大语言模型处置惩罚文档中的表单。可以识别表单的字段、填写要求，甚至可以根据上下文对表单内容举行主动填充或验证。
  
• LLMInlineMathLinesProcessor - 借助大语言模型处置惩罚行内数学公式。它可以对行内数学公式举行更正确的识别和转换，提高公式处置惩罚的正确性和可读性。
  
• LLMComplexRegionProcessor - 处置惩罚文档中的复杂区域，这些区域可能包含多种类型的元素，如文本、图像、表格等。大语言模型可以资助明白这些复杂区域的布局和语义，举行更公道的处置惩罚和转换。
  
• LLMImageDescriptionProcessor - 使用大语言模型为文档中的图像生成描述信息。可以根据图像的内容、上下文等生成正确的图像描述，提高文档的可访问性和信息完备性。
  
• LLMEquationProcessor - 结合大语言模型处置惩罚数学公式。与普通的 EquationProcessor 相比，它可以使用大语言模型的语义明白本事，对公式举行更深入的分析和处置惩罚，比方对公式举行表明、推导等。
  
• LLMHandwritingProcessor - 使用大语言模型处置惩罚手写内容。可以识别手写笔墨，将其转换为可编辑的文本，并对识别结果举行优化和纠错，提高手写内容处置惩罚的正确性。
  
• LLMMathBlockProcessor - 借助大语言模型处置惩罚独立的数学块。它可以对数学块举行更细致的分析和处置惩罚，确保数学块的内容和格式在转换后正确显示，同时可能会对数学块举行语义表明等操纵。
  

调试相干

• DebugProcessor - 紧张用于调试目的。它可以输出一些调试信息，资助开发者检查文档处置惩罚过程中的中心结果、变量值等，以便发现和解决问题。 这些处置惩罚器共同作用，对PDF文档举行全面、细致的剖析和处置惩罚，以实现将PDF转换为其他格式（如Markdown）的功能。
  

别的类型的文件处置惩罚方式：

• 对于docx，marker使用mammoth库把docx转换成HTML，然后再用weasyprint库把HTML转成PDF。中心隔了一个HTML，效果很差，亲测不如用 wps 把docx 转pdf。
  
• 对于pptx，使用python-pptx库剖析pptx元素，然后转化成HTML，再用weasyprint 将 HTML 渲染为 PDF。
  
• 对于xlsx，使用openpyxl库的 load_workbook 加载 XLSX 文件，将每个工作表转换为包含合并单位格处置惩罚的 HTML 表格。通过weasyprint 转成pdf。
  

Renderers

marker 提供了三种格式的输出：json、html、markdown，它们的代码都在marker/renderers。这三种格式包含的信息不是相同的，以下是分析：

• 由于 document 最轻易转化为 json（都是树布局可以直接转），所以 json 包含的信息最多（比如包含了caption 的分类结果，还有目标检测bbox 框），但由于过于复杂所以一样寻常用不上。
  
• html 是可视化效果最好的，尤其是表格，marker 对表格的剖析非常惊艳，不但文本正确识别，而且能识别出复杂的表布局（比如合并单位格），这些都能用 html 很好的渲染。
  
• markdown 包含的信息量最少，但是胜在简单，在 RAG 使命中适合作为下游 LLM 模型的输入。注意markdown 是从html 转换过来的而不是document，所以一些复杂布局（比如表格）会有失真。
  

renderers 中的代码可读性不错，可以自己修改得到想要的输出。比如我就修改过 markdown 的输出，让它包含页码、bbox、table html 等信息。
总结

marker 是一个非常优秀的基于深度学习的 pdf 剖析工具，它可以在大部分场景下得到完美的剖析结果，代码可读性和拓展性也很不错，很难想象这是一个人独自开发出来的。
marker 项目地点：https://github.com/VikParuchuri/marker

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。