当前位置:   article > 正文

谈面向任务的多轮对话系统(TOD)_任务型多轮对话

任务型多轮对话

        面向任务对话系统(Task-Oriented Dialogue (TOD) Systems)主要是为解决特定任务的,比如订票任务(订机票,电影票等),预定饭店等。这种对话往往需要多轮对话才能够完成。

多轮对话的例子

客户预定一个餐厅的过程:

  1. 用户:我要定一个餐厅
  2.     LLM: 请问你喜欢什么风格的餐厅?
  3.    用户  :无锡本帮菜
  4.    LLM:请问有几个人参加?
  5.    用户:5个人
  6.    LLM:你的预算是多少?
  7.   用户:人均150元
  8.   LLM:你预定的用餐时间?
  9.   用户:明天晚上6点
  10.   LLM: 根据你的邀请,我推荐XYZ 餐厅。。。。需要帮你预定么?
  11.   用户:好的
  12.   LLM:亲爱的用户,我已经帮预定好了XYZ 餐厅,祝你用餐愉快

      大语言模型出现之后,感觉实现实现这种系统比较简单了,但是深入思考后发现,这是一项富有挑战的工作。本文研究相关的问题与部分实验。

   我们将具有多轮会话的系统成为DiagGPT。

ChatGPT 与DiagGPT 的区别 

        

         ChatGPT 和 DiagGPT 之间的主要区别。ChatGPT直接回答用户问题,而DiagGPT不仅提供同等质量的答案,还具有主动提问、引导用户、内部保持对话状态的能力。  

        LLM 的一个流行应用是聊天机器人,它围绕这些模型构建对话系统。ChatGPT的1是此类应用程序的一个成功示例,其中 LLM 能够根据从大量训练数据中获得的知识分析上下文并响应用户查询。通过补充其背景知识并提供上下文和适当的提示,ChatGPT 已经能够为专业领域形成强大的问答模型。它可以理解用户的问题并有效地提供准确的答案。

        然而,我们日常生活中的对话场景可能更加复杂。例如,在法律或医疗诊断等专业咨询场景中,聊天代理需要考虑用户的独特情况或信息。在获取用户信息的过程中,座席提供的交互体验也是至关重要的。系统需要主动提出问题。因此,我们需要聊天代理的咨询过程,以更好地模拟真正的医学专家和法律专业人士。聊天代理应进行问答、主题管理,并引导用户实现特定目标或任务完成。这种类型的对话被称为面向任务的对话 (TOD)。对话中通常有一些预定义的目标。TOD帮助用户实现其特定目标,专注于了解用户、跟踪状态并生成后续操作。它与轻度对话或开放领域对话场景有很大不同。

        尽管在这一领域进行了大量研究,但由于缺乏训练数据、效率低下以及微调小型模型的缺点(包括无法完全理解用户含义和生成性能差)等问题,它仍然具有挑战性。关于该主题的现有研究模型并不稳健和通用。例如,微调模型需要大量数据进行训练,并且难以转移到其他场景。另一方面,尽管LLM拥有广泛的知识范围,其答案的质量也远远超出了微调模型,但传统的LLM已经不能满足TOD的需求,无法有效地管理复杂的对话逻辑。因为它们保持着简单的记忆,只能处理线性的交互。

DiagGPT的两种主要的方法

  •     端对端(End to End) 方式
  •     管道方式
  •     Function Call
  •    多Agent 方式

我们采取的方式

     基于我们正在研究的基于功能块的Agent 构建方法,我们采取了功能块方法实现面向任务的TOD 系统。具体方法如下:

 确定对话的任务目标(Goal)

      对于面向任务的对话而言,对话的主题是预先定义的(Predefined Goal)比如系统能够完成

  •     预约餐厅
  •    预约机票
  •    预约就医
  •    购买商品
  •    定外卖
  • 家庭自动化
  • 工厂自动化

        

     由于这些任务都需要在IT 系统的支持下完成,例如预约餐厅,机票,医院,购物平台的App 支持下完成的。所以这些目标应该是预先定义的。

Agent结构

目标Agent (Goal Agent)

     确定用户的请求要完成的目的。

任务Agent

     完成某一项单一任务的Agent。

目标Agent和任务Agent 支持多轮对话。

主题 Topic

     对于每个目标任务而言,需要提供一系列信息才可能完成。用户请求完成这些任务时不一定一次性提供所有的信息,这就需要多轮对话才能够补齐。这些信息称为对话的主题。

例如 预定餐厅的主题包括:

  1.      地理位置
  2.      餐馆的风格
  3.      就餐时间
  4.      就餐人数
  5.      预算 

    每个任务Agent 功能块中应该定义 Topic 列表。

状态机

  对于多轮对话而言,Agent 内部需要保留对话的记录。因此,Agent 功能块内部需要维持一个状态机。主要的状态

     初始状态 Status=0

    对话状态 Status=1

    确认状态 Status=2

   

当前主题

 当前对话的主题。

 主题队列(FIFO)

内部保留一个主题队列,主题队列的格式

  1. {
  2. "topic":"对话的主题",
  3. "Description":"主题的描述“
  4. "message":"对话信息"
  5. }

 处理的流程

      初始状态时,收到任务请求时,将主题列表复制到主题队列中。并将状态改为“对话”,如果用户输入的消息中已经包含了某些主题的信息,就将用户的信息直接填写到主题队列的主题中。

例如:请帮助我定一张 5月5日 常州飞沈阳的机票。

这个用户信息中已经包含了下面几个Topic

  1.    出发地
  2.    目的地
  3.    日期

基于功能块的实现

我们使用功能块实现Agent,由功能块与连接构成功能块网络。功能块网络描述了Agent 的互操作关系,表达了AI的思维链。

   关于功能块的研究见我写的博客:

        谈大语言模型动态思维流编排-CSDN博客

 在本项目中,我们使用了如下几个功能块

  •     InMessage
  •    Goal 
  •   Restaurant
  • OutMessage

        Goal 和Restaurant 功能块内部都维护一个状态,当Goal 和Restaurant功能块接收到一个任务请求后,将状态转换为Dialog 模式。当Restaurant完成对话后,发送DIalogFinish 事件给Goal ,使Goal 的状态返回初始状态。

初步实验

结论

         简单地依赖大模型实现面向任务的多轮对话系统,效果很差,无法确定地进行多轮对话完成任务,而使用多Agent 系统实现TOD 效果更好。我们提出了基于功能块的多Agent 架构能够灵活地实现多Agent 协作。本文讨论的TOD 系统的实现,再一次证明了功能块的Agent 的能力。

         事实上,功能块网络是一个分布式系统架构。Agent 能够部署在不同的地方。例如 Restaurant功能块能够作为一个独立的App 部署在云端。

       我们相信,源自于工业自动化领域的功能块能够成为构建分布式AI Agent 的建模语言。我们将进一步探讨如何将Agent 功能块技术建立分布式 Agent 技术标准。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家自动化/article/detail/1017842
推荐阅读
相关标签
  

闽ICP备14008679号