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



 写点什么

从 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 流程的信息，我们就可以通过所谓的“预触发“系统，预测哪些模型需要激活，哪些模型需要绕过。

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