最近两个多月写文章的频率明显低了很多，不是因为懒了，而是忙着做LLM应用的客户场景落地去了。今天把客户场景落地中的一些心得总结分享一下，希望对广大期望LLM应用落地的企业有一些帮助。
前述
与很多企业客户的深度接触之后，发现绝大多数企业在LLM应用落地中存在三个显著问题，这些企业包括世界500强企业、央企、著名品牌公司，也包括和我们一样但非AI行业的创业公司，所以从样本上来说应该有一定的参考性。然后再分享一下我们在落地过程中碰到的各种难点和需要客户一起决策的点。下面先说过总概。
三个问题
AI思维：就像以前大家常说的“互联网思维”一样，AI思维接下来肯定会被越来越多提及。其实所谓的“XX思维”没这么玄乎，说到点子上，其实就是想了解更多已经在开展的案例，然后结合自身情况来做“复制”或创新； 快速工具：企业工作人员使用LLM很简单，一个浏览器就可以。但是要把LLM的能力结合到自身的业务应用和系统中就没那么容易。需要对接LLM的API、控制幻觉、管理知识库、让RAG的准确度、相关性达到企业应用水平，还需要和自己的应用相结合等。绝大多数企业更希望将自有的研发人员（AI研发人员稀缺是普遍现象）投入到应用开发上，希望基于一个开箱即用、稳定和高质量的LLM应用开发平台来提升他们的业务水平； POC验证：这是大部分企业开始都没有提出来的，但却是最影响签约的环节。企业客户需要一套有说服力的POC评测方案，在评测结果上得到满意效果之后，企业内部决策（购买）才会变得更加顺畅。
四个难点
私有化部署的环境：包括网络和服务器环境，我们经历了纯内网的客户、GPU版本比较老的客户，以及国产GPU环境，嗯，可以总结的内容很多； 交互友好：CUI（命令行/对话方式的交互界面）的交互方式不是万能的，有些场景中，CUI会让使用者会望而却步（我不知道问什么）。有时候把对话的交互形式藏在GUI后面对用户更加友好； 意想不到：很多意外情况层出不穷，有些问题可以让你的落地进度滞后半天。解决这类问题，不仅仅需要技术，还需要一个好心态，这一点我们在之前的几千万人使用过的产品研发和运营中已经养成?； 方向选择：绝对不要让你的客户说先试试看，一定要让他做目标和方向的选择，不然后续很难做POC评测。要么就是针对企业客户明确且重要的需求，一起做到90分，要么也可以什么都上，就是一个尝鲜（但要放低期待）。嗯，客户对于LLM使用的方向、他们的预期，以及客户的配合度，对于落地是否成功都非常重要。
好吧，下面我们分为几个部分来梳理一下，这几部分没有什么必然联系，我也是想到哪写到哪，分别是RAG、数据、应用和部署。
这里我可以先把思维导图贴出来，下文就是对这个图进行说明。
图1:LLM应用落地中的问题总览思维导图
问题
一、RAG
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目标，然后去落地，最终给出满意的评测结果，才能最终促成合作。对于企业也是一样，想清楚做什么，时间和人力成本才不会浪费。
这里是这两个月总结的几个建议：
从简单业务或小切口入手，比如一个内部查询工具，一个智能客服，先让全员把AI用起来，只有用起来，才能提升全员的AI思维； 从清晰业务入手，业务本身逻辑和流程就复杂多变且存在问题，真的不适合作为最开始的AI应用； 从AI擅长的业务入手，这波AI的主要代表就是LLM，生成+推理是主要功能，去发挥最大LLM的功能，这样的业务会带来更好的提升； 需要去从业务架构梳理，需要有应用设计方案，这一点和传统的IT项目一样，别以为AI时代就能逃开。
快速应用
图8:TorchV AI的LLM企业应用快速开发架构
这句话有点别扭，但是快速也意味着可以更快找到核心业务场景，可以快速验证和调整。
这里就需要类似有我们TorchV AI这样的基础平台了，已经把一些复杂的技术问题处理好，客户只需关心业务的适配。要做到快速，我觉得需要做到四点：
快速知识库创建和维护：上传文件即可，零维护成本； 快速对接LLM：对接LLM，对LLM做选型，知道各个LLM的优势和劣势； 快速发布到多端：将应用快速发布到多端，让真正的使用者快速使用起来，形成“使用-反馈-迭代”的循环，才能达到企业真正想要的 效果； 快速评测POC：客观评测相对简单，可以设定评测集。真正需要费心的是主观评测，这里不展开。
60分还是90分
当然是90分，对于单独的一个企业客户来说，为什么要容忍一个只能达到60分的应用。当然这里的分数是和目标相关的，比如我们客户说，你能解决我30%的问题我就满意了，那这30%就是100分。
作为企业AI应用服务者，要达到90分你就必须深入企业业务，也许你不用去学会操作他们机器，但是必须要对他们认为什么是好，什么是不好有深刻理解。
创建应用的三种方式
在我的上一篇公众号文章中提到过这部分内容了，我不展开说，有兴趣的朋友客户查看《探讨实现AI Agents的三种方式，不同的方式带来不同的客群和场景 ｜LLM ｜Agent ｜RAG》。
三种方式主要是：
增强型：利用AI来增强原有产品，适合已经有丰富需求数据和用户的巨头们； 工具型：比较常见的就是圈住广大开发者的开源软件解决方案，用低代码工具编排workflow来创建应用； 共创型：深入企业业务，发展共性较强的几个场景的基线产品，在这些基线上为企业开发应用（或企业自己开发应用）。
四、私有化部署
最后说说私有化部署中的一些问题。
大模型能力考量
我相信大家应该都会关心在私有化场景中应该选择什么大模型。我们接触的客户在大模型选择上也是不尽相同，最早有Baichuan2-13B，后面有Qwen1.5-14B，还有客户自己就搭建了Qwen-72B。后面我们常用的其实是GLM3-6B。下面是我们做选择的一些思路分享：
选什么LLM其实和业务方向有关系：如果业务中逻辑推理要求较高，我们推荐参数越多越好，比如32B、72B。但如果业务中主要功能是做归纳生成，那么6B、13B、14B也够用； POC环节的资源限制：哪怕是一些非常大的企业，比如A股上市公司，或者央企。他们在POC阶段其实GPU资源也是很紧张的，主要POC验证效果不错，他们才会动用资源去采购更多资源。所以一定要考虑在小模型下也能达到一定水准。 胶水补丁：如果在POC阶段已经限制了大参数模型的使用，那么你就不能把太多问题推给LLM去解决。这时候胶水组件就起大作用了，比如在文件处理环节完全不依赖LLM，在检索生成环节做更多的意图识别、NER、分类，减轻LLM的处理压力，在算法上做一些优化（我们目前有三个原创的实用算法帮助我们解决了很多问题），都可以减少对LLM的依赖。这些胶水组件发挥的作用在POC环节非常关键，当然业务是强逻辑推理的，要和客户说清楚，肯定要上大参数模型。
各类环境适配
我就罗列一下碰到的问题和操作吧：
图9:国产环境适配
服务器环境问题 在低配环境需要降版本，比如相对老旧的T4、A10和V100，需要把一些组件的版本降下来才能更好地工作； 我们在国产的鲲鹏920、Atlas 300I上部署也是比较痛苦的，还好有官方工程师出马和我们一起搭，很多工作虽然缓慢最终也成功了。总结了宝贵的国产环境的部署经验； Docker是好东西； Java环境的部署真的友好太多了，Python的安装很自动化，但是在无外网的环境很痛苦，我们特意买了1TB的硬盘，把所有依赖全下载好，然后用脚本进行本地自动安装。 功能性模型部署 NER：命名实体识别模型安装； embedding模型：本地化我们一般采用BGE-large； rerank模型：本地化我们也采用BGE-large； MLLM模型：这个比较大，而且我们还在适配功能，到6月份再给有资源富余的客户们部署。 对接：这是一件很繁琐的事情。 客户原有系统对接：应该说不一定都能对接，因为也需要原有系统有API。这时候就看出来一些老系统的无力，大家在一些软件系统选型的时候，一定要问是否提供完整的API； 文件同步和等待队列：有些客户自己原本就有知识管理系统，所以就需要同步到我们部署的系统（知识库）里面。这时候最好是对方POST过来，减少定时循环拉取的压力。当然，我们还有客户的数据量非常大，一次性几十个文档，这时候需要做批量接收和等待队列，不然会中断 ； 更加完善的ETL过程：做到后面，我们发现十年前用的kettle依然还是非常牛逼的，他们的设计对于数据传输和处理放到现在依然够用，我们准备在后面进行集成。在企业应用里面，有太多非算法的工作需要去认真处理。
图10:TorchV提供的前后端全套API，可将系统融入客户系统
POC评测：本来也想把POC评测方法再展开讲讲，但是涉及和某客户的共创，所以就不展开说了。
总结
在实际的企业场景落地过程中，很多事情没有当初研发产品时那么性感，但我们最终提供的是客户价值，让企业客户能真正有效地将LLM应用跑起来，在业务中发挥巨大价值。所以任何关联的工作都是必须考虑的，过程中确实有很多坑需要去一个个填平。
