大模型系列｜基于大模型复杂数据系统架构（二）_基于大模型的架构

张俊林老师在 2023 WAIC AI 开发者论坛的演讲非常有概括性，这边沿着思路进行一定的整理。（文章来源：WAIC 2023 | 张俊林：大语言模型带来的交互方式变革）

---

1 Planning+Programming 模式的系统技术架构

基于大模型的数据系统要实现更加智能的自动化，要将LLM大模型放在大脑中枢位置，张老师的这页概括了依靠大模型的理解能力，下游需要的两个大模块：

• 任务规划（复杂的任务，将它先拆成若干个简单任务，然后再逐个解决）
• 形式化语言（Programming（程序）、API、SQL、模块调用）

这里的任务规划有点类似“把大象放进冰箱”的任务拆解。来看张老师的一个举例，SheetCopilot：

用户可以发出一个查询：
「把销售额在 200-500 之间的记录点亮。」

LLM（这里是 GPT-4）首先会把这个任务规划成子任务，这里是三个子任务：

• 1）先筛选出销售额在 200-500 之间的条目(写 prompt,再把表格的 schema（即表格每一列的含义）告诉它。GPT-4 就会生成一个 API)
• 2）把背景点亮成蓝色；
• 3）把点亮的数据嵌入回表格。

其中这里需要使用Text-to-SQL 的技术（可参考：大模型与数据科学：从Text-to-SQL 开始（一）），比如，谷歌的SQL-PaLM 操作数据库的方式有两种：

• 一是在上下文学习（in-context learning）, 也就是给模型一些例子，包括数据库的 schema、自然语言的问题和对应的 SQL 语句，然后再问几个新问题，要求模型输出 SQL 语句
• 另一种方式是微调（fine-tuning）

在比较复杂的数据库表上，其准确率为 78%，已经接近实用化水准了。这意味着随着技术的进一步快速发展，很可能 SQL 语句不需要人写了

参考文献：
WAIC 2023 | 张俊林：大语言模型带来的交互方式变革

---

2 HuggingGPT的Prompt架构

参考HuggingGPT：

LLM作为控制器（Controller），用来理解用户需求，然后结合HuggingFace社区的模型，将用户任务分解为：

• 任务规划（Task Planning）
• 模型选取（Model Selection）
• 任务执行（Task Execution）
• 响应生成（Response Generation）

HuggingGPT综合使用了:

• “基于规范的指令”（specification-based instruction）
  是指对Task做了规范约束，必须是下面的这种格式，包含任务内容（task）、任务id（id）、任务依赖（dep）和参数（args）等四个要素：

[{"task": task, "id", task_id, "dep": dependency_task_ids, "args": {"text": text, "image": URL, "audio": URL, "video": URL}}]
1

• “基于示范的解析”（demonstration-based parsing）
  Prompt中给它提供了若干“示例”（Demonstrations）。这会激发大模型的基于上下文学习（In-Context Learning）或者叫做Few-shot learning能力，从而产生更好的理解和生成。

参考文献：
硬核Prompt赏析：HuggingGPT告诉你Prompt可以有多“工程”

---

3 数据系统：Data-Copilot

Data-Copilot: 大语言模型做你最贴心省事的数据助手

号称：无需繁琐操作,只需要输入一句话, Data-Copilot自动帮你完成查数据,分析数据,管理数据,预测趋势,还可以画图做表

接口设计：我们设计了一个self-request的过程，使LLM能够自主地从少量种子请求生成足够的请求。然后，LLM根据生成的请求进行迭代式的设计和优化接口。这些接口使用自然语言描述，使它们易于扩展和在不同平台之间转移。
接口调度：在接收到用户请求后，LLM根据自设计的接口描述和in context demonstration来规划和调用接口工具,部署一个满足用户需求的工作流，并以多种形式呈现结果给用户。

此时该系统也是符合：Planning+Programming 模式。其中：

• LLM根据自设计的接口描述和in context demonstration来规划任务实现Planning；
• 还有该系统的Programming 核心是利用LLM强大的代码生成能力为接口库中的每个接口生成具体的代码(interface implementation)
  

来看一个例子：

用户问题: 预测下面四个季度的中国季度GDP
部署工作流：获取历史GDP数据----> 采用线性回归模型预测未来----->输出表格

---

4 ToolLLM：让LLM 指挥API

我组联合面壁智能给大模型接入16000+真实API，效果直逼ChatGPT！

ToolLLM 框架包括如何获取高质量工具学习训练数据、模型训练代码和模型自动评测的全流程。
作者构建了 ToolBench 数据集，该数据集囊括 16464 个真实世界 API。

尽管已经有一些工作（例如Gorrila、APIBank等）探索了如何让LLM掌握API调用能力，这些工作仍然存在以下局限性：

• 有限的API：很多研究没有使用真实世界的API（如RESTful API），存在API范围有限、多样性不足的问题

• 场景受限：先前工作大多集中在单一工具的使用，而实际场景中可能需要多个工具协同工作来完成复杂任务；此外，现有研究通常假设用户提供与指令相关的API，但现实中可供选择的API可能非常多，用户难以从中高效选择

• 模型规划和推理能力不足：现有模型推理方法如CoT、ReACT过于简单，无法充分利用LLM的潜力来处理复杂指令，因而难以处理复杂任务

4.1 API收集

API 收集分为 API 爬取、筛选和响应压缩三个步骤。

• API 爬取：作者从 RapidAPI Hub 上收集了大量真实多样的 API。RapidAPI 是一个行业领先的 API 提供商，开发者可以通过注册一个 RapidAPI 密钥来连接各种现有 API。所有 RapidAPI 中的 API 可以分为 49 个类别，例如体育、金融和天气等；每个类别下面有若干工具，每个工具由一个或多个 API 组成
• API 筛选：作者对在 RapidAPI 收集到的 10,853 个工具（53,190 个 API）基于能否正常运行和响应时间、质量等因素进行了筛选，最终保留了3,451 个高质量工具（16,464个API）
• API 响应压缩：某些 API 返回的内容可能包含冗余信息导致长度太长无法输入 LLM，因此作者对返回内容进行压缩以减少其长度并同时保留关键信息。基于每个API的固定返回格式，作者使用 ChatGPT 自动分析并删除其中不重要信息，大大减少了 API 返回内容的长度

4.2 指令生成

作者采用自底向上的方法进行工具指令生成，即从收集的 API 入手，反向构造涵盖各种 API 的指令。具体而言，作者首先从整个 API 集合中采样各种各样的 API 组合，接着通过 prompt engineering 让 ChatGPT 构思可能调用这些 API 的指令。
其中 prompt 包括了每个 API 的详细文档，这样 ChatGPT 能够理解不同 API 的功能和 API 之间的依赖关系，从而生成符合要求的人类指令。具体的采样方式分为单工具指令（指令涉及单工具下的多个 API）和多工具指令（指令涉及同类或跨不同类的工具的多个 API）。通过该方法，作者最终自动构造逾 20 万条合格的指令。