RAG 效果优化：高质量文档解析详解
作者：毛财胜
背景
尽管通用大语言模型（LLM）在知识问答方面取得了非常大的进展，但是对于专业领域依然无能为力，因为专业领域的数据不会对外公开，通用 LLM 没有学习过，自然不会回答。一种思路是将这些专业数据喂给 LLM 进行微调，但是对技术和成本要求往往太高，而 RAG 系统则是解决专业领域问答的另一种思路，在用户原始问题之后加上与之相关的私域数据一起提问，由通用 LLM 进行分析和总结。通过检索增强的方式为 LLM 提供更加精准的信息，从而提升最终回答效果，如下图所示：
知识数据库是 RAG 系统的核心组件，需要离线将各类私域文档转换成计算机可检索的数据。实际场景中，大部分专业文档都是以 pdf、doc 等非结构化数据进行存储，它们有标题、段落、表格、图片等元素，易于人类阅读，却不适合计算机进行检索和处理。文档解析是将这些非结构化文档转换为半结构化的文档（如 markdown、html），由系统后续进行切片、向量化处理，最终形成可检索的结构化数据。因此，文档解析是 RAG 系统的第一步，所谓 better input better output，高质量的解析结果自然会提升 RAG 系统整体的效果。
Word 与 Pdf 对比
Pdf 和 Word（MS Office 2007 之前为 doc，之后为 docx）是两种最常见的文档格式，但是二者有本质区别：
Word 倾向于编辑。Docx 格式遵循Office Open XML标准，底层通过 xml 保存数据，有标题、段落、表格等概念，但是不含页面和位置的概念，文档各个元素最终展现的位置由实际的渲染引擎决定（同一份文档不同软件打开后显示结果可能不同）。解析 docx 文件只需要按照标准读取底层的 xml 文件即可。doc 格式在 2008 年才对外开放（此时已被 docx 替代），能够解析的开源工具很少，通常是转换为 docx 文件后进行解析。
Pdf 倾向于阅读和打印。文档存储了一系列绘制字符、线条等基本元素的指令，指示了阅读器或打印机在屏幕或纸张上显示符号的位置和方式。相比 word，pdf 有页面和位置的概念，在不同终端的展示效果一致。因为不需要编辑，pdf 中没有标题、段落、表格等概念，例如标题只是大号加粗的文字，表格只是对齐排列的线条和文字。解析 pdf 文件除了需要提取出文字外，还需要进行额外的版面恢复、表格识别等操作。
以下是 docx 和 pdf 文件结构的示例：
总结：
Word 解析
docx 格式
一个 DOCX 文件实际上是一个包含多个文件和文件夹的压缩包，可以用解压缩工具进行解压。最小结构如下，示例为：📎minimal.docx
其中word/document.xml是 DOCX 文档的主要内容。参考上面的示例，以下是一些关键标签：
根元素，包含整个文档内容。
文档主体部分，包含所有段落、表格和其他内容。
(Paragraph)：段落元素。
(Run)：包含一段连续的文本，带有相同的格式。
(Text)：具体的文本内容。
(Section Properties)：节属性，定义页面设置如页边距、页码、页眉页脚等。
doc 格式
doc 格式本身是一个 OLE（Object Linking and Embedding）复合文档，文档将数据分成很多流（Steams），存储在不同的 Storages 里，详见MS-DOC文件格式规范。其中WordDocument二进制流是文档的主要内容，必须存在。据目前所知，python 环境下没有任何库能够直接读取 doc 文件中的内容。python olefile 虽然可以打开 doc 文件，但也仅限于打开，无法理解（decode）WordDocument 等流。因此 python 环境下一般通过libreoffice将 doc 文件转换为 docx 文件进行解析。同时为了避免文件加密导致转换失败，可以借助 olefile 及文件格式规范进行提前判断。
Pdf 解析
开源工具
目前 python 开源的 pdf 解析工具很多，总结如下：
其中 Papermage 对 PDFPlumber 进行了封装，并基于多个模型进行版面分析，功能最全，能识别标题、作者、摘要等元素，但仅限于论文场景。类似的还有ragflow-deepdoc（参考：深度解读RAGFlow的深度文档理解DeepDoc）。下面详细介绍下 Papermage。
PaperMage 介绍
第一步——纯文本提取
基于 PDFPlumber 将 pdf 中的文字部分提取出来，得到words集合，并基于 words 位置关系检测文本行（lines）。
第二步——视觉标注
将 pdf 按页光栅化成位图，通过目标检测技术识别位图中的元素，得到blocks，每个 block 包括了边界框（bounding box，bbox）和标签（如图片、表格等）信息。光栅化操作使用了 pdf2image 库（底层是 poppler），目标检测模型用的是 efficientdet 系列模型：layoutparser/efficientdet · Hugging Face。
可视化结果如下：
可以发现，bbox 是一个大致区域，主要目的是通过位置关系将 words 划分到不同 label 的 blocks 中，即第三步中的block_ids和labels。
第三步——字符级标注
字符标注模型使用了 I-VILA 系列模型（allenai/ivila-block-layoutlm-finetuned-s2vl-v2），将前两步的结果作为输入，输入格式如下：
预测出的标签有：
模型对于每个 word 都会预测出一个标签，相同标签的 word 聚合成一个实体（如titles、authors等），而实体的外接框为实体中所有 word 的外接框。
可视化结果如下（不同颜色表示不同实体，如红色表示标题，橙色表示作者，绿色表示段落，黑色表示脚注等）：
可以发现如果某个区域未提取到任何 word，则该区域就不会被标注，因此上图中图片未识别到（目标检测模型虽然检测到，但标签识别错误）。
总结：
目前开源工具可以分为两类。
（1）基于规则的方式，优势：适用性广泛、速度快。劣势：效果一般，识别的版面元素有限，且识别效果较差；
（2）基于模型的方式，优势：能够识别更多更上层的版面元素，有利于后续切片。劣势：速度慢，依赖 GPU 资源，适用的场景有限，识别过程黑盒（比如难以纠正上图中图片未识别的错误）。
关键问题
版面元素恢复
前面提到，pdf 相比 word 缺少了很多版面元素的概念，如果仅提取文本则会丢失很多信息（如语义段落信息，文字大小，位置信息等），不利于后续的文档切片。版面恢复主要包括识别标题、段落、上下标、页眉页脚等。
表格结构识别
表格分为两种，一种是全框表格，另一种是半框表格（如论文中常见的三线表）。准确识别表格的前提是准确定位到表格区域，然后识别出表格结构，最后提取出每个单元格对应的文本。
阅读顺序还原
通过版式恢复后，能够输出版面元素的 bounding box，如何准确的还原出符合人类阅读顺序的文档内容也是尤为重要。常见技术路径有：基于规则的方法（xy-cut 等)、基于深度学习的方法（Layoutreader等）。
阿里云搜索文档内容解析
整体架构
图中左侧和中间为 doc/docx 文件解析，右侧为 pdf 文件解析。对于 pdf 解析，我们采用了基于规则的方式，相比基于模型的方式，主要有以下考虑：
我们定位为通用场景，文档版面丰富多样，页数可能达到千页，模型性能泛化性达不到要求；
GPU 资源瓶颈，会限制服务最大吞吐量，而基于规则的方式只依赖 CPU 资源，可以无限扩缩；
模型效果黑盒化，badcase 难以纠正。
所有格式最终输出为 markdown 格式，支持的版面元素：
多级标题
自然段划分
图片（标量、矢量）
表格（全框、半框）
上标、下标（支持嵌套）
页眉、页脚
pdf 格式另外还支持：
阅读顺序还原
图片 OCR（支持影印版）
PPT 类型优化
效果示例
版面元素恢复
段落划分及阅读顺序，页脚识别
标题、段落、上下标、图片等元素识别
表格结构识别
原文
markdown
速度及准确率
测试集：53 篇论文
解析速度：
其中表格识别准确率（人工评测）：
服务体验
RAG 文档解析能力已在阿里云搜索开发工作台发布，搜索开发工作台围绕智能搜索及 RAG 场景，提供优质的组件化服务以及灵活的调用机制，内置文档解析、文档切片、文本向量、召回、排序及大模型等服务，可实现一站式灵活的 AI 搜索业务开发。
目前新用户可免费开通搜索开发工作台，获赠 100 次服务免费调用额度。
文档解析 API：https://help.aliyun.com/zh/open-search/search-platform/developer-reference/api-details
查看及体验搜索开发工作台更多服务：https://opensearch.console.aliyun.com/cn-shanghai/rag/server-market
还未添加个人签名 2020-10-15 加入
分享阿里云计算平台的大数据和AI方向的技术创新和趋势、实战案例、经验总结。
评论