你們中有些人可能熟悉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誕生的原因;)