第二节 数据处理的难点 - 解析和拆分原创

大家好，欢迎大家来到由腾讯云开发者社区、腾讯云项目数据库团队、安登团队共同打造的RG7天入门训练营系列课程的第二期。在第一期里面，我们讲到了rag整体应用的一个介绍，以及G整体开发框架中的一些细节。然后在第二节里面，我们会去讲rag构建的第一步，就是我们的数据处理的难点，需要提到我们的文件解析还有拆分。目前。刚刚我们第一节里面有提到long茜这个框架是目前大多数rag开应用开发者首先上来会选的第一个，呃，第一个框架去构建我们的rag应用。然后在。其余呢，我们还会谈到像index这样的一个框架，也是目前我们去做R应用开发的会使用到比较多的一个框架。然后再做R的应用的第一步就是需要去用到我们的框架，或者是第三方的一些库1还有一些第三方的工具去对我们的文件去做一些解析，还有拆分，去将我们的文件内容给提取出来，并将我们的文档内容去拆分成一个一个小的呛，然后在开源框架的long嵌还index这边呢，他们的优势你可以在他们的官网上可以看到，他们支持了多种文件类型，像常见的PDF worddown Jason ftml等等等等，然后都可以有很好的一些模块去把这些文件去进行内容的去提取。

然后同时也是因为呃廊前和拉index自带的这种解析器，然后会呃在我们R应用开发中去构建一个完整的RG应用，使用到这些解析，呃解析器会更加的方便。但是开源的解析器虽然能够提供这么多格式的文件支持，以及能够很好的与他们的框架去进行集合，但呃，下面我们也会去讲一下。如果去使用这种开源框架，会遇到啊哪些情况会导致这些框架对类似于PDF这样格式的文件解析起来其实效果是非常差的，然后导致我们解析出来的内容跟原始的文件内容差别很大。

首先可以看到，第一个在我们PDF这边，因为PDF格式其实呃，市面上的PDF有很多类型的，呃，排版，像我们这一张PPT里面介绍到的，可能会还会有一些类似于那种一二三级标题的标准格式，以及内容的那种双栏格式，以及像我们产品文档的跨页表格，还会有一些双栏的离散的文本块，以及像我们的小说格式，都是我们PDF这种文件中很经常出现的一些格式，使用开源的框架呢，它可能最多能够去做到，比如像我们的一些标准格式啊，还有论文的双栏格式，它能够去将。内容给提取的很好，但是面对这样复杂多变的一个文档格式，呃，首先第一步去将里面的内容给提取出来，就是一个十分困难的问题。可以看到这里面的问题主要集中在几个方面。就是第一个。

呃，文档的一个内容质量呢，其实就会很大影响到我们最终呃去构建知识库的一个效果，然后在整个去对文档去进行处理的过程中，会涉及到四类问题，第一个就是内容不完整，我们在去对文档的内容进行提取的时候，可能会呃发现提取出来的文档它的内容是会被截断的，像我们刚刚提到的那个跨页的形式，然后提取出来它的上下页，其实两部分的内容，然后就会被截断，然后也会导致我们说文档内的部分内容是丢失的，以及像我们去解析。呃，图片或者是说双栏啊，复杂的这种格式，它会有一部分内容丢失，然后第二部分呢，是我们的内容错误，内容错误这一部分呢，主要是集中在我们同一页的PDF文件里面，它可能会存在着像呃，文本表格，图片代码等等这种形式去混合，我们想要很好的去把这些格式内容给提取出来，也是非常呃需要非常大工作量的一个事项。还有一个内容错误呢，就是呃，PDF的解析过程中，其实有研究过的开发者应该知道，呃同业它不同的段落其实会也会有嗯不同标准的一些格式，然后我们会按照说一个比较通用的格式去进行一个提取解析，然后遇到了啊同业不同段落格式不标准的一个情况呢，也会导致我们的提取内容出错。

还有就是在文档格式，这目前我们的一个呃，支付文档啊，或者QA的文档等等这种文档，它都是以各种各样的文档格式去进行存储的，像常见的一些PDF markdown这种文件，也是我们目前遇到的用户比较多的一些存储类型的文件。然后我们需要去支持把这这些各类型的文档格式的文件都给内容其实都非常好。然后第4个问题呢，就是我们会在继续呃内容的时候遇到一些边界场景，比如说像刚刚我也提到了跨页，还有双栏PDF这种形式，以及更极端的一些场景，像我们的呃代码块，还有我们的单元格合并的一些问题，然后都这一些室内的问题，都是我们去呃去解析一个复杂文档格式中会遇到一些问题，然后目前我们调研下来，开源开源的像拉ex还有long这种框架开解析器，其实都不能很好的去进行解决处理。

然后在下面呢，我们也会去介绍一下，我们目前腾讯销量数据库其实已经上线了AI套件这一个能力，能够去帮助开发者快速的构建一个rag应用，然后在I套件里面呢，我们就去支持了多种格式文件的上传，我们这儿也是以一个PDF文档的一个呃文件为例。去给大家展示一下我们整个的一个呃内容提取的流程，大概是一个什么样子的，各位也可以看一下，然后最关键的一个解决步骤呢，可以从这一个呃倒数两行看起哦。在PDF的内容提取里面，我们不仅仅单单是做到了把里面的内容给提取出来，我们还会去把呃PF中我们识别到可能是一个标题这样的一个格式，可能是一个段落这样的格式给标记出来，然后在提取的时候会保留更多的格式信息。

然后同时我们还会有呃表格处理这样一个优化的流程，呃同时我们对于合并的单元格也能够去做非常好的一个处理，也可以看到呃，有使用过long框架的可以看到它。当前那个框架对于表格的处理提取出来之后，其实也是一个呃独立的文本，然后是不携带这种表格的一个信息的，然后我们这儿不仅能够将表格的一些呃格式给识别出来，同时我们对于这种单元格合并单元格格式的表格内容提取也是能够做到非常优秀的。然后还有一部分我们去做了一些增强，像我们的跨页跨栏，呃，像左右双栏这种我们提取出来之后，呃，左边这一栏按照我们阅读的一个顺序来说的话，左边这一列阅读之后，我们从右右边这一列的顶部开始阅读，然后我们提取出来的一个内容组织方式也是按照这样的逻辑去进行组织的。然后呃，这一块主要是去讲解我们目前腾讯上数据库AI套件对于PDF的解决一个流程，然后以及我们一些增强的手段，然后在下面呢，我也会去给大家演示一下对比浪茜，还有像我们腾讯相数据库AI套件的啊，同一个文档解析出来一个效果对比。

可以看到在呃解析效果对比里面，第一条呢，我们就用了一个比较经典的，我们这用了一个比较常规的PDF文件，然后它里面会携带一些标题啊，以及正文这样的一种格式，然后我们通过long嵌或者一些开源的解析工具去进进行解析的时候呢，可以看到这边呃，可能文字也比较小哦，我大概给大家介绍一下，然后右边这一栏呢，是我们通过一些开源的解析框架去解析出来的。呃截出来之后呢，它其实呃能够去做到把内容完整的提取出来，但是可以看到它呃实际上是缺失了一些格式的信息的，就我们在这儿腾讯相上数据库是什么这样一个标题的格式信息是丢失了的，然后可以在最下面看到我们通过相上数据库的AI套件去解析之后，在我们内部的一个解析效果的话，是可以呃判断出来我们现在腾讯向量数据库是什么这一句话，它是一个标题，我们通过这个NUMBER3，然后呃会带携带一个title，然后给它标识，目前我们腾讯相库数据库是什么，是被我们判断成了一个一级标题，然后同理的下面这一个关键概念也是被被我们判断成了一个一级标题，然后这样一个标题的格式就能够啊，在我们解析的阶段能够被提取出来。

然后再一个呢，也是我们刚刚提到的一个表格内容一个识别。表格内容识别啊，可以看到在右侧的开源框架呢，去进行解析呢，也是跟刚刚呃我们的标题那种格式是一样的，它将我们标题的格式去进行了一个丢失，只是将其中的内容文本给提取出来了啊在看到我们下面腾讯销售数据库的AI套件呢，其实我们不仅仅是将标题给提取出来了，同理我们下的表格也是以这种呃数组的一个形式，二维数组的一个形式给提取出来，可以看到我们在辖呃相似性计算方法以及方法说明，然后是被列为了一个表格里面，以及下面的内容部分也是会以表格的，也是会以表那个。

列表的形式去进行一个组织，然后能够很好的我们表格的内容去进行一个提取。然后呃还有会经常遇到一个问题，就是我们呃会遇到PDF中有跨页的一个主题内容，我们上一页可能呃跟下一页的内容是连在一起的，但是通过呃一些开源的解析工具呢，解析出来，它其实会被认为是一个跨的内容，可以看到右侧。在右侧我们上一页刚好提取出来了，呃，为什么是腾讯相关数据库之后这遇到了一个跨页，然后在下的这一个，呃，正文部分以及我们的。呃，抬头部分的内容会被识别到了下一页，就是第4页的一个内容里面去，然后就导致了我们呃内容被强行拆分成了两个部分。也可以看到在我们AI套里面呢，其实我们能够将这样的场景给处理的非常好，可以看到在下面我们是会去将这种快的内容去做一个，呃，合并也看到我们在这儿不仅是提出来了标题，然后在这，呃，为什么是腾讯销售数据库下面紧接着对腾讯云销售数据库的一些介绍，然后也会被我们合并成为一个文本段，然后给提取出来。

然后这个也是我们目前做的比较好的一个地方。还有第4个是跟刚刚的单元格是类似的，呃在单元格里面呢，我们难免会涉及到有一些表格会有呃单元格合并的情况的出现，然后开源的解析框架呢，还是呃按照只提取它的文本内容，然后不去对它做格式解析，然后就导致呃这提取出来它的表格内容基本上都是乱的，然后也没有表格的格式，然后这里会有一些。内容层面的丢失。因为这个可用区是对于呃这一个左侧表格的所有地域来说都适用的，然后可以看到右侧提取出来之后呢，这一个呃可用区的描述，然后就只能够被带到啊这个表格的最后一行。

然后再对比我们现在向量数据库AI套件里面解析出来内容呢，我们是能够去做这样一个呃单元格内容的，呃合并解析可以看到我们能够去检查到说我们这一个呃可用区，它是由三个单元格去进行合并了的，然后我们在做内容提取的时候，会把这个呃合并的单元格给拆分开来，然后。将对应的每一条数据都去补上这一个可用区的一个信息，然后会让我们在对于表格内容的提取，或者是对于我们最终送入单元模型，单元模型对这一个数据结构理解上会更全面一些。然后整体呢，这个就是我们呃在对PDF文件去进行解析中做了一些增强的手段，然后呃也是我们在最后能够去将整体的召回率做到比较高的一个呃解决方案。然后呃，其实这一节课的主要内容呢，也是去讲，我们在这儿为什么要去做一些呃知识片段的拆分。

在呃做这片段的拆分呢，主要绝大部分的一个原因还是因为我们现在的emding呃的模型是有限制的，像我们目前腾讯像数据库采用的一些啊BGE模型，以及15~2级这种模型啊，它都已输入token的一个限制，其实都是要求小于512TOKEN的，然后超过这个token限制的内容呢，它会直接被模型给丢弃的，所以说呃在这我们需要去将很长一篇上成百上千的文档给拆分成啊一个一个小的片段，然后对于每一个片段呢，然后我们再去做向量化。才能够去很好的将这一部分的呃内容语义信息给用向量的方式去保存起来，然后存储到我们向量数据库中去。然后第二个就是我们的一个效果影响，呃，因为目前我们的呃模型能够做到的最大维度，其实希望open I的呃A002那个模型，它是只能够做到1536维度，然后其实在一个有限的维度下去容纳呃较多文档信息，会产生一个失真效果，就你想象一下一篇呃几十万或者上百万的一篇呃文字的文档，然后你要用只用呃1536尾这样一个向量维度去进行存储的话，其实它会丢掉很多。

里面一些细节的语音信息，然后会影响整体的一个效果。然后第二个呢，就是呃回答的效果呢，也会去呃有一部分的降低，呃我们刚刚举了一个例子，就是我用成百上千的一些呃字符的内容去做向量化，然后在我召回回来的内容里面，其实我需要。很小的一个片段，然后但是那条数据把所有的文本都返回给我了，然后导致我丢给大圆模型的时候，大圆模型无法判断出来哪一部分知识是我需要的，所以说它也会那些无关的一些信息也会对大圆模型去产生干扰，所以说我们在这儿去进行拆分之后，拆成每一个一个小的片段，一个小的知识点，然后再召回，回来的时候只去召回呃，跟我们用户提供相关的一些片段，然后再交给大元模型，然后我们大元模型能够获得一个比较好的处理效果。

第三个部分呢，就是我们出于成本控制，因为我们大元模型其实是呃按照token去进行计费的，然后这个token的的一个概念转换，也是由我们的字符数去进行一个转换的，我们输入的一个字符数越多，对应着我们的ton数也会越多，像我们刚刚如果招回回来一条知识内容有呃上万个文字的话，那我们交给大语言模型的时候，那的投费用也会很高。然后第二个就是我们在网络传输这一个开销会很大，你想象一下，我们现在从相数据库里面呃查询出来一条。文本内容，然后其中有一个字段带了这么长的，这么是这么长的一个字符串，然后在我们的网络传输过程中，也会去有非常大的一个网络开销，然后在成本这一方面也是不可控的。所以综合来看呢，无论是从呃目前模型的一个限制，还是对于我们效果的影响来说，我们都需要去把一篇啊大的文档给拆分成一个一个小的呛，然后对于每一个小的呛去再做向量化，存入到我们向量数据库中，是一种比较好的处理方式。

在接下来呃，我们聊到了拆分，呃做R应用避不开会对我们常文本去做呃拆分，然后拆分之后呢。其实其中有一个很重要的概念，就是我们创可拆分的一个效果对最终结果的一个影响，这我们也去列举列举了一下我们创客拆分的一些呃逻辑，然后会对最终效果产生什么样的影响，在这我们可以看到呃拆分创口的时候，我们目前呃市面上常见的都是按照固定的字符数去进行拆分的，比如说我可能会去设置一个300字符数或者400字符数，然后这样去将一个枪口给拆分开。呃，这样设置的一个原因呢，主要是呃，白模型其实它对于目前的。文本长度是有一定的偏好的，像我们测试下来的BT模型，它对于那种短小的文，很短小很短小的文本啊，它的一个相似度会非常的高，会导致呃，我召回的结果里面TOP1或者TOP3的内容很多都是呃，无关信息的一些短文本。

然后太短的话就会导致，呃，我们这一个。TOP3的内容不是我们想要的，但是拆分的呛合太长了呢，也会导致我们的信息压缩失真，比如说我现在呃有一有一个知识文档，可能100字就能够描述的非常详尽的，然后我现在给它拆成了可能500个字符，然后它会将一些其他干扰信息也糅合进来，然后最终去做向量化，然后就会导致呃这一。这个很简短的文本，里面的一些关键信息被其他的干扰信息给冲淡了，然后会导致这里的信息会有一些丢失。还有呃，第三个我们可拆分的一个影响就是我们是不是会涉及到跨主题的一个拆分，这里跨主题呢？比如说呃，我现在有一篇markdown文档，然后呃我在拆分的时候，我原始的文本里面是有一级标题，二级标题这样的格式的，然后我在拆的时候可能会涉及到我把呃二级标题下面的一些文本给拆分出来了，然后拆分到了一级标题的下面去，然后就相当于。

一级标题里面有一部分正文的内容，和我二级标题下面有部分正文的内容给合并起来了，会导致呃整体的这一个内容脱节的，因为它本身讲的是呃，可能是毫无相关的两个概念。还有第三个就是呃拆分呢，也会涉及到一个比较大的问题，就是我们原文的一个内容会被截断，原始的一篇呃一段正文可能是都是去描述同一个问题的，然后现在我将呃那那一篇比较完整的文本给拆分开了之后呢，就会导致它上下文的一个丢失。单个窗口，它表达的一个信息就不是那么的完整，它上下文可能会有一些限制，然后下面会提到一些约束或者一些注意事项，然后这些含义都会被丢失掉。还有创口拆分也会引入一些干扰信息，在我拆分的时候，对于类似于markdown这种文档里面可能会有一些呃，HTML啊，或者一些链接这样的格式信息，然后在同等长度下，因为呃，按照如果按照字符数来拆分的话，这种格式也会被算作字符数。

就会导致我们呃引入了这一些符号的干扰信息会第一，第一个是会影响到我们创客本身所含的呃内容长本内容长度的大小，就可能我一个链接就占了，比如说50个字符，然后对应着我呃拆分的时候，我正文信息会相应的去减少。还有第二个就是呃这种信息，其实对于in be模型来讲，是因为in be模型最终呃是提取的文本的语义信息，然后这一类的符号类型等格式类型的信息呢，对应be模型来讲，它其实是呃不能够识别出来呃具体的含义的，所以说这一部分也会增加一些干扰信息。然后呃，最下面这一个主题和关系的一个丢失呢，就类似于我们用浪那套框架，我们去进行了一个内容提取，提取出来之后。

我的标题没有被识别出来，呃，这是会带来一个影响，然后即使我的标题被识别出来之后，我去做拆分的时候也会导致，呃，同一个正文内容下面的文本不会携带上标题的一个信息，然后导致我的主，我的这一段文本丢失的主题，会影响到我后面将这一个知识内容召回回来之后丢给大语言模型的一个处理效果，然后整体这的6个问题呢，就是我们创客拆分对于最终召回结果的一个影响，甚至影响到我们最终单元模型回答的一个效果。然后为了去呃保障我们说这呃相应数据库的AI套件能够去把口给拆分的合理，以及去解决我们呃提到的这6个问题，我们也去提出了。改进的一个知识拆分方案。在左侧呢，可以看到我们这是呃，处理正确的，还清洗好的一些支付文档，然后做了一些处理之后，我们在中间，中间这一块可以看成是我们的一个呃，向数据库的AI套件一个介绍，呃。

当我们会去将。每一篇文档都拆成一个树状的结构，我们会按照一级标题二级标题这样逐级的往下去进行拆分，然后拆分到呃正文的部分，然后每一个最底下的叶子节点都是我们的正文内容，然后在正文内容这我们会按照内部的一定呃设置的一个切分逻辑，就第一步我们会保证。呃，我们拆分的内容是不会去按照呃从中间段这个逻辑性拆分的，我们一句话就是会保留这一句话的完整性。然后去拆分成每个呛口，然后再对于呃呛口长度不足，比如说我上一个呛壳可能只有100个字符，然后拆到下一个呛口呃也只有100个字符的时候，会选择去将两个创口进行合并，合并成一个大的创口，最终从由下面的叶子节点呃将创口的信息组织好，同时将每一个创口所处的主题的呃信息给组织好，然后形成这一篇啊数形的结构，然后将这一篇文档拆分成这样的结构之后呢，我们会对每一个嵌再去做向量化，然后转呃转成向量数据，转向数据之后存储到我们向量数据库中去，然后在向量数据库中的AI套件会去维护一些。

原数据信息，然后在最终我们去进行召回的时候，比如说呃，我的呃用户的提问目前匹配到了这一个某一个呛，然后我会连带的把这一个创客所属的上下文的创客也一并的返回回去，去补足，补足这一个上下文信息，然后能够保证呃现在从像数据库，也就是我们知识库中召回回来的内容是相对比较完整的。呃，刚刚也其实也提到了很多我们腾讯相上数据库相关内容，也是我们在呃整个课程里面后半部分也会去给大家去进行介绍，也会有一些实战方面的经验去教导大家去使用我们项目数据库的AI套件哦，完成我们知库的快速入库，使用到我们的解析优化以及内容增强，还有我们后面提到的一些工程性的travel优化，还有inbing的优化，去快速的搭建我们的一个呃知识检索，还有问答的服务。

然后在这一节课呢，就主要讲解的就是在R应用中我们的解析，还有拆分的部分，然后下一节课呢，会讲解我们对于呃长篇的文档去有内容提取，以及拆分成每一个小的创之后对于小每一个小的创可去做向量化所涉及到的一些知识内容。谢谢大家。