的代码库同时增强了聊天机器

[email protected]

我们对助手的第二个实验试图为常见的支持问题提供自助服务。助理不会提出问题并转至支持队列而是引导用户完成解决问题的过程。 当我们启动第二个实验时新的提示已膨胀到超过 个令牌导致环境成本很高并且在长时间的对话中偶尔会超出令牌限制。当我们纳入新的说明和上下文时提示的准确性也下降了。随着我们通过将相关文章和内容合并到提示中来引入检索增强生成 内存管理变得越来越重要。本质上我们遵循了大型提示方法——创建一个提示来满足所有用户交互。 我们很快意识到过渡到面向任务的提示可以在复杂的对话流程中实现更高的效率。面向任务的提示专注于单个任务例如收集咖啡订单使作者能够用更少的标记给出简洁的说明从而提高准确性。






作者还可以控制输出（针对特定响应进行微调）因为可行答案的范围要小得多。然而 日本手机号码数据 面向任务的提示的特殊性意味着它们不适合一般的开放式的对话。我们需要在两种策略之间取得平衡。 在我们合并这两种方法的实验中我们在聊天流程的关键转换处使用了面向任务的提示。例如当用户需要转移到人工代理时我们将执行一项任务来提取重要信息为人工代理提供摘要。在其他场景中我们将运行搜索将结果注入对话中作为提示的上下文。 我们最早混合这两种策略的尝试有些僵化很大程度上依赖于确定性代码来决定何时将对话引导至特定提示。随着我们的方法日趋成熟我们从  的多代理工作（特别是  论文）中获得了灵感。该团队将重点转向使用控制器委托模式构建多提示架构其中大型提







示充当控制器将对话传递给面向任务的提示（委托）。 我们的多代理实验的初步结果是有希望的。允许控制器提示确定何时委托给另一个提示简化了我们人的功能。虽然我们的实施还处于早期阶段但这种类型的提示架构将变得普遍直到模型变得更加精确并且大上下文模型的成本降低。 小心结构化输出 人工智能机器人的纯文本响应非常适合聊天场景但对于围绕人工智能分析构建的系统来说可能效率较低。应根据需要从  模型请求结构化响应例如  或代码。包括  功能在内的一些模型已经具有生成结构化输出的集成功能。 然而验证输出的响应至关重要。在引入功能之前我们对   的初步试验提出了重大的可靠性挑战。我们构建了一