知识图谱是一种对现实世界实体及其关系的结构化表征。它通常存储在图数据库中，这类数据库能够原生地存储数据实体之间的关系。知识图谱中的实体可以表示对象、事件、情境或概念，而实体之间的关系则捕捉了它们如何连接的上下文与语义。

知识图谱将数据、关系与称为"组织原则"的框架共同存储。这些原则可被视为围绕数据的规则或分类，提供了一个灵活的概念性结构，以驱动更深层次的数据洞察。知识图谱的价值在于它通过组织原则、数据和关系的方式，为用户或业务呈现新的知识。这种设计适用于多种使用场景，包括实时应用、搜索与发现，以及为生成式AI的问答功能提供基础。

有时人们会过度复杂化知识图谱的概念。您可能听说过整合并连接数据孤岛和各类来源信息的企业级架构——这确实描述了知识图谱（能够支撑数据集成用例的一种），但这只是其广泛应用范围的一个方面。若仅从桥接大型数据集和多重数据源的角度思考，会使知识图谱的创建与实施显得复杂耗时。但知识图谱无需追求大而全，您完全可以通过更小的范围构建一个知识图谱来解决特定场景的问题。

知识图谱的工作原理

你可能听说过搜索引擎领域的知识图谱。Google 知识图谱改变了我们在网络上搜索和查找信息的方式。它将有关人物、地点和事物的信息汇集到一个有组织的实体网络中。当你在 Google 上搜索信息时，它会利用实体之间的联系，在上下文中呈现最相关的结果，例如，在 Google 称之为“信息框”的方框中。知识小组。”

谷歌知识面板上的圣家堂图片、地图、描述、地址、开放时间、建造它的建筑师、高度等等。

谷歌知识图谱中的实体代表了我们所知的世界，标志着信息处理方式从“字符串”向“实体”的转变。这句简单的短语背后蕴含着深刻的理念：将网络上的信息视为实体，而非一堆文本。由于信息是以实体网络的形式组织的，谷歌可以利用知识图谱的集体智慧，根据查询的含义而非简单的关键词匹配来返回定制结果。

主要特征

既然您已经了解了知识图谱如何组织和访问带有上下文的数据，接下来我们来看看知识图谱数据模型的基本组成部分。知识图谱的定义因人而异，但我们可以将其精髓提炼为三个关键要素：节点、关系和组织原则。

节点

节点用于表示和存储实体（例如人、地点、物体或机构）的详细信息。每个节点都有一个（有时是多个）标签来标识节点类型，并且可以选择性地具有一个或多个属性。节点有时也称为顶点。

例如，电子商务知识图谱中的节点通常代表实体，例如人（客户和潜在客户）、产品和订单：

人际关系

关系将两个节点连接起来：它们展示了实体之间的关联方式。与节点类似，每个关系都有一个标签，用于标识关系类型，并且可以选择性地包含一个或多个属性。关系有时也称为边。

在电子商务示例中，客户节点和订单节点之间存在关系，体现了客户与其订单之间的“已下单”关系：

组织原则

组织原则是一种框架或模式，它根据对当前用例至关重要的基本概念来组织节点和关系。与许多数据设计不同，知识图谱可以轻松地集成多个组织原则。

组织原则的复杂程度不一，从简单的（产品线 -> 产品类别 -> 产品分类）到复杂的（一套完整的业务词汇表，用于解释图表中的数据）。可以将组织原则理解为覆盖在图表中的数据和关系之上的概念图或元数据层。

该模型使用与知识图谱其余部分相同的节点和关系结构来描述组织原则——这意味着您可以编写从实例数据和组织原则中提取信息的查询。

以电子商务为例，组织原则可能是产品类型和类别：

本体论又如何呢？

在学习知识图谱时，你可能会遇到关于本体的文章，并疑惑它们在其中扮演什么角色。本体是对特定主题领域内概念及其相互关系的正式描述；语义网络是表示本体的常用方法。简而言之，本体是一种组织原则。

本体可能非常复杂，定义和维护都需要投入大量精力。在决定是否需要本体时，至关重要的是要考虑你试图用知识图谱解决的问题。在许多情况下，本体并非必要。例如，在电子商务示例中，对于产品推荐用例而言，使用产品分类法作为组织原则就足够了。

将知识图谱视为一个不断增长和演进的系统，它可以在早期阶段简化您的设计，并更快地交付价值。如果您选择合适的技术来实现知识图谱，就可以随着需求的变化扩展和演进图谱。这样，您就可以在用例需要时添加本体，而无需预先构建它们。

知识图谱示例

让我们来看看知识图谱是什么样子的。下图是一个简单的电子商务示例知识图谱，其中节点用圆圈表示，节点之间的关系用箭头表示。组织原则也以节点和关系的形式存储，因此图中使用了不同的颜色深浅来区分哪些节点和关系代表实例数据，哪些代表组织原则：

知识图谱和图数据库

创建知识图谱包括对图数据模型进行概念映射，然后将其实现到数据库中。虽然有很多数据库可供选择，但选择合适的数据库可以简化设计流程，加快开发和实施速度，并使其更容易适应未来的变化和改进。

属性图

原生属性图数据库，例如在新标签页中打开Neo4j是实现知识图谱的理想选择。它原生支持将信息存储为节点、关系和属性，从而实现直观易懂的建模。在新标签页中打开高度互连的数据结构可视化。物理数据库与概念数据模型相匹配，从而简化了知识图谱的设计和开发。使用属性图谱，您可以获得：

• 简洁易用的设计：属性图在设计知识图谱时可以实现直接的数据建模。由于概念模型和物理模型非常相似（通常相同），因此从设计到实现的过渡更加直接（也更容易向非技术用户解释）。
• 灵活性：无需进行大量重构或代码重写，即可轻松添加新的数据、属性、关系类型和组织原则。随着需求的变化，您可以迭代并逐步扩展知识图谱的数据、关系和组织结构。
• 性能：与 RDF 数据库或关系数据库等替代方案相比，属性图具有卓越的查询性能，尤其是在处理复杂遍历和多对多关系时。这种性能优势源于将实体间的关系直接存储在数据库中，而不是像查询那样使用连接操作重新生成关系。原生属性图数据库通过内存中的指针遍历关系，因此即使是遍历包含众多复杂关系的链式查询也能快速执行。
• 对开发者友好的代码：属性图支持直观且富有表现力的 ISO 查询语言标准，在新标签页中打开GQL的优势在于，与 SQL 或 SPARQL 相比，它需要编写、调试和维护的代码更少。Neo4j 的 Cypher 是 GQL 最广泛使用的实现。

属性图与三元组存储（RDF）

人们有时会想到在新标签页中打开属性图和三元组存储都是构建知识图谱的可行选择，但三元组存储（也称为 RDF 数据库）存在相当大的缺点。

基于资源描述框架 (RDF)，三元组存储采用细粒度的设计和存储方式。三元组存储以主语-谓语-宾语“三元组”的形式表示所有数据。此模型不支持带有属性的关系，也不支持实体之间存在多个同类型关系。为了满足实际应用场景，您需要实现一些变通方案。常见的变通方案包括将关系转换为对象（称为实体化）或使用单例属性，并通过额外的“类型”关系来捕获属性。这些变通方案会导致数据库规模更大、物理模型更复杂，以及查询性能下降。

由于实体化和单例特性迫使我们在设计之初就做出艰难的抉择，三元组存储并不适合解决涉及复杂数据域的实际问题。基于三元组存储构建的知识图谱设计起来更具挑战性，实现起来也更耗时，而且难以修改。

属性图与关系数据库

关系型数据库和其他非原生图方法都面临着类似的架构设计难题。关系型数据库和文档型数据库都不存储关系——它们必须在运行时通过查询代码中的连接或值查找来构建。由于关系存在于代码中而非数据集中，因此每个应用程序和数据使用都必须有自己的实现。SQL（关系型数据库查询语言）强制要求在查询本身中定义每个连接。因此，随着关系数量的增加，知识图谱的管理难度会越来越大，运行时性能也会下降。

知识图谱用例

知识图谱提供了一种强大的工具，用于存储和组织数据，从而帮助我们更深入地理解数据。为了了解企业是如何运用知识图谱的，让我们来看一些利用知识图谱解决特定问题的案例。虽然这并非一份完整的用例清单，但它提供了一系列具体的例子，展示了知识图谱在实际应用中的潜力。

面向企业搜索应用的生成式人工智能

在在新标签页中打开生成式人工智能应用和知识图谱能够捕获并组织关键的领域特定信息或公司专有信息。知识图谱不仅限于结构化数据，也能处理非结构化数据。

GraphRAG是一种利用知识图谱构建大型语言模型的技术，它正逐渐成为使用专有领域数据的 AI 应用（即 RAG 应用）的基础。知识图谱构建能够提高响应准确率，并通过数据关系提供的上下文信息增强可解释性。行业领导者德勤等机构强调了知识图谱在构建企业级基因人工智能（GenAI）中的关键作用。Gartner 认为知识图谱具有“高普及度”，是当今基因人工智能领域一项极具影响力的技术：