生成查询答案

已发表: 2022-05-05

这项最近授予的谷歌专利通常与生成查询答案有关,并且该专利还引入了约束的概念来帮助回答查询。

对查询答案使用约束

该专利询问与添加问题的实体的事实相关的内容的问题。

有关使用约束进行查询回答的文档如下:

    GRIP:图查询缺失答案的基于约束的解释
    使用约束满足的问答:QA-by-Dossier-with-Constraints

有趣的是,第一份文件引用了 Google 知识库作为参考。 可能是因为它专注于通过使用约束来获得问题的正确答案。

由于该专利非常关注语义搜索引擎优化。 它让我想起了与该主题有关的其他 Google 专利,包括这两项,值得仔细阅读:

  • 谷歌知识图对账
  • Google 知识图的实体提取

该专利提供了一些关于实体和实体属性如何工作、如何在图形搜索中使用元组以及对语义 SEO 的看法。

通过提供来自数据库的事实来生成查询答案

搜索系统可以通过提供来自数据库的事实来生成对事实查询的响应。

这些事实可能会存储在可以实时更新的图表中。

此类响应可能会被格式化为搜索结果列表而不是句子。

当用户提出一个事实性问题时,例如,通过语音向对话系统提出问题时,可能希望对问题有一个自然的响应。

最自然的响应可能是将答案表述为满足用户问题以提供查询答案的事实的语法陈述。

因此,根据本专利中描述的主题的一个一般方面,响应于事实查询,存储在数据库中的事实被转换成用户语言的句子。

接收识别实体属性的查询答案

本说明书中描述的主题的一个方面可以体现在包括接收标识实体属性的查询的动作的方法中。 这些属性是关于实体的事实。

然后,这些操作包括访问基于实体属性的查询答案的候选模板。 每个候选模板都有字段; 其中每个区域与至少一个约束相关联。

然后,这些动作包括获得一组提供查询答案的信息并从候选模板集合中选择一个模板。 所选择的模板具有最重要的字段数量,这些字段具有满足信息集的约束。

与实体相关的语义三元组

该组信息可以是一组实体-属性-值三元组。

动作还包括通过将信息集添加到所选模板的字段来生成短语,使得词包括查询答案。

短语是一个句子或句子的一部分。 最后,这些动作包括将单词传达给客户端设备。

短语可以作为与单词对应的音频信号来传达。

约束可能包括:

  • 类型约束
  • 时间约束
  • 性别限制
  • 关系约束
  • 单数/复数约束
  • 度量单位约束
  • 行列式约束。

一些实现涉及获取响应于查询中的单个属性的多组信息。

这些行动还包括:

  • 根据实体的类型获取句子模板,该句子模板包括多个短语字段
  • 将短语添加到句子模板的字段以形成句子
  • 从候选模板集中为每组信息选择一个模板
  • 通过将相应的信息集添加到相应所选模板的字段中,为每个所选模板生成一个短语
  • 将包括短语的句子传达给客户端设备

这可能涉及包含许多属性的查询答案。

  • 接收标识实体的许多属性的查询答案
  • 为实体的每个属性访问一组基于实体的相应属性的查询答案的候选模板
  • 为实体的每个属性获取一组回答查询的相应部分的信息
  • 从相应的候选模板集中选择一个模板
  • 通过将相应的信息集添加到所选模板的字段中,为实体的每个属性生成一个短语
  • 根据实体的类型获取句子模板,该句子模板包括多个短语字段
  • 将短语添加到句子模板的字段中以形成句子
  • 将包含短语的句子传达给客户端设备

此过程的优点包括:

该系统是可配置的并且可扩展到复杂的事实断言和答案。
它可以允许将实际数据库与句子生成机制完全分离。
它可以允许通过任何合适的方法添加新模板。

该生成查询答案专利位于

生成查询答案
发明人:Engin Cinar Sahin、Vinicius J. Fortuna 和 Emma S. Persky
受让人:谷歌有限责任公司
美国专利:11,321,331
授予:2022 年 5 月 3 日
提交日期:2018 年 7 月 23 日

抽象的

服务器接收标识实体属性的查询答案。

服务器访问一组候选模板以基于实体的属性回答查询,每个候选模板具有字段,其中每个字段与至少一个约束相关联。

服务器获取一组信息和查询答案,并从该组候选模板中选择一个模板。

所选模板的字段数最多,且信息集满足约束条件。

服务器通过将信息集添加到所选模板的字段来生成短语,使得该短语包括对查询的回答。

最后,服务器将短语传达给客户端设备。

将事实从数据库转换为句子

当用户提出事实问题时,搜索引擎可以通过访问数据库来提供查询答案。

一些系统,例如基于语音的对话系统,允许用户将查询计划为自然语言问题(例如,“谁是日本总统?”)。

在这种情况下,可能希望以句子的形式提供自然语言答案,而不是格式化为引用文档的搜索结果的答案。

因此,本规范中描述的系统可以将数据库中的事实转换为句子。 例如,这可能是有利的,使得答案可以作为语音返回给用户。

为了生成回答用户问题的句子,可能需要从数据库中检索随机事实。 但事实并不是随机的——它们使用约束信息来提供查询答案。 这似乎意味着更好地回答有关实体的查询。

为了回答诸如某人结婚之类的查询,系统可能会获取包括所有过去婚姻、参与过去婚礼的人、结合日期和婚姻协议类型的数据。 使用图形结构表示事实的灵活数据库可以提供这些事实。

访问候选模板以根据一个或多个属性生成查询答案

一旦收集了事实,答案引擎就可以访问候选模板,以根据查询中提供的一个或多个属性生成答案。 例如,如果最初的问题是“伍迪艾伦嫁给了谁”,那么重点可能是“婚姻”。 如果实际查询是“伍迪艾伦多大了”,则属性可能是“年龄”。 如下所述,问题的每个点可以对应于多个候选模板,例如,以支持或多或少详细的答案。

例如,如果属性是“年龄”,那么答案引擎可以获得一个包含出生日期和年龄的模板(例如,{<entity> 出生于 <date> 并且当前是 <value> 岁}),一个模板仅包含年龄(例如,{<entity> 当前为 <value> 岁})和包含出生日期和死亡日期的模板(例如,{<entity> 出生于 <date> 并死于 < /日期>})。

如以下更详细描述的,包含在“< >”中的模板部分(即,字段)可能与它们可以保存的数据的各种约束相关联。

一旦答案引擎获得候选模板,它会根据多个启发式方法选择最相关的模板,并通过将事实插入模板来生成句子。 然后,答案引擎可以将更正的答案提供给用户。

一种数据图搜索系统

系统可能习惯于使用这里描述的技术来实现数据图的搜索引擎。

系统被描述为用于处理来自客户端的查询请求的数据图的搜索引擎系统。 可以使用相关技术的其他配置和应用。 例如,查询请求可以源自另一个服务器、批处理作业或与数据图搜索系统通信的用户终端。

数据图搜索系统可以包括索引系统、搜索系统和索引集群。 索引系统、搜索系统和索引集群可以是采用若干不同设备形式的计算设备,例如标准服务器、一组这样的服务器或机架服务器系统。

此外,索引系统、搜索系统和索引集群可以在个人计算机中实现,例如膝上型计算机。

数据图搜索系统可以包括基于图的数据存储。 这样的数据图存储节点和边,可以从中创建图。

节点可以称为实体,边可以称为两个实体之间的关系。 这种关系可以通过多种方式存储。

在一个示例中,基于图的数据存储存储表示实体和关系的三元组。

表示实体和关系的三元组

三元组还可以包括一个格式,实体表示起始实体,点表示相关实体的特征,作为从实体重新定义的边,值表示相关实体。

三元组的一个例子是实体 Woody Allen 作为主语(或实体),关系作为谓词(或属性),实体 Annie Hall 作为宾语(或值)。

当然,具有许多实体甚至有限数量关系的数据图可能有数十亿个三元组。

索引系统可以包括被配置为执行机器可执行指令或软件、固件或其组合的处理器。

查找查询答案

搜索系统可以包括从客户端的用户接收查询并将那些查询提供给搜索系统的服务器(未示出)。

搜索系统可负责搜索数据图和其他数据源,例如来自互联网或内联网的文档语料库,以响应查询。

例如,搜索系统可以从客户端(例如客户端)接收查询,执行一些查询处理,并将查询发送到索引集群和存储用于搜索其他源的索引的其他索引集群。

搜索系统可以具有编译来自所有来源的结果并将编译结果提供给客户端的模块。

搜索系统可以只向索引集群发送查询,并且可以将来自索引集群的搜索结果提供给客户端。

搜索系统可以通过网络与客户端通信。

查找查询答案的索引簇

该系统还可以包括索引集群。 索引集群可以是单个计算设备或具有计算设备的分布式数据库系统,每个计算设备都有自己的处理器和内存。

组成索引集群的计算设备的数量可能会有所不同,为了简洁起见,索引集群被显示为单个实体。

每个索引集群可以包括被配置为执行机器可执行指令或软件、固件或其组合的处理器。

计算集群可以包括操作系统(未示出)和计算机存储器,例如主存储器,其被配置为临时、永久、半永久地或它们的组合存储多条数据。

存储器可以包括以处理器可以读取和执行的格式存储信息的任何类型的存储设备,包括易失性存储器、非易失性存储器或其组合。

访问索引以检索响应于查询的结果的查询解析器

索引集群还可以包括访问索引以检索响应于查询的结果的模块,例如查询解析器。

查询解析器也可能是搜索系统的一部分,或者可能分布在搜索系统和索引集群之间。

越来越复杂的查询和查询答案

一个涉及一个属性(“年龄”)并产生一个三重答案的简单查询。

一个简单查询的示例,它涉及一个属性(“婚姻”),但会产生多个三重答案。

涉及两个属性(“家乡和母校”)并导致多个三重答案的复杂查询示例。

一个生成句子以响应事实查询的示例系统。

该系统包括客户端设备、搜索系统、索引集群和答案引擎。

实体可以作为系统的一部分来实现。

用户使用客户端设备发起具有查询词的查询。

用户可以将原始查询格式化为句子。

与基于语音的对话系统交互

用户可以使用基于语音的对话系统与客户端设备交互。

例如,用户可以向客户端设备的麦克风说出查询“伍迪艾伦多大了”。

客户端设备然后可以执行语音识别以将话语转换为转录,然后将转录传输到搜索引擎。

或者,客户端设备可以发送对话语进行编码的音频语音数据。

搜索系统从客户端设备接收查询(例如,“伍迪艾伦几岁”)。

如果查询被编码为音频语音数据,则搜索系统可以将音频语音数据转换为转录。

然后搜索系统将原始查询解析并格式化为 <entity; 属性> 格式(例如 <woody Allen/age<),例如使用合适的自然语言解析引擎。

然后搜索系统将格式化的查询发送到索引集群。

索引簇访问索引以检索响应于查询的结果。

以三元组的形式查询答案

这些结果可能是一组三元组形式的事实信息(例如,</woody><woody Allen/born on/Dec. 1,>

然后索引簇传输格式化的查询(例如,</woody><woody Allen/age> 和回答查询的事实信息(例如,</woody><woody Allen/born on/Dec. 1, 1935>)到答案引擎。

使用格式化的查询和事实信息,答案引擎然后以一个或多个句子的形式生成答案。

答案引擎生成的答案如下。 首先,答案引擎从格式化的查询中获取一个或多个属性。

然后,答案引擎使用一个或多个属性来访问来自模板数据库的候选句子或短语模板。

接下来,答案引擎基于事实信息和与候选模板相关联的各种约束来选择模板之一。

最后,答案引擎使用事实信息填写所选模板中的字段。

获取一个或多个属性的应答引擎

更详细地说,答案引擎首先通过解析查询从格式化查询中获取一个或多个属性。 例如,假设查询被格式化为 <entity/attribute> 对,答案引擎会提取该对的属性部分。

在某些情况下,格式化查询可能包含多个属性。 例如,格式化查询可以是<entity/attribute/attribute>的形式。 在这种情况下,答案引擎可以从查询中提取每个属性。

接下来,答案引擎从模板数据库访问查询中每个属性的候选模板。

每个模板可以对应于完整的句子或句子的一部分(例如,短语)。

每个模板都包含可以插入事实信息的字段(显示为“< >”括号中的部分)。

例如,模板可能是“在 <date>,<entity> 与 <value> 结婚”。 模板可以手动或算法生成。

用户语言的候选模板

答案引擎识别用户的语言并选择用户语言的候选模板。

例如,答案引擎可以从搜索引擎接收指示原始查询语言的数据。 有利地,这样的配置可以促进答案的国际化。

字段可能与管理每个字段可能包含的数据的约束相关联。

如在本说明书中使用的,符号“<X/Y>”表示具有“X”约束和“Y”约束的字段。

样本约束可以包括类型约束、时间约束、性别约束、关系约束、单数/复数约束、度量单位约束和行列式约束。

不同的约束可能需要不同的数据类型

类型约束可能需要特定类型的数据,例如,<date> 约束可能需要日期,<entity> 约束可能需要实体名称或其他标识符,以及约束可能需要一个数字。

例如,时间约束可能要求日期或时间在过去或将来,例如,包含<日期/过去>的字段可能要求该字段包括过去的日期。 例如,性别约束可能需要男性或女性。

例如,关系约束可能需要与另一个实体的关系类型,例如,包含<entity/spouse> 的字段可能要求该字段包括作为另一个实体的配偶的实体。 例如,单数/复数约束可能要求字段中的数据为单数或复数形式。

例如,测量单位约束可能要求以特定的测量单位(例如,英寸、英尺、厘米、米等)测量现场中的数据。 例如,行列式约束可能要求“the”一词位于字段之前。

查询中的每个属性都可以用作访问一组候选模板的键。 例如,属性“年龄”可能会导致模板的检索。 示例模板包括第一个模板“ 出生于<日期/过去&glt; 并且当前是 <value> 岁”,这需要 <entity&lgt; 的实体名称。 字段,过去的日期字段,以及 <value< 字段的数字(例如,年龄)。

第二个模板,“<entity> 当前是 <value< years old”,需要 <entity> 字段的实体名称和 <value> 字段的数字(例如,年龄)。

第三个模板,“<entity> 出生于 <date/past>,死亡于 <date/past>”,需要 </entity><entity> 字段的实体名称和 <date/ 两个过去的日期过去>领域。

给定属性的多个模板

有利地,具有给定属性的多个模板使实现能够支持部分事实。 例如,对于年龄模板,如果知道出生年份但不知道具体日期,则合适的模板可能是“</entity><entity> 出生于 <year/past>”。 为给定属性提供多个模板还允许改变事实的不同部分的时态(例如,“伍迪艾伦结婚了”和“伍迪艾伦结婚了”)。

在获得候选模板后,答案引擎根据各种启发式方法从候选模板中选择一个模板。 例如,答案引擎可以检查性别一致性和正确时态。 此外,答案引擎可以确定原始查询的答案数量与所选模板的字段数量相匹配。

回答引擎还可以确定所选模板的约束和字段是否得到满足。 回答引擎可以选择具有由事实信息满足的约束的具有最大数量的字段的模板(例如,数据最丰富的模板)。 事实信息是“<woody Allen/born on/Dec. 1, 1935 年>。”

在这个例子中,第一个候选模板是“<entity> 出生于 <date/past> 并且当前是岁。” 这个模板有一个字段、<date/past> 字段和 <value> 字段。 事实信息提供满足 <entity> 字段约束的实体和满足场约束。

答案引擎可以基于事实信息得出值。 答案引擎因此可以计算年龄值以满足基于出生日期的<value<字段约束。 由于事实信息满足第一个模板中字段的所有约束,因此答案引擎选择第一个模板。

答案引擎选择第一个模板,其字段可由事实信息填充,并且不执行任何附加处理。 或者,答案引擎可以处理候选模板中的每个模板,并选择具有最多可以被事实信息填充的字段的模板。

选择模板后,答案引擎会根据模板生成句子或短语。 例如,答案引擎可以用来自事实信息的适当数据替换模板中的字段。 答案引擎使用所选模板生成句子“Woody Allen 出生于 1935 年 12 月 1 日,现年 77 岁”。

答案引擎然后将答案传输到客户端设备,其中答案包括生成的句子。答案可以是客户端设备转换为语音并呈现给用户的转录。

根据事实查询生成句子的系统

该系统包括客户端设备、搜索系统、索引集群和答案引擎。 例如,所示实体可以作为系统的一部分来实现。

客户端设备发起具有查询项的查询。

例如,用户可以在客户端设备的网络浏览器中输入查询“伍迪艾伦嫁给了谁”。

搜索系统从客户端设备接收查询(例如,“伍迪艾伦嫁给了谁”)。

然后搜索系统将原始查询解析并格式化为格式(例如, ) 使用例如合适的自然语言解析引擎。

在该示例中,格式化查询包括实体的标识符(例如,伍迪艾伦)、实体的类型(例如,人)和属性(例如,婚姻)。

类型信息可用于生成元模板,如下所述。 然后搜索系统将格式化的查询发送到索引集群。

索引集群访问索引以检索一组响应查询的事实信息

索引簇访问索引以检索一组响应查询的事实信息。 这些结果包括至少两个三元组(例如, , 和 <路易丝·拉塞尔/妻子/1966/1970>)。

然后索引簇传输格式化的查询(例如,<woody Allen/age> 和回答查询的事实信息(例如,<Soon-Yi Previn/wife/1997> 和 <louise Lasser/wife/1966/1970> ) 到答案引擎。

使用格式化的查询和事实信息,答案引擎然后生成一个或多个句子形式的答案,如下所示。

首先,答案引擎从格式化的查询(例如,人)中获取类型信息。

类型信息标识查询所基于的实体类型。 使用类型信息,答案引擎访问与“人”类型实体相关联的候选元模板。

如本规范中所述,元模板是具有配置为包含其他模板的字段的模板。

每个候选元模板包括用于实体名称或标识符的字段以及用于添加其他模板的至少一个字段。

这些模板允许答案引擎生成句子,以包含具有关于一个人的信息的各种短语。

回答引擎还从格式化的查询中获得一个或多个属性,并使用该一个或多个属性从模板数据库中访问候选短语模板。

这些短语模板旨在整合到元模板中。

如上所述,查询中的每个属性都可以用作访问一组候选短语模板的键。

例如,属性“婚姻”可能导致检索短语模板。

示例短语模板包括第一个模板“自 <date/past> 以来已与 <entity/spouse> 结婚”,该模板要求与格式化查询中的实体结婚的实体字段,以及过去的日期场地。

第二个模板“与 <entity/spouse> 结婚”需要一个与格式化查询中的实体结婚的实体场地。

第三个模板“已婚”不需要额外信息。

第四个模板“从 <date/past > 到 <date/past > 与 <entity/spouse > 结婚”,需要一个与格式化查询中的实体结婚的实体<date/past> 字段为过去的两个日期。 第五个模板“与 <entity/spouse> 结婚”需要一个与 <entity/spouse> 字段的格式化查询中的实体结婚的实体。 第六个模板“已婚”不需要额外信息。

接下来,答案引擎根据包含在事实信息中的信息类型选择候选元模板之一。 具体来说,答案引擎根据包含在事实信息中的三元组的数量来选择候选元模板。 两个三元组包含在事实信息中。 因此,答案引擎选择具有两个模板字段的“person”元模板,即“<entity><template> 和 </template><template>”。

对于事实信息中包含的每个三元组,答案引擎还从候选短语模板中选择一个模板。 答案引擎可以选择具有由事实信息满足的约束的最大字段数的短语模板(例如,数据最丰富的模板)。

事实信息中包含的第一个三元组是<Soon-Yi Previn/wife/1997>。” 在这个例子中,第一个候选短语模板是“已经结婚自从。” 这个模板有一个 <ntity/spouse&g; 字段和一个 <日期/过去> 字段。

第一个三元组具有与格式化查询中满足 <entity/spouse> 字段约束的实体具有配偶关系的实体,以及满足 <date/past> 字段约束的过去日期。 由于第一个三元组满足第一个模板中字段的所有约束,因此答案引擎为第一个三元组选择第一个模板。

事实信息中包含的第二个三元组是<louise Lasser/wife/1966/1970>。” 第四个候选短语模板是“从 <date/past> 到 <date/past> 与 <entity/spouse> 结婚”,它有一个 <entity/spouse> 字段和两个 <date/past> 字段。 事实信息中的第二个三元组提供与格式化查询中满足 <entity/spouse> 字段约束的实体具有配偶关系的实体,以及过去的两个日期满足场约束。

由于第二个三元组满足第四个模板中字段的所有约束,因此答案引擎为第二个三元组选择第四个模板。

答案引擎选择第一个模板,其字段可由事实信息填充,并且不执行任何附加处理。 或者,答案引擎可以处理候选模板中的每个模板,并选择具有最多可以被事实信息填充的字段的模板。

选择模板后,答案引擎会根据模板生成一个句子。 例如,答案引擎可以用来自事实信息的适当数据替换所选模板中的字段。

答案引擎可以用来自第一个三元组的信息替换第一个选择的短语模板中的字段(即,“自从 <<date/past> 以来已经与 <entity/spouse> 结婚”)以生成短语“has got mapped自 1997 年以来与 Soon-Yi Previn 结婚。”因此,答案引擎生成句子“Woody Allen 从 1997 年起与 Soon-Yi Previn 结婚,之前在 1966 年至 1970 年间与 Louise Lasser 结婚。”然后答案引擎传输答案到包含生成句子的客户端设备。答案可能包含在包含句子和其他搜索结果的搜索结果页面中。搜索结果页面还包括显示原始搜索查询的搜索框(即,“伍迪是谁Allen 结婚”)。然后,搜索结果页面可以由客户端设备呈现。该句子可以作为替代方式作为允许客户端设备生成语音的转录,或作为编码句子的音频信号来传输。 在客户端设备上渲染。

生成句子以响应事实查询的系统

该系统包括客户端设备、搜索系统、索引集群和答案引擎。

客户端设备向客户端设备处的网络浏览器发起具有两个查询词(“伍迪艾伦的家乡和母校在哪里”)的查询。

搜索系统从客户端设备接收查询(例如,“伍迪艾伦的家乡和母校在哪里”)。 然后,搜索系统使用例如合适的自然语言解析引擎将原始查询解析并格式化为<entity/type/attribute>格式(例如,>woody Allen/person/hometown/college<)。

在该示例中,格式化查询包括实体的标识符(例如,Woody Allen)、实体的类型(例如,人)和两个属性(例如,家乡和大学)。 然后搜索系统将格式化的查询发送到索引集群。

使用格式化的查询和事实信息,答案引擎然后生成一个或多个句子形式的答案,如下所示。 First, the answer engine obtains the type information from the formatted query (eg, person).

Using the type information, the answer engine accesses candidate meta-templates that are associated with a “person” type of entity.

As referred to in this specification, meta-templates are templates that have fields configured to contain other templates.

The answer engine also obtains the attributes from the formatted query and uses the attributes to access candidate phrase templates from template databases.

These phrase templates get designed to get incorporated into the meta-templates.

As described above, each attribute in the query may function as a key for accessing a set of candidate phrase templates. For example, the attribute “hometown” may result in the retrieval of the phrase templates. The sample phrase templates include a first template “currently lives in >location<,” which requires a geographic location for the 场地。

The second template, “has lived in </location><location> since <date/past>,” requires a geographic location for the </location<>location> field and a date in the past for the <date/past> field. The third template, “used to live in </location><location>,” requires a geographic location for the location field.

Next, the answer engine selects one of the candidate meta-templates based on the type of information included in the factual information. In particular, the answer engine selects a candidate meta-template based on the number of triples included in the factual information. Two triples get included in the factual information.

For each triple included in the factual information, the answer engine also selects a template from the candidate phrase templates The answer engine may select the phrase template having the maximum number of fields with constraints that get satisfied by the factual information (eg, the most data-rich template). The answer engine also may perform other heuristics, such as analyzing gender agreement and correct tense of the candidate templates.

The first triple included in the factual information is <woody Allen/hometown/NYC>.” In this example, the first candidate template in the hometown templates is “currently lives in <location>.” The first triple has a location (ie, NYC) that satisfies the </location><location> field constraint. Since the first triple satisfies all of the constraints for the fields in the first template, the answer engine selects the first template from the hometown templates for the first triple.

The second triple included in the factual information is <woody Allen/college/NYU>.” The first candidate template in the college templates is “his alma mater is </college><college>.” The second triple in the factual information provides a college name (ie, NYU) that satisfies the </college<>college> field constraint.

Also, the answer engine may determine that the gender of the entity (Woody Allen) agrees with the gender of the phrase in this template. The answer engine selects the first template from the college templates for the second triple.

The answer engine selects the first template with fields that can get filled by the factual information, and does not perform any additional processing. Alternatively, the answer engine may process each template in the candidate templates and select the template having the largest quantity of fields that can get filled by the factual information.

After selecting the templates, the answer engine then generates a sentence based on the templates. For example, the answer engine may replace the fields in the selected templates with the appropriate data from the factual information. The answer engine may replace the fields in the first selected phrase template (ie, “currently lives in <location>”) with the information from the first triple to generate the phrase “currently lives in New York City.”

The answer engine then replaces the template fields in the selected meta-template (ie, “<entity><template> and &kt;/template><template>”) with the phrases generated from the first and second phrase templates. Thus, the answer engine generates the sentence “Woody Allen currently lives in New York City and his alma mater is New York University.”

The answer engine then transmits an answer to the client device that includes the generated sentence.

The answer may get included in a search results page that includes the sentence and other search results. The search results page also includes a search box showing the original search query (ie, “Where is Woody Allen's hometown and alma mater”). The search results page may then get rendered by the client device.

As getting provided in search results, the sentence could alternatively get transmitted as a transcription that allows the client device to generate speech, or as an audio signal encoding the sentence for rendering at the client device.

An Example Data Graph

The example data graph includes nodes (eg, entities) and edges connecting the nodes (eg, relationships or attributes). Naturally, the example data graph shows only a partial graph–a full graph with a large number of entities and even a limited number of relationships may have billions of triples.

An indexing system may traverse the data graph to obtain factual information as various triples. One example of a triple that may get obtained is the entity “Woody Allen” as the subject (or entity), the relationship “was born” as the predicate (or attribute), and the entity “Dec. 1, 1935” as the object (or value).

Another example of a triple that may be obtained is the entity “Woody Allen” as the subject, the relationship “has type” as the predicate, and the entity “person” as the value. This triple may get used, for example, by the answer engine as described above to select candidate meta-templates.

Another example of a triple that may get obtained is the entity “Woody Allen” as the subject, the relationship “was married to” as the predicate, and the entity “Louise Lasser” as the value.

Note that to obtain this triple, the indexing system must traverse two edges in the data graph, ie, from the “Woody Allen” entity to the “Woody Allen marriages” entity, and then from the “Woody Allen marriages” entity to the “Louise Lasser” entity.

Generating Sentences In Response To Factual Queries

A server (eg, an answer engine) receives an original query that identifies the attributes of an entity. For example, the server may receive a query that identifies multiple attributes of an entity (eg, age, date of birth, place of birth, marriages, etc.).

The server accesses a set of candidate templates for answering the query based on the attributes of the entity. Each candidate template includes fields, wherein each field gets associated with at least one constraint. When multiple attributes get identified in the original query, the server accesses a set of candidate templates for each attribute of the entity. The constraints may include of a type constraint, a temporal constraint, a gender constraint, a relationship constraint, a singular/plural constraint, a unit of measure constraint, and a determinant constraint.

The server then obtains a set of information that answers the query, for example by accessing a graph-based datastore as described above. The set of information that answers the query may be, for example, a set of entity-attribute-value triples. When multiple attributes get identified in the original query, the server obtains a set of information for each attribute (ie, to answer each portion of the original query).

Multiple sets of information (eg, multiple triples) may be responsive to a single attribute. For example, if the attribute is “marriages” or “children,” then multiple triples may get obtained in response to the attribute.

the server selects a template from the set of candidate templates, where the selected template has a maximum number of fields with constraints that may get satisfied by the set of information that answers the query. When multiple attributes get identified in the original query, the server selects a template for each attribute from the appropriate set of candidate templates.

Also, when multiple sets of information get obtained in response to a single attribute, the server may select multiple templates from the same set of candidate templates.

The server then generates a phrase. The phrase may get generated by adding the set of information that answers the query to the fields of the selected template so that the phrase answers the original query. The phrase may get sentenced. Alternatively or in addition, the phrase may be portions of a sentence. When multiple attributes get identified in the original query, the server generates a phrase for each attribute. The server may then combine the phrases to generate a complete sentence.

The server may obtain a sentence template (eg, a meta-template) based on the type of the entity (eg, person or location). The sentence template may include multiple fields for inserting phrases. For example, the server may access a set of candidate meta-templates based on the type of entity, and then select a meta-template from the set based on the number of triples that answer the original query.

The server may then add the generated phrases described with reference to step to the fields of the sentence template to form a sentence.
The server communicates the phrase or sentence to a client device. The client device may then output the phrase to a display or as speech audio. The server transmits an audio signal corresponding to the phrase or sentence to the client device.