什么是AI-Agent智能体从0认识AI智能体
什么是AI-Agent智能体?从0认识AI智能体
一、简介
1、Agent介绍
Al Agent,称为人工智能
代理
,或者称为
AI智能体
。它是一种模拟人类智能行为的人工智能系统,以
大型语言模型(LLM)
作为其核心规划决策引擎。
能够感知环境,做出决策,并执行任务以实现特定的目标。
(1)举例
通俗说,可以将Agent智能体比作一个自动执行任务的小助手。它利用人工智能技术来完成特定的活动或作业。
想象一下,你有一个看不见的机器人,它可以根据你的命令或者自己的判断来帮你做事。这个看不见的机器人就是我们说的“智能体”。
举个例子,想象你在家里用智能音箱(如天猫精灵或小米小爱同学),你说:“帮我播放今天的新闻。“智能音箱就会根据你的命令,从网络上获取最新的新闻,并通过音箱播报出来。
这时,智能音箱就是一个智能体,它感知到了你的语音命令,然后在数字环境中获取新闻信息,并执行了播放新闻的任务。
甚至,你打开抖音,帮你推荐你喜欢的视频,其实抖音app就是一个智能体,它感知了你的兴趣爱好和用户行为,然后给你推荐视频,让你体验数字娱乐。
2、原理
Agents 定义为:
LLM + memory + planning skills + tool use
,即
大语言模型、记忆、任务规划、工具使用的集合
。
(1)架构
吴恩达分享的AI Agents设计模式:
感知(Perception):
Agent通过感知系统从环境中收集信息,这些信息可以是文本、图像、声音等多种形式。
感知是Agent理解周遭世界的第一道工序。
规划(Planning):
对问题进行拆解得到解决路径,既进行任务规划,类似于思维链,分解复杂任务,找到路径。
使用工具(Tool Use):
评估自己所需的工具,进行工具选择,并生成调用工具请求。
这些行动可能是物理的,如机器人的移动,也可能是虚拟的,如软件系统的数据处理,我电脑里面的未归档文件做好归档。
协作(Multiagent Collaboration):
多Agent,不同类型的助理(agent),可以通过
协作
组成一个团队或一家公司
记忆(memory):
短期记忆包括提示词上下文,工具的返回值,已经完成的推理路径;
长期记忆包括可访问的外部长期存储,例如RAG知识库。
(2)任务规划
1、子目标&拆解(Subgoal and decomposition)
我们处理问题的时候会采用”分治”的思想,将复杂任务
拆解
成一个个小任务处理。
这个在 Agent的实现中也是一样,一个复杂任务不太可能一次性就能解决的,需要拆分成多个
并行或串行的子任务
来进行求解,从而提升处理复杂问题的能力。
2、反思&完善(Reflection and refinement)
Agent 能够对过去的行动决策进行
自我反思
,完善过去的行动决策和纠正以前的错误来迭代改进。
ReAct 提示词技术
就是很经典的反思和完善过程。
结合 ReAct 提示词技术的 Agent 会在执行下一步action的时候,加上LLM 自己的思考过程,并将思考过程、执行的工具及参数、执行的结果放到 prompt中,让LLM 对当前和先前的任务完成度有更好的反思能力,从而提升模型的问题解决能力。
ReAct 的提示模板,大致格式如下(
思考、行动、观察
):
Thought: ...
Action: ...
Observation: ...
...(重复以上过程)
(3)记忆
记忆可以定义为用于获取、存储、保留以及随后检索信息的过程。
1、短期记忆(Short-Term Memory(STM))
可以理解为
多轮对话的上下文窗口
,受到Transformer 有限上下文窗口长度的限制,所以尽管对话很长,短期记忆理想情况只保留大模型能够处理的上下文窗口的上限,如果是 first in first out 的模式,则只保留最近的几次对话内容。
2、长期记忆(Long-Term Memory(LTM))
可以理解为
外置知识库
,在 Agent 处理任务的过程中作为额外检索数据的地方。
(4)工具使用
尽管大语言模型在预训练阶段学习了大量的知识,但只能够与大模型"纸上谈兵”,它只会说、不会做,同时也不能回答一些如天气,时间之类的简单问题。
Agent 对于
工具的使用
就是弥补大模型只说不做的缺陷。
Agent可以调用外部 API来获取模型权重中缺失的额外信息,包括当前时间、地理位置信息、代码执行能力、对专有知识库的访问等。
Agent的工作机制
【接收任务】用户提交任务给 Agent。
【组装提示词】Agent 收到用户提交的任务之后,对输入信息进行架构处理合并为最终的 prompt。
【与大模型交互】Agent 将处理后的 prompt提交给 LLM,拿到下一步需要执行的动作和思考过程。
【循环执行】Agent会执行LLM 返回的Action、观察评估结果、获取下一步Action。执行的工程中会自主的判断是否需要使用工具来处理Action 或者获取额外的信息。
3、应用领域
Al Agent技术已广泛应用于多个领域,包括但不限于:
客户服务(Customer Service):自动回答客户咨询,提供个性化服务。
医疗诊断(Medical Diagnosis):辅助医生进行疾病诊断和治疗方案推荐。
股市交易(Stock Trading):自动化交易系统,根据市场数据做出买卖决策。
智能交通(Intelligent Transportation):自动驾驶车辆和交通管理系统。
教育辅导(Educational Tutoring):个性化学习助手,根据学生的学习进度提供辅导。
4、程序开发范式变化
本质上,所有的 Agent 设计模式都是将人类的思维、管理模式以
结构化prompt的方式
告诉大模型来进行规划,并调用
工具
执行,且不断
迭代
的方法。
从这个角度来说,Agent设计模式很像传统意义上的程序开发范式,但是泛化和场景通用性远大于传统的程序开发范式。
在Agent设计模式中,Prompt可以类比为Python这类高级编程语言,大模型可以类比于程序语言编译&解释器。
大模型时代,Al agent编程给IT行业带来了哪些革命性的改变:
1、传统编程语言时代:
以ava、C++、Rust等语言为典型代表,这个时代的软件开发最重要的一件事就是
“抽象建模”
。
产品经理或者技术经理需要深刻地理解现实世界的业务场暴和业务需求,然后将业务需求转化为逻辑流和数据流的处理逻辑,用编程语言进行抽象描述,并且明确定义输入和输出的字段和格式。
然后将软件代码运行在一定的VM平台上,通过简单易用的U交互向终端用户提供产品价值。
2、ML/DL编程时代:
在传统编程时代,程序员们遇到了一个棘手的问题,就是当面对一些超高维的复杂问题(例如图像识别、长文本处理)的时候,传统的if-else逻辑范式几乎无法解决此类问题。
直到出现了神经网络技术之后,程序员们发现可以通过训练一个神经网络(相当于开发了一个程序)就可以很容易图像/文本处理问题。
但是在这个范式中,现实世界的业务场景和软件代码的逻辑之间依然存在非常巨大的鸿沟,建模、UML流程图这些传统编程中必不可少的步骤依然阳碍了软件的大规模应用。
3、AI Agent编程时代:
进入大模型编程时代,现实世界和软件逻辑世界的鸿沟被无限缩短了,原本用于描述和表征现实世界的自然语言、图片、音频等模态语言,可以直接以代码的形态,被大模型这种新型的程序解释器解释并执行。
可以这么说,在Al Agent编程时代,改变的是
建模范式
,不变的是数据流和逻辑流。
5、Agent开发注意事项
function calling 榜单:
https://gorilla.cs.berkeley.edu/leaderboard.html
在实际应用场景中进行Agent开发之前,有一些关键点需要注意和确认:
1、Agent 的规划能力依赖于
prompt 工程
能力,它比想象中更重要、执行起来也更琐碎。
目前 LLM 的数学、逻辑推理能力在 COT的基础上也仅能勉强达到及格水平,所以
不要让Agent一次性做复杂的推理性规划工作,而是把复杂任务人工拆解后再教给Agent。
当然这个论点随着基模的逐步发展和强大可能逐步重要性降低。
2、Agent 的 Action 能力强烈依赖于基座模型的 function calling 能力。
在规划 Agent 之前,对模型的 function calling 能力要充分调研。
加州伯克利大学发布了一个 function caling榜单,其中表现最好的 GPT4准确率是 89%,还不够理想。
3、Agent 的记忆力分为短期记忆和长期记忆。
短期记忆由 prompt负责(in-context learning),类似 Plan and resolve 樺式中的"碎碎念”,告诉Agent已经完成了啥,原始目标是啥。
在长期记忆中,事实性记忆用RAG实现(外部知识库),程序性记忆可用微调或者增量预训练实现(向模型中注入知识)。
4、Agent 的反思能力依赖于它的记忆能力。
上述几点正好对应着 Agent 的四大能力:
规划、反省、记忆、执行
。
用一张图来表示,其中绿色代表对 Agent 开发友好,红色代表对 Agent 应用开发有一些难以逾越的阻碍因素,需要靠产品降级来解决
二、提示词工程
1、介绍
提示工程(Prompt Engineering),也称为
上下文提示
,是一种通过不更新模型的权重/参数来引导LLM行为朝着特定结果的方法。
提示工程可以用于各种任务,从回答问题到算术推理乃至各种应用领域,理解提示工程,能够帮助我们了解LM的限制和能力。
硬提示(Hard Prompt)
传统提示是以自然语言的形式手动设计的。
例如,想让模型完成一个任务时,你可能会输入一句话,像“今天的天气如何?"。这种提示直接使用了自然语言,是固定不变的。
软提示(Soft Prompt)
软提示并不一定是自然语言,而是通过在模型训练过程中学习得到的一种向量表示。
它可能不具有任何语言意义,但能够通过改变模型内部的激活模式来影响模型的输出。
软提示不需要由人类显式编写,而是通过训练数据来学习最有效的提示。
在web端的大模型界面使用不到,一般编程做大模型任务的时候可以用到缩减成本。
Prompt Tuning是一种参数高效的微调方法,它属于软提示(Soft Prompt)的一种实现方式。
在 Prompt Tuning中,模型的权重被固定,只有提示(prompt)的参数会被更新。
软提示的使用通常分为两个主要部分:
生成软提示向量
和
将软提示应用于模型推理
2、软提示(Soft Prompt)使用例子
场景:电影评论情感分类任务。
假设我们有一个预训练的大型语言模型(例如llama3.1),你想让模型判断一段电影评论是
积极
还是
消极
的。
但我们不想用很多资源去微调整个模型,而是希望通过软提示来快速适应这一任务。
1、准备数据
我们有以下几条电影评论数据(少量数据,因为我们要用软提示实现少样本学习):
评论1:“这部电影太棒了,我非常喜欢!”
评论2:“这部电影真是无聊透顶,浪费时间。"
评论3:“演员的表演很精彩,但故事情节比较平淡。"
我们希望模型能够根据这些评论的内容给出“积极“或“消极”的情感分类。
2、生成软提示(Soft Prompt Tuning)
与传统的硬提示不同,软提示是通过学习的方式来自动生成的,这个过程大致包括以下步骤:
Step 1:初始化软提示向量
软提示不是自然语言词汇,而是由一组随机初始化的
向量
组成。例如,假设我们决定使用长度为10的提示,那么初始的软提示就是一组随机向量
p=[p1,p2,...,p10]
。
Step 2:联合训练软提示和模型
现在,我们将这些软
提示向量与评论数据结合起来
作为输入。
例如,对于评论1(”这部电影太棒了,我非常喜欢!”),模型的输入可以是软提示
p+评论文本
。
这些软提示向是不需要人类显式设计,而是通过训练数据进行调整的。
输入
1:[p1,p2,..,p10]
- “这部电影太棒了,我非常喜欢。
输入
2:[p1,p2,...,p10]
- “这部电影真是无聊透顶,浪费时间。”
我们将这个结合输入(软提示+评论文本)送入模型,同时提供相应的标签(“积极“或“消极”)来进行训练。
通过梯度下降等优化方法,模型会逐渐调整这组软提示向量,使其与评论分类任务相关联。
软提示最终会学习到特定的向量表示,它们可以增强模型在情感分类任务中的表现。
Step3:固定预训练模型,仅调整软提示
重要的一点是,在整个过程中,我们不改变预训练的语言型的权重。
我们只调整和优化软提示向量。这意味着通过少量的数据和计算资源,我们就能让模型适应情感分类任务。
3、应用软提示进行推理
一旦软提示经过训练并学会了如何帮助模型执行分类任务,我们可以将这些提示用于新数据。
例如,当我们输入一个新的评论:
评论4:“故事情节非常有趣,特效也很棒!”
推理阶段,我们会将训练好的软提示与这条评论结合:
推理输入:
[p1,p2,...,p10]+“故事情节非常有趣,特效也很棒!"
模型根据软提示的辅助,可以更加准确地给出情感分类,可能预测出“积极“结果。
3、软提示(Soft Prompt)训练
以下是软提示训练的详细步骡,以及前缀向量是如何更新的。
1、初始化前缀向量
首先,初始化一组前缀向量
P = [p1, p2, ……, Pk]
其中k是向量的维度。通常这些向量是
随机生成
的,或者使用零向量初始化。
2、准备训练数据
准备一小部分与任务相关的数据集,包括输入文本和相应的标签。
例如,在情感分类任务中,输入可能是电影评论,标签则是“积极“或“消极”。
3、构建模型输入
在训练过程中,每次输入将结合前缀向量和任务文本。例如,对于一个输入评论,模型的输入可以表示为:
Input =[p1,P2, ..., Pk] + 评论文本
4、前向传播
将输入送入预训练语言模型,模型会根据输入的前缀向量和文本生成一个输出。这个输出通常是一个预测,比如情感分类的概率分布。
5、计算损失
根据模型输出和真实标签,计算损失函数。例如,常用的损失函数是交叉熵损失(cross-entropyloss):
6、反向传播和优化
通过反向传播算法计算损失对前缀向量P的梯度。反向传播会将损失的梯度从输出层传递回输入层,从而计算出前缀向量的更新。
具体更新步骤如下:
7、重复训练
重复步骤3到6多次,直到模型的性能达到预期或损失收敛。通常在训练期间需要监控模型在验证集上的表现,以防止过拟合。
4、提示工程(Prompt Engingeering)基本方式
(1)Zero-shot Prompt
用户的输入问题直接被传入了大模型中,并将大模型返回结果直接返回给了终端用户
#提示词
将文本分类为中性、负面或正面,
文本:我认为这次假期还可以。
情感:
#输出:
中性
(2)Few-shot Prompt
few-shot prompt则是通过提供模型少量高质量的示例,这些示例包括目标任务的输入和期望输出。
通过观察这些良好的示例,模型可以更好地理解人类意图和生成准确输出的标准。
与zero-shot相比,few-shot通常会产生更好的性能。
然而,这种方法可能会
消耗更多的token
,并且在处理长文本的输入或者输出的时候可能会遇到上下文长度限制的问题。
在Few-shot Prompting中,提示包含
少量示例
(称为“shots”),向模型展示期望的输出应该是什么样子。
通常,使用两到五个示例,为模型提供从模式和结构中学习的框架,这个过程被称为
上下文学习(in-context learning)
。
Few-shot Prompting的工作原理包括以下几个步骤:
查询制定:用户通过包含清晰的任务描述和相关示例来制定提示。
示例提供:在提示中提供几个示例,这些示例展示了任务的输入和期望输出。
模型学习:模型通过这些示例学习任务的模式和结构,然后能够对新的输入生成准确的响应。
让我们看一下面的例子:
任务描述:对给定的文本进行情感分析,判断其是积极的、消极的还是中性的。
示例对:
输入:这部电影真是太棒了,我强烈推荐!
输出:积极
输入:服务很慢,食物冷冰冰的。
输出:消极
输入:天气不错,适合散步。
输出:中性
新输入:这个产品符合我的期望,价格也很合理。
预期输出:积极
我们可以从上面的提示中看到,模型被给定一个或几个例子,然后能够为下一个问题生成答案。
(3)思维链Chain-of-Thought Prompting
Chain-of-Thought(CoT)提示生成一系列短句,即被称为
思维链
的句子。
这些句子描述了逐步推理逻辑,导致最终答案,对于复杂推理的任务和较大的模型,可获得更多的好处。
常见的两种基本CoT提示包括
Few-shot CoT和Zero-Shot CoT
,并在下面对它们进行描述。
(4)Few-shot CoT
Few-shot CoT允许模型查看一些高质量推理链的演示。
在问LLM问题前,手工在prompt里面加入一些包
含思维过程(Chain of thought)的问答示例
,就可以让LLM在推理任务上大幅提升。
让我们看下面的例子:
#few shot
问:罗杰有5个网球。他又买了两罐网球。每个罐子有3个网球。他现在有多少个网球?
A:11个
问:自助餐厅有23个苹果。如果他们用20个做午餐,再买6个,他们有多少个苹果?
A:27个
#few shot cot
问:罗杰有5个网球。他又买了两耀网球。每个罐子有3个网球。他现在有多少个网球?
A:罗杰从5个球开始。2罐3个网球每个球等于6个网球。5+6=11答案是11。
问:自助餐厅有23个苹果。如果他们用20个做午餐,再买6个,他们有多少个苹果?
A:自助餐厅原来有23个苹果。他们用20个来做午餐,剩下23-20=3。所以他们又买了6个苹果,就有了3+6=9,所以他们的答案是9。
(5)Zero-shot CoT
Zero-shot CoT(Zero-shot Chain of Thought)是一种无需任何标注数据即可激发大型语言模型(LLMS)进行复杂推理的技术。
这种方法的核心在于使用特定的提示语,如
"Let's think step by step”
,来引导模型生成推理步骤,并基于这些步骤得出答案。
让我们看一个下面的例子:
prompt:
我去市场买了10个苹果。我给了邻居2个苹果和修理工2个苹果。然后我去买了5个苹果并吃了1个。我还剩下多少苹果? 让我们一步步思考。
推理:
首先,从10个苹果中减去给邻居的2个和修理工的2个,剩下6个苹果。然后,加上新买的5个苹果,总共有11个苹果。最后,减去吃掉的1个苹果,剩下10个苹果。
答案:
我还剩下10个苹果。
Zero-shot CoT能够帮助我们看到模型内部,并了解它是如何推理得出答案的。
(6)自一致性(Self.Consistency)
通过独立生成多条解题思路并对最终解答进行多数表决,增强了推理过程的鲁棒性。
就是少数服从多数的结果。
本文提出了一种新的解码策略—— self-consistency,以取代贪婪解码。
例子:
Q:假设你有 3 个苹果,又买了2个苹果,现在你有多少个苹果?
A1:
首先,我有 3 个苹果。
接着,我又买了 2 个苹果。
因此,我现在总共有3+2=5个苹果。
A2:
首先,我有3个苹果。
然后,我买了 2 个苹果。
所以总共有3+2=5 个苹果。
A3:
我有3个苹果,买了2个苹果,所以我有5个苹果。
聚合结果:每次的答案都是5,因此选择答案5作为最终结果
(7)思维树 (Tree of Thought)
思维树(Tree of Thought,简称 ToT)
是一种新型的语言模型推理框架,它通过模拟人类的决策过程来解决复杂问题。
这种方法允许大型语言模型(LLMs)通过考虑多个不同的推理路径和自我评估选择来决定下一步行动,并在必要时向前看或回潮以做出全局选择,从而进行深思熟虑的决策。
它首先将问题分解为多个思维步骤,并在每个步骤中生成多个思维,实质上是创建一个树形结构,搜索过程可以是广度优先过程或深度优先的过程。
提示词:
假设三位不同的专家来回答这个问题。
所有专家都写下他们思考这个问题的第一个步骤,然后与大家分享。
然后,所有专家都写下他们思考的下一个步骤并分享。
以此类推,直到所有专家写完他们思考的所有步骤。
只要大家发现有专家的步骡出错了,就让这位专家离开。
请问..
5、Co-STAR提示词框架
这是 Shella Teo 用来赢得新加坡 GPT-4 提示工程竞赛的框架。CO-STAR 的每个字母都代表提示词的一个具体部分。
”C“代表”Context(上下文)“你可以在这里给出任何相关的背景信息,比如你自己或是你希望它完成的任务的信息。
“O"代表”Objective(目标)“在这里,你需要给出非常明确的指示告诉 ChatGPT 你希望它做什么。
“S"代表"style(风格)“在这一部分,我们需要告诉 ChatGPT我们想要的写作风格可以是有趣的,比如我们希望它以Snoop Dogg的说唱风格来写作或者像顶级 CEO 那样的风格。
“T“代表“Tone(语调)“你希望回答的语调是什么?幽默的?情绪化?有胁性?由你来决定。
“A"代表”“Audience”,即我们要告诉 ChatGPT 的听众是谁。比如说,如果目标听众是五岁的孩子,那么结果会截然不同于目标听众是世界级物理学家的情况。
最后一个字母”R”,代表"Response”——我们想要的回应类型。我们需要一份详细的研究报告吗?或者需要一个表格?我们需要一个复杂的编程格式,比如JSON 吗?或者只是一大堆文字?你想要的,在这里都能找到。
具体的构建方法是这样的:
首先,我提供了一个我经营的背景,如我制作AI课程。
接着,我设定目标是撰写一个社交媒体(比如小红书风格)帖子以吸引人们购买。
然后,我设定我需要的风格,基本上是模仿小红书文案的方式。
其次,我要求AI用礼貌并且具有说服力的语调来编写文案。
第五,我告诉AI目标受众为 30 岁左右的人群。
最后,我指定了AI回答的格式:“你的回复应该是四句话,不需要话题标签,但需要加入一些表情符号。”
试用CO-STSR设计模型,有几个基本原则需要遵守:
借助 CO-STAR 框架构建高效的提示
利用分隔符来分节构建提示
设计含有 LLM 保护机制的系统级提示
仅依靠大语言模型分析数据集,无需插件或代码。
三、常用的Agent平台
1、钉钉
几乎所有
工作交流和大部分文件传输
都在钉钉上,日常聊天内容和文件网盘都在钉钉上,知识无需搬迁,使用效率极高,使用体验很好;
在请假、招聘、会议等重复性很高的办公流程上,钉钉的助理(实际就是Agent)非常好用,因为这就是对钉钉原有业务的增强。
目前钉钉给出来的功能更多是聚焦在
办公室业务
上,还无法深入企业的核心业务;
作为一家企业,如果要对外服务,不能要求他们的所有客户都用钉钉,也不希望把所有数据都放在钉钉上。
对普通用户来说,最好的是钉钉,其次是Coze,Dify有点难度。
2、Dify
Dify官网:
https://cloud.dify.ai/apps
(需要科学网)
使用
无代码和画板
让用户自建由Agent组成的workfiow,热度很高,各种社区上被开发者热捧,在一定程度上在LLM企业应用上往前走了一步。
Dify 的用户:试用系统默认只支持
Github和Google账号
登录使用,用户至少是产研人员目标客户不是无研发能力的公司(基础太弱,知识积累不成体系,造成应用场景很窄)和大型科技公司(自己会造)RAG会长期存在,且会越来越偏向数据工作。
也有对应的开源代码:
https://github.com/langgenius/dify
3、Coze
网址:
https://www.coze.cn/home
Coze,作为字节精心打造的
AI Bot开发旗舰平台
,致力于赋能开发者,以强大而简洁的界面,加速智能聊天机器人的设计与部署流程。
在中文大模型智能体生态中,Coze以其先驱地位做视群雄,无论是率先布局的市场先机,还是其在智能体编排工具的成熟度、插件的广泛性、兼容大模型种类的多样性,乃至发布渠道的全面覆盖,均展现出非凡实力。
Coze平台慷慨开放,无论是其自研的
云雀大模型
,还是外部知名的moonshot等尖端技术,均对开发者免费开放,极大地降低了创新门槛。
用户体验好、日活用户数大、底层技术支撑完善,Coze是众多智能体平台中佼佼者。
字节另一款AI智能对话助手:豆包以其独特的prompt驱动方式,让用户能够轻松定制专属智能体,无缝集成了先进的TTS(文本到语音)技术,让自定义的智能体能够直接与用户进行语音交互,更偏向于C端用户。
相较于Coze的全方位智能体构建方案,豆包更像是一款功能精炼、操作快捷的便携式Coze版本,尤其适合在移动端快速高效地应用。
4、百度干帆AgentBuilder
网址:
https://agents.baidu.com/center
百度AgentBuilder是一款智能体开发工具,旨在降低智能体开发门槛,让每个人、每个组织都能够成为智能体的开发者。
AgentBuilder是百度推出的三大AI开发工具之一,另外两个工具分别是AppBuilder和ModelBuilder。
产品形态:基于文心大模型的智能体平台,也是平台型。
开发方式:支持开发者根据自身行业领域和应用场景选择不同类型的开发方式,提供低成本的prompt编排方式。
功能特点:提供零代码和低代码两种开发模式,适合不同技术背景的开发者。
5、阿里云魔搭社区
网址:
https://modelscope.cn/home
产品形态革新:
专为开源大语言模型(LLM)量身定制的AI Agent开发框架。
完美兼容各类主流LLM,高度灵活与可扩展的平台,让Al Agent的开发与部署更加便捷高效。
开发方式多元化:
该框架支持创建多样化的多模态Al Agent,涵盖客户服务、个人助理等多个领域,满足不同场景下的智能化需求。
用户可以根据具体业务场景,轻松构建出既能处理文本对话,又能理解图像、语音等多类型信息的智能体。
一键协作,简化流程:
该框架创新性地引入了一键发送指令调用其他AI模型的功能,大幅简化了型集成与协作的流程。
用户无需深入技术细节,即可轻松实现多模型间的无缝对接,提升整体项目的智能化水平和响应速度。
低/零代码平台,降低门槛:
为了进一步降低Al Agent的开发门槛,我们结合了低/零代码平台的设计理念,让非技术背量的用户也能参与到AI应用的开发中来。
通过直观的图形化界面和丰富的预设模板,用户可以快速上手,实现个性化定制的智能体,无需编写复杂的代码。
6、智谱
网址:
https://chatglm.cn/main/alltoolsdetail
智谱清言推出的Agent生成器,在提供基础智能体生成能力的同时,独具特色地支持开发者通过API调用方式灵活使用智能体。
该API广泛覆盖清言C端页面的核心功能,包括
文本对话、文生图、图片解读、联网搜索、文档解析、Python代码执行及外部API调用
等。
在智能体中心,热门智能体琳琅满目,既有官方精心打造的,也有个人开发者热情贡献的。这些智能体紧贴时事热点,如高考志愿填报助手便是一例,彰显了其高度的实时性和实用性。
此外,分类上与其他平台相似,涵盖了工具类(搜索、修图、数据分析等)、娱乐类(搞笑、角色对话)及生活类(搭配选择)等多个领域,满足不同用户的多样化需求。
7、讯飞的星火友伴
网址:
https://xinghuo.xfyun.cn/desk
讯飞科技,以其深厚的AI技术底蕴,携手星火V3.0这一强大引擎,精心打造了一个专注于虚拟人格GPTs应用的创新平台。
该平台不仅代表了讯飞在人工智能领域的又一里程碑式成果,更是为探索个性化智能交互体验开辟了全新的道路。
智能体中心,是由讯飞官方精心设计的
虚拟人格模板
,这些模板各具特色,涵盖了从亲切友善的客服助手到风趣出默的聊天伙伴,再到专业严谨的顾问导师等多种角色设定。
用户可根据自身需求与偏好,轻松选择一款合适的模板作为起点,也可以通过平台的强大功能进行二次改造与个性化定制。
四、Tool Use与Function call
1、MRKL
“模块化推理、知识和语言”(Modular Reasoning, Knowledge,and Language)的缩写,MRKL 系统被提议包含一组”专家“模块,通用LLM 充当路由器,将查询路由到最合适的专家模块。
这些模块可以是
其它模型(例如深度学习横型)或外部工具(例如数学计算器、货币转换器、天气 API)
。
MRKL的核心思想是,现有 LLM(如 GPT-3)等仍存在一些缺陷,包括遗忘、外部知识的利用效率低下等。
MRKL将神经网络模型、外部知识库和符号专家系统相结合,提升了自然语言处理的效率和精度。
通过 MRKL 系统,不同类型的模块能够被整合在一起,实现更高效、灵活和可扩展的 AI 系统。
2、TALM
工具增强语言模型(Tool Augmented Language Models)是一种通过整合
外部工具
来增强大型语言横型(LLMs)能力的方法。
大型语言模型(LLM)在zero-shot和few-shot任务上表现出印象深刻的结果,展示了涌现能力。
这些模型存在固有限制,包括无法获取最新信息、幻觉事实倾向、低资源语言理解困难、缺乏精确计算数学技能和对时间进程的不了解。
工具增强语言模型的应用领域非常广泛,包括但不限于:
信息检索
:通过搜索引擎等工具获取最新信息,提高模型在实际业务中的应用能力。
复杂推理
:利用工具进行数学计算、逻辑推理等,解决传统语言模型难以处理的问题。
自动化和效率提升
:通过自动化工具提高工作效率,如自动生成代码、执行程序等。
3、Toolformer
github项目:
https://github,com/lucidrains/toolformer-pytorch
是由MetaAl提出的一项创新研究,旨在赋予语言模型使用外部工具的能力。
通过Toolformer,语言模型可以在生成文本时自动调用API,从而获取并整合外部信息,提升文本生成的准确性和实用性。
它能够通过自监督学习的方式教会自己使用各种工具,如计算器、问答系统、搜索引擎、翻译系统和日历等。
这种方法允许模型在处理任务时,通过调用相应的工具来获取所需的信息或执行特定的功能,从而提高模型的性能和适用性。
Toolformer 的核心思想是让语言机型学会在适当的时机调用适当的工具,而
这一过程不需要大量的人工注释,而是通过模型自身的上下文学习能力来实现
。
4、function call
函教调用是指可靠地连接LLM与外部工具的能力。让用户能够便用高效的外部工具、与外部API进行交互。
GPT-4和GPT-3.5是经过微调的LLM,能够检测函数是否被调用,随后输出包含调用函数参数的JSON。
函数调用功能可以
增强模型推理效果或进行其他外部操作
,包括信息检索、数据库操作、知识图谱搜索与推理、操作系统、触发外部操作等工具调用场景。
需要注意的是,大模型的 Function call不会执行任何的函数调用,仅
返回调用函数所需要的参教
,开发者可以利用模型输出的参数在应用中执行函数调用。
5、openai
ChatGPT插件和 OpenAI API 函数调用是 LLM 在实践中增强工具使用能力的良好示例,工具API集合可以由其他开发人员提供(如插件)或自定义(如函数调用)。
(1)例子1
通过查询天气举个例子,这块我用openai的funciton call进行演示。
首先我们定义一些function,如下所示,我只定义了一个查询天气的的数get_current_weather,我们需要对这个的教进行简单的描述,如“获取今天的天气”。
这个函数有两个参数,分别是地点location和时间time,也需要进行文本描述。
LLM根据函数描述,参数描述以及用户的输入,来决定是不是要调用这个funciton。
请求里如果有functions字段,返回了json,并帮我们从输入文本里抽取了get_current_weather所需要的location和time的函数值。
本质上ChatGPT就是在帮我们在做个
文本结构化
。
ChatGPT并不帮我们真正的去查询天气,但是我们可以真的用python去定义一个get_current_weather函数,在这个函数里,编写程序(调用查询天气的工具包)去实现查询天气的功能,函数的输入就用ChatGPT返回的ison里的内容。
相当于我们通过编程帮ChatGPT提供了一个查询天气的工具,因此也可以管function call叫做
“工具调用”
。
get_current_weather返回天气信息给ChatGPT,ChatGPT再回答给用户。
我们可以定义各种功能的函数帮ChatGPT完成任务,比如查询网页,算数等,因此工具调用对于agent来说非常重要。
tools是一个json对象列表,每一个json对象,都是一个function对象,有名字name,有description描述信息,大模型就是根据这个description来判断是调用哪个function。
(2)多function
6、通义千问
文档:
https://help.aliyun.com/zh/model-studio/developer-reference/use-qwen-by-calling-api
响应结果:
7、API-Bank
大语言模型(LLM)可以通过利用外部工具来增强其功能。
三个关键问题:
(1)目前的LLMS在使用工具方面的效率如何?
一个由73个API工具组成的可运行评估系统。用753个API调用对 314个工具用对话进行标注,评估现有LLMs在规划、检索和调用 API方面的能力。
(2)如何提高LLMs运用工具的能力?
一个全面的训练集,其中包含来自 1000 个不同领域的2138 个API 的1888 个工具便用对话。
(3)使用工具需要克服哪些障碍?
API的选择相当多样化,包括搜索引擎、计算器、日历查询、智能家居控制、日程管理、健康教据管理、账户认证工作流等等。
要提升大模型工具便用的准确率和有效性,还需要进一步提升大模型能力。
在 API-Bank 工作流程中,LLM 需要做出几个决策,并且我们可以在每个步骤中评估该决策的准确性
。
决策包括:
(1)是否需要API调用
(2)确定要调用的正确的 API:如果不够好,LLM 需要迭代修改 API输入(例如,决定搜索引擎 API 的搜索关键字)
(3)根据 API结果做出响应:如果结果不满意,模型可以选择改进并再次调用
能力评估
该基准从三个层面评估代理的工具使用能力:
level 1 评估调用 API的能力
在给定 API的用法描述和对话历史的前提下,模型需要判断是否调用 AP|、正确地调用 AP!、获得 API调用结果后正确的回复用户。
对应上图 api pool
level 2 考察检索 API的能力
在测试开始时,模型仅被告知 API检索系统的用法,任何对话中需要用到的特定 API的信息都不可见。LMS必须根据对话历史判断用户需求,关键词搜索可能能够解决用户需求的 API,并在检索到正确的 API后学习如何使用 API。
对应上图 api search
level3 评估除了检索和调用之外规划 API的能力
在这个级别中,用户的需求可能不明确,需要多个API调用步骤来解决。伤收:“我想从上海到北京旅行一周,从明天开始,帮我规划旅行路线并预订航班、门票和酒店”。LLMs 必须推断出合理的旅行计划,并基于计划调用航班、酒店和门票预订 API来完成用户需求
对应上图 plan
五、Agent设计模式
1、Zero-shot模式
这是最接近C端大多数人初次体验ChatGPT时的交互模式。
在这种Agent模式之下,用户的输入问题不增加任何prompt template处理,直接被传入了大模型中,并将大模型返回结果直接返回给了终端用户。
在大多数的终端应用开发场暴中,这种Agent开发模式都是无法满足需求的。
2、Few-Shot 模式
这种模式和PlainPrompt最大的区别在于,它开始有了prompt template逻辑,因为prompt template的存在,开发者得以调用大模型的context-learning(上下文学习)能力。
Few-Shot 模式应该是B端开发场景中使用频率最高的一种Agent范式。
大体上,这种范式中有几个核心组成部分:
角色描述:一句话描述清楚你希望大模型扮演什么样的角色,以及需要具备的能力和技能。
指令任务描述:可以是一句话,也可以通过提示词引导大模型按照一定的步骤逐步解决问题。
样例:一个完整的“任务-解决方案”示例,或者是入参/出参的格式。
工程师可以通过大模型的指令遵循能力,将原本需要通过复杂规则定义和处理的环节,都通过大模型重做一遍,提升工作效率。
3、ReAct模式
(1)原理
ReAct 原理很简单,没有 ReAct 之前,Reasoning和 Act是分割开来的。
ReAct针对给出的问题,先进行思考,再根据思考的结果行动,然后观察行动的结果,如果不满足要求,再进行思考、行动,直至得到满意的结果为止。
采用few-shot In-context学习来生成解决问题的action和thought序列。
每个in-context样例是由action、thought、observation构成的行为轨迹。
在推理占主导地位的应用中,我们交替生成thought和action,这样完整的行为轨迹就是多个thought-action-observation步骤。
相反在决策生成任务中(涉及大量action),thought只会在行为轨迹中最相关的位置稀疏出现。
举个例子,让孩子帮忙去厨房里拿一瓶酱油,告诉ta一步步来(COT提示词策略):
。先看看台面上有没有
。再拉开灶台底下抽屉里看看
。再打开油烟机左边吊柜里看看
在没有 ReAct的情况就是:不管在第几步找到酱油,孩子都会把这几个地方都看看(Action)
有 ReAct的情况是:
。Actilon1:先看看台面上有没有
。Observation1:台面上没有酱油,执行下一步
。Action2:再拉开灶台底下抽屉里看看
。Observation2:抽屉里有酱油
。Action3:把酱油拿出来
在论文的开头作者也提到人类智能的一项能力,即每次执行行动后都有一个
"自言自语的反思(Observatlon:我现在做了啥,是不是已经达到了目的)
这相当于让 Agent 能够维持
短期记忆
。
(2)实现
个ReAct流程里,关键是三个概念:
Thought
由LLM模型生成,是LLM产生行为和依据
可以根据LLM的思考,来衡量他要采取的行为是否合理
这是一个可用来判断本次决策是否合理的关键依据,相较于人类,thought的存在可以让LLM的决策变得更加有可解释性和可信度。
Act
Act是指LLM判断本次需要执行的具体行为
Act一般由两部分组成:行为和对象。用编程的说法就是API名称和对应的入参
LLM模型最大的优势是,可以根据Thought的判断,选择需要使用的API并生成需要填入API的参数。
从而保证了ReAct框架在执行层面的可行性。
obs
LLM框架对于外界输入的获取,就像LLM的五官,将外界的反信息同步给LLM模型,协助LLM模型进一步的做分析或者决策。
一个完整的ReAct的行为,包涵以下几个流程:
1、输入目标:任务的起点。可以是用户的手动输入,也可以是依靠触发器(比如系统故障报警)。
2、LOOP:LLM模型开始分析问题需要的步骤(Thought),按步执行Act,根据观察到的信息(Obs),循环执行这个过程。直到判断任务目标达成。
3、Finish:任务最终执行成功,返回最终结果。
(3)示例
通义千问 ReAct提示词模版:
https://github.com/QwenLM/Qwen/blob/maln/examples/react_prompt.md
构建提示词
根据 ReAct prompt模版、query、工具的信息构建 prompt
完整提示词
qwen网页端模拟过程1
注意:现在的通义千问(qwen2.5)已经不支持这种形式实验啦,主要还是演示流程为主
将这个 prompt 送入千问,并记得设置"Observation"为 stop word(见后面 设置stop word)——即让千问在预测到要生成的下一个词是"Obseration"时马上停止生成 —— 则千问在得到这个 prompt 后会生成结果
设置 Stop word
为了让 一系列Thought,Action和Observation,串行执行,特别是等 action完成之后,得到结果后生成Observation设置"Observation"为 stop word —— 即让千问在预测到要生成的下一个词是"Observation"时马上停止生成。
每一轮提交prompt的时候,需要通过chat 接囗的stop_words_ids 指定为Observation:
4、Plan and solve 模式
为了提升LLM的多步推理(multl-step reasoning)能力,讨论COT问题中 Zero-Shot 时 对推理质量的提升
论文首先分析了在 Zero-shot COT时的错误分布
其中三种错误:
计算错误,步骤缺失和语义理解错误
占比挺高,其余的错误可能是因为LLM本身能力(capability)不足导致的
。计算错误 7%
。步骤遗漏错误 12%
。语义理解错误 27%
为了解决计算错误,提升LLM生成的推理步骡(reasoning steps)质量,又对PS prompting进行了扩展,提出了PS+ prompting。
为了解决多步推理的
步骤缺失
问题,提出了Plan+and-solve(PS) prompting方法,下文简称为PS,它由两部分组成,首先设计计划,计划的目标是将整个任务划分为多个更小的
子任务
,然后根据计划执行子任务。
实现原理
这种设计模式是
先有计划再来执行
。
如果说 ReAct更适合 完成”厨房拿酱油”的任务
那么 Plan & solve 更适合完成”西红柿炒鸡蛋”的任务:
你需要计划,并且过程中计划可能会变化(比如你打开冰箱发现没有西红柿时,你将购买西红柿作为新的步骤加入计划)
规划器:
负责让 LLM 生成一个多步计划来完成一个大任务。
代码中有 Planner 和和 Replanner,Planner 负责第一次生成计划;
Replanner 是指在完成单个任务后,根据目前任务的完成情况进行 Replan,所以 Replanner提示词中除了Zeroshot,还会包含:
目标,原有计划,和已完成步骤的情况
。
执行器:
接受用户查询和规划中的步骤,并调用一个或多个工具来完成该任务。
提示词结构
PS Prompting也属于zero-shot CoT 类型的工作,简单说,就是用
"Let's first understand the problem and devise a plan to solve the problem. Then let's carry out the plan and solve the problem step by step"
代替Zero-shot-CoT提出的"Let’s think step by step
翻译:【让我们先了解问题并制定一个解决问题的计划。然后,让我们执行计划,逐步解决问题】
prompt template是
"Q: [X]. A:[T]"
X是问题描述,T是trigger指令,作者设计的T重点是包含了计划相关的描述:devise a plan和carry out the plan
即"Q:[X]. A: Let’s first understand the problem and devise a plan to solve the problem. Then, let’s carry out the plan and solve the problem step by step.“调用LLM得到推理步骤。
为了让LLM更加关注计算部分和中间步骤来提升准确率,作者进一步提出了PS+Prompting,就是在T中添加了:
pay attention to calculation, extract relevant variables and their corresponding numerals(不要忽略题目X中的相关信息)、calculate intermedlate results(让LLM生成的推理步骤质量更高)
翻译:【注意计算,提取相关变量及其对应数字】
和原始Zero-shot-CoT一样,需要调用
两次
LLM
一次生成
推理过程
:首先,通过给模型一个提示,如"Let’s think step by step”,模型会生成解决特定问题的推理过程,这个过程模拟了人类解决问题时的思考步骤,有助于模型更好地理解和解决问题。
一次提取最终答案:然后,使用生成的推理过程和原始问题,模型再次被调用以提取或生成最终的答案,这个步骤是为了从推理过程中得出结论,直接给出问题的答案。
5、Reason without observation 模式
(1)原理
核心思想是将推理(Reasoning)过程与外部观察(Observation)分离,以此来提高型的效率和性能。
在传统的LLM增强系统中,如ReAct模式中,模型的推理过程是与外部工具的调用和观察结果紧密交织在一起的。
这种模式虽然简单易用,但往往会导致
计算复杂性高
,因为需要多次调用语言模型(LLM)并重复执行操作,这不仅增加了计算成本,也增加了执行时间。
REWOO模式通过以下几个步骤来优化这一过程:
1、Planner(规划器)
首先,规划器接收用户输入的任务,并将其分解为一系列的计划(Plans)。
每个计划都详细说明了需要便用哪些外部工具以及如何使用这些工具来获取证据或执行特定的动作。
负责生成一个相互依赖的“链式计划”,定义每一步所依赖的上一步的输出。
2、Worker(执行器):
接下来,执行器根据规划器提供的计划,调用相应的外部工具来执行任务,并获取必要的信息或证据。
循环遍历每个任务,并将任务输出分配给相应的变量。当调用后续调用时,它还会用变量的结果替换变量。
3、Solver(合井器)
最后,合并器将所有计划的执行结果整合起来,形成对原始任务的最终解决方案。
这种模块化的设计显著减少了令牌消耗和执行时间,因为它允许一次性生成完整的工具链,而不是在每次迭代中都重复调用LLM。
此外,由于规划数据不依赖于工具的输出,因此可以在不实际调用工具的情况下对模型进行微调,进一步简化了微调过程。
ReAct执行k轮,每轮都与LLM互动,所以Q、C、S的内容每次都传共计k轮;而k轮过程中总计执行了k-1轮T->A->0的循环,并且第j次循环的TAO内容在prompt中传递了k-j次(例如第一次的内容在后续循环中不断被当做历史数据传入除了第一次)
(2)提示词模板
6、LLMCompiler模式
(1)实现原理
简单来说就是通过
并行Function calling
来提高效率,比如用户提问Scott Derrickson和Ed Wood是否是同一个国家的国民?
planner 搜索Scott Derrickson国籍和搜索Ed Wood国籍同时进行,最后合并即可。
架构上它由三个组件组成:
。
Planner(规划器)
:stream a DAG of tasks,即将原始问题分解为一个DAG(Direct Acyclic Graph,有向无环图)的任务列表。
。
Task Fetching Unit(井行执行器)
:根据任务的依赖,调度任务并行执行。
。
Joiner(合并器)
:综合DAG执行结果反馈给用户,如果没达预期可以重新规划任务。
7、Basic Reflection 模式
Basic Reflection 可以类比于学生(Generator)写作业,老师(Reflector)来批改建议,学生根据批改建议来修改,如此反复。
Basic Reflection可以类比于左右互博。
左手是Generator,负责根据用户指令生成结果;右手是Reflector,来审查Generator的生成结果并给出建议。
在左右互搏的情况下,Generator生成的结果越来越好,Reflector的检查越来越严格,输出的结果也越来越有效。
(1)原理
下图是Basic Reflection的原理,非常简单。
。Generator接收来自用户的输入,输出initial response
。Reflector接收来自Generator的response,根据开发者设置的要求,给出Reflections,即评语、特征、建议
。Generator再根据Reflector给出的反馈进行修改和优化,输出下一轮response
。循环往复,直到循环次数
Basic Reflection的架构,非常适合于进行相对比较发散的内容生成类工作,比如文章写作、图片生成、代码生成等等。
Basic Reflection是一种非常高效的
反思类Al Agent设计模式
。
Basic Reflection 的思路非常朴素,使用成本较低。但是在实际应用中,Basic Reflection也面临着一些缺陷:对于一些比较复杂的问题,显然需要Generator具备更强大的推理能力。
Generator生成的结果可能会过于发散,和我们要求的结果相去甚远。
在一些复杂场景下,Generator和Reflector之间的循环次数不太好定义,如果次数太少,生成效果不够理想;如果次数太多,对token的消耗会很大。
我们有两种方法来优化Basic Refection,一种是边推理边执行的Self Discover模式,一种是增加了强化学习的Reflexion模式
8、Reflexion 模式
(1)原理
由于传统强化学习需要大量的训练样本和昂贵的模型微调,大模型很难快速有效地从错误经验中学习。最近涌现了ReAct,HuggingGPT等基于大模型的任务决策框架,它们利用In-context learning的方式快速地指导模型执行任务,避免了传统微调方式带来的计算成本和时间成本。
受前面工作的启发,提出了
Reflexion
框架,使用语言反馈信号来帮助agent从先前的失败经验中学习。具体地,Reflexion将传统梯度更新中的参数信号转变为添加在大模型上下文中的语言总结,使得agent在下一个episode中能参考上次执行失败的失败经验,从而提高agent的执行效果。这个过程和
人类反思
(reflexion)过程十分相似。
作者在决策(AlfWorld)、推理(HotQA)和代码生成(HumanEval)任务上进行了完整的对比实验,Reflexion在不同的任务上均取得了不错的效果,特别是在代码生成任务上成为了最新的SOTA
如图所示,Reflexion框架包含四个组成部分:
Actor:
Actor由LLM担任,主要工作是基于当前环境生成下一步的动作。
Evaluator:
Evlauator主要工作是衡量Actor生成结果的质量。就像强化学习中的Reward函数对Actor的执行结果进行打分。
Self-reflexion:
Self-reflexion一般由LLM担任,是Reflexion框架中最重要的部分。
它能结合离散的reward信号(如success/fall)、trajecory(轨迹,也就是推理上下文)等生成具体且详细语言反馈信号,这种反馈信号会储存在
Memory
中,启发下一次实验的Actor执行动作。
相比reward分数,这种语言反馈信号储存更丰富的信息,例如在代码生成任务中,Reward只会告诉你任务是失败还是成功,但是Self-reflexion会告诉你哪一步错了,错误的原因是什么等。
Memory:
分为短期记忆(short-term)和长期记忆(long-term)。
在一次实验中的上下文称为短期记忆,多次试验中Self-reflexion的结果称为长期记忆。
类比人类思考过程,在推理阶段Actor会不仅会利用短期记忆,还会结合长期记忆中存储的重要细节,这是Reflexion框架能取得效果的关键。
Reflexion是一个选代过程,Actor产生行动,Evaluator对Actor的行动做出评价,Self-Rflexion基于行动和评价形成反思,并将反思结果存储到长期记忆中,直到Actor执行的结果达到目标效果。
(2)和basic reflection的区别
1、reflexion会把之前的生成-tool调用结果-评价 的所有过程数据,当做下次生成的prompt
2、可以通过外部工具查询数据来作为评价 修正的依据
9、Language Agent Tree Search 模式
(1)原理
LATS 简单来说:是Tree search + ReAct + Plan&solve 的融合体
与传统的基于MCTS的推理决策框架相比,LATS的主要改进在于:
使用了蒙特卡罗树搜索算法,可以有效地探索可能的解决方案;
利用了预训练的语言模型来评估节点的价值,从而更好地指导搜索过程;
引入了自我反思机制,可以从失败的轨迹中学习并提高决策能力。
本文主要解决了自然语言任务中的推理和决策问题,具体来说,它可以用于以下场景:
推理问题:当输入一个问题时,可以通过LATS生成一系列中间想法(思考序列),最终得到答案。
决策问题:当需要在多个选项之间做出选择时,LATS可以根据不同的情况生成不同的决策路径,并从中选择最优解。
总之,LATS提供了一种灵活、高效且可扩展的方式来处理自然语言任务中的推理和决策问题。
先拆解下LATS主要内容,包含了节点选择、拓展、评分、执行、反向传播、反思。
选择节点后进行拓展子节点,每个子节点通过LLM评分。
任务不断执行直到达到设定的指定步教或获取最优质的结果,再将结果反向传播给各父节点进行更新,而输出内容经过LLM进行反思更新结果。
我们看到 LATS 中通过树搜索的方式进行 Reward(强化学习的思路),同时还会融入 Reflection,从而拿到最佳结果。
所以:
LATS=Tree search + ReAct + Plan&solve + Reflection + 强化学习
提示词模板方面和之前的reflection,plan&solve,ReAct差别不大,只是上下文中多了对树搜索结果的评估和返回结果。
架构上,由多轮的 Basic Reflection,多个Generator和 Reflector 组成。
主要有四个主要步骤:
1、选择:根据下面步骤(2)中的总奖励选择最佳的下一步行动。要么做出响应(如果找到解决方案或达到最大搜索深度),要么继续搜索。
2、扩展和执行:生成N(例子中为 5个Act节点)个潜在操作以并行执行并执行它们。
3、反思+评估:观察这些行动的结果并根据反思(以及可能的外部反馈)对决策进行评分。
4、反向传播:根据结果更新根轨迹的分数
总结一下,选择当前节点,行动、反思、评分,并将结果反向传播给父节点,同时根据节点教量是否达到上限以及结果情况决定是否继续向下延伸或输出结果
(2)框架对比
LATS通过融合计划、思考、行动、反思与记忆,使用蒙特卡罗树搜索算法,相较ReACt、TOT、CoT、Refection等框架具有显著优势,下图为LATS与其他框架的对比
10、Self-Discover 模式
SELF-DISCOVER旨在使模型能够自动发现用于解决复杂推理问题的任务内在推理结构。
这类问题对于传统的提示方法来说构成了挑战。
SELF-DISCOVER的核心是一个自我发现过程,LLMS在这一过程中选择多个原子推理模块(如批判性思维和逐步思考)并将它们组合成一个明确的推理结构,供LLMS在解码时遵循。
(1)优点
SELF-DISCOVER增强LLM处理复杂推理问题的能力,尤其是那些传统提示方法难以应对的问题。
基于理论的代理推理和MATH等具有挑战性的推理基准测试上的表现,相比链式推理(CoT)提高了32%。
SELF-DISCOVER在效率上也超过了推理密集型方法,如CoT-Self-Consistency,同时所需的推理计算量减少了10到40倍。
展示了自我发现的推理结构在不同的模型家族之间具有普适性,可以从PaLM 2-L迁移到GPT-4,以及从GPT-4迁移到Lama2。
(2)推理结构
论文是从人类如何利用先验知识和技能来设计推理程序来解决问题中汲取灵感。
当人类面对一个新问题时,
人类通常首先在内部寻找我们以前经验中的哪些知识和技能可能有助于解决它
。
然后,我们
将尝试将相关知识和技能应用于此任务
。
最后,我们
将连接多种个人技能和知识来解决问题
。
SELF-DISCOVER是一个的两阶段方法,旨在利用大型LLM来自动构建和应用解决特定问题的推理结构,再通过生成的推理结构解决复杂的问题
(3)第一阶段-发现推理结构
第一阶段包括三个操作如下:
选择(Select):
在这一操作下,模型需要从39个预定义的推理模块中选择几个关键模块,这些模块可以帮助解决特定的任务。
提供了所有可用推理模块的描述,例如”批判性思维”、“步骤分解”和”提出并验证”等。
同时也给出了一些带答案的任务示例。
模型需要根据这些信息选择最合适的推理模块组合。
适应(Adapt)
选择完关键推理模块后,模型需要调整和细化每个模块的描述,使其更好地适应待解决的具体任务。
在这个阶段,会显示之前SELECT阶段选择的模块描述,以及一些无答案的任务示例。
模型需要根据这些信息,改写每个推理模块的描述,便其更贴合实际任务。
实施(lmplement)
模型需要将调整后的推理模块组合成一个SON格式的分步推理计划。
为了展示如何实现这一计划,会给出一个人工编写的示例推理结构。
该结构展示了如何将推理模块按顺序实施,以逐步解决问题并得到正确答案。
模型的目标是生成一个类似的推理计划,但应用于当前的任务和调整后的推理模块描述。
六、Agent框架
1、安全提醒
请注意,Agent如果有文件系统访问权限,这在所有情况下都是不安全的,要在docker容器中运行。
2、Single Agent框架
(1)优点
1.简单性:设计、实现和管理相对简单,因为不需要考虑多个智能体之间的交互和协调问题。
2.专业性:可以针对特定任务进行优化,专注于执行单一任务,效率较高。
3.易于开发:由于系统组件较少,开发和部署速度更快。
4.成本效益:相比多智能体系统,单智能体系统通常需要较少的计算资源。
(2)缺点
1.灵活性有限:对于需要多个智能体协作才能完成的复杂任务,单智能体系统可能无法提供最佳解决方案。
2.扩展件差:增加新功能或适应新环境可能需要重构整个系统,一旦面临极其错综复杂、计算量密集的任务,Single·Agent 无疑会遭遇算力瓶颈,无法高效完成处理,性能将大打折扣。
3.鲁棒性低:系统对故障的容忍度较低,单点故障可能导致整个系统失效
(3)常见热门项目
BabyAGI
github项目:
https://github.com/yoheinakajima/babyagi
babyAGI决策流程:1)根据需求分解任务;2)对任务排列优先级;3)执行任务并整合结果;
亮点:作为早期agent的实践,babyagi框架简单实用,里面的任务优先级排序模块是一个比较独特的feature,后续的agent里大多看不到这个feature(已经不维护了)
AutoGPT
github项目:
https://github.com/Significant-Gravitas/AutoGPT
文档:
https://docs.agpt.co/
AutoGPT 定位类似个人助理,帮助用户完成指定的任务,如调研某个课题。AutoGPT比较强调对
外部工具
的使用,如搜索引擎、页面浏览等。
同样,作为早期agent,autoGPT麻雀虽小五脏俱全,虽然也有很多缺点,比如无法控制迭代次数、工具有限,但是后续的模仿者非常多,基于此演变出了非常多的框架
HuggingGPT
github项目:
https://github.com/microsoft/JARVIS
由浙大&微软联合发布的一个大模型协作系统。研究者提出了用ChatGPT作为任务规划器,连接HuggingFace社区中的各种AI模型,完成多模态复杂任务。整个过程,只需要做的是:
用自然语言将你的需求输出
。
HuggingGPT 工作原理说明
通过以下四个阶段来完成工作流程:
1.任务规划:使用ChatGPT分析用户请求,将其分解为多个子任务,并规划任务顺序和依赖关系。
2.模型选择:根据HuggingFace中可用的功能描述选择模型。
3.任务执行:使用所选的AI模型执行每个子任务。
4.响应生成:根据AI模型执行结果进行总结和输出.
HuggingGPT的工作原理可以概括为以下几点:
。语言作为接口:HuggingGPT将语言作为连接LLM和AI模型的通用接口,通过将模型描述结合到提示中,使LLM能够管理AI模型,如计划、调度和合作。
。任务规划:LLM首先解析用户请求,将其分解为一系列结构化任务,并确定这些任务的依赖关系和执行顺序。
。模型选择:LLM根据HuggingFace中的模型描述,将解析后的任务分配给专家模型。
。任务执行:每个专家模型在推理端点上执行所分配的子任务,并将执行信息和推理结果记录到LLM。
。响应生成:最后,LLM总结执行过程日志和推理结果,并将摘要返回给用户。
HuggingGPT的亮点
:HuggingGPT与AutoGPT的不同之处在于,它可以调用HuggingFace上不同的模型来完成更复杂的任务,从而提高了每个任务的精确度和准确率。然而,总体成本并没有降低太多。
GPT-Engineer
github项目:
https://github.com/AntonOsika/gpt-engineer
基于langchain开发,单一的工程师agent,解决编码场景的问题,目的是创建一个完整的代码仓库,在需要时要求用户额外输入补充信息。
亮点:code-copilot的自动化升级版
AppAgent
github项目:
https://github.com/X-PLUG/MobileAgent
基于ground-dino以及gpt view模型做多模态处理的Agent。
亮点:基于视觉/多模态appagent,os级别的agent,可以完成系统级别的操作,直接操控多个app。
由于需要系统级权限、只支持了安卓。
OS-Copilot
github项目:
https://github.com/OS-Copilot/OS-Copilot
OS级别的Agent,FRIDAY能够从图片、视频或者文本中学习,并且能够执行一系列的计算机任务,比如在Excel中绘图,或者创建一个网站。
最重要的是,FRIDAY能够通过做任务来学习新的技能,就像人类一样,通过不断的尝试和练习变得更擅长。
亮点:自我学习改进,学习如何更有效地使用软件应用、执行特定任务的最佳实践等。
3、Multi-Agent框架
将多个Agent,按照一定的工作流进行编排,每个Agent负责不同的任务,即组成了
多智能体架构(Multi-Agent)
,这非常类似于我们实际中的工作流程或组织结构:拥有不同能力的人,负责不同的任务,每个工序执行的结果给到下一个工序,最终得到最后的任务成果。
举一个实际的例子。
现在我要设计一个智慧城市的数据分析工作流,由于数据来源比较复杂,并且要同时考虑模型的经济和分析地高效,可以设计三个不同的 Agent:
1、Agent-1 代理负责教据收集,从各种教据源(如气象部门、交通部门、环保部门的教据共享接口),收集原始教据,并进行去重、缺失值填补、格式转换等数据预处理工作。为了经济,使用 GPT-3.5 模型。
2、Agent-2 拿到 Agent-1 的结果,然后进行数据加载和深度数据分析,使用本地微调过的 Mistral 7B 模型。
3、Agent-3 则负责最终的教据可视化,将上一步的教据分析结果展示为可视化图表,并提供用户界面,可以选择允许用户与可视化结果进行交互,如筛选、放大、导出等。
这就是一个 multi agent 的例子,它允许不同角色的 Agent 完成任务,其中某个 Agent 擅长检索数据,余下的 Agent 则擅长数据分析或数据可视化。
优点:
1.协作性:智能体之间可以相互通信和协作,共同完成复杂任务。
2.灵活性和适应性:能够适应多变的环境和任务需求,智能体可以自主调整行为和策略。
3.可扩展性:通过增加更多的智能体来扩展系统的功能和处理能力。
4.鲁棒性和容错性:系统中的智能体可以互为备份,提高了系统的可靠性和容错性
5.分布式处理:可以分散处理任务,提高效率和吞吐量。
6.专业化:每个智能体可以拥有特定领域的专业知识,提高问题解决能力。
缺点:
1.复杂性高:需要设计和实现智能体之间的通信、协调和协作机制,增加了系统的复杂性
2.开发难度大:相比单智能体系统,多智能体系统需要更多的开发工作和专业知识
3.成本较高:可能需要更多的计算资源和开发投入,简单的问题single Agent也能解决
单智能体=大语言模型(LLM)+观察(obs)+思考(thought)+行动(act)+记忆(mem)
多智能体=智能体+环境+SOP+评审+通信+成本
(1)斯坦福虚拟小镇
github顶目:
https://github.com/joonspk-research/generative_agents
斯坦福虚拟小镇(Smallvile)是一个由斯坦福大学和谷歌的研究人员创建的虚拟社区项目,旨在模拟人类行为。
这个项目通过使用大型语言模型(LLM),特别是ChatGPT API,来实现25个AI智能体的自然语言交互和社会行为模拟。
这些AI智能体在虚拟小镇中生活,他们有工作,会八卦,能组织社交活动,结交新朋友,甚至举办派对,每个“小镇居民"都有独特的个性和背景故事。
Smallville虚拟小镇包含了多种公共场景,如咖啡馆、酒吧、公园、学校、宿舍、房屋和商店,智能体可以在这些场景中自由活动,进入或离开场所,甚至与其他智能体打招呼和互动。
这些智能体的行为模仿了人类的日常活动,例如如果看到早餐着火了,会走过去关掉炉子;如果看到浴室有人,会在外面等待;如果遇到一个想交谈的个体,会停下来聊天。
虚拟小镇作为早期的multi-agent项目,很多设计也影响到了其他multi-agent框架,里面的
反思和记忆检索
feature比较有意思,模拟人类的思考方式。
代理(Agents)感知他们的环境,当前代理所有的感知(完整的经历记录)都被保存在一个名为“记忆流”(memory stream)中。
基于代理的感知,系统检索相关的记忆,然后使用这些检索到的行为来决定下一个行为。
这些检索到的记忆也被用来形成长期计划,并创造出更高级的反思,这些都被输入到记忆流中以供未来使用。
(2)TaskWeaver
github项目:
https://github.com/microsoft/TaskWeaver
TaskWeaver,面向数据分析任务,通过编码片段解释用户请求,并以函数的形式有效协调各种插件来执行数据分析任务。
TaskWeaver不仅仅是一个工具,更是一个复杂的系统,能够解释命令,将它们转换为代码,并精确地执行任务。
TaskWeaver的工作流程涉及几个关键组件和过程,以下是工作流程的概览。
它由三个关键组件组成:
规划器(Planner)、代码生成器(CG)和代码执行器(CE)
。
代码生成器和代码执行器由代码解释器(CI)组成
(3)MetaGPT
github项目:
https://github.com/geekan/MetaGPT
metaGPT是国内开源的一个Multi-Agent框架,目前整体社区活跃度较高和也不断有新feature出来,中文文档支持的很好。
MetaGPT输入
一句话的老板需求,输出用户故事/竞品分析/需求/数据结构/APIS/文件等
。
MetaGPT以软件公司方式组成,内部包括
产品经理/架构师/项目经理/工程师
,它提供了一个软件公司的全过程与精心调配的SOP。
Role将从Environment中 _observe Message。
如果有一个Role _watch 的特定 Action 引起的 Message,那么这是一个有效的观察,触发Role的后续思考和操作。
在_think 中,Role将选择其能力范围内的一个 Action 并将其设置为要做的事情。
在_act中,Role执行要做的事情,即运行 Action并获取输出。将输出封装在 Message 中,最终 publish_message到 Environment,完成了一个完整的智能体运行。
对话模式:
每个agentrole维护一个自己的消息队列,并且按照自身的设定消费个性化消费里面的数据,并且再完成一个act之后会给全局环境发送消息,供所有agent消费
(4)微软UFO
github项目:
https://github.com/microsoft/UFO
UFO是面向Windows系统的Agent,结合自然语言和视觉操作Windows GUI
UFO(UI-Focused Agent)的工作原理基于先进的视觉语言模型技术,特别是GPT-Vision,以及一个独特的双代理框架,使其能够理解和执行Windows操作系统中的图形用户界面(GUI)任务。
以下是UFO工作原理的详细解释:
1、双代理框架 双代理架构:
UFO由两个主要代理组成,AppAgent和ActAgent,分别负责应用程序的选择与切换,以及在这些应用程序内执行具体动作。
应用程序选择代理(AppAgent):负责决定为了完成用户请求需要启动或切换到哪个应用程序,它通过分析用户的自然语言指令和当前桌面的屏幕截图来做出选择。一旦确定了最适合的应用程序,AppAgent会制定一个全局计划来指导任务的执行。
动作选择代理(ActAgent):一旦选择了应用程序,ActAgent就会在该应用程序中执行具体的操作,如点击按钮、输入文本等。ActAgent利用应用程序的屏幕截图和控件信息来决定下一步最合适的操作,并通过控制交互模块将这些操作转化为对应用程序控件的实际动作。
2、控制交互模块
UFO的控制交互模块是将代理识别的动作转换为应用程序中实际执行的关键组成部分。
这个模块使UFO能够直接与应用程序的GUI元素进行交互,执行如点击、拖动、文本输入等操作,而无需人工干预。
3、多模态输入处理
UFO能够处理多种类型的输入,包括文本(用户的自然语言指令)和图像(应用程序的屏幕截图)。
这使UFO能够理解当前GUI的状态、可用控件和它们的属性,从而做出准确的操作决策。
4、用户请求解析
当接收到用户的自然语言指令时,UFO首先解析这些指令,以确定用户的意图和所需完成的任务。
然后,它将这个任务分解成一系列子任务或操作步骤,这些步骤被AppAgent和ActAgent按顺序执行。
5、应用程序间的无缝切换
如果完成用户请求需要多个应用程序的操作,UFO能够在这些应用程序之间无缝切换
它通过AppAgent来决定何时以及如何切换应用程序,并通过ActAgent在每个应用程序中执行具体的操作。
6、自然语言命令到GUI操作的映射
UFO的核心功能之一是将用户的自然语言命令映射到具体的GUI操作上。
这一过程涉及到理解命令的意图,识别相关的GUI元素,以及生成和执行操作这些元素的动作。
通过这种方式,UFO可以自动完成从文档编辑和信息提取到电子邮件撰写和发送等一系列复杂的任务,大大提高用户在Windows操作系统中工作的效率和便捷性。
(5)Camel
github项目:
https://github.com/camel-ai/camel
早期Multi-Agent项目,实现agent间的一对一对话,文档较少,除了git和一个站点外没有找到太多有用信息
(6)现状
Multi-Agent并不是Agent框架的
终态
,Muliti-Agent框架是当前有限的LLM能力背景下的产物,更多还是为了解决当前LLM的能力缺陷,通过LLM多次选代、弥补些显而易见的错误,不同框架间仍然存在着
极高的学习和开发成本
。
随着LLM能力的提升,未来的Agent框架肯定会朝着更加的
简单、易用
的方向发展。
游戏场景(npc对话、游戏素材生产)、内容生产、私域助理、OS级别智能体、部分工作的提效。
在利用LLM多智体解决各种任务方面取得了有希望的结果,如软件开发、多机器人系统、社会模拟、策略模拟和游戏模拟。
由于该领域跨学科研究的性质,它吸引了各种各样的研究人员,从AI专家扩展到社会科学、心理学和政策研究专家。研究论文的数量正在迅速增加。
(7)ChatChain模式
本质上通过相互
聊天
能完善用户需求,能详细生成推理步骤,能提升模型规划能力,正确拆解任务。
crewai和AutoGen等项目采用ChatChain模式的原因在于,这种模式特别适合于构建能够协同工作的多代理系统,通过代理间的对话和协作来解决问题。
以下是ChatChain模式的相关信息:
多代理协作
:ChatChain模式允许创建多个代理,这些代理可以相互对话,共同完成任务,这种模式非常适合需要多个步骤或多个参与者协同工作的场景。
任务分解与分配
:在ChatChain中,复杂的任务可以被分解成多个子任务,并由不同的代理负责处理,这种任务分解和分配的方式提高了处理复杂问题的效率。
灵活性与可扩展性
:ChatChain模式支持多种会话模式,如双代理聊天、顺序聊天、群聊等,使得系统可以根据不同的需求灵活调整代理间的交互方式。