投资公司的数据团队在为投资组合经理（PMs）、量化分析师和研究人员提供必要工具和见解，以有效利用数据资产方面发挥着至关重要的作用。他们工作的关键部分是促进数据发现，确保用户能够轻松地从各种数据集中找到必要的数据点，包括结构化和非结构化的另类数据、市场数据和参考数据集。
在较大的投资或交易公司中，管理这些数据集可能会尤为具有挑战性。可能需要监督数百甚至数千个数据集，创建全面的文档并理解相关的数据资产是一项复杂且资源密集型的任务。对于投资组合经理、量化分析师和研究人员来说，深入了解可用数据集及如何浏览这些数据集至关重要，这可能会耗费大量时间和资源。
让我们来看看前台专业人员为数据团队提出的一些常见问题模式。
美国股票有哪些可用数据集？
实体星巴克有哪些可用数据集？
科技行业有哪些可用数据集？
人流量数据集可以与哪些参考数据集一起使用？
展示使用邮政编码的不同数据集中的所有列？
提供一些用于探索网页流量数据的范例Jupyter笔记本？
您能展示使用卫星图像数据集进行的分析示例吗？
我们评估了哪些人流数据供应商？
使用网页流量和人流量数据集构建的数据产品有哪些？
尽管看似无关紧要，回答一些问题可能是一项艰巨的任务。这通常涉及查阅各种文件、搜寻无数电子邮件、研究大量代码行，并寻求具有数据集经验的同事的帮助。这些看似简单的问题可能会成为漫长而具有挑战性的过程，突显了在任何项目中文档和沟通的至关重要性。让信息发现变得更加容易的一种方法是创建数据目录、文档和示例脚本，使用户能够自给自足。
随着基于LLMs和基于RAG的架构日益流行，对文档进行语义搜索已经成为收集信息和查找答案的一种常见方法。然而，这些答案并非总是直截了当的，因为它们可能需要LLM从多个来源获取信息才能提供逻辑回应。在这种情况下，基于文档的语义搜索在向量数据库上可能不足以满足需求。
在本文中，我们将探讨解决这一问题的另一种方法。通过使用从数据资产元数据派生的 Neo4j 知识图谱，我们可以赋予 LLMs 回答复杂问题的能力。本文以及其附带的 GitHub 代码将展示这种方法及其潜在利益。
随着我们的进展，有几个重要主题将会讨论。然而，我想首先概述这些目标。
我们的目标是利用 LLM 为用户关于数据集和数据资产的重要自然语言问题提供答案。在实现这一目标中的一个关键因素是将元数据表示为图，并利用语义和图搜索结合 LLM 的帮助。
通过在元数据级别通过基于 LLM 的实体映射技术连接不同的替代数据集，并利用 LLM 工作流将这些关联信息与结构化数据源集成，我们可以极大地增强数据的发现能力。
为数据集收集元数据可能是一项具有挑战性的任务，因为数据通常分散存储在不同的系统中。然而，与其手动从各种来源收集这些信息，一个更高效的方法是使用数据目录或可观察性平台。这不仅节省时间和精力，还确保收集到所有必要的元数据。在我的情况下，我将数据集存储在 Snowflake、Databricks 和 PostgreSQL 中，并使用 DataHub 检索它们。通过利用平台的 GraphQL API，我能够轻松访问所需信息并在 Neo4j 中生成图表。
在之前的文章中，我分享了一个实用指南，介绍了如何利用 DataHub 实现数据可观察性和治理，从而改善数据操作并在最终用户中建立信任。对于那些对元数据模型以及为无缝数据操作收集此信息的重要性不熟悉的人，我强烈推荐阅读那篇文章。
对于这个项目，我们将利用OpenAI API、Neo4j、LangChain和Chromadb。OpenAI 模型将被用于LLM，但您可以灵活地切换到您喜好的任何其他LLM。我已经在Ollama中使用llama3测试了与之的兼容性，它已被证明对我们的用例同样有效。
让我们想象一家拥有少量替代数据集的假设权益自主交易公司。大多数交易公司通常拥有一个安全主表，用于跟踪他们交易的证券，这对他们的运营和研究至关重要，我们的假设公司也有一个基本的安全主表，其中包含有限数量的证券。
注意：上述提到的每个数据集都包含一个时间组件，并且大多数都结构化为时点（PiT）。另外，元数据实体之间存在时点关系。然而，为简单起见，我们将不会将此纳入本体论设计中。
初始步骤是将表元数据实体描述为图形。在这个阶段，我们将拥有两种类型的节点 — 数据集和列。虽然我们可以将元数据模型（来自DataHub）中的其他数据资产，如笔记本和流水线，纳入其中，但我们目前的主要焦点将放在这两者上。
此外，我们还在图中包含这些对象的元数据，比如描述和示例值。此外，我们将标记需要嵌入的节点，特别是数据集和参考列。借助Neo4j的向量索引和与LangChain 的无缝集成，我们可以轻松地利用LLM来嵌入这些节点中的多个属性，从而产生可供在下一步中用于基于RAG的查询的向量嵌入和索引。
基于简单RAG的问题LLM现在可以使用向量索引轻松回答简单问题了。例如，我们可以询问有关在美国测量零售店人流量的数据集，或者请求查看来自不同数据集的邮政编码列。在幕后，LLM嵌入问题并在图中找到具有类似向量嵌入的节点。然后利用这个背景来准确回答问题，而不是做出假设。简单的向量数据库也可以进行相似性搜索并检索最接近的节点，但在处理更复杂的问题时可能会遇到困难。例如，如果我们要求在步行流量数据集中列出所有列，则向量数据库可能无法在嵌入文本中未提及它们时检索到它们。这就是图表表现出色的地方，因为它们可以检索与问题在语义上相关的连接节点。这为LLM提供了更相关的上下文，使其在传统向量数据库中脱颖而出。你可以在这本笔记本中找到所有这些问题及其答案。
高级问题和使用LLM进行后端操作。让我们尝试向我们的智能体提出一个更复杂的问题。
你能展示与星巴克公司相关的所有数据集吗？或者 你能展示所有与消费者自由裁量部门相关的数据集吗？
然而，这些问题提出了一些挑战，我们简单的基于 RAG 的方法可能无法处理。数据点尚未加载到图中（仅加载了元数据），因此无法从图中回答任何关于实体或数据集本身的问题。另外，我们不清楚这些数据集之间以及可用于连接它们的列之间的关系。
我将展示如何使用 LLM 和 LangChain 处理这两个问题。
让我们首先着手解决第二个问题，以星巴克为例。
在检查了人流数据集之后，我们发现星巴克的代码在符号列中列出。但这是否意味着只有人流数据集可用于分析星巴克？
经进一步调查，我们发现人流数据集中的商店也具有邮政编码，在天气数据集中也有，但被称为邮政编码。尽管术语不同，但仔细查看列描述和样本值会发现它们表示相同的信息。这意味着这两个数据集都可以用来收集有关星巴克位置的见解。换句话说，有两个数据集可用于分析星巴克的股票。
在secmaster和foot-traffic表中分别识别了股票代码和符号列的类似项，以及在foot-traffic和天气数据集中的邮政编码和邮政编码列，我们可以在图中建立这些列之间的新关系。这将使我们能够有效地连接并回答更复杂的问题。
人工筛选数据并链接列可能是一项乏味的任务。然而，借助LLM的帮助，这个过程可以加快。实体解决映射领域广阔而复杂，有许多技术可以与LLM和图表结合使用。以下是对我特别有效的四种技术。
在图中找到相似列的最简单方法是使用矢量余弦相似性。这种方法很直接，因为我们可以利用现有的节点矢量嵌入，而无需再次访问LLM API。通过运行基本的密码查询，我们可以比较向量对并确定它们的余弦相似度，这将帮助我们识别相似的列。
最简单的匹配实体的方法是通过提示，因为它不涉及使用嵌入或 RAGs。但是，这种方法在匹配过程和 LLM API 消耗方面可能有点昂贵。这是因为我们需要接近 n(n-1)/2 次地调用 API，其中 n 是要比较的列数。
You are given two columns from different tables that need to be compared todetermine if they represent the same identifiers.方法3: 简单RAG
Here are the details of the columns:
Column 1:
name: zip_code,
description: ZIP code of the location where the data was collected.,
values: 10001,
Column 2:
name: post_code,
description: Postal code where the location is situated.,
values: 10001,73070,
Compare these columns and answer the following questions:
1.Do these columns seem to represent the same type of identifier based on name and the description?
2.Based on the sample values, can we infer that these values are similar enough that they are taken from the same identifier ?
另一种考虑的方法是使用基于标记的方法，通过确定哪些嵌入列最相似来实现。可以通过使用特定提示来增强这种技术，从而实现成功的列匹配。然而，其中一个缺点是我们从输入列开始进行矢量搜索，这意味着如果列或实体不能准确地由矢量表示，我们可能会在上下文中检索到不正确的数据点。
You are given the below details about a column, find columns that represent the same identifier. There could be more than one match.方法 4: 高级RAG-GraphRAG
Use only the information from the given context
Compare these columns based on the flowing criteria's and provide an explanation.
1.Do these columns seem to represent the same type of identifier based on name and the description?
2.Compare the sample values to infer if these values are similar enough that they are taken from the same identifier, they don't have to be the same.
Column details:
name: zip_code,
description: ZIP code of the location where the data was collected.,
values: 10001,
Retrieved information:
{context}
上面提到的RAG方法可以与图中的高级RAG查询相结合，从中拉取连接的节点。例如，假设我们有一个名为ZIP的新列，表示邮政编码，并且在语义搜索中与天气数据集中的zip_code列匹配，RAG还将从foot_traffic数据集中获取连接的zip_code和postal_code列，因为它们之前有连接。这与简单的RAG方法（方法3）相反，后者仅会获取zip_code列。
现在，想象我们要引入一个新数据集，其中有一个名为ZP的列，包含邮政编码信息。通过使用这种连接检索过程，我们为LLM提供了来自以前连接的三个节点的知识。随着我们继续添加更多列，LLM获得更多信息以映射未来的列。在我的测试中，这种方法被证明是最有效和可扩展的解决方案。
您可以在这个笔记本中找到所有4种方法的代码。
就LLM API成本而言，方法1是最便宜的，方法2是最昂贵的，而方法3和4在我进行的测试中在成本与性能方面最为有效。这些技术并不是要完全取代人类判断，而是要简化专业人士的决策过程。目标是让他们更容易确定要连接哪些列。重要的不是简单的是或否答案，而是LLM创建的详细论点以匹配列，为我们提供最多信息。通过让人类参与其中，我们可以识别错误的阳性和阴性，并通过将它们用作进一步训练的示例来改善LLM的表现。
使用LLM的优势之一是它们能够编写SQL查询和Cyphers，Neo4j的声明性查询语言。通过LangChain，我们可以生成查询，以提供我们所需的信息。
例如，如果我们想知道所有可用数据集，我们之前创建的向量索引上的语义或图搜索是不够的。相反，我们需要构建一个Cypher查询，使用其输出作为我们的LLM获取答案的上下文。幸运的是，Neo4j和LangChain具有必要的工具来实现这一点。
同样，在连接数据集的工作背景下，我们可以要求LLM为问题创建一个Cypher查询，
展示我如何从sec_master导航到不同数据集？
MATCH path = (d:dataset {name: 'sec_master'})-[r*]-(d2:dataset)
UNWIND nodes(path) as n
return n, r让我们重新审视一下我们在尝试确定星巴克可用数据集时面临的初始挑战。我们如何弥合元数据图与数据层之间的差距？
一种解决方案是将所有数据导入图中，从而更容易查询实体并利用先前讨论过的方法。但是，我必须警告你，这项任务比看起来更复杂。节点和关系的数量庞大，可能需要对本体进行彻底检修。
一种更高效的方法是创建一个LLM代理工作流，将图和存储信息的数据存储库整合在一起。这将简化流程，使其更易管理。
我们流程中的第一步是确定问题所指的实体。可以通过将每一行代表一个文档的 sec_master 表嵌入到向量数据库中来轻松实现这一目标。然后，我们可以执行相似性搜索，以确定涉及的实体。
我们已经发现了一种确定各种数据集之间连接的方法。有了这些信息，我们可以轻松地为每条路径创建 SQL 查询，并在数据存储的 SQL 仓库中高效地搜索所需的实体。请求 LLM 从sec_master找到所有路径，它将为您提供下面的密码查询。
我需要一个密码查询，从sec_master数据集遍历到相关数据集？在密码查询中返回类型、名称和基础表。
MATCH path = (d:dataset {name: 'sec_master'})-[*]-(d2:dataset)
UNWIND nodes(path) as n
RETURN n.type, n.name, n.table;使用一些简单的Python代码，我们可以将来自密码查询的输出转换为SQL查询。通过在sec_master表上添加where子句，我们可以将搜索范围缩小到最初通过向量搜索识别的特定实体。然后，我们可以获取以下SQL查询。
select count(*)
from graph_db.public.sec_master a
inner join graph_db.public.foot_traffic b on a.ticker = b.symbol
inner join graph_db.public.foot_traffic c on b.post_code = c.zip_code
Where a.ticker = "SBUX"
如果我们的雪花查询产生任何结果，这意味着数据存在，我们可以在我们感兴趣的实体或部门的所有遍历路径上运行类似的SQL查询。因此，我们最终可以找出多少数据集包含关于星巴克的信息。在这种情况下，有两个：客流量数据集（直接提到星巴克股票代号SBUX）和天气数据集（通过客流量数据中的邮政编码与星巴克相连）。
您可以在此笔记本中找到上述语义搜索和SQL查询生成的代码。
乍一看，这可能看起来令人生畏，但是借助LangChain和LangGraph等框架的帮助，我们可以轻松地融入复杂的LLM逻辑。实际上，在我们讨论的所有场景中，我们必须在三种工作流程之间进行选择：对索引进行语义搜索，创建一个Cypher来回答问题，或者涉及多个代理和检索器的更复杂过程。因此，利用像LangGraph这样的框架对问题进行分类，并根据问题类型开发特定链是至关重要的。
在本文中，我展示了一些有关发现的商业用例。通过结合各种替代性数据集，我们可以开启一个超越迄今讨论的全新的Alpha研究潜力世界。通过图谱和LLM的力量，我们可以发现基本表元数据之外的宝贵见解和机会，这些见解和机会通常很难获得。此外，我们的重点主要集中在基本表元数据上。然而，在数据资产的元数据模型中，还有许多其他元素我们尚未探索。这些元素包括流水线、事件、数据使用者和质量问题。将我们的功能扩展到这些实体中将需要另一篇专门讨论利用这些信息来源在数据操作中的影响的文章。这一想法也可以应用于其他操作，比如交易或风险操作，仅限于一个人的想象力。
实体解析映射的概念已成为广泛研究的主题，特别是在金融和银行业。根据我的经验，与传统的NLP方法相比，大型语言模型（LLMs）在这一领域展现出了巨大潜力。然而，这个领域还有很多有待探索。
基于图谱的RAG在RAG社区中越来越受欢迎，我对微软开源GraphRAG项目重磅 - 微软官宣正式在GitHub开源GraphRAG感到非常兴奋。在这个简短项目中，我们仅仅触及了远程搜索器的表面。这是一个快速发展的研究领域，图搜索无疑是RAG的未来。
对我来说，这些都是我在项目中工作经验中得出的关键经验点。
利用元数据图和LLM的力量成功解决与数据资产相关的复杂查询。
通过基于LLM的实体解析映射连接不同的替代性数据集。
通过LLM链和图表将结构化数据和元数据图合并的概念，使用类似LangChain和LangGraphs的工具。
融入语义和图搜索技术的无限潜力。
维护元数据图的关键作用，以及如何为推动收入的同时提高运营效率做出贡献。
