http:// https://github.com/microsoft/JARVIS.

1 Abstract  and Introduction

借助大语言模型（LLMS）在语言理解生成推理等方面表现出的出色能力，考虑将其作为控制器来管理现有的各种AI模型，把语言作为通用接口。基于这一理念，提出了HuggingGPT框架，利用LLMS（ChatGPT）来连接机器学习社区（Hug face）中的各种AI模型，具体来说就是在接收用户请求时使用ChatGPT来进行任务规划，根据Hug face中提供的模型功能描述选择模型，使用所选AI模型执行每一个子任务，并根据执行结果汇总响应。

现有LLM技术的局限：1）局限于文本的输入输出形式。2）现实场景中的复杂任务由多个子任务组合，需要多个模型的调度和配合。3）在零镜头或少镜头下结果表现出色但仍弱于专家模型（如微调模型）。

在本文中，我们提出了一个名为HuggingGPT的系统来连接LLMs(即ChatGPT)和ML社区(即hug Face)，它可以处理来自不同模式的输入，并解决众多复杂的AI任务。更具体地说，对于hug Face中的每个AI模型，我们从库中使用其对应的模型描述，并将其融合到提示符中，以建立与ChatGPT的连接。之后，在我们的系统中，llm(即ChatGPT)将充当大脑来确定用户问题的答案。如图1所示，HuggingGPT的整个过程可以分为四个阶段:

1）Task Planning:利用ChatGPT分析用户的请求并通过提示将其分解为可能解决的任务。

2）Model Selection:ChatGPT根据模型描述选择托管在hug face上的专家模型。

3）Task Execution:调用并执行每个选定的模型，并将结果返回给ChatGPT。

4）Response Generation:最后用ChatGPT集成所有预测的模型为用户生成答案。

目前为止，我们的HuggingGPT 已经围绕chatGPT集成了数百个模型，涵盖了文本分类、对象检测、语义分割、图像生成、问答、文本转语音、文本视频等24个任务。

我们的贡献如下：

1）提出了模型间合作协议。大模型作为规划和决策的大脑，小模型作为每个特定任务的执行者。

2）构建了HuggingGPT,通过围绕ChatGPT集成了hug face当中的400多个用于特定任务的模型来处理通用的AI任务。

3）在跨语言、视觉、语音和跨模式的多个具有挑战性的AI任务上进行的大量实验证明了HuggingGPT在理解和解决来自多种模式和领域的复杂任务方面的能力。

2 Related Works

为了将大型语言模型(LLMs)的范围扩展到文本生成之外，当代研究研究了两种主要方法。

1)首先，一些工作设计了统一的多模态语言模型，如BLIP-2[https://arxiv.org/abs/2301.12597]，它利用Q-former来协调语言和视觉语义，Kosmos-1[https://arxiv.org/abs/2302.14045]将视觉输入合并到文本序列中，融合语言和视觉输入。

2)其次，其他研究集中在外部工具或模型的集成上。先锋Toolformer[https://arxiv.org/abs/2302.04761]在文本序列中引入了外部API标签，方便llm访问外部工具。

许多工作将LLMs扩展到视觉形态。Visual ChatGPT[20]融合了可视化基础模型，如BLIP[21]和ControlNet[22]，与llm。Visual Programming[23]和ViperGPT[20]通过使用编程语言将llm应用于可视对象，将可视查询解析为用Python代码表示的可解释步骤。

3 HuggingGPT

3.1 Task Planing

LLMs从用户获取一个请求并将其分解为一系列结构化任务并确定这些任务的依赖关系和执行顺序，在这里，HuggingGPT在其提示设计中采用了基于规范的指令和基于演示的解析。

1）Specification-based Instruction：提供了统一的模板，并允许大型语言模型通过插槽归档进行任务解析 ，为此设计了任务类型、任务ID、任务依赖项和任务参数四个槽位。

Task ID:为任务规划提供了一个唯一的标识符用于引用依赖任务及其生成的资源。

Task types:包括语言视觉视频音频等不同的任务。

Task dependencies:执行所需的先决条件任务，只有当所有先决条件相关任务都完成时任务才会启动。

Task arguments:包含任务执行所需参数的列表。包含三个子字段根据任务类型填充文本、图像和音频信息；它们是从用户请求或依赖任务生成的资源中解析出来的。

2）Demonstration-based Parsing：通过在提示中注入几个演示，为更有效的任务解析和计划引入了上下文学习。每个演示都是任务计划的一组输入和输出——将解析出用户的请求和预期的任务序列。这些演示是由从用户请求解析的任务之间的依赖关系组成。

3.2 Model Selection

在解析任务列表后，HuggingGPT 接下来要为任务列表中的每个任务选择适当的模型。为此，1）首先从hugging face hub中获取专家模型的描述；2）通过上下文任务模型分配机制动态地为任务选择模型。

Model Description：在hug Face Hub上托管的专家模型伴随着全面的模型描述，通常由开发人员提供。这些描述包含模型的功能、体系结构、支持的语言和域、许可等信息。这些信息有效地支持HuggingGPT根据用户请求和模型描述的相关性为任务选择正确的模型。

In-Context Task-Model Assignment ：通过在提示中包含用户查询和已解析地任务，HuggingGPT 可以为手头的任务选择最合适的模型，然而由于最大上下文长度的限制，在提示符中不可能包含所有相关的模型信息，因此我们根据它们的任务模型进行筛选，只保留那些与当前任务类型匹配的模型。剩下的模型根据下载量进行排名，并根据这个排名选择前k个的模型作为候选。

3.3 Task Execution

一旦将任务分配给特定的模型，下一步就是执行该任务，即执行模型推断。为了加速和计算稳定性，HuggingGPT 在混合推断端点上运行这些模型。通过将任务参数作为输入，模型计算推理结果，然后将它们发送回LLM。为了进一步提高推理效率，可以对没有资源依赖的模型进行并行化。

1）Hybrid Endpoint：为了保持系统的稳定和高效，HuggingGPT在本地提取并运行一些常见或耗时的模型，并且局部端点的优先级高于hug face的推理端点。只有匹配的模型不在本地部署时，huggingGPT才会在hug face端点上运行模型。

2）Resource Dependency:在任务执行阶段有效地管理任务之间的资源依赖关系是难题。在这里，我们使用一个唯一的符号“<resource>”来管理资源依赖关系。具体来说，HuggingGPT将前置任务生成的资源标识为-task_id，其中task_id是前置任务的任务id。在任务规划阶段，如果存在依赖于task_id任务生成的资源的任务，HuggingGPT将此符号设置为任务参数中对应的资源子字段。

3.4 Response Generation

所有任务执行完成后，HuggingGPT进入响应生成阶段。在这一阶段，HuggingGPT将前三个阶段(任务计划、模型选择和任务执行)的所有信息集成到一个简明的摘要中，包括计划的任务列表、为任务选择的模型以及模型的推断结果。

其中最重要的是推理结果，是HuggingGPT做出最终决策的依据。这些推理结果以结构化的形式出现，如对象检测模型中带有检测概率的边界框，问答模型中的答案分布等。HuggingGPT允许LLM接收这些结构化的推理结果作为输入，并以友好的人类语言形式生成响应。

本文链接：https://my.lmcjl.com/post/9851.html