谈面向任务的多轮对话系统（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）

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

{
"topic":"对话的主题",
"Description":"主题的描述“
"message":"对话信息"
}

 处理的流程

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

例如：请帮助我定一张 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 技术标准。