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"
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会将其封装为一个异步任务到后台进行处理deepdoc/parser。classParserType(StrEnum)
我们这里以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最终解析完成后生成并插入到ES中的文本块（chunk），主要包含五部分的信息：
从整个PDF文档的处理过程来看，使用了大量的预训练小模型来处理诸如OCR, 布局识别，表格内容识别等功能，确实可以称之为**“DeepDoc”**。但这也造成整个PDF的解析过程比起其它同类的应用来说要慢上不上，对硬件也有一定的要求。不过通过一系列复杂的处理，确实的提高了文档中有效内容的识别率，
其它类型的解析器主要是在general解析器的基础上在流程上做一些调整和删减，整体不太大，这里只简单举两个例子：
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]+)",]在完成原始的文本块解析过程之后，RagFlow还支持通过LLM对切片过程进行进一步的增强，提升后续的检索召回率。主要功能包括：
利用LLM自动提取每个文本块的关键字（数量由topn配置决定），提取的关键字将更新文本块的important_kwd（原始关键词）和important_tks（分词后关键词）字段。
利用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",]
开启该策略后，则完成原始文档解析之后，还会尝试对生成的文本块进行聚合提炼，逐层总结概要（会大大增加一个文档的文本块个数）。大致过程如下：
此外还有知识图谱增强（GraphRAG）, 这个网络上有很多介绍了，这里就不展开了。应该说开启LLM文档解析增强后，解析效果确实会得到明显改善（特别是RAPTOR），但也会显著的增加文档解析的耗时（这个增加的可不是一点半点，如果文档比较大又比较多的话，解析过程会让你抓狂），而且如果对接的是外部的LLM，也会额外消耗大量的token成本。怎么选择就只有看具体的业务场景了。
RagFlow在文档切片过程中提供了丰富的配置项供用户进行选择，几乎涵盖了目前RAG领域的各种最新的研究成果，特别是利用一系列的深度学习模型在文档解析时引入布局识别，表格结构解析等专有技术，有效提供了文档内容获取的质量，无愧于开源RAG领域的SOTA。不过也因为配置项太多，大家在使用时也需要根据文档的内容和形式仔细进行选择，盲目配置不但导致解析过程极其漫长，实际效果可能也并不会，希望本文能帮助大家更好的进行配置和使用。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |