自然语言用户界面的技术本质与实现

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

假设正在开发一个具有对话界面的应用程序：用户输入指令，应用程序执行相应操作，有时会在执行前请求澄清。

这项技术有许多相关术语——对话式商务、机器人、智能体等。通过类比可附加到同一应用程序的图形用户界面(GUI)，将其称为语言用户界面(LUI)会更加清晰。

用户文本如同点击事件

假设有一个简单的应用程序，能执行四个功能：

• 查看天气(): 显示当前天气和明日预报
• 查看日历(): 显示今日日程
• 呼叫母亲(): 给母亲打电话
• 讲笑话(): 讲一个老套笑话

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

编写LUI时，需要将用户文本解析为数字向量，判断用户"点击"了何处。通常将每个单词映射到任意ID，若识别5000个单词的词汇表，可将每个单词视为5000维空间中的不同点，然后将该空间压缩到更密集的空间（如300维），从而将文本解析为可管理的含义向量。

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)

此简单函数将用户文本的"含义"表示为两个实值对：

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

界面设计的核心挑战

使用GUI时，确定点击坐标毫无困难，无需考虑将点击事件解析到特定按钮。这些自动完成。而使用LUI时，必须关注这些细节。虽然可以做得更好或更差，但"黄金标准"——所有机器学习努力的圣杯——只能提供GUI中一直视为理所当然的东西。

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

考虑以下对话：

你好！今天能帮你什么？ 我想找车险 你是现有保单持有人吗？ 不，这是我的第一辆车

假设在底层，用户的最终话语触发car_insurance.non_holder.tell()功能，输出大量文本。此处的LUI为用户提供分层菜单，其选项由底层域确定。在GUI设计中，嵌套菜单带来的问题众所周知，很容易想象LUI的类似问题。

技术实现与局限性

LUI现在可行，因为可以合理准确地捕获用户的"点击"并将其解析到正确操作。现在可以很好地解释用户的文本。这是新的，机会有趣，但也比许多人想象的要狭窄得多。

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

优势是表结构可以改变而无需改变与UI的交互。劣势是用户被欺骗——被迫在泄漏的抽象层上与应用程序交互。

应用场景与展望

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

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

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