当前「AI²Paradiam」投资创业范式再思考-暨转译：LLM和它的朋友们形成的B端智能体

图｜Deep(Learning)Focus

文｜汤源/卡梅隆·沃尔夫博士

LLM和它的朋友们题图 by DEEP(LEARNING)FOCUS

▽

题记及AI²Paradiam投资创业范式再思考

之前转译过卡梅隆·沃尔夫博士（Cameron R. Wolfe, Ph.D. @CWOLFERESEARCH）的关于提示工程（Prompt Engineering）的一系列文章：

从思维链（CoT 转译1）到提示工程的进阶三部曲（转译2/3/4），如果加上前一段时间出现的ToT（Tree of Thoughts），有关提示工程的arxiv论文总结基本告一段落，作者后来提出程序辅助语言模型（基于PaL的PoT）无疑更高阶，笔者理解与最近OpenAI官方推出的code interpreter思路上是类似的。

△

“思维树概念示意图-来自ToT论文截图https://arxiv.org/pdf/2305.10601.pdf”

最近卡梅隆·沃尔夫博士的官方博客上又放出了：大语言模型和朋友们（Language Models and Friends: Gorilla, HuggingGPT, TaskMatrix, and More），显然原作者的研究视线也转到一个GPT生态新领域，就是以HuggingGPT为代表的通用GPT与专业GPT的集成器（integrator）、控制器（controller）或者调度器（coordinator）。

“By providing only the model descriptions, HuggingGPT can continuously and conveniently integrate diverse expert models from AI communities, without altering any structure or prompt settings. This open and continuous manner brings us one step closer to realizing artificial general intelligence.” - from [2]

“通过仅提供模型描述，HuggingGPT可以连续方便地集成来自AI社区的各种专家模型，而无需更改任何结构或提示设置。这种开放和持续的方式使我们离实现通用人工智能更近了一步“-来自论文[2]

Hugging Face公司是一家在2016年由Clément Delangue、Julien Chaumond和Thomas Wolf创立的公司，最初是开发面向青少年的聊天机器人应用的公司。后来，该公司转向专注于成为一个机器学习平台，提供了一个开源的自然语言处理库Transformers，以及一个支持多种机器学习任务和模型的在线平台Hub。该公司通过多轮融资筹集资金，目前估值达到了20亿美元，并且拥有一个非常强大并且活跃的人工智能社区。

虽然随着OpenAI下一个GPT版本的迭代，预计达到通用人工智能（AGI）并逐步到超级人工智能（ASI），并在一定程度上吞噬专业深度模型，但正如在终端智能及个人模型方面大模型蒸馏的存在，随着模型无处不在的浪潮席卷而来，未来无论是个人还是企业无疑也会面临同时使用多个模型的情况，笔者由此判断“模型的模型，从而形成面向复杂商业场景的B端智能体”作为一种创业投资方向，必不可少，也因此借转译卡梅隆博士这篇专业论述，更新在上一篇公众号文章中总结的模型原生投资创业范式，笔者称之为：

「AI²Paradiam」v3

AI之路千条万条，基于模型原生创业范式当前可分为四类（由之前的三类升级而来）：

▩大模型炼丹(pre-training)-基础大语言模型（foundation LLMs)，语言有超模态的地位，是通向AGI的必经之路，和OpenAI竞争或用于企业本地部署场景；（这一点以Yann LeCun为首的一直有不同意见，在5/9北京智源大会上演讲就以《走向能够学习、推理和规划的大模型》为题，有机会笔者也可以总结一下Yann和Ilya一直以来的分歧，应该也挺有意思）

▩大模型挖矿(prompting)-偏大模型应用场景，这个就多了，我个人比较看好MJ或characterai的GPT原生模式。其它B端对于现有业务AI增强改善只是有阶段性价值空间。为什么说是阶段性价值空间呢，因为大炼丹会导致模型无处不在，对物理世界的改造范式发生了革命性变化，会出现完全重构现有B端业务的新业务模式。可以类比想象：工业化出现后，农业就不再是主要生产场景。

还有就是基于开源LLM的Model Anywhere & Anydevices方向：

▩大模型蒸馏(distilling)-蒸馏出的小模型可以运行在终端智能或作为个人助理模型（in-device inference & personal agent models）：基于开源模型，类似llma.cpp的in-device inference场景，以及线上的数字分身产品等原生方向。按照Hinton老爷子的说法，大模型蒸馏类似于知识从教授向学生传授。

▩大模型智能体(promptless)-本来以为类似HuggingGPT这样的解决方案，作为通用GPT与专业GPT的集成器（integrator）、控制器（controller）或者调度器（coordinator）；通过学习调用关联的 API 将 LLM 与其他专门的深度学习模型集成在一起，生成的框架使用LLM作为集中式控制器，形成解决复杂的人工智能相关任务的计划，并将解决方案过程的专用部分委托给更合适的模型。但进一步探究，作为AI²Paradiam的第四种范式，应该不仅仅是一个大模型协同角色那么简单。这实际上就是完全可以独立运行（这里是否自主不确定）的大模型智能体的需求，而且与人类的交互甚至是完全自然语言或者能预测人类行为而采取计划与行动（promptless）。

面向个人，就是OpenAI请回Andrej负责的类似Javis的ChatGPT升级版的人类助手；面向家庭，就是智能体管家；面向复杂的企业场景，需要的则是类似HuggingGPT，Gorrila等整合社区的大量专业模型应用升级而来的商业智能体agent。

以上基本就是笔者接下来研究AI²Paradiam投资创业范式的框架。

HuggingGPT与LangChain的LLMs开发框架的区别

LangChain也是一个利用LLMs来开发应用的框架。它提供了一些模块化的抽象，用于处理与语言模型相关的组件，例如数据源、环境交互、API请求等。它还提供了一些特定用例的链，可以将这些组件以特定的方式组合起来，以实现某个特定的用例。LangChain支持多种文档类型和数据源，并且可以与OpenAI、Anthropic、Hugging Face等语言模型进行集成。

HuggingGPT和LangChain之间的区别主要在于以下几点：

• HuggingGPT使用ChatGPT作为控制器，而LangChain没有限定使用哪种LLM。

• HuggingGPT主要依赖于Hugging Face中提供的AI模型，而LangChain可以与更多的系统和服务进行集成。

• HuggingGPT更注重解决复杂和多模态的AI任务，而LangChain更注重提供通用和灵活的语言模型应用开发框架。

注：被题目吸引进来看投资创业方向的朋友以下转译内容可以略去(AI² Paradigam)。

转译：大语言模型LLMs和它的朋友们-Gorilla, HuggingGPT,  TaskMatrix,  and More

最近，我们见证了基础模型（Foundation Models）在深度学习研究中的普及。预训练的大型语言模型（LLM）导致了一种新的范式，其中可以使用单个模型来完成许多不同的任务，并取得了惊人的成功。

然而，尽管通用LLM很受欢迎，但特定任务领域，微调模型的方法往往优于直接利用基础模型。简而言之，专业领域模型仍然很难被击败！话虽如此，我们可能会开始怀疑基础模型和专门的深度学习模型是否可以结合起来。

在本概述中，我们将探索在这一领域最新研究进展，这些研究通过学习调用其关联的 API 将 LLM 与其他专门的深度学习模型集成在一起，生成的框架使用语言模型作为集中式控制器，形成解决复杂的人工智能相关任务的调度器，并将解决方案过程的专用部分委托给更合适的专业模型。

▩背景

在探索语言模型如何与其他深度学习模型集成之前，我们需要涵盖一些背景内容，例如LLM工具，信息检索和自指导[11]。有关语言模型的更多通用背景信息，请查看以下资源。

• Language Modeling Basics (GPT and GPT-2) [link]
  语言建模基础（GPT 和 GPT-2） [ 链接]

• The Importance of Scale for Language Models (GPT-3) [link]
  量表对语言模型的重要性 （GPT-3） [ 链接]

• Modern [link] and Specialized [link] LLMs
  现代 [ 链接] 和专业 [ 链接] LLM

• Basic [link] and Advanced [link] Prompt Engineering
  基本 [ 链接] 和高级 [ 链接] 提示工程

 将工具与LLM一起使用

“By empowering LLMs to use tools, we can grant access to vastly larger and changing knowledge bases and accomplish complex computational tasks.” - from [3]

“通过授权LLM使用工具，我们可以授予对更大和不断变化的知识库的访问权限，并完成复杂的计算任务。“-来自论文[3]

尽管语言模型具有大量令人印象深刻的功能，但它们并不完美，无法独自完成所有任务。在许多情况下，将现有模型与工具（例如，搜索引擎，计算器，日历等）相结合可以大大扩展其功能范围。在之前的概述中，我们探讨了 Toolformer [1]——一种用于教 LLM 使用一小组简单文本 API 的微调技术——以及如何使用工具来提高 LLM 的性能而无需太多努力；有关更多详细信息，请参见下文。

The Toolformer 工具成型机 [https://cameronrwolfe.substack.com/p/teaching-language-models-to-use-tools]

尽管像 Toolformer 这样的模型是有效的，但它们只考虑一小部分非常简单的 API。这些API几乎没有触及LLM可以使用的工具总数的表面。想象一下，例如，如果我们能够将LLM与通过互联网提供的任何API集成 - 我们可以解锁整个新应用程序和可能性的领域！

△

“ChatGPT Plus 插件商店中的热门应用程序”

（几乎）一切皆有可能！这种为语言模型提供广泛在线访问各种 API 的趋势正在通过 ChatGPT 插件商店进行探索;见上图。通过利用这些API，我们可以做的不仅仅是让LLM访问计算器等简单工具！我们可以很容易地想到通过这种方法可以实现的几个高影响的应用程序。例如，我们可以将语言模型与工具集成用于：

• Forming a vacation itinerary and booking all needed tickets and reservations
  制定度假行程并预订所有需要的机票和预订

• Curating and purchasing the week’s grocery list for curbside pickup
  策划和购买本周的购物清单，以便在路边取货

• Finding and reserving a table at a restaurant for the upcoming weekend
  在餐厅寻找并预订即将到来的周末餐桌

• Discovering and purchasing relevant products on any e-commerce store
  在任何电子商务商店发现和购买相关产

可能性的范围几乎是无穷无尽的！通过使用语言作为标准化的交流媒介，我们可以与 ChatGPT 等基础模型合作，完成令人惊讶的复杂任务。我们所要做的就是提示模型生成与我们的请求相关的 API 调用。

深度学习API｜在本概述中，我们将考虑将LLM与特定类型的API集成 - 那些在HuggingFace等平台上提供对开源深度学习模型的访问的API。AI/ML社区非常重视开源软件，这意味着许多最强大的深度学习模型都可以在线免费获得。通常，这些模型带有编写良好的描述，称为模型卡，可用于向LLM提供有关任何模型的所有所需信息。然后，这些模型可以通过基本的提示技术轻松地与LLM集成。

自指令框架 The Self-Insturct Framework

△

“来自论文[11]”

[11]中提出的自指令框架开创了使用LLM通过生成可用于微调的综合指令调整数据来训练自己的想法。从与某个任务或指令关联的单个输入输出对开始，自指令提示现成的LLM生成新任务，以及每个任务的有效指令和响应。在执行过滤以删除低质量数据后，我们可以对生成的指令调优数据集上的任何语言模型进行微调。有趣的是，我们发现根据这些数据进行微调的模型往往与通过人工管理的数据集训练的模型的性能相匹配。虽然自指令效果很好，但羊驼也提出了对整体框架的一些改进[12]。

自指令Self-Instruct 2.0 [https://github.com/tatsu-lab/stanford_alpaca#data-generation-process]

信息检索 Information Retrieval  

正如我们在之前的概述中看到的那样，基础语言模型的质量往往会随着规模的扩大而提高——大型预训练数据集和模型会产生最佳结果。但是，我们只能在语言模型中包含的固定权重集中存储如此多的信息。即使是大型模型也有有限数量的参数。此外，现代LLM的有限上下文窗口限制了我们只能在模型的提示中注入少量信息。1 那么，如果我们想为我们的LLM提供对大型信息库的访问，我们应该怎么做？这时我们需要采用某种形式的信息检索。

△

“来自论文[13]”

矢量数据库｜一种流行的信息检索形式可以通过将LLM与存储大量文本信息的矢量数据库集成来执行。在高层次上，这种与载体数据库（例如松果、Milvus、Weaviate、Redis 等）的集成由以下因素形成：

1. Chunking the text into small parts.
   将文本分成小部分。

2. Producing an embedding for each chunk of text.
   为每个文本块生成嵌入。

3. Storing these embeddings in a vector database.
   将这些嵌入存储在矢量数据库中。

4. Performing vector similarity search (based on these embeddings) to find relevant chunks of text to include in a prompt.
   执行矢量相似性搜索（基于这些嵌入）以查找要包含在提示中的相关文本块。

最终结果是，我们可以快速找到相关的文本信息，以在提示中作为额外的上下文提供，允许LLM利用超出其上下文窗口最大大小的信息。尽管我们仍然无法为模型提供所有信息，但我们可以使用向量相似性搜索来快速识别最相关的部分。

△

“来自论文[14]”

这是唯一的办法吗？｜已经提出了许多其他用于信息检索的方法 - 有一个完整的（非常活跃的）研究领域致力于这些技术。我们甚至可以使用 LLM 通过生成的知识提示生成相关信息（而不是检索它）;见上图。下面的文章很好地总结了现有的信息检索技术。

Info Retrieval Survey 信息检索调查 [https://jxmo.io/posts/retrieval]

总体而言，存在许多不同的技术，我们有很多选择来选择如何通过外部信息来源增强LLM。

△

“来自论文[3]”

我们为什么要关心？｜信息检索很棒，但我们可能想知道为什么这与将LLM与其他深度学习模型集成的主题相关。那么，如果我们想提供对在线可用任何模型的访问怎么办？在像HuggingFace这样的ML社区上有成千上万的模型！因此，我们无法向LLM提供所有这些模型的描述。相反，我们需要使用某种形式的信息检索来确定我们应该包含在LLM提示中的最相关的模型子集;见上图。

▩将LLM与其他模型集成

现在我们已经掌握了一些相关的背景信息，我们将看看最近的出版物，这些出版物用其他深度学习模型增强了LLM。尽管每种方法都不同[2，3]，但所有这些技术都旨在教LLM如何调用与其他专用模型关联的API。然后，LLM可以充当控制器（或大脑），通过规划和将子任务委派给不同的API来协调问题的解决方案。

HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face [2]

△

“来自论文[2]”

LLM最近变得流行，但近年来深度学习的研究已经产生了各种非常有用的模型，用于解决图像识别，视频动作检测，文本分类等特定任务。与语言模型 2 不同，这些模型是狭义的专家，这意味着它们可以在给定固定的输入输出格式的情况下准确解决特定任务。但是，除了训练要解决的特定任务之外，它们对任何事情都没有用。如果我们想将这些模型重新用作解决更多开放式AI相关任务的组件，该怎么办？

“LLMs [can] act as a controller to manage existing AI models to solve complicated AI tasks and language could be a generic interface to empower this.” - from [2]

“LLM [可以] 充当控制者来管理现有的 AI 模型来解决复杂的 AI 任务，语言可以成为增强这一点的通用接口。“-来自论文[2]

在[2]中，作者探索使用LLM作为将深度学习模型连接在一起的通用接口。HuggingGPT [2] 的灵感来自于 LLM 与具有各种不同专业功能的外部模型需要进行协调的想法。简而言之，LLM充当问题解决系统的“大脑”，该系统计划如何解决问题并协调不同深度学习模型之间的工作，以解决该问题的必要子任务。为了教LLM如何做到这一点，我们需要对每个模型进行高质量的描述。幸运的是，我们不需要执行任何快速工程来创建这些描述——它们可以通过 HuggingFace 等 ML 社区广泛获得！

HuggingFace 模型卡 https://huggingface.co/docs/hub/model-cards#what-are-model-cards

△

“来自论文[2]”

这是如何工作的？｜HuggingGPT [2] 将问题分解为四个部分：

• Task planning: use the LLM to decompose a user’s request into solvable tasks.
  任务规划：使用LLM将用户的请求分解为可解决的任务。

• Model selection: select models from HuggingFace to use for solving tasks.
  模型选择：从HuggingFace中选择模型用于解决任务。

• Task execution: run each selected model and return results to the LLM.
  任务执行：运行每个选定的模型并将结果返回到LLM。

• Response generation: use the LLM to generate a final response for the user.
  响应生成：使用 LLM 为用户生成最终响应。

正如我们所料，利用在线可用的模型功能使HuggingGPT能够解决各种复杂的问题！

“HuggingGPT can automatically generate plans from user requests and use external models, and thus can integrate multimodal perceptual capabilities and handle multiple complex AI tasks.” - from [2]

“HuggingGPT可以根据用户请求自动生成计划并使用外部模型，因此可以集成多模态感知功能并处理多个复杂的AI任务。“-来自论文[2]

令人印象深刻的是，HuggingGPT 根本不需要微调即可学习如何协调和使用这些模型！相反，它利用少量镜头的学习和指导提示来执行解决问题所需的每个任务;见下文。为了使这些提示正常工作，我们需要一个可操纵的LLM（例如，ChatGPT或GPT-4），它可以严格遵循指示并遵守严格的输出格式（例如，将问题分解为json格式的任务）。

△

“来自论文[2]”

值得注意的是，我们应该观察到要使用的可用模型集直接注入到提供给 HuggingGPT 的任务规划提示中;请参阅上面的示例。显然，网上可用的模型太多，无法将它们全部包含在提示中。为了决定哪些模型应该作为选项包含在提示中，HuggingGPT 根据任务类型（即，它们是否解决了与当前问题相关的任务）选择一组模型，根据下载量（即，在 HuggingFace 上下载或使用此模型的用户数量）对它们进行排名，然后将前 K 个模型作为选项提供给 LLM。

资源依赖关系｜在 HuggingGPT 将用户的请求分解为几个解决问题的步骤后，我们需要在指定的计划中执行每个模型。但是，当我们执行 HuggingGPT 指定的每个模型时，某些模型可能依赖于其他模型的输出，这在 [2] 中称为“资源依赖”。为了处理这些情况，具有依赖项的模型在执行之前会等待它们所依赖的模型的输出。没有依赖关系的模型可以并行执行，使 HuggingGPT 的任务执行步骤更快。有趣的是，LLM产生的任务规划结构不仅改变了每个模型的执行顺序，还改变了我们评估HuggingGPT输出的方式。例如，[2] 中的作者使用 GPT-4 来评估更复杂的任务计划的质量;见上图。

它表现良好吗？｜在[2]中进行的HuggingGPT评估仅侧重于评估几个不同LLM的任务规划能力，因为任务规划的质量在很大程度上决定了HuggingGPT整体问题解决框架的成功。如下图所示，像GPT-3.5这样的LLM（以及在一定程度上功能较弱的模型）似乎能够有效地将用户请求分解为有效的任务计划。

△

“来自论文[2]”

需要做很多工作来改进对这些技术的评估——[2]中提供的分析远非全面。此外，尽管HuggingGPT运行良好，但它只考虑了一小组记录良好的模型API，这些API直接注入LLM的提示中。与微调相比，此框架需要大量快速工程才能正常工作。虽然我们避免了微调数据集的需要，但框架高度依赖于底层模型的功能。因此，我们可能想知道：我们如何才能推广这种方法以更可靠地适用于更多的模型？

Gorrila：与大规模API连接的大型语言模型[3]

“Supporting a web scale collection of potentially millions of changing APIs requires rethinking our approach to how we integrate tools.” - from [3]

“支持可能具有数百万个不断变化的 API 的 Web 规模集合需要重新思考我们如何集成工具的方法。“-来自论文[3]

将LLM与一组较小的，固定的其他模型集成很酷，但是如果我们可以教LLM使用在线提供的任何模型API呢？为此，我们可以使用检索技术，i）识别相关的模型API，ii）将其文档提供给LLM。通过这种方法，LLM将不仅仅使用一小组策划的工具！相反，模型可以访问云中大量不断变化的API。然而，不幸的是，即使是强大的LLM（例如，GPT-4或Claude）也很难以这种方式利用API，因为倾向于传递不正确的参数或对不存在的API产生幻觉调用;见下图。

△

“来自论文[3]”

在[3]中，作者采用基于自指令[11]框架的微调方法，使LLM更有能力利用大量外部深度学习API。除了像HuggingGPT [2]这样的提案之外，[3]中的作者还考虑了1，600多种不同的模型API。这组模型 API 比之前工作中考虑的要大得多，具有重叠的功能（即，许多模型执行类似的任务），甚至包括各种文档不太完善的模型。要了解如何利用这些 API，请在 [3] 中对有效 API 调用的大型数据集微调 LLaMA-7B [5] 模型。生成的模型可以有效地利用其中许多 API，称为大猩猩（Gorrila）。

创建数据集｜为了微调Gorilla，通过利用HuggingFace Hub，PyTorch Hub和TensorFlow Hub创建了大量的API调用语料库。在所有三个中心中，总共选择了 1，645 个模型 API，涵盖从计算机视觉到音频、强化学习等众多领域。在 json 对象中存储每个 API 的相关信息（即包括域、框架、功能描述和 API 签名等信息）后，我们可以遵循自指示方法，使用 GPT-4 生成十个用户问题提示和相关响应，以配合每个 API。过滤不正确的 API 调用后，结果只是一个包含真实用例的大型数据集，这些用例利用每个不同的模型 API 来解决各种问题。此数据集非常适合微调 LLM;见下图。

△

“来自论文[3]”

检索感知微调｜Gorilla没有执行“正常”的监督微调，而是利用了“检索感知”的微调变体。这听起来可能很花哨，但实际实现很简单！对于微调数据集中模型 API 的每次调用，我们在数据中添加此 API 的最新文档。然后，我们在测试时遵循类似的方法，将 API 文档附加到我们的提示符中，这教会 LLM 根据文档动态确定每个 API 的正确用法;见下图。

△

“来自论文[3]”

检索感知微调是一种技术，它教会LLM在确定如何解决问题时更好地利用API文档。这种动态方法使LLM能够：

• Adapt to real-time changes in an API’s documentation at test time
  在测试时适应 API 文档中的实时更改

• Develop improved in-context learning abilities for making API calls
  培养用于进行 API 调用的改进的上下文学习能力

• Hallucinate less by paying better attention to info in an API’s documentation
  通过更好地关注 API 文档中的信息来减少幻觉

检索感知微调使Gorilla成为一个非常强大的接口，用于利用各种不同的深度学习模型 - 由此产生的LLM可以使用大量不同的API来解决问题。此外，该模型实际上可以适应其任何 API 的文档更改！有关适应 API 文档中更改的示例，请参阅上图。

△

“来自论文[3]”

使用大猩猩｜尽管我们知道在构建微调数据集时要在提示中包含哪个 API，但在推理过程中收到用户的任意提示时，我们不知道要使用的正确 API。为了确定要使用的正确API，我们可以采用一种信息检索技术，即i）嵌入用户的提示（或其他相关信息）和ii）执行向量相似性搜索以查找最相关的API文档。这样，我们可以轻松有效地确定用于解决问题的最佳 API。或者，我们可以以零镜头的方式使用大猩猩，将用户的提示直接传递给模型，而无需任何信息检索或额外信息。无论哪种方式，Gorilla 的目标都是生成对最合适的 API 的准确调用，以解决用户的提示;见上图。

△

“来自论文[3]”

正如上面的实验结果所证明的那样，Gorilla是一个令人难以置信的深度学习API接口。与更大、更强大的模型（例如 GPT-3.5、Claude 和 GPT-4）相比，我们看到 Gorilla 更有能力生成准确的 API 调用，这意味着该模型对不存在的 API 调用产生幻觉的次数更少，并且倾向于传递正确的输入参数！

其他值得注意的技术...

HuggingGPT [2] 和 Gorilla [3] 在过去的几个月里获得了很多公众的认可和讨论，但已经提出了许多其他技术，考虑使用 LLM 来协调几种不同深度学习模型的工作。下面概述了其他有趣技术的简要列表。

△

“来自论文[7]”

TaskMatrix [7]｜ 是一份立场文件——这意味着它提出了对一个值得注意的问题的立场或展望——它考虑了基础模型（例如，像 ChatGPT 这样的 LLM）与数百万种不同 API 的集成。值得注意的是，这项工作认为基础模型缺乏准确解决专业任务所需的领域知识，但许多现有的、特定于任务的模型可以以令人印象深刻的精度解决特定任务。由于兼容性问题，将这些专业/专家模型与LLM集成可能很困难，但是[7]中的作者广泛讨论和考虑了这个想法。在许多方面，HuggingGPT和Gorilla是[7]中讨论的想法的实际实现。

△

“来自论文[8]”

API Bank [8] ｜为评估工具增强型 LLM 提供了更好的基准。特别是，该基准测试考虑了通常与LLM集成的50多个API和264个带注释的对话（总共包括568个API调用）与这些工具一起使用。该基准测试旨在评估LLM创建任务计划（即执行哪些API调用的分步指南），确定要使用的正确API以及执行API调用以回答所提供问题的能力。不出所料，初步实验表明，GPT-4 在利用外部工具回答用户提供的问题方面具有最强大的能力。尽管这项工作没有特别考虑深度学习模型API，但使用的任务框架反映了本概述中看到的方法。

△

“来自论文[9]”

ToolkenGPT [9]｜ 试图通过为每个工具分配特定的令牌和关联的令牌嵌入来缓解工具遵循基础模型的微调要求，从而允许 LLM 以类似于生成普通单词标记的方式生成工具请求。发现这种方法在利用各种外部工具方面非常灵活。

△

“来自论文[10]”

使用开源LLM进行工具操作[10]｜在大多数情况下，我们看到闭源LLM（例如GPT-4）更具可操纵性，因此可以更好地操纵外部工具。然而，在[10]中，作者分析了开源LLM是否可以微调以匹配该特定技能中强大的闭源LLM的性能。使用人工反馈和监督来优化各种开源LLM，以提高其工具跟踪能力。有趣的是，我们看到，如果有足够的微调，一些开源模型可以通过 GPT-4 实现竞争性能。在这个概述中，我们已经看到像Gorilla这样的模型，在正确的微调程序下，开源LLM（例如LLaMA）非常强大。

▩结语

“There is a clear and pressing need for a mechanism that can leverage foundation models to propose task solution outlines and then automatically match some of the sub-tasks in the outlines to the off-the-shelf models and systems with special functionalities to complete them.” - from [7]

“明确而迫切需要一种机制，可以利用基础模型提出任务的解决方案大纲，然后自动将大纲中的一些子任务与具有特殊功能的现成模型和系统相匹配以完成它们。“-来自论文[7]

在这个概述中，我们已经看到LLM能够通过其API与其他深度学习模型集成。

在HuggingGPT [2]的情况下，这可以使用上下文学习方法来完成，其中我们提示LLM对现有模型及其功能的描述。

然而，值得注意的是，HuggingGPT 最适合像 ChatGPT 这样的强大闭源模型。如果我们想教开源模型（例如LLaMA）在解决复杂问题时调用深度学习模型API，我们需要采用Gorilla提出的微调方法[3]。无论哪种方式，这些技术都非常强大，因为它们在狭义的专家和基础模型的优势之间取得了平衡。

我们可以依靠LLM来执行高级推理并形成解决问题的计划，同时将某些子任务委托给更可靠和准确的专业模型，从而利用两者的力量。

“Supporting a web scale collection of potentially millions of changing APIs requires rethinking our approach to how we integrate tools.” - from [3]
“支持可能具有数百万个不断变化的 API 的 Web 规模集合需要重新思考我们如何集成工具的方法。”

参考：Bibliography书目

[1] Schick, Timo, et al. "Toolformer: Language models can teach themselves to use tools." arXiv preprint arXiv:2302.04761 (2023).

[2] Shen, Yongliang, et al. "Hugginggpt: Solving ai tasks with chatgpt and its friends in huggingface." arXiv preprint arXiv:2303.17580 (2023).

[3] Patil, Shishir G., et al. "Gorilla: Large Language Model Connected with Massive APIs." arXiv preprint arXiv:2305.15334 (2023).

[4] Wei, Jason, et al. "Chain of thought prompting elicits reasoning in large language models." arXiv preprint arXiv:2201.11903 (2022).

[5] Touvron, Hugo, et al. "Llama: Open and efficient foundation language models." arXiv preprint arXiv:2302.13971 (2023).

[6] Wang, Yizhong, et al. "Self-Instruct: Aligning Language Model with Self Generated Instructions." arXiv preprint arXiv:2212.10560 (2022).

[7] Liang, Yaobo, et al. "Taskmatrix. ai: Completing tasks by connecting foundation models with millions of apis." arXiv preprint arXiv:2303.16434 (2023).

[8] Li, Minghao, et al. "Api-bank: A benchmark for tool-augmented llms." arXiv preprint arXiv:2304.08244 (2023).

[9] Hao, Shibo, et al. "ToolkenGPT: Augmenting Frozen Language Models with Massive Tools via Tool Embeddings." arXiv preprint arXiv:2305.11554 (2023).

[10] Xu, Qiantong, et al. "On the Tool Manipulation Capability of Open-source Large Language Models." arXiv preprint arXiv:2305.16504 (2023).

[11] Wang, Yizhong, et al. "Self-Instruct: Aligning Language Model with Self Generated Instructions." arXiv preprint arXiv:2212.10560 (2022).

[12] Taori,  Rohan et al. “Stanford Alpaca: An Instruction-following LLaMA model.” (2023).

[13] Trivedi, Harsh, et al. "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions." arXiv preprint arXiv:2212.10509 (2022).

[14] Liu, Jiacheng, et al. "Generated knowledge prompting for commonsense reasoning." arXiv preprint arXiv:2110.08387 (2021).

---

END

扫码加群，

立变AI🍚！

AI范儿读者群

👇关注、标星哦～

那些prompt了我的，

是否也prompt了你...