返回首页
CCCF译文 | 工业级知识图谱：经验与挑战
图谱里有什么？设计方案
首先，我们来描述这五种知识图谱以及对应的设计方案和制定范围。每个企业的不同应用场景和产品目标导致了需要采用不同的设计方案和体系结构，在此过程中，他们经历了很多挑战。表1总结了这些知识图谱的设计参数。
微软
谷歌
谷歌知识图谱涵盖了广泛的主题，有700亿条断言，描述了10亿个实体，并且是来自不同个体的十多年数据贡献活动的结果，其中大多数人从未拥有过知识管理系统的经验。
也许更重要的是，知识图谱是许多谷歌产品和功能在后台使用的长期、稳定的类和实体标识来源。外部用户和开发人员在使用YouTube和谷歌云API等服务时，可以观察到这些功能特征。这种对本体的关注使谷歌可以过渡到“是实体而不是字符串”。知识图谱不是简单地返回传统的“10个蓝色链接”，而是帮助谷歌产品将用户请求解释为用户对于所处世界的认知概念的指代，并做出适当的响应。
谷歌的知识图谱对于用户最为直观的感受是，当用户发出与实体有关的查询，搜索结果能够包括一系列从知识图谱提供的有关实体的事实。例如，查询“I.M.Pei”（贝聿铭）会在搜索结果中出现一个面板，显示这位建筑师的学历、奖项和他设计的重要结构的信息。
知识图谱还认识到，某些类型的交互作用会随不同的实体而异。查询“俄罗斯茶室”时，会提供一个按钮进行预订，而查询“Rita Ora”（一位歌手的名字）则会提供在各种音乐服务中该歌手音乐作品的链接指向。
由于谷歌知识图谱规模庞大，单个人无法记住，更不用说管理整个图使用的详细结构了。为了确保系统随着时间的推移保持一致性，谷歌从一组基本的底层结构中构建了知识图谱。它在不同的抽象级别上沿用了相似的结构和推理机制，在概念上许多基本断言也引申了该结构。为了体现构造的不变性，谷歌利用类型本身也是类型的实例来引入元类型的概念。然后，可以对元类型进行推理，以验证更细粒度的类型是否违反了构造不变性。例如，它可以验证某时间独立类型不是时间相关类型的子类。这种可扩展的抽象级别更加容易添加，因为图谱系统其余部分也是基于相同底层结构而构建的。
这种元级架构还允许大规模验证数据。例如，可以通过将画家标识为其画作的原作者，并对这些元类之间的所有关系进行一般性检查，来验证画家在其艺术品创作之前就已经存在。
从概念上讲，知识图谱能够“理解”作者与创作作品的不同之处，即使这些实体经常合并至口语表达中。同样，创作作品也可能因为表现形式不同有多个不同的实例。随着图谱规模的增长，这种本体知识有助于维护实体的实例。
通过这些自我描述的层次结构来构建知识图谱，不仅简化了系统的一致性检查，而且还使内部用户更易于理解知识图谱。一旦对新开发人员进行了知识图谱组织方面的基础培训，他们就可以了解其架构的整个范围。类似地，通过将图谱的结构与一些核心原则联系在一起，并在框架中明确地公开元关系，内部开发人员可以简化查找和理解新的模式结构。
脸书
脸书以拥有全球最大的社交图谱而闻名。脸书工程师在过去十年中，通过一系列技术以实现人与人之间的丰富联系。现在，他们正在使用相同的技术来加深对人们以及人们关心的事物的了解。
通过以结构化的方式对世界进行大规模建模，脸书工程师能够“解锁”社交图谱本身无法实现的用例。即使是看似简单的东西，比如音乐和歌词，检测到用户在偶然时刻通过软件使用它们，可增进图谱对结构化知识的理解。如今，脸书产品的许多体验都由知识图谱提供支持。
覆盖范围、正确性、结构性和变动性都驱动着脸书知识图谱的设计。
● 覆盖范围 是指在要建模的领域中尽可能地详尽。默认设定是多来源产品，这意味着整个图谱生产系统是建立在这样的假设之上：数据将从多个来源接收，所有数据来源都提供有关重叠实体集（有时会相互冲突）的信息。脸书知识图谱以两种方式处理冲突的信息：如果该信息的置信度足够低，则可丢弃；或通过保留来源和关于断言的置信度推断值，将冲突的观点合并到实体中。
● 正确性 并不意味着知识图谱总是知道属性的“正确”值，而是它总是能够解释为什么做出某个断言。因此，它保留了流经系统的所有数据（从数据获取到服务层）来源。
● 结构性 意味着知识图谱必须是自描述的。如果某条数据未进行强类型化或属于不适合描述实体的架构，则图谱系统将尝试执行以下操作之一：将数据转换为期望的类型；提取与类型相匹配的结构化数据；或完全忽略它。
● 变动性 是指脸书知识图谱旨在不断变化。该图谱不是数据库中收到新信息时会更新的单一的表示形式，而是每天从源头持续不断地构建知识图谱，并且构建幂等的系统，最终生成完整的图谱。
脸书知识图谱的起点显然是脸书页面生态系统。企业和个人在脸书上创建页面，以代表各种各样的想法和兴趣。此外，让页面的所有者对其进行断言可作为有价值的数据源。但是与任何众包数据一样，它也遇到了困难。
脸书的页面是面向公众的，每天都有数百万人在上面互动。因此，页面所有者的关注点并不总是与知识图谱的构建要求保持一致。
最常见的情况是，页面和实体没有严格的1:1映射，因为页面可以表示实体的集合（例如电影特许经营权），数据也可以是不完整的或非结构化的（例如文本片段），这使得它在知识图谱的上下文中更加难以使用。
脸书的最大挑战是利用其页面上找到的数据，并将其与其他更结构化的数据源结合起来，以实现干净、结构化的知识图谱的目标。对于脸书来说，一种有效的手段是将图谱视为模型，将脸书页面视为视图（保存在图谱中的实体或实体集合的投影）。
易趣
易趣正在构建其产品知识图谱，它将对产品、实体，二者之间的相互关系以及同外部世界的关系等进行语义知识编码。这些知识将成为理解卖家供应与买家需求并将两者有机融合的关键，同时也是易趣市场技术的重要部分。
例如，易趣的知识图谱能够将产品关联到现实世界中的实体，从而给出产品的定位以及吸引买家的因素。比如芝加哥公牛队的队服只是一个普通商品，但如果它是迈克尔·乔丹(Michael Jordan)的签名款，那么它就是个完全不同的商品。
知识图谱中的实体也可以将不同的产品联系起来。如果一个用户搜索了关于莱昂纳尔·梅西(Lionel Messi)的纪念品，而知识图谱中显示梅西效力于巴塞罗纳富特博尔足球俱乐部，那么这名用户可能也会对该俱乐部的其他相关商品感兴趣。这个想法也可以从体育扩展到音乐、电影、文学、历史事件以及更多其他领域。
理解商品自身以及商品之间的关系也和理解实体之间的关系一样重要。能够区分一个商品是iPhone，而另一个是iPhone手机壳显然是很重要的。但是，不同的手机壳仅能够适用于某些型号的手机，与其他型号的手机并不适配，所以易趣需要能够对零件以及配件的尺寸进行建模。理解商品及其相关产品之间的关系也是很重要的。比如，哪些商品是同一商品的不同款式？它们在尺寸、容量或颜色上有没有区别？还是说它们有着大部分相同的特性，但可能是不同的品牌或颜色？系统还需要理解有些商品往往是捆绑销售的，比如捆绑包、套件，抑或是成套的时装。
和其他知识图谱一样，易趣构建的知识图谱也必须要解决数据大规模增长所带来的问题。在任意时间点都可能有超过数十亿的、遍布数千个种类的在售商品列表，这些列表可能包含数以亿计的商品以及数百亿种属性。
易趣的知识图谱包含很多不同的用户，这些用户位于不同的服务层次上，他们的需求存在着巨大的差异。当在搜索服务中解析一个用户的意图时，知识图谱必须在几毫秒内返回结果。随着数据规模的增大，大规模的图请求可能会花费数小时来产生结果。
为了应对这些挑战，易趣的工程师设计了一个能够同时保证灵活性和数据一致性的架构。该知识图谱使用了一个可供复制的日志来记录所有对图结构的写入和修改。日志能够提供数据一致性的保证。这种方式提供多后端数据存储以应对不同的使用需求。具体来说，有一个扁平化的文档存储库，用于提供低延迟的搜索查询；还有一个图结构存储库，用于进行长时间运行的图分析。其中每一个存储库都只需简单地将其操作写入日志中，并按顺序获取对图谱的添加和修改。因此，这些存储库能够保持一致性。
IBM
IBM开发了WatsonDiscovery服务及其相关产品所使用的知识图谱框架，并在IBM以外的许多行业环境中进行了部署。IBM Watson以两种不同的方式使用该知识图谱框架：首先，该框架直接用于驱动Watson Discovery，主要专注于使用结构化以及非结构化的知识，来发现新的信息为Discovery的下游产品提供服务；其次，该框架允许其他人以预先构建的知识图谱为核心来构建自己的知识图谱。
Discovery的用例创建不直接出现在域文档或数据源中的新知识。这些新的知识甚至可能是人类以往没有意识到的。虽然现有的搜索工具能够访问系统可用资源中已有的知识，这些知识对于Discovery来说是必要的，但并不足够。新的发现包括实体之间的新链接（例如，药物的新副作用、作为收购目标的新公司等），该领域中潜在的新的重要实体（例如，用于显示技术的新材料、特定投资领域的新投资者等），或现有实体发生的重要变化（组织中投资者在组织中增持股权，或在情报收集场景中增加利益相关者与犯罪分子之间的互动等）。
鉴于IBM具有广泛的企业客户基础，在各个领域应用了认知技术，IBM专注于为客户和客户团队创建框架来构建自己的知识图谱。IBM的行业团队利用此框架来构建特殊领域的实例。它的客户存在于多个领域，从银行、金融、保险、IT服务、媒体和娱乐、零售和客户服务等面向消费者的研究，到几乎完全专注于深度发现的行业，尤其是生命科学、石油和天然气、化工和石油、国防和太空探索等科学领域。这种应用广度要求框架具有客户自己构建和管理知识图谱所需的所有功能。框架中内置的一些关键技术包括文档转换、文档提取、段落存储和实体规范化。
接下来，是一些IBM工程师从为Watson Discovery构建知识图谱并在其他行业中部署该系统所学到的一些关键经验和教训。
● 应用多态存储 IBM Watson知识图谱使用多态存储，支持多种索引、数据库结构、内存数据库和图存储。这种架构会将实际数据（通常是冗余的）分布到一个或多个存储库中，从而使每个存储库都能满足特定的需求和工作负载。IBM工程师和研究人员解决了许多挑战，例如如何保持这些多存储库同步，如何通过微服务在存储库之间进行通信，以及如何以不重新加载或重建整个图的方式吸收新知识或重新处理原始数据。
● 保留原始“证据” 知识的“证据”是指将现实世界（开发人员通常尝试对现实世界进行建模）与包含着知识的数据结构联系起来的内容。这些证据通常是作为人类知识来源的一些原始文档、数据库、字典或图像、文本和视频文件等。在知识发现过程中进行有针对性的上下文查询时，元数据和其他相关信息通常在知识推断中发挥着重要的作用。因此，保证存储在图中关系的来源不丢失是至关重要的。
● 推迟实体消歧 解决由于使用部分名称、字面表达或者具有相同名称的多个实体导致的指代消歧问题是理解自然语言的经典问题。然而，在知识发现领域，开发人员通常会寻找一种潜在的模式，比如某个实体的活动方式并不为人熟知，或者出现在了一个新的语境中，那么可能发现了新的实体。因此，在知识图谱的创建过程中过早地进行实体消歧是和知识发现的目标相冲突的。所以，最好保留这些未解析的语句或将其消除歧义留给多个实体，然后在运行时查询上下文来解析实体名称。
今后的挑战
本文讨论的知识图谱的需求、覆盖范围和体系结构相差很大，但是在大多数实现中面临着相同的挑战。多年来，这些挑战一直处于研究的最前沿，但它们仍然使从业人员感到困惑。问题的严峻性因不同的应用环境而异。
实体消歧和标识管理
简单来说，该挑战是给定一个语句或者实例，确定它独有的规范化标识和陈述类型。许多自动提取的实体具有非常相似的字面形式，例如具有相同或相似标题的电影、歌曲和书籍。没有正确的链接和消歧，实体将与错误的事实相关联，并导致下游的错误推断。
尽管这些问题在较小的系统中已经足够明显，但在一个数据规模较大的系统中进行标识管理时，该问题将变得更具挑战性。如何进行标识描述，使不同的团队能够达成一致，并知道其他团队在描述什么？开发人员如何确保有足够的可读信息来判定冲突？
实体类型和类型解析
大多数当前的知识图谱允许每个实体具有多种类型，并且特定的类型在不同的情况下有不同的作用。例如，巴拉克·奥巴马(Barack Obama)是一个人，也是一个政治家和演员。虽然他作为一个政治家很出名，但不是所有人都知道他是个演员。古巴可以指一个国家，也可以指其政府。在某些情况下，知识图谱系统将类型分配推迟到运行时：每个实体描述其属性，应用程序根据不同的用户任务使用特定的类型和属性集合。
虽然定义类型成员的标准起初可能很简单，但是随着实例的增长，在保持语义稳定性的同时执行这些标准就变得很有挑战性。例如，谷歌当初为其知识图谱定义“运动”类别时，还不存在“电子竞技”这一类别。那么，谷歌是如何将电子竞技融合进来的同时，还可以维持运动类别标识呢？
知识演化和知识管理
有效的实体链接系统还需要根据其不断变化的输入数据进行有机增长。例如，公司可能会合并或拆分，新的科学发现可能会把现有的一个实体分解成多个实体。当一家公司收购另一家公司时，收购公司是否改变身份？如果一个部门被剥离出去会怎么样？身份标识是否随着命名的获得而产生？
虽然大多数知识图谱框架在存储知识图谱的某个时间点的版本和管理知识图的瞬时变化方面变得越来越有效，但是距离管理图谱中高度动态的知识仍然有一定差距[4]。要捕捉这些变化，需要一些对时间结构、历史以及对历史变化的基本理解。此外，还需要能够通过多个存储库（例如，IBM的多态存储）管理更新的能力。
对于更新过程的完整性、最终一致性、冲突的更新以及简单的运行时性能来说，有很多需要考虑的因素。不仅需要考虑现有分布式数据存储的不同变体，而且要处理增量级联更新。管理不断变化的模式和类型系统也很重要，但要避免与系统中已有的知识产生不一致。例如，谷歌通过将元模型层概念化为多层来解决此问题。较底层的部分保持不变，而较高层的部分通过元类型（实际上是类型的实例）的概念构建，从而丰富类型系统。
从多个结构化及非结构化源中抽取知识
尽管最近科学界在自然语言理解方面取得了诸多进展，但结构化知识（包括实体、它们的类型、属性和关系）的提取仍然面临着全面挑战。扩展大规模知识图谱不仅需要手动方法，还需要从开放域中的非结构化数据中通过无监督和半监督的方式提取知识。
例如，在易趣产品知识图谱中，许多图中的关系是从清单和卖家目录中的非结构化文本中提取的；IBM Discovery知识图谱依赖于文档作为图中所表示的事实的证据。传统的有监督机器学习框架需要大量的人力进行手工标注来训练知识提取系统。通过采用完全无监督的方法或半监督的技术可以减轻或消除手工标注带来的高成本问题。实体识别、分类、文本和实体嵌入都是可将非结构化文本链接到图中已知实体的有用工具[3]。
大规模管理运营
本文描述的所有知识图谱系统都面临着大规模图谱管理的问题，规模增大通常会使很多在学术界已经以多种形式解决的问题（例如消歧和非结构化数据提取）重新在工业界出现。大规模管理运营是一个基本的问题，它直接影响与性能和工作负载相关的几个操作。它还会间接影响到其他的相关操作，例如在IBM中管理大型知识图谱的快速增量更新的问题，以及在谷歌中维护大型演进知识图谱的一致性问题[1]。
其他的关键问题
除了以上真正普遍存在的问题之外，以下问题对于本文所述的工作也至关重要，这些是学术界普遍感兴趣的问题。
知识图谱语义嵌入
利用大规模知识图谱，开发人员可以构建实体和关系的高维表示形式。由此产生的嵌入表示(embeddings)将能极大地帮助许多机器学习、自然语言理解和AI任务，成为这些任务使用的特征和约束的来源，并且可以作为进行更复杂的推理和整理训练数据方法的基础[2]。
知识推理及其验证
确保事实正确是构建知识图谱的核心任务，但在大规模知识图谱中，不可能手动验证所有内容。这就需要一种自动化的方法：知识表示和推理、概率图模型和自然语言推理的进步，可以用来构建用于一致性检查和事实验证的自动或半自动系统。
全局、领域相关以及客户相关知识的融合
在像IBM客户这样构建自己的定制知识图谱的情况下，客户不需要告诉知识图谱一些很基础的知识和信息。例如，一位癌症研究人员不需要告诉知识图谱皮肤是一种组织，或者圣裘德(St. Jude)是田纳西州孟菲斯市的一家医院。这样的一些“常识”，能够直接在通用知识图谱中获取到。
更深入一步的知识是领域内众所周知的信息。比如“carcinoma”（癌症）就是“cancer”（癌症）的一种表述形式；NHL更有可能是表示“非霍奇金淋巴瘤”，而非“国家曲棍球联盟”。客户应该只需要输入与客户相关的私域信息或者系统尚不知道的任何其他知识。因此，知识图谱的基础和专业领域部分的解离、融合以及在线更新的问题成为了主要的问题。
私人设备中知识图谱的安全性和隐私性
从定义上来说，知识图谱是巨大的，因为它试图为世界上的每个名词创建一个实体，因此只能在云中合理地运行。但是实际上，大多数人并不关心世界上存在的所有实体，而是关心与个人相关的一小部分或子集。在个人用户使用的个性化知识图领域，前景十分广阔，可能要看它们能否缩小到足够小的尺度，以便迁移到移动设备上。这将允许开发人员能够通过在本地小知识图谱实例上进行更多的设备端学习和计算，从而持续地以尊重隐私的方式为用户提供价值。
多语言知识系统
全面的知识图谱必须涵盖以多种语言表达的事实，并将通过这些语言表达的概念融合在一起。除了从多语言来源提取知识方面的挑战外，不同的文化描述世界的方式也有细微的差别，这也给本体设计带来了挑战。
结论
从本文的讨论可以引申出一个问题，不同的知识图谱是否有一天可以共享某些核心内容，例如对人物、地点和相似实体的描述。共享这些描述的方法之一是将它们作为一个通用的多语言核心提供给维基数据(Wikidata)。
知识表示是一项在实践中难以解决的问题。随着发展速度和规模的扩大，知识表示方法的选择影响着用户探索知识核心的环境。正如本文讨论所证明的那样，知识表示在不同行业中都十分重要，因此同数据结构和算法一样，知识表示应成为计算机科学课程的基本组成部分。
最后，我们都认同人工智能系统将为企业在如何与客户互动的方面创造新的机会，在他们的领域中创造独特的价值，并改变他们的运营方式。为了实现这一愿景，这些企业必须了解如何构建可以发掘知识的新系统，使它们成为真正智能的企业。
脚注
* 本文译自Communication of the ACM, “Industry-Scale Knowledge Graphs: Lessons and Challenges”, 2019, 62(8):36~43一文，有删节。
参考文献
[1] Höffner, K., Walter, S., Marx, E., Usbeck, R., Lehmann, J. and Ngonga Ngomo, A.C. Survey on challenges of question answering in the semantic Web. Semantic Web 8, 6 (2017), 895-920.
[2] Lin, Y., Liu, Z., Sun, M., Liu, Y. and Zhu, X. Learning entity and relation embeddings for knowledge graph completion. In Proceedings of the Assoc. Advancement of Artificial Intelligence 15, (2015), 2181-2187.
[3] Nickel, M., Murphy, K., Tresp, V. and Gabrilovich, E. 2016. A review of relational machine learning for knowledge graphs. In Proceedings of the IEEE 104, 1 (2016), 11-33.
[4] Paulheim, H., Knowledge graph refinement: a survey of approaches and evaluation methods. Semantic Web 8, 3 (2017), 489-508.
作者简介
京公网安备 11010802032778号