转向仅 LLM 解决方案的原因

[arzina221]

为此，我们使用了 OpenAI 的生成式预训练 Transformer (GPT) 。这是一个通用的 GPT-3.5 模型；我们最初没有对其进行微调或训练。

大约一个月后，我们的虚拟代理已准备好进行现场测试。我们迫切想知道法学硕士课程的成绩如何。

这是第一个 AI 助手与真实客户的对话，客户提出了一个 Rasa 无法回答的问题。因此，GPT-3.5 并没有使用预定义的答案进行回复，而是进行了尝试：

第一个客户与人工智能的聊天。
初步结果看起来很有希望：Rasa 在流程描述良好的情况下表现出色，而 GPT-3.5 接管了一些后备请求。

我们决定采用这种方法，并在 Rasa 上涵盖尽可能多的新流程、意图和规则。当时，我们的主要目标是针对最频繁的客户端查询进行第一次迭代。

到 2023 年 9 月，聊天助手已全面投入运营，其处理的查询数量呈指数级增长：

由人工智能聊天机器人处理的对话。
然而，我们很快意识到，我们的聊天助手流程严格，不够灵活，无法真正理解客户的需求。它完全回答了大约 20% 的对话，其余的则交给了我们的客户成功团队。

正如第一次回访对话所示，LLM 理解了请求并与客户进行了很好的沟通。问题是它只提供了一般性信息。

我们希望人工智能能够为客户提供更多指导 Office 365 电子邮件地址数据 和实际数据，从而减轻客户成功团队的负担。为了实现这一目标，我们需要创建更多流程，并减少 LLM 因缺乏知识而提供的不准确答案。

总体而言，Rasa 扮演了更技术性的角色，引导 LLM 朝着正确的方向完成大部分工作。放弃 Rasa 意味着重新思考助手的原理和逻辑，但这并不意味着从头开始构建聊天助手——我们需要改变引擎，而不是整辆车。

Rasa 非常适合小型、确定性路径，因为它具有许多适应和定制可能性。然而，由于我们操作的深度和复杂性，它对我们来说并不是正确的解决方案。

部署基于 LLM 的聊天助手
现在我们已经告诉了您背景以及为什么我们决定使用仅限 LLM 的解决方案，让我们进入有趣的部分：我们构建了什么以及它是如何工作的。