avatar

Jacob Morrow

2023-10-20 15:34:54

2753 浏览, 5 min 阅读

随着LLM(大语言模型)的爆火,不少企业都在寻找通过LLM解决企业业务问题的方法,以达到降本增效的效果。但是,当面对较为复杂的业务问题(如:背景资料多、问题分类多、条件判断复杂、涉及模块多等)时,以LLM当前的发展程度,仅通过简单的LLM对话交互,是无法有效地解决此类问题的,原因在于,LLM也有自身的能力限制,如幻觉、上下文等。

由极光(Aurora)开发的GPTBots平台,为解决此类问题,打造了“Flow”形态的Bot搭建模式。该模式可将复杂的业务问题简单化,通过“Flow”的方式,将复杂多变的业务问题简化并抽象为多个“节点”和“流程”,并通过可视化编排 workflow方式,让多个专职LLM并行/串行工作,各司其职,从而快速地搭建起一个Bot,并立即应用于实际业务问题场景中。

本文将以搭建一个简单的“售后服务Bot”为目标,为您讲述“Flow”的实际应用过程。

找出问题,定义目标

设计一个Bot,和设计一款产品是一样的,首先需要定义该Bot需要解决的问题是什么,并定义出这个Bot的目标。

在本例中,我们需要解决的是售后服务问题。原有的售后服务,可能会包括(但不限于):

  • 咨询量大,需要投入大量的人力资源在其中;
  • 咨询的内容很广,意味着对客服人员的知识量要求较高;
  • ……

如果有一个专门解决售后咨询问题的Bot,那么就可以帮助企业提升售后服务效率的同时,降低售后服务的成本(人力、时间、管理资源……)。

业务梳理

在定义好问题和目标后,我们需要根据实际的业务场景,先规划好Bot的流程。

在该例子中,我们可以设计出这样的一个简单的售后问题处理流程:

  • 当客户提问关于保障服务(Support Service)相关问题时,则Bot基于《保障服务》文档知识,为客户解答;
  • 当客户提问是关于退货(Returns)时,则Bot基于《退货》文档的知识,为客户解答;
  • 当客户想要查询快递进度(Express Tracking)时,则Bot调用预定义好的快递查询插件,并为客户返回结果;
  • 当客户提出关于退款(Refund)的请求时,由于该业务涉及资金流动,较为敏感,因此我们选择让Bot调用预定义好的退款处理插件,为客户执行退款,并返回结果;
  • 当客户提问不属于以上任意一种类型时,我们设置一个默认回复信息给客户,例如可以让客户通过某种联系方式联系人工客服。

当然,在真实的企业售后服务中,远远不止这五种场景。企业开发者可根据实际情况设计Bot。

知识分类

在定义业务流程后,我们需要为该Bot准备售后知识数据。原因在于,既然是一个售后Bot,则这个Bot必须要熟知公司在售后服务上的所有知识,才能依照知识,对客户的问题进行合理的响应。

在准备Bot知识时,最重要的思维则是“分类”。

在售后服务场景中,售后服务人员会遇到很多不同的问题,例如可以退货吗?退货进度在哪里看?可以换货吗?怎么换?退款的话要多久能回到我的账户?快递配送到哪了?等等问题。

以上图为例,我们可以将前文业务梳理结果中涉及问答的部分,即保障服务和退货场景中的常见需要进行问答的场景进行分类,并且基于这些分类,来组织知识文档。例如《保障服务》、《退货》。

清晰的知识分类,有助于Bot对知识的学习和理解,并能在面对客户咨询时提供更加准确的回答。

Bot设计

FlowBot创建

在完成了知识组织和流程规划后,我们可以正式进入GPTBots平台,进行FlowBot的搭建。

在【FlowBot】模块中,先创建好一个售后服务Bot,并进入设置界面。

知识学习

在【知识库】模块中,分别将之前已经组织好的《保障服务》和《退货》文档提交给Bot进行学习和训练。GPTBots平台提供了多种类型的知识上传方式。

在本例中,我们选择了“Q&A”作为知识文档的管理格式。这是一种以“问答对(Q&A Pair)”为基本单位的知识储存格式。当客户提出了和其中某些问题(Q)语义相似的问题时,Bot可以迅速找到对应答案(A),并经过LLM组织语言后,给客户解答。

Flow设计

在配置好知识文档后,我们可以开始进入到Flow的设计环节中。

通过【编辑】进入Flow的可视化编辑界面。

每一个Flow都是由三个基本元素构成的:

  • 输入(Input):即客户的输入信息;
  • 输出(Output):即经过一系列Flow处理后,为输出给客户作为响应的信息;
  • 组件(Component):各类数据处理组件,包括了LLM、知识检索、条件判断和预置响应等。

场景判断

按照我们之前对业务流程的规划,在客户提出问题后,我们需要先对客户的问题进行判断,并根据客户的问题分类,进入对应的响应流程。

因此,Flow设计的第一步,就是将【输入】的下一步设置为一个【分支判断】组件,并通过自然语言设置【退款】、【物流】和【退货】等分支。

通过这个组件,Bot会根据客户提问内容判断下一步应该往哪个流程继续下去。

知识问答:退货、保障服务

以【退货】为例。若客户提问被判断为退货,则下一步需要做的,就是为客户的提问,从知识文档中,寻找合适的回答内容。

我们可以在此添加一个【知识向量】组件,并将【分支判断】中的【退货】连接至此。在【知识向量】中,我们选择之前已经上传并训练好的《退货》文档,作为本组件的知识检索材料。

由于【知识向量】组件检索出来的结果,都是较为“生硬”的知识片段,是不能直接用于回复客户的,因此我们需要在下一步,将客户提问与知识检索结果提供给LLM,让LLM基于这些信息进行理解、分析,并最终组织出一个合适的回答。

最后,将LLM的输出信息连接至【输出】组件,完成整个的流程。以上流程放在【保障服务】分支中,也是可以复用同样的设计思路。

插件调用:快递查询、退款

当客户的请求被判定为需要查询快递进度时,我们可以设置一个LLM组件,并为该组件添加【快递查询】插件。

LLM将从客户的请求内容中提取需要查询快递的订单号,并通过调用插件,为客户返回该订单号的物流进度。

同样地,若LLM从客户的请求中识别出了【退款】意图,则会指引客户提供必须信息,并帮助客户通过插件,向系统提交请求,执行退款流程。

预置相应:其他

最后,我们需要补充一个“兜底”分支。当客户问题不属于【分支判断】中设定的任意分支时,我们通过【预置响应】组件,设定一个通用的回复信息,让客户直接联系企业客服人员,以进一步人工解决问题。

Flow总览

经过上述一系列操作后,记得【保存】,这个简单的“售后服务Bot”就搭建完成了。

Flow验证

在【保存】之后,我们可以通过【运行】或【对话】,直接测试Bot的回复效果。

在【输入】组件中,输入客户提问内容,并点击【运行】,界面上就会以虚线的形式,展示出该问题的数据流转路径,并在最终的【输出】组件中,可以看到最终的输出结果。

同样,也可以通过【对话】,直接以对话的形式,验证Bot输出效果。