大模型赋能企业知识库问答的建设、应用与案例

01

大模型范式下的企业智能服务产品体系

在大模型爆发之后，企业服务迎来了重大突破，使用门槛大幅降低，解决效率实现飞跃。同时，大模型具备广泛的通用性世界知识，其创造力和知识储备也更加完善，因此在许多场景中应用效果更佳。

然而，当前大家所看到大模型问答产品，与企业实际使用的时候，确实存在着一些鸿沟。首先，在企业知识方面，由于企业拥有个性化的业务属性知识，那么应该如何让它与大模型更好地结合，又该如何把企业的数据充分利用起来。其次，如今的大模型具有非常通用的能力，那怎样才能够面向C端用户做到真正的千人千面，如何与我们的业务融合起来。此外，在安全可信方面大家也非常关注，以及关注ROI的整体消耗情况，因为大模型在性能和训练等方面消耗非常大。所以，企业也需要考虑整体的性价比。

基于上述情况，当前我们对整个知识库问答产品进行了一些定向的重新设计。一方面，希望它能够更好地围绕我们的场景，将知识与问答处理体系连接得更加紧密。

另一方面，在安全可控方面，一是接入了很多安全滤网方案，二是在产品中增加了很多可干预的手段。效果运营在问答产品中非常核心，包括在业务效果调优方面也比较重要。所以，我们在运营方式上进行了很大的变革，增加了很多基础运营和可协同的能力。

最后，在大模型的人机交互方式上，我们有了更多不同场景的人设配置，在生成的交互能力方面也有了更多的考虑。在生成的语言方面，它能够更加自然地进行交流。

总体而言，当前我们认为大模型要在企业更好地落地，企业这边有几个因素。第一，企业的数据资产是否健全、丰富。比如客服对话数据、会议纪要、企业内部产品说明书等，这取决于企业自身的经营业务。企业也应该会有很多业务数据、代码类和文档类相关数据。

第二，当前我们需要考虑企业是否具备完整的应用场景。无论是在客服侧、销售侧还是管理侧，在企业内部不同岗位上，都存在不同的工作流。每个岗位所需的问答、知识检索以及问答是否有特定的场景、工作流程和知识储备。如果要将整个知识库问答落地，企业理论上需要先具备这些条件。

接下来，说回到当前基于整套大模型下的服务产品。智能服务产品并不仅仅是一种对话机器人，它在服务域中可以展开并衍生出众多服务产品。可以看到，最底层是我们的通义大模型。在其上层，我们深度定制了一些对话大模型，这是基于海量对话数据、逻辑流程、代码数据等进行融合后整体设计出来的，具备多轮对话能力、整体知识溯源能力，不同Agent之间也会有Planning能力以及插件Plugin能力，因为企业自身需要对接内部的一些API业务系统等，这些是我们最基本需要具备的能力。

再往上是我们整个服务域里的产品矩阵。第一块是对话机器人加上整个知识库，企业可以将其打造为知识门户，这里面应用了很多能力开放，如文档和网站的问答能力、NL to SQL的数据问答能力等等。

再到中间还有一层，前面提到机器人可以进行很多问答，而在坐席与用户问答的过程中，我们也有一些产品支持，如坐席辅助，帮助坐席更高效、高质量地回复；还有培训、质检、销售分析、洞察评价分析、主题摘要分析等，这些都是为了辅助运营同学和坐席人员更高效地处理工作。

接下来是云呼叫中心产品，我们称之为智能联络中心，它是全渠道通信能力的集中地，无论是用户通过网页、电话、短信，还是音视频或社交媒体等渠道进入都可以接入。

到了最上层的应用层来说，不论是什么渠道、什么模态进入的客户，我们都会有统一的路由策略来进行分发，可以做到千人千面，包括坐席的挑选等策略，以帮助我们达到更好的效果。还有一些AI Agent服务，对于整个运营体系也有非常大的帮助。

再往后就是整个服务过程，包括对整个服务的监控，分析其质量好坏。在整个对话中，假如销售团队要进行销售线索分析，也可以通过我们整套的智能服务产品体系中的一个板块去进行整体分析。客户之声，相当于检测所有对话中客户提到的我们的品牌、产品情况、服务情况或者是否有投诉等，涵盖整个客户的支撑、趋势洞察等主题分析。

最后，也可以帮助企业管理者监控整个员工的服务表现、机器人整体的服务数据，并且管理者自己也可以设计一定的Agent来为其服务，以便了解更多员工和整体企业业务情况。

以上就是在我们整个智能服务产品体系下的所有产品矩阵和整个应用场景。

02

企业对内对外知识库问答服务建设

知识库的问答链路过程中有几个层次。首先，要把所有文档进行Emendin和Trunk。当用户输入时，需要理解其上下文关系，然后进行改写，改写完后召回与之相关的片段，再与我们本身的 指令需求拼接到一起，最后通过大模型来确定应该给出什么样的答案。这个答案我们也会经过一层安全滤网的过滤，以满足企业对安全的需求。

我们在电商、零售、金融等行业做了非常多的客户，也有了一定的实践，并且在一些特定领域里也会有一些微调的专属大模型来适配企业的不同需求。像这样的一个知识库问答服务，在当前比较热门的售前售后咨询助手、企业员工助手、知识查询助手等几个板块上应用非常多。

当前大模型与原先小模型时代的差异非常之大。其一，在原先小模型时代，我们的问答机器人基本是通过QA问答或者表格的形式，亦或是在闲聊场景中有不同的引擎来处理不同的需求。每个问题都需要单独输出，并且每个问题还得对应一些相似问法来进行泛化。然而当前的大模型则不需要进行如此高强度的手工操作，只需整理数据、文档以及业务流程，直接灌入我们的库中，再把高频问答定义出来即可。

其二，就原先的小模型而言，整个对话过程中回复相对比较固定和机械。而由于大模型具备世界知识，能够理解人类并懂得我们的诉求，所以它能够带来更人性化的对话体验。

最后，从运营层面考虑，当前我们的大模型方案下做了非常多可干预、可引导的措施，同时还具备效果反馈机制以迭代模型。并且整个运营的干预机制也非常完善，所以整体运营成本会下降很多。

但是大家会发现，当前简单的问答场景在测试完后可能没有问题，但对于复杂的数据，尤其是PPT阅读的顺序和整体结构的理解是非常重要的。如果对PPT进行切片的顺序不对，或者理解本身存在问题，那么整个PPT的文档内容就会失去其结构化的内容。

其次是复杂表格类的理解，现在对于表头关系、无线表格的分割以及表格的合并跨页等方式，会对解析造成非常大的困难。

最后，像一些多模态的数据，如图像内容或者一些数据的统计结果等，传统上依赖OCR进行解析，如果是复杂的柱状图、折线图，也非常难以处理。

在这三个方面，使用对话机器人和知识库问答对于文档复杂场景的解决方案我们也基本构建完成。

无论是PPT、表格还是多模态数据，我们都结合了非常多其他的能力，比如VL能力、规则解析以及OCR。我们会把原先已有的和当前更好的一些技术结合起来，整体输出结果。输出后，我们会对多路输出的结果进行解析和融合，最终给出一个相对更合理的结果。

03

知识问答实践案例分享

对于产品本身支持的一些能力，当前我们也有了非常好的实践效果，接下来分享一些相关案例。

以政务领域为例，首先我们需要理解我们要服务的客户属于什么行业，客户的用户群体是怎样的，他们的期待又是什么。

政务领域的对话问答机器人方面，在线链路中包括用户输入后经过Rewrite模块，接着是检索模块、排序模块，最后是Prompting，然后由大模型进行生成。对于政务来说，其离线方案是先收集政务数据，整理并结构化出来，进行Embedding解析切分，最后挑选海量高质量的数据来进行专属大模型的设计

众所周知，政务有政府官网、工作规范、内部很多政策文件库以及客服的知识库，还有工单信箱、一网统管事项库等。政府有非常多的数据来源，这些数据具有量多、内容杂、专业性强的特点。仅一个事项库的知识就可以理解为有上十万、百万的数据量。

另外，知识库复杂度也很高，不仅在事项库的理解上，还在政策文件、事项办理等不同数据上存在关系。比如，你的事项库是什么，对应的政策文件是什么，办理方式是什么……虽然数据来源不同，但中间有关联，而且政策不断更新，存在不断打补丁的问题。

此外，政务要求的专业性也很强，很多时候政务问答希望给老百姓的不是随意的口头表达，而是专业、权威、标准的结果，同时又要以老百姓能听懂的方式呈现。所以，客户的诉求中涉及希望给出专业结果的同时，采用老百姓能听懂的方式。

对于我们来说，需要首先理解很多文件，会有非常多法律法规、政策文件等参考，非常复杂。基于这些问题，我们做了很多治理工作。比如，针对数据量大的情况，我们会分析业务，按优先级保留与用户相关的字段，而把一些冗余或低频的先不处理。当文件本身与主题非常相关时，我们会设置一些关键字，去除特殊符号，以提升整体检索效果。还有一些常见的问答，我们会单独建立一个QA库，以确保这部分核心业务稳定且给出的答案绝对正确。

在文档处理方面，我们也做了很多工作，比如进行分段补充层级，在文件之间建立很多关联关系，用Markdown这种多层结构的方式构建文档图谱。最后，对于一些复杂的内容，我们会进行图表转化，将其转为有利于大模型理解的格式。同时，我们还做了一些业务标签，以提高知识筛选和持续运营的便捷度，对于非常专业的词汇进行了同义词等实体处理，增强大模型对意图的理解。

以上是我们在政务领域做的众多知识处理工作，目的是为了让大模型更好地理解和使用。

有了方案、理解了需求、进行了知识处理后，下一步就是确定整个评测标准。

在我们看来，在当前大模型时代，评测标准非常重要，即如何定义什么是好、什么是不好，以及如何评估好坏。这里面有几个要素，一是评测方案，要明确目的性，包括用户各种提问都能准确回答、是否人性化、是否有亲和力等，这是需要在前期明确的部分，然后转化为评价维度，不能主观地说回答是否人性、是否亲和，而是要转化为具体的评价维度。比如单轮对话的满意度如何给出，多轮对话又如何衡量。

同样的，构建评测集也非常重要，包括采样的来源、多样性和覆盖率等。因为今天的数据来源很广，未来服务的群体也很广，所以需要考虑服务人群的多样性和数据本身的多样性，最重要的是用户的提问方式和问题类型，要更全面地覆盖，这样的评测集才相对更客观，能更好地拟合未来上线的需要。

最后是标注和统计，标注时可能会根据大模型给出的期望结果给出标注结果和统计指标，最后确定达到什么样的情况可以上线。有了评测标准之后，接下来就是直接实施。实施过程的第一个环节，由于我们有现成产品，所以在知识方面需要前期做很多处理。处理完后，进行知识配置，包括文档导入、设计创客规则，如果有语料也可以进行增强。

对于Prompt的配置也值得关注，因为大模型输出结果的好坏很大程度上受Prompt的影响。这里涉及到机器人的人设、要完成的事情、使用的工具、输出要求等。相当于需要清楚理解今天机器人的定位、人设定位、服务群体，明确要回答什么、不能回答什么，过程中是否需要使用特定工具或调用具体接口查询问题，最后输出时要用什么样的格式等。这里需要非常详细地列出整体需求。

关于问题排查。一个问题的处理必然是先观察现象，然后进行定位，最后排查出原因。如今知识库的整个问答体系链路较长，其中包含几个主要环节，首先是解析，其次是改写，也就是对输入进行解析后进行改写；接着是召回、排序，最后是生成。所以在每个环节都需要进行一定的定位，这是一个正向的链路流程。

如果要排查问题，那就需从后往前进行。一旦结果不符合预期，先查看生成环节的问题排查，先看Prompt，检查其拼接结果中是否召回了正确答案，答案是否有缺失。如果答案没有缺失但答非所问，那就说明是大模型本身在生成环节出现问题。但如果在Prompt拼接的召回片段中没有答案，那就说明需要再往前看排序环节是否有问题，答案是否没有排在靠前位置。如果排序正常，那就继续往前查看是否有召回，也许根本就没有召回。就这样一层一层往前排查，确定是哪个环节出了问题，然后进行解决。

最后，在问题定位之后，我们在整个方案上有几个方面。

一方面是在业务策略上可以制定很多方案，比如进行文档的增删改查，这是业务本身需要做的。筛选出一些优质的对话示例让大模型学习，区分不同的Agent来处理不同的业务，使单个Agent能力更强、更聚焦，或者在业务上进行分层，区分不同渠道并绑定不同知识库，使知识更纯粹而不会相互缠绕等。这些是在业务策略上可以采取的措施。

另一方面，在工程链路上也可以做很多工作。最后，在算法上也可以进行一些调优。

接下来简单介绍几个客户场景。

在一些头部游戏客服场景中，利用大模型解答玩家问题，减少客服部门的工作。目前来看，测试准确性基本在90%及以上左右。

在某AI教育智能硬件上，我们也在进行知识库问答的应用。通过百炼的Rag知识库构建，面向儿童设定中国古代故事的人设，以拟人的方式给孩子讲述经典故事，孩子也会与之交互，它也会输出孩子关心的结果，整体调用量级非常大。

然后是汽车车书问答，汽车有非常多的型号、参数等，是非常典型的知识文档。我们也实现了汽车知识问答的Agent，目前整体效果非常不错。

最后，在当前直播非常多的零售行业，我们也做了很多商品搜索推荐。在这里，我们通过用户的Query召回用户需求的商品列表，方便主播后台的客服人员进行商品推荐。

以上是本次知识库问答的应用与实践的相关分享。