当前「AI²Paradiam」投资创业范式再思考-暨转译：LLM和它的朋友们形成的B端智能体
图｜Deep(Learning)Focus
▽
题记及AI²Paradiam投资创业范式再思考
「提示工程系列」转译(1)：思维链（CoT）提示-一种实用而简单的LLM“推理”方法
「提示工程系列」转译(2)：实用提示工程-成功提示 LLM 的提示和技巧
「提示工程系列」转译(3)：提示工程进阶-当小样本学习还不足以解决问题怎么办？
「提示工程系列」转译(4)：提示合奏使LLM更可靠-简单策略挖掘更多LLM潜能
从PaL到PoT，用程序辅助语言模型，释放大语言模型推理潜能
△
“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]
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投资创业范式的框架。
如何训练以及prompt你的GPT助手-二进宫OpenAI创始人Andrej倾情奉献「GPT现状」（AI范儿独家解读PPT版）
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更注重提供通用和灵活的语言模型应用开发框架。
转译：大语言模型LLMs和它的朋友们-Gorilla, HuggingGPT, TaskMatrix, and More
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
现代 [ 链接] 和专业 [ 链接] LLMBasic [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]
The Toolformer 工具成型机 [https://cameronrwolfe.substack.com/p/teaching-language-models-to-use-tools]
尽管像 Toolformer 这样的模型是有效的，但它们只考虑一小部分非常简单的 API。这些API几乎没有触及LLM可以使用的工具总数的表面。想象一下，例如，如果我们能够将LLM与通过互联网提供的任何API集成 - 我们可以解锁整个新应用程序和可能性的领域！
△
（几乎）一切皆有可能！这种为语言模型提供广泛在线访问各种 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]中提出的自指令框架开创了使用LLM通过生成可用于微调的综合指令调整数据来训练自己的想法。从与某个任务或指令关联的单个输入输出对开始，自指令提示现成的LLM生成新任务，以及每个任务的有效指令和响应。在执行过滤以删除低质量数据后，我们可以对生成的指令调优数据集上的任何语言模型进行微调。有趣的是，我们发现根据这些数据进行微调的模型往往与通过人工管理的数据集训练的模型的性能相匹配。虽然自指令效果很好，但羊驼也提出了对整体框架的一些改进[12]。
自指令Self-Instruct 2.0 [https://github.com/tatsu-lab/stanford_alpaca#data-generation-process]
信息检索 Information Retrieval
正如我们在之前的概述中看到的那样，基础语言模型的质量往往会随着规模的扩大而提高——大型预训练数据集和模型会产生最佳结果。但是，我们只能在语言模型中包含的固定权重集中存储如此多的信息。即使是大型模型也有有限数量的参数。此外，现代LLM的有限上下文窗口限制了我们只能在模型的提示中注入少量信息。1 那么，如果我们想为我们的LLM提供对大型信息库的访问，我们应该怎么做？这时我们需要采用某种形式的信息检索。
△
矢量数据库｜一种流行的信息检索形式可以通过将LLM与存储大量文本信息的矢量数据库集成来执行。在高层次上，这种与载体数据库（例如松果、Milvus、Weaviate、Redis 等）的集成由以下因素形成：
Chunking the text into small parts.
将文本分成小部分。Producing an embedding for each chunk of text.
为每个文本块生成嵌入。Storing these embeddings in a vector database.
将这些嵌入存储在矢量数据库中。Performing vector similarity search (based on these embeddings) to find relevant chunks of text to include in a prompt.
执行矢量相似性搜索（基于这些嵌入）以查找要包含在提示中的相关文本块。
最终结果是，我们可以快速找到相关的文本信息，以在提示中作为额外的上下文提供，允许LLM利用超出其上下文窗口最大大小的信息。尽管我们仍然无法为模型提供所有信息，但我们可以使用向量相似性搜索来快速识别最相关的部分。
△
这是唯一的办法吗？｜已经提出了许多其他用于信息检索的方法 - 有一个完整的（非常活跃的）研究领域致力于这些技术。我们甚至可以使用 LLM 通过生成的知识提示生成相关信息（而不是检索它）;见上图。下面的文章很好地总结了现有的信息检索技术。
Info Retrieval Survey 信息检索调查 [https://jxmo.io/posts/retrieval]
总体而言，存在许多不同的技术，我们有很多选择来选择如何通过外部信息来源增强LLM。
△
我们为什么要关心？｜信息检索很棒，但我们可能想知道为什么这与将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]
△
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]
△
这是如何工作的？｜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]
△
它表现良好吗？｜在[2]中进行的HuggingGPT评估仅侧重于评估几个不同LLM的任务规划能力，因为任务规划的质量在很大程度上决定了HuggingGPT整体问题解决框架的成功。如下图所示，像GPT-3.5这样的LLM（以及在一定程度上功能较弱的模型）似乎能够有效地将用户请求分解为有效的任务计划。
△
需要做很多工作来改进对这些技术的评估——[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]
△
在[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;见下图。
△
检索感知微调｜Gorilla没有执行“正常”的监督微调，而是利用了“检索感知”的微调变体。这听起来可能很花哨，但实际实现很简单！对于微调数据集中模型 API 的每次调用，我们在数据中添加此 API 的最新文档。然后，我们在测试时遵循类似的方法，将 API 文档附加到我们的提示符中，这教会 LLM 根据文档动态确定每个 API 的正确用法;见下图。
△
检索感知微调是一种技术，它教会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 文档中更改的示例，请参阅上图。
△
使用大猩猩｜尽管我们知道在构建微调数据集时要在提示中包含哪个 API，但在推理过程中收到用户的任意提示时，我们不知道要使用的正确 API。为了确定要使用的正确API，我们可以采用一种信息检索技术，即i）嵌入用户的提示（或其他相关信息）和ii）执行向量相似性搜索以查找最相关的API文档。这样，我们可以轻松有效地确定用于解决问题的最佳 API。或者，我们可以以零镜头的方式使用大猩猩，将用户的提示直接传递给模型，而无需任何信息检索或额外信息。无论哪种方式，Gorilla 的目标都是生成对最合适的 API 的准确调用，以解决用户的提示;见上图。
△
正如上面的实验结果所证明的那样，Gorilla是一个令人难以置信的深度学习API接口。与更大、更强大的模型（例如 GPT-3.5、Claude 和 GPT-4）相比，我们看到 Gorilla 更有能力生成准确的 API 调用，这意味着该模型对不存在的 API 调用产生幻觉的次数更少，并且倾向于传递正确的输入参数！
其他值得注意的技术...
HuggingGPT [2] 和 Gorilla [3] 在过去的几个月里获得了很多公众的认可和讨论，但已经提出了许多其他技术，考虑使用 LLM 来协调几种不同深度学习模型的工作。下面概述了其他有趣技术的简要列表。
△
TaskMatrix [7]｜ 是一份立场文件——这意味着它提出了对一个值得注意的问题的立场或展望——它考虑了基础模型（例如，像 ChatGPT 这样的 LLM）与数百万种不同 API 的集成。值得注意的是，这项工作认为基础模型缺乏准确解决专业任务所需的领域知识，但许多现有的、特定于任务的模型可以以令人印象深刻的精度解决特定任务。由于兼容性问题，将这些专业/专家模型与LLM集成可能很困难，但是[7]中的作者广泛讨论和考虑了这个想法。在许多方面，HuggingGPT和Gorilla是[7]中讨论的想法的实际实现。
△
API Bank [8] ｜为评估工具增强型 LLM 提供了更好的基准。特别是，该基准测试考虑了通常与LLM集成的50多个API和264个带注释的对话（总共包括568个API调用）与这些工具一起使用。该基准测试旨在评估LLM创建任务计划（即执行哪些API调用的分步指南），确定要使用的正确API以及执行API调用以回答所提供问题的能力。不出所料，初步实验表明，GPT-4 在利用外部工具回答用户提供的问题方面具有最强大的能力。尽管这项工作没有特别考虑深度学习模型API，但使用的任务框架反映了本概述中看到的方法。
△
ToolkenGPT [9]｜ 试图通过为每个工具分配特定的令牌和关联的令牌嵌入来缓解工具遵循基础模型的微调要求，从而允许 LLM 以类似于生成普通单词标记的方式生成工具请求。发现这种方法在利用各种外部工具方面非常灵活。
△
使用开源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]
“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).
END
扫码加群，
立变AI🍚！
AI范儿读者群
那些prompt了我的，
是否也prompt了你...