数据分析与AI丨Graph+LLM 如何重塑传统 BI 的未来

↑点击报名/查看会议详情

导读随着企业数据复杂度的指数级增长，传统 #BI 工具在动态关系分析、多模态数据处理及自然语言交互等方面的缺陷日益凸显。本文提出一种基于#图数据库（Graph Database）与#大语言模型（LLM）深度融合的新型数据分析架构，通过引入#语义增强技术（RDFS/OWL）与动态关系建模能力，实现从静态报表到智能推理的范式跃迁，为企业在供应链优化、知识图谱构建等场景提供可落地的解决方案。

文章将从以下几个方面展开介绍：

1. 选择图数据而不是关系型数据

2. 关系型数据如何变成图数据

3.LLM 如何从图中查询数据

分享嘉宾｜赵帅 Altair 数据分析高级应用工程师

编辑整理｜苏磊

内容校对｜李瑶

出品社区｜DataFun

01

选择图数据而不是关系型数据

首先来探讨为什么选择#图数据 而不选择关系型数据作为底层存储。

图数据的优势主要在于：

• 灵活的数据模型：图数据在定义表结构时，无需事先定义结构，而是可根据业务需求灵活进行节点和边的拓展。
• 
  
• 擅长处理复杂的关系数据：在存储过程中，图数据库将数据看作由节点和边组成的图形结构，便于查询和理解数据。
• 
  
• 更高的查询效率：利用图遍历算法，可快速找到节点和节点之间的关系路径，因此更擅长解决长链、复杂、深度查询等问题。比如查询数据超过 6 ~ 7 层的表关联情况，关系型数据库很难应对如此复杂的多层次查询。
• 
  
• 支持非结构化数据：图数据库可以通过图模型来存储半结构化数据和非结构化数据，比如文档、图片、视频等。

基于这些优势，图数据库能够更好地与大模型进行结合。接下来将介绍如何在图数据库中表征关系型数据。

02

关系型数据如何变成图数据

1.图数据的表现形式

RDF（Resource Description Framework），即资源描述框架，是一种描述数据文件存储的数据模型，该数据模型通常由三个部分组成，称为三元组。例如，要描述足球运动员罗纳尔多的信息，可以用以下 RDF 三元组来表示：

主语（Subject）：Person（指代罗纳尔多）

谓语（Predicate）：Chinese Name

宾语（Object）：罗纳尔多

类似地，还可以描述他的英文名、出生地、身高、生日等信息。这些三元组共同构成了一张知识图谱，宛如一幅数据的星图，清晰地勾勒出实体之间的关联网络。在这张图中，每个节点代表一个实体（如“罗纳尔多”或“巴西”），每条边则象征着实体之间的关系（如“出生于”或“身高”）。通过这种方式，图数据库不仅记录了数据本身，还捕捉了数据之间的深层语义。

然而 RDF 的表达能力有限，缺乏抽象能力，无法对同一类别的事物进行定义和描述。基于此，引入 RDFS。RDFS 为 RDF 提供了一种简单的模式语言，在RDF的基础上增加了 schema 的概念，使得我们能够对实体类和属性类进行定义。

• rdfs:class 定义实体类，如下图中的“Person”和“Place”，类似于关系型数据库中的表。
• 
  
• rdfs:property 定义属性，例如 Person 的生日、身高等，类似于表中的列。
• 
  
• rdfs:domain 表示该属性属于哪个类别，例如 career 属于 Person 表。
• 
  
• rdfs:range 描述该属性的取值类型。

RDFS 的表征能力仍然有限，所以在此基础上进一步做了扩充，引入了 OWL。OWL（Web Ontology Language）基于 RDS 和 RDFS，在语义表征推理和扩展性上都做了提升，能够更精确地描述知识结构和语义关系。

例如，在 OWL 中对属性进一步细化，将一个类的内部属性（如“身高”、“职业”）定义为 DatatypeProperty，而将类之间的关系（如“出生地”）定义为 ObjectProperty。

OWL 为复杂的数据建模提供了强大的工具。

2.关系型数据转换为图数据

前面介绍了如何在图数据库中表征结构化数据，接下来将讲解如何将关系型数据转换为图数据。这一过程通常包括以下四个步骤：

• 数据建模：需要根据业务需求设计图数据库的节点和边模型。例如，确定哪些实体需要作为节点，哪些关系需要作为边。这一步骤就像绘制一幅地图，明确每一座城市（节点）和道路（边）的位置与连接方式。
• 
  
• 数据导出：从关系型数据库中提取数据，并对其进行必要的清洗和转换，以确保数据质量。这一步骤犹如淘金，需去除杂质，留下最纯净的宝藏。
• 
  
• 格式转换：关系型数据转换成 OWL 格式数据（RDF/OWL）。
• 
  
• 数据导入：将清洗后的数据加载到图数据库中。这一步骤可能需要编写 ETL 脚本或使用专门的工具，如同将精炼后的黄金铸造成艺术品。验证数据加载的正确性，并根据实际查询需求对图数据库进行优化。

通过以上步骤，便可高效地将传统关系型数据迁移到图数据库中，为后续的大模型查询和可视化奠定坚实基础。

3.Altair Graph Studio 数据编织平台

在企业将关系型数据转换为图数据库时，通常更倾向于借助成熟的商业平台来高效完成这一过程。为此，Altair 推出了 Graph Studio 数据编织平台。该平台底层采用自研的图数据库，能够自动将用户加载的结构化、非结构化或半结构化数据转换为图数据格式，无需用户进行编程或依赖其他开源工具。

Graph Studio 的架构包含数据编织平台和 Graph LakeHouse 两大部分。Graph LakeHouse 是 Altair 自主研发的高性能图数据库，兼具性能与特色优势，技术核心聚焦于三大创新点：

• MPP（大规模并行处理）架构，从设计之初便支持高并发、分布式集群部署。在需要扩展至大规模集群时无需额外付费，充分满足企业级需求。
• 
  
• 内存常驻计算引擎，数据可完全驻留在内存中。这一特性尤其适合对查询响应速度要求极高的场景，能够显著降低延迟，提供卓越的实时计算能力。
• 
  
• 对外提供了通用的OLAP 查询接口。这意味着用户可以直接将其作为关系型数据库使用，无缝对接大模型、BI 工具及 AI 软件等多样化应用。

性能方面，在 200 节点集群的极限测试中，能够在 1 小时 45 分完成 1.065 万亿三元组数据加载，查询响应时间控制在1.67 至 189.18 秒之间，展现了强大的规模化处理能力。

基于图数据库开发了 Graph Studio 可视化数据编织平台。通过该平台，用户可以轻松加载结构化与非结构化数据，无需编写代码即可完成数据查询、转换及向图数据库的导入操作，让用户能够高效实现从关系型数据到图数据的转换过程。

在 Graph Studio平台上，数据编织分为四个关键步骤：

• 数据加载（On-board）：支持配置惯性数据或非结构化数据源，平台能够自动读取这些数据。
• 
  
• 模型构建：自动识别关系数据库中的表字段及表间关系，并在图数据库中自动生成对应的图模型，整个过程完全自动化。
• 
  
• 数据融合：针对多数据源场景，支持将不同来源生成的小规模图模型融合为全域模型，实现数据的统一整合。
• 
  
• 数据访问与应用：提供多样化的数据访问方式，包括可视化看板构建、OLAP 接口供第三方系统调用，以及自然语言对话查询接口，便于与大模型联动。

数据编织流程如下图所示，从左到右，读取不同来源的数据，自动生成对应数据源的图模型。基于这些独立的图模型，我们可以实现数据融合。如果分析业务需要从整体图模型中抽取部分数据进行专题分析，提供图数据集市功能。最终，通过通用接口对外暴露，方便您的

AI 系统、BI 工具或大模型对数据进行访问与调用。

下图展示了上述操作的界面，以下是关键环节的简要说明：

• 数据源定义：用户可通过界面定义多种数据源，包括关系型数据库（如 MySQL、Oracle）或大数据平台的数据。
• 
  
• 自动生成图结构与数据加载：系统会自动识别指定 schema 中的表、字段及表间关系，构建图结构，并将原始数据源中的数据读取并加载至该图结构中。
• 
  
• 数据融合：若需整合不同来源的数据，可在第三步完成。例如，将 MFG 模型与 Tube Order 模型融合，生成新的图模型，并加载对应数据。新图模型生成：基于融合后的数据，系统生成新的图模型并完成数据加载。
• 
  
• 数据访问：最后一步提供数据访问功能，包括快速构建仪表板和通用访问接口，便于用户对生成的图模型进行数据查询与分析。

若结构化数据本身较为规范（如来自数仓），整个流程从数据连接到图模型生成仅需 5 至 10 分钟即可完成。

数据存储完成后，提供三种访问方式：第一，通过自带的 dashboard 工具，在平台上构建可视化看板，进行数据分析；第二，支持标准的 SPARQL 查询语言，作为图数据库的通用查询语言，可对模型数据进行查询；第三，提供标准的 OData 访问协议，包括 ODBC 和 JDBC 接口，便于其他软件（如 BI 或 AI 工具）查询图数据库中的数据。

03

LLM 如何从图中查询数据

接下来介绍如何利用大模型，通过自然语言对话的方式，实现对图数据库中图数据进行查询。

大模型的核心能力在于能够精准理解用户的自然语言提问，并具备上下文记忆功能，从而连贯地处理多轮对话。不仅能理解单一模态信息，如文本、语音和图像，还能将不同模态的信息联合起来，比如理解一张图片中的内容并用文字描述它。

1.RAG-检索增强生成

RAG 技术已日趋成熟，其核心流程为将非结构化文档分割为文本块，通过嵌入模型将其向量化，并存储至向量数据库。当用户提问时，问题同样被转化为向量，用于检索数据库中与之最相似的回答，随后由大模型对这些回答进行总结并反馈给用户。

然而，RAG 技术也存在不足之处，为了增强其性能，GraphRAG 被引入以提升回答能力。但无论是 RAG 还是 GraphRAG，它们主要聚焦于非结构化数据（如 Word 文档、PPT 等），而对结构化数据（如表格数据）的支持则相对薄弱。

2.Text-To-Query

基于结构化数据的问答，主要采用 text to query 的方式。无论是将用户问题转化为关系数据库的 SQL 查询，还是转换为针对知识图谱或图数据库的查询，均属于这一范畴。在 Altair 的实践中，选择了 知识图谱与图数据库结合大模型的方式。这种方式能够高效解决针对关系型数据的问答需求。由于 Text-To-Query 的技术架构特性，查询结果具有高度精确性——前提是生成的查询语句无误。一旦查询成功，基于图数据库的特性，返回的数据一定是准确的。这种机制在很大程度上缓解了大模型在企业知识问答或数据问答场景中的“幻觉问题”。这也是采用 Text-To-Query 技术的核心原因。

3.Altair Copilot 如何回答企业用户问题

Altair Copilot 通过大模型与知识图谱结合，帮助企业内部用户高效解答问题。其流程分为四个关键步骤：

• 主体与关系提取。大模型从用户提问中解析出核心主体及其潜在关系。例如，在问题中识别“supplier”（供应商）和“distribution center”（分发中心）等主体，并捕捉它们之间的关系（如分数大于 0.7、位于某国家等）。此步骤确保问题中的语义信息被精准拆解。
• 
  
• 映射到知识图谱。大模型将提取的主体与关系映射至知识图谱或图数据库中的实体与关系。例如，“supplier”可能对应图数据库中的“PRM supplier”，而“located in”可能映射为“HQ_located_in”。通过这种映射，用户问题被转化为图数据库可理解的查询语言。
• 
  
• 生成查询并获取结果。基于映射结果，大模型生成针对知识图谱的查询语句，并将其传递给图数据库执行查询。这一过程确保返回的结果精确且无误。
• 
  
• 生成答案。大模型基于查询结果组织语言，形成自然流畅的回答，直接回应用户的原始问题。
• 

4.ChatBI 优势

与传统 BI 报表相比，Altair ChatBI 展现出以下核心优势：

• 效率提升：传统模式下，IT 或 BI 团队需预先构建分析型报表，而 ChatBI 解决方案使业务用户能够通过自然语言对话直接查询数据并生成可视化结果，无需预先构建报表，显著提高了业务用户的操作效率。
• 
  
• 应用性增强：业务用户无需深入了解业务系统或数仓中的数据结构，仅需以自然语言提问即可获取所需数据，极大降低了使用门槛，提升了系统的易用性。
• 
  
• 成本节约：通过减少 IT 人员在预定义和构建BI报表上的工作量，企业能够显著降低相关人力成本，实现资源的更高效配置。

对 Altair Graph Studio 感兴趣请扫码咨询，我们会安排专门的工作人员联系您。

产品咨询

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

赵帅

Altair

数据分析高级应用工程师

拥有数据分析行业近 15 年的工作经验，对数据治理、数据算法建模、数据分析等有深刻认识和丰富经验，拥有服装零售、商超连锁、医药零售、石化、电信 BI 等多个行业大数据项目的整体规划、方案设计与落地实施经验。

相关会议推荐：

技术前瞻与实践洞察并重

 Altair 作为计算智能领域的全球领导者，将于5月30日在上海举办“AI驱动，仿真未来”Altair 区域技术交流会。本次会议特邀了来自泛亚汽车、山东临工、零跑汽车、苏泊尔等知名企业的行业专家，共同探讨仿真智能化如何赋能工业创新，分享最新仿真与 AI 技术的应用实践。

您可在本次会议中深入了解 Altair 领先的仿真融合AI解决方案，共探在汽车、重工等领域的突破性应用，并通过实战案例掌握如何利用AI加速仿真流程、提升预测精度。诚邀您共话 AI + 仿真的未来，共同开启智能仿真技术新篇章。

立即报名

关于 Altair 澳汰尔

Altair 是计算智能领域的全球领导者之一，在仿真、高性能计算 (HPC) 和人工智能等领域提供软件和云解决方案。Altair 能使跨越广泛行业的企业们在连接的世界中更高效地竞争，并创造更可持续的未来。

公司总部位于美国密歇根州，服务于16000多家全球企业，应用行业包括汽车、消费电子、航空航天、能源、机车车辆、造船、国防军工、金融、零售等。

欲了解更多信息，欢迎访问：

www.altair.com.cn