百分点科技：基于HugeGraph的知识图谱技术在白酒行业的落地实践

编者按:信息化是企业在外部环境变化时保持核心竞争力的有力手段。在白酒企业信息化过程中,通过应用大数据、云计算等的新智慧营销方式,精准定位消费群体,将对中国白酒未来营销起到革命性作用。

在营销过程中,白酒企业基于知识图谱的数据信息化可以将隐藏在杂乱无章的数据背后的信息提炼出来,并进行数据分析与总结,最终得出研究对象的内在规律,帮助管理者进行更好地判断和决策。

本文从白酒行业实际情况出发,基于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%以上的指标数据获取,为决策者提供方便的决策数据支持。

系统说明:智能问答系统的构建属于长期维护的项目,项目初期一些技术决策往往只是基于系统当时各种因素的考虑,随着时间的推移,初期无法满足的条件在项目过程中可以满足。因此,后续可以收集没有返回答案的用户问题,不断地进行项目优化升级,丰富问题模板,增加问题的覆盖面、提升问题的回答率,增强缺省维度信息的优化处理能力和已知维度信息识别能力,在收集到足够多的语料情况下,可以使用分类模型来提升模板匹配的精准率。