在RAG系统中，文档解析的质量直接决定了后续检索和生成的上限。这个名为Deepdoc的解析工具，其架构设计思路很值得拿出来聊聊——它没有走“一套模型打天下”的路线，而是针对不同文档类型构建了差异化的解析管线。下面就从项目结构开始，逐步拆解它的核心组件和设计逻辑。
项目结构
|--deepdoc
|--parser
|--resume
|--entities
|--step_one.py
|--step_two.py
|--docx_parser.py
|--pdf_parser.py
|--excel_parser.py
|--html_parser.py
|--json_parser.py
|--markdown_parser.py
|--ppt_parser.py
|--vision
|--layout_recoginzer.py
|--ocr.py
|--ocr.res
|--operators.py
|--postprocess.py
|--recoginzer.py
|--seeit.py
|--t_recoginzer.py
|--t_ocr.py
|--table_structure_recognizer.py核心组件
- • OCR
- • 版面结构分析
- • 表格结构识别
- • 解析器
解析器
解析器是整个系统的执行单元，每种文档类型都有对应的专用解析器。但其中有两个特例：简历和PDF，它们因为自身结构的特殊性，处理方式要复杂得多。
简历类型的处理
简历可以说是最“不守规矩”的文档。格式五花八门，排版随心所欲，但最终都要被拆解成姓名、工作经历、教育背景等结构化字段。处理分两步走：第一步，利用entities中预定义的大学、公司等行业实体信息，结合关键词进行初步提取；第二步，对提取的结果做合并与过滤，毕竟同一家公司的名字可能有多种写法，需要做个“归一化”处理。
PDF文档的处理
PDF文档的复杂程度排在简历之前。它不仅要动用OCR模型，还得处理千差万别的版面结构。为了解决页面元素的阅读顺序问题，系统内置了一套排序规则，同时还引入了XGB模型作为规则之外的补充手段。
有意思的是，从实测效果来看，规则已经能搞定绝大多数文本块的排序任务，XGB的实际贡献并不大。通过特征重要性分析也能看到，真正起作用的特征主要还是坐标类型——比如元素在页面中的位置和区域。这说明PDF的版式虽然在视觉上丰富多变，但底层逻辑依然有规律可循。
整个PDF处理流程可以简化成一串操作：
文档转图片 → 版面分析 → 表格识别 → 文字识别 → 合并段落 → 后处理
其他类型的处理
至于Word、Excel、PPT这些常见格式，处理起来相对常规。每一个都有对应的解析器，基本都是基于现成的成熟库来完成，没有太多需要特别展开的地方。
视觉信息处理
视觉模块是Deepdoc的“眼睛”，主要负责两件事：搞清楚页面长什么样，以及表格内部的结构是怎样的。
版面结构识别
不同类型的文件，布局差异巨大。学术论文里图表和公式密集，政府公文则往往是纯文字的段落堆叠。只有准确识别出文件类型和页面布局，后续处理才能有的放矢。系统定义了以下10种类别来区分不同的页面内容：
- • 文本
- • 标题
- • 配图
- • 配图标题
- • 表格
- • 表格标题
- • 页头
- • 页尾
- • 参考引用
- • 公式
执行命令:
python deepdoc/vision/t_recognizer.py --inputs=path_to_images_or_pdfs --threshold=0.2 --mode=layout --output_dir=path_to_store_result表格结构识别
表格的结构可能是文档解析中最棘手的部分——多层次嵌套的标题、跨列跨行的合并单元格、行列结构不统一……这些都是家常便饭。针对这些情况，表格结构识别定义了5种类别：
- • 列
- • 行
- • 列标题
- • 行标题
- • 合并单元格
执行命令:
python deepdoc/vision/t_recognizer.py --inputs=path_to_images_or_pdfs --threshold=0.2 --mode=tsr --output_dir=path_to_store_result与版面结构分析不同，表格结构识别只会把可能是表格的区域识别出来
