編者按:信息化是企業(yè)在外部環(huán)境變化時保持核心競爭力的有力手段。在白酒企業(yè)信息化過程中,通過應(yīng)用大數(shù)據(jù)、云計算等的新智慧營銷方式,精準(zhǔn)定位消費(fèi)群體,將對中國白酒未來營銷起到革命性作用。
在營銷過程中,白酒企業(yè)基于知識圖譜的數(shù)據(jù)信息化可以將隱藏在雜亂無章的數(shù)據(jù)背后的信息提煉出來,并進(jìn)行數(shù)據(jù)分析與總結(jié),最終得出研究對象的內(nèi)在規(guī)律,幫助管理者進(jìn)行更好地判斷和決策。
本文從白酒行業(yè)實際情況出發(fā),基于HugeGraph圖形數(shù)據(jù)庫周邊應(yīng)用生態(tài),分享了百分點科技大數(shù)據(jù)技術(shù)團(tuán)隊在白酒行業(yè)的技術(shù)創(chuàng)新實踐,介紹如何通過知識的深度挖掘與關(guān)聯(lián)分析,創(chuàng)新性地實現(xiàn)業(yè)務(wù)指標(biāo)和問答的融合。
知識圖譜本身可以看作是一種新型的信息系統(tǒng)基礎(chǔ)設(shè)施。
從數(shù)據(jù)維度上看,知識圖譜要求用更加規(guī)范的語義提升企業(yè)數(shù)據(jù)的質(zhì)量,用鏈接數(shù)據(jù)的思想提升企業(yè)數(shù)據(jù)之間的關(guān)聯(lián)度,終極目標(biāo)是將非結(jié)構(gòu)、無顯示關(guān)聯(lián)的粗糙數(shù)據(jù)逐步提煉為結(jié)構(gòu)化、高度關(guān)聯(lián)的高質(zhì)量知識。因此,白酒企業(yè)應(yīng)該將知識圖譜作為一種面向數(shù)據(jù)的信息系統(tǒng)基礎(chǔ)設(shè)施進(jìn)行持續(xù)性建設(shè)。
從技術(shù)維度上看,知識圖譜的構(gòu)建涉及知識表示、關(guān)系抽取、圖數(shù)據(jù)存儲、數(shù)據(jù)融合、推理補(bǔ)全等多方面技術(shù);知識圖譜的應(yīng)用涉及語義搜索、知識問答、自動推理、知識驅(qū)動的語言及視覺理解、描述性數(shù)據(jù)分析等,因此,要構(gòu)建并利用好知識圖譜,白酒行業(yè)需要系統(tǒng)性地綜合利用來自知識表示、自然語言處理、機(jī)器學(xué)習(xí)、圖數(shù)據(jù)庫、多媒體處理等多個相關(guān)領(lǐng)域的技術(shù),而非單個領(lǐng)域的單一技術(shù)。可以說,用系統(tǒng)思維進(jìn)行知識圖譜的構(gòu)建和應(yīng)用,是未來的一種發(fā)展趨勢。
一、知識圖譜技術(shù)分析
知識圖譜與數(shù)據(jù)存儲
隨著知識圖譜規(guī)模的日益增長,知識圖譜數(shù)據(jù)管理問題也愈加突出。近年來,知識圖譜和數(shù)據(jù)庫領(lǐng)域均認(rèn)識到大規(guī)模知識圖譜數(shù)據(jù)管理任務(wù)的緊迫性。由于傳統(tǒng)關(guān)系數(shù)據(jù)庫無法有效適應(yīng)知識圖譜的圖數(shù)據(jù)模型,知識圖譜領(lǐng)域形成了RDF數(shù)據(jù)的三元組庫(Triple Store),數(shù)據(jù)庫領(lǐng)域開發(fā)了管理屬性的圖數(shù)據(jù)庫(Graph Database)。
Neo4j
Neo4j是用Java實現(xiàn)的開源圖數(shù)據(jù)庫,可以說Neo4j是目前流行程度最高的圖數(shù)據(jù)庫產(chǎn)品。Neo4j的不足之處在于其社區(qū)版是單機(jī)系統(tǒng),雖然Neo4j企業(yè)版支持高可用性(High Availability)集群,但與分布式圖存儲系統(tǒng)的最大區(qū)別在于它是在每個節(jié)點上存儲圖數(shù)據(jù)庫的完整副本(類似于關(guān)系數(shù)據(jù)庫鏡像的副本集群),而不是將圖數(shù)據(jù)劃分為子圖進(jìn)行分布式存儲,并非真正意義上的分布式數(shù)據(jù)庫系統(tǒng)。如果圖數(shù)據(jù)超過一定規(guī)模,系統(tǒng)性能就會因為磁盤、內(nèi)存等限制而大幅降低,此外,企業(yè)版每年授權(quán)費(fèi)用也是一大筆開支。
HugeGraph
HugeGraph是百度開源的一款易用、高效、通用的開源圖數(shù)據(jù)庫系統(tǒng)(Graph Database),實現(xiàn)了Apache TinkerPop3框架及完全兼容Gremlin查詢語言,具備完善的工具鏈組件,助力用戶輕松構(gòu)建基于圖數(shù)據(jù)庫之上的應(yīng)用和產(chǎn)品。HugeGraph支持百億以上的頂點和邊快速導(dǎo)入,并提供毫秒級的關(guān)聯(lián)關(guān)系查詢能力(OLTP),同時,還可與Hadoop、Spark等大數(shù)據(jù)平臺集成,進(jìn)行離線分析(OLAP)。
知識圖譜與智能問答
基于知識圖譜的問答(Knowledge-Based Question Answering,KBQA,下稱“知識問答”)是智能問答系統(tǒng)的核心功能,是一種人機(jī)交互的自然方式。知識問答依托一個大型知識庫(如知識圖譜、結(jié)構(gòu)化數(shù)據(jù)庫等),將用戶的自然語言問題轉(zhuǎn)化成結(jié)構(gòu)化查詢語句(如SPARQL、SQL、Gremlin等),直接從知識庫中查詢用戶所需的答案。
近年來,知識問答聚焦于解決事實型問答,問題的答案是一個實義詞或?qū)嵙x短語。如“2021年茅臺消費(fèi)最多的城市是哪個?”“北京市2021年銷售最好的品類是哪個?”事實型問題按問題類型可分為單知識點問題(Single-hop Questions)和多知識點問題(Multi-hop Questions);按問題的領(lǐng)域可分為垂直領(lǐng)域問題和通用領(lǐng)域問題,相對于通用領(lǐng)域或開放領(lǐng)域,垂直領(lǐng)域下的知識圖譜規(guī)模更小、精度更高,知識問答的質(zhì)量更容易提升。
知識問答技術(shù)的成熟與落地不僅能提高人們檢索信息的精度和效率,還能提升用戶的產(chǎn)品體驗。無論依托的知識庫的規(guī)模如何,用戶總能像“跟人打交道一樣”使用自然語言向機(jī)器提問并得到反饋,便利性與實用性共存。
攻克知識問答的關(guān)鍵在于理解并解析用戶提出的自然語言問句。這涉及自然語言處理、信息檢索和推理(Reasoning)等多個領(lǐng)域的不同技術(shù)。相關(guān)研究工作在近五年來受到越來越多國內(nèi)外學(xué)者的關(guān)注,研究方法主要可分為三大類:基于語義解析(Semantic Parsing)的方法、基于信息檢索(Information Retrieval)的方法和基于概率模型(Probabilistic Models)的方法。
大部分先進(jìn)的知識問答方法是基于語義解析的,目的是將自然語言問句解析成結(jié)構(gòu)化查詢語句,進(jìn)而在知識庫上執(zhí)行查詢得到答案。通常,自然語言問句經(jīng)過語義解析后,所得的語義結(jié)構(gòu)能解釋答案的產(chǎn)生。在實際工程應(yīng)用中,這一點優(yōu)勢不僅能幫助用戶理解答案的產(chǎn)生,還能在產(chǎn)生錯誤答案時幫助開發(fā)者定位錯誤的可能來源。
除此之外,在理解問題、回答問題的過程中,模型應(yīng)具備更強(qiáng)的推理能力和更好的可解釋性,更強(qiáng)的推理能力能滿足用戶的復(fù)雜提問需求,更好的可解釋性使用戶在“知其然”的同時“知其所以然”。
二、知識圖譜創(chuàng)新實踐
白酒知識圖譜系
本體創(chuàng)建
本體實際上就是對特定領(lǐng)域之中某套概念及其相互之間關(guān)系的形式化表達(dá),對那些可能相對于某一智能體(Agent)或智能體群體而存在的概念和關(guān)系的一種描述。
以下是本次項目中部分本體:
3. 知識查詢
知識圖譜體系構(gòu)建后,支持可視化界面查詢,包括體系中的品牌品規(guī)知識、零售戶屬性信息、零售戶經(jīng)營信息和商業(yè)企業(yè)信息等,此外,還支持實體查詢、關(guān)系查詢、屬性查詢。
知識檢索查詢,前端由VUE實現(xiàn)用戶的操作界面和交互邏輯,G6圖形組件來實現(xiàn)用戶的操作與后端的交互查詢。后端主要使用Hugegraph提供的Hugegraph-client、Hugegraph-loader、Hugegraph-hubble等組件,使用Gremlin圖形查詢語言與圖形數(shù)據(jù)庫進(jìn)行交互查詢。
4. 知識維護(hù)
4.1 本體維護(hù)
知識維護(hù)功能主要從列表維護(hù)模式和圖模式維護(hù)進(jìn)行知識模型的增刪改查。
知識維護(hù)主要維護(hù)的是PropertyKey(屬性鍵)、VertexLabel (本體)、EdgeLabel (關(guān)系)。
4.2 數(shù)據(jù)關(guān)聯(lián)加載
數(shù)據(jù)關(guān)聯(lián)加載功能為系統(tǒng)提供數(shù)據(jù)源接入功能,現(xiàn)階段支持CSV導(dǎo)入,數(shù)據(jù)庫數(shù)據(jù)導(dǎo)入。
未開始:處于新建狀態(tài)的任務(wù),只設(shè)置了任務(wù)的名稱和描述。
導(dǎo)入中:導(dǎo)入了CSV或者是設(shè)置了數(shù)據(jù)源。
成功:任務(wù)導(dǎo)入成功,可以對任務(wù)進(jìn)行刪除。
失敗:任務(wù)導(dǎo)入失敗,可以對任務(wù)進(jìn)行重新配置,再次導(dǎo)入,或是刪除任務(wù)。
白酒智能問答系統(tǒng)
智能問答系統(tǒng)屬于知識圖譜系統(tǒng)應(yīng)用之一,本次項目中的智能問答系統(tǒng),不僅方便客戶從圖譜上獲取相關(guān)信息,更能夠和白酒營銷過程中的各項指標(biāo)數(shù)據(jù)結(jié)合,使白酒營銷決策者更便捷地從問答系統(tǒng)中獲取到對應(yīng)的指標(biāo)數(shù)據(jù),從而更好地輔助營銷決策。
技術(shù)調(diào)研
智能問答核心主流的實現(xiàn)方式有問答對、NL2SQL和句型模板等,每種方式各有優(yōu)缺點。
問答對實現(xiàn)方式是盡可能地搜集問答系統(tǒng)中需要回答用戶提出的問題和對應(yīng)的答案,然后把問題和答案數(shù)據(jù)處理以后,保存到結(jié)構(gòu)化或者半結(jié)構(gòu)化數(shù)據(jù)庫中,后續(xù)供用戶提問的時候進(jìn)行檢索,一般應(yīng)用于固定答案的場景。
NL2SQL實現(xiàn)方式是利用大量的人工標(biāo)注語料進(jìn)行模型訓(xùn)練,使模型能夠?qū)τ脩糨斎氲膯栴},進(jìn)行語義識別并轉(zhuǎn)換成數(shù)據(jù)源的查詢語言與數(shù)據(jù)源進(jìn)行交互,最后把答案封裝成結(jié)果返回給用戶,一般應(yīng)用于問題的答案需要計算并與數(shù)據(jù)源進(jìn)行交互才能獲得的場景。
句型模板實現(xiàn)方式是將已經(jīng)收集到的用戶問題進(jìn)行分類整理,按照分類把每一類問題編寫成語義識別和數(shù)據(jù)源查詢語言的模板,根據(jù)用戶輸入的問題進(jìn)行語義識別以后,填充對應(yīng)模板和數(shù)據(jù)源查詢語句,再與數(shù)據(jù)源進(jìn)行交互,最后把答案封裝成結(jié)果返回給用戶,一般應(yīng)用于問題的答案需要計算并與數(shù)據(jù)源進(jìn)行交互才能獲得的場景。
在本次項目實踐中,為了滿足白酒行業(yè)從多個數(shù)據(jù)維度去獲取指標(biāo)數(shù)據(jù),并且還需要從圖譜上獲取相關(guān)的信息,顯然問答對的方式是不適合的。指標(biāo)數(shù)據(jù)的獲取需要查詢數(shù)據(jù)源,因此需要用NL2SQL和句型模板的方式去實現(xiàn),百分點大數(shù)據(jù)技術(shù)團(tuán)隊從工程角度分析,給出以下幾點考量:
(1)項目初期方案選用NL2SQL,但是收集到的問題有限,總量不足1000條,難以支撐模型訓(xùn)練。
(2)項目中智能問答使用的查詢維度,如品規(guī)、品牌、區(qū)域、指標(biāo),均是已知并且可以枚舉的,都有對應(yīng)的中文和ID,使用已知維度構(gòu)建詞對象以后,方便SQL中對應(yīng)維度的替換,可以避免模型標(biāo)注耗費(fèi)大量的人力資源。
(3)一個好用、易用的問答系統(tǒng)項目初期缺乏足夠多語料的情況下,使用語言模型并非就能達(dá)到很好的使用效果,好用的模型構(gòu)建需要足夠多的數(shù)據(jù)量支撐和必要的人工參與。在項目維護(hù)過程中,如果使用句型模板,則可以很容易擴(kuò)展用戶的問題,只需要擴(kuò)展模板即可。項目初期不需要面臨新問題頻繁增加時準(zhǔn)備語料、訓(xùn)練模型、模型優(yōu)化等一系列問題。
(4)此次項目中智能問答需要動態(tài)根據(jù)用戶輸入的問題,拆解出對應(yīng)的維度信息,維度信息不足時還需要使用缺省條件進(jìn)行補(bǔ)足,如時間缺省、區(qū)域缺省、用戶簡稱轉(zhuǎn)換等,這些特點和主流的實現(xiàn)方案中句型模板的優(yōu)點不謀而合,實現(xiàn)方式更容易,可控、可解釋性強(qiáng)。
(5)后續(xù)可以從問答系統(tǒng)中收集到足夠多的用戶對問答系統(tǒng)使用的問題,再結(jié)合對應(yīng)的語言模型,增加問答的回答率和準(zhǔn)確率。
最后項目選擇基于句型模板為問答核心,在這之上進(jìn)行增強(qiáng)擴(kuò)展。
基于句型模板的問答實踐
“結(jié)巴”分詞是一個Python 中文分詞組件,可以對中文文本進(jìn)行分詞、詞性標(biāo)注等功能,并且支持自定義詞典,本項目中分詞基于jieba組件實現(xiàn)。
模板匹配
基于REfO的問句匹配,REfO(RegularExpressions for Objects)并不是一個框架,它把正則表達(dá)式的功能擴(kuò)展到對象級別,它能同時使用關(guān)鍵和槽位匹配用戶問句,從而實現(xiàn)DM模塊的問句匹配功能,它支持Python。REfO表達(dá)實現(xiàn)了“上個月飛天茅臺在北京市的商業(yè)銷量是多少?”這個問句的匹配,匹配之后可以觸發(fā)相應(yīng)處理動作從數(shù)據(jù)庫中查找問題答案。REfO雖然規(guī)則編寫繁瑣,但是其基于規(guī)則引擎的特點也能克服問句句型模板匹配繁瑣的問題。其規(guī)則引擎其實就是能利用設(shè)計人員編寫的規(guī)則表達(dá)式對用戶輸入的問句,按照分詞以后的結(jié)果進(jìn)行模板匹配。
問答準(zhǔn)備
首先我們得對收集到的問句進(jìn)行整理,按照句型進(jìn)行歸類,方便后面對不同類型的問句進(jìn)行REfO規(guī)則表達(dá)式的編寫。比如:“上個月飛天茅臺在北京市的商業(yè)銷量是多少?”這個問題需要歸納到具有時間、品規(guī)、區(qū)域維度查詢指標(biāo)的句型中,用戶在提問的時候,可能會對問題中時間、品規(guī)、區(qū)域、指標(biāo)出現(xiàn)的順序沒有要求,所以在編寫這類句型規(guī)則模板的時候,需要對不同維度的詞出現(xiàn)的順序不敏感。
在進(jìn)行問句分詞之前,咱們針對的是白酒行業(yè),所以我們可以自定義一些白酒行業(yè)的行業(yè)詞以及這些詞對應(yīng)的詞性,比如品牌有:茅臺、五糧液、釣魚臺等,品規(guī)有:飛天茅臺、禮盒茅臺、低度茅臺等,方便后續(xù)分詞的時候,構(gòu)建詞對象。
除了構(gòu)建行業(yè)詞以外,為了讓問答更符合用戶的習(xí)慣,整理問答句型的時候,可以提取出用戶的習(xí)慣詞,比如時間:上個月,最近三個月,過去一年、最近半年等,比如區(qū)域中除了包含全國各省市以外,還應(yīng)該添加各省、全國、各公司等帶有區(qū)域性質(zhì)的自定義關(guān)鍵詞。
模板匹配過程
REfO會根據(jù)問題分詞以后,構(gòu)建的詞對象,遍歷規(guī)則數(shù)組中所有的規(guī)則,將所有匹配成功的模板放入匹配結(jié)果列表中。
如果匹配到多個模板,本項目中采用匹配詞對象最多的模板。
處理過程
問句匹配到規(guī)則模板以后,每個規(guī)則模板都有一個action處理函數(shù),不同的規(guī)則定義不同的處理函數(shù)。處理函數(shù)就是規(guī)則模板,對應(yīng)的封裝SQL的處理邏輯。例如:
這類句型我們編寫的REfO規(guī)則模板是:
Rule((gauge_entity + Star(Any(), greedy=False) + Question(k_time) + Question(region_entity) + Star(Any(), greedy=False) + Plus(index_entity) + Star(Any(), greedy=False))
| (Question(k_time) + region_entity + Star(Any(), greedy=False) + gauge_entity + Star(Any(), greedy=False) + Plus(index_entity) + Star(Any(), greedy=False))
| (gauge_entity + Star(Any(), greedy=False) + region_entity + Star(Any(), greedy=False) + Question(k_time) + Star(Any(), greedy=False) + Plus(index_entity) + Star(Any(), greedy=False))
| (Question(k_time) + Star(Any(), greedy=False) + gauge_entity + region_entity + Star(Any(), greedy=False) +Plus(index_entity) + Star(Any(), greedy=False))
| (region_entity + Star(Any(), greedy=False) + Question(k_time) + Star(Any(), greedy=False) + gauge_entity + Star(Any(), greedy=False) + Plus(index_entity) + Star(Any(), greedy=False))),
action=QuestionText.match_index_gauge_temp)
其中對應(yīng)例句的規(guī)則是:
(Question(k_time) + gauge_entity + Star(Any(), greedy=False) + region_entity + Star(Any(), greedy=False) +Plus(index_entity) + Star(Any(), greedy=False))
Question(k_time)代表時間槽位,gauge_entity代表品規(guī)槽位,Star(Any(), greedy=False)代表可以匹配任意的詞,類似通配符的作用,Question(region_entity)代表區(qū)域槽位,Star(Any(),greedy=False)又是一個通配符,Plus(index_entity) 代表指標(biāo)槽位,Star(Any(), greedy=False) 又是一個通配符。
其中豎線隔開的是用來處理不同維度的槽位詞出現(xiàn)的順序不一樣,也能正確匹配到這個模板。
總結(jié)
此次項目中智能問答的實現(xiàn),既能滿足項目初期從圖譜中獲取常規(guī)問題答案的要求,又能實現(xiàn)從數(shù)據(jù)庫中查詢對應(yīng)指標(biāo)數(shù)據(jù)的功能需求,可以覆蓋80%以上的指標(biāo)數(shù)據(jù)獲取,為決策者提供方便的決策數(shù)據(jù)支持。
系統(tǒng)說明:智能問答系統(tǒng)的構(gòu)建屬于長期維護(hù)的項目,項目初期一些技術(shù)決策往往只是基于系統(tǒng)當(dāng)時各種因素的考慮,隨著時間的推移,初期無法滿足的條件在項目過程中可以滿足。因此,后續(xù)可以收集沒有返回答案的用戶問題,不斷地進(jìn)行項目優(yōu)化升級,豐富問題模板,增加問題的覆蓋面、提升問題的回答率,增強(qiáng)缺省維度信息的優(yōu)化處理能力和已知維度信息識別能力,在收集到足夠多的語料情況下,可以使用分類模型來提升模板匹配的精準(zhǔn)率。
