SAP利用知识图谱为大模型打基础防幻觉

生成式AI应用开发或微调，知识图谱到底能做什么？答案是：关键角色。对于SAP来说，知识图谱是把那些结构化和非结构化的知识资产——业务数据模型、业务流程元数据、各类文档——整合起来，支撑生成式AI场景的关键手段。它能为LLM打下基础，解决幻觉问题，还能给SAP的基础模型注入真正的语义。

1、知识图谱的背景

不妨先做个最简单的实验：打开你最喜欢的搜索引擎，输入“SAP SE”。结果是什么？除了网页列表外，一定会出现一个来自知识图谱的SAP综合概述。图1就展示了这个知识图谱的一部分。

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

“知识图谱”这个概念在2013年才被正式提出，如今早已融入我们的日常搜索体验。刚才那个实验里，搜索结果不只是带“SAP SE”字样的网页清单，而是给出了关于这个实体的结构化和互联信息网络。这就点出了知识图谱的核心特征：它们编码的是“事物，而不是字符串”——也就是实体、实体的属性以及实体之间的关系。

在这个图谱中，能看到“SAP SE”的属性，比如它的描述、官网链接，还能看到它和其他实体的关系，比如总部所在地。点击“Walldorf”就会跳转到这个城市的知识图谱条目，那里又包含了新的人口数据“14,646”、和“Karlsruhe”的“地区”关系等。

通过这个例子，另一个关键点也浮出水面了：实体、属性和关系都来自现有异构数据源。这些数据源之间没有统一的数据模型，跟那种用统一模式的数据仓库做法完全不同。对于公司、个人、城市这类五花八门的实体类型，知识图谱模型是数据和用例驱动的。没有完美的“人”或“公司”模型，只有更适合特定场景的模型。

基于Web的知识图谱，最常用的数据源是Wikipedia。当然，实际用例需要什么类型的实体、属性或关系，其他数据源也会被拉进来。这里的示例是“提供财务信息”（比如股票价格）和“提供基于位置的信息”（比如当天天气）。要搞定这些场景，就需要把多个不相关的数据源信息整合到一起，比如提供SAP SE实时股票价格的数据库、提供各个城市天气的数据库。

知识图谱的一大价值，就在于实现了松散耦合数据源的集成，并提供一个灵活的信息访问层。这个层由用例驱动，可以不断扩展，不需要做那种紧耦合的数据集成。它跨越了底层异构数据源的边界，就像我们实验里那样，整合了维基百科、股票市场数据库、天气数据库。

知识图谱还允许在信息网络中自由探索。从你搜索的“SAP SE”出发，你可能会发现一些之前不知道的实体、属性和关系——比如沃尔多夫是卡尔斯鲁厄地区的一部分。这种丰富的语义关联能力，为新的应用场景甚至商业机会打开了大门，能以全新方式把现有数据资产变&现。

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

SAP S/4HANA是一款企业资源规划软件，覆盖企业的几乎所有日常业务流程，从订单到现金、从采购到付款、从计划到产品、从请求到服务。2015年推出以来，它被大量客户采用。关于它的技术文档、教程和说明散落在五花八门的来源里。要想在这片信息海洋里找到一个完整的、单一的事实来源，几乎不可能。业务知识图谱就是为了解决这个难题而生的：把业务数据整合在一起，在上下文和其他对象的关系中对数据进行建模，本质上就是把业务数据链接起来。

现在再提一个要求：我们希望用SAP S/4HANA系统中的数据来做生成式AI。数据都躺在表里，表名只有领域专家才懂，比如“EKKO”。没有深厚的SAP数据模型知识，生成式AI应用的开发者和LLM根本无从下手。知识图谱可以帮到他们。图2展示了这类知识图谱的一个片段。

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

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

和前面Web搜索的例子类似，一些原本没有直接连接的数据源也开始发挥作用，比如SAP S/4HANA数据字典、SAP文档、业务对象存储库和API定义。知识图谱是“用例驱动”的，不像要去“煮沸大海”。比如我们可以迭代式地扩大图谱，只添加给定用例所需的OData API定义部分。这种分散的性质让“跟着你的鼻子走”成为可能：在确定了ABAP表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的答题质量，而在某些场景下，知识图谱恰好是一种优秀的技术。对知识图谱的查询总能提供准确的响应——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的表现明显差于依赖知识图谱的方法。而且，因为知识图谱的结果始终基于对图谱的查询，幻觉率是0。

ABAP表的文档内容比公共CDS视图少。但通过向量相似性搜索选出CDS视图ID后，我们可以用前面描述的SPARQL基表查询检索到ABAP表。这就解释了为什么ABAP表的表现也很不错：检测到了超过70%的正确表。而只用LLM的方法，正确率只有30%，而且它还在产生幻觉。

7、知识图谱和LLM的展望

这篇文章阐述了知识图谱如何让生成式AI受益。以SAP S/4HANA为主角，用知识图谱中的具体例子，解释了知识图谱如何解决幻觉风险、支撑生成式AI应用开发。核心区别在于：SAP独特的知识资产，是以语义明确且值得信赖的方式编码的。

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：SAP利用知识图谱为大模型打基础防幻觉要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题