人工智能工具是否足够可靠,能够胜任商业环境中的重任?

更重要的是,我们是否应该赋予它们决策的“自主权”?根据《金融时报》的最新报道,亚马逊云计算部门近期发生的至少两起互联网停机事件,据称正是由笨拙的人工智能代理程序引发的。这些事件正将上述疑问推向风口浪尖。

打开网易新闻 查看精彩图片

去年12月发生了一起严重的事故。据四名知情人士透露,亚马逊网络服务的工程师当时允许其内部研发的名为基罗的“代理型”编程工具进行系统更改,结果引发了长达13个小时的服务中断。这台人工智能在命运的捉弄下,竟然作出了“删除并重建环境”的极端决策。

亚马逊的员工声称,这并非人工智能工具首次引发服务中断。“过去几个月里,我们已经目睹了至少两起生产环境停机事故,”亚马逊网络服务的一名高级员工在接受《金融时报》采访时表示,“工程师们让助手程序在无人干预的情况下解决问题,虽然停机规模不大,但完全是可以预见的。”

亚马逊网络服务于去年7月推出了内部编程助手基罗。公司将其描述为一个“自主型”代理,能够协助项目“从构思到投产”的全过程。而在此前的一起停机事件中,亚马逊开发的另一款被定义为人工智能助手的编程工具也牵涉其中。

打开网易新闻 查看精彩图片

据内部员工透露,这些人工智能工具被视为操作员权力的延伸,并被赋予了操作员级别的权限。在两起停机事故中,相关工程师在最终落实更改前均未按惯例要求第二人进行审核,这种做法违背了典型的操作规程。

在给《金融时报》的一份声明中,亚马逊声称停机只是“极其有限的事件”,仅影响了部分地区的单一服务。公司辩称,人工智能工具的介入纯属“巧合”,并表示“任何开发工具或手动操作都可能发生同样的问题”。

亚马逊还强调,其基罗工具在采取任何行动前都会“请求授权”,但去年12月事故中的工程师拥有比平时更高的权限。公司认为这是一个“用户访问控制问题,而非人工智能自主权问题”。亚马逊坚称:“在这两起案例中,错在用户,而非人工智能。”

打开网易新闻 查看精彩图片

亚马逊同时声称,没有证据表明人工智能工具更容易出错。对此,我们不禁要反问:亚马逊是生活在真空里吗?虽然人工智能及其在商业领域的探索尚处于萌芽阶段,但已有大量证据表明这些工具极易发生故障。它们产生“幻觉”——即凭空捏造事实的倾向已是众所周知,其安全护栏的脆弱性也备受诟病。甚至一些亚马逊自己的员工也告诉《金融时报》,由于担心出错风险,他们并不乐意使用这些人工智能工具。

资深程序员发现,人工智能编程助手经常吐出漏洞百出的代码。多项研究表明,由于需要对这些存疑的输出进行频繁的双重甚至三重检查,软件工程师的工作效率实际上被拉低了,尽管从表面上看,人工智能产出代码的速度确实更快。随着所谓“情绪编程”概念的兴起,由于人工智能代理作出了所有者意料之外的决策,类似的低级错误层出不穷。

打开网易新闻 查看精彩图片

诚然,如果科技巨头自己都不在业务中使用这些号称能极大提升生产力的工具,那显然缺乏说服力。目前,这些公司似乎都在“近水楼台先得月”。微软和谷歌均吹嘘其超过四分之一的代码现在由人工智能编写。安特罗皮克和人工智能开放世界的工程师甚至暗示,他们近乎100%的代码都出自人工智能之手。

亚马逊将停机事故轻描淡写地归结为简单的“用户错误”而非“人工智能错误”,这显得十分滑稽。毕竟,代码是由人工智能生成的。而且,亚马逊及其竞争对手一直在持续告知员工和客户,他们应该更深地依赖这些工具。

打开网易新闻 查看精彩图片

员工告诉《金融时报》,公司设定了一个目标,要求80%的开发者每周至少使用一次人工智能进行编程任务。这无异于一项硬性的强制命令。然而一旦人工智能出了偏差,责任永远在员工身上,而不在工具本身,更不在那些推波助澜的高层手中。

就目前所知,新披露的人工智能失误与去年10月导致“半个互联网”瘫痪的亚马逊网络服务大规模停机事故并无关联。但鉴于这些新披露的细节,以及该公司对人工智能工具日益沉重的依赖,人们不由得怀疑:在那场灾难中,人工智能是否也曾在某个环节扮演了不光彩的角色。

打开网易新闻 查看精彩图片