HuggingGPT Solving AI Tasks with ChatGPT and its Friends in HuggingFace---论文阅读总结

1、介绍

• LLMS（Large language models）在语言理解、生成、交互和推理方面产生优越的能力，推动了新的研究主题，例如上下文学习、指令学习以及思维链提示。

• 目前LLM技术仍不完善，主要有：

  • 限于文本生成的输入和输出形式，当前LLM缺乏处理视觉和语音等复杂信息的能力。

  • 在现实场景中，一些复杂任务通常由多个子任务组成，需要多个模型的调度和协作，超出了语言模型的能力。

  • 在零样本或少量样本情况下比一些专家模型（如微调模型）

• 作者提出概念：语言是LLMS连接AI模型的通用接口，换句话说，通过将这些模型描述合并到提示中，LLMS可以认为是管理AI模型的大脑，如计划、调度和合作。因此，这种策略使LLMS能够调用外部模型来解决AI任务，这种思路启发作者将LLM（如chatGPT）和公共ML社区（如GitHub、HuggingFace、Azure等）联系起来。

• 模型：HuggingGPT，连接LLMS（即ChatFGPT）和ML社区（即huggingface），可以处理来自不同模态的输入，并解决大量复杂的AI任务，具体来说对于huggingface中的每个AI模型，从库中使用其对应的模型描述，并将其融合到提示中，以建立与ChatGPT的连接，之后LLMS作为大脑确定用户问题的答案。

• HuggingGPT四个阶段：

  • 任务规划：使用ChatGPT分析用户的请求，了解意图，并通过提示将其分解为可能解决的任务。

  • 模型选择：为了解决规划的任务，ChatGPT根据模型描述选择托管在HuggingFace上的专家模型。

  • 任务执行：调用并执行每个选定的模型，并将结果返回给ChatGPT。

  • 回复生成：最后，使用ChatGPT整和所有模型的预测，为用户生成答案。

• 论文贡献

  • 为了补充LLMS和专家模型的优势，提出了模型间合作协议，大型语言模型作为规划和决策的大脑，小型模型作为每个特定任务的执行者，为设计通用AI模型提供了新的方法。

  • 构建了HuggingGPT来解决通用AI任务，通过将huggingfacehub与围绕ChatGPT的400多个特定任务模型集成。通过模型的开放协作，HuggingGPT为用户提供多模态和可靠的对话服务。

  • 在跨语言、视觉、语言和跨模态的多个具有挑战性的AI任务上进行广泛实验，证明了HuggingGPT在理解和解决来自多个模态和域的复杂任务方面的能力。

2、相关工作

• 大型语言模型：GPT-3、PaLM、LLaMa等模型

• LLM的一些活跃研究领域包括思维链提示（CoT）、指令调整

  • 思维链提示论文：

  • • 

    • 13论文通过设置几个案例实例，提示大型模型生成问题解决过程，从而显著提高模型的推理能力。

    • 

       

    • 14论文将思维链提示方法扩展到零样本思维链，发现通过使用“让我们一步步思考”这样的简单提示，可以让LLM能够生成代码逻辑来解决推理问题

  • 指令调优是大型语言模型应用的另一种方法

  • • 

    • 10、11、9等研究工作收集并将传统的NLP任务数据集转化为指令，并在指令数据集上对大型模型进行微调，以提高泛化能力。

• 将LLM的范围扩展到文本生成以外主要的两种方法：

  • 设计了统一的多模态语言模型，如BLIP-2[17]，利用Q-former协调语言和视觉语义；Kosmos-1[18]，将视觉输入纳入文本序列以合并语言和视觉输入。

  • 侧重外部工具或模型的集成。

    • [19]在文本序列中引入外部API标签，促进了LLM对外部工具的访问；

    • Visual ChatGPT[20]将视觉基础模型，如BLIP[21]和ControlNet[22]与LLMs融合；

    • [23]及ViperGPT[20]通过使用编程语言将LLMs应用于视觉对象，将视觉查询解析为表示为python代码的可解释步骤；

    • 使LLM适用专门的视觉任务，如Prophet[24]和ChatCaptioner[25]分别将LLM纳入视觉问答和图像描述任务。

• 作者提出的HuggingGPT与以上方法都不同，HuggingGPT特点：

  • HuggingGPT使用大型语言模型作为接口，将用户请求路由到专家模型，有效的将大型语言模型的语言理解能力与其他专家模型的专业知识相结合。

  • HuggingGPT不局限于视觉感知任务，而是可以通过大型语言模型组织模型之间的合作来解决任何模态或领域中的任务。

  • HuggingGPT采用了一种更开放的方式，基于模型描述来分配和组织任务，通过只提供模型描述，HuggingFace可以在不改变任何结构或提示设置的情况下，持续方便地集成多样化的专家模型。

3、HuggingGPT

 

• 1. 一个LLM首先解析用户请求，将其分解为多个任务，并根据其知识规划任务顺序和依赖关系

  2. LLM根据huggingface中的模型描述将解析后的任务分配给专家模型

  3. 专家模型在推理端点上执行分配的任务，并将执行信息和推理结果记录到LLM

  4. LLM汇总执行过程日志和推理结果，并将结果返回给用户。

• 任务规划阶段

  • 将复杂的请求分解为多个任务，LLM需要确定这些任务的依赖关系和执行顺序，为了使LLM进行有效的任务规划，HuggingGPT在其提示符设计中同时采用了基于规范的命令和基于演示的解析。

  • 基于规范的命令：任务规范为任务提供了统一的模板，并允许LLM通过slot filing进行任务解析，HuggingGPT为任务解析。HuggingGPT为任务解析设计了4个槽，分别是任务类型、任务ID、任务依赖关系、任务参数：

    • 任务ID：任务规划提供了唯一的标识符，用于引用依赖任务及其生成的资源

    • 任务类型：涵盖了语言、视觉、视频、音频等不同任务。

    • 任务依赖关系：定义了执行所需的先决任务，只有所有先决依赖任务完成时任务才能启动

    • 任务参数包含任务执行所需的参数列表，包含三个根据任务类型填充文本、图像和音频资源的子字段，从用户的请求或依赖任务的生成资源中解析。

  • 由于指令调优[9]和人类反馈强化学习[2]，大型语言模型具有跟随指令的能力

  • 基于演示的解析：HuggingGPT引入了上下文学习，以更有效的进行任务解析和规划，通过在提示中注入几个演示，HuggingGPT允许LLM更好的理解任务规划的意图和标准，每个演示都是一组关于任务规划的输入和输出--用户的请求和预期要解析出来的任务序列。

• 模型选择

  • 首先从huggingface hub中获取专家模型的描述，然后通过in-context任务-模型分配机制为任务动态的选择模型，这种做法允许增量的模型访问，且更加开放灵活。

    • 模型描述由开发人员提供，包含模型功能、架构、支持的语言、域、许可等信息。

    • 上下文中的任务-模型分配机制：单一选择，选择最合适模型，由于最大上下文长度的限制，无法总能根据提示包含所有相关模型，作者是根据任务类型过滤模型，只保留与当前任务类型匹配的模型，然后根据它们在huggingface上的下载量进行排名，选出k个模型作为候选。

• 任务执行

  • 执行模型推理，为加速和计算稳定性，huggingGPT在混合推理端点上运行这些模型，将任务参数作为输入，模型计算推理结果，然后返回大语言模型，为了进一步提高推理效率，没有资源依赖关系的模型可以并行化，意味着已经满足先决依赖关系的多个任务可以同时启动。

    • 混合端点：理想场景是只在Huggingface上使用推理端点，某些情况下必须部署局部推理端点，例如某些模型的推理端点不存在，推理耗时，或者网络访问受限等。为了保持系统的高效和稳定，HuggingGPT在本地拉取并运行一些常见或耗时的模型。局部推理端点速度很快，但覆盖的模型较少，而HuggingFace的推理端点相反，因此局部端点比huggingface的推理端点具有更高优先级，只有匹配的模型没有部署在本地，HuggingGPT才会在Huggingface端点上运行模型。

    • 资源依赖：HuggingGPT能够通过任务规划指定任务顺序，但在任务执行阶段有效管理任务之间的资源依赖关系仍具有挑战性，原因在于HuggingGPT无法指定future-generated任务规划阶段的任务资源，为解决这一问题作者使用了一个唯一的符合“<resource>”来管理资源依赖关系，具体来说，HuggingGPT将先决任务产生的资源标识为<resource>-task_id，其中rask_id是先决任务的任务id，在任务规划阶段，如果有依赖的task_id的任务生成资源的任务，HuggingGPT会将这个符号设置为认为参数中对应的资源子字段，然后在任务执行阶段huggingGPT动态替代此符号与先决任务产生的资源。

• 响应生成

  • 所有任务执行完成后，HuggingGPT进入相应生成阶段，在此阶段HuggingGPT将前三个阶段（任务规划、模型选择、任务执行）所有信息整合为一个摘要，包括计划的任务列表、为任务选择的模型及模型的推理结果。最重要的是推理结果，推理结果以结构化的格式出现，例如对象检测模型中带有检测概率的边界框、问答模型中的答案分布等，HuggingGPT允许LLM接收这些结构化的推理结果作为输入，并以友好的人类语言形式生成响应。

4、实验

• 实验中作者采用的是GPT-3.5-turbo和text-davincion-003变体作为大型语言模型，这些模型可以通过OpenAI API公开访问

  • OpenAI API地址：https://platform.openai.com/

• 此部分都是在展示HuggingGPT在不同输入任务上，以及复杂场景下运行情况，具体可参考原论文图8、9，10，11等。

5、局限性

• 效率问题，效率的瓶颈在于大型语言模型的推理。每一轮的用户请求，HuggingGPT都要求在任务规划、模型选择和响应生成阶段至少与LLM进行一次交互，极大的增加了响应延迟、并导致用户体验差。

• 最大上下文长度限制，受限于LLM可以接受的token最大数量，HuggingGPT也面临上下文长度限制，作者使用了对话窗口，只在任务规划阶段跟踪对话上下文来缓解。

• 系统稳定性，包含两个方面：

  • 一个是大型语言模型推理过程中发生的反叛，LLM在推理时偶尔会不符合指令，输出格式可能会违背预期，导致程序工作流程出现异常。

  • 托管在huggingface推理端点上的专家模型的不可控状态，可能受到网络延迟或服务状态的影响，导致任务执行阶段出现错误。

6、结论

• 作者提出了一个名为HuggingGPT的系统来解决AI任务，以语言作为连接LLM和AI模型的接口。我们系统的原理是LLM可以被视为管理AI模型的控制器，并可以利用来自ML社区的模型，如HuggingFace来解决用户的不同请求。通过利用LLM在理解和推理方面的优势，HuggingGPT可以剖析用户意图，并将任务分解为多个子任务，然后，基于专家模型描述，为每个任务分配最合适的模型，并整和来自不同模型的结果。