这是第一个 AI 助手与真实客户的对话，客户提出了一个 Rasa 无法回答的问题。因此，GPT-3.5 并没有使用预定义的答案进行回复，而是进行了尝试：
第一个客户与人工智能的聊天。
初步结果看起来很有希望：Rasa 在流程描述良好的情况下表现出色，而 GPT-3.5 接管了一些后备请求。
我们决定采用这种方法，并尽可能多地涵盖 Rasa 上的新流程、意图和规则。当时，我们的主要目标是针对最频繁的客户端查询进行第一次迭代。
转向仅 LLM 解决方案的原因
到 2023 年 9 月，聊天助手已全面投入运营，其处理的查询数量呈指数级增长：
由人工智能聊天机器人处理的对话
然而，我们很快意识到，我们的聊天助手流程严格，不够灵活，无法真正理解客户的需求。它完全回答了大约 20% 的对话，其余的则交给了我们的客户成功团队。
正如第一次回访对话所示，LLM 理解了请求并与客户进行了很好的沟通。问题是它只提供了一般性信息。
从而减轻客户成功团队的负担。为了实现这一目标，我们需要创建更多流程，并减少 LLM 因缺乏知识而提供的不准确答案。
总体而言，Rasa 扮演了更技术性的角色，引导 LLM 朝着正确的方向完成大部分工作。放弃 Rasa 意味着重新思考助手的原理和逻辑，但这并不意味着从头开始构建聊天助手——我们需要改变引擎，而不是整辆车。
Rasa 非常适合小型、确定性路径，因为它具有许多适应和定制可能性。然而，由于我们操作的深度和复杂性，它对我们来说并不是正确的解决方案。
部署基于 LLM 的聊天助手
现在我们已经告诉了您背景以及为什么我们决定使 电报粉 用仅限 LLM 的解决方案，让我们进入有趣的部分：我们构建了什么以及它是如何工作的。
这是我们的客户成功中的AI助手架构的简化图：
Kodee 的建筑。
以下是基于法学硕士的聊天助手（现称为 Kodee）的工作流程：
用户向我们的助手发送一条消息
切换分类器确定客户端是否想要与现场代理交谈。
如果用户只有一项服务，系统会将消息转发给基于 LLM 的代 可读性虽然人工智能工具可以帮 路由器或特定助手。
代理路由器对消息进行分类并决定哪个AI 代理应该处理聊天。
AI 代理处理输入消息以生成初始 选择加入列表 响应。它可以是对用户的响应，也可以是调用额外功能的要求。
根据输入或初始响应，LLM 确定是否需要我们希望人工智能能 调用任何外部或内部函数来收集信息或执行操作。这些函数包括：
调用外部 API获取数据。