思想领袖

为什么仅有更好的数据仍不足以支撑人工智能智能体

mm
将 Unite.AI 添加到您在 Google 上的首选来源

多年来,企业应用人工智能时最常听到的建议之一,就是先把数据准备好。道理很简单:系统要做出有用的决策,就需要准确、易于获取的信息。

如今,这一说法依然成立,但随着人工智能智能体从回答问题、生成内容,转向代表员工和组织采取行动,这一说法也逐渐显得不够全面。数据可以告诉智能体关于客户、交易、索赔或请求的真实情况,却未必能告诉它接下来应该怎么做,也未必能让它了解采取行动会带来什么后果。当智能体不再只是提供答案,而是要批准请求、更新记录、联系客户或推进案件时,这一区别就至关重要。

企业员工需要学会在包含审批链、业务规则、依赖关系、例外情况和升级处理路径的体系中工作,智能体也需要有办法做到这一点。鉴于Gartner预测,到2026年底,40%的企业应用将包含针对特定任务的人工智能智能体,而2025年这一比例还不到5%,智能体的知识盲区只会越来越难以忽视。

Gartner还预测,到2028年,智能体人工智能带来的可观投资回报中,80%将来自专业化、面向特定领域的智能体。专业化很重要,但它只解决了部分问题。了解某个特定领域,并不会自动让智能体明白自己的职责从何处开始、到何处结束,自己的任务如何融入更大的流程,或当事情超出职责范围时应由谁接手。要成为企业工作中可靠的一员,智能体既需要了解工作流和流程背景,也需要掌握业务数据。

优质数据不会告诉智能体接下来会发生什么

以贷款申请为例,智能体可能能够访问申请人的财务历史、就业信息和其他相关记录。这些信息有助于它理解申请内容,却无法告诉它组织会如何处理这份申请。

哪些检查需要先进行?申请人符合某项条件、却不符合另一项条件时,处理方式会有什么变化?案件进入下一步前,必须具备哪些信息?哪些决定可以自动作出,哪些需要交由信贷审批人员处理?

企业的大多数工作都充满了这类条件分支。满足某些标准时,流程可能自动推进;也可能暂停以收集更多信息;遇到例外情况时,还可能转入完全不同的处理路径。下一步该采取什么行动,不仅取决于现有信息,还取决于工作当前进行到哪个环节,以及此前已经发生了什么。

这改变了企业对智能体可靠性的定义。如果下一步行动错了,答案再准确也不够。智能体即使正确理解了眼前的信息,仍可能把案件推进到错误的阶段、跳过必要的审批,或在某项前置事项完成之前就采取行动。

McKinsey最近分享了其与一家医疗科技公司的合作经验。该公司发现,自己正在使用的人工智能平台无法支持其若干核心工作流规则。公司没有为了弥补这些缺口而推迟上线日期,而是按原计划继续推进,最终导致人工智能原本预期创造的价值约有30%未能实现。这一案例凸显了企业的必要之举:不仅要考虑完成任务所需的信息,也要考虑任务所处的流程。

让防护措施与智能体能够作出的决策相匹配

随着智能体开始具备采取行动的能力,治理措施也需要更加具体。检索政策文件的智能体,与能够更改客户账户、批准付款或发起交易的智能体,所带来的风险并不相同。然而,组织很容易走向两个极端之一:要么让智能体过于自由地行动,要么几乎所有事情都要求人工审批。

针对智能体的控制措施应与它能够作出的决策及其潜在后果相匹配。低风险、重复性的操作或许适合由智能体独立完成。另一项操作可能需要在金额超过某个数值时获得批准。遇到特殊案件时,则可能需要立即升级给员工处理。

只有经过审慎安排,人工监督才能发挥最大作用。如果每个常规步骤都必须由人批准,引入智能体的大部分好处就会消失。但如果在确实需要判断或问责的决策中取消检查环节,又会造成另一种问题。

IBM Research一直主张,应明确规定智能体获准采取的行动,以及必须进行人工监督的环节。这些控制措施还需要考虑智能体所参与的流程。智能体的权限未必会从个案开始到结束始终保持不变。它能够安全执行哪些操作,可能取决于流程所处的阶段、已经核实的信息、先前作出的决定,以及下一步行动可能造成的后果。

这意味着,组织需要将治理机制融入工作流程本身。与其赋予智能体一套宽泛的权限,并让它在所有环节都依赖这套权限,不如明确规定它可以在哪些环节自主行动、在哪些环节必须满足额外条件,以及在哪些环节必须将责任移交给人。问题的重点也就不再是智能体是否具备自主性,而是在流程中的哪些环节赋予它自主权才合适。

智能体必须融入现有业务

当智能体需要与企业其他部分交互时,流程背景就显得更加重要。组织并非从一张白纸开始。一个客户请求可能已经在客户关系管理(CRM)系统、文档存储库、案件管理平台和企业资源规划(ERP)系统之间流转,同时还涉及多个部门的员工。

把智能体部署到这种环境中的某个环节,并不意味着整个流程就会自动变得更高效。智能体或许能完美完成自己的任务,但如果之后还需要员工把它的输出复制到另一个应用中、判断接下来由谁处理,或在其他地方手动重新启动流程,那么瓶颈只是转移了位置。

因此,企业应当把智能体视为更大流程中的参与者,而不是孤立的工具。是什么触发了智能体?它会接收哪些信息?它负责什么?完成任务后,工作会流向何处?如果它无法完成任务,又会发生什么?

随着组织引入多个专门化智能体,这些问题就显得更加重要。Deloitte已将编排列为企业迈向多智能体系统的一项关键要求;在这类系统中,不同智能体可以承担不同角色并协调工作。企业级编排还必须涵盖智能体之间如何沟通和协调,而不能只关注它们各自如何运作。如果缺乏这种监督,智能体就可能依据不完整的背景信息采取行动、触发相互冲突的操作,或绕过既定的业务规则和审批流程。智能体仍然运行在由现有应用、员工、业务规则和流程构成的组织环境中,而这些流程可能持续数天、数周或数月。

首先,明确需要完成的流程,并确定智能体、人员和现有系统各自在其中承担什么角色。智能体可能独立处理其中一个步骤,另一个智能体可能执行专门检查,员工可能作出判断,而现有系统则可能执行最终交易。关键在于,工作能够在各参与方之间流转,同时不丢失上下文。

自主性需要架构

为智能体提供更多结构,并不意味着每项操作都需要再加一道限制。事实上,情况可能恰恰相反。明确的流程可以让组织更有信心地确定智能体能够自主运作的范围,因为边界、例外情况和升级处理节点都已预先界定。智能体无需拥有不受限制的自由,也能创造切实价值。它需要足够的职责来推动工作向前,需要充分的上下文来判断接下来该做什么,也需要清楚知道何时应由其他方面接手。

更好的数据将继续提升智能体的能力。但仅有能力,并不足以让智能体在企业内部发挥作用。真正的考验在于:它能否在业务设定的边界内,于流程中的恰当时点采取正确行动。

Joram 是 Flowable 的核心开发人员,在开源软件领域拥有多年经验,并致力于构建可扩展的流程引擎。他共同创立了 Activiti 项目(Flowable 以该项目为基础),并担任核心开发人员超过六年。在此之前,他曾作为 jBPM 团队的一员受雇于 JBoss/RedHat。