点击链接阅读原文，获取更多技术内容：
本文总结了我们过去参与的知识图谱项目中的一般问题和难点，沉淀为体系化的方法论，并针对不同复杂程度的知识建模问题，进行实操指南。
作者 | 袁琳(徽外)
(相关资料图)
来源 | 阿里开发者公众号
前言
过去两年多的时间，针对蚂蚁域内业务场景和知识体系多样、复杂，知识建模成本高导致图谱项目启动难的问题，我们提出了一种结构与语义解耦的知识建模及schema设计方法，并在商家图谱、事理图谱、保险图谱等多个项目中进行实践。相关简化schema设计及帮助对知识的属性语义化、标准化的能力已经集成到蜘蛛知识平台。本文总结了我们过去所工作，沉淀为体系化的方法论，并针对不同复杂程度的知识建模问题，进行实操指南。
说明
本指南在背景部分对知识建模的发展历程、相关问题、蚂蚁场景下的挑战进行书录说明，如果对这部分已经清楚或不感兴趣可以跳过。
在基础篇、进阶篇、高阶篇，针对不同业务场景的建模需求，由浅及深讲解知识建模的方法和案例，并涉及术语的解释。本文档所提出的建模方案，已经在蜘蛛平台做了对应的能力支持实现(或开发迭代中)。独立于蜘蛛平台，读者也可以按本文的方法论对自己的业务问题简化抽象，实施对领域知识的建模及对已有常识图谱的复用。
如果你对知识图片已有一定了解或实践，可跳过基础篇(基础篇的“属性语义标化”依然值得一读)。 如果你的图谱，涉及对业务类目体系、常识概念(如“行政区划”)的应用，请仔细阅读进阶篇。 如果你的图谱，涉及对带有时空信息的行为事件的表达，或建模场景下的业务规则、专家经验，需要对所定义“概念”的内涵和外延有计算机可处理可计算的逻辑语义解释，高阶篇中有你所需知道的一切。 由于高阶篇的内容有一定的阅读门槛，如果你的场景只需要描述相对静态的事实关联，不包含用户行为、新闻事件的建模，没有语义推理的需求，可以跳过高阶篇，参考基础篇和进阶篇就够用了。背景
知识建模是解决将真实世界中的海量信息转化为符合计算机处理模式的结构化数据，其中包括对真实世界中事物的属性特征及其关系的共性的抽象，制定表示的规范，同时兼顾对常识或领域概念及概念层级体系的语义理解，即体现了对知识的认知过程。
相关工作
图1 知识建模方法回顾
表1 知识建模方法对比
方法 | 特点 |
关系型数据库 | 用实体及其属性（关系也体现为外键）对数据结构化，不包括语义的建模，容易存在大量的数据冗余，多跳跨表查复杂、效率低。 |
知识工程 | 本体表示：将知识表示为辑符号的形式，构建特定领域概念类别及其层级细分关系，并用 一阶谓词逻辑、生产式规则表示领域专家经验，支持知识的符合推理。 框架(frame)表示：强调将所描述的每类事物都抽象为出特定的slot-value的结构化表示(例如目前百科词条就是frame表示)。 弊端：人工构建成本太高，知识获取困难。 |
语义网 | 出发点是用文档中的数据关联+逻辑描述，让计算机能认识和理解世界万物。语义网发展过程中先后制定了基于描述逻辑的DAML、RDF、OWL、OWL2等语言，语义完备性的强调，成为逻辑学家的游戏，无法工业化落地。 |
知识图谱 | 以基本的SPO三元组，表示实体间的事实关系；但SPO对由多个要素（>2）共同决定的多元关系表示存在缺陷；图谱schema的设计是主观的，不同图谱的异构导致知识难以对齐融合。 |
事理图谱 | 将事件以及事件之间的关系抽取并抽象出来，构建描述事件之间演化规律和模式的事理逻辑知识库。事件有frame框架表示、verb+nound表示等流派。 |
常识概念图谱 | 围绕常识性概念建立的实体以及实体之间的关系，帮助自然语言文本的理解。涵盖“是什么”的概念Taxonomy体系结构，“什么样”的概念属性关系，“给什么”的概念承接关系。 |
知识超图 | 超图(Hypergraph)：就是每一个边可以包含两个以上的点所构成的图，解决多元知识的表示。 |
业务问题
表2 蚂蚁域内常见建模问题
建模问题 | 现有解决方案及不足 |
商家资产等实体-关系schema设计 | ●无论是ER建模、本体、rdf、owl，都只是语法定义，不解决“设计模式”本身的问题。 ●schema设计启动难，难以决策属性/关系的设计、实体类型的划分。 ●schema的设计是主观的，导致不同图谱间知识的异构性（数据结构不同），阻碍知识的复用。 |
常识、领域结构化语义理解 | ●不同业务有各自体现业务语义的类目体系，同时蚂蚁域内的场景也涉及对常识的理解 ●传统的本体建模，在同一个分类体系上，既要对schema的扩展建模，又要对语义上的细分类建模，数据结构定义和语义建模的耦合，导致工程实现及维护管理的复杂性，也增加了业务梳理和表示(认知)领域知识的困难。 |
跨图谱融合场景 | ●不同业务部门构建图谱时先专注于自身领域的知识建模，但随着业务的开展，需要引入其他领域的知识。 ●跨图谱融合，解决提高数据的复用性、提升数据治理能力，减少数据冗余重复及帮助发掘业务价值拓展。 ●需要对领域内有共有的实体，如：用户、商家、POI等，提供统一的schema规范，并对域内常识或公用类目，如：行政区划、mcc类目等，沉淀为通用语义资产。 |
保险、黑产等业务逻辑表达需求 | ●保险产品运营、保险健告、黑产洞察等场景有着丰富的业务逻辑、业务规则沉淀 ●需要支持业务规则、专家经验的形式化表达及推理能力 ●一阶谓词、dsl等，对用户有门槛，业务规则较多时，需要有更简洁、快速的对规则建模的方法 |
用户行为建模场景 | 多元关系建模问题 ●用户行为、金融事件、业务状态流，都可以抽象为多元时空行为事件建模 ●spo三元组表达多元关系是有损的 ●超图结构的理解，对于非算法用户有学习门槛，难以直接可视化 ●行为时间事件之间，本身存在着时序、因果、共现的等关系 |
事理图谱及事理关系建模 | 已有的研究或工作，都只解决了事件图谱、事理（概念）图谱或事理常识中特定一类的表示，蚂蚁场景中需要对从实例到概念，从事实到常识的整体架构 ●每种事件的实例需要frame表示 ●事件概念体系需要本体表示 ●事件实例之间的事实关系需要spo表示 ●事件概念之间的顺承、因果等需要逻辑表达 |
方案概述
本体是偏哲学的学术概念，指“特定领域之中某套概念及其相互之间关系的形式化表达（formal representation）”。在知识工程、语义网时代，都用本体建模指代知识建模，利用rdf、owl等规范的语言，核心定义严格完备的逻辑。但这套方法不适合大数据时代知识的多样性、跨领域复杂性，无法满足数据的便捷迭代生产。
我们认为，“本体”在知识图谱建模阶段，存在误用。换言之， 知识图谱建模，不需要“本体”，而应该关注数据结构上的“元数据”的定义，以及知识语义关联的标签概念体系及概念网络。
剩余60%，完整内容请点击下方链接查看：
阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：
标签：
