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

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

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

關(guān)系數(shù)據(jù)庫(kù)的主要問(wèn)題是SQL編寫起來(lái)很冗長(zhǎng)，而反向工程很費(fèi)時(shí)。也就是說(shuō)，如果您有一個(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’ 

我知道，對(duì)吧?那是什么意思

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

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

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

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

使用FactEngine，您只需編寫：

> A simple natural language query. Image by author.

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

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

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

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

什么是受控自然語(yǔ)言?

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

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

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

FactEngine之旅

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

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

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

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

受控的自然語(yǔ)言提供了解決方案，至少直到AGI可以提出問(wèn)題以消除歧義不清的句子并自行解決查詢?yōu)橹?。即使如此，即使AGI做到了……AGI還能解析查詢嗎?答案必須是某種結(jié)構(gòu)化查詢，也可能首先是受控自然語(yǔ)言查詢。

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

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

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

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

作者第一次看到數(shù)據(jù)庫(kù)Grakn的查詢語(yǔ)言時(shí)，便是FactEngine的主要?jiǎng)恿?。典型的Grakn查詢?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; 

我知道，對(duì)吧?那是什么意思

Grakn將此稱為"高級(jí)查詢語(yǔ)言"。足夠說(shuō)了……FactEngine中的相同查詢?nèi)缦滤荆?/p>

> Image by author.

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

自然語(yǔ)言查詢有什么好處?

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

以下是幫助人們?cè)贔actEngine中編寫自然語(yǔ)言查詢的軟件的快照：

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

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

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

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

技術(shù)性

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

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

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

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

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

典型的對(duì)象角色模型如下所示：

> An Object-Role Model. Image by author.

用于對(duì)象角色建模(ORM)的軟件很難編寫，這就是為什么您在市場(chǎng)上沒有太多ORM軟件的原因?；谑聦?shí)的建模(FBM)可以說(shuō)相同。

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

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

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

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

我們?cè)谀?/strong>