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