知識圖譜的應(yīng)用篇(一)-搜索與推薦

之前從產(chǎn)品經(jīng)理角度寫了三篇有關(guān)知識圖譜的基礎(chǔ)知識,這篇文章和以后的文章會更貼近業(yè)務(wù)層面來寫一些知識圖譜的商業(yè)應(yīng)用。為什么要把搜索與推薦放一起,是因為這倆兄弟綁定的太深了。

如何理解搜索與推薦

搜索,從需求角度來分析,可以還原成下面的這一段話,

1.A是一個用戶;

2.A想要找一個"thing";

3.A有"thing"的某些信息,或者知道"thing"的名稱等等;

4.A用他個人的知識表達(dá)方式描述了"thing";

5.幫A找出"thing"。

再講通俗一點,就是幫A通過他的描述找到他最想要的"thing"。


推薦,從需求角度來分析,可以還原成下面的這一段話,

1.A是一個用戶

2.A已經(jīng)通過他的描述告訴你他想要的"thing"或A曾經(jīng)告訴過你他想要的"thing"

3.A不知道他還想要其他的哪些"thing"或者A下一步需要哪些"thing"

4.幫A找出"thing"

再講通俗點,我也不一定知道我喜歡什么,你來猜我想要什么吧,并且在合適的時間與地點出現(xiàn)。


推薦對比搜索來說有一定區(qū)別,推薦不僅要站在用戶的角度思考問題,而且還需要站在系統(tǒng)的角度去思考問題

一個好的推薦系統(tǒng)不僅需要滿足用戶的需求,也要滿足內(nèi)容生產(chǎn)者的需求,還要滿足系統(tǒng)自我進(jìn)化的需求。

通俗的講就是

1.幫助用戶找到他想要的東西

2.幫助更多的內(nèi)容生產(chǎn)者推送給他的目標(biāo)用戶

3.有一個比較好的反饋機制幫助優(yōu)化推薦系統(tǒng)

4.盡量避免馬太效應(yīng),讓弱勢的內(nèi)容生產(chǎn)者生產(chǎn)出來的優(yōu)質(zhì)內(nèi)容有機會能夠推薦到目標(biāo)用戶那里

現(xiàn)行的搜索系統(tǒng)

圖1是筆者歸納的一部分自然語言處理流,筆者需要盡量避免出現(xiàn)原公司的內(nèi)容,所以在技術(shù)層面上的知識會寫的比較少。

語言層:主要用于剔除語言中的噪音,雜質(zhì),以及時間、數(shù)值識別、描述一致性等問題。處理成計算機能識別的語言。

語義層:主要處理自然語言中的語義問題,這一塊決定了整個自然語言處理流的描述能力。

執(zhí)行層:執(zhí)行語義層的輸出結(jié)果。


圖1 自然語言處理流

以百度為例,搜索貫徹著一個思路。即從海量URL中找到標(biāo)題和正文經(jīng)過NLP語言層處理后匹配度最高的一個URL group。可以這么理解,語言層將語言處理成了標(biāo)準(zhǔn)形式,然后使用一個排序算法,得到各種URL的得分,根據(jù)得分高低將URL展示給用戶。這一過程中,語義層起到的作用甚微,可能就僅僅只在于將語言歸一化上(后面在知識圖譜應(yīng)用篇(二)-問答系統(tǒng)中會詳細(xì)講解語義層的作用)。


圖2 百度搜索結(jié)果1

從圖2中看出,百度在加裝了DNN之后,發(fā)現(xiàn)了(車頭,前),(如何放置,放在那里)的語義關(guān)系,在做的事情還是在更好的搜索url集合。

基于知識圖譜的搜索

注:下面所描述的schema構(gòu)建方案均為筆者自己從外面進(jìn)行研究然后自己思考得出的結(jié)論,如果有該公司的大神們看到并且實際有比較大的出入,請高抬貴手。

上面描述了傳統(tǒng)的搜索其實是在搜索url集合,然后通過DNN等深度學(xué)習(xí)技術(shù)發(fā)現(xiàn)了不同詞匯間的語義關(guān)系,通過RNN發(fā)現(xiàn)了語言的序列關(guān)系。然后通過排序算法(BM25是目前最常用且成功的)將url展現(xiàn)給用戶去篩選。請注意,這一整套流程下來,作為搜索引擎的機器是不知道用戶到底講的什么的,因為最后機器得到的參數(shù)就是(url,rank值),所以在互聯(lián)網(wǎng)內(nèi)容充足的情況下,這類方法雖然能夠解決用戶去找"thing"的問題,但是系統(tǒng)的描述能力會比較差。這一點是基于知識圖譜的搜索與傳統(tǒng)url搜索本質(zhì)的區(qū)別。

百度的case

圖3是百度的人物知識圖譜接搜索的結(jié)果,可以明顯對比知識圖譜和URL搜索的區(qū)別,主要就在于"知識"的概念,吳亦凡的身高,本身就是一個“知識”,通過URL搜索能否找出吳亦凡的身高呢?當(dāng)然是可以的,但是URL搜索本身是沒有“知識”的概念,基于知識圖譜的搜索,需要的就是將自然語言轉(zhuǎn)換成圖查詢語言,把知識展現(xiàn)出來即可。所以在“知識”這一塊的問答,毫無疑問,知識圖譜會比URL搜索精準(zhǔn)的多。

圖3 百度搜索結(jié)果2

來聊聊這個圖譜的schema構(gòu)建吧,這個圖譜應(yīng)該算比較容易構(gòu)建的schema,只需要導(dǎo)入人物的基本信息,例如:身高,體重,出生年月等等。例如:(吳亦凡(entity),身高(relation),187cm(value))。然后再就是實體間的關(guān)系搭建,參考圖4,一個比較鬼畜的問答

雙向邊構(gòu)建方式:(姚明(entity),夫妻(relation),葉莉(entity));(姚明(entity),父女(relation),姚沁蕾(entity));(葉莉(entity),母女(relation),姚沁蕾(entity))。

單項邊構(gòu)建方式:(姚明(entity),妻子(relation),葉莉(entity));(葉莉(entity),丈夫(relation),姚明(entity));(姚明(entity),女兒(relation),姚沁蕾(entity));(姚沁蕾(entity),爸爸(relation),姚明(entity));(葉莉(entity),女兒(relation),姚沁蕾(entity));(姚沁蕾(entity),媽媽(relation),葉莉(entity));

從單項邊的角度來說,做搜索查詢非常容易,常規(guī)的查詢幾乎不需要做語言處理,例如:姚明的女兒是誰?,只需要識別姚明是一個entity,女兒是一個relation,然后調(diào)取(姚明(entity),女兒(relation),姚沁蕾(entity))即可。


圖4 百度搜索結(jié)果3

神馬搜索的case

神馬搜索是一款基于移動端的搜索產(chǎn)品,筆者發(fā)現(xiàn)神馬搜索里面圖譜用的比較多,而且比較6,下面會單獨抽出幾個案例來講講神馬搜索,因為神馬的schema有點復(fù)雜了,里面會涉及到一些進(jìn)階的內(nèi)容。

圖5是神馬搜索中“阿里巴巴”的搜索結(jié)果。

頁卡:公司概述、組織關(guān)系、招聘信息

下方:創(chuàng)始人、聯(lián)系電話、地址

首先,阿里巴巴是一個entity,上述都是阿里巴巴的relation,頁卡部分比較復(fù)雜,是屬于復(fù)合型的屬性,常規(guī)的構(gòu)建方法容納不了這么多信息量。創(chuàng)始人(property)相當(dāng)于構(gòu)建了(企業(yè))-{創(chuàng)始人}-(人物)的關(guān)系。是關(guān)系型屬性。聯(lián)系電話和地址都是值類型的屬性。

圖5 神馬搜索結(jié)果1

圖6是組織結(jié)構(gòu)內(nèi)的長截圖,里面所有的內(nèi)容都是可以點擊的,并且可以精確找到對應(yīng)的目標(biāo),因為人物有重名現(xiàn)象,如果使用關(guān)系型數(shù)據(jù)庫,想要精確找到目標(biāo)是有一定實現(xiàn)成本的。可以看到,組織結(jié)構(gòu)里面包含了高管、子公司兩塊內(nèi)容,如果熟悉三元組構(gòu)建模式的話,會發(fā)現(xiàn)中間構(gòu)建會有一定問題。圖6展示的數(shù)據(jù)結(jié)構(gòu)是 阿里巴巴-組織關(guān)系-高管-馬云,阿里巴巴-組織關(guān)系-子公司-螞蟻金服,這已經(jīng)超出三元組的構(gòu)建范圍了,所以筆者推測神馬創(chuàng)造了一種復(fù)合類型的構(gòu)建方案。

首先,基于常識構(gòu)建知識,構(gòu)建如下

(阿里巴巴(entity),高管(relation),馬云(entity))

(阿里巴巴(entity),子公司(relation),螞蟻金服(entity))

然后創(chuàng)造一種復(fù)合類型的property,叫“組織關(guān)系”,組織關(guān)系包含了“高管”,“子公司”兩種property,用組織結(jié)構(gòu)指代2種property,使用圖查詢拉出結(jié)果。

圖6 神馬搜索結(jié)果2


神馬搜索的第二個case是關(guān)于學(xué)校的搜索,搜索學(xué)校的時候,用戶會關(guān)心學(xué)校的很多詳細(xì)且復(fù)雜的信息,例如分?jǐn)?shù)線,院校專業(yè),這個時候,常規(guī)的url搜索在某種意義上就不能滿足用戶的需求了。精準(zhǔn)搜素,信息關(guān)聯(lián)正是知識圖譜的強項。

圖7是使用神馬搜索關(guān)于“北京大學(xué)”的搜索結(jié)果,可以看到搜索北京大學(xué)后,頁面展示相當(dāng)豐富,概覽、資訊、分?jǐn)?shù)線、院校專業(yè)、校園生活等等。

圖7 神馬搜索結(jié)果3

圖8是分?jǐn)?shù)線頁卡里面的內(nèi)容,可以看出,里面的內(nèi)容相當(dāng)豐富,錄取分?jǐn)?shù)線具有地理位置、文理科劃分,還有批次劃分,還有年份等等。專業(yè)分?jǐn)?shù)線具有地理位置劃分,文理科劃分,年份劃分。總之,信息量相當(dāng)?shù)拇螅贸R?guī)的三元組構(gòu)建徹底無法構(gòu)建,因為三元組無法容納這么多的信息量,即使容納了,也相當(dāng)難查詢,如果查詢困難,知識圖譜就失去了他本身的意義了。

圖8 神馬搜索結(jié)果4

如果仔細(xì)觀察,你會發(fā)現(xiàn)分?jǐn)?shù)線這個類目里面沒有entity,也就意味著該頁面可能都是value。我們可以做一個假設(shè),這是另一種復(fù)合類型的schema構(gòu)建,構(gòu)建方案是(阿里巴巴(entity),分?jǐn)?shù)線(relation),table1(?))。讓relation直接連接表格,理論上就可以完成圖8的效果,不太能理解的話參考圖9


圖9 分?jǐn)?shù)線復(fù)合類型schema的構(gòu)建

圖10是院校專業(yè)的內(nèi)容,這部分有別于分?jǐn)?shù)線的內(nèi)容,里面的的內(nèi)容主要集中在專業(yè)類別,全國排名,專業(yè)名稱。看似比上面的分?jǐn)?shù)線簡單,實際是應(yīng)該比上面的分?jǐn)?shù)線schema復(fù)雜一些,因為專業(yè)名稱這一欄全部都是entity,就意味著這個schema必須連到圖譜本身,不能像分?jǐn)?shù)線那樣外接table去構(gòu)建了。

圖10 神馬搜索結(jié)果5

筆者認(rèn)為有2種方案可以構(gòu)建該圖譜schema

第一種是直接用(北京大學(xué)(entity),專業(yè)(relation),物理學(xué)(entity)),然后在該relation上添加屬性:全國排名,專業(yè)類別,是否是重點。該方案有一個風(fēng)險就是把信息存在relation_property里面風(fēng)險比較大,原因如下,relation_property只能存string,無法存entity了,萬一以后需要添加entity了,這個schema會因為這個原因直接掛掉。還有一個風(fēng)險是relation_property非常不適合查詢,如果想用全國排名去查詢的話,會有一定的實現(xiàn)成本。

第二種是使用復(fù)合構(gòu)建方案,創(chuàng)建一個復(fù)合屬性:專業(yè)概覽,連接一張表格,這張表格里面需要可以兼容導(dǎo)入圖譜的數(shù)據(jù)。具體參考圖11,這種構(gòu)建方法能夠更好的管理維護(hù)知識,查詢也會比較方便。

圖11 專業(yè)概覽的復(fù)合類型schema構(gòu)建

基于知識圖譜的推薦

知識圖譜的推薦主要是通過實體與實體之間的關(guān)系,將用戶搜索實體的相關(guān)內(nèi)容根據(jù)一定的邏輯推薦給用戶,以北京大學(xué)為例,搜索北京大學(xué)后,神馬搜索會出現(xiàn)“知名校友”,“相關(guān)院校”的推薦欄目,通過知識圖譜,能夠準(zhǔn)確的知道哪些人從北京大學(xué)畢業(yè)的,然后通過一系列的熱點排序算法,將用戶最關(guān)心的畢業(yè)生選出來,知名校友這一欄,就可以得出以下結(jié)果。

相關(guān)院校這一塊,可以采用對比學(xué)校的property相似度,相似度高的排前面,例如:清華、復(fù)旦、浙大、北大都是985院校,其他屬性相似度越高。

圖12 神馬搜索結(jié)果6

圖譜可以在不同的實體之間構(gòu)建可以描述性強的關(guān)系,產(chǎn)品經(jīng)理可以根據(jù)需求的不同去挑選不同的關(guān)系展示。例如用戶問企業(yè),可以根據(jù)一定邏輯返回相關(guān)的企業(yè)。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容