Multimodal Foundation Models:From Specialists to General-Purpose Assistants（Chapter 6-7）

Multimodal Foundation Models:From Specialists to General-Purpose Assistants

Chapter 6  Multimodal Agents: Chaining Tools with LLM

研究人员现在正在探索一种新的建模范式，从解决有限的预定义问题的独立模型转变为将多个工具或专家与LLM协同链接，以解决复杂的开放问题。

6.1 Overview

建模范式的演变，从特定任务的模型到最新的大型多模式模型，这些模型都需要数据和模型训练。将工具与LLM链接的新建模范式，它可能不需要任何训练，而是直接利用预先训练的LLM和通过开源平台或API广泛可用的现有工具。

LLM在数学推理和信息检索等基本功能方面仍面临挑战。此外，LLM以及当今其他大型模型的一个根本局限性是，它们只代表其训练数据所描述的世界，随着时间的推移，这些数据将不可避免地过时。用最新信息定期重新训练模型是不可行的。

同时，许多具有现实影响的任务不能仅靠LLM轻易解决。例如，访问最新信息和执行计算可以通过现有工具（例如，搜索引擎或计算器）完成。因此，最近在语言建模方面的研究探索了一种新的建模范式，通过用外部NLP工具补充LLM，包括计算器、搜索引擎、翻译系统、日历，甚至API对其他模型的调用。上述研究主要集中在一个单一的模态上，即语言，其中工具的输出是文本格式的，因此可以自然地作为附加知识输入LLM。然而，我们生活在一个多模式的世界中，一个真正的智能体应该能够执行高级的多模式推理和动作。如何通过工具使用使LLM能够感知多模式信号，是本章剩余部分的重点。

6.2 Multimodal Agent

用户直接与工具分配器（tool allocator）进行交互，工具分配器作为代理的大脑发挥作用。在当前的文献中，工具分配器通常是LLM。为了实现用户的目标，LLM将概述使用单个工具或将多个工具协作在一起所需的所有步骤。随后，它将从所有候选工具中检索所需工具，并执行可能的多轮工具以满足人类需求。最后，收集来自工具的执行结果作为LLM的输入，以生成对用户的响应。

Tools：工具tools是LLM可调用的外部模块，用于获取模型权重中缺少的额外信息，包括开源模型、公共/私有API或代码间预编码器。由于LLM只接受语言输入，因此必须包括可以处理多模式输入的工具，以构建多模式代理.

Planning：在规划过程中，LLM将用户请求分解为更小的、可管理的子问题，并概述了一个循序渐进的解决方案，每个解决方案都涉及调用外部工具。有两种方法可以教授LLM进行规划。一种是在上下文中用所有候选工具的少数示例in-context few-shot提示LLM。这种方法可以直接扩展通用模型，但受上下文长度的限制。另一种方法依赖于大量的注释数据来微调LLM，这很可能会损害模型的稳健性和可推广性。

Execution：生成的计划被进一步转换为对所需工具的可执行调用，这可以通过正则表达式匹配来完成；直接提示LLM生成可执行程序；或者通过提供描述每个模块的角色的自然语言指令以及一些调用示例，在上下文中利用LLM的in-context few-shot learning能力。执行结果反馈给LLM以生成对用户的响应。

6.3 Case Study: MM-REACT

6.3.1 System Design

6.3.2 Capabilities

6.3.3 Extensibility

构建多模态代理的工具链的一个有利特性是，该系统可以从两个角度轻松扩展和增强。一个是升级系统的核心部分LLM，另一个是扩大外部工具的数量。

涉及一个模型：RestGPT，它提出了一个多层次的在线规划框架，该框架有效地处理了与100多个RESTful API集成LLM相关的实际挑战。

6.4 Advanced Topics

6.4.1 Comparison to Training with LLM in Chapter 5

第五章和第六章介绍了基于LLM构建高级多模态系统的两个方向。作为关键区别，本章中的多模态代理利用LLM的高级规划能力来分配各种多模态工具，而第5章中使用LLM训练多模态模型仅利用LLM进行基于多模态输入的文本生成。

尽管如此，这两种方法都显示出各自的优点和缺点。一方面，指令调优实现了一个端到端模型，该模型直接解释多模态输入中丰富的语义，但需要数据管理和训练，因此计算成本更高。然而，在某些情况下，有限的指令调整数据可能会限制其功能，例如OCR。另一方面，通过将LLM与丰富的现成模型/API/代码解释器链接起来作为工具，并利用上下文中的少量示例来教授LLM规划，可以在没有任何培训的情况下构建多模态代理。然而，由于没有培训，该系统可能无法找到正确的工具。此外，弱领域专家可能会产生有噪声的输出，这可能会混淆LLM在规划或推理方面的表现，导致弱性能。

尽管这两种方法表现出不同的变化，但我们设想了一种融合两种范式优势的中间领域的可能性，并提出了以下问题。既然我们有了LLaVA等开源LMM，我们能用LLaVA代替LLM作为工具分配器吗？如果是，需要启用哪些功能？以及通过指令调整可以解决哪些问题。这些都是有趣的方向，在不久的将来可能值得探索。

6.4.2 Improving Multimodal Agents

Composing tools via code generation

大多数现有的多模式代理使用自然语言来提示LLM计划使用哪种工具。探索使用编程语言来实现更准确的执行。可视化编程是沿着这个方向的突出工作，它使用GPT-3的上下文学习能力，从自然语言指令生成类python模块化程序，用于合成视觉任务ViperGPT指示GPT-3 Codex生成python代码，以合成用于一轮查询应答的多模式工具。然而，由于代码仍然是由LLM生成的，因此工具使用不准确的问题仍然存在。

Improving accuracy in tool using: self-assessment

最近的一项工作AssistGPT试图通过自我评估来提高工具使用的准确性。

Improving accuracy in tool using: instruction tuning

关于提高工具使用准确性的另一个线索是将系统与指令调整相结合。可以通过自构造生成指令-API对的数据集，以调整较小的LLM（例如，Vicuna-7B）。

LMM as the tool allocator?

随着LMM的发展，我们设想LLM可以被LMM取代，作为系统中的工具分配器，以实现更高级的应用场景。如果工具分配器可以接受多模式输入，则无需将工具的输出统一为文本序列，从而允许工具分配器和多模式工具之间更自然的交互，特别是那些产生多模式输出的工具。

6.4.3 Diverse Applications of Multimodal Agents

6.4.4 Evaluation of Multimodal Agents

6.4.5 Tool Creation

6.4.6 Retrieval-Augmented Multimodal Agents

Chapter 7  Conclusions and Research Trends