微信扫码
与创始人交个朋友
我要投稿
大家下午好,
我叫肖玉民,来自杭州萌嘉网络科技有限公司,很荣幸受主办方的邀请,来参加此次GOTC2024的分享。
我们是一家刚成立不久的初创公司,目前主要聚焦在大模型、向量检索、RAG这一块的产品应用研发,我们的产品品牌是TorchV。
今天也是借着这个机会,结合我们自己做RAG产品迭代开发过程中的一些实践,分享我们在非结构化数据解析以及企业应用场景的一些探索和思考。
OK,今天我分享的主题主要围绕三个方面
OK,那么说到非结构化数据,自从RAG+大模型的技术栈爆火之后,我们看到了大模型在处理文本上的能力,为之惊讶。
在我们的实际应用场景中,可能80%的工作场景,都是在和非结构化打交道,这其中包含场景的Office办公软件套,还有图片、音频等等各种各样的结构数据。正是因为有了大模型的能力,让非结构化数据的内容,在整个内容检索、理解、利用等方面得以充分得发挥。提供人们的工作效率。
我们以RAG为基础的技术栈进行技术开发时,开发人员碰到的第一个难题也是以非结构化的数据解析为起点,我们需要将各种各样的格式的数据解析成文本,然后在通过检索、写Prompt的方式,让大模型进行推理生成,完成上游的应用部分的交互,解决人们在工作中碰到的各种企业问题。这里面我们碰到的问题:
在实际的开发场景中,可能还有很多的细节,需要开发人员去处理。
在碰到上面这些问题时,一开始我其实也有点不知所措,就拿PDF的格式来说,其1.7的规范就将近800页,如果要全部看完并提取解析成功。那可能是天方夜谭了。
我们可能和其他的开源的产品或者同类的产品不太一样的是,在TorchV的整个技术架构体系中,Java占的比重有将近80%,当然这里面包含文件的解析内容提取。
在Java生态中,针对上面的一些文件解析的问题,在目前整个Java生态里面,有三个中间件是很很好的在做RAG场景中,发挥重要作用的。Apache三件套。
在整个的非结构化数据提取过程中,上面这三个Apache项目,基本能解决我们80%的业务场景的问题,我知道目前大家对于大模型来提取识别文件觉得是非常酷的一件事件,但是在企业场景落地的时候,文件解析我们也是需要从成本、性能、效率等多方面去考虑。
有时候基于规则的提取,在可解释性上还是有较大的优势的。
我们基于上面三个中间件,其提供的文件格式大家也可以看到从Html、Office、PDf、图片、音频、压缩包等等,在企业应用场景中,绝对够用。
在整个文件解析中,PDF应该是最令开发者头疼的一个文件格式,尤以表格提取最麻烦。
在PDF的表格提取中,借助于Apache PDFBOX,目前有两种有效方法,是可以非常高效的提取表格内容,还原表格信息。
第一种是Tabula组件,开源的算法,主要基于PDFBox提供的文本坐标提取方式,通过将所有的文本坐标提取后,通过计算边界、文字边界连接等方式,可以通过坐标算法,基于水平和垂直两个方向的坐标系来明确单元格的边界,将整个表格还原提取出来。
这种方式在针对一些老的电子文件PDF是非常奏效的,因为在之前的PDF标准规范中,对于表格中的线、矩阵等信息并没有纳入规范中。而在目前的PDF规范中,PDF对于电子文件的内容流中,大部分场景都存储了表格中的线、矩阵坐标信息。
基于这个方式,我们可以使用PDFBOX中的第二个方式来还原提取PDF的表格信息,这主要是通过提取PDF内容流的线坐标、矩阵信息。
可以通过将所有的矩形、线的坐标信息,通过算法进行处理,这里面包括空间去重、冗余排除、矩阵坐标连接等方式,那么就可以做到图中的这样,将一个表格信息完整的画出来,我们通过矩阵坐标确定表格后,基于表格的单元格坐标,即可以进一步的确定当前表格他的单元格合并情况,明确每一个单元格是否需要纵向、横向的合并。最后确定这些信息后,通过PDFBOX按区域提取的方式,就可以精准的提取每一个单元的内容信息,将表格幂等的还原回来。
另外基于坐标的信息,其实要扩展做的内容也蛮多,在后面的案例我会讲到。
基于上面表格的提取方式,在PDFBox中,他的整个UML架构图就如图中所示:
最顶部是PDF基础的引擎类,在PDF的规范中,包含了非常多的Operator操作,下面的基于坐标、图片等信息的提取,都是基于PDF规范中的Operator来扩展提取。包括第二个图引擎的类,实现提取内容流中的线、矩阵、图片等信息的提取
最后按文本坐标区域提取的核心类,是一个非常实用的方法,在PDFBox中,特别是对于当前论文类型的PDF,双排的这种方式,通过大量的实验,其实提取计算文本的排版空间,都是比较轻松的一种方式。
第一个场景是知识库,这也是基本在大模型兴起后,最常见/可落地的一个领域,今天因为大模型超强的文本理解能力,我们通过各种手段将非结构化数据进行文本提取解析后,结合向量KNN等新一代的搜索技术,可以更加准确的搜索积累在数据库中的文本内容。
配合大模型作为润滑剂,将整个用户的问题进行理解,最后输出符合用户问题的答案。
我们在和我们的客户深入沟通交流的过程中,知识库就像AI时代的数据中台一样,做好知识库能给很多企业充分将AI的能力利用起来。
这里面包括:
这个是我们认为当前AI在企业场景里面非常重要的一个落地场景。
第二个场景应用我们叫研报助手Assistant.
他其实是一个富文本编辑器,大模型在今天其实已经非常擅长文本的生成了,对于知识的输出,效率相较以前数倍的能力提升。
但我们在企业的场景落地的过程中,大模型在一些严谨的场合下,输出的内容可能并不符合我们的要求,会产生幻觉,这也是RAG在当前最理想的一种技术手段,控制大模型的幻觉输出问题,让大模型基于给定的文本内容,进行总结输出。
Assistant主要是结合了非结构化的文本解析+向量检索+大模型归纳+富文本编辑器多种技术与一体的这么一个产品。通过用户上传的文档内进行检索生成,对于在一些需要引用严谨的报告输出,包括对大量文档的阅读,利用这个工具,可以高效的提升整个编写流程的体验。
在已经生成的文本内容,Assistant还加入了一些转换图表的能力,选中一些文本信息,可以快速的转换成饼图、柱状图、表格等不同的图表形式。
第三个是规则匹配的场景Cmparision
在这个场景中,我们主要还是依靠之前在处理PDF表格时提供的一些方法,可以无差别的根据区域信息,提取关键的字段信息。当然如果我们整个的处理场景中,会有一个处理的 顺序,如果PDF内容是扫描版本的话,那会通过OCR的方式,进行区域信息的提取,结合之前坐标空间的相关算法,将框定的内容给提取出来。
另外一个就是在非结构化的数据提取后,可以配合大模型的的Agent能力,针对特定的领域,基于规则提取文本中的关键信息。
提取关键信息后,那么我们在应用上层要处理时,不管是数据的校对、或者总结,在企业场景中,AI能高效的发挥作用,提供整体的工作效率。
最后想和大家分享一下我的一些个人感想。
第一个就是:AI技术栈很杂,是挑战,也是机遇
在我们讲RAG、大模型、向量检索整体的技术栈进行落地时,这里面涉及到的技术栈其实是非常广,而且很杂,开发人员不仅仅要关注到数据的处理,这里面还包含检索、向量数据库、大模型Agent、Prompt、微调等等技术领域,对于打造一个标品其实并不容易。这对于企业和开发者来说,都有不小的挑战。但是正是有了AI大模型,我们在今天的工作场景中,很多有趣的应用和产品层出不穷,这里面其实也蕴藏了大量的机遇,同时在AI的加持下,对于开发者而言可以更加大胆的畅想了,这对于探索、创新,创造更多有趣的产品是大有裨益的。
第二个则是:数据质量是基石,重剑无锋
数据质量我觉得是在做文本类AI应用的基石,不管是做RAG,还是微调模型,我们在构建开发TorchV的过程中,可能大概80%的时间都是花在怎么把数据处理好,幂等的将非结构化的数据最大程度的进行提取和还原,这是很关键的一步,RAG更是有Garbage in,Garbage out的经典名言,所以,数据的质量,应该是我们需要着重关注的。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-11-25
糟糕!LLM输出半截Json的答案,还有救吗!
2024-11-24
解读GraphRAG
2024-11-24
RAGChecker:显著超越RAGAS,一个精细化评估和诊断 RAG 系统的创新框架
2024-11-23
FastRAG半结构化RAG实现思路及OpenAI O1-long COT蒸馏路线思考
2024-11-23
检索增强生成(RAG):解密AI如何融合记忆与搜索
2024-11-23
如何提高RAG系统准确率?12大常见痛点及巧妙解!
2024-11-23
RAG 2.0性能提升:优化索引与召回机制的策略与实践
2024-11-22
RAG技术在实际应用中的挑战与解决方案
2024-07-18
2024-05-05
2024-07-09
2024-05-19
2024-07-09
2024-06-20
2024-07-07
2024-07-07
2024-07-08
2024-07-09
2024-11-06
2024-11-06
2024-11-05
2024-11-04
2024-10-27
2024-10-25
2024-10-21
2024-10-21