CN110119404B - 一种基于自然语言理解的智能取数系统及其方法 - Google Patents

Abstract

本发明公开了一种基于自然语言理解的智能取数系统及其方法，包括用户自然语言交互模块、Search Engine、Schema Graph、Tokenizer、Tree Builder、SQL Generation，用户自然语言交互模块输送自然语言至外部分词器进行外部分段来分隔单词，Tokenizer识别每个分隔单词含义和将单词组合成短语，最终自动或与用户交互选择最佳组合和解释；Tree Builder根据Tokenizer内的节点序列构建Query Tree，SQL Generation则将Query Tree转化成SQL至数据库DB内、并反馈至用户自然语言交互模块内供用户参考，能够支持更多的问句形式和支持更丰富的复杂查询，运用更少的信息可以在没有与用户交互的情况下在MAS数据集上达到更高的准确度。

Description

一种基于自然语言理解的智能取数系统及其方法

技术领域

本发明涉及计算机科学领域，特别涉及一种基于自然语言理解的智能取数系统及其方法。

背景技术

数据库的自然语言接口为人们提供了一种更简单、更符合习惯的方式来访问数据库，即使是缺乏计算机专业知识的人也可以通过该接口，使用自然语言查询的方式，轻松获取数据库中的数据。使用这样的查询方式，用户既不需要掌握复杂的结构化查询语言(如SQL)，也不需要了解数据库的表结构，然而数据库自然语言的接口构建一直是个难题，目前最主流的解决方案有NaLIR、ATHENA等。

图1展示了NaLIR的系统架构，整个系统由三个主要部分组成：问句解析部分、交互式通信器和查询树翻译器部分。问句解析部分包含分析树节点映射器(parse tree nodemapper)和分析树结构调整器(parse tree structure Adjustor)，负责将自然语言查询解析成一颗查询树。交互式通信器(interactive communicator)负责与用户交流，来确保解析过程的正确性。被用户所确认的查询树会被查询树翻译器(query tree translator)翻译成SQL语句，然后由RDBMS(关系型数据库管理系统)执行。

图2展示了ATHENA的系统架构，假设用户提交了这样一个查询：“Show merestricted stock investments in Alibaba since 2012by investor and year”。第一步，NLQ引擎将确定这个查询对应至本体中的哪些元素。比如，片段“restricted stock”将被对看作是InstitutionalInvestment.type或是Holding.type属性的一个值。相似的，片段“Alibaba”可能指Company.name、一个InvestorCompany或者一个Lender。NLQ引擎会处理所有这些可能的对应关系，并生成符合条件的解释结果的列表，解释结果需要遵循本体结构和语法上的约束，对于每个解释结果，会生成相应的自然语言解释。

在查询被解释的过程中，NLQ引擎依赖于一个附属的服务，叫做翻译索引(Translation Index，TI)。TI为RS中的数据和元数据、本体中的概念、属性、关系提供了索引。比如，在上述例子中，NLQ引擎会在TI中搜索“Alibaba”这个词，“Alibaba”被映射至本体中的Company.name属性。而基于本体至数据库映射关系，TI会知道“Alibaba”是RS中保存的Company表name列中的一个数据值。当然，事实上“Alibaba”还对应着本体中的其他元素(InvestorCompany、Lender)，TI会获得“Alibaba”与数据库对象之间的所有关系。TI通过使用语义变体生成方案提供了强大而灵活的匹配功能。重要的是，通过TI索引的数据，ATHENA不仅可以索引准确的值，也可以支持某个值的不同别名。ATHENA提供了语义变体生成器(variant generator，VG)，对人名、公司名等有效。比如，给一个输入字符串“AlibabaInc”，公司名的VG会给出以下一些别名：f“Alibaba”,“Alibaba Inc”,“Alibaba Inc.”,“Alibaba Incorporated”}。这使得ATHENA的用户可以通过索引中值的任何别名准确的表达一个查询，TI在离线初始化阶段被构建，并由RS中的数据填充。

ATHENA的一个显著特点是两阶段方法的使用，这带来了模块间的物理独立性。通过对于本体的依赖和对于TI的利用，NLQ引擎对于RS中实际保存的数据毫不知情。为了支持这个两阶段方法，ATHENA在本体之上定义了一个中间查询语言，叫做本体查询语言(Ontology Query Language，OQL)。OQL扮演的角色是为上层模块带来独立性，使它们不需要依赖于底层的数据存储形式及目标查询语言。比如说，相同的查询解释(OQL)可以同时被应用于关系型存储或是图型存储之上。这篇论文聚焦于关系型存储，OQL将作为查询翻译器(Query Translator)的输入，用来生成相应的SQL查询，NLQ引擎产生的每一个解释都将被翻译成一个OQL查询。

针对上述NaLIR和ATHENA，依据存在缺陷和不足，具体如下：

对于NaLIR，1、过度依赖于dependency parser(依存解析器)的可靠性，当问句复杂、语义解析出现较大偏差时，通过之后的步骤也无法修补；2、当问句较长时，在随机调整这一步上，搜索空间太大，既带来了较大的时间成本，搜索结果也难保准确。

对于ATHENA，1、不支持嵌套型SQL的生成，因而支持的问句形式受限；2、不支持同一实体多次出现，因此无法支持一些复杂问句。

综上所述，这两种目前最具代表性的解决方案都存在不少问题，它们在处理复杂查询时往往力不从心，在某些特定情形也容易出错。

发明内容

针对现有技术存在的不足，本发明的目的在于提供一种基于自然语言理解的智能取数系统及其方法，能够支持更多的问句形式和支持更丰富的复杂查询，运用更少的信息可以在没有与用户交互的情况下在MAS数据集上达到89％的准确度(与NaLIR、ATHENA相同)。

本发明的上述技术目的是通过以下技术方案得以实现的：

一种基于自然语言理解的智能取数方法，包括如下步骤：

步骤1，用户输入搜索自然语言，外部分词器进行外部分段来分隔中文查询单词、并输送每个分隔单词至标记解析器Tokenizer内识别含义；

步骤2，标记解析器Tokenizer尝试识别每个分隔单词的含义，必要时将分隔单词组合成短语，最后将单词和短语映射到含有语义信息的节点上，所有的单词最初都会标记成UnknownNode节点类型；

步骤2.1，标记解析器Tokenizer首先解析与数据库不相关的节点，并配备一个词库用于识别这些类型的节点，为了解决同一个词在不同语境中有不同的含义，标记解析器Tokenizer允许编写识别规则，识别规则匹配的是句子中的节点，根据上下文解释单词；

步骤2.2，标记解析器Tokenizer第二步解析与数据库相关的节点，首先从词本身出发，从所有匹配和组合方式中，通过打分的方式找到最佳的匹配和组合方式，接着将最佳匹配所有的节点的所有映射全排列，得到所有可能的组合，并将每个组合映射到数据模型Schema Graph的节点上，对这些节点生成Steiner Tree，在所有的Steiner Tree中，权重最小的组合即为最终标记解析器Tokenizer的结果，如果依旧有多个结果，则随机选出一个，并将所有结果返回用户，如有误用户可以订正；

步骤3，将得到的节点序列转化成查询树Query Tree，查询树Query Tree的构建方式采用先局部建成小的子树，再合并的建树方法；

步骤4，将查询树Query Tree转化成结构化查询语言SQL至数据库DB内、并反馈至用户自然语言交互模块内供用户参考。

进一步优选为，所述在步骤2.2中打分选择最近匹配和组合方式过程中，得分的高低从以下四个方面考虑：被匹配项的字符应尽可能多的匹配、稀有被匹配项应具有更高的优先级、不要破坏原始分词、匹配的字符要连续。

针对上述的一种基于自然语言理解的智能取数方法，同时延伸出：

一种基于自然语言理解的智能取数系统，包括用户自然语言交互模块、搜索引擎Search Engine、数据模型Schema Graph、标记解析器Tokenizer、树生成器Tree Builder、结构化查询语言转化模块SQL Generation，所述用户自然语言交互模块输送用户搜索的自然语言至外部分词器进行外部分段将中文查询分成单词,所述标记解析器Tokenizer包含先后进行的数据库不相关节点解析和数据库相关节点解析、用于尝试识别每个单词含义以选择最佳组合和解释，树生成器Tree Builder根据标记解析器Tokenizer内的节点序列构建查询树Query Tree，所述结构化查询语言转化模块SQL Generation则将查询树QueryTree转化成结构化查询语言SQL至数据库DB内、并最终反馈至用户自然语言交互模块内供用户参考。

进一步优选为，所述标记解析器Tokenizer内数据库相关节点解析同时会反馈得分前5的解释至用户自然语言交互模块中供用户选择。

进一步优选为，所述标记解析器Tokenizer的映射节点类型主要包括AggregationNode、ConceptNode、PropertyNode、StringValNode、UnknownNode、GroupByNode。

在实际应用中，要求客户从他们的业务中构建复杂的知识图谱几乎是不可能的，由此本申请的系统与需要整个知识图谱的ATHENA不同，此系统仅使用知识图谱中的Concept(例如会议)，尽管系统中没有使用知识图谱中的Properties(例如名称)和Relation(例如引用)。尽管信息有限，我们仍然可以在没有与用户交互的情况下在MAS数据集上达到89％的准确度(与ATHENA、NaLIR相同)。

假设用户想要将以下问句提交给我们的系统：在VLDB中发表论文数量前十的作者。首先，系统会先调用外部分段来分隔中文查询单词，然后，标记解析器Tokenizer尝试识别每个单词的含义，必要时将单词组合成短语，最后将单词和短语映射到有意义的节点。

由于每个单词都可能有许多可能的解释，还有许多不同的短语组合，本申请系统会自动选择最佳组合和解释。另一方面，我们还为每个单词返回得分前5的解释，如果我们的系统给出错误的解释，我们的用户可以手动选择正确的。在实际使用中，我们总能给出正确的解释，用户几乎不需要做选择。

在下一步中，我们尝试根据给定的节点序列构建查询树，以便从数据库的角度获取语义。某些单词可能无法映射到任何节点，在构建查询树的过程中忽略这些单词。与现有技术中，首先通过Stanford Dependency Parser构建parse tree，然后将parse tree调整为合法的query tree的NaLIR相比，我们实现了一个基于规则的Tree Builder。在实践中，我们发现Stanford Dependency Parser生成的解析树非常不可靠，特别是在查询变得复杂时。通过调整原始parse tree来构造合法的query tree几乎是不可能的，但我们设计的Tree Builder可以克服Stanford Dependency Parser的上述问题。

最后，结构化查询语言转化模块SQL Generation将查询树Query Tree作为输入并将其转换为结构化查询语言SQL进行查询，考虑到不同数据库的结构化查询语言之间的差异，我们允许用户指定他们想要使用哪种结构化查询语言，这样我们的系统可以支持不同的结构化查询语言SQL执行引擎。

综上所述，本发明对比于现有技术的有益效果为：本申请的系统与需要整个知识图谱的ATHENA不同，此系统仅使用知识图谱中的Concept(例如会议)，尽管系统中没有使用知识图谱中的Properties(例如名称)和Relation(例如引用)。尽管信息有限，我们仍然可以在没有与用户交互的情况下在MAS数据集上达到89％的准确度(与ATHENA、NaLIR相同)；

相比于现有技术中，首先通过Stanford Dependency Parser构建parse tree，然后将parse tree调整为合法的query tree的NaLIR，我们实现了一个基于规则的TreeBuilder，在实践中，我们发现Stanford Dependency Parser生成的解析树非常不可靠，特别是在查询变得复杂时。通过调整原始parse tree来构造合法的query tree几乎是不可能的，但我们设计的Tree Builder可以克服Stanford Dependency Parser的上述问题。

附图说明

图1为现有技术NaLIR的系统框架；

图2为现有技术ATHENA的系统框架；

图3为实施例的系统框架；

图4为实施例中节点类型的说明表格；

图5为实施例数据库相关节点解析中事例的最佳匹配框架图。

具体实施方案

以下结合附图对发明作进一步详细说明。

一种基于自然语言理解的智能取数方法，包括如下步骤：

步骤1，用户输入搜索自然语言，外部分词器进行外部分段来分隔中文查询单词、并输送每个分隔单词至标记解析器Tokenizer内识别含义；

步骤2，标记解析器Tokenizer尝试识别每个分隔单词的含义，必要时将分隔单词组合成短语，最后将单词和短语映射到含有语义信息的节点上，所有的单词最初都会标记成UnknownNode节点类型；

步骤2.1，标记解析器Tokenizer首先解析与数据库不相关的节点，并配备一个词库用于识别这些类型的节点，为了解决同一个词在不同语境中有不同的含义，标记解析器Tokenizer允许编写识别规则，识别规则匹配的是句子中的节点，根据上下文解释单词；

步骤2.2，标记解析器Tokenizer第二步解析与数据库相关的节点，首先从词本身出发，从所有匹配和组合方式中，通过打分的方式找到最佳的匹配和组合方式，接着将最佳匹配所有的节点的所有映射全排列，得到所有可能的组合，并将每个组合映射到数据模型Schema Graph的节点上，对这些节点生成Steiner Tree，在所有的Steiner Tree中，权重最小的组合即为最终标记解析器Tokenizer的结果，如果依旧有多个结果，则随机选出一个，并将所有结果返回用户，如有误用户可以订正；

步骤3，将得到的节点序列转化成查询树Query Tree，查询树Query Tree的构建方式采用先局部建成小的子树，再合并的建树方法；

步骤4，将查询树Query Tree转化成结构化查询语言SQL至数据库DB内、并反馈至用户自然语言交互模块内供用户参考。

进一步优选为，所述在步骤2.2中打分选择最近匹配和组合方式过程中，得分的高低从以下四个方面考虑：被匹配项的字符应尽可能多的匹配、稀有被匹配项应具有更高的优先级、不要破坏原始分词、匹配的字符要连续。

针对上述的一种基于自然语言理解的智能取数方法，同时延伸出：

一种基于自然语言理解的智能取数系统，参照图3所示，包括用户自然语言交互模块、搜索引擎Search Engine、数据模型Schema Graph、标记解析器Tokenizer、树生成器Tree Builder、结构化查询语言转化模块SQL Generation和数据库DB。

用户自然语言交互模块输送用户搜索的自然语言至外部分词器进行外部分段来分隔中文查询单词、并输送每个分隔单词至标记解析器Tokenizer内识别含义，搜索引擎Search Engine为标记解析器Tokenizer识别每个分隔单词提供识别和搜索支持。

数据模型Schema Graph为关系数据库的无向图，其包含所有由一组字段组成的表、以及由外键-主键关联关系组成的边的集合并对关联关系边分配权重，其中较小的权重意味着更强的连接，具体解释如下：

关系数据库D＝(T，S)由一组表T和一组参照完整性约束S组成，每个表T_i由一组字段F_i组成，并且有一个(或几个)字段作为其主键。

我们已定义了Concept，它代表了本体中的概念，我们用C表示所有Concept。每个Concept C_i；必须通过一个函数M映射到一张特定的表和它的一组record上，M定义为：M:C_i→(T′，R)T′∈T，R表示T中的一组record，这组record包含C的所有实例并且没有重复。

标记解析器Tokenizer识别每个分隔单词含义和将单词组合成短语，并最终将单词和短语映射到含有语义信息节点上。由于为了从数据库的角度识别词语的含义，每个词，被映射到不同类型的Node，主要的节点类型(参照图4所示)主要包括AggregationNode、ConceptNode、PropertyNode、StringValNode、UnknownNode、GroupByNode，最初，所有的单词都标记为UnknownNode节点类型，标记解析器Tokenizer再试图将它们映射到含有语义信息的节点上。

其中一些类型的Node对立于要查询的数据库，另一部分则依赖于要查询的数据库，由此标记解析器Tokenizer包含通过编写识别规则根据上下文解释单词的数据库不相关节点解析、以及从所有匹配和组合方式中进行打分择优的数据库相关节点解析两个部分，同时数据库相关节点解析根据最佳匹配将所有节点的所有映射全排列得到所有可能组合、并将每个组合映射到数据模型Schema Graph节点上形成steiner tree。

针对上述数据库不相关节点解析和数据库相关节点解析，具体内容介绍如下；

标记解析器Tokenizer首先解析与数据库不相关的节点：

我们系统有一个词库配合使用，用于识别这些类型的节点。但是，在中文中，同一个词在不同的语境中有不同的含义，为了解决这个问题，我们实现了一个基于规则的标记解析器Tokenizer，允许我们编写识别规则，其语法就像正则表达式一样，可以根据其上下文解释单词。不像正则表达式，用来匹配字符，我们的规则匹配的是句子中的节点。以下是一个规则的例子，会将“每个“月”两个节点(词)解析成一个Groupby Node：

Any(text＝'每个)Unknown(text＝'月’)＝>Groupby(text＝'每月'，time＝MONTH)，其中，Any、Unknown、Groupby是节点的类型，括号中key＝value的形式是节点的属性；＝>符号左边为要匹配的内容，右边为替换左边的序列。此外，我们也支持类似正则表达中的group方法，获取＝>左边匹配到的内容。

标记解析器Tokenizer接着解析与数据库相关的节点：

识别数据库相关词语较为复杂，多张表的不同字段可以包含相同的值。例如，VLDB不仅是会议的名称，也是期刊的名称；其次，用户可能会采用缩写，不标准说法，使得查询的词和数据库的数据不是完全匹配，多个词可能会有多种组合方式。

例如，用户想查面杭州下沙证券营业部”，但是输入了“杭州下沙营业部”，该查询有三个词，相关的数据库数据有：“杭州下沙杭联热电有限公司”，“杭州下沙证券营业部”，“杭州金城路证券营业部”，“杭州下沙”(地区名称)，杭州下沙”(客户住址)，“营业部”(Concept)。所以我们需要一种算法，找到最好组合方式，抓住用户的意图。

标记解析器Tokenizer首先从词本身出发，从所有匹配和组合方式中，通过打分的方式，找到最佳的匹配和组合方式。这里不去考虑一个词可能属于多个表不同列，即不考虑词对应的数据库信息，仅考虑词本身，例如“杭州下沙融资余额的最佳匹配是“杭州下沙”+“期末融资余额”，而“杭州下沙”即可能是一个地区的名称，也能是一个客户的住址，在这里仅作记录，不去匹配。得分的高低从以下四个方面考虑：

1、被匹配项的字符应尽可能多地匹配；

2、稀有被匹配项应具有更高的优先级；

3、不要破坏原始分词，由此几乎不会发生分词错误；

4、匹配的字符要连续。

我们用“杭州下沙利息”为例来说明。首先标记解析器Tokenizer依赖于搜索引擎(例如Solr和Elastic Search)找到所有与输入查询相关的被匹配项，搜索到的被匹配项如下：“杭州下沙>杭州下沙”，”利息>当日利息”，”杭州->杭州黄龙”。接下来我们一个字一个字的匹配，每匹配一个字，会生成一个状态集，其中每个状态都有一个根据以上4条评分原则得到的得分。

参照图5所示，左侧从上到下为依次匹配的每一个字，每个字右侧为匹配该字得到的状态集。第一次匹配“杭”字，由两个候选项含有“杭”，于是得到两个状态。第二个字“州”，“杭州黄龙”一方面可以继续匹配老的候选项，另一方面可以匹配一个新的候选项“杭州下沙”于是生成两个状态。“杭州下沙”同理。但是(杭州黄龙，杭州下沙)这个状态不连续匹配，并且破坏了分词，于是得分很低，被删除。之后的字重复上述步骤，到“息“字最终得到三个结果，其中(杭州下沙，当日利息)得分最高，胜出进入后续步骤。

得到了最佳匹配，还需要解决同一个节点可以映射到不同列的问题。我们将所有节点的所有映射全排列，得到所有可能的组合，并捋每个组合映射到Schema Graph的节点上，对这些节点生成Steiner Tree。在所有的Steiner Tree中，权重最小的组合即为最终标记解析器Tokenize的结果。如果仍然有多个结果，则随机选出一个，并将所有结果返回用户，如果有误用户可以订正。

树生成器Tree Builder根据标记解析器Tokenizer内的节点序列构建查询树Query Tree，Query Tree是一个从数据库的角度表示查询语句的数据结构，树中的每个部分都和SQL的某些语句有着对应关系，是自然语言到SQL语句的桥梁。

用户最后问的问题，无外乎下面所列的三类：

1、直接问Concept或者Concept的统计结果，比如“男的客户”，“杭州的营业部”，“客户人数”，“最近三天融资金额前三的客户”；

2、问Property或者Property的统计结果，Property会属于某个Concept，比如“张三的身高”，“张三的融资金额和融券金额之和”，“张三最近三天的融资金额之和”；

3、问句中包含Concept之间的关系，比如“营业部是xx的客户”，“杭州的营业部的客户的持有的股票”。

鉴于现有技术NaLIR中，Standford Dependency Parser一次将全部全部句子建树的方法效果不佳，我们构思了局部建成小的子树，再合井的建树方法。我们使用规则构建小的子树，根据我们实践中的经验，子树的种类井不多，总共也就10种构建规则。规则如下(说明：＝>符号左边为要匹配的节点类型，右边为要生成的树，#1表示左侧匹配到的第一个节点，使用括号表示父子关系，括号左侧的节点为括号内节点的父亲)。

规则总共可以分为3类：第一类，聚合操作应用与某个Property之上；第二类，找出筛选条件(相当于SQL的Where语句)，比如“融资余额>20000”；第三类，找出涉及对某个Property进行排序的筛选条件，比如“客户人数前十”，由此最终构建了一个森林。

接下来需要将森林合井成为一个Query Tree。我们将一个查询中所有的ConceptNode都当作核心节点，按照一般汉语的语序，左边的内容修饰右边的内容，最右边的Concept Node是用户最终需要数据。所以，我们采用reduce的方法从左到右，依次将左边的Concept Node转化成右边Concept Node的子树，如果两个Concept Node中间有筛选条件，我们认为筛选是修饰右侧的Concept，将筛选条件转化为右侧Concept Node的孩子，从我们的经验来看，即使因为语序原因，偶尔出现筛选条件挂错父亲的情况，也不影响最终产生正确的数据。最后，如果查询中出现被动语态，需要将被动语态所在的Concept特别处理。

结构化查询语言转化模块SQL Generation则将查询树Query Tree转化成结构化查询语言SQL至数据库DB内、并反馈至用户自然语言交互模块内供用户参考。由于查询树Query Tree是按照Concept划分层级关系，所以在生产SQL时，一个Concept就是一个子查询，下面逐一介绍SQL的每个语句是怎么生产的：

1、From语句，找出当前Concept下所有的数据库相关的Node所涉及的表，将这些表全部加入From语句中。在Schema Graph中对这些表生成最小生成树，Steiner树的边生成Join条件；如果有子查询，则使用子查询的Concept与当前Concept在Schema Graph中生成Steiner树，作为Join条件；

2、Select语句，找出当前Concept下所有Property Node对应的数据库字段加入Select语句中，再将当前Concept的primary key加入Select.由于用户通常使用Concept的名称而不是ID来区别Concept的个体，所以还需要将表示Concept名称的字段加入Select。如果有子查询，则将子查询中所有Concept相关的字段(primary key，名称字段)Select出来；

3、Where语句，将Query Tree所有的ValueFilter和ColumnFiter翻译成Where语句；

4、Group By语句，如果当前Concept有GroupBy Node则将该GroupBy Node放入待group by队列。如果遇到Aggregation Node则将所有group by队列中的GroupBy Node全部添加进Group By语句。如果group by队列为空，则将最内层的Concept加入到Group By语句中。

进一步优选为，标记解析器Tokenizer内数据库相关节点解析同时会反馈得分前5的解释至用户自然语言交互模块中供用户选择。

在上述的技术中，存在着如下的替换技术：

1、在将自然语言分词阶段，可使用不同的分词器来进行分词，如Stanfordparser、HanLP等，分词器可在程序中直接调用或作为独立服务部署在云端；

2、可不使用Query Tree的形式作为中间结果，学习ATHENA使用00L等。

在实际应用中，要求客户从他们的业务中构建复杂的知识图谱几乎是不可能的，由此本申请的系统与需要整个知识图谱的ATHENA不同，此系统仅使用知识图谱中的Concept(例如会议)，尽管系统中没有使用知识图谱中的Properties(例如名称)和Relation(例如引用)。尽管信息有限，我们仍然可以在没有与用户交互的情况下在MAS数据集上达到89％的准确度(与ATHENA、NaLIR相同)。

假设用户想要将以下问句提交给我们的系统：在VLDB中发表论文数量前十的作者。首先，系统会先调用外部分段来分隔中文查询单词，然后，标记解析器Tokenizer尝试识别每个单词的含义，必要时将单词组合成短语，最后将单词和短语映射到有意义的节点。

由于每个单词都可能有许多可能的解释，还有许多不同的短语组合，本申请系统会自动选择最佳组合和解释。另一方面，我们还为每个单词返回得分前5的解释，如果我们的系统给出错误的解释，我们的用户可以手动选择正确的。在实际使用中，我们总能给出正确的解释，用户几乎不需要做选择。

在下一步中，我们尝试根据给定的节点序列构建查询树，以便从数据库的角度获取语义。某些单词可能无法映射到任何节点，在构建查询树的过程中忽略这些单词。与现有技术中，首先通过Stanford Dependency Parser构建parse tree，然后将parse tree调整为合法的query tree的NaLIR相比，我们实现了一个基于规则的Tree Builder。在实践中，我们发现Stanford Dependency Parser生成的解析树非常不可靠，特别是在查询变得复杂时。通过调整原始parse tree来构造合法的query tree几乎是不可能的，但我们设计的Tree Builder可以克服Stanford Dependency Parser的上述问题。

最后，结构化查询语言转化模块SQL Generation将查询树Query Tree作为输入并将其转换为结构化查询语言SQL进行查询，考虑到不同数据库的结构化查询语言之间的差异，我们允许用户指定他们想要使用哪种结构化查询语言，这样我们的系统可以支持不同的结构化查询语言SQL执行引擎。

以上所述仅是本发明的示范性实施方式，而非用于限制本发明的保护范围，本发明的保护范围由所附的权利要求确定。

Claims (5)

1.一种基于自然语言理解的智能取数方法，其特征是，包括如下步骤：

步骤1，用户输入搜索自然语言，外部分词器进行外部分段来分隔中文查询单词、并输送每个分隔单词至标记解析器Tokenizer内识别含义；

步骤2，标记解析器Tokenizer尝试识别每个分隔单词的含义，必要时将分隔单词组合成短语，最后将单词和短语映射到含有语义信息的节点上，所有的单词最初都会标记成UnknownNode节点类型；

步骤2.1，标记解析器Tokenizer首先解析与数据库不相关的节点，并配备一个词库用于识别这些类型的节点，为了解决同一个词在不同语境中有不同的含义，标记解析器Tokenizer允许编写识别规则，识别规则匹配的是句子中的节点，根据上下文解释单词；

步骤2.2，标记解析器Tokenizer第二步解析与数据库相关的节点，首先从词本身出发，从所有匹配和组合方式中，通过打分的方式找到最佳的匹配和组合方式，接着将最佳匹配所有的节点的所有映射全排列，得到所有可能的组合，并将每个组合映射到数据模型Schema Graph的节点上，对这些节点生成Steiner Tree，在所有的Steiner Tree中，权重最小的组合即为最终标记解析器Tokenizer的结果，如果依旧有多个结果，则随机选出一个，并将所有结果返回用户，如有误用户可以订正；

步骤3，将得到的节点序列转化成查询树Query Tree，查询树Query Tree的构建方式采用先局部建成小的子树，再合并的建树方法；

步骤4，将查询树Query Tree转化成结构化查询语言SQL至数据库DB内、并反馈至用户自然语言交互模块内供用户参考。

2.根据权利要求1所述的一种基于自然语言理解的智能取数方法，其特征是，在步骤2.2中打分选择最近匹配和组合方式过程中，得分的高低从以下四个方面考虑：被匹配项的字符应尽可能多的匹配、稀有被匹配项应具有更高的优先级、不要破坏原始分词、匹配的字符要连续。

3.一种基于自然语言理解的智能取数系统，用于执行如权利要求1所述的智能取数方法，其特征是，包括用户自然语言交互模块、搜索引擎Search Engine、数据模型SchemaGraph、标记解析器Tokenizer、树生成器Tree Builder、结构化查询语言转化模块SQLGeneration，所述用户自然语言交互模块输送用户搜索的自然语言至外部分词器进行外部分段将中文查询分成单词,所述标记解析器Tokenizer包含先后进行的数据库不相关节点解析和数据库相关节点解析、用于尝试识别每个单词含义以选择最佳组合和解释，树生成器Tree Builder根据标记解析器Tokenizer内的节点序列构建查询树Query Tree，所述结构化查询语言转化模块SQL Generation则将查询树Query Tree转化成结构化查询语言SQL至数据库DB内、并最终反馈至用户自然语言交互模块内供用户参考。

4.根据权利要求3所述的一种基于自然语言理解的智能取数系统，其特征是，所述标记解析器Tokenizer内数据库相关节点解析同时会反馈得分前5的解释至用户自然语言交互模块中供用户选择。

5.根据权利要求3所述的一种基于自然语言理解的智能取数系统，其特征是，所述标记解析器Tokenizer的映射节点类型主要包括AggregationNode、ConceptNode、PropertyNode、StringValNode、UnknownNode、GroupByNode。

Images