👉导读
👉目录
01
02
03
-
感知端:除了基础的纯文本空间感知,智能体也应该将自身的感知能力扩展到视觉、听觉等多模态领域,从而更加有效地利用周围环境中的信息。 -
控制端:这是智能体的大脑,也是智能体的核心,通常由 LLMs 构成。它不仅可以存储知识和记忆历史,而且还需要具备信息处理、决策等重要功能。同时需要具备推理和计划的能力以更好地应对未知任务。 -
行动端:除了常规的文本输出,智能体还具备具身能力和使用工具的能力,使其能够更好地适应环境变化。它可以通过与环境进行反馈和交互来塑造环境。
3.1 感知端(Perception)
文本输入
视觉输入
-
一种直接的方法是为图像输入生成相应的文本描述,即 Image Captioning。这些文本描述可以直接与标准文本指令相关联,并输入到智能体中。这种方法具有很高可解释性,并不需要额外训练用于生成字幕,从而节省了大量计算资源,但在转换过程中可能会丢失很多潜在信息。 -
也有一些工作将预训练的视觉编码器和 LLMs 结合以增强智能体的视觉感知和语言表达能力。然而,LLMs 不能直接理解视觉编码器的输出,因此有必要将图像编码转换为 LLMs 可以理解的嵌入。换句话说,这涉及到将视觉编码器与 LLM 对齐。通常需要在它们之间添加一个额外可学习的接口层。例如,BLIP-2 和 InstructBLIP 使用查询变压器(Q-Former)模块作为视觉编码器和 LLM 之间的中间层。
听觉输入
其他输入
3.2 控制端(Brain)
自然语言交互
-
高质量文本生成:大量评估实验表明,LLMs 能够生成流畅、多样、新颖、可控的文本。尽管在个别语言上表现欠佳,但整体上具备良好的多语言能力。 -
言外之意的理解:除了直观表现出的内容,语言背后可能还传递了说话者的意图、偏好等信息。言外之意有助于智能体更高效地沟通与合作,大模型已经展现出了这方面的潜力。
知识
记忆
-
扩展模型架构的长度限制:针对 Transformers 固有的序列长度限制问题进行改进。 -
总结记忆(Summarizing):对记忆进行摘要总结,增强智能体从记忆中提取关键细节的能力。 -
压缩记忆(Compressing):通过使用向量或适当的数据结构对记忆进行压缩,可以提高记忆检索效率。此外,记忆的检索方法也很重要,只有检索到合适的内容,智能体才能够访问到最相关和准确的信息。
3.3 检索增强生成(RAG)
任务规划
-
计划制定 (Plan Formulation):智能体将复杂任务分解为更易于管理的子任务。例如:一次性 分解再按顺序执行、逐步规划并执行、多路规划并选取最优路径等。在一些需要专业知识的场景中,智能体可与特定领域的 Planner 模块集成,提升能力。 -
计划反思 (Plan Reflection):在制定计划后,可以进行反思并评估其优劣。这种反思一般来自三个方面:借助内部反馈机制;与人类互动获得反馈;从环境中获得反馈。
3.4 行动端(Action)
文本输出
工具使用
-
调用其他的 AI 模型,比如 HuggingGPT 中调用其他的专有任务模型 -
网络搜索引擎,比如 Google 搜索、Bing 搜索 -
常见的开放 API,比如天气查询、航班查询 -
企业信息获取,比如产品信息、CRM 客户信息
-
如何让 LLM 正确地做出使用工具的决策,即应该在什么时候使用什么工具? 我们知道 LLM 的唯一输入是提示词,因此需要给予 LLM 足够的工具使用提示似乎是唯一的办法,而正确性则有赖于 LLM 自身的推理能力。 -
如何构建正确的工具使用输入信息? 如果你需要使用搜索引擎这个工具,那么你的搜索关键词是什么?显然,这需要 LLM 结合自身知识、上下文、外部环境进行推理。再比如,你需要 LLM 访问你的企业系统,而你的系统输入要求是严谨的 JSON 格式,那么如何让 LLM 能够从自然语言推理出符合规范的 JSON 结构呢?这些难题都需要大模型可以进行完整精确的 prompt 理解,依赖于大模型自身的语义理解能力。
-
是否需要调用 API:大模型规划完成任务的能力需求 -
识别正确的 API 进行调用:如果不够好,LLMs 需要迭代修改 API 输入(例如为搜索引擎 API 确定搜索关键字)。 -
根据 API 结果进行响应:如果结果不满意,模型可以选择优化并再次调用。
-
Level-1 评估了调用 API 的能力。给定一个 API 的描述,模型需要确定是否要调用给定的 API,正确地进行调用,并对返回值做出适当响应。 -
Level-2 检查了检索 API 的能力。模型需要搜索可能解决用户需求的各种可能性,并通过阅读文档学习如何使用它们。 -
Level-3 评估了计划超越检索和调用之外的 API 能力。鉴于用户请求不明确(例如安排团队会议、预订航班/酒店/餐厅等),模型可能必须进行多次 API 调用来解决问题。
具身行动
-
Observation 可以帮助智能体在环境中定位自身位置、感知对象物品和获取其他环境信息; -
Manipulation 则是完成一些具体的抓取、推动等操作任务; -
Navigation 要求智能体根据任务目标变换自身位置并根据环境信息更新自身状态。
04
-
协助用户摆脱日常任务和重复劳动,从而减轻人们的工作压力并提高任务解决效率。 -
不再需要用户提供明确的低级指令。智能体可以独立分析、规划和解决问题。 -
在释放了用户的双手之后,智能体还使它们的思维能够参与探索性和创新性工作,在前沿科学领域发挥出全部潜力。
4.1 单智能体场景
-
AutoGPT:AutoGPT 是一个开源的 AI 智能体实现,目前在 Github 上以获得超过 150k 的 star,超过了 transformers 和 pytorch。它遵循单一智能体范式,属于任务导向型,它根据终极目标制定多个子目标的来自动化 NLP 任务,同时还融合了 ReAct 的推理和行动循环。 -
ChatGPT+(带代码解释器或插件):ChatGPT 是一个对话式AI服务或智能体,现在可以与代码解释器或插件一起使用(目前仅在高级订阅计划 ChatGPT Plus 下可用)(OpenAI, 2023)。代码解释器使 ChatGPT 能够执行代码,而插件则通过提供各种精选工具来增强 ChatGPT 的功能。 -
LangChain Agents:LangChain 是一个用于开发基于 LLM 应用程序的通用框架。LangChain Agents 是一个子包,用于使用 LLM 选择一系列动作。LangChain Agents 中有各种类型的智能体,其中 ReAct 智能体是一个显著例子,在使用 LLMs 时结合推理和行为。LangChain Agents 提供的所有智能体都遵循单一智能体范式,并且并非专门设计为沟通和协作模式。
4.2 多智能体场景
-
Researcher: 根据需求,上网搜各种资料,并把内容扒下来、进行总结。 -
Editor: 根据需求和 Researcher 提供的资料,给出稿件的方向和框架。 -
Writer: 根据 Editor 的指示,完成稿件撰写。 -
Reviewer: 审稿,提出修改意见,返回给 Writer 做改进。
-
当所有智能体自由地表达自己的观点、看法,以一种没有顺序的方式进行合作时,称为无序合作(动态对话拓扑)。 -
当所有智能体遵循一定的规则,例如以流水线的形式逐一发表自己的观点时,整个合作过程井然有序,称为有序合作(静态对话拓扑)。
多智能体交互框架
-
单个个体智能体的职能和能力是什么?这个问题即是我们通常所说的角色定义,需要考虑在应用场景中需要的个体智能体分工及能力。 -
智能体如何感知应用场景的环境信息?环境信息主要是指系统中定义的智能体、智能体间的可见性、以及其他的用户配置和全局变量。该问题需要我们能够清楚的定义个体智能体的感知能力半径。 -
个体智能体间如何交流?具体来说,我们需要考虑不同应用场景智能体间的通信方式,因为基于大模型的智能体以语言交流为主,因此我们重点考虑不同智能体的协作形式(合作还是对抗)、交流方式(纯自然语言还是附加环境变量)和协作模式(有序还是无序/动态还是静态)。
-
基础设施:系统是否被设计为用于构建 LLM 应用程序的通用基础设施; -
协作模式:实现系统支持的模式类型(有序还是无序/动态还是静态); -
执行能力:系统是否能够执行由 LLM 生成的代码或者有效的使用工具; -
人类参与:系统是否允许人类在执行过程中参与以及如何参与。
-
可对话:AutoGen 中的智能体是可对话的,这意味着任何一个智能体都可以向其他智能体发送和接收消息以启动或继续一次对话。 -
可定制化:AutoGen 中的智能体可以根据需要进行定制,以整合 LLMs、人类、工具或它们的组合。
-
定义一组具有特定能力和角色的可交谈智能体(如上所述); -
以对话为中心的计算和控制来编写智能体之间的交互行为。通过将自然语言和编程语言相结合,可以实现这两个步骤,并构建具有各种对话模式和智能体行为的应用程序。
-
AssistantAgent 被设计成作为 AI 助手,使用默认情况下使用 LLMs。当接收到消息(通常是描述需要解决的任务)时,它可以为用户编写 Python 代码。在底层,Python 代码由 LLM(例如 GPT-4)编写。它还可以接收执行结果并提出修正或错误修复建议。 -
UserProxyAgent 概念上是人类的代理,每次交互轮次都会自动征求人类输入作为该智能体的回复,并具有执行代码和调用函数的能力,默认情况下,在接收到可执行代码块且没有提供人工用户输入时,UserProxyAgent 会自动触发代码执行。 -
GroupChatManager 被设计为对话流程的管理者,支持复杂的动态群聊功能,该功能可以动态选择下一个发言者,并将其响应广播给其他代理。
-
AssistantAgent 从 UserProxyAgent 接收到包含任务描述的消息。 -
然后,AssistantAgent 尝试编写 Python 代码来解决任务,并将响应发送给 UserProxyAgent。 -
一旦 UserProxyAgent 收到了来自 AssistantAgent 的响应,它会尝试通过征求人类输入或准备自动生成的回复来进行回复。如果没有提供人类输入,则 UserProxyAgent 执行代码并将结果用作自动回复。 -
然后,AssistantAgent 为 UserProxyAgent 生成进一步的响应。然后,UserProxyAgent 可以决定是否终止对话。如果不终止,则重复步骤3和4。
-
注册自动回复。通过可插拔的自动回复功能,可以根据当前消息和上下文的内容选择与其他智能体进行对话。可以在 GroupChatManager 中注册了一个自动回复函数,让 LLM 决定在群聊设置中下一个发言者将是谁。 -
基于 LLM 的函数调用。在这种方法中,LLM 根据每次推理调用中的对话状态决定是否调用特定函数。通过向被调用函数发送附加智能体的消息,LLM 可以动态驱动多智能体对话。
-
BabyAGI:是一个在 Python 脚本中实现的基于人工智能的任务管理系统示例。在这个实现的系统中,使用了多个基于LLM的智能体。例如,有一个智能体根据前一项任务的目标和结果创建新任务,一个智能体用于对任务列表进行优先级排序,以及一个智能体用于完成任务/子任务。作为多智能体系统,BabyAGI 采用静态智能体对话模式,即预定义的智能体通信顺序。 -
CAMEL:是一个交流型智能体框架。它展示了如何利用角色扮演让聊天机器人之间进行任务完成时的沟通。它还记录了智能体之间的对话以进行行为分析和能力了解。采用了启发式提示技术来实现自主协作。与 AutoGen 不同,CAMEL 并不原生地支持工具使用(例如代码执行)。虽然它被提出作为多 Agent 对话基础设施,但只支持静态对话模式。 -
MetaGPT:是一种基于多智能体对话框架的专用 LLM 应用程序,用于自动软件开发。它们将不同的角色分配给 GPTs 以协作开发软件。它们是针对特定场景的专业解决方案,不是一个通用基础设施。 -
Generative Agents:即我们常说的斯坦福虚拟小镇,它是基于 LLM 做的一个有趣实验,在该实验中,25个虚拟角色,每一个都由 LLM 驱动的,在一个受《模拟人生》启发的沙盒环境中生活和互动。Generative Agents 的设计将 LLM 与记忆、规划和反思机制相结合,使 Agent 可以根据过去的经验行事,以及与其他 Agents 进行互动。角色之间的对话模式是动态的。
4.3 人机交互场景
05
-
可控性有限:Agent 基本由自我迭代组成,而且对每个迭代的部分要求严格,并且这个迭代过程使用 prompt 约束,无法百分百可控。如果涉及到准确性要求,例如 SQLdb、科学计算等,结果更加难以控制。 -
智能体的记忆和状态存储问题:智能体的行动需要储存记忆和状态,复杂的工作(比如大量的文本、大量的搜索结果)会直接爆 token,如果直接上 GPT-4 32k 或者 Claude 100k,注意力分散也是个问题。 -
串联任务:目前 Agent 的工作模式绝大多数都是串联,很难优化,框架对并联任务的支持很差; -
长运行时间的低可用性:一个简单的需求能跑10分钟; -
任务复杂性:Agent 的 prompt 很难测试鲁棒性,某些复杂的任务会出现错误乃至危险; -
现阶段 LLMs 的短板:现阶段 LLMs 并没有针对 Agent 各个环节进行调整,而是完全依赖于模型的泛化能力。
– END –
报告下载
大佬观点