下载掌阅APP，畅读海量书库
立即打开
当今计算机已经渗透到人们工作和生活的方方面面。各行各业的人每一天都会接触到大量的计算机系统，小到穿戴设备，大到所乘坐的交通工具。计算机的功能越来越丰富，人们对计算机的需求范围也在不断扩大。随之而来的是计算机自身的复杂度和多样化程度越来越高，计算机的操作难度也逐渐增大，这样就需要更先进的人机交互技术。当前计算机的操作方式主要有以下两种。
1）命令行交互：命令行交互是一种通过命令行界面与计算机进行交互的方式。在命令行界面中，用户可以输入各种命令，从而控制计算机完成相应的操作。
命令行交互的优点在于，它可以让用户更加自由地控制计算机，不依赖于图形用户界面，而且可以更快速地完成一些操作。此外，使用命令行界面还可以在服务器等远程计算机上进行操作，而无须在远程计算机上安装图形界面。不过，命令行界面也有其缺点，例如需要记忆各种指令和参数，学习曲线较陡峭等。
2）图形界面交互：图形用户界面（Graphical User Interface，GUI）是一种用户与计算机交互的方式。与命令行交互不同，GUI使用图形化的界面，通过鼠标、键盘等输入设备进行交互。用户可以通过点击图标、按钮、菜单等元素来完成各种操作，如打开应用程序、管理文件等。
GUI具有易用性、直观性和用户友好性等优点，但往往需要更多的硬件和软件资源，并且开发成本也更高。
可以说，图形界面交互是取代命令行交互在人机交互技术领域的一次巨大飞跃。但是随着业务应用的发展和用户对交互操作便捷性与效率要求的进一步提高，图形化也面临很多应用难点。下面以蚂蚁集团支小宝项目为例进行介绍。
支小宝App的主要功能是为用户提供金融理财方面的信息咨询服务。在服务过程中，用户希望支小宝能从数据库中检索到相关数据，以回答自己关于金融理财方面的问题。这里就涉及复杂的人机交互。
图1-1是支小宝使用示例。根据线上用户的真实提问数据，人机交互的需求主要有单/多条件查询、排序、聚合、比较、嵌套等复杂操作，如图1-1所示。
图1-1 支小宝使用示例
如果按照传统的图形界面进行人机交互，我们需要根据不同的查询类型和过滤条件制作图形界面，例如在界面中添加一个下拉列表框，将基金类型为“混合中风险”的所有基金列出来，如图1-2所示。
但是用户在该应用中可能要用到的过滤条件与组合非常多，用户每一次查询自己想要的信息就要找到对应的列表项，过程会非常烦琐。尤其对手机App这类屏幕比较小的交互应用来说，该功能会因为需要在屏幕上显示大量的可操作控件而基本不能落地。
图1-2 过滤条件的选项框
为了解决图形界面交互在该类场景中效率低的问题，基于自然语言理解的语义解析技术应运而生，即用户可直接使用人类自然语言和计算机系统进行交互。
语义解析技术是实现自然语言理解的关键技术之一，旨在将自然语言转换为计算机可以理解的形式化语义表示。准确来说，所有将自然语言句子转化成计算机可识别的、可计算的、完全的语义表示的技术，如各种编程语言、Lambda表达式、SQL语句、语义图等都属于语义解析技术的研究范畴。语义解析的任务目标如图1-3所示。
应用在问答系统上的语义解析技术主要包括NL2SQL技术和知识图谱问答（KBQA）中的NL2SPARQL技术，它们的区别是：NL2SQL技术应用在表格问答系统上，回答问题的信息来源于表格；而NL2SPARQL技术应用在知识图谱问答系统上，通过SPARQL语言从知识图谱中查询到答案。其实知识图谱问答主要有两个实现的技术路线，分别是信息检索和语义解析，其中语义解析部分主要由NL2SPARQL技术组成。由于本书的内容是讲解语义解析技术在NL2SQL和KBQA中的应用，所以后文介绍的技术路线不包括KBQA中信息检索的部分，在介绍KBQA任务的技术路线时将以NL2SPARQL技术为主。
图1-3 语义解析的任务目标
虽然NL2SQL在企业问答系统中有大量的应用，但仍然存在大量的问题需要解决，例如NL2SQL的SQL结构难以预测、SQL关联难以预测、数据稀疏问题以及列之间的操作关系难以预测等。
（1）SQL的结构难以预测
该问题主要体现在SQL的语法为树形结构，但是深度学习模型的输出为矩阵结构上，两者难以建立一种映射关系。例如，SQL语句可能有多层嵌套，每一层嵌套含有不同的语法现象。
查询 ：有哪些公司收购或并购过其他公司？
对应的SQL语句如下：
该SQL语句的执行流程如图1-4所示。
在图1-4所示的树形结构中，如果前面的SQL子句更为复杂，树还会加深，此时模型的输出就没有很好的表达方式。
（2）SQL关联难以预测
查询 ：在排名公司各品牌收入的利润占比时，给出前3名对应的品牌的名称以及公司各品牌收入排名的营收占比。
对应的SQL语句如下：
图1-4 求并集操作
上述SQL语句中有多个关联列，我们需要预测多个列之间的关联关系。在上文所说的数据集中，只有外键关联才能作为关联列。实际上根据SQL语法，只要两个列的数据类型相同就是可以关联的。假设有两个表，各有10个列，就存在10×10=100种关联关系。关联关系还分左连接和右连接，这样关联方式就更多了，在预测的输出矩阵上不能很好地表示这种关联关系。
（3）数据稀疏问题
问题中所提到的列只占表结构中很少的部分，就我经历过的项目而言，一个表有几十上百列的情况并不少见，此时建模NL2SQL就会操作不了大部分的列。同时SQL中的语法类型较多，在数据集中会存在某一类语法的样本数占比较少，从而导致模型很难训练。例如，我们统计了百度语义解析竞赛中的语法分布，如图1-5所示。
从图1-5可以看到，intersect嵌套类型的SQL语句占比较少，这意味着相比value嵌套，模型较难学会intersect嵌套的语法现象。
图1-5 百度语义解析竞赛中的语法分布统计
（4）列之间的操作关系难以预测
SQL语法允许对列进行操作，但该操作较为复杂，来看一个示例。
查询 ：哪些城市平均每平方米部署的体育馆小于0.03个？给出这些城市所属的省份和实际体育馆分布密度。
在这个查询语句中，首先模型难以理解平均每平方米的体育馆是不是体育馆数量除以占地面积，这需要模型具备相关的先验知识。其次，多个列之间的操作在序列模型中很难输出，理由同样是列之间的关联关系难以预测。而主流的语义解析技术，为上述问题提供了较好的解决方案。