Su的技术博客

  • 首页
  • 原创
  • 视频
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • AI
  • Other
  • 工具
    • AI工具集
    • 工具清单
    • JSON在线格式化
    • JSON在线比较
    • SQL在线格式化
  • 打赏
  • 关于
路很长,又很短
  1. 首页
  2. AI
  3. 正文
                           

【腾讯】OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘

2023-11-10 3078点热度 0人点赞 0条评论

👉导读

OpenAI 发布会带来了全新的开发方式——Assistants API,这背后基于的正是你可能闻所未闻的 AI Agent 智能体技术。本篇文章将为你全面解析 AI Agent 的概念、技术框架与应用场景。长文干货,先码再看!

👉目录

1 引言
2 什么是 Agent
3 智能体技术框架
4 智能体应用场景
5 总结

01

引言
北京时间 11 月 7 日凌晨,OpenAI 首次开发者大会正式开启,创始人 Sam Altman 和同事同台演绎,45 分钟时间的发布会上,密集发布了团队最新成果 GPT-4 Turbo 、可定制的 GPT ,同时做到更快更便宜,未来还将有类似苹果 App Store 的 GPT Store 发布。与此同时,ChatGPT 的语料库信息也终于更新到了 2023 年 4 月。
在这场 45 分钟的短暂开发者大会上,OpenAI 带来的信息密度可谓是直接震撼了整个技术圈。特别是其中发布的让开发者更容易使用 OpenAI API 的开发方式——Assistants API,使得人人都能通过自然语言创建基于自己知识库的 AI Agent,并可加入 OpenAI 的应用商店获得分成,同时不用写一行代码!
当国服版本还鲜有人知 AI Agent 概念时,OpenAI 发布会上已经快要“杀死”很多做 Agent 的公司了。那么 AI Agent 究竟是什么?它的技术框架是怎样的?具体有哪些应用场景?本篇文章将为你全面解析!
友情提醒,文章略长且干,建议先分享转发收藏再慢慢细品~
 

02

什么是 Agent
Agent 的概念由 Minsky 在其 1986 年出版的《思维的社会》一书中提出,Minsky 认为社会中的某些个体经过协商之后可求得问题的解,这些个体就是 Agent。他还认为Agent应具有社会交互性和智能性。Agent在英文单词里面,主要指能够活动的软件或者硬件实体。在人工智能领域,agent通常被翻译成为”智能体“,泛指任何能够独立思考并可以与环境交互的实体。
随着最新大语言模型,例如 GPT 系列、PaLM2 的兴起,大语言模型强大的能力为 AI Agent 的突破带来了契机。大模型庞大的训练数据集中包含了大量人类行为数据,为模拟类人的交互打下了坚实基础;另一方面,随着模型规模不断增大,大模型涌现出了上下文学习能力、推理能力、思维链等类似人类思考方式的多种能力。将大模型作为 Agent 的核心大脑,就可以实现以往难以实现的将复杂问题拆解成可实现的子任务、类人的自然语言交互等能力。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
比如此前出现过的斯坦福「虚拟小镇」,商汤、清华等机构在《我的世界》中推出的通才 AI 智能体 Ghost in the Minecraft,包括后来英伟达的 Voyager 等,都是 AI Agent 的典型代表。直到今天,OpenAI 通过 Assistants API 的方式带来了全新的、不用写一行代码即可构建的 AI Agent 。
 

03

智能体技术框架
大模型加持的智能体的技术框架是怎样的呢?像智慧生物一样,比如一个人想要在社会环境中生存,就必须学会感知环境,对环境具备认知能力并应对外界的变化。因此,一个智能体的技术框架也由三个部分构成:感知端(Perception)、控制端(Brain)和行动端(Action)。
  • 感知端:除了基础的纯文本空间感知,智能体也应该将自身的感知能力扩展到视觉、听觉等多模态领域,从而更加有效地利用周围环境中的信息。
  • 控制端:这是智能体的大脑,也是智能体的核心,通常由 LLMs 构成。它不仅可以存储知识和记忆历史,而且还需要具备信息处理、决策等重要功能。同时需要具备推理和计划的能力以更好地应对未知任务。
  • 行动端:除了常规的文本输出,智能体还具备具身能力和使用工具的能力,使其能够更好地适应环境变化。它可以通过与环境进行反馈和交互来塑造环境。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
基于大模型的智能体框架图
如图所示,当人类询问是否会下雨时,感知端将人类和环境信息指令转换为 LLMs 可以理解的表示,然后控制端根据当前的天气和互联网上的天气预报进行推理和行为规划,最后行动端做出响应,告诉人类会下雨并将雨伞递给人类。
 

   3.1 感知端(Perception)

人类和动物都依赖于眼睛和耳朵等感觉器官从周围环境中收集信息。这些感知输入被转化为神经信号并发送到大脑进行处理,使我们能够感知和与世界互动。同样,对于基于LLM的智能体来说,从各种来源和模态接收信息是至关重要的。这种扩展的感知空间有助于智能体更好地理解其环境、做出明智决策,并在更广泛的任务范围内取得成功。这些感知信息大体上可以分为四类:文本输入、视觉输入、听觉输入以及其他输入。
 
文本输入
基于 LLM 的智能体已经具备通过文本输入和输出与人类进行沟通的基本能力。在用户的文本输入中,除了明确内容外,还隐藏着内涵和意图。理解暗含意义对于智能体来把握人类用户潜在及底层意图至关重要,从而提高其与用户之间的沟通效率和质量。
 
视觉输入
 
尽管 LLMs 在语言理解和多轮对话方面表现出色,但它们本质上缺乏视觉感知能力,只能理解离散的文本内容。视觉输入通常包含丰富的关于世界的信息,包括物体属性、空间关系、场景布局等等与智能体周围环境相关的内容。因此,将视觉信息与其他模态数据整合起来可以为智能体提供更广泛的背景和更精确的理解,加深其对环境的感知。为了帮助智能体理解图像中所包含的信息,通常分为两种技术手段:
  • 一种直接的方法是为图像输入生成相应的文本描述,即 Image Captioning。这些文本描述可以直接与标准文本指令相关联,并输入到智能体中。这种方法具有很高可解释性,并不需要额外训练用于生成字幕,从而节省了大量计算资源,但在转换过程中可能会丢失很多潜在信息。
  • 也有一些工作将预训练的视觉编码器和 LLMs 结合以增强智能体的视觉感知和语言表达能力。然而,LLMs 不能直接理解视觉编码器的输出,因此有必要将图像编码转换为 LLMs 可以理解的嵌入。换句话说,这涉及到将视觉编码器与 LLM 对齐。通常需要在它们之间添加一个额外可学习的接口层。例如,BLIP-2 和 InstructBLIP 使用查询变压器(Q-Former)模块作为视觉编码器和 LLM 之间的中间层。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
Llava 利用视觉编码器将图像信息编码为语言模型可理解的嵌入
听觉输入
当一个智能体拥有听觉能力时,它可以提高对互动内容、周围环境甚至潜在危险的意识。一种常见的方式是利用语音识别(Automate Speech Recognition,ASR)来将语音信息转换为文本,但是这仅仅只能处理包含人类语言的音频信息。那么,如何处理环境中其他的听觉信息呢,比如音乐、环境音等?鉴于 LLMs 具有出色的工具使用能力,一个非常直观的想法是智能体可以将 LLMs 用作控制中心,在级联方式下调用现有工具集或模型库以感知音频信息。例如,AudioGPT 充分利用了像 FastSpeech、GenerSpeech、Whisper 等其他模型在文本转语音、风格转换和语音识别等任务中取得优异结果的能力。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
AudioGPT的听觉感知流程
 
其他输入
除了文本、视觉和听觉等感知单元,基于 LLM 的智能体可能可以配备更丰富的感知模块。
 
例如在游戏场景中,智能体需要感知游戏环境信息,玩家状态,具体角色行为和参与行为的其他逻辑单元,物品、其他角色、场景等。
 
又例如,在具身机器人场景中,可以拥有独特的触摸和嗅觉器官,在与物体互动时能够收集更详细的信息,同时,清楚地感知周围环境中的温度、湿度和亮度,并能采取与环境相关的行动。典型的例子是,InternGPT 引入了指向性指令。用户可以通过手势或将光标移动到选择、拖动或绘制图像上难以描述部分来与之交互。添加指向性指令有助于为个别文本指令提供更精确的规范说明。在此基础上,智能体具备了感知更复杂用户输入的潜力。例如,在增强现实/虚拟现实设备中使用眼球追踪技术、身体运动捕捉甚至脑机接口中的脑电波信号等技术。
 

   3.2 控制端(Brain)

控制端作为智能体最核心的组成成分,也是大模型起着决定性作用的部分,从技术框架上来说大致可以从下面四个方面设计:
 
自然语言交互
 
语言是沟通的媒介,其中包含着丰富的信息。得益于 LLMs 强大的自然语言生成和理解能力,智能智能体能够通过自然语言与外界进行多轮交互,进而实现目标。具体而言,可以分为两个方面:
  • 高质量文本生成:大量评估实验表明,LLMs 能够生成流畅、多样、新颖、可控的文本。尽管在个别语言上表现欠佳,但整体上具备良好的多语言能力。
  • 言外之意的理解:除了直观表现出的内容,语言背后可能还传递了说话者的意图、偏好等信息。言外之意有助于智能体更高效地沟通与合作,大模型已经展现出了这方面的潜力。
知识
 
基于大批量语料训练的 LLMs,拥有了存储海量知识 (Knowledge)的能力。除了语言知识以外,常识知识和专业技能知识都是 LLM-based Agents 的重要组成部分。虽然 LLMs 其本身仍然存在知识过期、幻觉等问题,现有的一些研究通过知识编辑或调用外部知识库等方法,可以在一定程度上得到缓解。
 
记忆
 
Lilian Weng 在其博客中对现在的智能体机制做了不错总结,如人类一样,智能体的记忆可以分为感觉记忆、短期记忆和长期记忆。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
感觉记忆:这是记忆的最早阶段,能够在原始刺激结束后保持对感官信息(视觉、听觉等)的印象。感觉记忆通常只持续几秒钟。子类包括图像记忆(视觉)、回声记忆(听觉)和触动记忆(触摸),这部分我们可以通过感知端得以实现。
 
短期记忆或工作记忆:它存储我们当前意识到并需要进行复杂认知任务(如学习和推理)所需的信息。短期记忆被认为具有约7个项目的容量,并持续20-30秒钟。
 
长期记忆:长期记忆可以将信息存储很长时间,从几天到数十年不等,并且具有基本无限的存储容量。
 
在实践中,我们可以大致考虑以下映射:感觉记忆作为学习嵌入表示原始输入的能力,包括文本、图像或其他模态;短期记忆作为上下文中的学习。它是短暂且有限的,因为它受到 Transformer 有限上下文窗口长度的限制。长期记忆作为智能体可以在查询时关注并通过快速检索访问的外部向量存储。
 
而基于大模型的 Agent 的记忆模块(Memory)主要关注于后两者,短期记忆和长期记忆。记忆模块可以储存智能体过往的观察、思考和行动序列。通过特定的记忆机制,智能体可以有效地反思并应用先前的策路,使其借鉴过去的经验来适应陌生的环境。通常用于提升记忆能力的方法有三种:
  • 扩展模型架构的长度限制:针对 Transformers 固有的序列长度限制问题进行改进。
  • 总结记忆(Summarizing):对记忆进行摘要总结,增强智能体从记忆中提取关键细节的能力。
  • 压缩记忆(Compressing):通过使用向量或适当的数据结构对记忆进行压缩,可以提高记忆检索效率。此外,记忆的检索方法也很重要,只有检索到合适的内容,智能体才能够访问到最相关和准确的信息。

   3.3 检索增强生成(RAG)

外部记忆可以减轻有限注意力范围的约束。一种标准做法是将信息的嵌入表示保存在向量数据库中,支持快速的最大内积搜索,常使用的近似最近邻(ANN)算法返回最相近的前 k 个近邻。
 
基于嵌入表示相似性检索的大模型研究目前主要集中在基于检索增强的生成(Retrieval Argmented Generation,RAG)。RAG 整体分为5步,第一步是用户向 Agent 提出问题,第二步基于问题在数据库中检索相关问题,第三步,将检索结果 top n 的数据传给 Agent,Agent 基于用户问题以及检索到的相关信息进行合并形成最终的 prompt,第四步,将 prompt 提交给大模型,第五步,大模型产生输出,进而返回给用户。
 
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
一种常用的 RAG 技术选型
 
实际上,在真实落地中,RAG 需要考虑几个比较突出的问题,主要包括以下两点:
 
第一,RAG 进行应用权衡文档长度和返回文档数据的问题。 这个本质上是检索数据相关性的问题。而召回数据相关性的影响方面很多,既包括文档的切分,也包括文档 query 输入的清晰度,因此现在也出现了从多 query、多召回策略以及排序修正等多个方案。针对这个问题,可以调研最新的一些方法,比如:RAG-Fusion 和 RRF。
 
第二,关于问答答案散落在多个文档以及多个文档内部段落里的问题, 这个问题的根在于,在有限的上下文窗口内,不同的答案很分散,不容易都放在窗口之内,因此需要将文本进行聚类(主题分割),尽可能地让有限的窗口下能塞满多个主题的内容。因此,我们会有很多思路,例如前面说到的泛化 query 来召回不同的答案点,又如,通过主题分割、检索文本主题聚类等方法进行处理。
 
任务规划
任务规划能力对于智能体进行决策、分析等复杂任务而言至关重要。具体到 LLMs 上,就是以思维链(Chain-of-Thought, CoT) 为代表的一系列提示方法。它帮助智能体组织思维、设定目标并确定实现这些目标的步骤。在具体实现中,规划可以包含两个步骤:
  • 计划制定 (Plan Formulation):智能体将复杂任务分解为更易于管理的子任务。例如:一次性 分解再按顺序执行、逐步规划并执行、多路规划并选取最优路径等。在一些需要专业知识的场景中,智能体可与特定领域的 Planner 模块集成,提升能力。
  • 计划反思 (Plan Reflection):在制定计划后,可以进行反思并评估其优劣。这种反思一般来自三个方面:借助内部反馈机制;与人类互动获得反馈;从环境中获得反馈。
以 HuggingGPT 为例,该智能体中使用 ChatGPT 分析用户请求以了解其意图,并通过提示将其拆分为可能可解决的任务。例如对于输入的指令,“请生成一个女孩正在读书的图像,她的姿势与图像 example.jpg 中的男孩相同。然后请用您的声音描述新图像。”
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
 
HuggingGPT 在第一步,任务规划中,设计了 6 个任务,pose-control, pose-to-image, image-class, object-det, image-to-text, text-to-speech,并安排了它们的依赖关系。然后,针对每一个具体的任务从模型库中选择最优的模型执行获取各个子任务的结果。最后,利用大模型的生成表达能力将各阶段的结果进行组合生成最终的响应。整个过程中,HuggingGPT 将大模型利用自身强大的推理能力将一个复杂的任务进行子任务分解并通过利用外部模型将自身能力扩展到多模态,从而完成难以置信的各种多模态组合的复杂任务。
 
在具体的任务拆解模块中,一般通过的技术主要分为下面三类:
 
首先是思维链(Chain of Thoughts,CoT)。它已经成为增强复杂任务上模型性能的标准提示技术,主要是通过Prompt的设计来实现。在实现过程中,模型被指示「一步一步思考」,从而利用更多的测试时间计算将困难任务分解为更小、更简单的步骤。CoT 将大型任务转化为多个可管理的小任务,并解释清楚模型的思维过程。
其次是思维树(Tree of Thoughts,ToT)。它通过在每一步探索多种推理可能性来扩展 CoT。首先将问题分解为多个思考步骤,并在每个步骤中生成多个思考,创建一种树结构。搜索过程可以是广度优先搜索(BFS)或深度优先搜索(DFS),其中每个状态由分类器(通过提示)或多数 vote 进行评估。
反思和完善:智能体可以对过去的行为展开自我批评和自我反思,从错误中吸取教训,并针对未来的步骤进行完善,提高最终结果的质量。
 

   3.4 行动端(Action)

当一个智能体具备了类似人类的大脑结构,拥有知识、记忆、推理规划等能力,以及多模态感知能力时,也期望它具备与人类相似的多样化行动来响应周围环境。在智能体构建中,行动端接收由大脑模块发送的行动序列,并执行与环境互动相关的行为。
 
文本输出
 
文本输出作为 LLMs 最基础的能力,不再过多赘述。
 
工具使用
工具的使用是人类一个最显著的特征,也是 AI Agent 在 LLM 基础上实现的最重要能力。借助于工具的使用,相当于给 LLM 安装上了四肢,可以显著的扩展 LLM 模型的功能。比如:
  • 调用其他的 AI 模型,比如 HuggingGPT 中调用其他的专有任务模型
  • 网络搜索引擎,比如 Google 搜索、Bing 搜索
  • 常见的开放 API,比如天气查询、航班查询
  • 企业信息获取,比如产品信息、CRM 客户信息
 
AI Agent 的工具使用能力的核心问题不在于工具本身的构建,而需要关注另外两个问题:
  • 如何让 LLM 正确地做出使用工具的决策,即应该在什么时候使用什么工具? 我们知道 LLM 的唯一输入是提示词,因此需要给予 LLM 足够的工具使用提示似乎是唯一的办法,而正确性则有赖于 LLM 自身的推理能力。
  • 如何构建正确的工具使用输入信息? 如果你需要使用搜索引擎这个工具,那么你的搜索关键词是什么?显然,这需要 LLM 结合自身知识、上下文、外部环境进行推理。再比如,你需要 LLM 访问你的企业系统,而你的系统输入要求是严谨的 JSON 格式,那么如何让 LLM 能够从自然语言推理出符合规范的 JSON 结构呢?这些难题都需要大模型可以进行完整精确的 prompt 理解,依赖于大模型自身的语义理解能力。
 
API-Bank(Li 等人,2023年)是评估工具增强型 LLMs 性能的基准。它包含53个常用的 API 工具,一个完整的工具增强型 LLM 工作流程以及264个带有568次API调用的注释对话。所选取的 API 非常多样化,包括搜索引擎、计算器、日历查询、智能家居控制、日程管理、健康数据管理、账户认证流程等等。由于存在大量的 APIs,LLM 首先通过 API 搜索引擎获取正确的 API 调用,并使用相应文档进行调用。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
LLM 在进行 API 调用的流程示例
 
在 API-Bank 的工作流程中,LLMs 需要做出一些决策,并且在每个步骤中我们可以评估该决策的准确性。这些决策包括:
  • 是否需要调用 API:大模型规划完成任务的能力需求
  • 识别正确的 API 进行调用:如果不够好,LLMs 需要迭代修改 API 输入(例如为搜索引擎 API 确定搜索关键字)。
  • 根据 API 结果进行响应:如果结果不满意,模型可以选择优化并再次调用。
 
此基准测试评估了智能体工具使用能力的三个层次:
  1. Level-1 评估了调用 API 的能力。给定一个 API 的描述,模型需要确定是否要调用给定的 API,正确地进行调用,并对返回值做出适当响应。
  2. Level-2 检查了检索 API 的能力。模型需要搜索可能解决用户需求的各种可能性,并通过阅读文档学习如何使用它们。
  3. Level-3 评估了计划超越检索和调用之外的 API 能力。鉴于用户请求不明确(例如安排团队会议、预订航班/酒店/餐厅等),模型可能必须进行多次 API 调用来解决问题。
 
具身行动
 
具身(Embodyment)是指智能体与环境交互过程中,理解、改造环境并更新自身状态的能力。具身行动(Embodied Action)被视为虚拟智能与物理现实的互通桥梁。生物的进化总能给智能的研究带来很多启发。过去 5.4 亿年来,地球上所有的生物都是通过身体逐步产生智能的。有了身体,智能体就可以在快速变化的环境中移动、导航、生存、操纵和做出改变。相比之下,没有身体的智能体只能「旁观」,很难适应现实世界。由于大模型表现出的强大推理能力,人工智能研究也自然而然地走向了「具身」的道路。人们希望机器人也能像生物体一样,通过与环境交互以及自身的学习,产生对于客观世界的理解和改造能力。具身智能也被斯坦福大学教授李飞飞定义为 AI 领域的下一个北极星问题之一。
 
传统的基于强化学习的 Agent 在样本效率、泛化性和复杂问题推理等方面存在局限性,而 LLM-based Agents 通过引入大模型丰富的内在知识,使得 Embodied Agent 能够像人类一样主动感知、影响物理环境。根据智能体在任务中的自主程度或者说 Action 的复杂程度,可以有以下的原子 Action:
  • Observation 可以帮助智能体在环境中定位自身位置、感知对象物品和获取其他环境信息;
  • Manipulation 则是完成一些具体的抓取、推动等操作任务;
  • Navigation 要求智能体根据任务目标变换自身位置并根据环境信息更新自身状态。
 
通过组合这些原子行动,智能体可以完成更为复杂的任务。当然,受限于物理世界硬件的高成本和具身数据集缺乏等问题,目前具身行动的研究主要集中于游戏平台《我的世界》等虚拟沙盒环境中,比如 GITM、Voyager。尽管如此,近期一些基于大模型的现实具身智能体同样取得了令人兴奋的突破,比如谷歌的 PaLM-E、斯坦福的 VoxPoser 。它们能够直接「听懂」自然语言指令,并将其拆解成若干个动作来完成,准确率已经达到了相当高的水平。以谷歌的 PaLM-E 为例,这个模型集成了参数量 540B 的 PaLM 和参数量 22B 的视觉 Transformer(ViT),使用文本和来自机器人传感器的多模态数据(比如图像、机器人状态、场景环境信息等)作为输入,输出以文本形式表示的机器人运动指令,进行端到端的训练。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
它的结构如下图中间部分所示:绿色的部分用来编码机器人本身的状态,包括底盘、机械臂的位置等状态量;传感器捕捉到的图像由一个 ViT 模型来编码(图中蓝色部分)。给定这些条件,人类就可以发出一个自然语言指令,比如「如何抓起蓝色的木块」,然后这个指令就会被编码为嵌入,并经过一个 CoT(chain of thought)的过程被转换为一系列动作。这些动作会由一个动作解码器(图中的紫色部分)来执行,它会把每个步骤的指令转化为机器人的扭矩等参数。
 

OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘

 

经过测试,整个模型完成任务的成功率接近 80%。作为一个端到端的框架,这是一个让人觉得非常不可思议的工作。

04

智能体应用场景
虽然基于 LLM 的智能体作为一种新兴方向,但已经引起了越来越多的关注。在特定领域和任务中已经开发出许多应用程序,展示了智能体强大而多功能的能力。作为一个基于 LLM 的智能体,其设计目标应始终对人类有益,即使得人类能够善用 AI。具体而言,我们期望智能体可以实现以下目标:
  1. 协助用户摆脱日常任务和重复劳动,从而减轻人们的工作压力并提高任务解决效率。
  2. 不再需要用户提供明确的低级指令。智能体可以独立分析、规划和解决问题。
  3. 在释放了用户的双手之后,智能体还使它们的思维能够参与探索性和创新性工作,在前沿科学领域发挥出全部潜力。

 

   4.1 单智能体场景

 
当前,基于大模型的智能体的应用实例正在蓬勃发展,并主要以单智能体的场景实现,或者将其称之为个体智能体,比如前文提及的 AutoGPT 、 HuggingGPT 、Voyager 等。根据 Zhiheng Xi 等人的划分,单智能体的应用大致分为三种层次:任务导向型、创新导向性和生命周期导向型。
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
这三种类型的智能体区别在于智能体的应用场景和能力要求。任务导向型主要应用于执行任务的场景,创新导向型主要应用于面对未知问题的探索场景,生命周期导向型主要应用于长期生存和自我适应的场景。
 
任务导向型是指智能体在执行任务时,遵循用户的高级指令,执行任务,例如目标分解、子目标的序列规划、环境的交互探索等,直到最终目标实现。任务导向型智能体可以理解人类自然语言命令并执行日常任务,因此它们是目前最受欢迎和实用的智能体之一。
 
创新导向型是指智能体在面对更具智力挑战性的领域,如前沿科学时,具备自主探索的能力,以便在面对未知的科学问题时能够自主地提出解决方案。这需要智能体具备自主学习和自主规划的能力,以便在没有人类干预的情况下,能够自主地探索和发现新的知识。任务导向型的智能体已经在执行任务和提高重复工作效率方面展现出了强大的能力,但是在更具智力挑战性的领域,智能体的潜力尚未得到充分发挥。这主要是由于两个挑战:一方面,科学的内在复杂性构成了重要的障碍。许多领域特定术语和多维结构难以用单一文本表示。因此,它们的完整属性无法完全封装。这极大地削弱了智能体的认知水平。另一方面,在科学领域缺乏适当的训练数据,使得智能体难以理解整个领域知识。如果智能体能够发现自主探索的能力,无疑将为人类技术带来有益的创新。
 
在生命周期导向型中,智能体需要具有持续探索、学习和利用新技能的能力,并确保在开放世界中实现长期生存。这种类型的智能体需要具备自我学习和自我适应的能力,以便在不断变化的环境中适应新的情况。为了实现这一点,智能体需要具备自我监控和自我评估的能力,以便在需要时自我调整。此外,智能体还需要具备自我修复和自我保护的能力,以便在遭受攻击或损坏时能够自我修复并保护自己。在生命周期导向部署中,智能体需要具备自我管理和自我组织的能力,以便在不同的任务和环境中自主地规划和执行任务。这种类型的智能体通常被用于自主机器人、智能家居、智能城市等领域,以实现自主控制和自主决策。
 
一些具有代表性的单智能体系统:
  • 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 多智能体场景

单智能体的核心在于 LLM 与感知、行动的配合。LLM 通过理解用户的任务,推理出需要调用的工具或行动,并基于调用或行动结果给用户反馈。但是对于很多场景来说,单智能体能做的还是太有限了。以写稿为例,完成的操作流程中该场景至少需要4个智能体:
  • Researcher: 根据需求,上网搜各种资料,并把内容扒下来、进行总结。
  • Editor: 根据需求和 Researcher 提供的资料,给出稿件的方向和框架。
  • Writer: 根据 Editor 的指示,完成稿件撰写。
  • Reviewer: 审稿,提出修改意见,返回给 Writer 做改进。
上面这4个智能体,既是4个角色,也是写稿工作流中的4个步骤。显然,单个智能体无法胜任。而且,类似 Reviewer 这样的角色还能让 LLM 自我审核、防止“脑残”。
 
多角色、复杂流程,需要多个 Agent 协作才能胜任,因此需要构建多智能体系统。多智能体系统会为不同的 Agent 赋予 不同的角色定位, 通过 Agent 之间的 协作来完成复杂的任务。 而在完成任务的过程中,相比于单智能体来说,与用户的交互会更少一些。 多智能体场景主要关注智能体们如何有效地协调并协作解决问题,根据任务的协作方式来看可以分为合作型和对抗型:
 
合作型互动:作为实际应用中最为广泛的类型,合作型的智能体系统可以有效提高任务效率、共同改进决策。具体来说,根据合作形式的不同,又可分为无序合作与有序合作。
  • 当所有智能体自由地表达自己的观点、看法,以一种没有顺序的方式进行合作时,称为无序合作(动态对话拓扑)。
  • 当所有智能体遵循一定的规则,例如以流水线的形式逐一发表自己的观点时,整个合作过程井然有序,称为有序合作(静态对话拓扑)。
 
对抗型互动:智能体们以一种针锋相对的对抗方式进行互动。通过竞争、谈判、辩论的形式,智能体抛弃原先可能错误的信念,对自己的行为或者推理过程进行有意义的反思,最终带来整个系统响应质量的提升。
多智能体交互框架
 
目前,多智能体系统在全球研究者的共同努力下如雨后春笋般应运而生,总体来看,多智能体框架的构建主要考虑以下问题:
  1. 单个个体智能体的职能和能力是什么?这个问题即是我们通常所说的角色定义,需要考虑在应用场景中需要的个体智能体分工及能力。
  2. 智能体如何感知应用场景的环境信息?环境信息主要是指系统中定义的智能体、智能体间的可见性、以及其他的用户配置和全局变量。该问题需要我们能够清楚的定义个体智能体的感知能力半径。
  3. 个体智能体间如何交流?具体来说,我们需要考虑不同应用场景智能体间的通信方式,因为基于大模型的智能体以语言交流为主,因此我们重点考虑不同智能体的协作形式(合作还是对抗)、交流方式(纯自然语言还是附加环境变量)和协作模式(有序还是无序/动态还是静态)。
 
因此,我们在设计多智能体交互框架时需要考虑如下四个关键要素:
  • 基础设施:系统是否被设计为用于构建 LLM 应用程序的通用基础设施;
  • 协作模式:实现系统支持的模式类型(有序还是无序/动态还是静态);
  • 执行能力:系统是否能够执行由 LLM 生成的代码或者有效的使用工具;
  • 人类参与:系统是否允许人类在执行过程中参与以及如何参与。
 
接下来,我们介绍一下微软近期开源的多智能体对话框架 AutoGen,该框架具备高度的通用性和灵活性,可以帮助开发者快捷地创建基于大模型的复杂应用。依据微软公司对 AutoGen 的描述,AutoGen 是“一个简化大语言模型工作流编排、优化和自动化的框架。AutoGen 背后的基本概念是“智能体”的创建,这些智能体通过自然语言信息相互作用,完成各种任务。 AutoGen 提供了一个统一的多智能体对话框架,作为使用基础模型的高级抽象。它具有功能强大、可定制和可交流的智能体,通过自动化智能体对话将 LLM、工具和人类整合在一起。通过自动化多个能力强大的智能体之间的对话,可以轻松地使它们集体自主执行任务或与人类反馈合作,包括需要通过代码使用工具的任务。
 
该框架简化了复杂的 LLM 工作流程的编排、自动化和优化。它最大限度地提高了 LLM 模型的性能,并克服了它们的弱点。它使得基于多智能体对话构建下一代 LLM 应用变得轻松无比。
 
AutoGen 抽象并实现了可对话的智能体,旨在通过智能体之间的对话解决任务。具体而言,AutoGen 中的智能体具有以下显著特点:
  • 可对话:AutoGen 中的智能体是可对话的,这意味着任何一个智能体都可以向其他智能体发送和接收消息以启动或继续一次对话。
  • 可定制化:AutoGen 中的智能体可以根据需要进行定制,以整合 LLMs、人类、工具或它们的组合。
 
与此同时,AutoGen 提出了对话式编程的概念。AutoGen 的一个基本洞察是将复杂的 LLM 应用工作流程简化和统一为多智能体对话。因此,AutoGen 采用了以这些智能体之间的对话为中心的编程范式并将这种范式称为对话式编程,通过两个主要步骤简化了复杂应用程序的开发:
  • 定义一组具有特定能力和角色的可交谈智能体(如上所述);
  • 以对话为中心的计算和控制来编写智能体之间的交互行为。通过将自然语言和编程语言相结合,可以实现这两个步骤,并构建具有各种对话模式和智能体行为的应用程序。

OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘

 

上图展示了 AutoGen 中内置的智能体。为了能够通过交换消息相互对话以共同完成任务,该框架设计了一个通用的 ConversableAgent 类。智能体可以与其他智能体进行通信并执行操作。不同的智能体在接收到消息后可能执行不同的操作。三个典型的子类是 AssistantAgent、UserProxyAgent 和 GroupChatManager:
  • AssistantAgent 被设计成作为 AI 助手,使用默认情况下使用 LLMs。当接收到消息(通常是描述需要解决的任务)时,它可以为用户编写 Python 代码。在底层,Python 代码由 LLM(例如 GPT-4)编写。它还可以接收执行结果并提出修正或错误修复建议。
  • UserProxyAgent 概念上是人类的代理,每次交互轮次都会自动征求人类输入作为该智能体的回复,并具有执行代码和调用函数的能力,默认情况下,在接收到可执行代码块且没有提供人工用户输入时,UserProxyAgent 会自动触发代码执行。
  • GroupChatManager 被设计为对话流程的管理者,支持复杂的动态群聊功能,该功能可以动态选择下一个发言者,并将其响应广播给其他代理。
ConversableAgent 的自动回复功能允许更多自治的多智能体之间进行通信,并保留人工干预的可能。
 
OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘
上图是一个基本的 AutoGen 双智能体对话示例:
  1. AssistantAgent 从 UserProxyAgent 接收到包含任务描述的消息。
  2. 然后,AssistantAgent 尝试编写 Python 代码来解决任务,并将响应发送给 UserProxyAgent。
  3. 一旦 UserProxyAgent 收到了来自 AssistantAgent 的响应,它会尝试通过征求人类输入或准备自动生成的回复来进行回复。如果没有提供人类输入,则 UserProxyAgent 执行代码并将结果用作自动回复。
  4. 然后,AssistantAgent 为 UserProxyAgent 生成进一步的响应。然后,UserProxyAgent 可以决定是否终止对话。如果不终止,则重复步骤3和4。
通过采用编程语言和自然语言的对话驱动控制,AutoGen 本身允许有序合作(静态对话)和无序合作(动态对话)。无序合作使得智能体的实际对话流程能够根据不同的输入问题而发生改变,而有序合作的流程始终遵循预定义的对话流程。在交互模式无法提前确定的复杂应用中,无序合作模式非常有用。AutoGen 提供了两种实现无序合作的一般方法:
  • 注册自动回复。通过可插拔的自动回复功能,可以根据当前消息和上下文的内容选择与其他智能体进行对话。可以在 GroupChatManager 中注册了一个自动回复函数,让 LLM 决定在群聊设置中下一个发言者将是谁。
  • 基于 LLM 的函数调用。在这种方法中,LLM 根据每次推理调用中的对话状态决定是否调用特定函数。通过向被调用函数发送附加智能体的消息,LLM 可以动态驱动多智能体对话。
 
下面的图示展示了使用 AutoGen 构建的六个应用程序示例。
 

OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘

 

 
一些具有代表性的多智能体系统:
  • BabyAGI:是一个在 Python 脚本中实现的基于人工智能的任务管理系统示例。在这个实现的系统中,使用了多个基于LLM的智能体。例如,有一个智能体根据前一项任务的目标和结果创建新任务,一个智能体用于对任务列表进行优先级排序,以及一个智能体用于完成任务/子任务。作为多智能体系统,BabyAGI 采用静态智能体对话模式,即预定义的智能体通信顺序。
  • CAMEL:是一个交流型智能体框架。它展示了如何利用角色扮演让聊天机器人之间进行任务完成时的沟通。它还记录了智能体之间的对话以进行行为分析和能力了解。采用了启发式提示技术来实现自主协作。与 AutoGen 不同,CAMEL 并不原生地支持工具使用(例如代码执行)。虽然它被提出作为多 Agent 对话基础设施,但只支持静态对话模式。
  • MetaGPT:是一种基于多智能体对话框架的专用 LLM 应用程序,用于自动软件开发。它们将不同的角色分配给 GPTs 以协作开发软件。它们是针对特定场景的专业解决方案,不是一个通用基础设施。
  • Generative Agents:即我们常说的斯坦福虚拟小镇,它是基于 LLM 做的一个有趣实验,在该实验中,25个虚拟角色,每一个都由 LLM 驱动的,在一个受《模拟人生》启发的沙盒环境中生活和互动。Generative Agents 的设计将 LLM 与记忆、规划和反思机制相结合,使 Agent 可以根据过去的经验行事,以及与其他 Agents 进行互动。角色之间的对话模式是动态的。
 
Generative Agents 的设计将 LLM 与记忆、规划和反思机制相结合,使 Agent 可以根据过去的经验行事,以及与其他 Agents 进行互动。

 

   4.3 人机交互场景

 
在智能体系统中,人类通常会起到重要的作用。一方面,智能体的动态学习能力需要沟通交流来支持;另一方面,目前的智能体系统在可解释性上的表现依然不足,可能会存在安全性、合法性等方面的问题,因此需要人类参与进行规范与监督。
 
Human-Agent 的交互划分为以下两种模式:
 

OpenAI震撼技术圈!0代码构建Assistants API,技术原理探秘

 

05

总结
在本文中,我们深入探讨了 AI 智能体,并详细介绍了相关的技术实现、框架设计和一些示例(包括一些外部的工作和我们自己的尝试)。尽管 AI 智能体目前在大模型的推动下取得了不错的突破和相关落地,但是我们仍然需要认识到现阶段 AI 智能体的局限,主要可以包括以下几点:
  • 可控性有限:Agent 基本由自我迭代组成,而且对每个迭代的部分要求严格,并且这个迭代过程使用 prompt 约束,无法百分百可控。如果涉及到准确性要求,例如 SQLdb、科学计算等,结果更加难以控制。
  • 智能体的记忆和状态存储问题:智能体的行动需要储存记忆和状态,复杂的工作(比如大量的文本、大量的搜索结果)会直接爆 token,如果直接上 GPT-4 32k 或者 Claude 100k,注意力分散也是个问题。
  • 串联任务:目前 Agent 的工作模式绝大多数都是串联,很难优化,框架对并联任务的支持很差;
  • 长运行时间的低可用性:一个简单的需求能跑10分钟;
  • 任务复杂性:Agent 的 prompt 很难测试鲁棒性,某些复杂的任务会出现错误乃至危险;
  • 现阶段 LLMs 的短板:现阶段 LLMs 并没有针对 Agent 各个环节进行调整,而是完全依赖于模型的泛化能力。
-End-
原创作者|刘文强

 

本文仅供学习!所有权归属原作者。侵删!文章来源: 腾讯云开发者 -刘文强 :http://mp.weixin.qq.com/s/lfINl0qb-o9pjpbxKe8dRQ

更多文章:

  1. LangChain:打造自己的LLM应用
  2. 《2023 年度 AI 大事记》
  3. 重磅!AI 驱动的 Java 开发框架:Spring AI Alibaba
  4. 2023 年 AI 盘点(转译)
  5. LLM下半场之Agent基础能力概述:Profile、Memory、Plan、Action、Eval学习笔记
  6. AI辅助编码,应该怎么选?
  7. GitHub Copilot Chat默认Prompt
  8. Prompt之【翻译】
  9. 一文带你了解OpenAI Sora
  10. ChatGPT完胜DeepSeek、通义千问
标签: 腾讯 GPT AI ChatGPT 人工智能 Agent OpenAI
最后更新:2023-11-10

coder

分享干货文章,学习先进经验。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

广告
文章目录
  • 01
  • 02
  • 03
  • 04
  • 05
最新 热点 推荐
最新 热点 推荐
微服务架构:必懂的6大性能维度 Anthropic Code with Claude 开发者大会:开启 AI Agent 新时代 视频笔记-微服务架构P4:必懂5种设计模式 视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构 干货 | 论Elasticsearch数据建模的重要性 马蜂窝消息总线——面向业务的消息服务设计 基于 MySQL Binlog 实现可配置的异构数据同步 视频笔记:Google发布Agent2Agent协议
视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构干货 | 论Elasticsearch数据建模的重要性视频笔记-微服务架构P4:必懂5种设计模式Anthropic Code with Claude 开发者大会:开启 AI Agent 新时代微服务架构:必懂的6大性能维度
从滴滴的故障我们能学到什么 Arthas实战-线上热更新代码只需3步 视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构 Spring中@Autowired和@Inject注解的区别? 仅使用set属性值就把数据库数据给改了 Eureka源码剖析之四:服务续约 笔记 | 网络编程基础:TCP如何保证可靠性 ElasticSearch之各大版本演进,发布8.0.0 Alpha 2版本

CRUD (1) Event Sourcing (1) graphql (1) id (1) NoSQL (1) quarkus (1) rest (1) RocketMQ (2) Spring Boot (1) zk (1) zookeeper (1) 上下文 (1) 事务消息 (1) 二级缓存 (1) 值对象 (1) 关系数据库 (1) 分布式缓存 (1) 原子性 (1) 唯一ID (1) 商品 (1) 多对多 (1) 子域 (1) 字符集 (1) 客户端心跳 (1) 幂等 (2) 干货 (1) 并发 (1) 应用场景 (1) 应用架构图 (1) 康威定律 (2) 异步复制 (1) 微服务架构 (3) 总体方案 (1) 技术方案 (2) 技术架构 (2) 技术架构图 (1) 技能 (1) 持续集成 (1) 支撑域 (1) 故障恢复 (1) 数据架构图 (1) 方案选型 (1) 日记 (1) 服务发现 (1) 服务治理 (1) 服务注册 (2) 机房 (1) 核心域 (1) 泄漏 (1) 洋葱架构 (1) 消息队列 (5) 源码剖析 (1) 灰度发布 (1) 熔断 (1) 生态 (1) 画图工具 (1) 研发团队 (1) 线程 (2) 组织架构 (1) 缓存架构 (1) 编码 (1) 视频 (20) 读写分离 (1) 贵州 (1) 软件设计 (1) 迁移 (1) 通用域 (1) 集群化 (1) 雪花算法 (1) 顺序消息 (1)

推荐链接🔗
  • AI工具集
  • 工具箱🛠️

COPYRIGHT © 2014-2025 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2