深度理解Agent:AI产品经理入门必读!(下) 人人都是产品经
总而言之,扩展、函数和数据存储构成了几种不同类型的工具,可供智能体在运行时使用。每种工具都有其独特用途,智能体开发者可自行决定将它们结合使用或单独使用。1)智能体通过利用工具来访问实时信息、提出现实世界中的行动建议,以及自主规划和执行复杂任务,从而扩展了语言模型的能力。智能体可以利用一个或多个语言模型来决定何时以及如何在不同状态间转换,并使用外部工具来完成模型自身难以或无法独立完成的各种复杂任务。
在AI领域,智能体(Agent)正成为推动产品创新的关键技术。本文作为《深度理解Agent:AI产品经理入门必读》系列的下篇,继续深入探讨Agent的核心组件及其在产品中的应用。文章详细介绍了数据存储的作用、模型性能提升的方法,以及从产品经理视角对Agent应用的洞见与警示。

上一篇介绍了什么是Agent(包含模型、工具、编排、如何运作)、工具篇的扩展和函数部分。
本篇将介绍工具篇的数据存储及总结、模型性能提升、产品经理视角的洞见与警示。
工具篇(续)
数据存储
把语言模型想象成一个巨大的图书馆,里面存放着它的训练数据。但与不断购入新书的图书馆不同,这个 “图书馆” 是静态的,仅包含其最初训练时的知识。这就带来了一个挑战,因为现实世界的知识在不断发展。数据存储通过提供对更动态、最新信息的访问,解决了这一限制,并确保模型的回复基于事实且具有相关性。
数据存储使开发人员能够以原始格式向智能体提供额外数据,从而无需进行耗时的数据转换、模型重新训练或微调。数据存储会将传入的文档转换为一组向量数据库嵌入,智能体可以利用这些嵌入提取所需信息,为其下一步行动或对用户的回复提供补充。

实现与应用:
在生成式人工智能智能体的情境下,数据存储通常被实现为向量数据库,开发者希望智能体在运行时能够访问该数据库。虽然我们在此不会深入探讨向量数据库,但关键要理解的是,它们以向量嵌入的形式存储数据,向量嵌入是一种高维向量,是对所提供数据的数学表示。近年来,数据存储在语言模型中的一个极为常见的应用示例,就是基于检索增强生成(RAG)的应用程序。这些应用程序旨在通过让模型访问各种格式的数据,如:
- 网站内容;
- 以 PDF、Word 文档、CSV、电子表格等格式存在的结构化数据;
- 以 HTML、PDF、TXT 等格式存在的非结构化数据,
每个用户请求和智能体响应循环的底层过程通常如下图 13 所示。
- 用户查询被发送到嵌入模型,以生成该查询的嵌入表示。
- 然后使用类似可扩展最近邻搜索(SCaNN)这样的匹配算法,将查询嵌入与向量数据库的内容进行匹配。
- 从向量数据库中以文本格式检索匹配的内容,并将其发送回智能体。
- 智能体接收用户查询和检索到的内容,然后制定响应或行动。
- 最终的回复被发送给用户。

图 14 展示了一个与采用 ReAct 推理 / 规划来实现检索增强生成(RAG)的智能体的示例交互。(强烈建议看一下图中的具体内容,它示例了Agent的一个循环过程)

工具总结
总而言之,扩展、函数和数据存储构成了几种不同类型的工具,可供智能体在运行时使用。每种工具都有其独特用途,智能体开发者可自行决定将它们结合使用或单独使用。

通过定向学习提升模型性能
有效使用模型的一个关键方面,在于模型在生成输出时能否选择合适的工具,尤其是在生产环境中大规模使用工具的情况下。虽然常规训练有助于模型培养这种技能,但现实场景往往需要训练数据之外的知识。可以将其想象成基本烹饪技能与精通某一特定菜系之间的差别。两者都需要基础烹饪知识,但后者需要定向学习,才能取得更精细的成果。
为帮助模型获取这类特定知识,有几种可行方法:
- 上下文内学习In-context learning:此方法在推理时,为通用模型提供提示、工具以及少量示例,使其能够 “即时” 学习如何以及何时针对特定任务使用这些工具。自然语言处理中的 ReAct 框架就是这种方法的一个例子。
- 基于检索的上下文内学习Retrieval-based in-context learning:该技术通过从外部存储器中检索信息,动态地用最相关的信息、工具及相关示例填充模型提示。比如 Vertex AI 扩展中的 “示例存储”,或者前面提到的基于检索增强生成(RAG)架构的数据存储,都是这种方法的实例。
- 基于微调的学习Fine-tuning based learning:此方法在推理前,使用大量特定示例的数据集对模型进行训练。这有助于模型在接收任何用户查询之前,就理解何时以及如何应用某些工具。
为了更深入地了解每种定向学习方法,让我们以烹饪作为类比。
- 想象一下,一位厨师从顾客那里收到一份特定的食谱(提示)、一些关键食材(相关工具)以及几道示例菜肴(少量示例)。基于这些有限的信息以及厨师的烹饪常识,他们需要 “即时” 想出如何制作出与食谱和顾客偏好最相符的菜肴。这就是上下文内学习。
- 现在,假设我们这位厨师身处一个食材储备丰富的厨房(外部数据存储),里面摆满了各种食材和烹饪书籍(示例和工具)。此时,厨师能够从厨房储备中动态挑选食材和烹饪书籍,更好地契合顾客的食谱和偏好。这使得厨师能够借助已有的知识和新知识,制作出更符合要求且更精致的菜肴。这就是基于检索的上下文内学习。
- 最后,设想我们送这位厨师回学校学习一种或几种新菜系(使用大量特定示例的数据集进行预训练)。这样一来,厨师在面对未来从未见过的顾客食谱时,就能有更深入的理解。如果我们希望厨师精通特定菜系(知识领域),这种方法就非常合适。这就是基于微调的学习。
- 就速度、成本和延迟而言,每种方法都有其独特的优缺点。然而,通过在智能体框架中结合这些技术,我们可以发挥它们的各种优势,将劣势降至最低,从而获得一个更强大、适应性更强的解决方案。
虽然本文探讨了智能体的核心组件,但构建生产级应用程序还需要将它们与用户界面、评估框架和持续改进机制等其他工具相结合。
总结

本文的一些关键要点包括:
1)智能体通过利用工具来访问实时信息、提出现实世界中的行动建议,以及自主规划和执行复杂任务,从而扩展了语言模型的能力。智能体可以利用一个或多个语言模型来决定何时以及如何在不同状态间转换,并使用外部工具来完成模型自身难以或无法独立完成的各种复杂任务。
2)智能体运行的核心是编排层,这是一种认知架构,它组织推理、规划、决策过程并指导智能体的行动。诸如 ReAct、思维链(Chain-of-Thought)和思维树(Tree-of-Thoughts)等各种推理技术,为编排层提供了一个框架,使其能够接收信息、进行内部推理,并生成明智的决策或响应。
3)扩展、函数和数据存储等工具,是智能体通向外部世界的钥匙,使它们能够与外部系统交互,并获取超出其训练数据范围的知识。扩展在智能体与外部 API 之间架起了一座桥梁,能够执行 API 调用并检索实时信息。函数通过分工为开发者提供了更精细的控制,允许智能体生成可在客户端执行的函数参数。数据存储使智能体能够访问结构化或非结构化数据,从而实现数据驱动的应用程序。
4)智能体通常包含以下几个部分:
- 推理能力:指支撑复杂逻辑推理、语言理解与决策过程的基础模型。这些模型负责评估信息,构成了 Agent 的认知中枢。
- 记忆系统:负责存储、组织并检索短期上下文信息以及长期积累的知识。
- 工具调用:指 Agent 与外部应用程序、API 接口、数据库、互联网及其他软件进行交互的集成能力。
- 规划能力:指 Agent 内部用于拆解复杂任务为可管理步骤、评估执行效果并适时调整策略的架构设计。
智能体的未来充满令人激动的发展,而我们目前仅仅是浅尝辄止,尚未充分发掘其潜力。随着工具变得更加精良,推理能力得到提升,智能体将能够解决愈发复杂的问题。
此外,“智能体链式连接” 这一策略性方法的发展势头将持续增强。通过将专长于特定领域或任务的专业智能体组合在一起,我们可以打造一种 “智能体专家组合” 的模式,使其能够在各个行业和各类问题领域取得卓越成果。
写在最后
(1)为什么Agent还没有爆发
- 没有清晰的AI或Agent-Native的产品形态落地
- 需要对AI、行业know-how的认知,都非常深
- 另外,还有一个“Agent爆发”需要的前置条件当前远没有具备,就是:Agent和Agent之间通信、交互的标准和基建,目前还几乎是行业空白。
(2)基于Agent的框架,产品经理的产品思维要有哪些变化
过去互联网/移动互联网时代,典型的思考格式是“场景-用户-需求”(什么场景下,怎样的典型用户画像,有什么痛点需求)。AI 2.0时代,需要增加一个关键词,“关系”。某个Agent在某个场景里,和用户或者其他Agent之间,是什么的关系?定义了关系,其实就定义了边界、约束条件和需求属性。
(3)回归问题本质,AI 只是锤子
对于产品经理来说,在落地产品的时候,核心是解决你的问题:至于是不是智能体,是不是大语言模型,是不是 AI 帮你决策,都不是最重要的。
一个被提及很多的是吴恩达老师写的多智能体翻译的例子,简单来说就是用三个智能体:一个直译智能体、一个审查智能体、一个意译润色智能体,确实可以大幅提升翻译质量。但并非一定要三个智能体才能提升翻译质量,其实,基于 Prompt 让 LLM 在翻译时,使用直译 + 反思 + 意译三个步骤输出,也可以得到高质量的翻译结果。
其实大部分 AI 应用场景都类似:要用 AI 解决问题,核心不在于智能体,而在于设计出一个适合 AI 的工作流。我们有时候过于关注一些流行的概念或技术,而忽略了要解决的根本问题是什么,将 AI 变成了目的而不是手段。
如果你有了解马斯克的第一性原理思维,其强调的就是回归事物最基本的条件,把其解构成各种要素进行分析,从而找到实现目标最优路径的方法。
而运用第一性原理通常有三个步骤:
第 1 步:定义清楚你要解决的根本问题。
第 2 步:拆解问题。
第 3 步:从头开始创建解决方案。
而这也个思路也适用于我们去借助 AI 解决问题,设计出适合 AI 的工作流。真正要用好 AI,让 AI 发挥最大效能,核心是还是要基于你要解决的问题,重新设计一个适合 AI 的工作流,让 AI 在工作流中完成它最擅长的工作,至于是不是智能体,是不是大语言模型,是不是 AI 帮你决策,都不是最重要的。
*一、AI行业的招聘趋势以及人才紧缺度*
根据脉脉《2023年人才报告》显示:人工智能成为2022最缺人行业,⼈⼯智能⾏业的⼈才紧缺指数(⼈才需求量/⼈才投递量)为0.83,也就是说这个领域人才缺口巨大且没那么卷。而且随着ChatGPT4.0的大火,这种趋势在2023年强势蔓延。
目前,各行业内人士的共识就是:*AI产品经理超级缺人,大小公司都缺*。我最近跟小米、百度的资深AI产品沟通,他们反馈:在大量招人,只要有AI相关的项目经验,学历别太差就能拿到面试机会。而且领导很舍得给钱,涨薪40-60%很正常。

在AI领域,特别是最近大火的AIGC方向,招聘量最大的就是两类岗位:一类是研发类,一类是产品类。

整体上,这两类岗位的薪资也最高,也最建议大家求职这两类岗位。根据脉脉高聘人才智库的数据显示:
AIGC领域热招岗位中,图像识别、算法研究员、深度学习岗位的薪资均已达到百万。
此外,AIGC产品经理作为非技术岗,薪资水平也达到90万元,与其他领域相比占据较大优势,吸引大量产品人才投递。

*1.1 AI产品经理职责*
主要职责一方面是规划如何将成熟的AI技术应用在各个领域不同场景中,提升原有场景的效率或效果等;另一方面是基于业务方的需求如何用现有的AI技术或者AI技术组合予以实现,甚至有可能联合技术团队孵化新的AI软件解决方案或者AI硬件产品。
*1.2 AI产品经理与传统互联网产品经理的区别*
AI产品经理本身也只是产品经理的一种,并没有什么特殊性。只是这些年AI相对比较火,理解AI技术需要一定的技术门槛,和传统的交互产品经理、系统产品经理等对比起来入门门槛更高。传统的互联网产品经理不懂技术是可以成为一名优秀的产品经理,但是对于AI产品经理来说完全不懂技术,只具备产品经理应有的沟通能力、协调能力、项目管理能力等是很难成为一名优秀的AI产品经理的。AI产品经理与传统互联网产品经理最大的区别应该是“懂技术”成为了必要条件,当然目前市场上很多AI产品经理都只对AI技术略知皮毛,理不清机器学习和深度学习的区别,不会算召回率和精准率等。而AI产品经理未来的大趋势是一定由“懂技术”的专业性人才担任,而不是传统那些通用型产品经理人才担任,国内外AI&机器学习&计算机科学等专业毕业的科班学生越来越多,这方面的专业性人才也会越来越多。(“懂技术”是一个相对比较宽泛的概念,简单直接点说就是可以和算法研发们基本无障碍地进行沟通,能够客观准确地评估他们的工作量,这点产品经理懂得都懂。)
*2*.** AI产品经理的类型**
我们弄明白什么是AI产品经理后,那么AI产品经理具体可以分为哪些方向了。如下图:

总的分为两个大的方向,一个是AI软件产品经理,将AI等技术应用在某些场景中,是一个AI软件解决方案。同时部分场景下需要调整AI应用的策略和效果等,这种有时候也被称为AI算法产品经理,这里我们不再继续细分。
*作为一个零基础小白,如何做到真正的入局AI产品?*
*为了帮助开发者打破壁垒,快速了解AI产品经理核心技术原理,学习相关AI产品经理,及大模型技术。从原理出发真正入局AI产品经理*。
📖AI产品经理经典面试八股文
📖大模型RAG经验面试题
📖大模型LLMS面试宝典
📖大模型典型示范应用案例集99个
📖AI产品经理入门书籍
📖生成式AI商业落地白皮书
AI产品经理需要掌握的技术
AI是一个找出对应关系的工具,把行业内的需求,转化成的“输入”和“输出”的问题,然后收集数据,整理成训练集给AI进行学习。不同技术方向下的“输入”和“输出”,形式会有不同。
AI产品上线之后一般是需要做三件事:1)模型评估指标体系的搭建,这部分应该是在产品定义之初就搭建好;2)指标的计算逻辑设计;3)模型验收测试。

根据以上AI产品经理工作流程的梳理,我梳理了3大技能模型,如上图所示如果有兴趣想提前布局进入AI产品经理的领域的同学,可以根据这个作为方向,一点点的提升自己的能力。
**或扫描下方二维码领取 **

更多推荐


所有评论(0)