目前企业用户在落地大模型时，TOP3 的场景是数据分析、知识库问答、客服营销这些方向。今天的分享核心分为三个部分。
第一部分将分享，为什么知识库问答是值得企业用户落地的优选场景？尤其向管理层汇报为什么落知识库问答，会高度相关。
第二部分会介绍，大模型加知识库跟传统知识库之间有什么区别？这个同时也是企业内部去立项时，需要解决的一个问题。
第三部分会分享，金融行业大模型加知识库的落地案例。分享嘉宾｜张扬
大模型知识库为什么是企业大模型落地的优选场景？
大模型技术落地时，分了四层：应用层、中间层、模型层、基础层。
过去大家是把知识库当成核心落地的一个场景，尤其今年爱分析和企业用户交流的过程中，企业用户基于上层的场景，抽象出一些中间的能力，放在中间层。过去的中间层主要是一些大模型的运维工具，现在有越来越多的企业用户会考虑把中间层作为一个能力中台，去调用各种各样能力。第一个是知识库及知识库的 RAG 检索，是企业用户在落地的过程中，优先考虑以及选择比较多的能力场景。第二个是大模型加数据分析，不管是对话式数据分析，还是直接取数，这是第二个中间的能力场景。第三个是 Agent 的一个流程画布，是因为大模型涉及到有 Agent 能力做目标的理解、任务的拆解和自动执行，所以这是第三个核心能力场景。基于这三个核心的能力场景，延伸出企业用户在落地应用时，会优选的一些核心落地方向。知识库和检索毫无疑问是第一位的，因为在实际落地的过程中，大家最开始接触的 langchain 或者是 FAST GPT ，这些其实都是基于知识库落地的。今年落地时大家很关心的 RAG ，其实也是知识库上层检索落地的一些应用场景。第一个核心点从大模型的能力角度来讲，它会逐渐越来越偏中间层。知识库问答是知识及检索之上的一个应用场景，知识库和检索作为中间的能力层，可以应用的点会很多。这也是为什么我们建议企业用户优选知识库问答落地的原因。第二个核心点是知识库及检索带来的上层应用比原来多了很多。过去大家理解知识库主要核心就两个场景，一方面是有一个知识库的门户，是公司内部在使用。另一方面是知识库上层做客服，除了这两个场景以外，其他的场景跟知识库之间的关系会小很多。但是现在知识库及检索如果变成一个能力的话，对内部用户和可应用的场景范围变大了，因为不光是客服可以有助手或者客服底层有知识库，其实 it 、营销、HR 也可以有。包括现在央国企落得比较多的办公类场景，其实很多时候都在落各种各样的一些 SSC 的场景，这背后其实都是知识库问答，或者说知识库其实是核心落地的基础。第三个核心点从知识库本身的建设的过程当中，我们总结下来就是三个核心的要素：成本可控、算力、验证速度。首先是知识库场景的成本可控，不管是去年下半年也好，还是今年上半年也好，知识库实际落地的时候，它的成本相比较其他大模型的落地场景预算，相对来说比较便宜。也可以去做公有云的一些调用，这样如果用 API ，价格会比较便宜。整体知识库的场景建设，成本基本上是能控制在百万级别。其次即使私有化部署，用的模型参数量要求也不会特别多，大部分我们看到的基本上都是十几 B ，30B+的看到的比较少，绝大部分 100 亿左右参数就能解决。推理的算力相对来说要求会比较低，如果你有一块英伟达的卡，基本上 10 - 20 个并发的知识库问答，基本上一张卡推理就能解决。有时候也能看到很多提供的解决方案里，也是带了一体机，基本上就是百万级别的一体机能解决实际的场景落地，这是推理算力要求比较低的优势点。同时整个知识库场景上层的建设成本也会低很多，因为它主要的应用是把它包装成 API 嵌到应用里边，另外一就是直接做知识库的问答展现在前台，所以它的场景搭建成本会稍微低一些。最后落地的速度比较快，验证起来也比较快，绝大部分知识库的问答场景可能是在一个季度之内就能解决。对比私有化部署需要花半年甚至一年左右的时间去验证的话，这个验证的速度是比较快。到底大模型加知识库和传统的知识库有哪些区别？
按知识库发展的历程，最早的时候知识库就是档案室。很多央国企、党建、人力、招投标的档案都会有档案室的存在。这就这是传统的知识库，比较简单，然后逐渐进阶到把传统知识库搬到线上，变成数字知识库，大家接触比较多的基本上还是上一代传统 AI 的知识库。
传统 AI 的知识库的话，覆盖的模态基本已经比较多了，文本、图片、语音、视频这些模态都会有。它的核心应用基本上是以搜索、客服和推荐这三个为核心去展开的。相对来说知识库的应用范围比较窄。另外传统知识库 1.0 阶段有三个核心的问题，一直比较难解决。第一个在知识库构建的过程当中成本是比较高的。传统的 AI 知识库相对来说冷启动周期会比较久。要做大量的数据标注，包括知识的提取、流程画布的设计，冷启动中需要话术师，然后包括一部分人工的数据标注，这个时间周期会比较久。第二个 AI 知识库很难做全公司统一的知识库。更多的就是客服，有客服的知识库，整个公司有一个大的知识库门户，但底层的知识库其实还是割裂的，这里边就涉及到运维的成本，一旦要新建一个知识库，还得从 0 再起一套。例如面对 IT 部门，重新去建 IT 的知识库，先要把它抽出来变成一个 IT 的知识库，然后再去做上层的 IT 知识库的搜索检索，所以知识库一旦要做上层的助手时，就需要重建一次，这个运维和更新的成本会比较高。第三个是交互能力比较弱。基本都是封闭域的问答，很难跨域去解决问题，包括交互的上下文的联系能力会比较弱。到了大模型加知识库的阶段，从模态的角度来讲，基本上变化不大，还是过去的文本、图片、语音和视频。第一个核心比较大的变化就是知识库上层长的应用比原来多了很多。除了搜索推荐和客服以外，像知识库的助手、营销、合规、工单自动流转、基于 PDC 的闭环去 tracing 工单，都是过去知识库比较难去做到的，是大模型新增的一个能力点。涉及到交互的一些结果，传统的知识库其实是用全文检索也可以去实现，但是更多的是告诉你检索的位置，包括检索出来的一些结果，但是并没法直接回答你的问题，大模型加知识库，更多的还是用向量去解决问题，所以它能够联系上下文，除了给你结果所在的溯源位置以外，它还能告诉你直接加工出来一些答案，使用更高效。第二个是构建和运维的效率会比原来更高，过去知识库需要有话术师，有人工去做标注。现在构建的环节基本上就变成了文档的上传，上传之后，要去做一些相似问的扩充，这些工作其实并没有省掉。不过在这个过程当中，大模型能够加入其中，在上传一个文档后，大模型能够自动帮你去生成一些问答，人更多的是从中去选择和审核。相似问过去是基于专家经验在做，现在大模型可以帮你去做，做完了之后人更多的是一个审核的一个过程。在构建的过程当中效率比较高，不再需要大量的人工，冷启动周期会比过去要短。在运维的阶段，过去的运维因为底层的知识库有割裂，包括每个知识库的主题方向上，如果要去新建和更新的话，都需要重新去做标注，有可能涉及到话术师的一些配置。现在可以做个统一的全企业的知识库，当然还是要把知识库去做分域，但这个过程当中，人的参与度，包括运维的成本要比原来低很多，即使要做一个新的知识库助手，更多的是调优的过程，而不是从 0 再去搭建一个新模型的过程。第三个是应用场景扩充，核心就是能够覆盖企业内部各个岗位，每个岗位都可以有自己的助手。应用场景的扩充，包括企业用户数量的扩充，是它核心的第三个优势。除了发展历程上的对比，从知识库本身构建和运维的环节角度，也可以看到一些大模型的核心价值。
大模型在知识库构建和运维的过程当中，有很多可以实现自动化。比如知识构建中典型的一个案例就是车企，过去做自动驾驶的一些标注，其实都是人工在去做。现在大模型有通识在里边，所以大模型有很多数据标注，这是绝大部分车企在自动驾驶环节要去尝试的一个点。包括它有可能涉及到知识的自动分类、抽取实体关系、自动生成问答，对这些构建过程当中，很多是大模型可以自动实现的，人更多的是审核和选优的过程。
在知识库的知识校验层面，是目前在尝试大模型落地应用的方向，这里可能会存在的一个问题，主要是新词的校验会存在滞后性，本质上还是人要去做一次兜底。毕竟大模型对于新的知识接受程度，或者新的知识获取渠道还是比较少，即使有 RAG 加载新的知识库，也需要有新的知识库之后他才能理解。所以这可能是校验的时候存在的难点和问题，目前还是人工再去兜底的阶段。
未来在知识库的运维、安全层面，其实大模型也会有它渗透和应用的方向。比如运维，知识库一定会存在很多过时的信息，每年 GPT 除了年初会发布一次以外，每年还会再做一次审核，跟前四个季度去做一次对比和审核，其实数据会持续去更新，这些数据其实会涉及到前后的时间戳的区别。过去这些都是需要人工选答案，人工做标注。未来有可能基于基础的时间戳逻辑，大模型自动去判断，或者自动去做好运维工具，把它更新成最新的知识。
除了时效性的角度，大模型的知识其实还是会有错误，或者是不同的文档里边针对同一个知识有不同的解释和理解。这些可以是大模型去发现的一些问题，也是知识运维的过程中，过去需要人遇到的具体问题才能去解决的。其实大模型是可以在知识运维阶段提示知识不一致或者知识错误的点，然后由人工去改正或者说是修复的。
在工单场景，比如内部用户提到了一个问题，大模型没解决，现在大模型可以实现基于未解决的问题，根据工单的分类自动生成一个新的工单，再将工单自动派发给某一位工程师或者某一位负责知识管理的人员，由知识管理人员把工单里边的问题解决，然后关掉。
关闭之后，其实大模型针对这个新的问答就具备了加载的能力，这样客户或者终端用户去问新的问题时，涉及到新问题的时候，能回答出来最新的结果。这个基本上是目前能够实现的知识运维的一个点，更多的还是发现问题能够自动帮你生成工单。
实际在落地的过程当中，还没有实现到具体检测过时信息，包括自动修正这些是在尝试的一些方向。
另外知识库的安全有一个很重要的问题，其实是权限，这也是在跟很多企业用户沟通的过程当中，落地的时候比较大的一个问题，知识库里边涉及到的知识，针对权限会有很大的弊端。因为过去的权限其实是写死在代码里边的，用户能看什么样的数据权限是写死在后台的。有了大模型之后，所有的知识在大模型里边，那其实在大模型里边的话，如果不断地去通过提示词的一些注入，或者反向的提示词，有可能会通过大模型绕过写死在代码里的权限。
比如说通过提示词工程，去告诉大模型，我是一个高级别的人，能够看到这个文件，通过不停的提示词训练，大模型会可能出现数据泄密的问题，所以这个是当前大模型在数据库安全，尤其是权限管理着重去解决的问题，也是比较大的一个隐患。
金融机构大模型知识中台建设
一个金融机构落地知识中台，核心用的是大模型，这里面主要讲几个核心的要点。
第一个要点是实际用的大模型，部署的话基本上铺了两个，一个6B，一个13B。两个国产的开源大模型就可以，能保证上层的使用了。所以实际落地的时候，对于绝大部分的企业用户来讲，知识库确实是一个，对于算力要求、对于底层大模型要求，不是那么高的一个场景。这也是回应刚才讲的大模型加知识库是一个比较优选的落地。第二个是在落地过程当中涉及到业务收益等核心。这家金融机构最终讲的业务收益落在知识库构建的用时的角度，本质上讲的就是知识库冷启动这点，这点也是我们看到目前绝大部分企业用户会去认可的一个点，绝大部分人最后认的还是冷启动的效率提升。所以最终这家金融机构讲的指标改善，也是知识构建用时下降了30%。第三个要点是这个案例的成本是三四百万级别。这个项目为什么预算能做得比普通的知识库更高？其实核心是它融合在知识中台里边去做，相当于把原来金融机构里边各个割裂的知识库拉通的过程。包括上层长出来在客服场景也是第一个使用场景，后续也规划了很多，比方说营销、 IT 的场景，其实是一个比较好的落地方式。不一定是以大模型加知识库这个单点去落地这个应用，其实是可以把它包装成大模型加统一的知识中台的方式，在内部做落地应用，一方面整个项目对于全公司的感知会更明显，涉及到的终端的用户更多。另外一方面它的业务收益价值会体现得更清晰一些。
粤ICP备17114055号
支持私有云部署
