自然语言用户界面只是一种用户界面

假设您正在编写一个应用程序，并希望为其添加对话式界面：用户输入某些命令，应用程序在可能需要请求澄清后执行相应操作。

这项技术涉及许多术语——对话式商务、机器人、智能代理等。我认为将其称为语言用户界面（LUI）更为清晰，类似于可以为同一应用程序附加的图形用户界面（GUI）。

想象您的应用程序配备GUI，是避免对"智能代理"产生模糊思维的良好方法。您仍然需要将UI与底层应用程序连接，而底层应用程序的概念模型仍将在整体用户体验中发挥主导作用。

用户的文本如同点击 假设您有一个简单的应用程序，能够执行四个功能：

check_weather()：显示当前天气和明日预报 check_calendar()：显示今日日程安排 call_mom()：给母亲打电话 tell_joke()：讲一个老套的笑话

想象从头开始为此应用程序编写GUI。用户移动光标并点击。每次点击时，您会获得一对数字，代表光标位置。因此，每个用户操作都为您提供一个包含两个实数值的向量。应用程序知道其四个按钮的边界框。对于每个向量，您检查该点是否落在某个按钮的边界内。如果是，则触发按钮按下动画，并执行相应功能。

要从头编写LUI，我们必须获取用户的文本并将其解析为数字向量。我们必须确定用户"点击"了"哪里"。通常我们将每个单词映射到任意ID。如果我们识别5000个单词的词汇表，可以将每个单词视为5000维空间中的不同点。然后将此空间缩减到更密集的空间，比如300维。这使我们能够将文本解析为可管理的意义向量。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

word_to_value = {
    'show': 0.1, "what's": 0.3, 'check': 0.3, 'tell': 0.4, 'call': 0.7,
    'news': 0.3, 'weather': 0.3, 'joke': 0.1, 'mom': 0.9
}

def get_coords(text):
    values = []
    for word in text.split():
        if word in word_to_value:
            values.append(word_to_value[word])
    return (values[0], values[-1]) if values else (0.0, 0.0)

为说明这一点，让我们识别少量词汇，并为每个单词分配实值。要将用户的文本映射到二维空间，我们将识别的第一个单词作为x坐标，最后一个识别的单词作为y坐标。

上述简单函数让我们将用户文本的"含义"表示为两个实数值对：

通过绘制这些值并为我们的"按钮"——应用程序的操作——提出一些边界，我们可以完成LUI和GUI之间的类比。

使用GUI时，确定点击坐标没有问题，您永远不需要考虑将点击事件解析到特定按钮（如果有）。这些事情会自动发生——为您处理好了。使用LUI时，您必须注意这些细节。您可以在这方面做得更好或更差，但"黄金标准"——您所有机器学习工作的圣杯——只会给您一些在GUI中一直认为理所当然的东西。

当然，您拥有一个更大、多维的画布，用户可以在上面"点击"，每次点击可以为您提供丰富结构化的数据。但您仍然需要在此画布上绘制按钮、表单、导航菜单等。您仍然将UI连接到某些固定的底层功能集。

考虑以下对话：

“您好！今天我能为您提供什么帮助？” “我正在寻找汽车保险。” “您是现有保单持有人吗？” “不，这是我的第一辆车。”

假设在底层，用户的最终话语触发函数car_insurance.non_holder.tell()，该函数打印大量文本。这里的LUI为用户提供了一个分层菜单，其选项由底层域确定。在GUI设计中，嵌套菜单带来的问题是众所周知的，很容易想象LUI会出现类似问题。

如果您位于嵌套菜单的顶部，如何知道树的叶子是什么？如果您知道需要特定的叶子，如何可靠地猜测如何导航到它？LUI提示为您提供更多文本，因此上下文有时可能更清晰。另一方面，可用选项范围并不总是被枚举，您的意图可能会被错误分类。

这里的重点是语言用户界面（LUI）只是一个界面。您的应用程序仍然需要概念模型，您肯定仍然需要将该概念模型传达给用户。因此，问自己：如果这个应用程序有GUI，那个GUI会是什么样子？

Siri的GUI版本可能会给您一个主屏幕，其中包含多页表单元素，每个元素对应Siri的一个子应用程序。还会有一个长按钮列表，用于触发Siri的原子"彩蛋"功能。请注意，Siri的GUI不会简单是iOS的主屏幕。如果是这样，那么Siri会将您的话语映射到触摸事件和用户输入序列。

当您说"告诉我妈妈我爱她"时，Siri执行命令sms(“my mother”, “I love her”)。它绝对不会执行一系列用户操作，以您的方式"驾驶"您的iPhone。尝试这样做将是疯狂的。Siri只是一个应用程序，具有您可能想要执行的操作的概念模型。它通过LUI而不是GUI向您暴露这些操作。

昨天我们不能做什么？ 我认为准确理解新的和改进的AI技术正在开辟哪些机会非常重要。LUI现在可行，因为您可以期望能够捕获用户的"点击"并相当准确地将其解析到正确的操作。您现在可以期望很好地解释用户的文本。这是新的，机会很有趣。但机会也比许多人似乎认为的要狭窄得多。

我认为LUI对于填写复杂表单特别有用，其中有许多很少使用的参数。然而，我想要越精确，使用自然语言的热情就越低。我的自然语言查询将被映射到数据库查询，而我查询的表的结构是预先确定的。表的结构对我隐藏既好又坏。

优点是表的结构可以改变，而我不必改变与UI的交互。缺点是我被欺骗了——我被迫在泄漏的抽象上与应用程序交互。

可能如果我想找到附近有WiFi和素食选项并在晚上10点后营业的咖啡馆，我会很兴奋使用自然语言界面。如果我要预订飞往澳大利亚的航班，我宁愿打开笔记本电脑填写网络表单。

除非您将用户的指令编译成代码并评估它（我不建议这样做！），否则LUI不会引入任何额外的表达能力。语言用户界面和图形用户界面都是……用户界面。

语言界面可能更好，也可能更差。这取决于设计，您的成功将与您尝试构建的应用程序密切相关。问题是我们设计LUI的经验要少得多，用户使用它们的经验也要少得多。

我的预测是，为构建具有语言用户界面的应用程序的人将具有强大的后发优势。关于UI设计的经验教训需要重新学习，使用假设文化必须积累。同时，我期望LUI最适合相对简单的应用程序，这些应用程序热衷于降低成本并依托流行平台。

换句话说，我认为LUI最适合进行小额投资的小型团队。如果您有一个大胆的计划，并且您的雄心包括为您的应用程序提供"独特的用户界面"，您应该小心您的愿望。这就像希望生活在有趣的时代。