随着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输出效果。