作为一名参与初创企业的成员，该企业的主要产品是数据目录，我有时会感觉不太舒服，这种感觉可能来源于元数据管理工具变得越来越普遍的影响。事实上，除了我们的直接竞争对手，几乎所有数据仓库平台，例如Snowflake、Databricks、AWS、微软的Azure、谷歌等，都在提供某种形式的元数据管理工具。

但这只是一个印象。数据目录不仅仅是一个元数据存储库，其中收集的技术元数据只是为了整理出一个像图书馆目录那样的有序名称和描述列表……事实上，从企业数据环境中收集信息，即元数据，是业务中最有价值的资产之一：它不仅仅涉及底层原始数据的结构和定义，而是开启了真正的企业知识管理（EKM）之路。

但可以用来开发基于元数据的企业级EKM的工具都有哪些呢？正如在IT行业中常见的那样，概念或工具已经存在了一段时间，有时甚至是几十年之久，新的使用组合带来了创新，甚至可以说是一种颠覆。我认为这种情况适用于“语义层次”，即在技术元数据层之上的层次，在这里我们处理底层数据的意义。在这里，大型语言模型（LLM）和知识图谱（KG）都能发挥作用，特别是它们的结合效果非常出色。

看看元数据湖的图表？

首先，我们将元数据库组织方式重塑为图形，即由 node-relation-node 三元组组成。通常，将数据结构以图形形式展示比Excel表格更容易理解！但图的表示方式的好处不仅在于其图形吸引力；节点间的关系（即边）为信息空间增添了另一维度。为了准确起见，图中实际上包含两个不同的信息层面：
(1) 语义或人类传达的信息： (A) — [:isAFriendOf] →(B) 和，
(2) 节点间的连接方式，即如何形成网络。
本文将专注于第一点，探讨如何利用这一点来增强元数据湖的可理解性。如果我们仔细想想，元数据本质上是语义化的对象：它们旨在有意义且易于人类理解的方式描述原始数据。我们不像数据工程师使用SQL代码和JOIN语句操作表，我们只执行一些非常“人性化的”操作，如从自然语言中搜索数据，查询大量数据，尝试在看似无关的资产之间找到相似性，构建混乱数据集中的分类模型等。因此，将元数据资产表示为图中的互联节点是完全合理的做法。接下来我们可能要问的问题是：

知识图谱能给使用数据的人带来哪些好处呢？

将元数据资产组织为知识图谱的根本原因在于，正如上面提到的，我们处理的是对象，而不仅仅是数据位和字节，或者正如谷歌工程一篇开创性文章中所解释的：“things, not strings”，这一理念也体现在去年的Gartner影响雷达报告中……

https://www.gartner.com/en/articles/30个新兴技术将指导您的商业决策

在这里，我将研究如何从元数据的视角提升企业知识管理，以及知识图谱(KG)如何被大型语言模型(LLM)利用来进行查询。

数据目录从技术角度来说，是一个包含元数据（即数据资产）的数据库。它配备了各种管理工具，例如搜索引擎、资料编辑工作流（含访问控制），以丰富描述（业务元数据），以及数据血缘或数据质量工具来调查数据的特定方面。

Quollio 数据智能平台 (QDIC) UI

但这样的系统，如Quollio 数据智能平台，并不是孤立或封闭的应用程序：元数据资产可以通过多种方式交换，比如通过 API、CSV 文件或共享数据库。我将在这里使用 CSV 下载功能。我创建的演示环境简化了实际使用场景：从多个 DWH、CSV 文件以及业务应用程序来源摄取元数据，这些代表了多个业务领域或实体。值得注意的是，这些实体可能位于企业域之外，元数据也可以通过特定的数据合同进行交换。

QDIC数据源中心（服务名称）（参见 https://docs.quollio.com）

实际上，元数据知识图谱就是一个数据模型。

所以，让我们将这个元数据仓库转化为知识图谱，并在其上执行一些操作。为了展示平台的灵活性，我们使用了一个第三方应用程序：这里我们使用的是Neo4j，但也可能是其他类似的应用程序（例如AWS Neptune等）。重点在于强调使用方便的工具从语义层面对元数据进行处理的重要性，而不是专注于特定的解决方案。数据流程如下：

在开放的环境和知识图中使用元数据

一旦元数据被导入图数据库中，我们可以从与QDIC接口不同的角度来探索数据视图。此时，我们只是以不同的视角来看待现有的元数据湖。它不仅显示了层次结构，如（:Table）-[:isInSchema]->（:Schema），还包括其他关系，例如数据血统或外键，以及任何已附加到目录中资产的词条。目录管理员可以灵活地将其元数据湖导出到知识图谱或其他业务应用程序中，而不会对其实际运行环境造成任何影响。这两种选项各有其特定用途和目标用户群。但鉴于知识图谱方法侧重于语义层关注点，它可能更适合业务分析的应用场景。

QDIC元数据湖以知识图形式展示（使用Neo4j控制台界面）

众所周知，当SQL JOIN的层数增加时，图引擎比传统的关系型数据库更胜一筹（例如：https://neo4j.com/news/how-much-faster-is-a-graph-database-really/）。在我们的案例中，我们并没有在元数据之间执行JOIN操作，但我们仍然可以从查询引擎中获益，以便从多个角度探索资产。举例来说，用户可能会有这样的需求：

我想获取从id为‘tbl-xyz’的表开始，沿从端到端的血统路径上最多8跳的表；
返回路径上所有表附带的标签，及其所属的架构。

这种类型的搜索用标准搜索引擎来表达可能会有点复杂，但作为图数据库查询却非常简单，即使是初学者！（下面的示例代码是简化版，用于说明这个概念。)

匹配 p=(d:数据库)-[]-(s:模式)-[]-(t:表)-[:表的线谱*8]->(t2)  
其中 lower(s.name) 转换为小写后包含 'value chain'  
    并且 t.id 等于 'tbl-xyz'  
可选匹配 (t2)-[]-(tg:标签)  
可选匹配 (t2)-[]-(st:模式)  
返回 p,tg,st

结果如下图所示。查询仅需几毫秒，因为请求非常直接，返回的数据包中包含了所有元数据，例如表描述和属性，以便进一步分析（稍后我们将看到具体如何操作）。有趣的是，能够沿着路径提取标签或节点所属的原始数据库中的模式（这里指数据库结构），这对于业务分析师来说非常重要，例如这可以帮助识别数据血缘穿越的数据域。类似的探索还可以用于其他类型的关系，例如基于相似性的节点聚类等。

沿路径进行数据血统查询，最多支持8跳，并且包含标签和模式结构，从一张表开始。

另一个有用的工具是使用_本体_来在知识图谱中添加一些形式化的术语。由于知识图谱本质上是模式无关的（即横向而非严格的层级结构），可以添加和链接特定领域的本体到元数据资产。这有助于理解业务实体资产所属的领域或类别及其相互关系（例如参阅Sequeda & Lassila, 2021）。

作为一个简单的例子，让我们考虑一家公司从多个部门和业务领域获取数据：通过ERP获取采购数据，通过SCM获取供应商信息，通过PLM应用获取产品生命周期和制造数据，然后是这些实体之间的物流。虽然各个领域的数据所有者对他们的数据非常熟悉，但是数据治理专员（DS）在理解每个元数据资产与哪个业务实体或数据源相关联时，可能会遇到一定的困难。使用本体来组织这些资产可以极大地优化数据景观的组织。下图展示了一个标准化本体如何被添加到知识图谱中的类中。元数据资产可以根据此特定领域分类进行分类。

带有额外特定领域知识模型的元数据图

这种方法的好处在于，我们可以逐步地添加特定领域的（公司）或特定应用的本体，来补充元数据语义层。例如，假设我们从SAP ERP系统中导入元数据，我们的数据治理专员（DS）不是SAP专家，但被销售部门要求准备一个数据产品来计算由于更换供应商而产生的成本预测。他们要求我们找到一些表，以调查关于此供应商关键部件的合规问题。听起来熟悉吗？实际上，我们的DS可能需要找到诸如EKKO、EKPO、LFA1和MARA等表……但在没有成为SAP顾问的情况下，这并不是一项简单的任务。顺便说一句，MARA代表（材料主数据）(材料主数据)，它包含了关于材料的重要信息，如产品数据和成本信息。DS可能会被建议从这张表入手收集资源，但在没有详细的KG的情况下，这将是相当艰巨的任务。正如在SAP技术博客文章中讨论的那样，添加一个特定于SAP的本体到KG中将极大地帮助解决问题。

一篇SAP技术博客：知识图谱用于LLM的锚定和防止虚构。

关键在于明确定义这些实体：“abaptable:”、“bo:”表示业务对象（BO）、“cdsview:”表示核心数据服务等。当然，这些定义在LLM模型中大部分已经存在，但提前准备好这些元数据及其与SAP内部实体的关系定义，在查询知识图谱（KG）时会有明显优势。

注：LLM指大型语言模型。

那么，我们如何利用知识图谱来改进大型语言模型（LLM）任务，而反过来，具体来说有两类主要任务，大致可以分为两大类，元数据管理应用可以从AI/LLM中获得很大帮助。

(1) 元数据丰富：帮助数据管理员完成元数据成熟过程中的工作。在实际生产环境中，可能存在着数以百万计的资产，且其元数据不完整，让这些名称和描述更易读至关重要，但如果不进行一定程度的自动化，这将是一项巨大的工作量。此外，自动将标签或术语与词汇表匹配以帮助分类，可以节省宝贵的IT时间资源。

（2）通过自然语言问题或业务分析来查询数据（即资产查询）。大多数业务用户不懂SQL，希望能通过类似业务的问题获得他们需要的数据。

在（1）中，生成描述的准确性将取决于LLM引擎对整个上下文的理解。例如，给定以下表格（来自一个真实的物联网设备），假设逻辑名称和描述并没有由数据所有者提供，就像数据湖中自动采集的传感器数据可能出现的情况一样。

技术及业务元数据在Quollio应用中

让我们来问一下双子对“KYAKU_DENRYOKU_SYOHI”有什么想法：

显然，没有上下文的情况下，提出的解决方案只能从物理名称中“猜测”出来。在这种情况下，双子能够推断出日语单词背后的日语 Hepburn 拼音，但这很简单，不需要大型语言模型来实现这一点。提供列名可以增强结果，但没有关于物理环境的具体信息，这个物联网传感器是在哪里实施的，是在工场BOP里，还是在物流中，或者是在货柜中？从原始数据中读取可能会提供 GPS 数据的位置信息，但我们无法通过元数据获取这些信息。

显然，我们应该传递模式和数据库的信息，以及附加的标签（这里“工場BOP”=“工场BOP”），这可能已经提供了上下文，但我们知道生产数据库中的名称可能是缩写或只是首字母缩略词。

我们期望大型语言模型引擎能够生成逻辑名称“IOTセンサーデータ”以及最重要的描述：“第1条生产线的耗电量·CFP检测装置”，这提供了关键信息“CFP”。再次，在没有更多上下文的情况下，很难猜出在本案中，CFP 意味着“产品碳足迹”，这与新的出口合规规定有关……

在第二类里，可以提出这样的问题：

“负责EMEA（欧洲、中东、非洲）地区的业务团队和采购部门希望分析产品X的碳足迹，并评估供应商成本与碳足迹成本（碳足迹，CFP）的关系，考虑碳税，提供ERP（企业资源计划）、PLM（产品生命周期管理）和SCM（供应链管理）系统中的相关数据。”

(*) 在这个例子中，我们是一家日本公司，在日本经营，向EMEA地区出口，与全球供应商打交道，并应对新的出口规定和要求...

如果我们不理解业务应用在语义层面上是如何相互连接的，我们如何查询标准数据目录中的信息以找到关于产品“X”的相关信息？

显然，在这两种情况下，获取相关背景信息的唯一方法是查询知识图（参见上面的流程示例）。值得一提的是，可以半自动地查询知识图，方法是从预设模板或直接从大型语言模型引擎（即通过专用代理程序）进行查询。

基于检索增强生成（RAG）架构的大型语言模型（LLM）自从chatGPT被引入以来得到了广泛研究，特别是在不同RAG架构中使用知识图谱（KG）的好处方面。使用RAG的主要目的是在LLM任务中为AI代理提供上下文信息，以避免或至少减少生成响应中的幻觉和不准确信息。
然而，实际操作中发现，仅仅将PDF文件向量化以供RAG使用的方法在准确性上往往不足，因为在转换过程中，资产之间的语义关系变得模糊。
为了在LLM上下文中保留语义信息，我们从知识图谱中检索数据并将其输入到LLM中。如图所示，这是一个简化的逻辑数据架构。

由知识图谱驱动的LLM-RAG逻辑架构示例

左边是元数据湖，其中包含额外的本体论和未结构化的文档，这些信息以图数据库的形式提供。KG引擎向LLM引擎提供所需的上下文信息，同时用户可以直接查询KG来获取资产（如上例中的数据血缘）。
LLM部分的实现比之前图示所展示的要复杂：实际上需要与特定代理程序合作来基于KG查询生成提示信息。在这里，我将仅展示一个简单的基于langGraph框架的例子，使用Azure OpenAI的LLM和Neo4j KG。
我定义了一些代理程序来执行特定任务，例如查询KG然后使用KG查询返回的信息来驱动LLM，以提供预期答案。工作流如图所示。
这种基于代理的方法的优点在于可以有节点（半）自主地执行任务，并在需要时查询KG以获取更多上下文信息。

使用langGraph的简单KG和LLM流程

实际上，我们会提出这样的问题：提供此资产的业务情境：“BEV_URIAGE_POS”。他们会首先决定向知识引擎发送哪个查询，然后根据返回的信息创建提示信息。

这些资产是由对知识图谱（KG）的查询返回的，并与查询的表相关联。

答案会是这样的：

    ### 表格的业务背景：BEV_URIAGE_POS

1. **整体业务背景：**  
       表 `BEV_URIAGE_POS` 是一个综合性数据集市的一部分，该数据集市旨在对汽车行业中的电池电动汽车（BEV）进行绩效分析。该数据集市名为 `総合データマート`（General Data Mart），用于分析公司价值链中的各个方面，包括销售、库存和促销活动。数据集市支持详细的销售表现分析、库存管理以及竞争基准分析，这对于汽车行业中的战略决策制定和运营效率提升至关重要。  

2. **表格的目的：**  
       表 `BEV_URIAGE_POS` 包含详细的BEV销售数据，包括销售交易在销售点（POS）处的相关信息以及经销商信息。这是该表的第二版，增加了有关经销商的详细信息。该表的主要目的是提供详细的销售数据，可用于分析SKU级别的销售表现、跟踪库存量以及评估促销活动的有效性。它是理解销售趋势、管理库存和优化销售策略的关键数据来源。  

3. **使用表格进行业务分析：**  
       可以使用 `BEV_URIAGE_POS` 表及其相关联的表格执行多种业务分析。以下是关键分析和相关表格：  

       - **SKU 分析：**  
         - **表格：** `BEV_URIAGE_POS`, `BEV_URIAGE_TOTAL`, `MART_BEV_URIAGE`  
         - **描述：** 分析单个SKU的销售和库存状态，以支持高效的销售规划和订单处理。这种分析有助于识别表现良好的产品并有效管理库存量。  

       - **促销效果分析：**  
         - **表格：** `BEV_URIAGE_POS`, `BEV_URIAGE_TOTAL`, `SALES_DEMO`  
         - **描述：** 评估各种促销活动（如折扣、促销等）对销售表现的影响。这种分析有助于确定促销活动的投资回报率（ROI）并识别最有效的促销手段。  

    <... *答案被截断>

通过这个简单的例子来看，LLM引擎给出的答案仍然很简单，但它确实利用了从KG中获得的上下文信息。在实际生产环境中，为了特定的目标，我们需要创建多个工作流程，但是这里讨论的概念仍然适用。

• Sequeda, J. & Lassila, O., 2021. 《设计和构建企业知识图谱》. Springer International Publishing 出版的.
• Olesen-Bagneux, O. V. G., 2023. 《企业数据目录》, 第一版, 北京: O’Reilly.
• Kejriwal, M., 2021. 《知识图谱》. 麻省理工出版社出版.
• https://neo4j.com/knowledge-graphs-data-in-context-for-responsive-businesses-developers/
• https://neo4j.com/knowledge-graphs-实践指南/
• https://www.deloitte.com/content/dam/assets-zone2/nl/en/docs/products/2024/deloitte-nl-risk-responsible-enterprise-decisions-with-knowledge-enriched-generative-ai-whitepaper-download.pdf