写点什么

对话式人工智能发展的真正限制是人类的耐心

  • 2022-05-05
  • 本文字数:2141 字

    阅读完需:约 7 分钟

对话式人工智能发展的真正限制是人类的耐心

从 Siri 到 Alexa 再到谷歌助手,今天我们已经被各种人工智能系统包围了。它们的设计目标只有一个:理解我们。


我们已经看到了很多惊人的进展。在一瞬间数以千亿计的计算能力帮助下,最新的人工智能技术能够以人类水平的准确性理解某些类型的文本。然而,当目标文本属于一长段对话时,系统面临的挑战就变得更加艰巨,因为它需要考虑对话上下文来解释用户的意思并决定该如何回应。不过,像 Facebook 的 BlenderBot 2.0 这样的聊天机器人似乎预示着人类与人工智能的互动会流畅自然许多。


但问题在于:我们给这些对话式人工智能机器人增加的复杂性越多,就越难满足我们对实时响应能力的期望。BlenderBot 2.0 就是一个完美的例子。因为它突破了 BlenderBot 1.0 的许多关键局限(包括缺乏长期记忆),所以 2.0 版本比它的前辈要复杂得多。因此,要让幕后起作用的机器学习(ML)响应速度更快就更难了。

对话式人工智能和聊天机器人的速度限制


要实现自然流畅的对话是没有什么秘密可言的。它需要一个让人头疼的庞大 ML 模型网络,为了确定下一步应该回答什么内容,网络中每一个模型都要解决一小块难题。一个模型可能会考虑用户的位置,另一个模型会考虑到互动的历史,还有一个模型需要考虑到过去类似回应引起的反馈——每个模型都会给系统增加以毫秒计的宝贵延迟。


换句话说,对话式人工智能的真正限制是我们的耐心。

“依赖地狱”的深度


我们对人工智能的期望在学术背景下完全是另一码事。在学术背景下,我们为了结果可以等待几个小时甚至几天;而在现实环境中,我们要求系统立即做出反应。特别是对于对话式人工智能机器人来说,每一项潜在的改进都必须考虑到降低延迟的目标来进行权衡。


这种延迟是所谓的“关键路径“的产物,关键路径是指:从输入(用户的信息)到输出(机器人的反应)所需的最短 ML 模型链条序列。这是一个来自项目管理的古老概念,但在试图避免不必要的步骤这方面,它对今天的 ML 网络来说是非常重要的。


那么,你该如何找到关键路径呢?这一切都归结为依赖关系,长期以来,这一直是常规软件开发领域的一个决定性问题。对于任何一种由很多部分相互连接而成的软件架构来说,改进其中某一个应用程序都可能迫使工程师更新整个系统。但有时,对应用 A 来说至关重要的更新却与应用 B、C 和 D 不兼容。


这就是所谓的“依赖地狱“。如果不去特别关注细节的话,机器学习的依赖关系会让我们面对的地狱更加深邃黑暗。


正常的软件依赖项是基于 API 的,它传达了一个特定应用程序的简单、离散的状态,例如电子表格中的一个单元格从红色变为绿色。API 允许工程师在某种程度上独立开发每个应用程序,同时让它们保持在同一页面上。但对于 ML 的依赖项来说,工程师则要处理抽象的概率分布才行,这意味着我们很难搞清楚一个模型的变化应该如何影响更大范围的 ML 网络。只有掌握了这些模型之间的细微关系,我们才能让对话式人工智能成为现实——更不用说实时体验了。

通过跳过步骤来节省时间

为了充分了解对话式人工智能的依赖关系,你需要将机器学习与人类的直觉相结合在一起。


举个例子,我们的一个对话式人工智能机器人旨在回应员工的各种请求,比如说他们想要一个 PowerPoint 许可证,或是对 PTO 政策有疑问。事实证明,即使是看起来很简单的问题也会把你带入依赖地狱的深处。PTO 问题的答案可能深藏在员工手册的第 53 页,而且对于加拿大的销售人员和西班牙的工程师来说可能还是不一样的。此外你还要忽略很多不相关的细节(比如员工的夏威夷度假计划),所以你有几十个专门的 ML 模型,它们还必须作为一个整体来运作。


诀窍在于确定哪些模型——也就是关键路径中的哪些步骤——是解决每个问题所必需的。第一步是自然语言理解,或 NLU,其目标是将非结构化文本转化为机器可操作的信息。我们的 NLU 是一个由许多 ML 模型组成的管道,可以纠正错别字、识别关键实体、从噪音中分离出信号、弄清用户的意图,等等。有了这些信息,我们就可以开始在下游筛选出不必要的模型。


这意味着在分析公司现有的实际解决方案之前,预测出目标问题有哪些有益解决方案。一名要求使用 PowerPoint 的员工可能会用到软件许可或申请表格,但他们几乎肯定不想要新办公室的地图。只要能充分利用来自 NLU 流程的信息,我们就可以通过所谓的“预触发“系统,预测哪些模型需要激活,哪些模型需要绕过。


鉴于这一过程中所涉及的概率分布的抽象性质,我们的预触发系统既依赖于机器学习的输入,也依赖于人类专家基于直觉制定的规则。归根结底,把时间花在有意义的地方既是一门艺术,也是一门科学。

为对话式人工智能机器人的进步留出空间

没有人知道对话式人工智能在十年后会是什么样子。然而我们所知道的是,我们现在需要优化我们的聊天机器人,为未来的进步留出空间。如果我们想获得像人类对话一样的体验,我们就必须考虑整个系统的延迟,不能毫不顾忌地增加越来越多的复杂性。


与科幻小说相反,我们在人工智能领域看到的“突破“都是对现有模型和技术的许多小的、渐进式改进累加起来的产物。优化对话式人工智能的工作并不是为了影视作品里那种效果,成果也很难在一夜之间就爆发。但是,正是这些年的不懈努力——而不是几次天才般的思想火花——让聊天机器人能够实时理解我们的意图并帮助我们。


原文链接:


https://venturebeat.com/2022/02/23/why-the-true-test-for-todays-conversational-ai-chatbots-is-time/

2022-05-05 21:463277
用户头像
刘燕 InfoQ高级技术编辑

发布了 1112 篇内容, 共 540.0 次阅读, 收获喜欢 1977 次。

关注

评论

发布
暂无评论
发现更多内容

十八般武艺玩转GaussDB(DWS)性能调优(二):坏味道SQL识别

华为云开发者联盟

数据库 sql 性能调优 GaussDB 算子

架构师训练营第六周课后练习

薛凯

Double Kill!! 数据联邦修炼之路

脑极体

数据库JDBC:Statement查询

正向成长

JDBC sql查询 SQL光标

第二周总结

Griffenliu

玩转华为云开发|老板万万没想到:刚入职的我一人就搞定人脸识别开发

华为云开发者联盟

软件开发 模块化流程 人脸识别 API 华为云

Week2 - 框架设计

evildracula

学习 架构

第二周作业

Griffenliu

架构师训练营第 1 期第 6 周作业

好吃不贵

极客大学架构师训练营

架构师训练营 1 期第 6 周:技术选型(二) - 作业

piercebn

极客大学架构师训练营

架构师训练营第二周作业

邢永春

全网首发,做第一人纯源码讲解RabbitMQ实践,收藏吧

小Q

Java 学习 架构 面试 RabbitMQ

【Java】变量声明在循环体内还是循环体外你选哪一个咧?

root

Java 变量声明

阿里五位MySQL封神大佬耗17个月总结出53章性能优化法则

996小迁

Java MySQL 大数据 架构 面试

架构师训练营 W02 作业

Geek_f06ede

架构师训练

RabbitMQ之路由和通配符模式,附源码注释讲解

小Q

Java 学习 架构 面试 RabbitMQ

架构师训练营第二周学习总结

邢永春

使用抓包工具fiddler和apipost进行接口测试

测试人生路

测试工具 fiddler

架构训练营-week6-学习总结-技术选型(二)

于成龙

架构训练营

架构训练营-week6-作业

于成龙

CAP 架构训练营

Java程序员必会的三个技能:Spring+MySQL+并发编程

Java架构师迁哥

架构师训练营第 1 期第 6 周学习总结

好吃不贵

极客大学架构师训练营

云小课|云数据库RDS实例连接失败了?送你7大妙招轻松应对

华为云开发者联盟

数据库 网络 ssl RDS实例 端口

第1周 架构方法-作业

SuGeek

第六周作业

alpha

极客大学架构师训练营

LeetCode题解:78. 子集,迭代,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

渣渣2本学历CRUD一年半,决定改变现状,努力学习两个月成功拿到美团30k offer

Java架构之路

Java 程序员 架构 面试 编程语言

架构师训练营 W02 总结

Geek_f06ede

架构师训练

第五周作业

icydolphin

极客大学架构师训练营

一个90后码农的真实经历,希望大家可以不留遗憾;

Java架构师迁哥

第六周

等燕归

对话式人工智能发展的真正限制是人类的耐心_AI&大模型_Jiang Chen_InfoQ精选文章