LLM整合多个函数调用的新思路！LLMCompiler：用于并行函数调用的LLM编译器

最新推荐文章于 2024-10-08 20:27:53 发布

Python编程杰哥

最新推荐文章于 2024-10-08 20:27:53 发布

阅读量448

点赞数 4

文章标签：人工智能百度 oracle 数据库知识图谱

本文链接：https://blog.csdn.net/xx_nm98/article/details/140858818

版权

UC Berkeley联合LangChain于23年12月发布了用于执行并行函数调用的大模型编译器——LLMCompiler。借鉴传统编译原理，LLMCompiler通过三个组件简化并行函数调用：(i)一个函数调用规划器，用于分析语义并拆解任务，从而制定执行计划；(ii)一个任务获取单元，分发函数调用任务；以及(iii)一个执行器，以并行方式执行这些任务。LLMCompiler项目当前已经开源，开源地址：https://github.com/SqueezeAILab/LLMCompiler。

1、引言

随着LLMs逐渐具备了整合各种工具和函数调用的能力，逐渐使开发LLM软件的范式发生根本性的转变。然而这引出一个重要挑战：_最有效的调用整合多个函数的方法是什么？_ReAct目前取得了比较不错的效果，然而其串行调用执行的特点导致了大量的时延成本。

为了解决这一挑战，来自伯克利BAIR团队的作者们从传统编译原理中汲取灵感，在传统编程语言中，优化指令执行已被广泛探索。编译器中的一个关键优化技术包括识别可以并行执行的指令并有效管理它们的依赖关系。受此启发，作者可以设想一个为LLM函数调用量身定制的编译器，从而高效地协调各种函数调用及其依赖关系。这与最近将LLMs与计算机系统对齐的研究有着相似的哲学。为此，作者介绍了LLMCompiler，这是一个新颖的框架，它使LLMs能够在不同的模型和工作负载中并行执行多个工具。据作者所知，LLMCompiler是第一个优化LLM函数调用编排的框架，不仅可以通过最小化中间函数调用输出的干扰来提高延迟和成本，还可以提高准确性。

2、方法论

为了说明LLMCompiler的组件，作者使用上图中的一个简单的双向并行示例。要回答“微软的市值需要增加多少才能超过苹果的市值？”这个问题，LLM首先需要对这两家公司的市值进行网络搜索，然后进行除法操作。虽然现有的框架，包括ReAct，在执行这些任务时是顺序的，但很明显这些任务可以并行执行。关键问题是如何自动确定哪些任务是可以并行的，哪些是相互依赖的，以便作者能够相应地协调不同任务的执行。LLMCompiler通过一个系统实现这一点，该系统由以下三个组件组成：函数调用规划器（Function Calling Planner），用于生成任务序列及其依赖关系；任务获取单元（Task Fetching Unit），根据中间结果替换参数并获取任务；执行器（Executor），使用相关工具执行任务。要使用LLMCompiler，用户只需要提供工具定义，以及规划器的可选上下文。

函数调用规划器

函数调用规划器负责生成要执行的任务序列以及它们之间的任何依赖关系。例如，图2中的任务$1和$2是两个可以并行执行的独立搜索。然而，任务$3依赖于第一次和第二次搜索的结果。因此，规划器的作用是使用LLMs的复杂推理能力自动识别必要的任务、它们的输入参数以及它们的相互依赖性，本质上形成了任务依赖的有向无环图（DAG）。如果一个任务依赖于前面的任务，它就会包含一个占位符变量，如任务$3的$1，稍后将用前面任务的实际输出替换。LLMCompiler中的规划器利用LLMs的推理能力从自然语言输入中分解任务。为了实现这一点，规划器LLM包含了一个预定义的提示，指导它如何创建依赖图并确保正确的语法。除此之外，用户还需要为规划器提供工具定义和可选的上下文示例。这些示例提供了特定于问题的任务分解的详细演示，帮助规划器更好地理解规则。

任务获取单元

任务获取单元受到现代计算机架构中指令获取单元的启发，根据贪心策略，一旦任务准备好（并行）执行，就立即将任务获取到执行器。另一个关键功能是使用前面任务的实际输出替换最初由规划器设置的占位符变量。如，在图，一旦搜索任务完成，任务$3中的变量$1和$2将被微软和苹果的实际市值所替换。这可以通过一个简单的获取和排队机制来实现，而不需要专用的LLM。

执行器

执行器异步执行从任务获取单元获取的任务。由于任务获取单元保证了所有调度给执行器的任务都是独立的，它可以简单地同时执行它们。执行器配备了用户提供的工具，并将任务委托给相关工具。这些工具可以是简单的函数，如计算器、维基百科搜索或API调用，也可以是针对特定任务量身定制的LLM代理。如示意图的执行器模块所示，每个任务都有专用的内存来存储其中间结果，这与典型的顺序框架在聚合观察结果作为单个提示时所做的类似。任务完成后，最终结果将作为输入转发给依赖于它们的任务。

动态重规划

在各类应用中，执行图可能需要根据中间结果进行调整。在编程中的一个类似比喻是分支，执行路径仅在运行时确定，这取决于满足哪个分支条件。这样的动态执行模式也可以出现在LLM的函数调用中。对于简单的分支（例如，if-else语句），人们可以静态编译执行流程，并根据中间结果动态选择正确的分支。然而，对于更复杂的分支，可能更好地基于中间结果进行重新编译或重规划。在重规划中，执行器将中间结果发送回作者的LLM规划器。基于此，规划器生成一组新的任务及其相关依赖关系，并将它们分派给任务获取单元，然后是执行器。这个过程会重复进行，直到最终结果达成。

3、LLMCompiler细节

用户需提供的信息

LLMCompiler 需要用户输入以下两种信息：

工具定义：用户需要指定LLMs可以使用的工具，包括它们的描述和参数规范。用户还可以选择性地提供展示这些工具使用方式的上下文示例。这基本上与其他框架如ReAct和OpenAI函数调用的要求相同。
规划器的上下文示例：用户可以为规划器提供示例，说明规划器应如何表现。例如，用户可以提供展示特定查询预期任务间依赖关系的示例。这些示例可以帮助规划器LLM为输入生成适当的依赖图和正确格式。

流式规划器

规划器在处理涉及许多任务的用户查询时可能会产生巨大开销，因为它会阻塞任务获取单元和执行器，这些单元必须等待规划器输出后才能启动它们的进程。然而，通过使规划器能够异步地流式传输依赖图，可以类比于现代计算机系统中的指令流水线，从而允许每个任务在解决其依赖性后立即由执行器处理。通过在不同基准测试中使用和不使用流式机制的LLMCompiler的延迟比较，结果表示流式传输可以一致地改善延迟。特别是在ParallelQA基准测试中，流式传输功能可以将延迟提高达1.3倍。这归因于ParallelQA的数学工具的执行时间较长，可以有效隐藏规划器生成后续任务的延迟，而HotpotQA和电影推荐中使用的搜索工具的执行时间较短则做不到这一点。

4、评估结果

在本节中，作者使用各种模型和问题类型来评估 LLMCompiler。使用了专有的 GPT 模型和开源的 LLaMA-2 模型，后者展示了 LLMCompiler 在启用开源模型中的并行函数调用方面的能力。此外，还有各种类型的并行函数调用模式可以通过 LLMs 来解决。这包括从简单的并行模式，即所有任务可以并行执行且它们之间没有任何依赖关系，到更复杂的依赖模式，值得注意的是，作者还评估了 LLMCompiler 在基于中间结果进行动态重规划的 Game of 24 基准测试上的表现，突出了其适应动态依赖图的能力。最后，作者将 LLMCompiler 应用于 WebShop 基准测试，以展示其在决策任务方面的潜力。在本节中，作者首先介绍简单执行模式的结果，然后转向更复杂的模式。

作者在不同的基准测试上将 LLMCompiler 与基线进行了准确性和延迟的比较，包括 HotpotQA、电影推荐、作者自定义的数据集 ParallelQA 和 24 点游戏。对于 HotpotQA 和电影推荐，作者经常观察到循环和提前停止。作者尽可能地加入了 ReAct 特定的提示以最小化这些行为，作者将其表示为 ReAct†。ReAct 表示没有这种提示的原始结果。由于循环和提前停止使得精确的延迟测量变得困难，作者没有包括原始 ReAct 的延迟。

下面我们以并行函数调用为例看一看相关实验的评估结果。

并行函数调用

最简单的场景涉及 LLM 重复使用工具进行独立任务，例如进行并行搜索或分析以收集不同主题的信息，如图 3(a) 所示的模式。虽然这些任务彼此独立并且可以并行执行，但 ReAct 以及其他现有的 LLM 解决方案将需要按顺序运行。这导致了由于每个工具使用时频繁调用 LLM 而导致的延迟增加和令牌消耗增加，如图 1 所示。在这一部分，我们展示了 LLMCompiler 如何识别可并行化的模式，并执行独立任务以并发解决这个问题，使用以下两个基准测试：

HotpotQA: 一个评估多跳推理的数据集，只使用比较开发集。包含1.5k个比较两个不同实体的问题，因此展示了2路并行执行模式。
电影推荐：一个包含 500 个示例的数据集，要求从四个选项中识别出与另一组四部电影中最相似的电影，展示了8路并行模式。

实验设置

作为基线方法，我们将 LLMCompiler 与 ReAct 进行了比较。我们遵循 ReAct 的设置，使用相同的维基百科搜索工具，LLM 可以使用它来搜索信息。我们没有包括查找工具，因为它与我们的问题设置无关。我们已经为 ReAct 和 LLMCompiler 优化了提示和上下文示例。对于这些数据集的所有实验，我们使用了 gpt3.5-turbo (1106 版本)。对于使用 GPT 的实验，我们还报告了使用 OpenAI 的并行函数调用功能的实验结果，该功能与我们的工作同时宣布。我们还展示了如何将 LLMCompiler 与开源 LLaMA-2 70B 模型有效结合，为模型提供并行函数调用能力。对于所有实验，我们测量了准确性、端到端延迟以及输入和输出令牌使用情况。有关实验设置的更多详细信息。

准确性和延迟

实验结果体现了与ReAct相比，LLMCompiler 的准确性、端到端延迟和相对加速。首先，我们观察到ReAct与OpenAI并行函数调用和LLMCompiler相比，始终保持着较低的准确性。

我们确定了 ReAct 的两个主要失败模式：(1) 冗余生成先前函数调用的倾向，这也是原始 ReAct 论文中指出的一点；(2) 基于不完整的中间结果过早停止。在附录 A.1 中，我们提供了一个详细分析，展示了这两种普遍的失败案例如何显著损害 ReAct 的准确性，以及它们如何被 LLMCompiler 解决，从而将准确性提高多达 7% - 8%。此外，我们还进行了干预实验，在其中我们加入了 ReAct 特定的提示，以避免重复函数调用和提前停止。ReAct 特定的提示使 ReAct† 的准确性普遍提高，与原始 ReAct 相比。尽管如此，LLMCompiler 仍然展示了与 ReAct† 相当甚至更好的准确性，因为这种提示并不能作为完全避免 ReAct 错误行为的完美解决方案。此外，与 ReAct† 相比，LLMCompiler 在 HotpotQA 基准测试上展示了 1.80× 和 1.40× 的显著加速，分别使用了 GPT 和 LLaMA。同样地，在电影推荐基准测试上，每种模型都展示了 3.74× 和 2.82× 的加速。请注意，我们将 LLMCompiler 的延迟与 ReAct† 的延迟进行了基准测试，因为如上文讨论的原始 ReAct 的重复和提前停止行为使其延迟不可预测，不适合进行公平比较。与 OpenAI 并行函数调用相比，LLMCompiler 展示了高达 35% 的加速，而 OpenAI 并行函数调用在每个基准测试上的延迟增益分别为 1.61× 和 2.76×。

成本

使用 LLMs 的另一个重要考虑因素是成本，这取决于输入和输出令牌的使用情况。GPT 实验的成本在表 2 中提供。由于涉及较少频率的 LLM 调用，LLMCompiler 在成本方面比 ReAct 更具成本效益。有趣的是，LLMCompiler 还在成本效率方面超过了 OpenAI 最近的并行函数调用。这是因为 LLMCompiler 的计划阶段比 OpenAI 并行函数调用更具提示长度效率，因为我们的计划者的上下文示例相当短，只包括计划，而不是观察结果（见附录 A.7）。

5、总结

现有的方法在利用大型语言模型（LLMs）调用多个函数时，通常采用顺序和动态推理，导致在延迟、成本和准确性方面存在效率低下的问题。为了解决这些问题，我们介绍了LLMCompiler，这是一个受编译器启发的框架，它能够跨不同LLMs实现高效的并行函数调用，包括开源模型如LLaMA-2和OpenAI的GPT系列。通过将用户输入分解为具有定义的相互依赖性的任务，并通过其规划器、任务获取单元和执行器组件并发执行这些任务，LLMCompiler在延迟（最高达3.7倍）、成本效率（最高达6.7倍）和准确性（最高达约9%）方面展示了显著的改进，甚至在延迟增益方面超过了OpenAI的并行函数调用功能。基于LLMCompiler的进一步探索将增强并因此彻底改变基于LLM的应用的未来发展。我们期待未来的工作能够基于我们的框架，提高LLM执行复杂、大规模任务的能力和效率，从而转变基于LLM的应用的未来发展。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述