0629讲稿
以下是我在2024年6月29日上午在北京富力万丽酒店举行的稀土掘金开发者大会RAG专场的分享内容，包括文字稿，一并分享给大家！
朋友们，上午好！
我叫卢向东，来自杭州，今天为大家分享的是我们在大模型应用的企业落地时碰到的一些关于RAG的难点和创新。
可能很多朋友认识我是因为公众号“土猛的员外”，从去年6、7月份开始持续分享了关于RAG和大模型的一些文章和观点。现正在和几个伙伴一起创业，担任杭州萌嘉网络科技（也就是TorchV）的CEO。
今天在这里想和大家分享的主要内容，是关于我们在大模型应用的企业落地场景中遇到的一些问题，以及一些落地的产品案例。我一共会分享四个难点，三个应用案例，然后把一些个人对这一领域的思考放在最后面。希望能从不同视角给大家带来一些大模型应用在企业落地实践中的内容。
OK，那现在我们就进入第一Part，来讲讲我们在实践中遇到的问题。
第一个问题，是文件解析，或者说是知识解析。目前整个RAG流程中，第一步往往都是从文件解析开始的，如果咱们把文件上传上去，结果系统都无法识别，那后面也就没有RAG什么事情了。所以我们在具体的客户落地实施过程中，首先遇到的就是各类复杂文件的解析，企业里面的各类文件的类型是很广的，甚至有些都是我第一次听说的类型，比如“.vnp”。当然，最常见的问题主要出现在老文件上，比如“.doc”的解析上，以及各类有数字签名、带图片的pdf解析上。我们发现市面上很多同类产品是不支持“.doc”这样的老文件的，一般都只支持到“.docx”，但是你在企业应用中会发现，这太常见了，而且很多toG场景也是一样的，“.doc”很多。而且大部分情况下，你要是手工转成“.docx”依然是无效的，所以要真正去做企业的大模型应用，这些都是必须具备的能力。另外就是PDF的各种问题，PDF应该是我们碰到最常见的文件类型了，原来觉得PDF是最省心的，但是接触的实际场景越来越多之后，你会发现没见过的情况太多了，包括PDF的扫描件、布局问题，还有一些数字签名怎么绕过去，都是问题。这些都需要一一想办法去解决，包括用OCR去识别，有时候需要解读PDF的文件流，从根源上去获取它的数据结构和数据内容。关于PDF我还会在下一页讲一下表格处理。当然，文件解析的问题还有很多，包括在图文格式下如何处理，在检测到哪些情况的时候去启动OCR等等，我不一一展开讲了。还有就是布局识别，这是一个很难的事情，和OCR不同。OCR基本上就是去识别文字，有一些简单的布局识别，但是不够。真正的布局识别更多的是要知道内容在什么位置，这个位置代表的意义是什么。比如一张飞机票，1510，1540，代表的是登机时间/起飞时间？还是什么，我们是需要去根据布局上的点线和多边形来判断的。在这一块目前有一些多模态的模型可以做到60%-70%的布局识别能力，但是真正要用到企业应用中，要做到90分的效果，那还需要再等等基础模型的发展。
说到这里呢，就顺便讲一下在PDF表格解析中的一些问题。这是我们自己开发的一个比较强大的PDF解析工具，基于Apache PDFBox进行开发，用的是Java语言。对，我们TorchV的主程序就是使用Java开发的，可能是比较另类的。使用Java生态，在企业级应用里面有太多可以使用的开源组件，而且其稳定高效的特点早就被证明。我们的这个PDF表格解析工具，没有使用到GPU的能力，但是解析速度非常快，而且准确率极高。我们也接受了各类试用客户的挑战，包括各类复杂表格，准确率统计下来在95%以上。为了做到这个效果，我们重写了PDF内容流解析的实现类，对RowSpan/ColSpan识别做了特殊处理，来解决合并单元格的问题。另外做了区域识别，以及内容的结构化还原，可以还原成HTML或着Markdown，这样就非常利于大模型进一步处理。这项技术的突破，除了让我们在处理企业文件的表格更加得心应手之外，还可以进行反向操作，就是将大量知识填入到表格中，完成一些不那么机械的表格填写。目前我们也提供了一个测试的链接（点击左下角的“查看原文”），大家可以在我们的官网（torchv.com）的文档中心里面找到这个PDF表格解析试用链接。
下面来说说第二个问题，结构化数据如何融合到RAG中。我们目前碰到的客户中，只使用非结构化数据就能完成整个业务流程的很少，基本上都需要去对接他们原有的关系型数据库，再不济也是已经整理过的excel文件。结构化数据，顾名思义，结构比较固定，相对来说，它们被使用的时候，比如我们通过商品id去展示某个商品，那么它的展现肯定是幂等的，也就是每次都一样。所以在RAG中要把结构化数据融合进来，我们的一个总体思路是不去破坏结构化数据原本的结构清晰度。我们最早是把所有数据抽出来，直接embedding的，但是在检索和使用的时候经常出现效果不佳的情况，比如丢数据，而且有些时序数据，你根本没办法去处理；我们后面也做了Text2SQL的尝试，在一些简单场景下都是没问题的，而且我自己觉得这应该是未来的方向。但就目前来说，一旦处于复杂逻辑中就出不了好的结果，或者很不稳定。所以我们后面逐渐采用了一种中间方案。就是先将数据库的元数据抽出来，包括字段信息和表、视图的描述，人工补充一些必要的资源描述，再进行embedding。然后在建立一些可重复使用的通用data-func，还有一些特殊的data-func，也就是类似以前mybatis和hibernate这样的模板，可以把复杂SQL逻辑写进去。在整个使用过程中，function-call起到了处理和转发的作用，在和LLM一起理解了用户意图之后，寻找相应的元数据和data-func，进行一个或多个步骤的执行SQL组装，进行查询执行。目前我们在使用的过程中发现，虽然在data-func的创建中会有一点工作量，但是执行效果比较稳定，毕竟对于企业用户来说，稳定可控可能是最重要的。
第三个问题可能是个常规但不能忽视的问题，那就是检索能力如何提高。我们在给客户POC的时候，客户往往处于一种测试的心理状态，这种状态带来的直接影响是什么呢，就是这会儿的硬件环境其实都不太好，很多情况下只能部署6B、13B和14B这样的模型。这时候检索能力就显得尤为重要，检索能力越强，送进大模型去处理的内容就会越纯净。这个时候处理好元数据就非常重要了，这里指的元数据是从文件的标题、目录、属性等内容中获取的，包括文件名、年份月份等时间信息、组织和部门，以及财务、人事、销售、财务报表等关键标签。这些元数据会在文件处理的时候被自动抽出来进行管理，和chunks和索引做一对多的关联。这么做的好处是，在用户进行检索的时候，我们会首先使用一个规模比较小的基于BERT训练的幂等分类器（也就是图上的IC）进行NER，然后使用识别的内容现在元数据里面进行查询，将索引范围进行限定，后面就是混合检索和rerank等操作。这样做的好处是可以将一些很相似的内容区分开，比如真实客户环境下，很多文件只有日期、部门和金额等内容是不同的，如果直接做检索，很可能因为切片时候错过这些关键信息而混杂在一起。
第四点是想分享一下rerank模型的一些其他应用方式。对于rerank，大家应该常用的方式就是将第一次检索的结果进行更准确的验证，通过交叉编码验证让召回的结果再进行排序，达到更精确的回答。我们在实际使用中也是有一些创新，比如在rerank的结果中，我们会使用密度函数再做一个验证，如果像图上的第四个结果，在得分上突然掉下来了，那么我们就会进行舍弃，这样做的好处是在结果的选择策略上做到宁缺毋滥。
当然rerank还被我们用到了原文显示上，在我们的问答板块，对于问答结果的原文引用我们是默认展示的。但是一般一个答案都会有多个原文，显示在第一个的并不一定是最正确的，这是因为大模型在最后的处理的时候有自己的判断。那么如何显示最精确的原文呢？这里我们就是用答案和多个引用的原文再进行比较，找到最精确的原文来进行展示。
另外我们还在尝试将rerank用在自动标注上，比如用户在翻阅问答记录的时候，看到某些问答可能是蕴含商机的，下次有类似提问的时候需要立即流转到特别环节，比如转到销售代表那边。在以往的打标操作中，我们需要先进行语义理解，进行扩展词的编写和关联等，过程还是比较复杂的。但是现在你只需将这个问题进行标注分类，比如选择“商机”标签。rerank会对后续的提问进行比对，如果和已经被我们标注的提问相近，比如score是大于0.8的，那么也会触发这个流转的动作。
好了，以上是今天要分享的四个企业实际落地场景中的问题，分别是文件解析、结构化数据融合、索引中的元数据处理，以及rerank的多种用途。
接下来我再分享三个在企业落地应用方面的创新，现在应用方面的创新应该是非常多的，所以对于应用我们
第一个是在金融研报中的应用。
其实我们做的事情很简单，就是把几百份针对一个公司的各类公开和私有资料扔进我们的TorchV Assistant，然后对它们进行提问，比如三年复合增长率是多少？比如近三年合同的履约情况怎么样？再比如近三年的人员流动情况等。对得到的答案与一起出来的原文进行比较，确认答案正确之后，就可以将其拉到左边的编辑器中，完成一个问题的编写。这与之前最大的改进就是大量节省了阅读理解几百份文件的时间，而且在内容关联性查找方面，也会比人更加稳定和出色。我们一个朋友在使用之后给的反馈是，原来需要两三周完成的事情，现在最快三小时就可以完成。
当然，TorchV Assistant还可以用于报表的快速生成，可以根据用户的语言表达从已有数据中生成相应的数据分析图表和报表。这也就是我们还在研发的另外一个产品妙语分析师。
第二个是在零售业务中的应用，叫TorchV Doraemon，让客户拥有自己的哆啦A梦，你想要什么产品，直接告诉它，它就能帮你找出来，这种特点在零售场景中还是比较有用的。
这个产品我们的第一个客户是一个国外的医美超市，当然也是华人开的。他们最大的问题是面对3万多个SKUs，导购员往往无法找到合适的产品给顾客。比如一个法国的女性对导购员说“我今年45岁，想要改善一下我的鱼尾纹，之前我用了A、B、C产品了，没什么效果，然后我对肉毒素有些过敏，怎么样的产品比较好？”对于这样的问题，TorchV Doraemon可以根据用户的产品数据库和产品说明书进行快速产品筛查，找出最适合的产品。
还有一个案例就是在酒店装修的前期确认环节。在酒店装修设计行业，最复杂的就是整体装修设计的确认，往往是一个设计方案拿过去，客户总会指出这里要换那里不行。然后你就抱着反馈回去再设计三套方案，两周之后再拿过来确认，客户说上次我不是这么说的吧？而我们现在一个POC方案是使用Pad进行界面化操作，比如图中这个设计效果图，我们要把这个绿色椅子换掉，只需要点击椅子，在弹出窗选择“智能选型”，即可获得系统推荐的最合适的几款替代产品。其实整个流程也是很简单的，它的底层依然是一个RAG问答系统。如果简单地说，其输入的内容是什么呢，这是A设计师的设计风格，整体要提现一种简约的美式风格….现在有xxxx书柜（可以带入它的介绍说明书），还有XXXX实木书桌，还有XXXX地毯，现在要替换XXX椅子，帮我从现有产品库里面寻找最合适当前装修搭配的椅子。这个应用场景的好处是提升装修设计的现场确认率。
第三个是TorchV Comparison，也就是规则预审方面的应用，主要的应用场景有合同预审和项目审批。
我们使用该规则预审产品，帮助某家世界500强中前150名的客户开发了合同预审应用。在这个案例中，客户的四名法务每年大概需要处理3万份合同，而在整个处理过程中，最复杂的是各种接收、审查和打回等反复的操作。在今年三月份他们开始启用合同预审应用之后，一期已经开放了22个预审规则，包括在不同语境中的歧义字检查，必填项缺失检查，甲乙双方权利和责任比对，合同金额与交易物价值预警，以及合法合规检查等。有了这个应用之后，很多业务部门提交上来的合同会先经过一道AI的检查，只有AI这一道关先过了之后，才会到真正的法务手上，这就大大缩短了整个合同审核的流程。
另外一个应用场景和合同预审其实差不多，就是项目审批，不一样的是项目审批中待检文件更多，需要的算力和处理流程也更复杂。
好了，这就是我分享的三个应用案例，用在金融领域的AI研报制作、用在零售的导购助手，以及用在规则预审的合同助手。
最后我想分享一点大模型应用在企业落地实战中自己的一些感受。
第一个感受是如果要做好AI应用的企业场景落地，需要往三个特点去靠。第一个是特点是功能小，我们可以找到一个清晰的量化指标，比如前面说的装修设计确认周期降到原来的40%，非常清晰。第二个特点是质量高，企业客户往往会给我们提出很多需求，但是这些需求是需要去审视的，有些需求在现有能力下，没办法做到80分或者90分，只能做到60分，那就会影响整体的使用体验，进而影响客户的付款意愿，所以要和客户沟通确认，先做80分、90分的事情。第三点是价值大，虽然我们可以将功能做小，质量做高，但是更重要的还是要去了解客户为什么要去做这个事情。尽量找到那些做完就能给客户的业务带来极大提升的功能，优先去完成这些功能。在大模型应用的企业落地中，我们可以尽量往这三点去靠，那整体的成功率会更高。嗯，功能小、质量高、价值大。
第二个感受是在AI大模型的企业落地中，需要的能力还是比较多的，比做产品要累。如果说做产品是把一横做好的话，那么去做企业落地服务就是一竖。从最初的需求交流与方案确认，再到POC计划，到部署实施，再到后面的培训和陪跑。所以做企业AI应用落地服务并不性感，是很苦逼的活儿，但是优势是，你可以在那些有付费能力和意愿的客户那里获得真实需求，以及培养自己的服务能力。
也就像我最后一个感受中想说的，技术优势是动态的，这个行业里面谁都在拼命往前跑，一刻不敢停歇。就算OpenAI躺半年，也会被对手远远超过。所以对于大多数公司来说，技术优势是动态的，不会一直是优势，去沉淀应用场景，找到客户价值，才是大模型应用企业服务的核心。
底部有我的公众号”土猛的员外”的二维码，里面置顶文章有公司的介绍和我的联系方式，还有TorchV AI的交流群。
感谢您的耐心！谢谢！
