微信扫码
与创始人交个朋友
我要投稿
最近两个多月写文章的频率明显低了很多,不是因为懒了,而是忙着做LLM应用的客户场景落地去了。今天把客户场景落地中的一些心得总结分享一下,希望对广大期望LLM应用落地的企业有一些帮助。
与很多企业客户的深度接触之后,发现绝大多数企业在LLM应用落地中存在三个显著问题,这些企业包括世界500强企业、央企、著名品牌公司,也包括和我们一样但非AI行业的创业公司,所以从样本上来说应该有一定的参考性。然后再分享一下我们在落地过程中碰到的各种难点和需要客户一起决策的点。下面先说过总概。
好吧,下面我们分为几个部分来梳理一下,这几部分没有什么必然联系,我也是想到哪写到哪,分别是RAG、数据、应用和部署。
这里我可以先把思维导图贴出来,下文就是对这个图进行说明。
图1:LLM应用落地中的问题总览思维导图
RAG在LLM的企业应用中的重要性自然不必多说了,我的公众号讲RAG都把我自己快讲吐了,本文就简要讲讲一些难点。
首先是多跳问题
图2:多跳
多跳问题在我们的落地场景中一般都是发生在报告编写的数据整理环节,比如要从一堆报表中找出企业近三年的复合增长率,要和竞对比较发展情况等,这时候一般的RAG无法满足。在网上也有不少介绍解决多跳问题的方案,较为常见的是使用图数据库,但是在实际落地环境中,这对于数据更新还是有困难的(也可能是我们不熟悉),所以我们最终没选择图数据库,而是采用了去理解意图,然后拆分实体和意图的方式进行RAG。也许在某些环节中对于关联关系没有图数据库那么强大,但维护方便啊,几乎没有额外的人工维护成本。
然后是路由问题
图3:路有问题,我们也叫外部MoE
说实话这个问题我们之前是没有关注的,但是你知道一旦落到实际生产环境中,文件一多,特别相似文件一多,各种问题就出来了。比如公司2021年的财报和2022年的财报中某项数据,有时候只在文件名和一些大标题才有年份,就造成了chunking之后失去年份等关键信息,造成最终结果的错误。
这种问题我们目前采用的方式是在文件处理时收录元数据,如标题、时间、区域等。然后在检索的时候,首先对问题进行拆解,识别年份等关键信息,直接路由到相应的年份知识库或目录进行检索,不仅提升效率还解决了内容混淆的问题。
相对于RAG,个人觉得数据处理是企业应用中在技术层面最难的问题。下面我就简单分享四点。
结构化数据处理
图4:结构化数据处理
我们在RAG中处理的都是非结构化数据,比如word、pdf、txt、图片等,激活企业中沉寂状态的绝大多数资源数据,对RAG来说已经“功不可没”了。但是在企业场景中,结构化数据无法逃避,比如企业想把自己的产品数据库加入到基于LLM的应用中,在问答、统计分析等场景中就可以使用这些结构化数据。
我们的对结构化数据的处理方式比较淳朴,没有把DB、excel等进行向量化处理,而是仅仅提取了结构化数据的资源名录和说明内容,或者是数据里面的表名、表描述和schema等元数据,只做元数据的embedding,然后加入到应用中,后续通过function call进行调用。让结构化数据保持原有的精度比向量化要好,我们需要审视,RAG在整个应用中仅仅是作为一个pipeline,而不是全部。
管理大文件
图5:知识管理本身就具有非常高的复杂性
这一部分其实无关任何技术,最大的问题是文件数量一多之后的管理问题。因为用户需要一个清晰的交互界面去管理海量文件,就像我们有一个客户,文件总量已经超过5TB,数量非常庞大。但他们也有更新文件的需求,这时候,一个可清晰管理的交互界面就非常重要了。也为此,我们在v1.7.3引入了二级分类和标签来简化客户管理知识资源的复杂度。
这一块看似和AI无关,但是我们要照顾到用户的使用体验,简化海量知识内容场景下的知识管理复杂度,对于数据质量至关重要。
文件解析
图6:文件解析
文件解析是一个需要持续优化的过程。最直接的一个例子就是我们在实际场景中发现一些大型客户的资料还存在大量的doc文件(目前主流的是docx),但是python体系里面我们很难找到解析doc的合适组件,于是我们转向用Java生态来解决这个问题,我们的系统本来就是以Java语言为主的。
还有就是一些国标文件里面存在大量的数字签名,需要用特别的方式去解析。然后就是扫描件和影印版,有些能直接识别,更多的则需要OCR。
再说一个就是表格的解析,我们现在使用的是提取之后转成带有制表符的markdown,这能解决大部分问题。但是也有一些特殊情况,比如复合表头,以及在一个格子里面存在层级缩进(大标题、小标题的组合)情况时,就需要特别处理。
反正文件解析是一个大难题,难在特殊情况比较多,就像我前面说的,你需要有一种心态,不是觉得烦就放弃了,而是要关关难过关关过的心态。前几年我们团队在研发和运营一款数千万用户的产品时,也是经常有人反馈各类问题,在中间比较长的一段时间,我们的第一反应是“就你事多”,“肯定是你自己不会用”。但是后来慢慢性子磨下来了,觉得我们去抱怨客户的行为和形态是最傻的,其实人家是在帮助我们提高。所以后面团队内部达成统一思想,要乐于接受反馈并积极改进。
只有当你操盘过几千万人使用的产品,才会面对各种稀奇古怪的问题,才会心态崩溃,然后持续崩溃,最后你打扫碎了一地的烦躁,振作起来,才能真正做好一个服务者。
多模态
这是我们还未很好解决的一个问题,但是它变得越来越重要。
图7:多模态问题,更多时候我们不是在说OCR
目前碰到的多模态场景里,语音的处理还算简单,基本上ASR就可以完全解决,对于视频我们还没去碰。目前对我们来说最难的是图片,不是所谓的OCR,而是布局识别。比如以文末的思维导图为例,“请问在数据节点中,主要讲了哪些问题?”好吧,我相信这是个复杂的问题,但是企业应用里面确实存在。还有企业客户让我们识别图纸内容,我们只能坦诚地说等我们再努力努力(也不一定能攻克),也许新的多模态大模型到来的那一天就是给答案的那一天。
目前我们对于这类问题其实已经有一个比较好的解决方案,就是我们在产品架构中提到的MLLM,但是空跑都需要占用26GB显存,说实话在私有化过程中,对于一些企业是有压力的。
对于应用我其实不想说太多,因为差异化太大,我只想说一些自己认为的方法论。
“做什么”比“怎么做”更重要
我们面对的企业客户(也包括试用客户和POC客户)中,确实有一部分是处于FOMO状态的,自身并没有想好要做什么,只是有很强的“危机意识”,不拥抱AI就会弱后。但是对于我们来说,要更好地为他们服务,就必须是让客户想清楚或者选定一个目标的,不然做到哪算哪,最终签合同的时候就会不顺畅。只有确定了清晰的POC目标,然后去落地,最终给出满意的评测结果,才能最终促成合作。对于企业也是一样,想清楚做什么,时间和人力成本才不会浪费。
这里是这两个月总结的几个建议:
快速应用
图8:TorchV AI的LLM企业应用快速开发架构
这句话有点别扭,但是快速也意味着可以更快找到核心业务场景,可以快速验证和调整。
这里就需要类似有我们TorchV AI这样的基础平台了,已经把一些复杂的技术问题处理好,客户只需关心业务的适配。要做到快速,我觉得需要做到四点:
60分还是90分
当然是90分,对于单独的一个企业客户来说,为什么要容忍一个只能达到60分的应用。当然这里的分数是和目标相关的,比如我们客户说,你能解决我30%的问题我就满意了,那这30%就是100分。
作为企业AI应用服务者,要达到90分你就必须深入企业业务,也许你不用去学会操作他们机器,但是必须要对他们认为什么是好,什么是不好有深刻理解。
创建应用的三种方式
在我的上一篇公众号文章中提到过这部分内容了,我不展开说,有兴趣的朋友客户查看《探讨实现AI Agents的三种方式,不同的方式带来不同的客群和场景 |LLM |Agent |RAG》。
三种方式主要是:
最后说说私有化部署中的一些问题。
大模型能力考量
我相信大家应该都会关心在私有化场景中应该选择什么大模型。我们接触的客户在大模型选择上也是不尽相同,最早有Baichuan2-13B,后面有Qwen1.5-14B,还有客户自己就搭建了Qwen-72B。后面我们常用的其实是GLM3-6B。下面是我们做选择的一些思路分享:
各类环境适配
我就罗列一下碰到的问题和操作吧:
图9:国产环境适配
图10:TorchV提供的前后端全套API,可将系统融入客户系统
在实际的企业场景落地过程中,很多事情没有当初研发产品时那么性感,但我们最终提供的是客户价值,让企业客户能真正有效地将LLM应用跑起来,在业务中发挥巨大价值。所以任何关联的工作都是必须考虑的,过程中确实有很多坑需要去一个个填平。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-07-18
2024-05-05
2024-06-20
2024-09-04
2024-05-19
2024-07-09
2024-07-09
2024-07-07
2024-06-13
2024-07-07