在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与版面结构分析不同，表格结构识别只会锁定疑似表格的区域进行解析
