之前從產(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é)果。
以百度為例，搜索貫徹著一個思路。即從海量URL中找到標(biāo)題和正文經(jīng)過NLP語言層處理后匹配度最高的一個URL group。可以這么理解，語言層將語言處理成了標(biāo)準(zhǔn)形式，然后使用一個排序算法，得到各種URL的得分，根據(jù)得分高低將URL展示給用戶。這一過程中，語義層起到的作用甚微，可能就僅僅只在于將語言歸一化上（后面在知識圖譜應(yīng)用篇（二）-問答系統(tǒng)中會詳細(xì)講解語義層的作用）。
從圖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)的多。
來聊聊這個圖譜的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））即可。
神馬搜索的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)系電話和地址都是值類型的屬性。
圖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é)果。
神馬搜索的第二個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è)、校園生活等等。
圖8是分?jǐn)?shù)線頁卡里面的內(nèi)容，可以看出，里面的內(nèi)容相當(dāng)豐富，錄取分?jǐn)?shù)線具有地理位置、文理科劃分，還有批次劃分，還有年份等等。專業(yè)分?jǐn)?shù)線具有地理位置劃分，文理科劃分，年份劃分。總之，信息量相當(dāng)?shù)拇螅贸Ｒ?guī)的三元組構(gòu)建徹底無法構(gòu)建，因為三元組無法容納這么多的信息量，即使容納了，也相當(dāng)難查詢，如果查詢困難，知識圖譜就失去了他本身的意義了。
如果仔細(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
圖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)建了。
筆者認(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ù)知識，查詢也會比較方便。
基于知識圖譜的推薦
知識圖譜的推薦主要是通過實體與實體之間的關(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院校，其他屬性相似度越高。
圖譜可以在不同的實體之間構(gòu)建可以描述性強的關(guān)系，產(chǎn)品經(jīng)理可以根據(jù)需求的不同去挑選不同的關(guān)系展示。例如用戶問企業(yè)，可以根據(jù)一定邏輯返回相關(guān)的企業(yè)。
