FactEngine之旅
> A natural language query in FactEngine. Image by author.
你们中有些人可能熟悉FactEngine（www.factengine.ai）。FactEngine是一项计划，旨在彻底改变人们对数据库和数据库查询的看法。
这似乎是一个大胆的举措，但是数据库行业已经陷入困境，有一段时间了，直到最近人们才要求更多并得到它。
从1990年代初开始，我就记得人们尝试自然语言查询作为使普通人更容易访问数据库的一种方式。在那些日子里，结构化查询语言（SQL）风行一时，他们使用的关系数据库已经在这个行业占据了统治地位。
关系数据库的主要问题是SQL编写起来很冗长，而反向工程很费时。也就是说，如果您有一个未编写的SQL查询，则有时很难弄清它的含义。
例如，SQL中的上述查询如下所示：
SELECT [Lecturer].FirstName,[Lecturer].LastName,[School].SchoolName,[Faculty].FacultyName,[TimetableBooking].LecturerId,[TimetableBooking].Semester,[TimetableBooking].WeekDay,[TimetableBooking].PeriodNr,[TimetableBooking].RoomRoomNr,[Lecturer].EmailAddress,[TimetableBooking].ClassId
FROM Lecturer,
School,
Faculty,
TimetableBooking,
Room,
Position,
Timeslot
WHERE Lecturer.SchoolId = School.SchoolId
AND School.FacultyId = Faculty.FacultyId
AND TimetableBooking.FacultyId = Faculty.FacultyId
AND TimetableBooking.RoomRoomNr = Room.RoomRoomNr
AND Lecturer.PositionId = Position.PositionId
AND TimetableBooking.Semester = Timeslot.Semester
AND TimetableBooking.WeekDay = Timeslot.WeekDay
AND TimetableBooking.PeriodNr = Timeslot.PeriodNr
AND Room.RoomName = ‘A1’
我知道，对吧？那是什么意思
因此，长期以来，人们一直在寻找以自然语言查询数据库的方法，以使他们的生活更轻松。
所谓的图数据库的出现的部分原因是，查询语言更自然地适应了所说实体之间的谓词。这更侧重于自然语言。例如，如果某人是我们数据库中其他人的朋友，我们可能会编写一个类似*的图形查询：
MATCH (p1:person)-[:FRIEND-WITH]-(p2:person)WHERE p1.name = "Jack"RETURN p2.name
我知道，对吧？所有的点和虚线，大写字母，冒号表示什么。
使用FactEngine，您只需编写：
> A simple natural language query. Image by author.
FactEngine的优点在于，使用基础语言体系结构（受控自然语言），无论您是在图形数据库还是关系数据库上运行都无关紧要。
在较早的文章中，我解释了为什么任何关系数据库都可以视为图形数据库，并且所有数据库都是多模型酒吧，他们认为有所不同。用外行的话来说，意味着可以使用自然语言来查询任何数据库，即使它们是受控的。任何数据库也可以作为图数据库查询。
原因是数据库的主要两种类型（图形数据库和关系数据库）在概念上是同构的。从外行的角度来说，这意味着可以在概念上将它们视为相同。
但是，让我们回到自然语言查询和受控自然语言。
什么是受控自然语言？
顾名思义，受控自然语言是一种自然语言语法，具有一定程度的控制权，可控制您所说的内容和怎么说的方式。足够优雅的受控自然语言将看起来像香草自然语言，因为它的核心当然是自然语言。
FactEngine控制的自然语言之所以有效，是因为它与其他语言同构。
就是说……您不必担心是在关系数据库还是专用图数据库上进行操作……您所需要知道的是，所有数据库都可以视为一种图数据库。这样，您可以在任何数据库上使用一种语言。
FactEngine之旅
自然语言查询以前曾被誉为"蛇油"。
这样做的原因是，大多数对自然语言查询（NLQ）的尝试都依靠某种形式的推理将自然语言映射到查询语言和数据库结构，而不是始终保证期望结果的纯算法方法。
通常用于NLQ的推理引擎依赖于消除自然语言句子的歧义，就像人类的大脑消除复杂的，有时是模棱两可的句子的歧义一样。在这方面，NLQ推理引擎具有与误解自然语言的方式相同的错误解释自然语言查询的潜力。
确实，如果您想象一个人工智能通用技术（AGI）像活着的任何人一样聪明，那么您的人工智能就不会像该人那样提供更好的歧义消除机会。这是查询数据库的问题，在该数据库中您需要结构正确的查询的准确答案。
受控的自然语言提供了解决方案，至少直到AGI可以提出问题以消除歧义不清的句子并自行解决查询为止。即使如此，即使AGI做到了……AGI还能解析查询吗？答案必须是某种结构化查询，也可能首先是受控自然语言查询。
因此，要想达到FactEngine的今天水平，FactEngine需要一个基础架构，该架构允许构建受控的自然语言查询。
我以前的公司Viev在开发波士顿概念建模工具方面朝着这个目标努力了11年，该工具可以帮助用户开发包含自然语言构造并使用对象角色建模作为模型开发基础的数据模型。
但是FactEngine还需要一个理由。除了自然语言概念查询的明显优势之外，推动市场发展的是市场上现有技术的状态。
就易读性而言，图形查询是从SQL跃迁而来的，为了达到自然语言查询使今天的图形查询语言与之相比显得原始的程度，我们需要在另一个层次上突破性技术。
作者第一次看到数据库Grakn的查询语言时，便是FactEngine的主要动力。典型的Grakn查询如下所示：
match $p isa person; i$ isa issue; $auth1($i, $p) isa authorship;
$r isa repostitory; cr$($is,$r) isa contains;
$m isa milestone; $cm($i,$m) isa contains;
$p2 isa person; $p != $p2; $ass($i,$p2$) isa assignment;
$comm isa comment; $t ($i, $comm) isa thread;
$p3 isa person; $p2 != $p3; $auth2 ($comm, $p3) isa authorship;
$i2 isa issue; $dep ($i,$i2) isa dependency;
limit 5; offset 0; get;
我知道，对吧？那是什么意思
Grakn将此称为"高级查询语言"。足够说了……FactEngine中的相同查询如下所示：
> Image by author.
也就是说，Grakn通过将其他语言贬义为原始语言来提出挑战，因此接受了这一挑战以明确高级查询语言的外观。
自然语言查询有什么好处？
受控自然语言查询提供了与可比较的SQL和图形查询相同的实用程序，并且它是使软件实际上首先帮助您编写查询的实用程序，这是真正的好处。
以下是帮助人们在FactEngine中编写自然语言查询的软件的快照：
> FactEngine assisting to write a database query. Image by author.
在人工智能时代，易于编写查询已成为热门话题。人们期望从他们的数据库和随附的查询语言中获得更多。人们并不期望成为信息技术专家才能从数据库中获得结果。提供自然语言查询允许面向客户的应用程序将直接查询数据库的工具置于客户手中，而不必将工作交给更多的技术人员。
确实，如果您查看现存的SQL和图形数据库技术，它几乎就像是旨在使生活变得困难并且限制具有技术头脑的人员的访问。这浪费时间和资源。数据和技术的民主化主要是通过使日常人们更容易使用来扩展技术市场。
另一个好处是自然语言很容易被人阅读。编写后，自然语言查询可以轻松地与其他人共享，他们将在阅读后立即知道该查询的用途。
技术性
现存的查询语言（例如SQL）和当前的图形查询语言（FactEngine知识语言除外）来自于一切都太困难的时代。这种想法是很难将''（空格）字符视为字符，因此我们将使用MATCH（p1：person）-[：FRIEND-WITH]-（p2：person）代替WHICH Person是WHICH Person 2的朋友。或者，很难让计算机为实体分配其自己的差异变量，因此我们最终得到了$ p3 isa person。$ p2！= $ p3;而不是人3不是人2。
虽然让事情变得困难并且没有计算机来为您完成工作可能会使技术专家继续工作，但这并不是完全有帮助或以客户为中心。它还嘲笑了人们对艺术的感知和优雅。
让计算机为您完成艰苦的工作也需要时间，因此，将产品推向市场会给客户带来缺乏技巧的解决方案。
因此，FactEngine进行了13年的对象角色建模软件研究和开发，并进行了30多年的对象角色建模和基于事实的建模研究。
基于事实的建模认为自然语言（包括空格和短语）都是数据库概念建模问题的一部分。
典型的对象角色模型如下所示：
> An Object-Role Model. Image by author.
用于对象角色建模（ORM）的软件很难编写，这就是为什么您在市场上没有太多ORM软件的原因。基于事实的建模（FBM）可以说相同。
但是，一旦有了合适的ORM / FBM软件，就有可能实现非凡的成就。例如，很容易将模型可视化为关系数据库的实体关系图（ERD）或图形数据库的属性图模式（PGS）。例如：
> Isomorphic Mappings: Object-Role Modeling, Entity Relationship Diagrams, Property Graph Schemas.
因此，从技术上来说，您需要一个合适的基于事实建模的元模型，然后您就可以开始了。涉及的更多，但这是专有的。
不用说您的客户不必担心他们是在图形数据库还是在关系数据库上进行操作，他们需要关心的就是能够简单，轻松地在该数据库上编写查询。
我们在哪
FactEngine是一种新型的商业数据库查询语言技术。对于直接到SQL的1：1映射，该技术已经相当成熟并且在不断发展。图形查询语言（例如Neo4j）具有SQL O / JDBC驱动程序，因此通过SQL和图形数据库进行概念验证是既成事实。
世界其他地方在哪里？好吧……我们知道一个，这就是FactEngine诞生的原因;）
感谢您的阅读。如果时间允许，我将写更多有关自然语言查询，基于事实和基于对象角色的建模，概念建模和图形数据库的文章。
(本文由闻数起舞翻译自Mohammed Ayar的文章《Natural Language Queries. For real this time.》，转载请注明出处，原文链接：https://towardsdatascience.com/natural-language-queries-for-real-this-time-5383bf42ad2a) |
