你們中有些人可能熟悉FactEngine(www.factengine.ai)。FactEngine是一項(xiàng)計(jì)劃，旨在徹底改變?nèi)藗儗?shù)據(jù)庫和數(shù)據(jù)庫查詢的看法。

這似乎是一個(gè)大膽的舉措，但是數(shù)據(jù)庫行業(yè)已經(jīng)陷入困境，有一段時(shí)間了，直到最近人們才要求更多并得到它。

從1990年代初開始，我就記得人們嘗試自然語言查詢作為使普通人更容易訪問數(shù)據(jù)庫的一種方式。在那些日子里，結(jié)構(gòu)化查詢語言(SQL)風(fēng)行一時(shí)，他們使用的關(guān)系數(shù)據(jù)庫已經(jīng)在這個(gè)行業(yè)占據(jù)了統(tǒng)治地位。

關(guān)系數(shù)據(jù)庫的主要問題是SQL編寫起來很冗長，而反向工程很費(fèi)時(shí)。也就是說，如果您有一個(gè)未編寫的SQL查詢，則有時(shí)很難弄清它的含義。

例如，SQL中的上述查詢?nèi)缦滤荆?/p>

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’ 

我知道，對吧?那是什么意思

因此，長期以來，人們一直在尋找以自然語言查詢數(shù)據(jù)庫的方法，以使他們的生活更輕松。

所謂的圖數(shù)據(jù)庫的出現(xiàn)的部分原因是，查詢語言更自然地適應(yīng)了所說實(shí)體之間的謂詞。這更側(cè)重于自然語言。例如，如果某人是我們數(shù)據(jù)庫中其他人的朋友，我們可能會(huì)編寫一個(gè)類似*的圖形查詢：

MATCH (p1:person)-[:FRIEND-WITH]-(p2:person) 
WHERE p1.name = "Jack" 
RETURN p2.name 

我知道，對吧?所有的點(diǎn)和虛線，大寫字母，冒號(hào)表示什么。

使用FactEngine，您只需編寫：

> A simple natural language query. Image by author.

FactEngine的優(yōu)點(diǎn)在于，使用基礎(chǔ)語言體系結(jié)構(gòu)(受控自然語言)，無論您是在圖形數(shù)據(jù)庫還是關(guān)系數(shù)據(jù)庫上運(yùn)行都無關(guān)緊要。

在較早的文章中，我解釋了為什么任何關(guān)系數(shù)據(jù)庫都可以視為圖形數(shù)據(jù)庫，并且所有數(shù)據(jù)庫都是多模型酒吧，他們認(rèn)為有所不同。用外行的話來說，意味著可以使用自然語言來查詢?nèi)魏螖?shù)據(jù)庫，即使它們是受控的。任何數(shù)據(jù)庫也可以作為圖數(shù)據(jù)庫查詢。

原因是數(shù)據(jù)庫的主要兩種類型(圖形數(shù)據(jù)庫和關(guān)系數(shù)據(jù)庫)在概念上是同構(gòu)的。從外行的角度來說，這意味著可以在概念上將它們視為相同。

但是，讓我們回到自然語言查詢和受控自然語言。

什么是受控自然語言?

顧名思義，受控自然語言是一種自然語言語法，具有一定程度的控制權(quán)，可控制您所說的內(nèi)容和怎么說的方式。足夠優(yōu)雅的受控自然語言將看起來像香草自然語言，因?yàn)樗暮诵漠?dāng)然是自然語言。

FactEngine控制的自然語言之所以有效，是因?yàn)樗c其他語言同構(gòu)。

就是說……您不必?fù)?dān)心是在關(guān)系數(shù)據(jù)庫還是專用圖數(shù)據(jù)庫上進(jìn)行操作……您所需要知道的是，所有數(shù)據(jù)庫都可以視為一種圖數(shù)據(jù)庫。這樣，您可以在任何數(shù)據(jù)庫上使用一種語言。

FactEngine之旅

自然語言查詢以前曾被譽(yù)為"蛇油"。

這樣做的原因是，大多數(shù)對自然語言查詢(NLQ)的嘗試都依靠某種形式的推理將自然語言映射到查詢語言和數(shù)據(jù)庫結(jié)構(gòu)，而不是始終保證期望結(jié)果的純算法方法。

通常用于NLQ的推理引擎依賴于消除自然語言句子的歧義，就像人類的大腦消除復(fù)雜的，有時(shí)是模棱兩可的句子的歧義一樣。在這方面，NLQ推理引擎具有與誤解自然語言的方式相同的錯(cuò)誤解釋自然語言查詢的潛力。

確實(shí)，如果您想象一個(gè)人工智能通用技術(shù)(AGI)像活著的任何人一樣聰明，那么您的人工智能就不會(huì)像該人那樣提供更好的歧義消除機(jī)會(huì)。這是查詢數(shù)據(jù)庫的問題，在該數(shù)據(jù)庫中您需要結(jié)構(gòu)正確的查詢的準(zhǔn)確答案。

受控的自然語言提供了解決方案，至少直到AGI可以提出問題以消除歧義不清的句子并自行解決查詢?yōu)橹埂＜词谷绱耍词笰GI做到了……AGI還能解析查詢嗎?答案必須是某種結(jié)構(gòu)化查詢，也可能首先是受控自然語言查詢。

因此，要想達(dá)到FactEngine的今天水平，F(xiàn)actEngine需要一個(gè)基礎(chǔ)架構(gòu)，該架構(gòu)允許構(gòu)建受控的自然語言查詢。

我以前的公司Viev在開發(fā)波士頓概念建模工具方面朝著這個(gè)目標(biāo)努力了11年，該工具可以幫助用戶開發(fā)包含自然語言構(gòu)造并使用對象角色建模作為模型開發(fā)基礎(chǔ)的數(shù)據(jù)模型。

但是FactEngine還需要一個(gè)理由。除了自然語言概念查詢的明顯優(yōu)勢之外，推動(dòng)市場發(fā)展的是市場上現(xiàn)有技術(shù)的狀態(tài)。

就易讀性而言，圖形查詢是從SQL躍遷而來的，為了達(dá)到自然語言查詢使今天的圖形查詢語言與之相比顯得原始的程度，我們需要在另一個(gè)層次上突破性技術(shù)。

作者第一次看到數(shù)據(jù)庫Grakn的查詢語言時(shí)，便是FactEngine的主要?jiǎng)恿Α５湫偷腉rakn查詢?nèi)缦滤荆?/p>

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將此稱為"高級(jí)查詢語言"。足夠說了……FactEngine中的相同查詢?nèi)缦滤荆?/p>

> Image by author.

也就是說，Grakn通過將其他語言貶義為原始語言來提出挑戰(zhàn)，因此接受了這一挑戰(zhàn)以明確高級(jí)查詢語言的外觀。

自然語言查詢有什么好處?

受控自然語言查詢提供了與可比較的SQL和圖形查詢相同的實(shí)用程序，并且它是使軟件實(shí)際上首先幫助您編寫查詢的實(shí)用程序，這是真正的好處。

以下是幫助人們在FactEngine中編寫自然語言查詢的軟件的快照：

> FactEngine assisting to write a database query. Image by author.

在人工智能時(shí)代，易于編寫查詢已成為熱門話題。人們期望從他們的數(shù)據(jù)庫和隨附的查詢語言中獲得更多。人們并不期望成為信息技術(shù)專家才能從數(shù)據(jù)庫中獲得結(jié)果。提供自然語言查詢允許面向客戶的應(yīng)用程序?qū)⒅苯硬樵償?shù)據(jù)庫的工具置于客戶手中，而不必將工作交給更多的技術(shù)人員。

確實(shí)，如果您查看現(xiàn)存的SQL和圖形數(shù)據(jù)庫技術(shù)，它幾乎就像是旨在使生活變得困難并且限制具有技術(shù)頭腦的人員的訪問。這浪費(fèi)時(shí)間和資源。數(shù)據(jù)和技術(shù)的民主化主要是通過使日常人們更容易使用來擴(kuò)展技術(shù)市場。

另一個(gè)好處是自然語言很容易被人閱讀。編寫后，自然語言查詢可以輕松地與其他人共享，他們將在閱讀后立即知道該查詢的用途。

技術(shù)性

現(xiàn)存的查詢語言(例如SQL)和當(dāng)前的圖形查詢語言(FactEngine知識(shí)語言除外)來自于一切都太困難的時(shí)代。這種想法是很難將''(空格)字符視為字符，因此我們將使用MATCH(p1：person)-[：FRIEND-WITH]-(p2：person)代替WHICH Person是WHICH Person 2的朋友。或者，很難讓計(jì)算機(jī)為實(shí)體分配其自己的差異變量，因此我們最終得到了$ p3 isa person。$ p2!= $ p3;而不是人3不是人2。

雖然讓事情變得困難并且沒有計(jì)算機(jī)來為您完成工作可能會(huì)使技術(shù)專家繼續(xù)工作，但這并不是完全有幫助或以客戶為中心。它還嘲笑了人們對藝術(shù)的感知和優(yōu)雅。

讓計(jì)算機(jī)為您完成艱苦的工作也需要時(shí)間，因此，將產(chǎn)品推向市場會(huì)給客戶帶來缺乏技巧的解決方案。

因此，F(xiàn)actEngine進(jìn)行了13年的對象角色建模軟件研究和開發(fā)，并進(jìn)行了30多年的對象角色建模和基于事實(shí)的建模研究。

基于事實(shí)的建模認(rèn)為自然語言(包括空格和短語)都是數(shù)據(jù)庫概念建模問題的一部分。

典型的對象角色模型如下所示：

> An Object-Role Model. Image by author.

用于對象角色建模(ORM)的軟件很難編寫，這就是為什么您在市場上沒有太多ORM軟件的原因。基于事實(shí)的建模(FBM)可以說相同。

但是，一旦有了合適的ORM / FBM軟件，就有可能實(shí)現(xiàn)非凡的成就。例如，很容易將模型可視化為關(guān)系數(shù)據(jù)庫的實(shí)體關(guān)系圖(ERD)或圖形數(shù)據(jù)庫的屬性圖模式(PGS)。例如：

> Isomorphic Mappings: Object-Role Modeling, Entity Relationship Diagrams, Property Graph Schemas.

因此，從技術(shù)上來說，您需要一個(gè)合適的基于事實(shí)建模的元模型，然后您就可以開始了。涉及的更多，但這是專有的。

不用說您的客戶不必?fù)?dān)心他們是在圖形數(shù)據(jù)庫還是在關(guān)系數(shù)據(jù)庫上進(jìn)行操作，他們需要關(guān)心的就是能夠簡單，輕松地在該數(shù)據(jù)庫上編寫查詢。

我們在哪

FactEngine是一種新型的商業(yè)數(shù)據(jù)庫查詢語言技術(shù)。對于直接到SQL的1：1映射，該技術(shù)已經(jīng)相當(dāng)成熟并且在不斷發(fā)展。圖形查詢語言(例如Neo4j)具有SQL O / JDBC驅(qū)動(dòng)程序，因此通過SQL和圖形數(shù)據(jù)庫進(jìn)行概念驗(yàn)證是既成事實(shí)。

世界其他地方在哪里?好吧……我們知道一個(gè)，這就是FactEngine誕生的原因;)