在生成式 AI 应用开发或微调等技术中，知识图谱可以发挥关键作用。对于 SAP 而言，知识图谱是利用其独特的结构化和非结构化知识资产（如业务数据模型、业务流程元数据和文档等）实现生成式 AI 场景的关键手段。知识图谱有助于为 LLM 打下基础、解决幻觉等挑战，并为 SAP 基础模型提供语义。

1、知识图谱的背景

    让我们从一个简单的实验开始：使用您最喜欢的 Web 搜索引擎并输入“SAP SE”。您会得到什么结果？答案是：除了网页列表之外，您还将看到从知识图谱中提取的 SAP 综合概述。知识图谱的部分内容在图1中进行了可视化。

图 1：SAP SE 及其相关实体的知识图谱的一部分

    “知识图谱”这一术语于 2013 年被引入。如今，知识图谱已成为我们日常网络搜索体验的常见组成部分。在我们的实验中，搜索结果不仅包括带有字符串“SAP SE”的网页列表，还提供了有关实体“ SAP SE”的结构化和互连信息网络。这证明了知识图谱的一个关键方面：它们编码的是“事物，而不是字符串”，即：实体、它们的属性以及与其他实体的关系。

    在知识图谱中，您将看到实体“SAP SE”的属性，例如其描述或 SAP 网站的链接。您还将看到与知识图谱中其他实体的关系，例如 SAP 总部。例如，单击“Walldorf”将带您进入 Walldorf 的知识图谱条目，其中包括其他类型的属性和关系，例如人口“14,646”和与实体“Karlsruhe”的“地区”关系。

    您可以从此示例中了解到知识图谱的另一个方面：实体、它们的属性和关系都是基于现有的异构数据源生成的。与使用具有统一模式的数据仓库的其他数据集成方法相比，这些数据源之间没有通用的数据模型。对于公司、个人或城市等各种类型的实体，知识图谱模型是以数据和用例驱动的方式创建的。对于“人”或“公司”等实体，并不存在完美的知识图谱模型，只有或多或少适合给定用例的模型。

    基于 Web 的知识图谱中经常使用的数据源是 Wikipedia。根据给定用例所需的实体类型及其属性或关系，其他数据源也会发挥作用。我们在这里看到的示例用例是“提供财务信息”（如股票价格）和“提供基于位置的信息”（如“当前天气”）。实现这些用例意味着添加来自多个不相关数据源的信息，例如提供 SAP SE 当前股票价格或当前城市天气的数据库。

    知识图谱实现了对于松散耦合的数据源的集成，并提供了 一个灵活的信息访问层，该层由用例驱动扩展，无需紧密的数据集成。它们跨越了底层异构数据源的边界，例如在我们的示例中，包含维基百科、股票市场信息数据库和天气数据库等。

    知识图谱还允许在信息网络中自由地探索。从您搜索的实体（例如“SAP SE”）中，您可能会发现其他您不知道的实体、属性和关系：您知道沃尔多夫是卡尔斯鲁厄地区的一部分吗？知识图谱的丰富的语义关联能力为新用例甚至商业机会打开了大门，以新的方式将现有数据源资产化。

2. 关联业务数据的知识图谱

    SAP S/4HANA 是一款企业资源规划软件，旨在涵盖企业的所有日常业务流程，包括从订单到现金、从采购到付款、从计划到产品、从请求到服务等。自 2015 年推出 SAP S/4HANA 以来，该软件已被客户广泛采用。人们可以在许多不同的来源找到技术文档、教程和说明。在如此多样化的信息世界中，找到一个完整的单一事实来源是一项艰巨的任务。业务知识图谱正是为解决这个问题而开发的：将业务数据整合在一起，并在上下文和与其他对象的关系中对数据进行建模，本质上形成链接的业务数据。

    现在让我们进行另一项实验，或者更确切地说，提出一个要求：我们希望使用 SAP S/4HANA 系统中的数据进行生成 AI。数据驻留在表中，其名称只有领域专家才能理解，例如“EKKO”。如果没有 SAP 数据模型领域的深厚知识，生成 AI 应用程序的开发人员以及LLM就无法理解这些数据。知识图谱可以为开发人员和LLM提供帮助。图2显示了此类知识图谱的一部分。

图 2：业务元数据和底层数据源知识图谱示例

    知识图谱包含实体、属性和关系。实体类型包括 ABAP 表（如“EKKO”）、业务对象（如“采购订单”）或来自 OData API 的实体集。知识图谱的一个关键价值是它将业务对象存储为事物（即图中的实体），而不是字符串。与知识图谱中的所有实体和关系一样，业务对象具有全局和唯一标识符，从而可以灵活地集成新的（元）数据源。通过“相关业务对象”关系，它们构成了跨领域特定元数据项的可扩展语义访问层。通过这种方式，知识图谱实现了我们的要求并实现了对表“EKKO”的语义访问。

    与前面围绕 Web 搜索的示例一样，一些之前并未直接连接的数据源开始发挥作用。其中包括 SAP S/4HANA 数据字典、SAP 文档、业务对象存储库和 API 定义。知识图谱以用例驱动的方式关联这些数据源，而不会试图“煮沸大海”。例如，我们迭代式扩大知识图谱，并仅添加给定用例所需的 OData API 定义部分。知识图谱的分散性质实现了“跟着你的鼻子走”的原则。例如，在确定了 SAP 数据库表 EKKO（采购单据标题）的业务对象“采购合同”后，您可以找到您未知的链接实体，如 CDS 视图“I_PurchaseContract”或 OData 实体集“I_PurchaseContract”，这些实体可以触发新的用例。

    知识图谱生成过程涵盖知识图谱生命周期的四个常见步骤：数据提取、建模、知识图谱生成和知识图谱提供。

    （1）从各种 SAP 内部和外部数据源提取元数据（用于 ABAP 表、业务对象、CDS 视图等）。

    （2）为用例定义目标图谱模型。该模型仅捕获我们的用例所需的实体类型及其属性，即我们不会在知识图谱中反映源数据的所有方面。

    （3）我们将提取的数据转换至目标图谱模型。

    （4）将数据上传到知识图谱数据库，并通过 API 将图谱能力提供给应用程序。

    在向量数据库中对图谱的各个部分进行索引的附加步骤是我们用例的一部分，这可以通过知识图谱有效增强大模型的RAG能力。

    总结一下，通过上述业务元数据知识图谱，我们创建了一个由 SAP 业务知识资产组成的语义访问层，该层由用例驱动，随着时间的推移以灵活和迭代的方式增长。这样，我们对开发人员和 LLM 的领域知识要求就更少了。知识图谱将逐步增长。每次扩展知识图谱的新迭代都可以利用现有的知识图谱建模。例如，文档记录较差的 OData 实体集可以从互连的SAP Core Data Services (CDS) 视图和业务对象提供的语义中受益。

    知识图谱非常适合在单一位置表示结构化和非结构化数据。我们可以轻松地将“采购订单”表示为知识图谱中的单个对象，并在此唯一对象上定义新关系，只需添加一个链接，其余部分保持不变。我们也可以根据需要使用业务数据简单地扩展知识图谱，并根据用例包含或排除来源。

3. RDF作为知识图谱的技术基础

    我们生成、存储和查询知识图谱的技术基础是图数据模型 RDF（资源描述框架），这是 W3C（万维网联盟）开发的一套标准。下面的 RDF 源代码包含可视化背后的 RDF 数据。

    RDF 代码片段使用RDF 海龟语法。从第 1 行到第 12 行，为对象类（例如ABAPTable ）或属性（例如s4:relatedBusinessObject）定义了前缀。RDF 属性既可用于定义与其他类的关系（例如s4:baseTable关系），也可用于引用值（例如cds:description）。

    该示例还展示了RDF 词汇表的作用，这里通过前缀进行标识（RDF 还允许通过OWL或SHACL等技术为词汇表创建形式模型）。根据用例需求，我们可以创建和扩展我们自己的 SAP 特定词汇表，并将它们与SKOS等公共词汇表相结合。词汇表是实现前面提到的知识图谱区分“事物与字符串”能力的关键手段。例如，我们可以区分两个具有相同名称I_PURCHASECONTRACT的不同实体，因为它们属于两个不同的词汇表：cdsview:I_PURCHASECONTRACT与entitySet:I_PURCHASECONTRACT。

    示例中的实际 RDF 数据在第 14 行的前缀定义之后开始。RDF 图具有所谓的三元组的概念。关系的起始节点是主体（第 14 行abatable:EKKO），关系是属性或谓词（第 14 行s4:relatedBusinessObject），关系的目标是对象（第 14 行bo:PurchaseOrder）。

    尤其是在知识图谱和生成式 AI 领域，标记属性图(LPG) 的图数据模型受到多家图谱工具供应商的高度关注和支持。图数据模型之间的选择是一个持续讨论的话题，为此，SAP 正在参与 W3C RDF Star 工作组，该工作组将促进 RDF 和 LPG 之间的互操作性。

    我们之所以选择 RDF，是因为其词汇表等功能是我们知识图谱方法的关键部分：以去中心化的方式创建和发展知识图谱，由用例驱动。通过这种方式，各个团队可以扩展知识图谱。这里，“各个团队”是指 SAP 内部的团队，以及 SAP 外部的团队（展望未来），也就是说，SAP希望让合作伙伴和客户能够创建自己的知识图谱内容。

4. 无基础的LLM与知识图谱

    网络上有大量关于 SAP 知识资产的信息，LLM也将其作为训练数据的一部分。因此，问题来了：为什么不能直接使用LLM来利用 SAP 的业务元数据？

    我们用另一个实验来解释原因。首先，我们向 LLM 提出问题“CDS 视图 I_PURCHASECONTRACT 的基表是什么？”。然后我们将结果与知识图谱查询进行比较。两种方法的结果显示在图3中。

图 3：LLM 的幻觉与业务元数据知识图谱提供的已验证信息相比

    图左侧的 LLM 的回复提供了一些合理的猜测。但 LLM 也表示无法提供精确的答案。而且，即使是猜测，作为用户，我们也无法验证 LLM 结果的正确性。

    打好基础可以提高 LLM 的答题质量。在某些情况下，使用知识图谱是一种非常好的技术。对知识图谱的查询提供了准确的响应。CDS 视图具有使基表显式化的关系。由于我们根据受信任的 SAP 元数据源生成了图谱，因此响应真实、准确且可靠。

5. 知识图谱与检索增强生成

    前面提到的 LLM 不了解 SAP 知识资产的局限性，可以通过检索增强生成(RAG) 结合知识图谱 (称为GraphRAG ) 来解决。我们将在示例查询“CDS 视图 I_PURCHASECONTRACT 的基表是什么？”中简要解释 RAG 和知识图谱之间的相互作用。

    在 RAG 中，数据以向量嵌入的形式存储在向量数据库中。检索和响应生成涉及 LLM为数据块生成嵌入。然后将自然语言中的用户问题与向量数据库进行匹配。具有与问题匹配的向量表示的块用于生成对问题的响应。

    对于查找基表的用例，我们可以将 CDS 视图的基表信息存储在文档中，并在向量数据库中对其进行索引。这样就可以仅通过 LLM 来检索基表。

    这种方法的问题在于，在 SAP 的知识资产中，实体之间存在许多关系，例如 CDS 视图、ABAP 表和业务对象。因此，我们无法将所有可能与用例相关的关系编码为给定实体的块。例如，CDS 视图并不总是直接连接到其基表。如果我们想要捕获基表关系，我们将需要重新生成索引。对于与用例相关的任何其他远距离关系，都必须这样做。

    重新生成向量索引的方法既耗时又耗费计算资源，而且也不如图图 2中所示的知识图谱查询精确：即使基表关系存储在一个块中，基于向量的检索也可能对同一用户查询提供不同的响应。

    尽管存在这些限制，但在生成式 AI 中使用向量数据库仍具有巨大的优势。自然语言访问是知识图谱所缺乏的一项关键功能。人们可以向 LLM 提问，或者通过 LLM 向向量数据库提问并得到答复。仅靠知识图谱是无法做到这一点的。

    未来的发展方向是通过 GraphRAG 结合两全其美的优势：可以使用 LLM 来访问知识图谱中经过验证的信息。图4显示了这通常是如何工作的，虽然它没有涉及实施细节。

图 4：结合两个领域的优点：通过 LLM 访问知识图谱

    作为整个工作流程的设计时步骤，我们提取知识图谱中记录良好的节点。此提取通过 RDF 查询语言SPARQL实现。下面的 SPARQL 查询选择所有 CDS 视图并对其描述以及相关业务对象的描述进行分组。

    CDS 视图cds:I_PURCHASECONTRACT的查询输出如下。

    这被导入到向量数据库中。然后通过 cds 视图 ID 唯一地标识每个块。块的嵌入是根据提取的文本信息生成的。经过此设计时准备步骤后，系统即可在运行时使用，如下所述。

    用户询问有关基表的问题。LLM 将问题中的实体I_PURCHASECONTRACT与向量数据库进行匹配。向量相似性处理会从知识图谱中找到具有cdsview:I_PURCHASECONTRACT唯一标识符的块。

    使用此标识符和有关 RDF 属性（如s4:baseTable ）的信息，可以生成知识图谱查询。在我们当前的场景中，为了确保生成可靠的 SPARQL，此步骤基于预定义的查询模板，该模板中填充了 CDS 视图 ID。查询的结果是表名 EKKO。

    然后向用户提供响应EKKO 。

    结合 LLM 和知识图谱的好处可以总结如下：

• 我们支持对 SAP 独特知识资产进行自然语言探索；

  
  

• 我们确保对与 SAP 数据模型相关的查询提供最新且相关的响应；

  
  

• 我们避免幻觉和不相关的结果；

  
  

• 我们确保特定领域的结果，同时利用 LLM 功能的优势，例如排名结果；

  
  

• 我们通过支持数据沿袭和可追溯性来明确数据来源。

  
  

    我们相信在数据的独特上下文中以及与其他对象的关系中呈现数据的力量。只有这样，我们才能将隐性变为显性，充分利用我们多年来收集的丰富企业数据，为客户提供价值。

6. 有无知识图谱情况下的LLM效果评估

    我们对实施效果进行了评估，其证明了知识图谱的价值。我们使用了一组小型评估业务问题和适合回答这些问题的 CDS 视图或 ABAP 表。这些问题是由 S4 领域专家和数据科学家创建的，他们是我们场景中的主要用户群。下表总结了实验结果。

    我们针对大约 5,400 个公共 CDS 视图和大约 3,000 个 ABAP 基表，针对 22 个业务问题进行了实验。整个图包含 80,000 个 CDS 视图和 450,000 个 ABAP 表。LLM 应该从 Web 文档中了解公共 CDS 视图。不过，单纯LLM 的表现比依赖知识图谱的方法差得多。而且由于知识图谱结果始终基于对图谱的查询，因此根本没有幻觉。

    与公共 CDS 视图相比，ABAP 表的文档内容较少。但通过向量相似性搜索选择 CDS 视图 ID 后，我们可以使用前面描述的 SPARQL 基表查询检索 ABAP 表。这解释了我们对 ABAP 表的良好表现：检测到了 70% 以上的正确表。对于仅使用 LLM 的方法，只有 30% 的结果是正确的，而且 LLM 再次产生了幻觉。

7、知识图谱和LLM的展望

    本文述了知识图谱如何使生成式 AI 受益。文章以 SAP S/4HANA 为重点，以知识图谱中的示例为例，解释了知识图谱如何解决幻觉风险并支持生成式 AI 应用程序的开发，其关键区别在于：SAP 独特的知识资产，以语义明确且值得信赖的方式进行编码。

    我们目前正在研究知识图谱的几个用例。用例领域包括：1）在 AI 应用程序的设计时和运行时支持数据模型发现和配置；2）为 AI 应用程序明确数据沿袭和数据来源，作为对可信和可解释 AI 的关键支撑；3）为 SAP 的结构化数据基础模型提供语义。此外，我们正在与多个伙伴 合作，研究如何使用 SAP 生态系统中的大量非结构化数据来丰富我们当前的知识图谱，我们正在研究如何让 SAP 顾问、合作伙伴和客户使用他们自己的内容来扩展知识图谱。