技术动态 | 基于SAP数据的生成式人工智能：大语言模型和知识图谱

转载公众号 | 知识管理就在夏博

---

我们已经在 SAP 中存储数据数十年了，数据量太大，因此我们使用数据仓库和类似技术。现在，借助 Transformer Models，我们有能力理解极其庞大的数据集。想象一下，我们向通用大语言模型展示 BKPF 和 BSEG 之间的关系，并回答有关它的查询。

我相信基础模型有能力重塑所有行业，但现有的大型语言模型在对复杂行业用例的适用性方面存在不足。从嵌入和微调通用基础模型，我慢慢地开始将垂直和特定领域的数据合并到模型中。我的最终目标是构建一个自定义模型来处理来自 SAP 的全面公司知识，因为就我知道的学术研究都没有专门针对这个方向。

除了学术界之外，我对软件行业如何处理 SAP 也很感兴趣。我看到供应商有两大类方法。一方面，我们有传统的数据供应商，他们在数据治理、数据质量、数据集成等方面非常熟练。这些公司经常谈论构建领域特定模型，因为向客户展示以下内容符合他们的利益：如果没有合适的数据集供模型交互，则其右侧的所有内容都将不相关。

这种观点大致上是正确的，但不是 100% 准确。基础模型接受了可能与企业查询相关的各种数据的训练，并且有大量研究允许模型以执行 API 的方式与另一个数据集进行交互查询或数据库查询。

转到图片的右端，我们看到这些公司（主要是初创公司或研究小组）在 LLM 层如何掌握提示工程以及如何应用 RAG 方面带来了很多创新。在这一端，企业的入门级要简单得多。我们可以轻松地与给定的模型进行交互，通过API 调用来应用其中一些技术，并获得一些奇妙的结果。但 API 调用的可扩展性很快就会成为一个风险。第三方模型 API 调用按 token（字符）收费，快速查看 Cohere 或 OpenAI 会发现 Cohere 价格比 OpenAI 便宜 10 到 500 倍；根据所选的引擎不同，成本可能会很快升高。

RAG 很酷，但 Vector DB 并不是一切

检索增强生成（RAG）颠覆了开放问答领域，使系统能够针对各种查询生成模仿人类行为的响应。RAG 的核心是检索模块，它扫描大量文本以识别相关的上下文段落。然后，这些段落由生成模块（通常是预先训练的语言模型，例如 GPT-3）处理以制定最终答案。

然而，尽管这种方法很有效，但它也有一些局限性。该系统关键组成部分之一是在嵌入段落上进行向量搜索，它具有固有的限制，可能会阻碍系统进行细致推理的能力，比如当遇到需要跨多个文档进行多步骤感知的复杂问题时，这一点变得尤其明显。

向量搜索的主要优点是它能够搜索语义相似性，而不是仅仅依赖字面关键字匹配。向量表示捕获概念意义，从而能够识别更相关的搜索结果，这些结果可能在语言上有所不同，但共享相似的语义概念。与传统的关键字匹配相比，这可以实现更高的搜索质量。然而，将数据转换为向量并在高维语义空间中进行搜索时存在局限性。向量搜索很难捕获文档之间的多样化关系和复杂的互连。

此外，对结构化 SAP 数据集执行向量搜索，尤其是在考虑复杂的关系时，存在一些限制和挑战。解决这些限制可能需要结合专门的算法、数据预处理和特定领域的知识，来为具有复杂表关系的 SAP 数据创建有效的向量搜索系统。此外，持续监控和优化对于确保系统随着 SAP 数据的发展保持准确和高效至关重要。

LLM已经展示了他们在理解和生成人类语言以及其他应用方面的实力。然而，它们处理图数据的能力仍未得到充分探索。需要在图相关任务上进一步评估LLM以增强其实用性，特别是在关系检测、知识推理和图模式识别方面。

许多研究都集中在评估LLM（主要是 GPT 模型）处理图相关查询和生成准确响应的能力。然而，这些研究主要集中在 OpenAI 的闭源模型上，忽视了其他开源替代方案。此外，他们还没有彻底探索诸如多答案问题的保真度或LLM的自我纠正能力等方面。

知识图谱和LLM

为了克服这些限制，知识图谱（KG）或知识图谱提示（KGP）成为一种有前途的替代方案。KGP 将各种关系显式编码为互连的图结构，增强了推理能力的丰富性。

图数据库结构有利于建模和分析不同数据类型之间的复杂关系，例如客户数据、产品数据、市场数据、第三方数据和资产负债表数据等：

• •     实体：在图数据库中，每条数据都表示为一个实体。可以对实体进行标记以将其分类为不同类型。例如，您可能有“客户”、“产品”、“市场”、“第三方”和“资产负债表”等实体。

  •     属性：每个实体都可以具有与其关联的属性。例如，“客户”实体可能具有“customer_id”、“名称”和“电子邮件”等属性。类似地，“产品”实体可以具有诸如“product_id”、“名称”和“价格”之类的属性。

  •     关系：实体之间的关系在图中表示为边。这些边定义了不同数据的连接方式。例如：“客户”可能与“产品”有关系以表示他们购买的产品。“市场”可以连接到“产品”以显示哪些产品在特定市场上可用。“第三方”可以连接到“产品”，以指示与特定产品关联的第三方服务或数据源。“资产负债表”可以连接到“客户”以显示金融交易和余额。

  •     查询：图数据库支持强大的查询语言，例如 Gremlin，专门为遍历和查询图数据而设计。这些查询可以检索有关数据内关系和模式的信息。假设您想要查找特定客户购买的所有产品、其相关市场、这些交易期间使用的任何第三方服务以及相应的资产负债表信息。在图数据库中可以从代表特定客户的“客户”实体开始，遍历标记为“已购买”的边以到达“产品”实体，遍历标记为“available_in”的边以查找关联的“市场”实体，遍历标记为“third_party_service”的边以发现第三方数据或服务，遍历标记为“交易”的边以查找“资产负债表”实体和相关的财务数据。

SAP数据可以通过知识图建模的各种关系，如下图所示。

    总结来说，知识图谱具有以下优点：

• • •     结构关系：KGP 通过将段落链接到特定文档或部分来编码信息的上下文层次结构，帮助确定推理过程中的重要性、有效性和相关性。

    •    时间关系：KGP 通过按时间顺序对段落进行排序来考虑时间动态，从而促进对展开的叙述和时间线的推理。

    •     实体关系：KGP 以实体为中心的方法允许集中探索知识图谱，促进跨文档的特定实体的事实聚合。

虽然向量搜索是开放问答领域的重大飞跃，但它也有局限性，特别是在处理复杂查询和内容之间的不同关系方面。知识图谱提示通过显式地建模各种关系、增强推理能力并解决向量搜索的一些缺点，提供了一种有前景的解决方案。随着人工智能系统越来越融入我们的生活，了解这些优点和缺点对于充分发挥其潜力至关重要。

典型的汽车数据模型代表汽车行业内数据的结构和关系，它组织和管理与车辆、其零部件、客户、经销商和其他相关实体相关的信息。下面，我将概述简化的汽车数据模型中的一些关键实体及其关系：

    车辆：

属性：VIN（车辆识别码）、制造商、型号、年份、颜色、发动机类型等

关系：与制造商的多对一（每辆车均由一个制造商制造），与经销商的多对多（一辆车可以由多个经销商销售），与服务记录一对多（一辆车可以有多个服务记录）

    制造商：

属性：名称、总部地点、成立年份等

关系：与车辆一对多（制造商生产许多车辆）

    顾客：

属性：客户 ID、姓名、联系信息等

关系：车辆多对多（一个客户可以拥有多辆车辆），与经销商的多对多（客户可以从多个经销商处购买）

    经销商：

属性：经销商 ID、名称、位置、联系信息等

关系：车辆多对多（经销商可以销售多辆车辆），与客户的多对多（经销商可以有多个客户），一对多销售交易（经销商可以有多个销售交易）

    服务记录：

属性：服务 ID、日期、描述、费用等

关系：与车辆多对一（服务记录与一辆车相关联）

    销售交易：

属性：交易ID、日期、价格、支付方式等。

关系：车辆多对一（一笔交易与一辆车关联），与客户多对一（一笔交易与一个客户关联），与经销商的多对一（交易发生在一个经销商处）

    存货：

属性：库存ID、数量、价格等

关系：与经销商的多对一（库存由一个经销商管理），车辆多对一（库存包括一种类型的车辆）

    员工：

属性：员工 ID、姓名、角色、联系信息等

关系：与经销店的多对一（一名员工在一个经销店工作）

这是一个简化的表示，在使用 ECC 或 S/4HANA 的现实场景中，数据模型可能会更加复杂，带来 Ariba、Fieldglass 或汽车行业的其他实体和属性，包括零件、供应商、保修以及更多信息。

KG 和 LLM 之间的交互对于使用关系数据库的企业有特别的好处。但是，我花了几天时间阅读了 55 篇论文，这些论文可以指导我 LLM 如何更好地理解 SAP 数据模型，这就是我对它们的总结：

• •     KG增强的LLM预训练：该研究小组专注于在大型语言模型的预训练阶段整合知识图谱。这样做的目的是提高LLM表达和理解知识的能力。这通常涉及修改预训练过程，以使模型更加了解知识图谱中的结构化知识。

  •     KG 增强的 LLM 推理：在这一类别中，研究在 LLM 的推理阶段使用知识图谱。这使得LLM无需重新培训即可从知识库获取最新信息。这对于让LLM了解最新知识特别有用。

  •     KG增强的LLM可解释性：该小组专注于利用知识图谱来更好地理解LLM学到的知识并解释LLM的推理过程。这有助于使LLM的决策过程更加透明和可解释。

将知识图谱与大型语言模型集成是一个令人兴奋的研究领域，它可以提高这些模型在广泛应用程序中的性能和可解释性，它能够整合结构化知识，及时了解不断变化的信息，并在输出中提供更透明的推理。让我们用供应链图来做另一个例子。

它合并了来自以下实体的 SAP 数据。

这种方法使我们能够将复杂的 SAP 数据模型构建为实体和关系，从而生成材料、组件和产品如何从供应商流向客户的整体图景。知识图谱固有的相互联系和依赖性变得明显且可分析。我们相信基于 LLM 的应用程序的未来是将向量相似性搜索方法与 Gremlin 或 SPARQL 等图数据库查询语言相结合。

知识图谱如何帮助LLM更好地推理

知识图谱已成为以机器可读格式构建和编码世界知识的强大方式。基于向量相似度的传统段落检索技术在推理能力上存在局限性。本文探讨了现代大语言模型 (LLM) 如何增强高质量知识图谱的构建，以及这些增强图谱如何与内容检索相结合，塑造检索系统的未来。

传统上，构建知识图谱涉及复杂的过程，例如实体提取、关系提取和图填充。然而，Llama Index 、KnowledgeGraphIndex等工具利用LLM来自动化这些任务，包括实体识别和关系提取，从而减少了有效使用知识图谱的障碍。

当与LLM和内容检索方法相结合时，知识图谱为段落检索提供了超越传统向量相似性的有前途的途径。它们增强了多跳推理能力，并有可能塑造智能检索系统的未来，提供更大的灵活性和理解深度。

在此示例中，智能搜索系统演示了大型语言模型 (LLM) 和知识图谱的强大组合。它利用 LLM 生成用于知识图查询的 Cypher 语句，检索相关信息，然后使用另一个 LLM 生成准确的答案。这种灵活的方法允许使用不同的LLM来完成不同的任务或在单个LLM上使用不同的提示，从而增强了系统的适应性。

知识图谱和大语言模型的融合体现了在结构化数据上优化创新搜索系统的稳健策略，特别是在解决需要结构化和非结构化数据源有效集成以提供上下文相关响应的查询时。

下图摘自东南大学的一项研究：Knowledge Solver。比较 (a) 中的普通LLM和 (b) 中的零样本知识求解器用于问答任务的示例。LLM通过利用自身的普遍性来寻找执行任务所需的知识。紫色代表LLM选择的正确路径中的节点和关系。

下图

摘自伊利诺伊大学的一项研究。 对于每个问题答案选择对，我们检索相关知识子图并将其编码为文本提示，直接注入到LLM中以帮助他们执行所需知识的任务。 在这个问答场景中，LLM与提供的外部知识进行交互，以选择回答问题的正确路径。

结论

一些开创性的研究工作涉及对各种 LLM进行微调，以实现 KG 到文本的生成。这些方法通常将输入图表示为线性遍历，这种简单的方法已经取得了成功，优于许多现有的最先进的知识图谱到文本生成系统。

虽然图数据库已经存在很多年了，但它们并未获得太多的欢迎，但这种情况可能会很快发生变化。在这篇文章中，我介绍了RAG 框架如何结合知识图谱和大语言模型 (LLM) 的功能来增强推理和信息检索，将其好处总结如下：

• • 结构化上下文：知识图谱提供结构化数据，增强LLM对实体之间关系的理解并改进上下文感知推理。

  • 高效的信息检索：知识图谱可以实现精确高效的信息检索，减少噪音并提高响应的准确性。

  • 多跳推理：LLM可以通过遍历知识图谱路径进行多跳推理，从而能够回答复杂的问题并基于结构化数据进行推理

组织可以创建适合其特定领域或行业的自定义知识图谱。这使得LLM能够获得特定领域的知识，使他们在专业应用中更有价值。然而，这对于 SAP 环境来说是一个真正的挑战，在 ECC 系统中非常复杂，而在 S/4HANA 上则不太复杂，但也并不容易。

有趣的是，SAP 推出的关于生成式 AI 的首批课程之一是如何利用新的图谱API 来开发基于大语言模型 (LLM) 的应用程序。

---

OpenKG

OpenKG（中文开放知识图谱）旨在推动以中文为核心的知识图谱数据的开放、互联及众包，并促进知识图谱算法、工具及平台的开源开放。

点击阅读原文，进入 OpenKG 网站。