人们对人工智能(尤其是最新一波以法学硕士为核心的人工智能)的潜力,以及“人工智能优先”的公司与前几代公司有何不同,都充满了期待。虽然有很多重要且切实的机遇摆在眼前,但我发现,很多这样的讨论都停留在抽象的层面,有些过于抽象了。这就好比说,如果你的公司仅仅采用了软件,情况就会好得多。这当然没错,但这并不是一个特别有用的论断。
这篇文章旨在简明扼要地总结人工智能代理的工作原理,并将该总结应用于一些现实世界的人工智能用例,并证明人工智能代理的潜力与当代人工智能相当。我希望读完本文后,您能够就法学硕士 (LLM) 和代理如何改变贵公司的形态进行具体的讨论。
代理商如何工作?
从本质上讲,使用 LLM 是一个包含提示的 API 调用。例如,您可以调用 Anthropic 的/v1/message
并输入提示: How should I adopt LLMs in my company?
该提示用于填充 LLM 的上下文窗口,从而调整模型以生成特定类型的响应。
这是代理可以做的第一件重要的事情:使用 LLM 评估上下文窗口并得到结果。
提示工程,或者现在所说的上下文工程,是指决定将哪些内容放入上下文窗口,以便生成所需的最佳响应。例如,上下文学习 (ICL) 就是一种上下文工程,在提问之前,你需要提供一堆类似的示例。如果我想确定一笔交易是否是欺诈性的,那么我可能会提供一堆先前的交易,以及它们是否是欺诈性的,作为 ICL 示例。这些示例可以提高生成正确答案的可能性。
然而,编写完美的上下文窗口非常耗时,可以利用元提示之类的技巧来改进上下文。事实上,创建初始上下文的人(或自动化)可能没有足够的知识来提供相关的上下文。例如,如果你提示“ Who is going to become the next mayor of New York City?
,那么你就不适合在提示中包含该问题的答案。要做到这一点,你需要已经知道答案,这就是你一开始提出这个问题的原因!
我们看到,OpenAI 和 Anthropic 的模型聊天体验利用网络搜索来获取你可能没有的背景信息。如果你问一个关于纽约新市长的问题,他们会使用一个工具来检索网络搜索结果,然后将这些搜索的内容添加到你的上下文窗口中。
这是代理可以做的第二件重要的事情:使用 LLM 来建议与上下文窗口相关的工具,然后使用该工具的响应来丰富上下文窗口。
然而,澄清“工具使用”的实际运作方式至关重要。LLM 实际上并不会调用工具。(如果您想查看一个具体的实际示例,可以浏览 OpenAI 的函数调用文档。)相反,调用工具的过程分为五个步骤,可能有点违反直觉:
- 调用 LLM API 的程序设计者还必须定义一组允许 LLM 建议使用的工具。
- 对 LLM 的每个 API 调用都包含一组定义的工具,作为 LLM 可以推荐的选项
- 具有定义函数的 API 调用的响应是:
-
生成的文本与任何其他 LLM 调用一样
-
建议调用具有特定参数集的特定工具,例如了解
get_weather
工具的 LLM,当被提示有关巴黎的天气时,可能会返回此响应:[{ "type": "function_call", "name": "get_weather", "arguments": "{\"location\":\"Paris, France\"}" }]
-
- 调用 LLM API 的程序随后会决定是否以及如何执行该工具使用请求。程序可能会拒绝该工具请求,因为它最近使用过于频繁(例如,速率限制);它可能会检查相关用户是否有权使用该工具(例如,它可能是一个仅限付费用户使用的工具);它还可能会检查参数是否与用户基于角色的权限匹配(例如,用户可以查看天气,但只有管理员用户才被允许查看法国的天气)。
- 如果程序确实决定调用该工具,它将调用该工具,然后调用 LLM API,并将该工具的输出附加到先前调用的上下文窗口。
这个循环的关键在于,LLM 本身仍然只能做一件有趣的事情:获取上下文窗口并返回生成的文本。更广泛的程序(我们可以在此时将其称为代理)会调用工具并将工具的输出发送到 LLM 以生成更多上下文。
神奇的是,LLM 加上工具之后,能够真正改善生成上下文窗口的方式。无需事先定义好初始上下文窗口,你只需使用工具注入相关上下文,即可改进初始上下文。
这引出了代理可以做的第三件重要的事情:它们管理工具使用的流量控制。让我们考虑三种不同的场景:
- 通过规则进行流程控制,对于如何使用工具有具体的规则。例如:
- 它可能只允许在给定的工作流程中使用一次给定的工具(或每个用户对工具的使用限制等)
- 可能需要人工批准超过一定值的参数(例如,超过 100 美元的退款需要人工批准)
- 它可能会运行生成的 Python 程序并返回输出以分析数据集(如果失败则提供错误消息)
- 对工具使用应用权限系统,限制谁可以使用哪些工具以及特定用户可以使用哪些参数(例如,您只能检索自己的个人数据)
- 只有在与 LLM 代理进行五次来回沟通后,才能调用升级到人工代表的工具
- 通过统计进行流量控制可以使用统计数据来识别异常行为并采取行动:
- 如果退款金额高于该订单其他退款的 99%,您可能需要升级到人工
- 如果某个用户使用某个工具的次数超过其他用户的 99%,那么你可能希望在当天剩余时间内拒绝其使用
- 如果工具参数与之前需要升级到人工代理的参数更相似,则可能会升级到人工代表
LLM 本身绝对不可信。任何时候依赖 LLM 来执行重要的事情,你都会失败。使用代理来管理流程控制,是构建安全可靠 LLM 系统的机制。每当你发现自己面对的是基于 LLM 的不可靠系统时,你总能找到一种方法,将复杂性转移到工具上来避免这个问题。例如,如果你想用 LLM 做代数运算,解决方案不是让 LLM 直接进行代数运算,而是为 LLM 提供一个能够进行代数运算的工具,然后依靠 LLM 使用适当的参数调用该工具。
至此,代理还有最后一件重要的事情:它们是软件程序。这意味着它们可以做任何软件能做的事情,以构建更好的上下文窗口,并将其传递给 LLM 进行生成。这类任务种类繁多,但通常包括:
- 构建通用上下文以添加到上下文窗口,有时被认为是维护记忆
- 根据票务跟踪器、客户支持系统等中的传入票证启动工作流程
- 在特定时间定期启动工作流程,例如每小时审查一次收到的工单
好了,我们现在已经将AI代理的功能总结为四种通用能力。简单回顾一下,这些能力包括:
- 使用 LLM 评估上下文窗口并获取结果
- 使用 LLM 建议与上下文窗口相关的工具,然后使用该工具的响应丰富上下文窗口
- 通过规则或统计分析管理工具使用的流量控制
- 代理是软件程序,可以做其他软件程序能做的任何事情
有了这四种能力,我们将能够思考如何将人工智能代理应用于多种机会,以及不能应用于哪些机会。
用例 1:客户支持代理
人们经常谈论部署AI代理的首要场景之一就是客户支持,所以我们就从这里开始吧。典型的客户支持流程会涉及多层级的代理,负责处理日益复杂的客户问题。因此,我们设定一个目标,首先接管最简单的层级,随着效果显现,再逐步提升层级。
我们的方法可能是:
- 允许工单(或支持聊天)流入 AI 代理
- 提供多种工具给代理商支持:
- 检索有关用户的信息:最近的客户支持单、帐户历史记录、帐户状态等
- 升级到下一级客户支持
- 退还购买款项(几乎肯定会以“退款购买”的形式实现,指的是用户的特定购买,而不是“退款金额”,以防止代理商被欺骗而退还过多款项的情况)
- 根据要求关闭用户帐户
- 在上下文窗口中包含客户支持指南,描述客户问题,并将这些问题映射到应该用于解决问题的特定工具
- 流程控制规则,确保所有未在特定时间段内解决的呼叫都升级为人工处理,包括来回沟通次数、代理程序出错等。这些规则应基于规则和统计数据,以确保规则中的漏洞不会被利用,也不会造成糟糕的客户体验。
- 审查客服人员与客户之间的互动,以控制质量,并改进提供给人工智能客服人员的支持指南。首先,您需要审查每一次互动,然后逐步审查导致异常结果(例如升级到人工客服)的互动,并进行一定程度的随机抽样。
- 审查每小时、每天、每周的座席绩效指标
- 根据指标评审的经验,您应该为需要更快速响应的警报设定基准。例如,如果某个新主题频繁出现,则可能意味着您的产品或流程出现了严重的倒退,需要立即评审,而不是定期评审。
请注意,即使您已将“客户支持移至 AI 代理”,您仍然拥有:
- 处理最复杂呼叫的人工代理层
- 人类审查定期绩效统计数据
- 人类对人工智能代理与客户互动进行质量控制
您完全可以用专属的AI代理取代每个下游步骤(例如审查绩效统计数据),但这需要为每个流程开发一款AI产品。这是一个递归过程,随着时间的推移,您可以消除业务中的许多人为因素,但随着复杂性的增加,脆弱性也会随之增加。复杂系统最有趣的部分并非其运作方式,而是其故障方式。代理驱动的系统偶尔也会发生故障,所有系统都会如此,包括人为驱动的系统。
只要谨慎操作,上述一系列措施就能成功。然而,重要的是要认识到,这需要构建一整条软件流水线,并学习如何在生产环境中运营该软件流水线。这些都是切实可行的,但也是意义非凡的工作,需要将客户支持团队转变为产品经理,并需要一个工程团队来构建和运营客户支持代理。
用例 2:对收到的错误报告进行分类
当公司内部出现事故,或者收到错误报告时,首要任务就是确定问题的严重程度。如果问题可能非常严重,那么您需要值班工程师立即展开调查;如果问题确实不严重,那么您需要通过某种不太紧急的流程进行分类。思考一下人工智能代理如何支持这种分类工作流程,将会非常有趣。
该过程可能如下:
- 将所有创建的事件和所有创建的票证传送给该代理进行审核。
- 向代理公开这些工具:
- 开启事件
- 检索当前事件
- 检索最近创建的票证
- 检索生产指标
- 检索部署日志
- 检索功能标志更改日志
- 切换已知安全功能标志
- 建议将一个事件与另一个事件合并以供人工批准
- 建议将一张票与另一张票合并以供人工批准
- 为关键工作流程提供冗余的 LLM 提供商。如果 LLM 提供商的 API 不可用,则在十秒内重试三次,然后尝试使用第二个模型提供商(例如,先使用 Anthropic,如果不可用则尝试 OpenAI),最后创建一个分类机制不可用的事件。对于关键工作流程,我们不能简单地假设 API 可用,因为实际上所有主要提供商似乎都存在月度可用性问题。
- 合并重复项。收到工单时,首先检查正在进行的事件和最近创建的工单,查找可能重复的工单。如果存在重复项,建议将该工单或事件与现有问题合并,然后退出工作流程。
- 评估影响。如果生产统计数据受到严重影响,或者生产中出现新的错误,则很可能需要快速人工审核。如果是高优先级,则创建事件。如果是低优先级,则创建工单。
- 提出原因。既然事件的规模已经确定,那就转而分析事件的潜在原因。查看最近部署的代码提交,并提出可能导致当前错误的潜在问题。在某些情况下,这可能是显而易见的(例如,通过回溯最近更改的代码行来发现尖峰错误),而在其他情况下,这仅仅是时间上的接近性。
- 应用已知安全的功能标记。建立一个允许系统自行激活的已知安全功能标记列表。例如,如果某些高开销的功能可以安全禁用,则可以允许禁用它们。例如,在负载下限制对深度搜索结果进行分页,这可能是在稳定性和用户体验之间进行合理权衡的措施。
- 听从人类指引。此时,依靠人类来推动事件或工单的补救工作直至完成。
- 起草初始事件报告。如果已启动事件,代理应起草一份初始事件报告,其中包括时间线、相关变更以及事件过程中的人员活动。该报告随后应由参与事件的人员最终完成。
- 运行事件审查。您现有的事件审查流程应该进行事件审查,并确定如何修改您的系统(包括分类代理),以提高可靠性。
- 重新启用功能开关的安全措施。由于我们现在有代理来禁用功能开关,我们还需要添加定期检查(代理驱动或其他方式),以便在没有持续事件发生的情况下重新启用“已知安全”的功能开关,避免意外长时间禁用它们。
这是另一个 AI 代理,只要你把它当作软件产品,它就绝对有效。在这种情况下,工程部门很可能是产品负责人,但它仍然需要经过深思熟虑的迭代,才能随着时间的推移改进其行为。为了使此流程有效,需要进行一些持续的验证,包括:
-
人类在事件响应和审查中的作用依然重要,只不过需要借助代理的帮助。尤其是在审查过程中,代理无法解决审查流程的问题,因为它需要根据事件主动学习需要进行哪些更改。
你可以提出一个合理的论点,即一个代理可以决定需要更改的内容,然后将该规范交给另一个代理来实现。即使在今天,你也可以很容易地想象低风险的更改(例如,副本更改)会自动添加到工单中以供人工审批。
对于更复杂或风险更高的变更,这样做是可能的,但需要格外谨慎和细致:这与“只需添加代理,事情就变得简单”的想法截然相反。相反,实现这种自动化需要格外小心地限制对系统的更改,以免暴露不安全的行为。例如,我认识的一家初创公司使用领域特定语言 (DSL) 来表示他们的领域逻辑,这种语言可以由 LLM 安全生成,并且能够仅通过该 DSL 来表示许多客户特定的功能。
-
扩大已知安全功能标记列表,使事件可补救。要广泛实施此操作,需要对软件开发方式实施非常具体的要求。即使只是小范围地实施此操作,也需要进行更改,以确保已知安全功能标记在软件开发过程中保持安全。
-
定期审查事件统计数据,确保平均解决时间 (MTTR) 持续减少。如果代理确实有效,MTTR 应该会减少。如果代理没有推动 MTTR 的降低,则说明实施细节存在问题。
即使非常高效的代理也无法减轻精心设计系统的责任。相反,代理可以提升系统设计的质量:做得好,代理可以显著提高效率。做得不好,它们只会进一步放大你的问题。
人工智能代理是否代表了这一代人工智能的全部?
如果你接受我的定义,即AI代理是法学硕士(LLM)和软件的任意组合,那么我认为,这一代AI所能表达的,几乎都符合这个定义。我很乐意接受“法学硕士”这个术语过于狭隘,或许“基础模型”这个术语更合适。我的感觉是,这是一个前沿定义和口语化用法略有偏差的地方。
总结
法学硕士和代理是强大的机制。我认为它们将真正改变产品的设计方式和运作方式。整整一代软件开发者和公司高管正在学习这些工具的工作原理。软件并非魔法,它非常合乎逻辑,但它所能实现的功能却充满魔力。代理和法学硕士也是如此。我们越能加快学习曲线,对我们的行业就越有利。