重要!搭建 Bot 的思路
最新更新:2024-07-01

重要!搭建 Bot 的思路

GPTBots 是一款 AI 应用(Bot)开发平台,您可以在这里根据您的需求,以无代码的方式,创造出任何专属于您的 Bot。

GPTBots 功能简单,易于上手,因此,对于用户来说,最大的阻碍在于——如何创造出符合自己需求的可用的 Bot?

因此,思路是最重要的。

本文将引导您一步一步思考,并搭建出属于自己的 Bot。

思路

设计 Bot 和设计产品的大体思路是一致的。

但我们建议,把 Bot 当做一个人类来看待,这样有助于我们更好地将现实生活中待解决的问题投射到 Bot 上,让 Bot 解决。

场景

首先,需要确定场景,即我们希望这个 Bot 能解决哪些问题?

我们一般用「5W1H」来描述一个场景:

在什么地方(Where),什么时间(When),谁(Who),因为什么原因(Why),用什么方式(How),要做什么事情(What)。

例如:

在家中(Where),网购时(When),买家(Who),因为不懂如何退货(Why),想要打电话(How),咨询网店客服(What)。

这是一个典型的电商客服的用户场景。

我们可以以此为参照,为 Bot 列出多个场景,例如:

  • 不懂如何退货
  • 不懂如何退款
  • 不懂如何换货
  • 不懂如何投诉
  • 商品的使用方法
  • 平台的其他联系方式
  • ……

一般来说,我们不推荐让一个 Bot 解决太广的问题。Bot 的场景越是垂直或集中,它越是能够有效地解决问题。

和人类一样,需要「术业有专攻」。

在上述例子中,列举出来的例子均是与「电商客服」相关的场景,一个电商客服人员的形象就很立体地被树立起来了。

同时,我们就最好不要把诸如「贷款推荐、商品推荐」等与「电商客服」无关的场景放到该 Bot 中。

定位

在列举出场景后,我们可以对该 Bot 有一个清晰的定位。

在上述例子中,它就是一个「电商客服」Bot,可以为用户回答电商平台的一些问题,也可以为用户处理诸如退换货之类的一些任务。

资源

在定位清晰后,我们需要开始准备搭建该 Bot 所需要使用的一些资源,主要包括两类:知识、工具

知识

知识,顾名思义,即 Bot 需要学习和了解的东西,通常是一些文档。

即使是人类,在处理工作事务时,也需要先学习对应的业务知识,才能处理。Bot 也一样。

Bot 会根据知识,来响应用户的问题。

例如,某电商平台的退货、换货的流程,如果这些知识不提供给 Bot,那么 Bot 是不知道该如何回答的,极端情况下甚至会产生「幻觉」而胡乱回答。

您需要根据 Bot 的场景和定位,来准备这些知识文档。

例如,您希望 Bot 能够回答电商平台关于退货、换货的问题,那么就需要准备电商平台关于退换货的规章制度的相关文档。

工具

工具,即 Bot 执行任务所需要的工具,

对于 Bot 来说,工具其实就是「API」。将 API 提供给 Bot 作为工具,Bot 会在合适的时候调用 API,并执行某些任务。

例如,某电商平台的用户想要退货,Bot 开发者可以将退货的 API 提供给 Bot,Bot 就可以在用户想要退货时调用该 API,直接为用户完成退货流程。

您需要根据 Bot 的场景和定位,来准备这些工具(API),例如退货 API,换货 API,提交工单 API 等。

设计

在思路理清,并将资源准备妥当后,我们可以进入正式的 Bot 的设计环节。

身份提示:为 Bot 定位

image-20240702183619107

撰写一个合理的身份提示,是打造一个优秀 Bot 的第一步。

在身份提示中,我们需要为 Bot 定义它的角色、技能、任务、限制等,让它明确自己的职责,以让它表现更佳。

阅读:如何撰写高效且强大的身份提示

上下文分配:让 Bot 在有限的空间内处理合适的信息

image-20240702183704628

Bot 是基于大语言模型(LLM)的,而 LLM 的上下文长度则代表着它能够处理的信息量,该长度是有限的。

就像不同的人阅读文章的能力一样,有些人可以在短时间内阅读大量文章,依然能够对文章的内容和信息进行理解和处理,但有些人只能在相同的时间内阅读很少量的文章,甚至都无法处理。

LLM 的上下文长度,就和人类短时间内可阅读并处理的文章量是类似的道理。

因此,在有限的上下文内,为 LLM 提供合适的信息,并尽可能不提供无效的信息,更能有助于 LLM 输出更好的结果。

阅读:如何合理地分配 LLM 上下文

知识库:让 Bot 学会知识

image-20240702183726588

在知识库中,将您准备好的知识文档上传进去,使之成为 Bot 的知识。如此一来,当用户提出问题时,Bot 会先使用用户的提问到知识库内进行检索,找出与问题语义相关的文档内容作为参考,再交由 LLM 进行总结,并给用户回答。

但是,往 Bot 知识库内上传知识文档,并不一定是最好的使用知识的方式,这与 RAG 框架以及 LLM 的任务处理方式有关。您可以参考这篇文章,设计出最适合您的场景的方式:

阅读:如何操作知识库

工具:让 Bot 能够执行任务

image-20240702183808305

在 Tools 模块,您可以将您准备好的 API 包装为 Tool,并添加到 Bot 内,让 Bot 具备执行这些 API 的能力。

阅读:如何创建 Tools

同时,GPTBots 官方也提供了大量的开箱即用的 OpenTools,您也可以根据自己的需求直接添加到 Bot 内使用,不需要自己再二次开发。

Flow:流程复杂的 Bot 可用

image-20240702183843845

如果您要设计的 Bot 逻辑较为复杂,涉及众多的步骤、流程或条件判断,那么 Flow 将会是一个很好的选择,它可以让您在画布中,通过拖拉拽的方式,自由搭配 Bot 的工作流。

阅读:关于 Flow

记忆:让 Bot 能够持续处理任务

image-20240702184900746

就和人与人之间的聊天一样,我们需要知道刚才我们聊了什么,才能延续之前的话题,继续往下聊。

Bot 的记忆也是如此。

您可以根据 Bot 服务的场景来判断是否需要使用记忆,以及如何使用。例如:

  • 若涉及需要非常多轮对话才能解决问题的 Bot(如:深度问题探讨),则可以开启「长期记忆」;
  • 若寥寥数轮对话即可解决问题的 Bot(如:在线咨询),则仅开启「短期记忆」即可,无需「长期记忆」;
  • 若 Bot 的主要任务是可一次性生成的(如:邮件撰写),则无需开启任何记忆。

image-20240702184917989

同时,您也可以将用户属性提供给 Bot 作为记忆,让 Bot 能够了解用户的一些信息,以让 Bot 为用户提供更佳的个性化服务。

image-20240702190038187

例如,对于一个酒店的客房服务 Bot,当 Bot 与房客对话时,Bot 必定已经通过用户属性了解到了用户的名字、房间号等,因此,若此时房客通过 Bot 申请订餐上门时,Bot 不必再次询问房客的名字和房间号,只需要询问房客需要什么样的服务即可,因为 Bot 知道要把餐送到哪个房间里。

阅读:关于记忆和用户属性

发布使用:Bot 被使用的地方

您可以根据您用户的具体使用场景,来评估 Bot 需要被集成至何处以服务用户。

用户在哪里,就集成至哪里。

阅读:Bot 集成

案例

如果您阅读完以上内容后,依然不太明白 Bot 应该如何设计,我们也为您准备了丰富的例子。

image-20240702192402047

您只需要在创建 Bot 时,选择任意一个模板进行创建,您就可以得到一个 Bot。您可以参考模板已经设定好的参数,来进一步了解和思考 Bot 如何设计。这是一个非常好的学习方式。