RagFlow文档解析过程分析

显示全部楼层

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;border-left: none;padding: 1em;border-radius: 8px;color: rgba(0, 0, 0, 0.5);background: rgb(247, 247, 247);margin: 2em 8px;">
RagFlow是当前比较流行的一个开源RAG应用，它的特点是号称基于深度文档理解（DeepDoc）进行构建的文档处理引擎，能够大幅提升RAG的实际效果。我前段时间由于工作需要通读了一下Ragflow的源码（基于0.17.0）版本，发现它在文档解析，文档检索等方面确实有一些独到的地方，这里就给大家分享一下我的一些理解吧，希望能帮助大家发现一些新的RAG优化的思路。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">RAG最重要的部分就是文档的解析，所谓的"Garbage in Garbage out", 如果文档解析的效果不好，应该收集的信息没有收集到，那么后续的检索过程做再多的优化也于事无补。所以我们先来看一下RagFlow是怎么做文档解析的。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 1.2em;font-weight: bold;display: table;margin: 4em auto 2em;padding: 0px 0.2em;background: rgb(15, 76, 129);color: rgb(255, 255, 255);">任务生成与管理

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">用户在页面上提交一个文档的解析请求，RagFlow会将其封装为一个异步任务到后台进行处理

1.任务切分
系统会根据文档类型和配置规则对任务进行切分。例如：

• PDF文件按页码范围切分（如1-50页、51-100页等）。
• Excel文件按行切分（每3000行为一个子任务）。
• 切分后的子任务将被放入异步任务队列，由Redis负责管理和分发。

2.任务去重优化
通过提取任务信息的哈希值，对任务队列进行去重，避免重复处理。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 1.2em;font-weight: bold;display: table;margin: 4em auto 2em;padding: 0px 0.2em;background: rgb(15, 76, 129);color: rgb(255, 255, 255);">文档解析器

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;margin: 1.5em 8px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">文档解析任务处理时，RagFlow会根据文档的文件类型以及用户选择的解析器（parser），来确定如何对文件进行解析。 RagFlow提供了多种类型的解析器，针对不同文档类型和内容特性进行优化。解析器分为两类：

•文件类型解析器：针对PDF、PPT、Word等文件格式的核心逻辑，源码位于deepdoc/parser。
•内容类型解析器：根据文档内容特性（如论文、Q/A、表格等）进一步细化对不同类型文档的处理方式，用户可选择适合的解析器以达到最好的解析效果。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;overflow-x: auto;border-radius: 8px;padding: 1em;margin: 10px 8px;">

classParserType(StrEnum)RESENTATION="presentation"LAWS="laws"MANUAL="manual"PAPER="paper"RESUME="resume"BOOK="book"QA="qa"TABLE="table"NAIVE="naive"PICTURE="picture"ONE="one"AUDIO="audio"EMAIL="email"KG="knowledge_graph"TAG="tag"

文档解析流程

我们这里以PDF文档的解析过程为例进行解释。PDF应该是我们日常最容易遇到的文档类型之一，而且由于其来源的复杂性（从word，ppt等文件导出，影印版的纯图片PDF，标准生成的pdf文档等），所以处理过程也是所有类型文档中流程最为复杂的，它的解析过程主要分为6个步骤（这里选择的是general解析器，源码位于rag/app/naive.py）

def__call__(self,filename,binary=None,from_page=0,to_page=100000,zoomin=3,callback=None):start=timer()first_start=startcallback(msg="OCRstarted")self.__images__(filenameifnotbinaryelsebinary,zoomin,from_page,to_page,callback)callback(msg="OCRfinished({:.2f}s)".format(timer()-start))logging.info("OCR({}~{}):{:.2f}s".format(from_page,to_page,timer()-start))start=timer()self._layouts_rec(zoomin)callback(0.63,"Layoutanalysis({:.2f}s)".format(timer()-start))start=timer()self._table_transformer_job(zoomin)callback(0.65,"Tableanalysis({:.2f}s)".format(timer()-start))start=timer()self._text_merge()callback(0.67,"Textmerged({:.2f}s)".format(timer()-start))tbls=self._extract_table_figure(True,zoomin,True,True)#self._naive_vertical_merge()self._concat_downward()#self._filter_forpages()logging.info("layoutscost:{}s".format(timer()-first_start))return[(b["text"],self._line_tag(b,zoomin))forbinself.boxes],tbls

1. 图像转换与OCR提取

• 将PDF页面转换为高清图片。
• 使用OCR技术提取文字信息，同时结合PDF原生文本提取功能，提升文字提取性能。
•优势：统一图片和文字处理逻辑，兼容扫描件PDF场景。

2. 布局分析

• 使用预训练模型分析每个页面的布局情况，将页面切分为文本、标题、图表、页眉/页脚等几个不同的类型区域。
• 记录区域的类型及其在图片中的坐标位置，并与OCR的文本块结果关联，为后续处理提供数据支撑。

3. 表格增强处理

• 针对布局分析中识别为表格的区域，使用预训练表格模型提取更加详细的结构化的表格数据（行列信息）。

4. 简单文本块合并

• 对前面识别出来的文本块进行合并，提升文本连贯性和可读性。相对于第五步的合并，这里没有使用任何预训练模型，只是基于布局规则的简单合并。
•合并条件：

• 布局一致性：同一布局区域且为普通文本。
• 垂直对齐：文本框垂直距离小于页面平均行高的1/3或1/5。
• 水平连续性：水平间距满足阈值或存在标点衔接。

•合并操作：扩展坐标、居中对齐、文本拼接、移除冗余。

5. 垂直方向文本块合并

• 进一步进行垂直方向上的文本块合并，将垂直方向上连续且语义相关的文本块（如跨行段落、跨页内容）合并为完整的文本段落，解决OCR结果中文本被错误分段的问题。这里主要使用XGBoost模型进行连续性判断。
•模型特征输入：几何特征（文本块的间距、高度比）、上下文特征（结尾的标点、跨页数）、语义特征（分词连续性）、布局特征（表格关联性）。

最终解析完成后生成并插入到ES中的文本块（chunk），主要包含五部分的信息：

• 文本块所在的文档标题信息（标题内容和分词结果）。
• 文本块的文本信息（内容及分词结果，内容受用户指定的最大token影响，但没有严格限制，合并时可能会超出）
• 文本块的文本信息的向量化数据（用于后面基于向量的相似性比对）
• 文本块对应文档页的图片信息
• 文本块在页图片中坐标信息

从整个PDF文档的处理过程来看，使用了大量的预训练小模型来处理诸如OCR, 布局识别，表格内容识别等功能，确实可以称之为**“DeepDoc”**。但这也造成整个PDF的解析过程比起其它同类的应用来说要慢上不上，对硬件也有一定的要求。不过通过一系列复杂的处理，确实的提高了文档中有效内容的识别率，

其它类型的解析器

其它类型的解析器主要是在general解析器的基础上在流程上做一些调整和删减，整体不太大，这里只简单举两个例子：

•Presentation解析器：仅执行图片转换和文本提取，每页单独切分为一个独立的文本块（文本块的token数不受限制），不进行表格解析和复杂合并。
•QA解析器：执行前四步解析，并通过正则表达式匹配问题和答案，生成完整的问答形式文本块（文本块的token数不受限制）

QUESTION_PATTERN=[r"第([零一二三四五六七八九十百0-9]+)问",r"第([零一二三四五六七八九十百0-9]+)条",r"[\(（]([零一二三四五六七八九十百]+)[\)）]",r"第([0-9]+)问",r"第([0-9]+)条",r"([0-9]{1,2})[\.、]",r"([零一二三四五六七八九十百]+)[、]",r"[\(（]([0-9]{1,2})[\)）]",r"QUESTION(ONE|TWO|THREE|FOUR|FIVE|SIX|SEVEN|EIGHT|NINE|TEN)",r"QUESTION(I+V?|VI*|XI|IX|X)",r"QUESTION([0-9]+)",]

LLM辅助增强

在完成原始的文本块解析过程之后，RagFlow还支持通过LLM对切片过程进行进一步的增强，提升后续的检索召回率。主要功能包括：

1. 自动关键词提取（auto_keywords）

利用LLM自动提取每个文本块的关键字（数量由topn配置决定），提取的关键字将更新文本块的important_kwd（原始关键词）和important_tks（分词后关键词）字段。

2. 自动问题生成（auto_questions）

利用LLM从文本块中自动提炼该文本块可能关联的问题（数量由topn配置决定），提取的问题会更新文本块的question_kwd（原始问题）和question_tks（分词后问题）字段。这几个新增的字段都会和文本块一起存入到ES中，在查询阶段执行混合检索时（关键字匹配+向量）时，其中关键字匹配会对文本块的不同字段赋予不同的匹配权重值（见下），从这里可以看出上述几个字段的意义，就是加强关键字检索阶段的精度。检索的具体过程以后再单独写一篇文章，这里就不展开了。

self.query_fields=["title_tks^10","title_sm_tks^5","important_kwd^30","important_tks^20","question_tks^20","content_ltks^2","content_sm_ltks",]

3. RAPTOR召回增强策略

开启该策略后，则完成原始文档解析之后，还会尝试对生成的文本块进行聚合提炼，逐层总结概要（会大大增加一个文档的文本块个数）。大致过程如下：

1. 对原始文本块集合基于向量相似性，进行聚类，聚合成不同的分组（使用GMM）。
2. 拼接分组内所有文本块的文本，使用LLM总结为为一段新的文本。
3. 重复聚类和总结，直到分组数量为1。
4. 返回原始文本块和所有通过总结得到的新的文本块。

此外还有知识图谱增强（GraphRAG）, 这个网络上有很多介绍了，这里就不展开了。应该说开启LLM文档解析增强后，解析效果确实会得到明显改善（特别是RAPTOR），但也会显著的增加文档解析的耗时（这个增加的可不是一点半点，如果文档比较大又比较多的话，解析过程会让你抓狂），而且如果对接的是外部的LLM，也会额外消耗大量的token成本。怎么选择就只有看具体的业务场景了。

总结

RagFlow在文档切片过程中提供了丰富的配置项供用户进行选择，几乎涵盖了目前RAG领域的各种最新的研究成果，特别是利用一系列的深度学习模型在文档解析时引入布局识别，表格结构解析等专有技术，有效提供了文档内容获取的质量，无愧于开源RAG领域的SOTA。不过也因为配置项太多，大家在使用时也需要根据文档的内容和形式仔细进行选择，盲目配置不但导致解析过程极其漫长，实际效果可能也并不会，希望本文能帮助大家更好的进行配置和使用。