随着人工智能技术的飞速发展，知识管理已逐渐成为企业核心竞争力的重要组成部分，为创新与效率提供源源不断的动力。如何巧妙融合大模型的先进能力，构建一个既高效又智能的知识库问答系统，进而优化企业服务品质与运营效率，是当前众多企业积极探索的关键课题。
本次分享将深入剖析大模型技何赋能企业知识库问答系统的建设，介绍相关应用与实践。
本次分享会聚焦我们在通义大模型和百炼的基础上，如何将阿里云视为企业并结合其知识与AI，以助力企业高效创造价值，主要从四个方面进行介绍：
第一，从阿里云的知识采集管理实践入手，让大家初步了解阿里云知识管理的现状以及在AI领域的一些构想。
第二，通过智能应用这一我们最早且最为成熟的应用，描述当前产品知识在 AI 相关方面的应用情况，并介绍我们对其效果的理解。
第三，许多企业非常关注如何产出高质量知识内容，将从几个方面进行介绍。
第四，在内容和效果完善后，如何在集团企业内部进行广泛的运营传播以产生业务价值。01
阿里云的产品技术是核心，所以产技知识是阿里云知识的最核心组成部分。我们的知识管理有几个核心理念：一是知识管理旨在提升业务效率，同时对知识进行运营；二是用户既是使用方，也是内容生产方，通过社区化进行运营；三是知识来自业务并应用于业务。这也是我们进行知识管理的初衷，均围绕这一核心理念。
就今天围绕AI所讲的内容而言，必然要涉及知识的生产和管理方式。我们的主要模式是 “一加N”，即面向整个阿里云的众多不同条线的产品或技术领域，横向拉通这些技术领域或产品。在进行知识生产时，我们通常采用 “三环” 方式。所谓三环，第一环是非常重要的官方材料，即那些非常正式、质量极高的部分，完全由内容管理方进行内容生产和编写。中间二环部分由内容管理方进行定义、规划甚至输出模板，再由各个业务方或产业线生产内容。第三环则是由广大条线部门人员、用户拓展不同内容，主要是分层次的三种不同内容层次和生产方式。实际上，之所以要讲述这个生产方式，是因为它与我们今天要谈到的基于大模型进行内容利用和治理密切相关。在AI时代到来后，我们思考如何围绕知识管理理念，更好地与大模型结合，利用大模型的能力将知识管理更好地应用于业务中，提升业务效率。
因此，从去年开始，我们基于通义千问和百炼构建了一系列应用。其中，一些应用纯粹与知识管理相关，还有一些应用直接面向业务，例如面向产品管理生命周期、需求管理提效的AI增强应用，以及面向售前过程所需要的一些AI增强能力应用，这些都是在整个过程中产生的。从去年开始建设时，我们就将其规划为一个大的框架，称为 “产品博士”，如今它已成为我们产品知识的专属模型。基于这个模型的能力，未来我们还会不断拓展更多新的应用，以更好地衔接知识与业务。接下来聊聊智能问答，它是我们从去年5月份就开始做的最早的应用。我们先做智能问答的第一个原因是，它本质上是大模型最直接的应用形态，大家比较熟悉且较为成熟。第二个原因是我们希望在做智能应用的过程中，沉淀我们产品专属知识的专属模型能力。因为在这个过程中，我们知道要进行大量的内容治理工作。所以，整个工作完成后，我们的产品知识得到打磨，这部分知识就可以被利用到面向其他应用提供服务。
从今年年初智能应用发布上线后一直到现在，我们又打造了一些新的各种各样的应用，这些应用都源自于我们事先做好的产品知识内容。我们的智能问答包括几个应用场景。首先，最基本的是可以基于产品询问相关信息，例如产品的各种属性，如功能、优势、特性、原理、场景等。但一般来说，客户可能不会这么问，他们可能会基于一个具体的业务问题，询问可以用什么产品或产品组合来满足这个业务需求。所以，我们也提供了这部分能力，即基于场景或功能查找产品。
我们打造了这样一个智能问答应用，其定位是专门面向阿里云的产品知识，回答产品知识各个方面的问题。主要瞄准的用户群体是阿里云内部员工，尤其是前线销售队伍。
除了这两个最主要的问答能力之外，还有一些相关的周边能力也被整合到这个产品中。例如，可以基于它查找产品相关的产品经理、案例、解决方案、产品参数以及产品竞对对比等。经过几个月的打磨和几轮优化后，该产品在今年2月份推出。从今年一整年的运营情况来看，得到了前线核心用户群体的积极反馈，目前可以说是整个公司内使用量最大的智能应用。
我们在这个过程中发现，流量并非仅靠运营就能取得，一定是有较好的实际问答效果才会进行发布。这个效果主要取决于两个方面，一是模型的能力，二是内容的质量。
模型的能力可以分为两个层次来说。第一个层次是基模，基模的能力以及参数规模对整个效果有着全局性和根本性的影响，这种影响非常明显。第二个层次是基于基模之上的百炼。对于ToB业务来说，我们必然要经过百炼来调用使用基模的能力。百炼为我们提供了像Prompt、SFT、RAG等能力，我们直接使用这些能力就可以撬动基模的智慧。我们今天讲的这个智能问答应用就是基于百炼的RAG能力，同时也内置了系统级Prompt。所以，这是模型能力对效果的一个比较重要的影响。
第二个层面是内容的质量。很多时候，我们接触到的很多客户在初次结合大模型去做智能应用时，往往会遇到一个难点，就是不知道该如何处理内容，因为效果可能未必能达到预期。当模型确定后，能做的工作就是在内容上下功夫。今天也会为大家介绍一下我们在内容方面的一些实践。
我们智能应用主要用到三个方面的知识内容，这是我们人为的划分。但我们觉得，对于企业来说，虽然任何一家企业的知识未必像阿里云的产技知识那样，但无论什么样的知识，其实也可以类似这样划分。至于原因，我们先来看一下结构化数据内容。
第一部分内容，它代表了一类非常准确客观的数据。这些数据往往直接存在数据库里，是最客观、可信的。这部分数据几乎不需要做任何治理，可以直接使用。尤其是在直接问到相关数据内容时，甚至可以不经过内容生成，直接给出答案。但这部分内容覆盖的面通常没有那么大。
所以，我们还需要有一部分核心的知识内容去覆盖90%以上询问产品各种知识的情况。我们会构建这样一批核心的知识内容，其要求是质量必须有保障。这里面的内容来自于我们过去在知识管理过程中沉淀的一批高质量材料，比如产品知识库、赋能认证材料等，这是我们筛选出的一些核心内容。由于用户可以询问产品的各种方面问题，所以我们为了覆盖更全面，还会有各种扩展的知识内容，以应对产品周边的一些问题。例如，我们会筛选一批市场洞察报告、客户案例、解决方案资料等作为扩展资料，以提高覆盖度。所以，我们对整个内容进行了这样的划分。第三部分会介绍一下我们是如何产出高质量的知识内容。当下可能普遍会存在一个误区，即手上有什么内容就用什么内容。这样做效果通常不会很好，因为手上的内容往往没有经过规划，是过去历史沉淀下来的。如果直接使用，当问题问到知识盲区时，会发现缺乏知识内容，回答效果肯定不太好。所以不能有什么内容就用什么内容。那应该怎么做呢？应该进行内容的规划和策划。这就好比在写代码之前要先做软件架构设计，同样，我们今天也要先做内容的架构设计。我们要围绕打造的智能应用的定位，分析面向的人群和需要提供的问答范围。根据这个范围，确定我们需要哪些知识模块和知识点，这些知识模块和知识点就构成了我们的知识地图，这是我们做内容策划架构的成果物。
有了这个知识地图作为指引，我们自然就知道对比手上已有的内容后缺什么，缺什么就补什么。如果内容欠缺，效果肯定会受到影响。
第二个误区，觉得内容越多越好。现在企业里的知识内容往往非常庞大，比如企业经过十多年时间沉淀了海量的知识内容。但这些知识内容往往不一定都是最新的，很多知识有生命周期，有的已经很陈旧却没有被更新。所以，看似是一个海量的知识库，但内容质量参差不齐。一旦把所有知识内容都尽可能用上，反而会发现效果不好，因为内容之间会互相影响。尤其是我们之前讲的用RAG的方式，在生成之前先进行检索。那么检索的时候，每一次询问问题，比如问一个问题问10遍，有可能检索召回的内容片段各不相同。因为重复的内容知识点太多，如果重复的知识点内容质量参差不齐，那么每次召回时，可能召回高质量或低质量的内容，这样问答效果就会大打折扣。所以并不是内容量越多越好。
一般以我们自己的实践角度来看，尽量不要让冗余内容太多。如果一定要有冗余，也尽量保证这些冗余知识都是高质量的，这样无论检索到哪个片段都没有问题。理论上讲，当描述一个知识点时，只需要一篇非常好、非常全面的文档就够了，不需要导入10 篇、100篇围绕这个知识点的文档。
第三个误区是因为内容量太大，很多用户或企业用户可能会觉得内容治理的工作量太大。一旦发现效果没有达到预期，在最初始的时候就不知道怎么往下开展，看到海量内容不知道该如何治理。实际上，内容治理并不需要把所有内容都进行治理，这样工作量肯定吃不消，基本上不可行。应该怎么做呢？就像企业招人，不会到市场上招很多小学生过来，使劲培养成大学生再用人，而是培养大学生后，做一个非常可控的小规模上岗培训。同样，在做内容治理之前，要先做内容筛选，不要一股脑把内容全搞进去，先选出高质量的内容，在此基础上进行可控工作量的治理，这样就非常可控了。所以我们一定要有一个内容筛选的机制。
做了内容的规划和设计之后，对整个内容进行各种打标、分类，了解其质量和来源。这时会面临两种情况。第一种是发现缺某种知识内容，那就需要去生产、准备。第二种是已经有知识内容，但效果不好，说明这个知识内容需要治理。
我们从两个方面分别来说一下。
第一个是新内容需要生产开发，最好的方式是建立一个标准化的生产模式。如今我们发现大模型正好很需要这样一种方式。具体做法而言，我们要使生产的过程流程化，生产的内容结构化。当我们需要一个内容时，不是直接把这个内容作为任务交给内容生产者让其交付内容，而是首先对内容进行梳理，将其中的知识点结构化，甚至定义出内容的规范标准。在此基础上，我们可以拉通其他各个团队，进行跨团队的大规模知识生产。同时，通过流程化、规范化来保障生产过程。
所以，通过这种方式生产出来的内容质量相对较高，今天我们几乎可以直接将其与大模型相结合，导入后效果不错。如果很多内容材料不是以这种方式生产，而是比较随机、随意的方式生产，那么其质量未必能够得到保证。
前面我们看到了一环、二环、三环几种不同的生产方式，在这里也呼应一下，在选择内容时，我们尽量多用一环的内容，对二环的内容要仔细考察，三环的内容几乎不用。我们采用这种方式是为了保证内容质量高，希望直接选出来的就是可以上岗的大学生，而不是需要做大量工作将小学生培养成大学生。
第二个是内容已经有了，那么如何进行治理以提高效果呢？治理有几个方面，第一个是进行ROI比较高的增补。比如，发现有些英文缩写在问答时效果不一定好，那么我们可能会针对一些英文的概念术语进行定向增补。还有一些重点场景或大家关注的热点问题，我们也会进行定向增补。另外，有些知识问题可能比较复杂，为了回答这个知识，即使一个人也需要跨多个文档去消化、理解才能给出回答。这个时候我们知道对于RAG来讲，检索召回的片段永远是有上限的，比如5 个、10个。那么跨多文档显然会带来一些问题，比如找不全。这种情况我们可以人工定义一些high level的知识内容框架，通过这个框架可以更好地将这些跨多文档整合起来，这样更有利于检索召回。
同时，对于复杂表格中的知识内容，可以根据需要进行总结或简化加工，以便更好地解析表格，使知识内容得到更好的呈现。知识内容经过生产和治理后导入到百炼中。这个过程是迭代进行的，但不建议在没有产生较好效果之前就直接推送给用户，因为一旦效果不好，会影响用户的心智。如果此时再拿回来重新调优后推向用户，效果通常不会很好，因为用户的心智已经受到了影响。所以一般来说，在进行内容治理时，在发布之前一定要进行多个迭代，直到达到预期效果后再发布。这个过程涉及到对知识内容迭代和优化的管理。
左手是企业的知识库，右手是百炼和通义千问，那么如何将知识库内容与基模百炼进行整合呢？我们通过工程化的能力构建了一个逻辑性的数据管理平台。这个平台可以带来一些便利，比如企业知识库中有很多大量的PPT文件，如果直接解析，效果可能会受损，不一定那么好。我们可以进行格式转换，比如转换成PDF格式，当然可以自动转换，不可能靠人工去做这样的工作。
同时，我们还可以关联更多的内容源和知识库，通过这种关联可以对接原件，知道知识内容的来源，即来源于原知识库的哪个地址。另外，当原件的知识内容进行更新时，它可以自动进行更新。这里很重要的一点是，不建议将知识内容从支持元件上复制粘贴出来再进行治理，因为一旦原件发生变更，我们可能不知道，这样知识就全部进行了分叉，以后就很难进行管理。所以尽量在原件上进行内容治理和提升。
有了知识内容导入并与百炼结合之后，在查看效果之前需要进行基准评测，要有一个基准评测集。那么这个评测集如何构建呢？一般来说，最好能够有一些非常准确、高质量、客观的数据。比如对于阿里云来讲，内部有一套经过上万人验证的试题集，这是一种情况。
第二种情况是尽量收集来自更真实用户的提问，比如到核心用户群那里收集客户询问产品知识问题的实际情况，把这些最真实的问题变成评测集的一部分，这样能更准确地判断效果是否可行。这是对于基准评测集的构建方法。
再往后就是迭代打造效果的过程。在这个过程中，要针对Badcase做好分析，因为所有改善效果背后的问题其实都包含在Badcase中。比如有1000个用例问题，跑完后假设发现有100个Badcase，不一定要一个一个去解决，这样通常效果不好也比较花时间。可以先进行分类，至少分出TOP3，分类后的TOP3一定代表了问题的主要部分，解决一个问题就相当于解决了一类问题。
另外，现在在产品博士的界面上已经给出了与用户互动的方式，用户可以在界面上直接点赞或者点踩。当用户发现有一个问答效果不好时，可以通过点踩的方式传到后台，每天会有人针对这样的数据进行分析，从而提升效果。
另外，我们还会针对用户进行分析。比如有些用户在发布后一直没有使用过，我们称之为缺席用户，会对他们进行访谈调查。还有一些用户更重要的是使用了一个月后就不再使用了，这类我们称为离席用户，对于这些离席用户也会进行访谈和调研。通过种种这些行动共同提升我们的内容质量。
因为有很多我们的企业客户都是大中型集团企业，对于集团企业来说，其内容知识很分散，运营范围也非常广。阿里云也是一个集团企业，那么我们如何进行这样的运营呢？
首先，给大家看两组数据。我们的产品从今年2月份发布到现在，大半年将近一年的时间。在发布的时候，我们就已经做到了这样的问答质量：问题的平均回答率在95%以上，回答采答率在90%以上，也就是说拒实率比较低的情况下，正确率还能做得很高，这样问答效果就比较好。
有了这样的效果作为基础，才有后面的运营做支撑，才会有今天这样比较好的用户反馈和效果。现在，我们的核心用户群大概几千人，这些核心用户的使用率在8月份的时候已经达到了73%以上的覆盖度。8月份每月的问题回答数已经超过了15万，这是我们的使用情况。经过分析，主要有几个方面的场景是最核心的用途。
第一种情况是在需要快速作答的场景，比如在客户现场与客户交流时，客户问了一个问题，需要快速回答，来不及线下去花一个小时查阅资料。这种情况在电销客服中非常常见。
第二种情况是当客户问到一些非常复杂的问题，自己可能解决不了，需要请教专家或者查阅大量文档来回答。这种情况下可以直接问我们的智能问答。
第三种情况是有一些非常细致的问题，比如产品如何使用等，这些问题不需要去官网查找，可以直接通过智能问答回答。这几个都是我们现在用得最多的场景，一是快速应答客户，二是可以帮助我们洞察一些商机。举个例子，比如现在每个月有 4000 多个提问都是关于辅助场景下产品推荐的问题。例如，有人说 “我们今天要做一个两地三中心的容灾方案，请问可以用什么样的一些产品”，这样的问题可以帮助我们洞察商机。
此外还有一些辅助作用。第一个辅助作用是可以带来一些写作能力，对业务进行提效。比如每个月我们发现有500多个提问直接要求 “请帮我写一段文字，关于xx产品的介绍，我的应用场景是面向客户要去做一些交流”。在整个这样的一些场景上，对我们的业务有非常明显的助力。
第二个辅助作用是可以帮助我们辅助改进产品。比如结合每个月15万以上的问答数据，针对这个数据可以按行业分析、场景分析、产品分析或者结合起来进行分析，就会发现很多关于我们产品的相关洞察。这里面最核心的一点就是至少可以帮助我们更加扩充产品资料，或者提升产品资料的质量。当然，同时在其他几个方面也可以连带帮助我们提升产品的各方面能力。 那么我们如何进行运营推广呢？我们用了将近大半年时间，将提问量做到了15倍，将月提问人数做到了10倍。一般讲运营的时候，可能首先想到的是面向阿里云智能内部员工，以及核心用户群体几千人直接进行运营，但这样效果不一定好。所以我们采用了一种ToB+ToC的运营方式。因为我们希望产品博士这个智能应用能够给业务带来提效，而业务的开展是以组织的方式牵动的，所以我们要拉通组织，和组织一起进行运营，运营的对象首先是组织和团队，而不是个体。我们会联合业务方和用户群体的团队组织共同进行运营。从一开始就确定目标用户，确定优先级，然后将他们拉入进来，一起共建、一起发布。在没有得到用户真正认可的效果之前，不会进行发布。一旦联合发布，效果一定能达标。
那么同时，这种发布其实不能仅仅代表我们在发布，而实际上是用户自己在做发布。这样的话，接下来用户团队在自己内部进行消化和使用，所带来的运营效果会非常好。有了这个基础之后，我们就可以全面地在内部进行铺开。这个时候可以利用企业内部的各种渠道去进行触达和推广。
然而，仅仅有触达和推广是不够的，因为这往往只会给我们带来一个波峰，从流量上看可能这一周效果会非常好，但下一周流量又会下降。那怎么办呢？我们发现很多用户有可能还不知道怎么去用这个产品，他们不太会用，甚至可能还不太了解这个产品。所以，我们会在日常中有节奏、有频率地推送几个方面的内容。
第一个是如何使用这个产品，让用户清楚产品的功能和操作方法。
第二个是如何提问，因为对于这样一个基于大模型的智能应用，提问的Prompt是撬动智慧的唯一钥匙，提问的好坏直接影响回答的效果，所以提问的技巧也要进行普及。
第三个是最佳实践的分享，把别人真实的最佳问法分享给大家，进行反哺分享。
第四个方面又回到了组织ToB层面，与不同的团队去衔接，找到他们面向业务的核心诉求点，联合去做一些行动，比如开展一些线上线下的活动，甚至将我们的产品嵌入到日常业务的办理节点中。这样，我们整个产品就会自然而然地被使用起来。
粤ICP备14082021号
免费POC，
零成本试错
