planningagent 的核心是负责解决用户所提出的任务。这个任务由目标和约束条件定义。例如一个任务是安排一次从上海到北京为期两周的旅行预算为 5000。 目标是为期两周的旅行约束条件是预算。复杂的任务需要规划。规划过程的输出是一个计划它是一份概述完成任务所需步骤的路线图。有效的规划通常要求模型理解任务考虑实现该任务的不同选项并选择最有希望的一个。planning概述给定一个任务有很多种可能的解决方法但不是所有方法都能成功。在正确的方案中有些比其他方案更高效。考虑这个查询“有多少没有收入的公司至少融了 10 个亿”以及两个可能的解决方案先找出所有没有收入的公司然后按照融资金额筛选。先找出所有至少融资了 10 个亿的公司然后按照收入筛选。第二种方案效率更高。没有收入的公司数量远远多于筹集了 10 个亿的公司数量。如果只有这两个选项一个智能 agent 应该选择方案 2。你可以将规划和执行放在同一个prompt中。例如你给模型一个prompt要求它逐步思考例如使用思维链提示然后在同一个提示中执行这些步骤。但如果模型给出了一个 1000 步的计划结果连目标都实现不了怎么办在没有监督的情况下一个 agent 可以跑这些步骤几个小时浪费时间和 API 调用费用直到你发现它根本毫无进展。为了避免这种徒劳的执行规划应该与执行解耦。你先要求 agent 生成一个计划只有在验证该计划之后才执行它。计划可以用一些启发式方法验证。例如一个简单的启发式方法是排除包含无效操作的计划。如果生成的计划需要 Google 搜索而 agent 没有访问 Google 搜索的权限那么这个计划就是无效的。另一个简单的启发式方法是排除所有超过 X 步的计划。计划也可以使用 AI 评判来验证。你可以让一个模型来评估计划是否合理或者如何改进它。如果生成的计划被评估为不佳你可以要求规划器生成另一个计划。如果生成的计划良好则执行它。如果计划中涉及到外部工具就会调用函数调用。执行该计划的输出结果也需要再次评估。请注意生成的计划不必是整个任务的端到端计划它可以只是针对某个子任务的小计划。整个过程如下图所示。整个系统现在有三个组件一个用于生成计划一个用于验证计划另一个用于执行计划。如果你把每个组件都看作是一个 agent那么这就构成了一个多 agent 系统。由于大多数 agent 工作流程都足够复杂需要多个组件因此大多数 agent 都是多 agent 的。为了加速这个过程你可以并行生成多个计划而不是按顺序生成然后让评估器选择最有希望的一个。这是一种在延迟和成本之间的权衡因为同时生成多个计划会带来额外的成本。规划需要理解任务背后的意图用户想通过这个查询做什么意图分类器通常用来帮助 agent 规划。比如说将复杂任务分解为更简单的子任务意图分类可以使用另一个提示或一个为这个任务训练的分类模型来完成。意图分类机制可以看作是多 agent 系统中的另一个 agent。了解意图可以帮助 agent 选择合适的工具。例如对于客户支持如果查询是关于查工资的agent 可能需要访问一个工具来检索用户最近的工资条信息。但如果查询是关于如何重置密码的agent 可能需要访问文档检索功能。有些查询可能超出了 agent 的能力范围。意图分类器应该能够将请求分类为“不相关”以便 agent 可以礼貌地拒绝这些请求而不是浪费计算资源去尝试不可能的解决方案。到目前为止我们假设 agent 自动化了所有三个阶段生成计划、验证计划和执行计划。实际上人类可以在任何阶段参与进来协助这个过程并降低风险。人类专家可以提供计划、验证计划或执行部分计划。例如对于 agent 难以生成完整计划的复杂任务人类专家可以提供一个高层次的计划然后让 agent 在此基础上进行扩展。 如果计划涉及到有风险的操作例如更新数据库或合并代码更改系统可以在执行前请求明确的人工批准或者将这些操作交给人工执行。为了实现这一点你需要清楚地定义 agent 在每个操作中可以拥有的自动化程度。总而言之解决一个任务通常涉及以下步骤。反思对于 agent 来说不是强制性的但它可以显著提高 agent 的性能计划生成提出完成该任务的计划。一个计划是一系列可管理的操作因此这个过程也称为任务分解。反思和错误纠正评估生成的计划。如果这是一个不好的计划则生成一个新计划。执行采取生成的计划中概述的操作。这通常涉及调用特定的函数。反思和错误纠正在收到操作结果后评估这些结果并确定是否已完成目标。识别并纠正错误。如果目标未完成则生成新计划。当你要求模型“逐步思考”时你实际上是在要求它分解任务。当你要求模型“验证你的答案是否正确”时你实际上是在要求它进行反思。大模型作为规划器一个常见的问题是大模型在规划方面的表现如何。许多研究人员认为大模型至少是那些建立在自回归语言模型之上的模型无法进行规划。Meta 的首席 AI 科学家 Yann LeCun 明确表示自回归 LLM 无法规划。虽然有很多传闻证据表明 LLM 是做规划非常的糟糕但尚不清楚这是否是因为我们不知道如何正确使用 LLM还是因为 LLM 本质上就不能规划。规划的核心是一个搜索问题。你在通向目标的不同路径中搜索预测每条路径的结果奖励并选择结果最有希望的路径。有时你可能会确定根本没有路径可以到达目标。搜索通常需要回溯。例如假设你处于一个步骤其中有两个可能的动作A 和 B。在执行动作 A 后你进入了一个不理想的状态因此你需要回溯到之前的状态以执行动作 B。有些人认为自回归模型只能生成前向动作而不能回溯生成替代动作。因此他们得出结论自回归模型无法规划。但这不一定是真的。在执行完动作 A 的路径后如果模型判断这条路径不合理它可以修改路径改为使用动作 B从而实现回溯。模型也可以随时重新开始选择另一条路径。LLM 也可能因为没有获得规划所需的工具而成为糟糕的规划者。要进行规划不仅需要知道可用的操作还需要知道每个操作的潜在结果。举一个简单的例子假设你想爬上一座山。你可能的动作是向右转、向左转、掉头或径直向前走。但是如果向右转会导致你从悬崖上掉下去你可能就不会考虑这个动作。用技术术语来说一个动作会将你从一个状态带到另一个状态你需要知道结果状态才能决定是否执行这个动作。这意味着仅仅提示模型生成一系列操作例如思维链是不够的。“Reasoning with Language Model is Planning with World Model” 这篇论文认为LLM 因为包含了大量关于世界的信息因此能够预测每个动作的结果。这个 LLM 可以将这种结果预测纳入其中从而生成连贯的计划。即使 AI 不能规划它仍然可以是规划器的一部分。有可能使用搜索工具和状态跟踪系统来增强 LLM以帮助它进行规划。关于RL AgentAgent 是 RL 中的核心概念。根据维基百科的定义RL 是一个“关注智能 agent 如何在动态环境中采取行动以最大化累积奖励”的领域。RL agent 和 FM agent 在许多方面都很相似。它们的共同特点是它们的环境和可能的操作。主要区别在于它们的规划器的工作方式。在 RL agent 中规划器由 RL 算法训练。训练这个 RL 规划器可能需要大量的时间和资源。 在 FM agent 中模型本身就是规划器。这个模型可以通过提示或微调来提高其规划能力而且通常需要更少的时间和资源。但是没有什么能阻止 FM agent 采用 RL 算法来提高其性能。从长远来看FM agent 和 RL agent 将会融合。planning生成将模型变成planning生成器的最简单方法是使用提示工程。假设你想创建一个 agent 来帮助客户了解 家用显卡 的产品。你为该 agent 提供对三个外部工具的访问权限按价格检索产品、检索热门产品和检索产品信息。下面是一个用于计划生成的提示示例。此提示仅用于说明目的。实际的生产提示可能会更复杂。system prompt提出一个解决任务的计划。你可以使用以下5个操作*get_today_date()*fetch_top_products(start_date,end_date,num_products)*fetch_product_info(product_name)*generate_query(task_history,tool_output)*generate_response(query) 计划必须是一系列有效的操作。**示例****任务**“告诉我关于5090的信息”**计划**[fetch_product_info,generate_query,generate_response]**任务**“上周最畅销的产品是什么”**计划**[fetch_top_products,generate_query,generate_response]**任务**{用户输入}**计划**关于这个例子有两点需要注意这里使用的计划格式——一个函数列表其参数由 agent 推断——只是构建 agent 控制流的多种方式之一。generate_query函数接收任务的当前历史记录和最近的工具输出以生成要输入到响应生成器的查询。每个步骤的工具输出都会添加到任务的历史记录中。如果用户输入“上周最畅销产品的价格是多少”则生成的计划可能如下所示get_time()fetch_top_products()fetch_product_info()generate_query()generate_response()你可能会想“每个函数需要的参数是什么” 确切的参数很难提前预测因为它们通常是从之前的工具输出中提取的。如果第一步get_time()输出“2030-09-13”那么 agent 可以推断出下一步的参数应该按如下方式调用retrieve_top_products(start_date2030-09-07,end_date2030-09-13,num_products1)通常没有足够的信息来确定函数的精确参数值。例如如果用户问“最畅销产品的平均价格是多少”那么以下问题的答案就不清楚用户想看多少最畅销的产品用户想要的是上周、上个月还是所有时间的最畅销产品这意味着模型经常需要进行猜测而猜测可能会出错。由于操作序列和相关的参数都是由 AI 模型生成的它们可能会产生幻觉。幻觉会导致模型调用无效的函数或者调用有效的函数但参数错误。通常可以使用提高模型整体性能的技术来提高模型的规划能力。让 agent 更好地规划的提示编写包含更多示例的更好的系统提示。提供对工具及其参数的更清晰的描述以便模型更好地理解它们。重写函数本身使其更简单例如将一个复杂的函数重构为两个更简单的函数。使用更强大的模型。一般来说更强大的模型更擅长规划。为规划生成微调模型。函数调用现在的模型公司基本都提供了函数调用的能力从而有效地将它们的模型变成了 agent。工具就是一个函数。因此调用工具通常称为函数调用。不同的模型 API 的工作方式有所不同但一般来说函数调用按以下步骤工作创建工具清单。声明你希望模型使用的所有工具。每个工具都由其执行入口点例如函数名、参数和文档例如函数的作用以及需要哪些参数描述。指定 agent 可以为特定查询使用的工具。由于不同的查询可能需要不同的工具因此许多 API 允许你指定每个查询要使用的已声明工具列表。有些允许你通过以下设置进一步控制工具的使用required模型必须使用至少一个工具。none模型不应使用任何工具。auto模型决定使用哪些工具。给定一个查询agent 会自动生成要使用的工具及其参数。某些函数调用 API 将确保仅生成有效的函数尽管它们无法保证参数值的正确性。规划粒度规划是概述完成任务所需步骤的路线图。路线图可以有不同的粒度级别。为一年做计划时按季度计划比按月计划更高级而按月计划又比按周计划更高级。在规划和执行之间存在一种权衡。详细的计划更难生成但更容易执行。更高级的计划更容易生成但更难执行。一种规避这种权衡的方法是分层规划。首先使用规划器生成一个高层次的计划例如按季度计划。然后对于每个季度使用相同或不同的规划器生成一个按月计划。到目前为止所有生成的计划示例都使用确切的函数名称这非常细粒度。这种方法的一个问题是 agent 的工具清单会随着时间推移而改变。例如获取当前日期的函数get_time()可以重命名为get_current_time()。当工具发生变化时你需要更新你的提示和所有示例。使用确切的函数名称也使得在具有不同工具 API 的不同用例中重用规划器变得更加困难。如果你之前微调过一个模型以基于旧的工具清单生成计划则你需要使用新的工具清单再次微调该模型。为了避免这个问题计划也可以使用更自然的语言生成这种语言比特定领域的函数名称更高级。例如给定查询“上周最畅销产品的价格是多少”可以指示 agent 输出如下所示的计划获取当前日期 检索上周最畅销的产品 检索产品信息 生成查询 生成响应使用更自然的语言有助于你的计划生成器更好地应对工具 API 的变化。如果你的模型主要是在自然语言上训练的它可能会更擅长理解和生成自然语言的计划并且不太可能出现幻觉。这种方法的缺点是你需要一个翻译器来将每个自然语言操作转换为可执行的命令。Chameleon中将这个翻译器称为程序生成器。但是翻译是一项比规划简单得多的任务并且可以通过幻觉风险较低的弱模型来完成。复杂规划到目前为止的规划示例都是顺序的计划中的下一个操作总是在前一个操作完成后执行。可以执行操作的顺序称为控制流。顺序形式只是控制流的一种类型。其他类型的控制流包括并行、if 语句和 for 循环。以下列表概述了每种控制流包括用于比较的顺序顺序在任务 A 完成后执行任务 B可能是因为任务 B 依赖于任务 A。例如SQL 查询只能在从自然语言输入翻译后执行。并行同时执行任务 A 和 B。例如给定查询“查找 100 元以下的畅销产品”agent 可能会先检索前 100 名畅销产品然后为每个产品检索其价格。If 语句根据上一步的输出执行任务 B 或任务 C。例如agent 首先检查 宁德时代 的财务报告。根据此报告它可以决定出售或购买宁德时代股票。Anthropic 的帖子将此模式称为“路由”。For 循环重复执行任务 A直到满足特定条件。例如持续生成随机数直到出现质数。Agent 控制流在传统的软件工程中控制流的条件是精确的。对于 AI 驱动的 agentAI 模型决定控制流。具有非顺序控制流的计划更难生成和转换为可执行的命令。在评估 agent 框架时请检查它支持哪些控制流。例如如果系统需要浏览十个网站它可以同时进行吗并行执行可以显著减少用户感知的延迟。反思和错误纠正即使是最好的计划也需要不断评估和调整以最大限度地提高其成功的机会。虽然反思对于 agent 的运行并非绝对必要但对于 agent 的成功至关重要。在任务过程中有很多地方可以使用反思在收到用户查询后评估请求是否可行。在初始计划生成后评估该计划是否合理。在每个执行步骤之后评估它是否在正确的轨道上。在整个计划执行完毕后确定任务是否已完成。反思和错误纠正是相辅相成的两种不同机制。反思产生有助于发现需要纠正的错误的见解。反思可以使用具有自我批评提示的同一个 agent 来完成。它也可以使用单独的组件来完成例如专用评分器一个为每个结果输出具体分数的模型。ReAct 首先提出交错推理和行动已成为 agent 的常见模式。在每一步都会要求 agent 解释其想法规划、采取行动然后分析观察结果反思直到 agent 认为任务完成。通常会使用示例提示 agent 以以下格式生成输出想法1:...行动1:...观察1:......[继续直到反思确定任务已完成]...想法 N:...行动 N:完成[对查询的响应]你可以在多 agent 设置中实现反思一个 agent 规划并采取行动另一个 agent 在每个步骤或多个步骤后评估结果。如果 agent 的响应未能完成任务你可以提示 agent 反思失败的原因以及如何改进。基于此建议agent 生成新计划。这使 agent 可以从错误中学习。例如给定一个代码生成任务评估器可能会评估生成的代码在 ⅓ 的测试用例中失败。然后agent 反思失败的原因是它没有考虑到所有数字都是负数的数组。然后执行器生成新代码其中考虑了所有负数数组。这是 Reflexion 采用的方法。在此框架中反思分为两个模块一个评估结果的评估器和一个分析哪里出错的自我反思模块。下图是Reflexion agent 的工作示例。作者使用术语“trajectory”来指代规划。在每一步之后经过评估和自我反思agent 都会提出新的trajectory。与规划生成相比反思相对容易实现并且可以带来令人惊讶的性能提升。这种方法的缺点是延迟和成本。想法、观察有时还有行动可能需要生成大量的 token这会增加成本和用户感知的延迟特别是对于有很多中间步骤的任务。为了促使他们的 agent 遵循格式ReAct 和 Reflexion 的作者都在他们的提示中使用了大量的示例。这会增加计算输入 token 的成本并减少可用于其他信息的上下文空间。工具选择由于工具通常在任务的成功中起着至关重要的作用因此工具选择需要仔细考虑。为你 agent 提供的工具取决于环境和任务但也取决于驱动 agent 的 AI 模型。没有关于如何选择最佳工具集的万无一失的指南。在 agent 文献中你会发现各种各样的工具清单。例如Toolformer (Schick et al., 2023) 微调 GPT-J 以学习 5 个工具。Chameleon (Lu et al., 2023) 使用 13 个工具。Gorilla (Patil et al., 2023) 尝试提示 agent 在 1,645 个 API 中选择正确的 API 调用。更多的工具可以为 agent 提供更多的功能。但是工具越多就越难有效地使用它们。这类似于人类难以掌握大量工具的情况。添加工具也意味着增加工具描述这可能不适合模型的上下文。与构建 AI 应用程序时的许多其他决策一样工具选择需要实验和分析。以下是一些可以帮助你做出决定的事情比较 agent 在不同工具集下的表现。进行消融研究以查看如果从其清单中删除某个工具agent 的性能会下降多少。如果可以删除某个工具而不会降低性能则将其删除。查找 agent 经常出错的工具。如果事实证明某个工具对于 agent 来说太难使用例如大量的提示甚至微调都无法让模型学会使用它请更改该工具。绘制工具调用的分布图以查看哪些工具使用最多哪些工具使用最少。图 6-14 显示了 GPT-4 和 ChatGPT 在 Chameleon (Lu et al., 2023) 中的工具使用模式差异。不同模型具有不同的工具偏好Chameleon 的实验也证明了两点不同的任务需要不同的工具。ScienceQA科学问题解答任务比 TabMWP表格数学问题求解任务更依赖于知识检索工具。不同的模型具有不同的工具偏好。例如GPT-4 似乎选择的工具集比 ChatGPT 更广泛。ChatGPT 似乎更喜欢图像字幕而 GPT-4 似乎更喜欢知识检索。在评估 agent 框架时评估它支持哪些规划器和工具。不同的框架可能专注于不同类别的工具。例如AutoGPT 专注于社交媒体 APIReddit、X 和 Wikipedia而 Composio 专注于企业 APIGoogle Apps、GitHub 和 Slack。由于你的需求可能会随着时间的推移而变化因此请评估扩展你的 agent 以包含新工具的难易程度。作为人类我们变得更高效不仅是因为使用给定的工具还因为从更简单的工具中逐步创建更强大的工具。AI 可以从其初始工具创建新工具吗Chameleon 提出了工具转换的研究在工具 X 之后agent 调用工具 Y 的可能性有多大下图展了一个工具转换的示例。如果两个工具经常一起使用则可以将它们组合成一个更大的工具。如果 agent 意识到此信息则 agent 本身可以组合初始工具以不断构建更复杂的工具。Vogager 提出了一个技能管理器以跟踪 agent 获取的用于以后重用的新技能工具。每个技能都是一个编码程序。当技能管理器确定新创建的技能有用时例如因为它已成功帮助 agent 完成任务它会将此技能添加到技能库在概念上类似于工具清单。以后可以检索此技能以用于其他任务。最后的最后感谢你们的阅读和喜欢作为一位在一线互联网行业奋斗多年的老兵我深知在这个瞬息万变的技术领域中持续学习和进步的重要性。为了帮助更多热爱技术、渴望成长的朋友我特别整理了一份涵盖大模型领域的宝贵资料集。这些资料不仅是我多年积累的心血结晶也是我在行业一线实战经验的总结。这些学习资料不仅深入浅出而且非常实用让大家系统而高效地掌握AI大模型的各个知识点。如果你愿意花时间沉下心来学习相信它们一定能为你提供实质性的帮助。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】大模型知识脑图为了成为更好的 AI大模型 开发者这里为大家提供了总的路线图。它的用处就在于你可以按照上面的知识点去找对应的学习资源保证自己学得较为全面。经典书籍阅读阅读AI大模型经典书籍可以帮助读者提高技术水平开拓视野掌握核心技术提高解决问题的能力同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说阅读经典书籍是非常有必要的。实战案例光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。面试资料我们学习AI大模型必然是想找到高薪的工作下面这些面试题都是总结当前最新、最热、最高频的面试题并且每道题都有详细的答案面试前刷完这套面试题资料小小offer不在话下640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
planningagent 的核心是负责解决用户所提出的任务。这个任务由目标和约束条件定义。例如一个任务是安排一次从上海到北京为期两周的旅行预算为 5000。 目标是为期两周的旅行约束条件是预算。复杂的任务需要规划。规划过程的输出是一个计划它是一份概述完成任务所需步骤的路线图。有效的规划通常要求模型理解任务考虑实现该任务的不同选项并选择最有希望的一个。planning概述给定一个任务有很多种可能的解决方法但不是所有方法都能成功。在正确的方案中有些比其他方案更高效。考虑这个查询“有多少没有收入的公司至少融了 10 个亿”以及两个可能的解决方案先找出所有没有收入的公司然后按照融资金额筛选。先找出所有至少融资了 10 个亿的公司然后按照收入筛选。第二种方案效率更高。没有收入的公司数量远远多于筹集了 10 个亿的公司数量。如果只有这两个选项一个智能 agent 应该选择方案 2。你可以将规划和执行放在同一个prompt中。例如你给模型一个prompt要求它逐步思考例如使用思维链提示然后在同一个提示中执行这些步骤。但如果模型给出了一个 1000 步的计划结果连目标都实现不了怎么办在没有监督的情况下一个 agent 可以跑这些步骤几个小时浪费时间和 API 调用费用直到你发现它根本毫无进展。为了避免这种徒劳的执行规划应该与执行解耦。你先要求 agent 生成一个计划只有在验证该计划之后才执行它。计划可以用一些启发式方法验证。例如一个简单的启发式方法是排除包含无效操作的计划。如果生成的计划需要 Google 搜索而 agent 没有访问 Google 搜索的权限那么这个计划就是无效的。另一个简单的启发式方法是排除所有超过 X 步的计划。计划也可以使用 AI 评判来验证。你可以让一个模型来评估计划是否合理或者如何改进它。如果生成的计划被评估为不佳你可以要求规划器生成另一个计划。如果生成的计划良好则执行它。如果计划中涉及到外部工具就会调用函数调用。执行该计划的输出结果也需要再次评估。请注意生成的计划不必是整个任务的端到端计划它可以只是针对某个子任务的小计划。整个过程如下图所示。整个系统现在有三个组件一个用于生成计划一个用于验证计划另一个用于执行计划。如果你把每个组件都看作是一个 agent那么这就构成了一个多 agent 系统。由于大多数 agent 工作流程都足够复杂需要多个组件因此大多数 agent 都是多 agent 的。为了加速这个过程你可以并行生成多个计划而不是按顺序生成然后让评估器选择最有希望的一个。这是一种在延迟和成本之间的权衡因为同时生成多个计划会带来额外的成本。规划需要理解任务背后的意图用户想通过这个查询做什么意图分类器通常用来帮助 agent 规划。比如说将复杂任务分解为更简单的子任务意图分类可以使用另一个提示或一个为这个任务训练的分类模型来完成。意图分类机制可以看作是多 agent 系统中的另一个 agent。了解意图可以帮助 agent 选择合适的工具。例如对于客户支持如果查询是关于查工资的agent 可能需要访问一个工具来检索用户最近的工资条信息。但如果查询是关于如何重置密码的agent 可能需要访问文档检索功能。有些查询可能超出了 agent 的能力范围。意图分类器应该能够将请求分类为“不相关”以便 agent 可以礼貌地拒绝这些请求而不是浪费计算资源去尝试不可能的解决方案。到目前为止我们假设 agent 自动化了所有三个阶段生成计划、验证计划和执行计划。实际上人类可以在任何阶段参与进来协助这个过程并降低风险。人类专家可以提供计划、验证计划或执行部分计划。例如对于 agent 难以生成完整计划的复杂任务人类专家可以提供一个高层次的计划然后让 agent 在此基础上进行扩展。 如果计划涉及到有风险的操作例如更新数据库或合并代码更改系统可以在执行前请求明确的人工批准或者将这些操作交给人工执行。为了实现这一点你需要清楚地定义 agent 在每个操作中可以拥有的自动化程度。总而言之解决一个任务通常涉及以下步骤。反思对于 agent 来说不是强制性的但它可以显著提高 agent 的性能计划生成提出完成该任务的计划。一个计划是一系列可管理的操作因此这个过程也称为任务分解。反思和错误纠正评估生成的计划。如果这是一个不好的计划则生成一个新计划。执行采取生成的计划中概述的操作。这通常涉及调用特定的函数。反思和错误纠正在收到操作结果后评估这些结果并确定是否已完成目标。识别并纠正错误。如果目标未完成则生成新计划。当你要求模型“逐步思考”时你实际上是在要求它分解任务。当你要求模型“验证你的答案是否正确”时你实际上是在要求它进行反思。大模型作为规划器一个常见的问题是大模型在规划方面的表现如何。许多研究人员认为大模型至少是那些建立在自回归语言模型之上的模型无法进行规划。Meta 的首席 AI 科学家 Yann LeCun 明确表示自回归 LLM 无法规划。虽然有很多传闻证据表明 LLM 是做规划非常的糟糕但尚不清楚这是否是因为我们不知道如何正确使用 LLM还是因为 LLM 本质上就不能规划。规划的核心是一个搜索问题。你在通向目标的不同路径中搜索预测每条路径的结果奖励并选择结果最有希望的路径。有时你可能会确定根本没有路径可以到达目标。搜索通常需要回溯。例如假设你处于一个步骤其中有两个可能的动作A 和 B。在执行动作 A 后你进入了一个不理想的状态因此你需要回溯到之前的状态以执行动作 B。有些人认为自回归模型只能生成前向动作而不能回溯生成替代动作。因此他们得出结论自回归模型无法规划。但这不一定是真的。在执行完动作 A 的路径后如果模型判断这条路径不合理它可以修改路径改为使用动作 B从而实现回溯。模型也可以随时重新开始选择另一条路径。LLM 也可能因为没有获得规划所需的工具而成为糟糕的规划者。要进行规划不仅需要知道可用的操作还需要知道每个操作的潜在结果。举一个简单的例子假设你想爬上一座山。你可能的动作是向右转、向左转、掉头或径直向前走。但是如果向右转会导致你从悬崖上掉下去你可能就不会考虑这个动作。用技术术语来说一个动作会将你从一个状态带到另一个状态你需要知道结果状态才能决定是否执行这个动作。这意味着仅仅提示模型生成一系列操作例如思维链是不够的。“Reasoning with Language Model is Planning with World Model” 这篇论文认为LLM 因为包含了大量关于世界的信息因此能够预测每个动作的结果。这个 LLM 可以将这种结果预测纳入其中从而生成连贯的计划。即使 AI 不能规划它仍然可以是规划器的一部分。有可能使用搜索工具和状态跟踪系统来增强 LLM以帮助它进行规划。关于RL AgentAgent 是 RL 中的核心概念。根据维基百科的定义RL 是一个“关注智能 agent 如何在动态环境中采取行动以最大化累积奖励”的领域。RL agent 和 FM agent 在许多方面都很相似。它们的共同特点是它们的环境和可能的操作。主要区别在于它们的规划器的工作方式。在 RL agent 中规划器由 RL 算法训练。训练这个 RL 规划器可能需要大量的时间和资源。 在 FM agent 中模型本身就是规划器。这个模型可以通过提示或微调来提高其规划能力而且通常需要更少的时间和资源。但是没有什么能阻止 FM agent 采用 RL 算法来提高其性能。从长远来看FM agent 和 RL agent 将会融合。planning生成将模型变成planning生成器的最简单方法是使用提示工程。假设你想创建一个 agent 来帮助客户了解 家用显卡 的产品。你为该 agent 提供对三个外部工具的访问权限按价格检索产品、检索热门产品和检索产品信息。下面是一个用于计划生成的提示示例。此提示仅用于说明目的。实际的生产提示可能会更复杂。system prompt提出一个解决任务的计划。你可以使用以下5个操作*get_today_date()*fetch_top_products(start_date,end_date,num_products)*fetch_product_info(product_name)*generate_query(task_history,tool_output)*generate_response(query) 计划必须是一系列有效的操作。**示例****任务**“告诉我关于5090的信息”**计划**[fetch_product_info,generate_query,generate_response]**任务**“上周最畅销的产品是什么”**计划**[fetch_top_products,generate_query,generate_response]**任务**{用户输入}**计划**关于这个例子有两点需要注意这里使用的计划格式——一个函数列表其参数由 agent 推断——只是构建 agent 控制流的多种方式之一。generate_query函数接收任务的当前历史记录和最近的工具输出以生成要输入到响应生成器的查询。每个步骤的工具输出都会添加到任务的历史记录中。如果用户输入“上周最畅销产品的价格是多少”则生成的计划可能如下所示get_time()fetch_top_products()fetch_product_info()generate_query()generate_response()你可能会想“每个函数需要的参数是什么” 确切的参数很难提前预测因为它们通常是从之前的工具输出中提取的。如果第一步get_time()输出“2030-09-13”那么 agent 可以推断出下一步的参数应该按如下方式调用retrieve_top_products(start_date2030-09-07,end_date2030-09-13,num_products1)通常没有足够的信息来确定函数的精确参数值。例如如果用户问“最畅销产品的平均价格是多少”那么以下问题的答案就不清楚用户想看多少最畅销的产品用户想要的是上周、上个月还是所有时间的最畅销产品这意味着模型经常需要进行猜测而猜测可能会出错。由于操作序列和相关的参数都是由 AI 模型生成的它们可能会产生幻觉。幻觉会导致模型调用无效的函数或者调用有效的函数但参数错误。通常可以使用提高模型整体性能的技术来提高模型的规划能力。让 agent 更好地规划的提示编写包含更多示例的更好的系统提示。提供对工具及其参数的更清晰的描述以便模型更好地理解它们。重写函数本身使其更简单例如将一个复杂的函数重构为两个更简单的函数。使用更强大的模型。一般来说更强大的模型更擅长规划。为规划生成微调模型。函数调用现在的模型公司基本都提供了函数调用的能力从而有效地将它们的模型变成了 agent。工具就是一个函数。因此调用工具通常称为函数调用。不同的模型 API 的工作方式有所不同但一般来说函数调用按以下步骤工作创建工具清单。声明你希望模型使用的所有工具。每个工具都由其执行入口点例如函数名、参数和文档例如函数的作用以及需要哪些参数描述。指定 agent 可以为特定查询使用的工具。由于不同的查询可能需要不同的工具因此许多 API 允许你指定每个查询要使用的已声明工具列表。有些允许你通过以下设置进一步控制工具的使用required模型必须使用至少一个工具。none模型不应使用任何工具。auto模型决定使用哪些工具。给定一个查询agent 会自动生成要使用的工具及其参数。某些函数调用 API 将确保仅生成有效的函数尽管它们无法保证参数值的正确性。规划粒度规划是概述完成任务所需步骤的路线图。路线图可以有不同的粒度级别。为一年做计划时按季度计划比按月计划更高级而按月计划又比按周计划更高级。在规划和执行之间存在一种权衡。详细的计划更难生成但更容易执行。更高级的计划更容易生成但更难执行。一种规避这种权衡的方法是分层规划。首先使用规划器生成一个高层次的计划例如按季度计划。然后对于每个季度使用相同或不同的规划器生成一个按月计划。到目前为止所有生成的计划示例都使用确切的函数名称这非常细粒度。这种方法的一个问题是 agent 的工具清单会随着时间推移而改变。例如获取当前日期的函数get_time()可以重命名为get_current_time()。当工具发生变化时你需要更新你的提示和所有示例。使用确切的函数名称也使得在具有不同工具 API 的不同用例中重用规划器变得更加困难。如果你之前微调过一个模型以基于旧的工具清单生成计划则你需要使用新的工具清单再次微调该模型。为了避免这个问题计划也可以使用更自然的语言生成这种语言比特定领域的函数名称更高级。例如给定查询“上周最畅销产品的价格是多少”可以指示 agent 输出如下所示的计划获取当前日期 检索上周最畅销的产品 检索产品信息 生成查询 生成响应使用更自然的语言有助于你的计划生成器更好地应对工具 API 的变化。如果你的模型主要是在自然语言上训练的它可能会更擅长理解和生成自然语言的计划并且不太可能出现幻觉。这种方法的缺点是你需要一个翻译器来将每个自然语言操作转换为可执行的命令。Chameleon中将这个翻译器称为程序生成器。但是翻译是一项比规划简单得多的任务并且可以通过幻觉风险较低的弱模型来完成。复杂规划到目前为止的规划示例都是顺序的计划中的下一个操作总是在前一个操作完成后执行。可以执行操作的顺序称为控制流。顺序形式只是控制流的一种类型。其他类型的控制流包括并行、if 语句和 for 循环。以下列表概述了每种控制流包括用于比较的顺序顺序在任务 A 完成后执行任务 B可能是因为任务 B 依赖于任务 A。例如SQL 查询只能在从自然语言输入翻译后执行。并行同时执行任务 A 和 B。例如给定查询“查找 100 元以下的畅销产品”agent 可能会先检索前 100 名畅销产品然后为每个产品检索其价格。If 语句根据上一步的输出执行任务 B 或任务 C。例如agent 首先检查 宁德时代 的财务报告。根据此报告它可以决定出售或购买宁德时代股票。Anthropic 的帖子将此模式称为“路由”。For 循环重复执行任务 A直到满足特定条件。例如持续生成随机数直到出现质数。Agent 控制流在传统的软件工程中控制流的条件是精确的。对于 AI 驱动的 agentAI 模型决定控制流。具有非顺序控制流的计划更难生成和转换为可执行的命令。在评估 agent 框架时请检查它支持哪些控制流。例如如果系统需要浏览十个网站它可以同时进行吗并行执行可以显著减少用户感知的延迟。反思和错误纠正即使是最好的计划也需要不断评估和调整以最大限度地提高其成功的机会。虽然反思对于 agent 的运行并非绝对必要但对于 agent 的成功至关重要。在任务过程中有很多地方可以使用反思在收到用户查询后评估请求是否可行。在初始计划生成后评估该计划是否合理。在每个执行步骤之后评估它是否在正确的轨道上。在整个计划执行完毕后确定任务是否已完成。反思和错误纠正是相辅相成的两种不同机制。反思产生有助于发现需要纠正的错误的见解。反思可以使用具有自我批评提示的同一个 agent 来完成。它也可以使用单独的组件来完成例如专用评分器一个为每个结果输出具体分数的模型。ReAct 首先提出交错推理和行动已成为 agent 的常见模式。在每一步都会要求 agent 解释其想法规划、采取行动然后分析观察结果反思直到 agent 认为任务完成。通常会使用示例提示 agent 以以下格式生成输出想法1:...行动1:...观察1:......[继续直到反思确定任务已完成]...想法 N:...行动 N:完成[对查询的响应]你可以在多 agent 设置中实现反思一个 agent 规划并采取行动另一个 agent 在每个步骤或多个步骤后评估结果。如果 agent 的响应未能完成任务你可以提示 agent 反思失败的原因以及如何改进。基于此建议agent 生成新计划。这使 agent 可以从错误中学习。例如给定一个代码生成任务评估器可能会评估生成的代码在 ⅓ 的测试用例中失败。然后agent 反思失败的原因是它没有考虑到所有数字都是负数的数组。然后执行器生成新代码其中考虑了所有负数数组。这是 Reflexion 采用的方法。在此框架中反思分为两个模块一个评估结果的评估器和一个分析哪里出错的自我反思模块。下图是Reflexion agent 的工作示例。作者使用术语“trajectory”来指代规划。在每一步之后经过评估和自我反思agent 都会提出新的trajectory。与规划生成相比反思相对容易实现并且可以带来令人惊讶的性能提升。这种方法的缺点是延迟和成本。想法、观察有时还有行动可能需要生成大量的 token这会增加成本和用户感知的延迟特别是对于有很多中间步骤的任务。为了促使他们的 agent 遵循格式ReAct 和 Reflexion 的作者都在他们的提示中使用了大量的示例。这会增加计算输入 token 的成本并减少可用于其他信息的上下文空间。工具选择由于工具通常在任务的成功中起着至关重要的作用因此工具选择需要仔细考虑。为你 agent 提供的工具取决于环境和任务但也取决于驱动 agent 的 AI 模型。没有关于如何选择最佳工具集的万无一失的指南。在 agent 文献中你会发现各种各样的工具清单。例如Toolformer (Schick et al., 2023) 微调 GPT-J 以学习 5 个工具。Chameleon (Lu et al., 2023) 使用 13 个工具。Gorilla (Patil et al., 2023) 尝试提示 agent 在 1,645 个 API 中选择正确的 API 调用。更多的工具可以为 agent 提供更多的功能。但是工具越多就越难有效地使用它们。这类似于人类难以掌握大量工具的情况。添加工具也意味着增加工具描述这可能不适合模型的上下文。与构建 AI 应用程序时的许多其他决策一样工具选择需要实验和分析。以下是一些可以帮助你做出决定的事情比较 agent 在不同工具集下的表现。进行消融研究以查看如果从其清单中删除某个工具agent 的性能会下降多少。如果可以删除某个工具而不会降低性能则将其删除。查找 agent 经常出错的工具。如果事实证明某个工具对于 agent 来说太难使用例如大量的提示甚至微调都无法让模型学会使用它请更改该工具。绘制工具调用的分布图以查看哪些工具使用最多哪些工具使用最少。图 6-14 显示了 GPT-4 和 ChatGPT 在 Chameleon (Lu et al., 2023) 中的工具使用模式差异。不同模型具有不同的工具偏好Chameleon 的实验也证明了两点不同的任务需要不同的工具。ScienceQA科学问题解答任务比 TabMWP表格数学问题求解任务更依赖于知识检索工具。不同的模型具有不同的工具偏好。例如GPT-4 似乎选择的工具集比 ChatGPT 更广泛。ChatGPT 似乎更喜欢图像字幕而 GPT-4 似乎更喜欢知识检索。在评估 agent 框架时评估它支持哪些规划器和工具。不同的框架可能专注于不同类别的工具。例如AutoGPT 专注于社交媒体 APIReddit、X 和 Wikipedia而 Composio 专注于企业 APIGoogle Apps、GitHub 和 Slack。由于你的需求可能会随着时间的推移而变化因此请评估扩展你的 agent 以包含新工具的难易程度。作为人类我们变得更高效不仅是因为使用给定的工具还因为从更简单的工具中逐步创建更强大的工具。AI 可以从其初始工具创建新工具吗Chameleon 提出了工具转换的研究在工具 X 之后agent 调用工具 Y 的可能性有多大下图展了一个工具转换的示例。如果两个工具经常一起使用则可以将它们组合成一个更大的工具。如果 agent 意识到此信息则 agent 本身可以组合初始工具以不断构建更复杂的工具。Vogager 提出了一个技能管理器以跟踪 agent 获取的用于以后重用的新技能工具。每个技能都是一个编码程序。当技能管理器确定新创建的技能有用时例如因为它已成功帮助 agent 完成任务它会将此技能添加到技能库在概念上类似于工具清单。以后可以检索此技能以用于其他任务。最后的最后感谢你们的阅读和喜欢作为一位在一线互联网行业奋斗多年的老兵我深知在这个瞬息万变的技术领域中持续学习和进步的重要性。为了帮助更多热爱技术、渴望成长的朋友我特别整理了一份涵盖大模型领域的宝贵资料集。这些资料不仅是我多年积累的心血结晶也是我在行业一线实战经验的总结。这些学习资料不仅深入浅出而且非常实用让大家系统而高效地掌握AI大模型的各个知识点。如果你愿意花时间沉下心来学习相信它们一定能为你提供实质性的帮助。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】大模型知识脑图为了成为更好的 AI大模型 开发者这里为大家提供了总的路线图。它的用处就在于你可以按照上面的知识点去找对应的学习资源保证自己学得较为全面。经典书籍阅读阅读AI大模型经典书籍可以帮助读者提高技术水平开拓视野掌握核心技术提高解决问题的能力同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说阅读经典书籍是非常有必要的。实战案例光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。面试资料我们学习AI大模型必然是想找到高薪的工作下面这些面试题都是总结当前最新、最热、最高频的面试题并且每道题都有详细的答案面试前刷完这套面试题资料小小offer不在话下640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
