信息化是企业在外部环境变化时保持核心竞争力的有力手段。在白酒企业信息化过程中，通过应用大数据、云计算等的新智慧营销方式，精准定位消费群体，将对中国白酒未来营销起到革命性作用。
在营销过程中，白酒企业基于知识图谱的数据信息化可以将隐藏在杂乱无章的数据背后的信息提炼出来，并进行数据分析与总结，终得出研究对象的内在规律，帮助管理者进行更好地判断和决策。
本文从白酒行业实际情况出发，基于HugeGraph图形数据库周边应用生态，分享了百分点大数据技术团队在白酒行业的技术创新实践，介绍如何通过知识的深度挖掘与关联分析，创新性地实现业务指标和问答的融合。
知识图谱本身可以看作是一种新型的信息系统基础设施。从数据维度上看，知识图谱要求用更加规范的语义提升企业数据的质量，用链接数据的思想提升企业数据之间的关联度，终极目标是将非结构、无显示关联的粗糙数据逐步提炼为结构化、高度关联的高质量知识。因此，白酒企业应该将知识图谱作为一种面向数据的信息系统基础设施进行持续性建设。从技术维度上看，知识图谱的构建涉及知识表示、关系抽取、图数据存储、数据融合、推理补全等多方面技术；知识图谱的应用涉及语义搜索、知识问答、自动推理、知识驱动的语言及视觉理解、描述性数据分析等，因此，要构建并利用好知识图谱，白酒行业需要系统性地综合利用来自知识表示、自然语言处理、机器学习、图数据库、多媒体处理等多个相关领域的技术，而非单个领域的单一技术。可以说，用系统思维进行知识图谱的构建和应用，是未来的一种发展趋势。
1. 知识图谱与数据存储
随着知识图谱规模的日益增长，知识图谱数据管理问题也愈加突出。近年来，知识图谱和数据库领域均认识到大规模知识图谱数据管理任务的紧迫性。由于传统关系数据库无法有效适应知识图谱的图数据模型，知识图谱领域形成了RDF数据的三元组库（Triple Store），数据库领域开发了管理属性的图数据库（Graph Database）。Neo4j是用Java实现的开源图数据库，可以说Neo4j是目前流行程度高的图数据库产品。Neo4j的不足之处在于其社区版是单机系统，虽然Neo4j企业版支持高可用性（High Availability）集群，但与分布式图存储系统的大区别在于它是在每个节点上存储图数据库的完整副本（类似于关系数据库镜像的副本集群），而不是将图数据划分为子图进行分布式存储，并非真正意义上的分布式数据库系统。如果图数据超过一定规模，系统性能就会因为磁盘、内存等限制而大幅降低，此外，企业版每年授权费用也是一大笔开支。HugeGraph是百度开源的一款易用、高效、通用的开源图数据库系统（Graph Database），实现了Apache TinkerPop3框架及完全兼容Gremlin查询语言，具备完善的工具链组件，助力用户轻松构建基于图数据库之上的应用和产品。HugeGraph支持百亿以上的顶点和边快速导入，并提供毫秒级的关联关系查询能力（OLTP），同时，还可与Hadoop、Spark等大数据平台集成，进行离线分析（OLAP）。
本次项目综合考虑，选用国产开源的HugeGraph进行图谱应用构建，如下是HugeGraph图形周边生态。
基于知识图谱的问答（Knowledge-Based Question Answering，KBQA，下称“知识问答”）是智能问答系统的核心功能，是一种人机交互的自然方式。知识问答依托一个大型知识库（如知识图谱、结构化数据库等），将用户的自然语言问题转化成结构化查询语句（如SPARQL、SQL、Gremlin等），直接从知识库中查询用户所需的答案。近年来，知识问答聚焦于解决事实型问答，问题的答案是一个实义词或实义短语。如“2021年茅台消费多的城市是哪个？”“北京市2021年销售好的品类是哪个？”事实型问题按问题类型可分为单知识点问题（Single-hop Questions）和多知识点问题（Multi-hop Questions）；按问题的领域可分为垂直领域问题和通用领域问题，相对于通用领域或开放领域，垂直领域下的知识图谱规模更小、精度更高，知识问答的质量更容易提升。知识问答技术的成熟与落地不仅能提高人们检索信息的精度和效率，还能提升用户的产品体验。无论依托的知识库的规模如何，用户总能像“跟人打交道一样”使用自然语言向机器提问并得到反馈，便利性与实用性共存。攻克知识问答的关键在于理解并解析用户提出的自然语言问句。这涉及自然语言处理、信息检索和推理（Reasoning）等多个领域的不同技术。相关研究工作在近五年来受到越来越多国内外学者的关注，研究方法主要可分为三大类：基于语义解析（Semantic Parsing）的方法、基于信息检索（Information Retrieval）的方法和基于概率模型（Probabilistic Models）的方法。大部分先进的知识问答方法是基于语义解析的，目的是将自然语言问句解析成结构化查询语句，进而在知识库上执行查询得到答案。通常，自然语言问句经过语义解析后，所得的语义结构能解释答案的产生。在实际工程应用中，这一点优势不仅能帮助用户理解答案的产生，还能在产生错误答案时帮助开发者定位错误的可能来源。除此之外，在理解问题、回答问题的过程中，模型应具备更强的推理能力和更好的可解释性，更强的推理能力能满足用户的复杂提问需求，更好的可解释性使用户在“知其然”的同时“知其所以然”。
本体实际上就是对特定领域之中某套概念及其相互之间关系的形式化表达，对那些可能相对于某一智能体（Agent）或智能体群体而存在的概念和关系的一种描述。
本次项目根据需求，以品规为核心，结合品规品牌知识、零售户属性信息和经营信息、商企业等多位数据基础，通过知识处理来构建白酒知识体系，整体应用功能包括检索查询、知识维护和数据关联加载三个应用模块。
知识图谱体系构建后，支持可视化界面查询，包括体系中的品牌品规知识、零售户属性信息、零售户经营信息和商业企业信息等，此外，还支持实体查询、关系查询、属性查询。知识检索查询，前端由VUE实现用户的操作界面和交互逻辑，G6图形组件来实现用户的操作与后端的交互查询。后端主要使用Hugegraph提供的Hugegraph-client、Hugegraph-loader、Hugegraph-hubble等组件，使用Gremlin图形查询语言与图形数据库进行交互查询。知识维护功能主要从列表维护模式和图模式维护进行知识模型的增删改查。知识维护主要维护的是PropertyKey(属性键)、VertexLabel (本体)、EdgeLabel (关系)。（1）PropertyKey是用来规范顶点和边的属性的约束。
只需要填写属性名称和选择数据类型，以及基数保存就可以新建一个属性键。（2）VertexLabel用来定义顶点类型，描述顶点的约束信息，VertexLabel允许定义的约束信息包括名称、ID策略、属性、主键和允许空值键。
按照说明，填写相关的属性值，保存即可，顶点名称不能重复。（3）EdgeLabel用来定义边类型，描述边的约束信息，EdgeLabel允许定义的约束信息包括名称、起点、终点、属性和空值键。
按照说明，填写相关的属性值，保存即可，顶点名称不能重复。数据关联加载功能为系统提供数据源接入功能，现阶段支持CSV导入，数据库数据导入。
新建任务：创建一个导入任务。
填写任务属性：填写任务的名称和描述。
上传CSV：上传需要导入数据的CSV，可以上传多个，默认需要包含标题行。
文件设置：默认设置的编码格式为UTF-8，包含标题头，日期格式yyyy-mm-dd等，如果上传的文件和该默认设置不对应的话，可以自定义。
类型设置：创建顶点和边的映射，需要对顶点或者是边的属性对上传的CSV文件的列进行一一对应，ID列进行对应。需要把所上传的CSV文件都映射完毕才能执行下一步。
导入：当完成映射的时候，直接可以进行导入，同时也可以看到导入进度。完成以后，可以看到任务状态。
流程和CSV导入相似，不同点是数据库导入需要设置数据源、数据库表的选择和类型映射，数据源设置是配置导入过程中需要连接到数据源服务器的数据库类型，IP地址，端口，用户名，密码，数据库等数据库连信息，库表设置是从已经连接的数据库中选择一张或多张数据表。类型映射是创建顶点和边的映射，需要将顶点或边的属性与数据库表的列进行一一对应，并将所上传的CSV文件都映射完毕才能执行下一步。导入任务管理：导入任务管理就是在各种状态下对已经存在的任务进行管理。
未开始：处于新建状态的任务，只设置了任务的名称和描述。失败：任务导入失败，可以对任务进行重新配置，再次导入，或是删除任务。智能问答系统属于知识图谱系统应用之一，本次项目中的智能问答系统，不仅方便客户从图谱上获取相关信息，更能够和白酒营销过程中的各项指标数据结合，使白酒营销决策者更便捷地从问答系统中获取到对应的指标数据，从而更好地辅助营销决策。智能问答核心主流的实现方式有问答对、NL2SQL和句型模板等，每种方式各有优缺点。问答对实现方式是尽可能地搜集问答系统中需要回答用户提出的问题和对应的答案，然后把问题和答案数据处理以后，保存到结构化或者半结构化数据库中，后续供用户提问的时候进行检索，一般应用于固定答案的场景。NL2SQL实现方式是利用大量的人工标注语料进行模型训练，使模型能够对用户输入的问题，进行语义识别并转换成数据源的查询语言与数据源进行交互，后把答案封装成结果返回给用户，一般应用于问题的答案需要计算并与数据源进行交互才能获得的场景。句型模板实现方式是将已经收集到的用户问题进行分类整理，按照分类把每一类问题编写成语义识别和数据源查询语言的模板，根据用户输入的问题进行语义识别以后，填充对应模板和数据源查询语句，再与数据源进行交互，后把答案封装成结果返回给用户，一般应用于问题的答案需要计算并与数据源进行交互才能获得的场景。在本次项目实践中，为了满足白酒行业从多个数据维度去获取指标数据，并且还需要从图谱上获取相关的信息，显然问答对的方式是不适合的。指标数据的获取需要查询数据源，因此需要用NL2SQL和句型模板的方式去实现，百分点大数据技术团队从工程角度分析，给出以下几点考量：（1）项目初期方案选用NL2SQL，但是收集到的问题有限，总量不足1000条，难以支撑模型训练。（2）项目中智能问答使用的查询维度，如品规、品牌、区域、指标，均是已知并且可以枚举的，都有对应的中文和ID，使用已知维度构建词对象以后，方便SQL中对应维度的替换，可以避免模型标注耗费大量的人力资源。（3）一个好用、易用的问答系统项目初期缺乏足够多语料的情况下，使用语言模型并非就能达到很好的使用效果，好用的模型构建需要足够多的数据量支撑和必要的人工参与。在项目维护过程中，如果使用句型模板，则可以很容易扩展用户的问题，只需要扩展模板即可。项目初期不需要面临新问题频繁增加时准备语料、训练模型、模型优化等一系列问题。（4）此次项目中智能问答需要动态根据用户输入的问题，拆解出对应的维度信息，维度信息不足时还需要使用缺省条件进行补足，如时间缺省、区域缺省、用户简称转换等，这些特点和主流的实现方案中句型模板的优点不谋而合，实现方式更容易，可控、可解释性强。（5）后续可以从问答系统中收集到足够多的用户对问答系统使用的问题，再结合对应的语言模型，增加问答的回答率和准确率。后项目选择基于句型模板为问答核心，在这之上进行增强扩展。“结巴”分词是一个Python 中文分词组件，可以对中文文本进行分词、词性标注等功能，并且支持自定义词典，本项目中分词基于jieba组件实现。
模板匹配
基于REfO的问句匹配，REfO（RegularExpressions for Objects）并不是一个框架，它把正则表达式的功能扩展到对象级别，它能同时使用关键和槽位匹配用户问句，从而实现DM模块的问句匹配功能，它支持Python。REfO表达实现了“上个月飞天茅台在北京市的商业销量是多少？”这个问句的匹配，匹配之后可以触发相应处理动作从数据库中查找问题答案。REfO虽然规则编写繁琐，但是其基于规则引擎的特点也能克服问句句型模板匹配繁琐的问题。其规则引擎其实就是能利用设计人员编写的规则表达式对用户输入的问句，按照分词以后的结果进行模板匹配。
问答准备
模板匹配过程
处理过程
问句匹配到规则模板以后，每个规则模板都有一个action处理函数，不同的规则定义不同的处理函数。处理函数就是规则模板，对应的封装SQL的处理逻辑。例如：
（1）在项目中定义一些实体词性。
（2）定义一些用户习惯的关键词。
（3）因为行业词数据太多，因此使用导入的方式加载到项目中。
词典：
加载数据到项目中：
问句：上个月飞天茅台在北京市的商业销量是多少？
针对这类句型，我们编写的REfO规则模板是：
其中对应例句的规则是：
Question(k_time)代表时间槽位，gauge_entity代表品规槽位，Star(Any(), greedy=False)代表可以匹配任意的词，类似通配符的作用，Question(region_entity)代表区域槽位，Star(Any(),greedy=False)又是一个通配符，Plus(index_entity) 代表指标槽位，Star(Any(), greedy=False) 又是一个通配符。
其中竖线隔开的是用来处理不同维度的槽位词出现的顺序不一样，也能正确匹配到这个模板。
模板后面对应的action则是模板对应的执行函数，例如例句中的处理函数是：
问答系统执行流程如下图所示：
此次项目中智能问答的实现，既能满足项目初期从图谱中获取常规问题答案的要求，又能实现从数据库中查询对应指标数据的功能需求，可以覆盖80%以上的指标数据获取，为决策者提供方便的决策数据支持。系统说明：智能问答系统的构建属于长期维护的项目，项目初期一些技术决策往往只是基于系统当时各种因素的考虑，随着时间的推移，初期无法满足的条件在项目过程中可以满足。因此，后续可以收集没有返回答案的用户问题，不断地进行项目优化升级，丰富问题模板，增加问题的覆盖面、提升问题的回答率，增强缺省维度信息的优化处理能力和已知维度信息识别能力，在收集到足够多的语料情况下，可以使用分类模型来提升模板匹配的精准率。[1]《知识图谱方法、实践与应用》王昊奋,漆桂林,陈华钧.
来自：https://mp.weixin.qq.com/s/LtGN5-2m4wmdsj8XSJfohQ