【2023Q2】漫谈ChatGPT系列（10）：Auto-GPT、ReAct模式 与 策略流程的自动化生成
本文系列文章之一，之前提到的内容不会再重复讨论。完整索引见文章末尾。
上一篇 【2023H1】漫谈ChatGPT系列（9）：谈 语义处理框架 的设计
1 导言
1.1 LangChain Agent 与 Auto-GPT
（本节给没有看过本系列上一篇，但了解AutoGPT的读者）
最近Auto-GPT一下在全网变得很热门，它的能力也让人觉得相对于ChatGPT和LLM更进了一层。
不过实际上它使用的主要“技术”在半年前就已经有文章提出了，LangChain Agent也在5-6个月前就实现了对应的功能。但先发不等于知名，这块能力被人广为认知还是要等到2023.3月AutoGPT项目开始后。
本文目标是从它的能力来源和实现方式来做一些探讨。
1.2 语义处理程序的自动化生成
（本节给已经看过上一篇，但不了解AutoGPT的读者）
在系列上一篇中，讨论了如何基于LLM能力来构建更复杂、更可靠的策略处理逻辑的思路。这个视角是将LLM当成以一个高级的语义处理工具（函数），再其上再类似传统编程的方式来堆砌处理逻辑。
那么语义处理程序（或者其他高级概念的处理程序）是否能摆脱人工编写，也来让LLM实现呢？Self ask和ReAct模式 给我们指出一个方向。而Auto-GPT就可以看成是它们的一个优化一点的实现。
在写上一篇文章的时候，我还没有推演到这种更加激进的idea，也没有想到它已经能够落地成demo。直到最近，我才从Auto-GPT这条线反查了解了这个思路。由于这个想法的创新性和落地成本较低，也由于中文圈对于这块的介绍和讨论内容还不是很多，让我觉得有必要来写一下。而且这个思路也是我上一篇内容的一个扩展。
2 让LLM自己更好的思考
自从LLM被训练出来，如何更多的“调用它的能力的不同方面”一直是人们探索的一个方向。相信大家已经耳熟能详 思维链（Chain of Thoughts，简写为CoT）prompt模式，而本文要讨论的self ask 和 ReAct也是类似的prompt模式，可以调动LLM的一部分新的能力。
本质上来讲， chain of thoughts、self ask、ReAct三者其实手段类似，都是让LLM以一个更细的粒度来思考。
2.1 Self ask
提出self ask方式的论文 Measuring and Narrowing the Compositionality Gap in Language Model ，作者的英文介绍文 Self-ask Prompting 。
这里对齐最核心内做一个简要介绍：
- 主要思路：引导LLM将一个复杂的问题拆分为简单的问题，逐个回答，然后汇总成为答案。
- 实施细节1：在prompt中直接提问“是否需要拆分出子问题”。
- 实施细节2：拆分出的子问题，不依赖LLM自己进行回答，而是调用外部搜索工具进行回答。并把结果交给LLM继续思考推理。
这个方式可以引入外部知识库来补充LLM所不知道的信息，还可以让LLM对它使用的事实进行校验。
但如何引导LLM正确的分解问题，并且以合适的方式与上层调度整个过程的程序进行交互呢？是靠Few-shot的方式在prompt中先举一些分解的例子（也有人称为in-context learning）。
2.2 ReAct
ReAct是 Reasoning + Acting的简写，提出的论文是 ReAct: Synergizing Reasoning and Acting in Language Models ，一个英文的详细介绍可以见 https:// tsmatz.wordpress.com/20 23/03/07/react-with-openai-gpt-and-langchain/ 。
ReAct也是引导LLM将复杂的问题解决过程拆解为简单的步骤，差异是：
- 和self ask不同，ReAct每次让LLM输出一个当前的【思考】和【要做的动作】，这个动作并不只限于检索信息，可以是调用任何工具，类似ChatGPT plugin。LLM通过few shot的例子和工具自带的描述、还有它自己学到的常识来决定何时调用工具以及如何调用工具。
这样ReAct引入了外部工具的概念，让LLM能够通过这种步进式的方式逐步思考并调用外部工具，根绝外部工具的结果进一步思考循环。同时也可以仅仅是输出一步思考，并继续下去，类似CoT。
整个过程是逐步推进的，并且可以直观的输出整个策略系统的思考和执行过程，对用户的可解释性也很好。
这个过程仍然是靠few-shot的方式给例子，引导LLM类似的“思考”，并按格式返回后续步骤的信息。
2.3 Auto-GPT
ReAct再加上一些工具（如搜索等），其实就已经能够有Auto-GPT大部分的能力，这块LangChain Agent中已经实现了ReAct的版本。不过Auto-GPT有一些改进：
- 支持更多的工具/操作，包括对于本地文件系统的控制。这也是为什么AutoGPT需要被放到一个沙盒docker中运行，为了保证用户环境的安全。
- 每次让LLM输出的内容包括：
- Thoughts：当前的思考
- Reasoning：推理过程
- Plan：后续计划
- Criticism：（在执行操作前预想的）自我批判审视
- Next action：下一步行动
- 这个引导思考的模板比ReAct更全面一些。其中的Criticism看起来LLM外部没有用，但其实是通过对话历史给到后续的LLM调用中，帮助改善LLM的推理结果的。
- 此外，还通过prompt对于LLM给到一些信息和要求：
- 它自己的记忆很短，重要内容要尽快保存到文件中。
- 不要依赖用户。
- 持续回顾和分析自己之前的行为，目标是充分发挥自己的能力。
- 自我批判。
- 反思过去的决定和策略来改进后续的方法。
- 每个命令都有成本，要尽可能高效，减少步骤。
这些prompt指定都在 https:// github.com/Significant- Gravitas/Auto-GPT/blob/v0.2.2/autogpt/prompt.py
Auto-GPT似乎并没有通过few-shot的方式来举例让LLM模仿思考方式，而是直接给了一些更抽象层面的指示。这看起来就像是给一个人的指示，再加上Auto-GPT运行时所展示的思考能力，会让人觉得这已经像是一个非常非常简单的AGI。
更详细的AutoGPT源代码分析见 Auto-GPT实现解析
3 对Auto-GPT的评论
3.0 Auto-GPT 不是人
虽然Auto-GPT自己使用的prompt和Auto-GPT在各种问题上展示的思考过程都很让人觉得它已经很像人，虽然它还有这个各种各样的问题，会卡在各种各样简单的地方。但这个能力确实看起来远超过人类创造的任何一个工具。
那它是一个困在模型中的人么？它有自己的意识么？
我对此的回答还是跟对LLM和ChatGPT一样，它虽然看起来有类人的反应能力，但它没有意识。也没有我们意义上的那种很好的（多步）思考能力，如果单步反应也算是思考的话。
当然这已经是一个哲学问题，每个人会有自己的思考和认知的演变过程。我觉得这个问题得留给哲学家来回答。
3.1 技术上的问题
这方面已经有了一个文章对它进行评论了： https:// jina.ai/news/auto-gpt-u nmasked-hype-hard-truths-production-pitfalls/
这里简要概括一下其中指出的问题：
- 成本高昂。主要来自于：LLM的调用成本、需要的LLM的调用次数较多、每次调用需要使用的Context很长。
- 已有思考过程无法固化。每次对于同类问题都需要重复进行思考，耗费同样的费用成本。
- 经常陷入死循环。
3.2 思考/决策过程的可靠性
虽然Auto-GPT看起来功能强大，但我得说：它的质量只能算的上是一个demo。Auto-GPT项目自己也自称为一个实验。
目前依靠LLM的系统，如果希望可靠的解决问题、完成人物，LLM自身的不可靠都是一个主要的问题。本系列上一篇文章的主题也是如何基于LLM来构建一个更可靠的策略系统。Auto-GPT不光依赖LLM，还把策略本身的实现也交给LLM完成。当LLM的结果出现问题时，LLM以外没有任何矫正能力，所以其整体的可靠性较低就不奇怪了。
特别是排除LLM后，整个系统就只有一个循环迭代策略，这就很难避免超过LLM支持的的最大Context长度的死循环。
所以我的看法是：Auto-GPT虽然看起来功能强大，但光靠它自己是很难取得商业上的成功的，即使不考虑其昂贵的成本。
4 一些个人展望
回顾一下上一篇 （9）：谈 语义处理框架 的设计 的内容和本文前面的内容，有：
4.1 Auto-GPT的prompt模式仍然可以改进
前面第2节提到的方式都是让LLM以一个更小的粒度做决策，Auto-GPT中虽然加了让其自我批判、自我反思的过程，但整个过程仍然是一个走不回头路的过程。实际上，沿着类似的思路，我们可以进一步优化策略的可靠性：
- 让其对问题构造一个稍微通用一点的处理过程
- 在实际执行前，让LLM审视和优化这个过程
- 然后再付诸执行，并在执行中可以根据当前的具体情况决定是否要重新生成整个策略过程再继续执行。
用上一篇文章的视角就可以描述成：先让LLM生成一个语义处理程序，然后要求LLM优化这个语义处理程序，然后再付诸执行。当然本文讨论的内容就并不限于一个简单的语义，可以是事实的推理、感情的分析等等更加复杂抽象的问题处理策略。
这个先生成策略流程、自我优化、再执行的过程其实也解决了第3.1节中的第二个问题，它生成的这个处理流程可以直接固化，在后续类似场景的调用中就可以变成一个工具来由LLM使用，或者由人直接调用。
4.2 问题的自动解决过程的发展可能比我们想象的快
在ReAct和AutoGPT之前，大概很少有人会想到现在我们就已经有了一个可以实际把玩的demo。我自己也惊讶于我们现在就能看到这样的东西，而且它的实现成本还比较低。
虽然光靠AutoGPT自己还很难可靠的完成任务，降低成本，但如果配合一些类似前文提到的框架之类的，再配合人的一些监督和指导，快速堆砌出一个解决策略、或者是根据已有策略的应用日志来优化它大概比我们想象的要近。
之前是接开发需求做工程开发的人感到了自己被替代的风险，现在是策略算法岗或者策略产品岗人看到了自己的工作可以被部分替代的风险。
这是目前我看到的最强的支持AGI可能没有我们想象的那么远的证据。不过我目前仍然不觉得可靠的AGI能够在未来10年出现，但确实不可靠的AGI似乎已经开始了。
附录A 后续相关内容补充
Low-code LLM
论文 https:// arxiv.org/abs/2304.0810 3
中文解读 AutoGPT不靠谱，微软推出升级版！可编辑自主规划过程
此文的思路与本文提到的类似：使用LLM生成一个整个策略流程，再进行后续处理。
此论文新的内容：
- 生成的策略流程通过Lowcode的可视化方式显示，可以由用户编辑修改之后再执行。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，可以从我知乎的签名或 交流及合作方式 中的方式联系我。
附录、系列文章索引
Rethinking LLM 系列
【2023Q2】Rethinking LLM（1）：Token 与 语义 的Gap
【2023H1】Rethinking LLM（2）：如何理解LLM中的微调和RLHF阶段
【2023Q2】Rethinking LLM：自动化的RLHF数据生成 与 Multi-Agent Alignment
【2023.6】Rethinking LLM（3）：语义层面 探索的一些想法
【2023.6】Rethinking LLM（4）：从总体视角看LLM
【2023.7】Rethinking LLM：谈OpenAI 0613版本System Message的实现方式
基于LLM的程序 系列
【2023.5】基于LLM的程序开发：LLM的Context Window 与 短期发展展望
【2023Q2】基于LLM的程序开发：LLM是否能通过文本输出score数值？
【2023Q2】基于LLM的程序开发：Tree of Thoughts专题
【2023Q3】基于LLM的程序开发：策略内部状态是否应该结构化
【2023Q3】基于LLM的程序开发：System Message的崛起
LLM炼丹trick拾遗 系列
【2023Q2】LLM炼丹trick拾遗：（0）系列定位及背景介绍
【2023.5】LLM炼丹trick拾遗：LLM场景的Tokenizer设计
【2023Q2】LLM炼丹trick拾遗：数据集并不只是燃料，更是准星
【2023Q2】LLM炼丹trick拾遗：LLM的MoE架构与Lifelong learning
产品视角看LLM 系列
【2023Q2】产品视角看LLM：（1）不是所有的“智能大脑”都能被LLM赋能
【2023.6】产品视角看LLM：（2）谈 面向应用场景的LLM benchmark平台 如何设计
【2023.6】产品视角看LLM：LLM的benchmark结果已经不可信
【2023Q3】产品视角看LLM：重新审视 长文档摘要 需求
【2023Q3】产品视角看LLM：LLM-native应用的算法壁垒在哪里
ChatGPT 系列（主要是2023.5.1以前的文章）
【2023H1】漫谈ChatGPT系列（7）：谈LLM能处理的最大 有效上下文长度
【2023Q1】漫谈ChatGPT系列（8）：谈LLM的语义级回避 与 二阶自监督学习
【2023H1】漫谈ChatGPT系列（9）：谈 语义处理框架 的设计
【2023Q2】漫谈ChatGPT系列（10）：Auto-GPT、ReAct模式 与 策略流程的自动化生成
【2023.5】ChatGPT Plugin 与 AutoGPT
本文成文于 2023.4.17
2023.4.29 增加Low-code LLM
2023.5.28，修正AutoGPT prompt的url
