11 月 7 日深圳丨悦数图数据库新产品发布会

应用分享

新闻资讯

用户案例

周边工具

特性讲解

发版说明

技术干货

行业实践

行业科普

中国移动：悦数图数据库在金融风控领域的落地应用

悦数图数据库发布 v3.4.0，深入探索数据价值

五矿期货：悦数图数据库在金融期货行业的应用与实践探索

同盾科技：聊聊知识图谱在金融风控场景中的应用

悦数图数据库完成鲲鹏、飞腾、海光等多款国产 CPU 信创兼容性认证

![时序图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-07-17.png)

2026 年 5 月，某全国性银行的智能风控系统出了一个令人困惑的误报。系统对一家连续合作 6 年的优质企业客户发出了"关联风险预警"——理由是该企业与一家已被列入黑名单的公司存在"股权关联"。风控团队核查后发现，这个关联确实存在过——2019 年，黑名单公司的法定代表人曾持有该企业客户 8% 的股份，但 2020 年 3 月已全部转让退出，此后双方再无任何关联。问题出在图数据库只存了"当前关系快照"——它知道"A 曾经持有 B 的股份"，但不知道这个关系已经在 2020 年结束了。系统看到的是一条"永远存在"的边，而不是一条"有过有效期"的边。这不是个别现象。某咨询公司的调研显示，72% 的企业图数据库部署中，关系边不携带时间属性——所有的边都是"当前快照"，没有起始时间、没有终止时间、没有变更历史。这意味着企业 AI 只能回答"谁和谁有关系"，无法回答"这个关系什么时候开始的、什么时候结束的、中间发生过什么变化、现在的状态是什么"。**缺少时间维度的图数据库就像一张没有日期的照片——你看到了谁和谁站在一起，但不知道这是昨天的合影还是十年前的旧照。时序图数据库的崛起，不是因为时间维度"锦上添花"，而是因为没有它，企业 AI 会把过期的关系当成有效的风险，把历史的关联当成当前的威胁——时间不是图的附加属性，时间是一切的上下文。**

### 一、静态图数据库的四类"时间盲区"

当前主流的[图数据库](https://www.yueshu.com.cn/database)在建模时默认关系是"永远有效的"——一条边一旦写入，就持续存在直到被显式删除。这种静态视角在企业场景中制造了四类系统性盲区。

**盲区一：关系过期无法自动失效。** 企业间的商业关系本质上是有时效的——股权关系会随交易变更、担保关系会随到期解除、合作关系会随合同终止。静态图数据库不知道一条边的"有效期"——2020 年建立的担保关系在 2023 年已到期，但图数据库中这条边仍然存在，AI 做关联分析时仍然把它当作有效担保计入风险敞口。某银行的排查数据显示，存量图数据库中 15-20% 的担保边已经过期但未被删除——这些"幽灵边"每天制造大量误报，风控团队不得不逐条人工核实，严重削弱了系统的可信度。

**盲区二：关系演变过程不可追溯。** 一家企业的股权结构在过去 5 年可能经历了 8 次变更——创始人持股 80% → 引入战投后降至 60% → IPO 后降至 45% → 二次定增后降至 38% → 关联方增持至 52%……每次变更都改变了实际控制人的判定。静态图数据库只保留最新状态——"当前持股 52%"——中间的 7 次变更过程全部丢失。当审计人员需要追溯"2022 年 6 月时谁是实际控制人"时，图数据库无法回答——它没有历史版本，只有当前快照。时间被压缩成了一个点，过程被抹平了。

**盲区三：事件时序无法推理因果。** 企业风险的传导是有先后顺序的——A 公司违约 → 担保链上的 B 公司承压 → B 的供应商 C 账期延长 → C 的原材料采购减少 → C 的上游 D 营收下降。这条因果链上的每一个事件都有一个明确的时间戳——A 违约是因，D 营收下降是果，因果方向由时间先后决定。静态图数据库只知道"A 和 B 有担保关系""B 和 C 有供应关系""C 和 D 有采购关系"，但不知道这些关系上的事件谁先发生谁后发生——没有时间维度，因果推理退化为相关性分析，AI 无法区分"是 A 导致了 D"还是"只是恰好都发生了"。

**盲区四：时间窗口查询无法执行。** 企业分析中最常见的问题之一是"过去 3 个月内，这家公司新增了哪些关联关系"。静态图数据库的回答只能是"当前有哪些关联关系"——它不记录每条边的创建时间，无法做时间窗口筛选。这意味着所有基于时间范围的关联分析——"近半年新增的担保""近一年变更的股东""近三个月出现的异常交易对手"——都需要在应用层自行维护时间索引，图数据库本身的查询能力完全用不上。

| 维度         | 静态图数据库       | 时序图数据库         |
| ------------ | ------------------ | -------------------- |
| 关系有效期   | 无（默认永远有效） | 起止时间+状态标记    |
| 历史追溯     | 仅当前快照         | 任意时间点重建       |
| 因果推理     | 相关性分析         | 时序因果链           |
| 时间窗口查询 | 不支持             | 原生支持             |
| 关系变更追踪 | 不记录             | 完整变更日志         |
| 误报率       | 高（幽灵边干扰）   | 低（过期边自动失效） |

### 二、时序图数据库：让每条边都带上时间戳

时序图数据库的核心改变看似简单——给每条边增加时间属性——但它引发的是查询范式和推理能力的质变。

**边的时间建模：四维属性。** 在时序图数据库中，每条边不再是"有或无"的二元存在，而是携带四个时间维度属性的结构化记录——`valid_from`（关系建立时间）、`valid_to`（关系终止时间，NULL 表示当前有效）、`last_modified`（最后一次变更时间）、`transaction_time`（数据写入图数据库的时间）。这四个属性让每条边有了完整的"生命周期"——从建立到变更到终止，每个阶段都有精确的时间标记。查询"某企业当前的有效关联关系"时，系统自动过滤 `valid_to IS NULL` 的边——过期关系不再干扰当前分析，"幽灵边"问题从根源消除。

**时间点快照重建：穿越回任意时刻。** 时序图数据库最强大的能力之一是"时间旅行"——给定一个历史时间点 T，系统能重建 T 时刻的图状态。查询"2022 年 6 月 30 日时这家公司的股权结构是什么"，系统自动筛选 `valid_from <= '2022-06-30' AND (valid_to IS NULL OR valid_to > '2022-06-30')` 的边——只返回在 2022 年 6 月 30 日当时有效的持股关系。审计人员可以在时间轴上自由滑动——看 2019 年的初始结构、2020 年的战投引入、2022 年的定增稀释、2024 年的关联方增持——每一次股权变更的"前后对比"一步查询完成。

**时序因果链推理：时间排序确定因果方向。** 当图数据库中的边携带时间戳后，因果推理从"相关性猜测"升级为"时序因果推导"。以担保链风险传导为例：A 公司 2025 年 1 月违约 → 担保方 B 公司 2025 年 2 月被追偿 → B 的供应商 C 2025 年 3 月账期从 30 天延长到 90 天 → C 的上游 D 2025 年 4 月订单减少 35%。图数据库沿担保边、供应边、采购边遍历这条四跳路径时，每条边上的事件时间戳自动排序——1 月→2 月→3 月→4 月——因果方向由时间先后直接确定。AI 生成分析报告时不再是"A 和 D 存在关联"，而是"A 的违约在 1 月发生，通过担保链传导到 B（2 月）、C（3 月）、D（4 月），传导链路总长度 4 跳、时间跨度 3 个月、D 的营收影响可量化为 35% 的下降"。

### 三、大模型 + 时序图：时间维度的推理跃迁

时序图数据库给了大模型一个全新的推理维度——时间。大模型不再只在"谁和谁有关系"的平面上推理，而是在"谁在什么时候和谁有什么关系"的四维空间中推理。

**时间感知的实体消歧。** 企业知识库中同名实体的消歧一直是个难题——三个"张伟"在同一图空间中如何区分？静态图数据库只能靠属性过滤——"华东大区、P7 职级的张伟"。时序图数据库增加了时间维度——"2022 年在华东大区任职的张伟"和"2024 年调到华南大区的张伟"可以是同一个人在不同时段的状态，也可以是两个不同的人。大模型利用时间属性做精确消歧——"问题是关于 2023 年的某个项目，那么张伟指的是 2023 年在华东大区的那位，不是 2024 年入职华南的那位"。时间维度让消歧准确率从 78% 提升到 95%+。

**关系演变趋势预测。** 时序图数据库记录了关系的完整变更历史，大模型可以从历史趋势中推理未来走向。某企业的供应链关系图谱显示：过去 3 年中，该企业每年新增 8-12 个供应商，同时淘汰 5-8 个——净增长 3-4 个/年，淘汰率约 15%。大模型基于这个时序模式推理："如果维持当前趋势，该企业未来 12 个月预计新增 8-12 个供应商、淘汰 5-8 个，供应商总数将从 67 增长到 70-71。需要关注的是淘汰率是否有加速趋势——2025 年淘汰率从 12% 上升到 18%，如果 2026 年延续这个趋势，淘汰率可能达到 24%，意味着供应链稳定性在下降。"这种推理不是"猜"——它是基于时序图数据库中的历史变更记录做的趋势外推，每一步推理都有数据支撑。

**GraphRAG 的时序增强。** GraphRAG 在时序图数据库上的推理能力产生了质的飞跃。传统 GraphRAG 的推理路径是"A → B → C → D"的静态链路——找到了路径就给答案。时序 GraphRAG 的推理路径是"A(2025-01) → B(2025-02) → C(2025-03) → D(2025-04)"的动态链路——不仅找到路径，还标注每个节点的激活时间，验证因果方向的合理性。大模型生成答案时附带完整的时序推理链："A 在 2025 年 1 月发生违约事件（因），传导至 B（2 月追偿）、C（3 月账期延长）、D（4 月订单下降，果）。传导时序合理，因果方向经时间验证，D 的营收下降可归因于 A 的违约事件，传导路径完整、时间跨度 3 个月。"可解释性从"关系路径"升级为"时间因果链"。

### 四、四类时序查询场景：企业 AI 的新能力

时序图数据库让企业 AI 能回答四类过去根本无法触及的新问题。

**场景一：关联关系时效性审查。** 银行在信贷审批中需要回答："这家企业当前的有效关联担保有多少？历史上最多时是多少？趋势是增加还是减少？"时序图数据库一条查询语句即可完成——筛选 `valid_to IS NULL` 的担保边计算当前有效敞口，按 `valid_from` 分组统计历史每月有效担保总量，趋势曲线自动生成。某银行上线时序图后，担保链审查从"3 天人工翻查历史变更记录"变为"1 条查询 200 毫秒返回"，审查效率提升 1000 倍。

**场景二：风险传导时序模拟。** "如果 A 公司今天违约，风险在 1 个月、3 个月、6 个月后分别会传导到哪里？"这是一个典型的时序推理问题——图数据库沿担保边、供应边、投资边遍历关联网络，同时根据历史传导数据估算每跳的时间延迟（担保追偿平均 30-45 天、供应商账期影响平均 60-90 天、投资减值平均 90-180 天），输出一张时间轴上的风险传导热力图——第 1 个月波及 5 家直接担保方，第 3 个月扩展到 18 家供应链关联方，第 6 个月影响范围达到 42 家。静态图数据库只能做"波及范围"的拓扑分析，时序图数据库能做"波及过程"的时间推演。

**场景三：实体关系演变画像。** "这家公司在过去 5 年中，实际控制人变更了几次？每次变更的原因是什么？每次变更前后公司的业务方向有什么变化？"时序图数据库对目标公司做时间点快照重建——分别在 2021、2022、2023、2024、2025 年末重建股权结构图，对比每次变更前后的差异。大模型结合公司公告、董事会决议等文档提取变更原因——"2022 年变更因引入战略投资者""2024 年变更因创始人股权转让"——生成完整的关系演变时间线。这是审计、尽调、投资分析中最核心也最耗时的工作，时序图数据库把它从"3 周人工梳理"变成"10 分钟自动生成"。

**场景四：异常时序模式检测。** "这家公司过去 3 个月新增的关联关系中，有没有异常模式——比如突然集中新增多个离岸壳公司关联？"时序图数据库按时间窗口检索新增边，同时运行图算法分析新增节点的属性特征——注册地是否为离岸地区、注册资本是否异常偏低、成立时间是否近期。某监管机构用这个方案在 2026 年 Q1 识别出 23 家"短期集中新增离岸关联"的企业，其中 7 家后续被确认涉及跨境资金异常转移——时序模式检测比静态关联分析提前 2-3 个月发出了预警。

### 五、悦数图数据库的核心支撑

[时序图数据库](https://yueshu.com.cn/posts/Web3-Risk-Control)对企业级图基础设施提出了四项新要求，悦数在每一项上有明确的工程支撑。

**亿级时序多跳百毫秒查询。** 时序属性让图的规模进一步膨胀——一条关系如果有 8 次变更记录，在时序图中就是 8 条带不同时间戳的边，图规模扩大 5-10 倍。悦数的分布式存储和并行查询引擎在数十亿级时序图规模下保持多跳遍历百毫秒级响应——时间过滤条件作为边属性索引被高效利用，不会因为增加了 `valid_from/valid_to` 过滤而显著增加查询延迟。

**存算分离支撑时序数据持续写入。** 时序图数据库的数据写入模式与静态图不同——静态图的写入以"新增边"为主，时序图的写入以"更新边状态"为主（每次变更产生一条新的时间版本边，旧边设置 `valid_to`）。悦数存算分离架构让写入和查询在独立节点上执行——时序数据持续写入不阻塞查询服务，查询高峰期弹性扩容计算节点，低峰期自动缩回。

**动态 Schema 时间版本管理。** 不同业务场景对时间粒度的要求不同——金融交易需要秒级精度，股权变更需要日级精度，合作关系需要月级精度。悦数动态 Schema 允许为不同边类型定义不同的时间精度和版本策略——交易边保留全量秒级历史、股权边保留日级变更版本、合作边仅保留月级快照。灵活的时间版本策略避免了一刀切带来的存储浪费，让时序数据的管理成本可控。

**Text2nGQL 时序自然语言查询。** 时序查询的复杂度远高于静态查询——"2022 年 6 月时这家公司谁是实控人"需要时间点快照重建，"过去 3 个月新增了哪些关联"需要时间窗口过滤，"风险在 6 个月后传导到哪里"需要时序模拟。Text2nGQL 把这些复杂的时序查询语句自动生成——用户用自然语言提问，系统自动翻译为带时间条件的 nGQL 语句。时序图数据库的强大能力不再被查询语法门槛阻挡。

### 六、从"静态快照"到"时序推理"：升级路线图

图数据库从静态到时序的升级，是三个阶段的递进演进。

| 阶段                   | 目标                            | 核心工作                                                     | 参考周期 |
| ---------------------- | ------------------------------- | ------------------------------------------------------------ | -------- |
| 第一阶段：时间属性标注 | 消除"幽灵边"误报                | 现有边增加 valid_from/valid_to 属性、过期边自动标记、当前有效查询过滤上线 | 4-6 周   |
| 第二阶段：时序查询能力 | 支持时间点重建与时间窗口分析    | 全量历史变更数据导入、时间点快照重建、时间窗口关联查询、时序因果链推理 | 8-12 周  |
| 第三阶段：时序智能推理 | 图遍历+大模型协同做时间维度推理 | GraphRAG 时序增强、关系演变趋势预测、风险传导时序模拟、异常时序模式检测 | 12-16 周 |

第一阶段解决的是"不误报"的问题——给现有图数据库的边补上时间属性，过期关系自动失效，消除 15-20% 的幽灵边干扰。这是成本最低、见效最快的改进——不需要重建图，只需要在现有边上增加两个时间属性列。

第二阶段解决的是"能回溯"的问题——把历史变更数据导入图数据库，支持任意时间点快照重建和时间窗口关联查询。审计、尽调、合规审查中最耗时的"历史关联追溯"工作自动化完成——从"3 周人工梳理"变成"10 分钟自动生成"。

第三阶段解决的是"能推理"的问题——时序图数据库和大模型在引擎层深度耦合，AI 不仅回答"现在是什么""过去是什么"，更推理"未来会怎样"。关系演变趋势预测、风险传导时序模拟、异常时序模式检测——这些过去需要资深分析师用经验判断的问题，时序 GraphRAG 能基于数据自动推理。

**关系不是静态的快照，而是动态的流。一家企业的关联网络不是一张照片，而是一部电影——每一帧都有时间戳，每一帧之间都有因果。当时序图数据库让 AI 终于能"看懂这部电影"，企业从关联分析中获得的不再是"谁和谁有关系"的事实清单，而是"关系怎么来、怎么变、往哪去"的完整因果链路。时间维度不是图数据库的补充，而是图数据库从"存储工具"进化为"推理引擎"的关键一跃。**



悦数图数据库通过亿级多跳百毫秒查询、存算分离弹性扩缩容、动态 Schema 时间版本管理、原生 GraphRAG 引擎层耦合与 Text2nGQL 自然语言接口，让图数据库从"静态关系快照"进化为"时序关联网络"。

时序图数据库崛起——当关系带上时间维度，企业 AI 能回答什么新问题？

![Web3图数据库重塑 Web3](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-07-16.png)

一位 DeFi 协议的开发者在社区里吐槽了一个真实经历：用户在他的 DApp 上点击"查看钱包关联交易"，页面加载了 47 秒才返回结果。他排查后发现，瓶颈不在前端也不在服务器——而是链上数据查询本身。要回答"这个钱包地址在过去 30 天内与哪些合约发生过交互、这些合约之间有没有资金流转关系、有没有异常的关联地址群"，他需要先从以太坊节点逐条扫描该地址的交易记录（RPC 调用，每秒 15-20 条），再把每条交易涉及的合约地址作为新起点重复扫描——5 跳关联查询意味着 5 层递归 RPC 调用，在以太坊主网上需要 3-8 分钟。他想改用 The Graph 的子图索引，但子图只能覆盖他提前定义的关系模式——如果用户问的是"这个地址有没有通过中间合约和某个已知黑名单地址产生间接资金关联"，这种动态多跳查询不在子图定义范围内，要么重新部署子图（需要重新同步全量数据，耗时数天），要么回到逐条 RPC 扫描。这个困境不是某一条链或某一个协议的个例，而是 Web3 数据基础设施的系统性问题。**链上数据天然是图结构——地址、合约、代币、交易是节点，转账、调用、授权是边。但现有的查询工具要么把图压成表（SQL 索引），要么把图切成子图（The Graph），要么干脆让用户逐条扫描（RPC），没有一个真正在图结构上做多跳遍历。[图数据库](https://www.yueshu.com.cn/database)不是"链上数据的新索引方案"，而是链上数据的"原生运行环境"——它终于让数据回到了自己该在的结构里。**

### 一、链上数据查询慢的三层根因

链上数据查询的延迟不是优化不够，而是从数据结构到查询范式到存储架构的三层系统性缺陷。

**根因一：链上数据的原生结构是图，但查询工具用表。** 每一笔链上交易本质上是一条边——连接发送地址和接收地址的关系记录，携带金额、时间、Gas 等属性。一个地址的完整链上画像不是"这个地址的交易列表"（表格视角），而是"以这个地址为中心的关系网络"（图视角）——它和哪些地址有过转账、这些地址又和哪些合约交互、哪些合约被同一个开发者部署、哪些代币在这些地址之间流转。传统 SQL 索引把交易记录存为"交易表"，查单地址交易列表很快，但做关联查询需要反复，3 层 JOIN 之后查询时间从毫秒跳到秒级，5 层以上基本不可执行。图结构被压成表后，多跳遍历变成了多表 JOIN——维度变了，效率自然崩塌。

**根因二：The Graph 的子图模式是"预定义切片"，不支持动态多跳。** The Graph 是 Web3 最广泛使用的索引方案——开发者用 GraphQL 定义子图（subgraph），指定要索引的实体类型和关系模式，The Graph 同步链上数据后按定义构建索引。子图在单跳查询上表现优秀——"查某个地址的 ERC-20 转账记录"可以秒级返回。但子图的结构是开发者预先定义的——你在定义子图时写的是 `Transfer { from, to, value }`，它就只索引这三列。如果用户后来问"from 这个地址还和其他哪些合约有过交互"，这个关系不在子图定义范围内，The Graph 无法回答——除非你重新修改子图定义、重新部署、重新同步全量数据。这个过程需要 2-5 天。Web3 的查询需求高度动态——安全团队今天想查资金归集路径、明天想查关联地址群、后天想查跨链桥流向，每种需求都对应不同的多跳路径。子图的"预定义切片"模式根本跟不上这种动态性。

**根因三：RPC 直连节点的扫描范式是最慢但最常用的方式。** 大量 DApp 的后端仍在用 RPC 调用直接查询链上节点。这种方式的延迟取决于两个因素：节点响应速度（以太坊主网公共节点平均 200-500ms/次）和数据量（一个活跃地址的月交易量可达 5000+ 条）。单地址查询还好，但多跳关联查询是指数级增长——第 1 跳扫描 5000 条交易，提取 300 个关联地址；第 2 跳对 300 个地址各扫描 5000 条交易，提取 90000 条关联……RPC 扫描模式的本质是"在无索引的海量数据上做深度优先遍历"——每一步都在翻整本字典找某个词，而不是翻目录。

| 查询方式       | 单跳延迟 | 3 跳延迟             | 5 跳延迟    | 动态多跳       | 跨链查询       |
| -------------- | -------- | -------------------- | ----------- | -------------- | -------------- |
| RPC 直连节点   | 5-30s    | 分钟级               | 不可用      | 不支持         | 不支持         |
| SQL 索引       | 毫秒级   | 秒级                 | 分钟级/超时 | 不支持         | 多库联合       |
| The Graph 子图 | 毫秒级   | 秒级（预定义范围内） | 不支持      | 需重新部署子图 | 需部署多个子图 |
| 图数据库       | 毫秒级   | 百毫秒级             | 百毫秒级    | 原生支持       | 统一图遍历     |

### 二、图数据库：链上数据的原生运行环境

图数据库对链上数据的价值不是"比现有方案快一点"，而是数据模型层面的归位——链上数据终于回到了它天生的结构里。

**节点建模：地址、合约、代币、交易四类核心实体。** 在图数据库中，链上数据的四类核心实体直接建模为节点——地址节点（携带余额、首次活跃时间、标签等属性）、合约节点（携带创建者、部署时间、合约类型等属性）、代币节点（携带名称、总供应量、合约地址等属性）、交易节点（携带哈希、金额、Gas、时间戳等属性）。这四类节点在同一个图空间里通过边直接连接，无需 JOIN——地址 A 通过"转账"边连接地址 B，地址 B 通过"调用"边连接合约 C，合约 C 通过"发行"边连接代币 D。一个地址的完整链上画像就是以该地址节点为中心的子图——所有关联实体和关系一步展开，不需要"先查交易表再查合约表再查代币表"。

**边建模：转账、调用、授权、归属四类核心关系。** 链上的核心交互模式天然对应四种边类型——转账边（from → to，携带金额和时间）、调用边（地址 → 合约，携带函数签名和参数）、授权边（地址 → 合约，携带授权额度和代币类型）、归属边（合约 → 创建者地址，携带部署交易哈希）。这些边在图数据库中不是表格中的列，而是有方向、有类型、有权重的连接——查询"地址 A 通过中间合约转账给地址 B"不再是 JOIN 三张表再过滤，而是沿"转账边→调用边→转账边"这条三跳路径直接遍历，百毫秒完成。

**多跳遍历：关联关系一键展开。** 以一个典型的安全查询为例："地址 0x7a2b…有没有通过任何中间路径与已知黑名单地址 0x3f1c…产生过资金关联？"图数据库的做法是：从 0x7a2b 出发，沿转账边和调用边做双向遍历，设置最大跳数为 5，在遍历过程中实时检查每个到达的节点是否是 0x3f1c 或与 0x3f1c 有直接转账关系。一条 nGQL 语句就能完成这个 5 跳关联查询——如果存在关联路径，返回完整路径链路；如果不存在，返回空结果。查询时间取决于路径长度和数据量，在亿级图规模下 5 跳遍历百毫秒级响应。对比 RPC 扫描方式做同样查询需要 3-8 分钟——效率差距不是优化级，是范式级。

### 三、跨链图谱：多链世界的统一查询层

Web3 最大的数据挑战不是单链查询慢，而是多链数据各自孤立——以太坊上的地址和 Polygon 上的地址没有关联索引，跨链桥的资金流向分散在两条链上各查各的，一个用户的完整链上画像需要分别在 5 条链上做 5 次独立查询再人工拼接。

**跨链桥建模：两条链之间的"传送门"。** 跨链桥（如 Polygon Bridge、Arbitrum Bridge）在图数据库中建模为一类特殊的边——"桥接边"（Bridge Edge），连接两条链上的两个地址节点，携带桥接金额、目标链 ID、桥接时间等属性。这条边让以太坊上的地址 A 和 Polygon 上的地址 B 在同一个图空间里直接相连——查询"以太坊地址 A 的资金有没有通过跨链桥流向 Polygon"不再是"先在以太坊查 A 的出账记录 → 找到桥合约调用 → 再去 Polygon 查入账记录"的两步操作，而是沿"转账边→桥接边→转账边"的三跳遍历一步完成。

**统一图空间：多链数据融合建模。** 悦数图数据库的存算分离架构支持多链数据的统一建模——以太坊、Polygon、Arbitrum、BSC 等多条链的地址、交易、合约数据导入同一个图数据库，每条链的节点携带 `chain_id` 属性标识来源链，跨链桥接边连接不同链上的节点。查询"地址 A 在所有链上的完整活动画像"不再需要 5 次独立查询——一条 nGQL 语句 `MATCH (a:Address {hash: '0x7a2b...'})-[r*1..3]-(x) WHERE x.chain_id IN ['ethereum', 'polygon', 'arbitrum'] RETURN x, r` 就能一次性展开 A 在三条链上的 3 跳关系网络。跨链数据从"各查各的"变成"一图统览"。

**动态 Schema 兼容多链异构。** 不同链的数据结构差异显著——以太坊有复杂的合约调用日志（4 列参数），Solana 的交易结构完全不同（指令列表+账户键），Cosmos 的跨链消息格式独特（IBC 协议头）。悦数动态 Schema 允许为每条链定义不同的节点属性和边属性模板——以太坊合约节点有 `abi` 属性，Solana 程序节点有 `program_id` 属性，两者在同一个图空间里共存但互不干扰。新增一条链的数据只需要新增对应的 Schema 模板，不需要重建整个图——数据随链扩展，图随数据生长。

### 四、三大实战场景：图数据库在 Web3 的核心应用

**场景一：链上安全——关联地址群与资金归集路径实时识别。** 链上安全团队的核心工作是识别异常模式——某个地址突然向 50 个新地址分散转账（可能是洗钱的分层阶段），或者 50 个地址的资金最终归集到同一个目标地址（可能是诈骗的归集阶段）。传统方式是用 RPC 扫描或 SQL 查询逐个地址检查，一次完整扫描需要 10-30 分钟。图数据库的做法是：从可疑地址出发，沿转账边做多跳遍历，同时运行 Louvain 社群发现算法识别紧密关联的地址群——50 个"分散层"地址和 1 个"归集层"地址自动划为同一个社群，社群内的资金流向结构一目了然。PageRank 算法进一步量化每个地址在社群中的"中心性"——归集地址的 PageRank 分数远高于分散地址，直接定位资金最终去向。一次图遍历 + 两次图算法，2 秒完成传统方式 30 分钟的工作量。

**场景二：DeFi 协议——流动性路径与合约依赖链分析。** DeFi 协议的复杂性不在单个合约，而在合约之间的依赖链——一个 Swap 操作可能涉及 3-5 个合约的嵌套调用（路由合约 → 池合约 → 代币合约 → 费用合约），一个闪电贷攻击可能沿这条依赖链在 7 个协议之间完成套利环路。图数据库把合约调用链建模为"调用边"的路径——从一个入口合约出发，沿调用边遍历到所有下游合约，每条边携带调用函数和参数金额。查询"这个 Swap 操作涉及哪些合约、资金流向路径是什么"不再是逐个合约手动追踪，而是沿调用边路径一键展开。闪电贷攻击的完整环路在图数据库中是一条闭合路径——从借款合约出发经过 7 个协议最终回到还款合约，Louvain 算法自动识别这条异常环路并标记为高风险。

**场景三：NFT 与社交图谱——所有权链路与创作者网络。** NFT 的价值链不仅是"谁持有哪个 Token"——还包括"谁创造了这个系列""谁铸造了这件作品""这件作品从创作者到当前持有者经过了哪些转移"。图数据库把 NFT 的完整生命周期建模为一条时间路径——创作者节点通过"创建系列"边连接系列节点，系列节点通过"铸造"边连接作品节点，作品节点通过"转移"边连接一系列持有者节点。查询"这个 NFT 的完整所有权历史"就是沿这条路径遍历——从当前持有者回溯到创作者，完整链路一步展开。创作者网络更有价值——某个创作者和哪些收藏者频繁交互、哪些收藏者之间有共同的收藏偏好、整个系列的流通结构是什么，这些关系在图数据库中沿边遍历即可发现。

### 五、悦数图数据库的核心支撑

Web3 数据基础设施对图数据库提出了四项硬性要求，悦数在每一项上有明确的工程支撑。

**亿级多跳百毫秒遍历。** 以太坊主网的历史交易量超过 20 亿笔，加上地址、合约、代币等实体节点，总图规模轻松达到数十亿级。链上关联查询的核心操作是多跳遍历——从锚定地址出发走 3-7 跳找到关联路径。悦数的分布式存储和并行查询引擎在数十亿级图规模下保持 5 跳遍历百毫秒级响应——DApp 用户按下"查看关联交易"按钮，结果在不到 1 秒内返回，体验和查单条交易一样流畅。

**存算分离弹性扩缩容。** 链上数据持续高速增长——以太坊每天新增 100 万+ 笔交易，Solana 每天新增 2000 万+ 笔。图数据库需要在数据持续写入的情况下保持查询服务不中断，同时在查询高峰期（市场波动引发大量关联查询）弹性扩容计算资源。悦数存算分离架构让写入和查询在独立节点上执行——数据同步不阻塞查询，高峰期临时增加计算节点，低峰期自动缩回，成本随负载弹性波动。

**动态 Schema 兼容多链异构。** Web3 的链生态持续扩展——新链、新协议、新代币标准随时出现。悦数动态 Schema 允许不停机新增节点类型和边类型——新增一条链的数据只需要定义对应的 Schema 模板，不需要重建图。Solana 的指令日志、Cosmos 的 IBC 消息、zkSync 的 L2 状态差异都可以用各自的 Schema 模板建模，共存于同一个图空间中。

**Text2nGQL 自然语言查询链上数据。** 链上数据查询的最终用户不是开发者，而是 DApp 用户和安全分析师——他们不会写 nGQL，但他们能说"帮我查一下这个钱包有没有和黑名单地址关联"。Text2nGQL 把自然语言自动翻译为图查询语句——"查看 0x7a2b…的关联地址群"自动翻译为多跳遍历查询。链上数据查询的使用门槛从"需要区块链工程师"降到"任何人都能用"。

### 六、从"慢查询"到"基础设施"：Web3 数据升级路线图

链上数据从"查询总是慢"到"基础设施核心能力"的升级，是三个阶段的递进演进。

| 阶段                        | 目标                                    | 核心工作                                                     | 参考周期 |
| --------------------------- | --------------------------------------- | ------------------------------------------------------------ | -------- |
| 第一阶段：单链图索引        | 解决单链关联查询慢的问题                | 单链数据导入图数据库、地址/交易/合约节点建模、3-5 跳遍历查询上线、替代 RPC 扫描 | 4-6 周   |
| 第二阶段：跨链统一图谱      | 多链数据融合，跨链关联一键展开          | 跨链桥接边建模、多链统一图空间、动态 Schema 兼容异构链、图算法安全分析上线 | 8-12 周  |
| 第三阶段：GraphRAG 深度推理 | 图遍历+大模型协同，链上智能分析全面上线 | 引擎层耦合推理、Text2nGQL 自然语言查询、跨链风险传播预测、DeFi 协议依赖链自动发现 | 12-16 周 |

第一阶段解决的是"查得到"的问题——用图数据库替代 RPC 扫描和 SQL JOIN，单链关联查询从分钟级降到百毫秒级。这是投入产出比最高的起步——一次部署替代所有 RPC 扫描场景，DApp 用户体验从"等 30 秒"变成"秒级响应"。

第二阶段解决的是"看得全"的问题——多链数据融合建模，跨链关联查询一步完成。图算法上线让安全分析从"逐个地址检查"变成"社群自动发现+中心性自动量化"——安全团队不再需要手动追踪资金流向，图数据库自动画出完整的关联地址群和资金归集路径。

第三阶段解决的是"推得深"的问题——图遍历和大模型在引擎层深度耦合，链上智能分析从"查历史"进化为"预测未来"。[GraphRAG](https://yueshu.com.cn/posts/graph-rag) 能回答"这笔新交易是否可能是攻击的前兆""这个地址的关联网络中有没有隐藏的风险传导路径"——不再只是查询已经发生的事，而是推理可能发生的事。

**链上数据天生是图——它由地址和交易编织成一张无边界的网络。当查询工具终于匹配了数据的原生结构，链上数据查询从"Web3 的痛点"变成了"Web3 基础设施的核心能力"。图数据库不是给链上数据加了一层索引，而是让链上数据回到了它该在的家。**



悦数图数据库通过亿级多跳百毫秒查询、存算分离弹性扩缩容、动态 Schema 兼容多链异构、Text2nGQL 自然语言查询与 Studio 可视化链路追踪，重塑 Web3 数据基础设施——从"链上数据只能逐条扫描"到"关联关系一键展开"，从"多链数据各查各的"到"跨链图谱统一遍历"，从"查询耗时分钟级"到"百毫秒响应"，让链上数据查询从痛点变成基础设施的核心能力。

链上数据查询为什么总是那么慢？图数据库重塑 Web3 数据基础设施

![GraphRAG](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-07-15.png)

某券商研究所的分析师在用内部 RAG 系统做行业研究时遇到一个典型困境。他问系统："宁德时代的上游供应商中，哪些同时是比亚迪的供应商，且这些供应商在 2025 年三季度的净利润环比下降超过 20%？"系统返回了三段文档——一段宁德时代 2024 年年报中提到"上游供应商包括赣锋锂业、天赐材料等"，一段比亚迪的招股说明书中列出"主要原材料供应商包括天赐材料、多氟多等"，还有一段某财经媒体关于天赐材料三季度利润下滑的报道。三段文档都是相关的，但系统没有把它们关联起来——它不知道"天赐材料"在第一段和第二段中是同一个实体，更没有能力把"供应商交集"和"利润下滑"这两个条件组合推理。分析师最终自己花了 40 分钟翻完六份报告，手工拼出了答案：天赐材料和多氟多两家同时供应宁德时代和比亚迪，且三季度净利润环比分别下降 23% 和 31%。这不是 RAG 系统不够努力，而是它的数据模型决定了它的天花板——**传统的 RAG 是在"文档堆"里做关键词和向量匹配，而企业真正需要的是在"知识网"里做关系推理。两者的差距，不是搜索精度的差距，是数据结构的代差。**

### 一、"文档堆"式 RAG 的三层天花板

当前绝大多数企业部署的 RAG 系统，底层架构是"文档→分块→向量化→检索→拼接→生成"的线性流水线。这条流水线在"找文档"场景下表现尚可，但在"推理型问题"面前存在三层结构性天花板。

**第一层：分块切断了实体关系。** 文档分块（chunking）是 RAG 的标准前置步骤——把长文档切成 512 或 1024 个 token 的片段，每个片段独立向量化。问题在于，企业知识中的实体关系天然是跨文档的：宁德时代的供应商列表在年报 A 里，比亚迪的供应商列表在招股书 B 里，供应商的财务数据在财报 C 里——这三个信息片段分散在三个文档的不同分块中。向量检索只能基于语义相似度逐个召回片段，它没有"实体"的概念，不知道"天赐材料"在不同文档里指的是同一家公司，更不会主动去把三个片段关联起来做交集运算。分块越多，实体被切断得越碎，关联就越难建立。

**第二层：向量相似度无法表达关系语义。** 向量检索的核心是"语义距离"——两段文本在向量空间中越近，相似度越高。但企业问题的核心不是"相似"，而是"关联"。问"宁德时代和比亚迪的共同供应商"——这不是在问"哪段文档和这个问题最相似"，而是在问"两家公司的供应商集合的交集是什么"。这是一个集合运算，需要先分别检索两家公司的供应商列表，再做交集。向量检索的模型里没有"集合"和"交集"的概念，它只能返回"和这个问题语义最接近的文档片段"——于是返回了三段各包含部分信息的片段，至于怎么组合、怎么推理，全靠大模型在 prompt 里临场发挥。大模型的推理能力在上下文窗口有限、实体消歧不完整的情况下，准确率大打折扣。

**第三层：检索结果缺少推理路径。** 传统 RAG 返回的是"top-K 相关文档片段"——用户看到的是五段文本，但不知道这五段文本之间是什么关系、为什么被一起召回、它们如何推导出最终答案。在简单的事实查找场景中这不是问题——"公司年报里写的营收是多少"只需要一段文档。但在多跳推理场景中，可解释性至关重要——分析师需要知道"系统是怎么得出'天赐材料是共同供应商'这个结论的"，需要验证"天赐材料在三份文档中确实是同一家公司"。传统 RAG 的返回结果是一个黑盒——给了答案，但给不出推理过程。

| 维度       | "文档堆"式 RAG             | "知识网"式 GraphRAG    |
| ---------- | -------------------------- | ---------------------- |
| 数据模型   | 文档→分块→向量             | 实体→关系→图结构       |
| 检索逻辑   | 向量相似度匹配             | 多跳关系遍历+向量混合  |
| 实体消歧   | 不支持                     | 原生支持               |
| 跨文档关联 | 依赖大模型临场推理         | 图遍历自动完成         |
| 推理深度   | 1-2 跳（受限于上下文窗口） | 5-7 跳（图遍历无上限） |
| 可解释性   | 相似度分数                 | 完整推理路径           |
| 多跳准确率 | 30-40%                     | 80-90%                 |

### 二、从"文档堆"到"知识网"：数据模型的根本转变

[GraphRAG](https://yueshu.com.cn/posts/graph-rag) 的核心不是在传统 RAG 上叠加一个图数据库，而是从数据模型层面重建知识库的底层结构——把"文档"分解为"实体"和"关系"，把"分块检索"升级为"图遍历推理"。

**实体提取与图谱构建。** 知识网的第一步是把文档中的信息提取为结构化的实体和关系。大模型负责从非结构化文档中识别实体——"宁德时代"是公司实体、"天赐材料"是公司实体、"供应商"是关系类型。提取出的实体和关系写入图数据库，形成知识图谱的节点和边。每条边携带元数据：关系来源（哪份文档的哪一段）、关系时效（起始日期）、置信度（大模型提取的把握程度）。这意味着图数据库中的每一条关系都可追溯到原始文档——不是"大模型凭空编出来的"，而是"有据可查的结构化事实"。

**实体消歧：同一实体自动合并。** 当大模型从三份不同文档中分别提取出"天赐材料""广州天赐高新材料股份有限公司""天赐"时，图数据库通过实体消歧算法识别它们指向同一家公司——基于工商注册号、统一社会信用代码、简称别名表等规则做精确匹配，再用名称相似度和关系上下文做模糊补充。三个实体节点合并为一个，三份文档中的供应商关系边都指向同一个节点——"天赐材料是宁德时代的供应商"和"天赐材料是比亚迪的供应商"这两条边现在挂在同一个节点上，交集运算自然成立。

**图遍历替代向量匹配。** 知识网建好后，用户提问的检索方式从"向量找最相似的片段"变成"图遍历走关系路径"。以"宁德时代和比亚迪的共同供应商中三季度利润下滑超过 20% 的有哪些"为例：第一步，从"宁德时代"节点出发，沿"供应商"边遍历到所有供应商节点——得到集合 A（赣锋锂业、天赐材料、华友钴业等 12 家）；第二步，从"比亚迪"节点出发，沿"供应商"边遍历到所有供应商节点——得到集合 B（天赐材料、多氟多、融捷股份等 9 家）；第三步，计算 A ∩ B 的交集——得到共同供应商集合 C（天赐材料、多氟多）；第四步，对集合 C 中每个节点沿"财务数据"边遍历到三季度财报节点，筛选净利润环比降幅 > 20% 的——得到最终答案：天赐材料（-23%）、多氟多（-31%）。四步图遍历，200 毫秒完成，每一步都有明确的关系类型和方向。传统 RAG 用向量检索+大模型推理做了 40 分钟还没做对的事，GraphRAG 在不到 1 秒内精确完成。

### 三、大模型在 GraphRAG 中的新角色

从"文档堆"到"知识网"的升级中，大模型不是被边缘化了，而是从"万能但不可靠的推理引擎"变成了"精准且可追溯的知识提取器"。大模型在 GraphRAG 中承担三个新角色。

**角色一：知识提取引擎。** 大模型的核心能力是语义理解——从非结构化文档中精准提取实体、关系和属性。这一步在图谱构建阶段至关重要——不是简单的命名实体识别（NER），而是深度语义提取：从一段财报中提取"天赐材料向宁德时代供应电解液，2025 年上半年供应额 8.2 亿元，占总采购额的 12%"——这条信息包含实体（天赐材料、宁德时代）、关系（供应电解液）、属性（供应额 8.2 亿、占比 12%、时间 2025 上半年）。大模型把这些信息结构化为图数据库中的节点和边，原始文档中的非结构化知识从此变为可遍历、可计算的结构化资产。

**角色二：意图解析与查询路由。** 用户用自然语言提问时，大模型负责理解意图并路由到正确的检索策略。简单事实型问题（"宁德时代的注册资本是多少"）路由到属性查找；关系型问题（"宁德时代的供应商有哪些"）路由到单跳图遍历；推理型问题（"宁德时代和比亚迪的共同供应商中利润下滑的有哪些"）路由到多跳图遍历+集合运算。大模型同时做实体识别和消歧——从问题中提取"宁德时代""比亚迪""共同供应商""利润下滑"等关键概念，映射到图数据库中的节点和边类型，自动生成 nGQL 查询语句。这个能力就是 Text2nGQL——用户不需要学图查询语言，大模型替他们写。

**角色三：推理结果的自然语言组装。** 图遍历返回的是结构化结果——节点列表、关系路径、属性值。大模型把这些结构化数据"翻译"成用户能理解的自然语言答案——"宁德时代和比亚迪的共同供应商中，天赐材料三季度净利润环比下降 23%，多氟多下降 31%。两家供应商均面临上游原材料价格波动压力，建议关注其四季度盈利恢复情况。"大模型同时利用图遍历返回的关系路径做推理增强——沿着"天赐材料→原材料→碳酸锂→价格走势"这条边发现碳酸锂价格在三季度下跌 18%，补充解释"利润下滑的主因是下游压价而非成本上升"。这种"图遍历提供骨架、大模型提供血肉"的协同，让答案既有事实精度又有分析深度。

### 四、GraphRAG 的三大企业实战场景

**场景一：金融研报的关联推理。** 券商分析师的核心工作是发现市场中的关联性——某行业的政策变化如何影响上下游产业链、某公司的业绩波动如何传导到其供应商和客户。传统研报 RAG 只能做"找相关研报"的检索，GraphRAG 能做"推理产业链传导路径"的分析。问"如果碳酸锂价格继续下跌 15%，哪些上市公司受影响最大"，GraphRAG 从"碳酸锂"节点出发，沿"下游产品"边找到"电解液""正极材料"，沿"生产商"边找到天赐材料、多氟多等公司，再沿"客户"边找到宁德时代、比亚迪，最后沿"营收占比"边计算每家公司的碳酸锂成本敏感度——一次遍历输出完整的传导链路和量化影响排序。

**场景二：企业内部知识管理的精准问答。** 大型企业的内部知识库包含技术文档、产品手册、SOP、培训材料、项目复盘报告等数千份文档。员工问"我们上次处理类似客户数据泄露事件的流程是什么、涉及哪些部门、花了多长时间"，传统 RAG 返回所有包含"数据泄露"关键词的文档列表。GraphRAG 从"数据泄露事件"节点出发，沿"处理流程"边找到 SOP 节点，沿"负责部门"边找到信息安全部和法务部，沿"处理时长"属性找到"从发现到关闭耗时 72 小时"——直接返回结构化答案而非文档列表。员工不需要再打开文档自己找，一步到位。

**场景三：医疗临床决策支持。** 医院的知识库包含病历、诊疗指南、药物说明书、临床研究论文等。医生问"这位患者同时服用了华法林和某抗生素，有没有相互作用风险、应该怎么调整剂量"，GraphRAG 从"华法林"节点出发，沿"药物相互作用"边找到该抗生素，沿"相互作用机制"边找到"CYP2C9 酶抑制"，沿"临床建议"边找到"建议华法林剂量减少 30%、监测 INR 值"——一次遍历给出完整的药物相互作用链路和剂量调整建议，每一步都有临床指南和文献来源可追溯。

### 五、悦数图数据库的核心支撑

GraphRAG 对底层[图数据库](https://yueshu.com.cn/database)提出了五项硬性要求，悦数在每一项上有明确的工程支撑。

**原生 GraphRAG 引擎层耦合。** GraphRAG 的技术核心是"图遍历+大模型推理"的协同。悦数不是在应用层用 API 把图数据库和大模型"拼"在一起，而是在引擎层面做深度耦合——图遍历的中间结果直接流过大模型推理管线，中间步骤不需要跨进程通信，端到端延迟降低 60% 以上。引擎层耦合还保证了推理可追溯性——大模型生成的每一个结论都能回溯到具体的图遍历路径和实体属性，杜绝"大模型编造关系"的风险。

**亿级多跳百毫秒查询。** 大型企业的知识图谱规模可达数千万到数亿个实体——产品、人员、客户、供应商、文档、工单，加上关系边总规模轻松突破十亿级。GraphRAG 的核心操作是多跳遍历——从锚定实体出发走 3-7 跳找到答案路径。悦数的分布式存储和并行查询引擎在亿级图规模下保持 5 跳遍历百毫秒级响应，确保推理体验的实时性——用户提问后答案在感知不到延迟的情况下返回。

**Text2nGQL 自然语言接口。** GraphRAG 的交互方式不应该是"用户学 nGQL 写查询语句"，而应该是"用户用自然语言提问，系统自动翻译"。Text2nGQL 将用户的自然语言问题自动转化为 nGQL 图查询语句——"帮我查一下宁德时代和比亚迪的共同供应商"自动翻译为多跳遍历查询语句。这让 GraphRAG 的使用门槛从"需要数据工程师"降到"任何人都能用"。

**动态 Schema 知识持续生长。** 企业知识结构不是静态的——新业务线、新产品、新供应商、新员工随时加入。悦数动态 Schema 允许在不停机的情况下新增节点类型和边类型——知识图谱随业务持续生长，而不是"建一次用三年，三年后推倒重建"。新增的文档通过大模型自动提取实体和关系写入图谱，知识网越用越密、越用越准。

**Studio 可视化推理路径调试。** GraphRAG 的推理路径对开发者和业务人员都有价值——开发者需要调试"为什么查出来的答案不对""哪一跳的过滤条件有问题"，业务人员需要理解"答案是怎么推出来的"。悦数 Studio 提供交互式图谱可视化界面，推理结果附带完整的关系路径子图——节点大小反映关联强度，边颜色反映关系类型，高亮标注遍历路径。业务人员可在可视化界面上交互探索——展开某个实体的完整关系网络、切换不同跳数、对比不同时间段的图谱变化。

**知识库的本质不是存了多少文档，而是文档之间的关联有多深。"文档堆"解决的是"信息存储"问题，"知识网"解决的是"知识推理"问题。当 RAG 从"搜索"走向"推理"，企业知识库才真正从"成本中心"变成"智能引擎"。**

悦数图数据库通过原生 GraphRAG 引擎层耦合、亿级多跳百毫秒查询、Text2nGQL 自然语言接口、动态 Schema 与 Studio 可视化，让企业知识库从"文档堆"进化为"知识网"——RAG 不再只是从文档片段中"搜"答案，而是沿实体关系网络多跳"推理"出答案，从召回率 40% 跃升到 85%+，让大模型真正读懂企业知识。