HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face
Status: Reading
Author: Dongsheng Li, Kaitao Song, Weiming Lu, Xu Tan, Yongliang Shen, Yueting Zhuang
Institution: 微软亚洲研究院(Microsoft Research Asia), 浙江大学(Zhejiang University)
Publisher: NeurIPS
Publishing/Release Date: December 3, 2023
Summary: 解决不同领域和多种模态的复杂任务是通往AGI的关键,尽管现在有各种各样的AI模型,但是它们没有办法自主地处理复杂任务,而LLMs恰好可以作为管理者控制现有的AI模型来完成任务。本文提出的HuggingGPT就是一个基于ChatGPT的Agent,可以利用HuggingFace上各种各样的AI模型来完成任务。首先通过ChatGPT根据用户的请求制定任务计划,然后根据HuggingFace上模型的功能描述选择可用的AI模型,之后通过这些模型来执行子任务,最后总结执行结果并给出响应。HuggingGPT可以解决跨领域跨模态的各种AI任务,在语言、视觉、语音等任务中都取得很好的效果。
Type: Paper
链接: https://arxiv.org/abs/2303.17580
代码是否开源: 开源
代码链接: https://github.com/microsoft/JARVIS
读前先问
带着问题读论文,边读边回答。
- 大方向的任务是什么?Task
Agent
- 这个方向有什么问题?是什么类型的问题?Type
虽然AI模型众多,但是不能互相配合。
- 为什么会有这个问题?Why
没有一个大脑作为指挥。
- 作者是怎么解决这个问题的?How
将ChatGPT作为大脑来指挥各种AI模型。
-
怎么验证解决方案是否有效?
-
实验结果怎么样?What(重点关注有没有解决问题,而不是效果有多好)
论文精读
引言
目前的LLM技术尚不完善,在构建先进的AI系统的道路上面临着一些紧迫的挑战:
- 受限于文本生成的输入输出形式,目前的LLM缺乏处理视觉、语音等复杂信息的能力;
- 在现实场景中,一些复杂的任务通常由多个子任务组成,因此需要多个模型的调度和协作,这也超出了语言模型的能力;
- 对于一些具有挑战性的任务,LLM在Zero-Shot或Few-Shot设置中表现出出色的结果,但仍然弱于一些专家。
作者认为,为了处理复杂的AI任务,LLM应该能够与外部模型协调以利用它们的力量。关键问题是如何选择合适的中间件来桥接LLM和AI模型之间的联系,LLM恰好可以完成这个工作。将各种AI模型的描述融入到提示词中,LLM可以作为管理规划、调度、合作等这些AI模型的大脑。
在这篇论文中,作者提出了一种名为 HuggingGPT 的由 LLM 驱动的 Agent,可以自主处理各种复杂的 AI 任务,它连接了 LLM(即 ChatGPT)和 ML 社区(即 Hugging Face),并且可以处理来自不同模式的输入。更具体地说,LLM充当大脑:一方面根据用户请求拆解任务,另一方面根据模型描述为任务分配合适的模型。通过执行模型并将结果集成到计划任务中,HuggingGPT 可以自主满足复杂的用户请求。
HuggingGPT 的工作流如下图所示,可以分为四个阶段:
- 任务规划:使用ChatGPT分析用户的请求,了解他们的意图,并将其分解为可能的可解决的任务。
- 模型选择:ChatGPT 根据模型描述选择托管在 Hugging Face 上的专家模型。
- 任务执行:调用并执行每个选定的模型,并将结果返回给ChatGPT。
- 响应生成:ChatGPT 集成所有模型的预测结果并为用户生成响应。
HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face
Status: Reading
Author: Dongsheng Li, Kaitao Song, Weiming Lu, Xu Tan, Yongliang Shen, Yueting Zhuang
Institution: 微软亚洲研究院(Microsoft Research Asia), 浙江大学(Zhejiang University)
Publisher: NeurIPS
Publishing/Release Date: December 3, 2023
Summary: 解决不同领域和多种模态的复杂任务是通往AGI的关键,尽管现在有各种各样的AI模型,但是它们没有办法自主地处理复杂任务,而LLMs恰好可以作为管理者控制现有的AI模型来完成任务。本文提出的HuggingGPT就是一个基于ChatGPT的Agent,可以利用HuggingFace上各种各样的AI模型来完成任务。首先通过ChatGPT根据用户的请求制定任务计划,然后根据HuggingFace上模型的功能描述选择可用的AI模型,之后通过这些模型来执行子任务,最后总结执行结果并给出响应。HuggingGPT可以解决跨领域跨模态的各种AI任务,在语言、视觉、语音等任务中都取得很好的效果。
Type: Paper
链接: https://arxiv.org/abs/2303.17580
代码是否开源: 开源
代码链接: https://github.com/microsoft/JARVIS
读前先问
带着问题读论文,边读边回答。
- 大方向的任务是什么?Task
Agent
- 这个方向有什么问题?是什么类型的问题?Type
虽然AI模型众多,但是不能互相配合。
- 为什么会有这个问题?Why
没有一个大脑作为指挥。
- 作者是怎么解决这个问题的?How
将ChatGPT作为大脑来指挥各种AI模型。
-
怎么验证解决方案是否有效?
-
实验结果怎么样?What(重点关注有没有解决问题,而不是效果有多好)
论文精读
引言
目前的LLM技术尚不完善,在构建先进的AI系统的道路上面临着一些紧迫的挑战:
- 受限于文本生成的输入输出形式,目前的LLM缺乏处理视觉、语音等复杂信息的能力;
- 在现实场景中,一些复杂的任务通常由多个子任务组成,因此需要多个模型的调度和协作,这也超出了语言模型的能力;
- 对于一些具有挑战性的任务,LLM在Zero-Shot或Few-Shot设置中表现出出色的结果,但仍然弱于一些专家。
作者认为,为了处理复杂的AI任务,LLM应该能够与外部模型协调以利用它们的力量。关键问题是如何选择合适的中间件来桥接LLM和AI模型之间的联系,LLM恰好可以完成这个工作。将各种AI模型的描述融入到提示词中,LLM可以作为管理规划、调度、合作等这些AI模型的大脑。
在这篇论文中,作者提出了一种名为 HuggingGPT 的由 LLM 驱动的 Agent,可以自主处理各种复杂的 AI 任务,它连接了 LLM(即 ChatGPT)和 ML 社区(即 Hugging Face),并且可以处理来自不同模式的输入。更具体地说,LLM充当大脑:一方面根据用户请求拆解任务,另一方面根据模型描述为任务分配合适的模型。通过执行模型并将结果集成到计划任务中,HuggingGPT 可以自主满足复杂的用户请求。
HuggingGPT 的工作流如下图所示,可以分为四个阶段:
- 任务规划:使用ChatGPT分析用户的请求,了解他们的意图,并将其分解为可能的可解决的任务。
- 模型选择:ChatGPT 根据模型描述选择托管在 Hugging Face 上的专家模型。
- 任务执行:调用并执行每个选定的模型,并将结果返回给ChatGPT。
- 响应生成:ChatGPT 集成所有模型的预测结果并为用户生成响应。
主要贡献:
- 提出HuggingGPT,结合LLM和专家模型,通过模型间合作协议,提供设计通用AI解决方案的新方法。
- 将Hugging Face平台的任务特定模型与ChatGPT集成,处理多模态、多领域的广义AI任务,提供可靠的多模态对话服务。
- 强调任务规划和模型选择的重要性,并提出评估LLMs在这方面能力的实验方法。
- 大量跨模态和领域的实验表明,HuggingGPT在理解和解决复杂任务方面具有强大能力和巨大潜力。
方法
任务规划
任务规划模块旨在使用LLM分析用户请求,然后将其分解为结构化任务的集合,还要要求LLM确定这些分解任务的依赖关系和执行顺序,以建立它们的连接。
- 特定格式的指令:为了更好地表示用户请求并且在后续阶段使用,我们希望LLM能够输出特定格式(例如JSON)的内容,方便解析。一个任务则是由任务名称、任务ID、依赖任务和参数四部分组成。
- 为了更好地理解任务规划的意图和标准,HuggingGPT 在提示词中融入了多个例子。
任务规划阶段的提示词如下图所示,为了支持更复杂的场景(例如,多轮对话),作者在提示词中还包含了聊天日志。
任务规划的模板
python
[{
"task": task,
"id", task_id,
"dep": dependency_task_ids,
"args": {"text": text, "image": URL, "audio": URL, "video": URL}
}]
名称 | 定义 |
---|---|
task | 代表解析任务的类型,涵盖了语言、视觉、视频、音频等不同的任务。 |
id | 任务计划的唯一标识符,用于引用相关任务及其生成的资源。 |
dep | 定义了执行所需的先决任务,仅当所有先决依赖任务完成后才会启动该任务。 |
args | 包含任务执行所需参数的列表,三个子字段,根据任务类型填充文本、图像和音频资源。它们是根据用户的请求或依赖任务生成的资源来解析的。 |
支持的任务列表
模型选择
HuggingGPT 继续将任务与模型进行匹配的任务,即为解析的任务列表中的每个任务选择最合适的模型。作者使用模型描述作为连接每个模型的语言接口,从 ML 社区(例如 Hugging Face)收集专家模型的描述,然后采用动态上下文任务模型分配机制来为任务选择模型。
模型选择阶段的提示词如下图所示,将模型选择制定为单选问题,其中可用模型在给定上下文中作为选项呈现。由于最大上下文长度的限制,提示词中无法包含所有相关模型的信息。为了缓解这个问题,作者首先根据任务类型过滤模型,然后根据 Hugging Face 上的下载量对模型进行排名,选择前 K 个模型作为候选模型。
任务执行
HuggingGPT 会自动将任务参数输入到模型中,执行这些模型以获得推理结果,然后将其发送回 LLM。
由于先决任务的输出是动态生成的,HuggingGPT 还需要在启动任务之前动态指定任务的依赖资源。因此,任务执行阶段的重点是建立具有资源依赖性的任务之间的连接。
作者使用了一个唯一符号""来维护资源依赖性。具体来说,HuggingGPT 将先决任务生成的资源标识为 -task_id,其中 task_id 是先决任务的 id。在任务规划阶段,如果某些任务依赖于先前执行的任务的输出(例如,task_id),HuggingGPT 会将此符号(即 -task_id)设置为参数中相应的资源子字段。然后在任务执行阶段,HuggingGPT 动态地用先决任务生成的资源替换该符号。
其余没有任何资源依赖的任务直接并行执行,进一步提高推理效率。也就是说,如果多个任务满足先决条件依赖关系,则可以同时执行多个任务。
响应生成
HuggingGPT 在本阶段将前三个阶段(任务规划、模型选择和任务执行)的所有信息整合为一个简洁的摘要,包括规划的任务列表、任务选择的模型以及模型的推理结果。
其中最重要的是推理结果,这是HuggingGPT做出最终决策的关键点。HuggingGPT 允许LLM接收结构化的推理结果作为输入,并以友好的人类语言形式生成响应。此外,LLM 不是简单地汇总结果,而是生成积极响应用户请求的响应,从而提供具有置信度的可靠决策。
实验
采用 GPT 模型的 gpt-3.5-turbo、text-davinci-003 和 gpt-4 变体作为主要 LLM,可通过 OpenAI API 公开访问,set the decoding temperature to 0,set the logit_bias to 0.2 on the format constraints (e.g., "{" and "}")。
定性分析
下图中,用户的请求包括三个任务:检测示例图像中人的姿势,根据该姿势和指定文本生成新图像,以及创建描述该图像的语音。 HuggingGPT 将这些任务解析为六个任务,包括姿势检测、基于姿势的文生图、目标检测、图像分类、图像字幕和TTS。可以观察到 HuggingGPT 可以正确编排任务之间的执行顺序和资源依赖关系。例如,基于姿势的文生图任务必须遵循姿势检测并使用其输出作为输入。之后,HuggingGPT 为每个任务选择合适的模型,并将模型执行的结果综合为最终响应。
定量分析
任务规划在整个工作流程中起着至关重要的作用,因为它决定了后续流程中将执行哪些任务。因此,我们认为任务规划的质量可以用来衡量LLM作为HuggingGPT控制器的能力。
作者通过仅考虑任务类型来简化评估,不考虑其关联的参数。为了更好地对任务规划进行评估,作者将任务分为三个不同的类别并为它们制定不同的指标:
- 单任务:仅涉及一项任务的请求。当且仅当任务名称和预测标签完全相同时,才认为计划是正确的。在这种情况下使用 F1 和准确性作为评估指标。
- 顺序任务:用户的请求可以分解为多个子任务的序列。在这种情况下采用 F1 和归一化编辑距离作为评估指标。
- 图任务:用户请求可以分解为有向无环图。图任务中可能存在多种规划拓扑,仅依靠F1分数不足以反映LLM在规划方面的能力。为了解决这个问题,作者采用 GPT-4 作为批评者来评估规划的正确性。准确率是通过评估GPT-4的判断力得到的,简称GPT-4 Score。
数据集
作者创建两个数据集用于评估任务规划,收集了 3497 个不同的用户请求
- 邀请一些标注者提交一些用户请求作为评估数据集,用 GPT-4 生成任务规划作为伪标签,涵盖单任务(1450个)、顺序任务(1917个)和图任务(130个)。
- 邀请一些专家标注者将一些复杂请求(46 个示例,24个顺序任务+22个图任务)的任务规划标记为高质量的人工注释数据集。
性能
单任务评估结果:
顺序任务评估结果:
图任务评估结果:
复杂任务评估结果:
消融实验
任务规划阶段,提示词中不同任务示例的多样性对结果的影响。多样性指的是提示词中涉及的不同任务类型的数量。增加示例的多样性可以适度提高LLM在任务规划方面的表现。
提示词中不同任务示例的数量对结果的影响。添加一些示例可以稍微提高模型性能,但当示例数量超过 4 个时,这种改进将受到限制。
人工评测
作者收集了 130 个不同的请求来评估 HuggingGPT 在各个阶段的性能,包括任务规划、模型选择和最终响应生成,设计了三个评价指标,即通过率、合理性、成功率。
限制
一些限制或改进空间:
- HuggingGPT 中的规划很大程度上依赖于 LLM 的能力,而我们无法确保生成的计划始终可行且最优。因此,探索优化LLM的途径,提升其规划能力至关重要;
- 效率是一个最大的挑战,要构建这样一个具有任务自动化功能的协作系统(即 HuggingGPT),它在很大程度上依赖于强大的控制器(例如 ChatGPT)。然而,HuggingGPT 在整个工作流程中需要与LLM进行多次交互,从而增加了生成响应的时间成本;
- 令牌长度是使用 LLM 时的另一个常见问题,因为最大令牌长度始终受到限制,如何简洁有效地总结模型描述也是值得探索的;
- 不稳定主要是因为LLM通常不可控,在推理过程中可能不符合指令或给出错误答案,从而导致程序工作流程出现异常。在设计系统时应该考虑如何减少推理过程中的这些不确定性。
速览笔记
Motivation
作者为什么做这件事?之前存在什么问题?
AI模型很多,但是大部分都是领域专家模型,没有一个控制器将它们都联合起来。
ChatGPT出来之后,展现出了强大的理解和推理能力,正好可以作为一个复杂AI系统的大脑。
Novelty
- 创建点在哪里?为什么要提出来这个?要解决什么问题?
创新点包括:将ChatGPT作为控制器和规划器,解构复杂的任务,调用HuggingFace上的模型完成子任务,最后再汇总。
其实它也解决LLM只是一个纯语言模型,不能听、说和看的问题。
- 怎么才能想出来这个创新点?想问题的思路是什么?
推测作者的想法
站在当时的情境下,ChatGPT爆火,随之而来的就是AGI和Agent的概念。当时也有一些项目,像是AutoGPT、AgentGPT和BabyAGI等等,都是非常新的东西。
但是更多处理的还是文本这一个模态的信息,并不能处理其它像语音、图像和音频等模态的信息。
而GPT-4当时应该是还没有开放视觉能力,如果想要让ChatGPT拥有多模态的处理能力,就只能借助其它的模型,也就是HuggingFace上的模型。这些模型为了能够跟ChatGPT进行交互,也只能把输入输出都转换为文本的形式,这样就能搭建起一个以文本为媒介,ChatGPT为大脑的AI系统。
- 怎么就能发这个会议或者这个期刊的?
站在审稿人的角度看论文
一方面AGI和Agent这两点结合的很好,另外一方面,我觉得最重要的是,它提供了一种以文本为媒介的多模态处理方式,还不需要训练一个多模态模型。
Methods
对照代码,整理模型整体结构,分析每个模块的作用以及对性能的提升贡献(重点,呼应实验),找到核心模块(提点最多),以及判断跟创新点是否匹配
Experiments
训练集和测试集
用的哪个数据集,规模多少,评价指标是什么
作者自己创建两个数据集用于评估任务规划,收集了 3497 个不同的用户请求
- 邀请一些标注者提交一些用户请求作为评估数据集,用 GPT-4 生成任务规划作为伪标签,涵盖单任务(1450个)、顺序任务(1917个)和图任务(130个)。
- 邀请一些专家标注者将一些复杂请求(46 个示例,24个顺序任务+22个图任务)的任务规划标记为高质量的人工注释数据集。
性能如何,好不好复现,是否有Code/Blog/知乎讨论
代码开源,但是数据集不开源,尝试一下demo可以,复现实验结果不太好弄。
浙大与微软发布的 HuggingGPT 在线演示惊艳亮相,可完成多模态复杂任务,将带来哪些影响? - 知乎
浙大与微软发布的 HuggingGPT 在线演示惊艳亮相,可完成多模态复杂任务,将带来哪些影响? - 知乎
每个实验证明了什么
定量分析都是模型在任务规划阶段的指标。
消融实验是为了则是评估了提示词中示例的数量对结果的影响。
人类评估测试主要分了三个方面:通过率、合理性和成功率,我觉得最重要的事合理性。
有没有哪些实验没有做
论文中只对任务规划模块进行了定量分析,虽然给出的理由是任务规划模块最重要,但是我觉得其它模块也应该做实验分析。
- 任务规划模块,只考虑了任务类型的准确性,没有考虑参数,而且也没有考虑任务之间的依赖是否准确。对于顺序任务和图任务,我觉得顺序也是一个非常重要的因素;
- 模型选择这一块,选择模型的准确性也需要评估。例如TTS任务,用户请求是合成的是中文,它会不会选择一个通用的TTS模型然后合成了英文输出;
- 任务执行这一块倒是没有什么实验可以做;
- 响应生成这一块,是邀请了人类专家做的评判,但是这一块我觉得有些评测可以自动化,比如统计图片中有多少只狗,这个在一些目标检测的数据集中应该是有标签的,可以自动评测。
Downsides
哪些提出的模块是有问题的
好像也没有什么问题,少一个模块都不大行。
哪些提出的点对性能提升存疑
暂无。
有没有能改进的地方
论文中提出的未来改进方向:
- we plan to improve the quality and quantity of this dataset to further assist in evaluating the LLM's planning capabilities.
- we believe that developing technologies to improve the ability of LLMs in task planning is very important, and we leave it as a future research direction.
- In the future, we will continue to explore more elements that can improve the capability of LLMs at different stages.
- we think that how to design and deploy systems with better stability for HuggingGPT or other autonomous agents will be very important in the future.
增加反馈机制,如果有哪个流程出现了问题,可以通过ChatGPT进行检查并反馈。
Thinking
能否迁移应用?(业务应用方向、模型改进、数据生产组织等方面)
超级缝合怪,牛逼o( ̄▽ ̄)d。
不一定要训练多模态大模型,借助现有的各种领域专家模型也可以。