深度长文：产品经理视角解析AutoGPT背后的技术原理

本文主要讲的内容：

类AutoGPT应用的背后技术原理。

更抽象一层，其实是解释：LLM（GPT）是怎么实现自己学会使用工具的？

1）LLM怎么将人类需求分解成任务；

2）LLM怎么知道什么任务要使用什么外部工具；

2）LLM怎么学会使用这些外部工具的；

---大约5300字，概览如下：

1、为什么研究这个（LLM是怎么学会使用外部工具的）

2、介绍这个领域几个关键产品产品的原理：LangChain、Toolformer、OpenAi-Plugin、huggingGPT、Babyagi、AutoGPT

3、LLM目前使用外部工具的局限是什么？

4、OpenAi-Plugin的数据飞轮

---正文开始---

一、为什么研究这个

一方面，源于我对LLM有一定认知之后，做出的一个判断“未来会出现All in one chatbot”

也就是未来每个人都会有一个基于LLM的IM助手（准确来说是智能助手，虽然说可能无处不在，但是最先落地的一定是IM也就是目前的这种chatbot，用文字或者语音交互）

我只需要跟这个IM发指令，IM就可以理解指令，并且调用外部工具，给到我对应的东西。

举个畅想的例子：用户说：“我中午想点一份40块以内的川菜外卖”，IM会返回一个符合我要求的川菜外卖列表。然后我再点选一个进行下单即可。

这个畅想（openai plugin已经有这样的影子了）往终局来说：

1）会导致目前的APP形态发生很大改变，目前这些APP是为人设计的。未来这些APP更多需要考虑是为LLM设计。

2）在这个设想下，大部分的APP可能不再有自有流量。人们都是通过IM借助LLM来发现并使用这些APP。某种意义上所有目前的APP的用户都会变成LLM，最终再由LLM再提供给人。

我其实一直挺想求证一下，我的这个畅想离现实到底有多远，实现上有什么阻碍。

这不巧了么，最近类似的工具或者论文层出不穷。

LangChain、Toolformer、OpenAi-Plugin、huggingGPT、Babyagi、AutoGPT

其实现这个畅想的要解决的核心问题都是类似的：

1）LLM怎么分解人类指令？2）LLM怎么知道用什么工具？3）LLM怎么才能会用工具？

另一方面，作为一个产品经理，其实对看论文这件事其实挺抵触的（论文这两个字给我的心理压力暗示非常大）。

但是，你不阅读一手内容，似乎总差点意思。所以先从这个偏应用的课题入手，开始看看论文（看了几篇，发现还好，可能是偏应用的原因吧hhh）。

二、对这个领域关于应用&论文的原理简介

依次：LangChain、Toolformer、OpenAi-Plugin、HuggingGPT、BabyAGI、AutoGPT

我追溯了一下LangChain应该是这个应用思路（让LLM自己学会使用外部工具）的鼻祖，时间上LangChain 20221023就发布了第一个版本

所以先介绍LangChain

这部分主要会介绍LangChain让LLM使用外部工具的思路和原理，其他部分暂时不做介绍（强烈建议大家都可以去了解下）

LangChain针对不同场景，有不同的使用外部工具的思路，分为Chain和Agent

Chain概念：

1）在特定的场景下，完成特定的任务

2）约束条件：用户的需求是同一类（比如计算）

3）核心：让LLM根据提供的API文档，结合用户的自然语言，组装正确的API调用参数

链接：https://python.langchain.com/en/latest/reference/modules/chains.html#langchain.chains.APIChain.api_docs

Agent概念：

1）在用户需求无法限定的场景，完成更广泛的任务。

2）核心：Agent增加了一个功能，就是根据用户的输入自己去判断应该使用什么工具（在提供的有限的工具list里），然后去使用工具，最后满足用户需求。

链接：https://python.langchain.com/en/latest/reference/modules/agents.html

接下来详细展开两者的实现原理

Chain的实现原理

1）告诉LLM工具使用手册：工具（其实就是API）的使用文档，即api_docs

2）告诉LLM用户的问题

3）让LLM基于上述两个信息，组装可以解决用户问题的API请求

具体的prompt如下：

You are given the below API Documentation:{api_docs}

Using this documentation, generate the full API url to call for answering the user question.
You should build the API url in order to get a response that is as short as possible, while still getting the necessary information to answer the question. Pay attention to deliberately exclude any unnecessary pieces of data in the API call.

Question:{question}
API url: {api_url}

Here is the response from the API:{api_response}

Summarize this response to answer the original question.
Summary:

其实我一直对LLM是怎么学会组装正确的API请求参数的，一直有些疑问，去翻了一下源代码，api_docs的内容大概是这个样子（有点像OpenAPI的格式）

api_docs = """ 
This API endpoint will search the notes for a user. 
Endpoint: thisapidoesntexist.com 
GET /api/notes 
Query parameters: q | string | The search term for notes 
"""
端点（Endpoint）：thisapidoesntexist.com
请求方法：GET
路径（Path）：/api/notes
查询参数（Query parameters）：q：字符串类型，用于表示搜索的关键词

这是一个搜索API的例子，假设要query的内容是example，LLM输出的api_url会是：

https://thisapidoesntexist.com/api/notes?q=example

Agent的实现原理

简而言之，就是在Chain的基础上，让LLM先分解任务，然后再根据每个任务自动根据用户的问题去找到合适的工具

ps：目前还是在给定的几个工具范围内找，这个范围受限于LLM的prompt长度限制，目前需要指定。

话不多说，看prompt你就秒懂了

Answer the following questions as best you can. 
You have access to the following tools: 
Calculator: Useful for when you need to answer questions about math. 
Weather: useful for When you want to know about the weather 

Use the following format: 
Question: the input question you must answer 
Thought: you should always think about what to do 
Action: the action to take, should be one of [Calculator, Weather] 
Action Input: the input to the action 
Observation: the result of the action ...
(this Thought/Action/Action Input/Observation can repeat N times) 

Thought: I now know the final answer 
Final Answer: the final answer to the original input question 
Begin! 
Question: Query the weather of this week,And How old will I be in ten years? This year I am 28 
Thought:

中文翻译版：
尽最大努力回答以下问题。
您可以使用以下工具：
计算器：在需要回答数学问题时很有用。
天气：在想了解天气时很有用

请使用以下格式：
问题：您必须回答的输入问题
思考：您应该始终考虑要做什么
行动：采取的行动，应该是[计算器，天气]之一
行动输入：输入到操作的内容
观察：行动的结果...
（这个Thought/Action/Action Input/Observation可以重复N次）

思考：我现在知道了最后的答案
最终答案：对原始输入问题的最终答案

开始！
问题：查询本周天气，并询问十年后我多大了？今年我28岁
思考：

Toolformer介绍

Toolformer是meta发的一篇关于，LLM怎么自己学会用外部工具的论文

地址：https://arxiv.org/pdf/2302.04761.pdf

了解完LangChain的思路后，其实Toolformer的思路大差不差。

Toolformer是一个经过微调的模型，能够决定何时调用哪些API、传递哪些参数，以及如何将结果最佳地融入未来的token预测。

大概过程：

1）先用完整的句子，让LLM自己插入API指令。指令后面的原文其实就是答案。

2）执行API，计算API获得信息和原文答案之间的差异度，如果差异度ok的话，这条原文+正确位置插入正确API问题的数据，就会成为训练数据集。

3）通过这个训练数据集，去fine-tune这个模型。从而让模型可以知道：

a、在什么地方，应该去调用外部API获取信息。

b、要调用什么工具（论文里主要训练了模型用QA、计算器、翻译、wiki搜索，这4种工具）。

c、调用工具需要组装的正确参数是什么。

OpenAi-Plugin原理

话不多说，直接上和GPT-4的对话

图片里‘---’前面的内容是复制了openai官方文档里的一个plugin的示例的ai-plugin.json、和这个示例的OpenAPI specification

链接：https://platform.openai.com/docs/plugins/examples

HuggingGPT的原理

HuggingGPT是一个希望“让语言作为接口，让大型语言模型（LLM）能够连接众多AI模型，解决复杂AI任务”的框架。

这个框架的主要流程如下：

1）任务规划：使用ChatGPT分析用户请求以理解他们的意图，并通过提示将其拆解为可能可解决的任务。

2）模型选择：为了解决计划好的任务，ChatGPT根据模型描述从Hugging Face中选择合适的模型。

3）任务执行：调用并执行每个选定的模型，并将结果返回给ChatGPT。

4）整合结果：最后，使用ChatGPT整合所有模型的预测，并为用户生成答案

可以看具体的prompt加深理解：

parse_task（分解任务）:
The chat log [ {{context}} ] may contain the resources 
I mentioned. Now I input { {{input}} }. Pay attention to 
the input and output types of tasks and the dependencies 
between tasks.

choose_model（选择模型）:
Please choose the most suitable model from {{metas}} for 
the task {{task}}. The output must be in a strict 
JSON format: 
{"id": "id", "reason": "your detail reasons for the choice"}.

response_results（整合结果）:
Yes. Please first think carefully and directly answer my 
request based on the inference results. Some of the 
inferences may not always turn out to be correct and 
require you to make careful consideration in making 
decisions. Then please detail your workflow including 
the used models and inference results for my request in 
your friendly tone. Please filter out information that 
is not relevant to my request. Tell me the complete path 
or urls of files in inference results. If there is 
nothing in the results, please tell me you can't make it.

论文地址：https://arxiv.org/pdf/2303.17580.pdf

BabyAGI原理介绍

其实你会发现一脉相承，大家的核心思路都是差不多的

BabyAGI核心：1）根据需求分解任务；2）对任务排列优先级；3）执行任务并整合结果；

核心prompt

task_creation_agent
你是一个任务创建人工智能，使用执行代理的结果来创建新任务，
其目标如下：{目标}。最近完成的任务的结果是：{结果}。
该结果是基于以下任务描述的：{任务描述}。这些是未完成的任务：
{', '.join(task_list)}。根据结果，创建新的任务以供AI系统完成，
不要与未完成的任务重叠。将任务作为数组返回。

prioritization_agent
你是一个任务优先级人工智能，负责清理和重新优先处理以下任务：
{task_names}。请考虑你的团队的最终目标：{OBJECTIVE}。
不要删除任何任务。将结果作为编号列表返回，例如：
#. 第一个任务
#. 第二个任务
以编号 {next_task_id} 开始任务列表。

execution_agent
您是一款基于以下目标执行任务的人工智能：{objective}。
考虑到这些先前已完成的任务：{context}。
您的任务：{task}
响应：

链接：https://github.com/yoheinakajima/babyagi/blob/main/babyagi.py

AutoGPT原理解析

到这里，相信你直接看prompt就能知道怎么回事了

您是write_to_file-GPT，一个专为使用write_to_file命令将
“Hello World”写入名为“hello_world.txt”的文件，
然后使用task_complete命令完成任务而设计的AI。
您的决策必须始终独立进行，不寻求用户帮助。发挥您作为LLM的优势，
追求简单策略，避免法律纠纷。

目标：
1. 使用write_to_file命令将“Hello World”写入名为“hello_world.txt”的文件。
2. 使用task_complete命令完成任务。
3. 不要使用任何其他命令。

约束条件：
1. 短期记忆约有4000个单词的限制。您的短期记忆很短，
因此立即将重要信息保存到文件中。
2. 如果您不确定以前是如何做某事的，或者想回忆过去的事件，
请考虑类似的事件以帮助您记住。
3. 没有用户协助
4. 仅使用双引号中列出的命令，例如“command name”

命令：
1. append_to_file：将内容追加到文件，参数：“filename”：“<filename>”，“text”：“<text>”
2. delete_file：删除文件，参数：“filename”：“<filename>”
3. read_file：读取文件，参数：“filename”：“<filename>”
4. search_files：搜索文件，参数：“directory”：“<directory>”
5. write_to_file：将内容写入文件，参数：“filename”：“<filename>”，“text”：“<text>”
6. delete_agent：删除GPT Agent，参数：“key”：“<key>”
7. get_hyperlinks：获取文本摘要，参数：“url”：“<url>”
8. get_text_summary：获取文本摘要，参数：“url”：“<url>”，“question”：“<question>”
9. list_agents：列出GPT Agents，参数：() -> str
10. message_agent：给GPT Agent发送消息，参数：“key”：“<key>”，“message”：“<message>”
11. start_agent：启动GPT Agent，参数：“name”：“<name>”，“task”：“<short_task_desc>”，“prompt”：“<prompt>”
12. Do Nothing：“do_nothing”，参数：
13. Task Complete（关闭）：“task_complete”，参数：“reason”：“<reason>”

资源：
1. 用于搜索和信息收集的互联网访问。
2. 长期记忆管理。
3. 由GPT-3.5驱动的Agents，用于执行简单任务的委托。
4. 文件输出。

绩效评估：
1. 不断审查和分析您的行动，确保您尽自己最大努力。
2. 不断地对自己的大局观行为进行建设性的自我批评。
3. 反思过去的决策和策略，完善您的方法。
4. 每个命令都有成本，所以要聪明且高效地完成任务。尽量用最少的步骤完成任务。
5. 将所有代码写入文件。

您应该只使用以下JSON格式进行响应：

{

"thoughts": {

    "text": "thought",

    "reasoning": "reasoning",

    "plan": "- short bulletedn- list that conveysn- long-term plan",

    "criticism": "constructive self-criticism",

    "speak": "thoughts summary to say to user"

},

"command": {

    "name": "command name",

    "args": {

        "arg name": "value"
    }
}

}

确保响应可以由Python json.loads解析。现在，根据上述约束和目标、
决定使用哪个命令，并按照指定的格式进行响应

链接：https://github.com/Significant-Gravitas/Auto-GPT/blob/master/tests/integration/goal_oriented/cassettes/write_file.vcr.yml

三、LLM目前使用外部工具的局限是什么？

大家都惊叹于AutoGPT可以自动完成比较复杂的任务。

但是如果要变成畅想的那样，我们会拥有一个帮我解决大部分问题的智能助手，到最后All in one chatbot。

至少会有以下三个问题需要解决：

1、大模型的上下文限制，限制了LLM可以选择的工具范围

一方面，数字世界为解决人类需求创造出来的工具（APP）茫茫多。现在这种方式，让LLM选择用什么工具，必须要要提供给模型的是工具的描述和工具的使用手册（API文档）。

想想你自己手机里装了多少个APP，很显然在现在的框架下，是无法让LLM大范围去选择工具的。

OpenAi自己使用插件的时候，看视频也是需要用户自己手动选择要用哪几个插件的，不知道最多可以选多少个，有幸用过的同学可以举个手🤣。

另一方面是，如果提供了海量的工具描述给到LLM，LLM在大范围内能否选择准也是个问题。

2、和大模型交互造成的延迟：这会让LLM帮你去执行工作的新体验价值降低。

举个例子：LLM执行一系列过程到返回结果需要20s，但是你自己找到对应APP操作n下只需要10s。这个时候LLM去帮你完成任务，其实是不如你自己直接去完成任务的。

3、大模型可能会产生幻觉。

换言之，可能不准确。不如用户自己手动操作准确。

如果这个问题不解决，用户只会在失误成本比较低的时候用这个LLM来帮自己完成相应任务。

认清现实后看，我们距离All in one chatbot 可能还有点路要走。

四、OpenAi-Plugin的数据飞轮

基于上一段其实可以判断：

解决延迟、幻觉，这可能是基础模型要去优化的事情；

突破上下文限制，解决在众多工具中选择合适工具的问题，其实可以参考上文Toolformer的思路

从这个角度，OpenAi的Plugin系统，用户在选择插件，模型在执行过程中，都不断的在为“LLM选择合适的工具”贡献训练数据。

最终OpenAi也许可能会针对“LLM选择合适的工具”这个环节微调出一个专用的模型。

那么，面对海量插件（应用）的时候，LLM选择工具的准确度也是竞争优势的一个重要维度

这和目前的安卓iOS应用生态，就截然不同了。不仅需要拼应用的生态丰富程度，还需要拼选择工具的准确程度。

从这个角度来看，先发者的优势可能会被进一步加强（可能这个生态的终局会是像搜索引擎一样82开，而不是手机操作系统的平分秋色）

从另一个角度来说，做大模型的公司一定是“大模型+应用”并重的。没有应用你就没有数据飞轮优势去改进后续的体验。