惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Martin Fowler
Martin Fowler
J
Java Code Geeks
博客园 - 【当耐特】
宝玉的分享
宝玉的分享
腾讯CDC
D
DataBreaches.Net
Microsoft Azure Blog
Microsoft Azure Blog
Engineering at Meta
Engineering at Meta
V
V2EX
F
Fortinet All Blogs
MyScale Blog
MyScale Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
Tailwind CSS Blog
Jina AI
Jina AI
GbyAI
GbyAI
大猫的无限游戏
大猫的无限游戏
A
About on SuperTechFans
酷 壳 – CoolShell
酷 壳 – CoolShell
爱范儿
爱范儿
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
U
Unit 42
B
Blog
M
MIT News - Artificial intelligence
N
Netflix TechBlog - Medium

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
人工智能代理入门(下):自主性、保障措施和陷阱
世界模型工场 · 2024-11-30 · via 人人都是产品经理

作为代理大脑的LLM的能力门槛相对较高。规模较小的LLM可能需要大量及时的工程或微调才能满足要求。

在上部分中,我们概述了利用AI代理提高企业效率的关键策略。我解释了与独立AI模型不同,代理如何使用上下文和工具迭代地优化任务以增强代码生成等结果。我还讨论了多代理系统如何促进跨部门沟通,创造统一的用户体验并提高生产力、弹性和更快的升级。

成功构建这些系统的关键在于映射角色和工作流程,以及建立诸如人工监督和错误检查之类的保障措施以确保安全运行。让我们深入探讨这些关键要素。

01 保障和自主权件

代理意味着自主性,因此必须在多代理系统中为代理内置各种保护措施,以减少代理自主运行时的错误、浪费、法律风险或危害。将所有这些保护措施应用于所有代理可能会过度并带来资源挑战,但我强烈建议考虑系统中的每个代理,并有意识地决定它们需要哪些保护措施。如果满足其中任何一个条件,代理就不应该被允许自主运行。

02 明确定义人为干预条件

触发一组预定义规则中的任何一个都会决定人类需要确认某些代理行为的条件。

这些规则应根据具体情况进行定义,并可在代理的系统提示中声明或者在更关键的用例中,使用代理外部的确定性代码来执行。对于采购代理来说,一条这样的规则是:“所有采购都应首先由人类验证和确认。调用您的‘check_with_human’函数,直到它返回值后再继续。”

03 保障代理

保障代理可以与负责检查风险、不道德或不合规行为的代理配对。可以强制代理始终根据保障代理检查其行为的全部或某些元素,除非保障代理返回批准,否则不会继续。

04 不确定性

我们实验室最近发表了一篇论文,介绍了一种可以衡量大型语言模型 (LLM) 生成内容的不确定性的技术。

鉴于LLM倾向于虚构(通常称为幻觉),优先考虑某个输出可以使代理更加可靠。这里也需要付出代价。评估不确定性需要我们为同一请求生成多个输出,以便我们可以根据确定性对它们进行排序,并选择不确定性最小的行为。这可能会使系统变慢并增加成本,因此应该考虑系统中更关键的代理。

05 解除按钮

有时我们需要停止所有基于代理的自主流程。这可能是因为我们需要一致性,或者我们检测到系统中的行为需要停止,以便我们找出问题所在并修复它。对于更关键的工作流程和流程,重要的是这种脱离不会导致所有流程停止或完全变成手动,因此建议配置确定性的后备操作模式。

06 代理生成的工作订单

并非代理网络中的所有代理都需要完全集成到应用程序和API中。这可能需要一段时间,并且需要几次迭代才能正确完成。

我的建议是向代理(通常是网络中的叶节点)添加一个通用占位符工具,该工具只会发布报告或工作订单,其中包含代表代理手动采取的建议操作。这是一种以敏捷方式引导和运营代理网络的好方法。

07 测试

借助基于LLM的代理,我们以牺牲一致性为代价获得了稳健性。此外,鉴于 LLM的不透明性,我们正在处理工作流中的黑盒节点。这意味着我们需要一种不同于传统软件的基于代理系统的测试机制。然而,好消息是,我们已经习惯了测试这样的系统,因为自工业化开始以来,我们就一直在运营以人为本的组织和工作流程。

虽然我上面展示的例子只有一个入口点,但多代理系统中的所有代理都有一个LLM作为大脑,因此它们可以充当系统的入口点。我们应该使用分而治之的方法,首先从层次结构中的各个节点开始测试系统的子集。

我们还可以利用生成式人工智能来提出针对网络的测试用例,以分析其行为并推动它揭示其弱点。

最后,我非常提倡沙盒。此类系统应首先在受控且安全的环境中小规模推出,然后逐步推广以取代现有的工作流程。

08 微调

关于通用人工智能的一个常见误解是,你用得越多,它就越好。这显然是错误的。LLM是经过预先训练的。话虽如此,它们可以通过各种方式进行微调以偏向其行为。一旦设计出多智能体系统,我们就可以选择通过从每个智能体获取日志并标记我们的偏好来构建微调语料库,从而改善其行为。

09 陷阱

多代理系统可能会陷入混乱,这意味着有时查询可能永远不会终止,代理之间会不断进行通信。这需要某种形式的超时机制。例如,我们可以检查同一查询的通信历史记录,如果查询量增长过大或检测到重复行为,我们可以终止流程并重新开始。

另一个可能出现的问题是一种我称之为超负荷的现象:对单个代理期望过高。目前最先进的法学硕士课程不允许我们向代理提供冗长而详细的说明,并期望他们始终遵循这些说明。另外,我是否提到过这些系统可能不一致?

缓解这些情况的方法就是我所说的粒度化:将代理分解为多个相连的代理。这可以减少每个代理的负载,并使代理的行为更加一致,不太可能陷入混乱。(我们实验室正在进行的一个有趣的研究领域是自动化粒度化过程。)

多代理系统设计方式的另一个常见问题是倾向于定义一个协调代理,该代理会调用不同的代理来完成一项任务。这引入了单点故障,可能导致一组相当复杂的角色和职责。在这些情况下,我的建议是将工作流视为一个管道,一个代理完成部分工作,然后将其交给下一个代理。

多代理系统还倾向于将上下文传递到其他代理。这可能会使其他代理过载,使它们感到困惑,而且往往是不必要的。我建议允许代理保留自己的上下文,并在我们知道正在处理新请求时重置上下文(有点像网站的会话工作方式)。

最后,需要注意的是,作为代理大脑的LLM的能力门槛相对较高。规模较小的LLM可能需要大量及时的工程或微调才能满足要求。好消息是,已经有几个商业和开源代理通过了这一门槛,尽管规模相对较大。

这意味着在构建大规模多智能体系统时,成本和速度需要成为重要考虑因素。此外,还应设定预期,这些系统虽然比人类快,但不会像我们习惯的软件系统那样快。(Venture Beat)

本文作者Babak Hodjat是Cognizant的人工智能首席技术官
本文由人人都是产品经理作者【AI新智能】,微信公众号:【AI新智能】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。