![数据血缘的图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-21.png)

治理团队维护了一张血缘表，Excel 格式，八十几行，记录着核心表之间的依赖关系。这是很多企业在引入[图数据库](https://www.yueshu.com.cn/database)之前的真实状态。改字段之前，数据负责人特意查了一遍，结论是「下游只有两张报表会受影响」，于是按计划改了类型。

三天后，第六个系统的日终对账任务挂了。

事后复盘发现，那条链路是 ETL 工程师在调度脚本里临时加的，没有登记进血缘表。类似的情况不是孤例：那张 Excel 上一次更新是四个月前，而这两个月里新增了四十多个加工任务。血缘表不是没人管，是**根本管不住**——因为数据加工这件事发生在 SQL 与调度脚本里，每天都在变，而文档更新永远是滞后的。

这就是为什么数据血缘这件事，最后都会走到同一个地方：不能靠人填，得靠系统采集；不能存成表格，得存成图。这篇文章讲清楚三件事：血缘该怎么建模、数据从哪来、以及影响分析到底怎么算。

# 一、人工血缘为什么会失效

先看清失效的机制，才知道该建什么。人工维护的血缘有三个绕不过去的失效点。

| 失效点     | 具体表现                                  | 为什么绕不过去              |
| ---------- | ----------------------------------------- | --------------------------- |
| 变更频率   | 每周新增数十个加工任务                    | 文档更新速度追不上开发速度  |
| 跨系统     | 数仓、业务库、调度平台、BI 工具各自为政   | 没有一个地方能看到全链路    |
| 逻辑藏匿   | 依赖关系写在 SQL 的 WHERE、JOIN、临时表里 | 不解析 SQL 就看不见这层关系 |
| 责任人分散 | 每条链路由不同团队维护                    | 没人对完整链路负责          |

第三点最要命。一条血缘关系的「事实来源」不是文档，而是那段加工 SQL——它从哪张表读、按什么条件过滤、写到哪张表。只要不去解析 SQL，血缘就只能靠人回忆，而人对三个月前写的逻辑的记忆是不可靠的。

**所以第一个结论：血缘必须从执行逻辑里采集，而不是从文档里维护。**文档可以做补充说明，但不能作为事实来源。

# 二、血缘的本质是一张有向图

抛开工具不谈，血缘描述的是一组实体与它们之间的依赖关系——这本身就是一个图结构。

| 图元素       | 血缘里的对应物               | 关键属性                                    |
| ------------ | ---------------------------- | ------------------------------------------- |
| 点：表       | 库表、视图、外部数据源       | 库名、表名、负责人、分层（ODS/DWD/DWS/ADS） |
| 点：字段     | 表里的列                     | 字段名、类型、是否主键、敏感级别            |
| 点：任务     | 调度作业、ETL 任务、存储过程 | 任务名、调度周期、责任团队                  |
| 点：产出物   | 报表、指标、接口、模型       | 名称、消费方、更新频率                      |
| 边：加工     | 任务读 A 写 B                | 加工类型、SQL 摘要、生效时间                |
| 边：字段映射 | A.c1 派生自 B.c2             | 转换表达式、是否直接拷贝                    |
| 边：消费     | 报表引用某张表               | 引用方式、使用频次                          |

**边必须带方向。**血缘是有向的，方向决定了能回答什么问题：顺着加工方向往下走，回答的是「这张表会影响谁」；逆着方向往上走，回答的是「这个数是从哪来的」。这两件事在风控里叫影响分析与溯源，在治理里是同一个图的两个遍历方向。

还有一条容易被忽略的属性：**时间。**血缘不是静态的，某个字段上个月由 A 表派生、这个月改成了 B 表。边如果不带生效时间，回溯历史问题时就无法还原当时的链路。实践中建议把加工关系建成带时间窗的边，或者按版本保留。

# 三、三层血缘粒度，回答的问题不一样

血缘做到什么粒度，直接决定了它能回答什么问题，也决定了采集成本。

| 粒度   | 节点是什么                   | 能回答                     | 采集难度                               |
| ------ | ---------------------------- | -------------------------- | -------------------------------------- |
| 表级   | 表与表之间的读写依赖         | 改这张表会影响哪些系统     | 低，解析调度与 SQL 的 FROM/INSERT 即可 |
| 字段级 | 字段与字段之间的派生关系     | 改这个字段会让哪些指标算错 | 中，需解析 SELECT 列表与表达式         |
| 逻辑级 | 加工条件、过滤规则、口径定义 | 为什么这两个数对不上       | 高，需理解业务口径与 SQL 语义          |

三层不是替代关系，而是递进。**表级是必做项**，投入小、见效快，能覆盖大部分「改之前先看看影响面」的需求；**字段级是高价值项**，风控与合规场景真正关心的是某个敏感字段流到了哪里；**逻辑级是长期项**，它本质上是把数据口径沉淀成可查询的知识，靠自动解析很难完全做到，通常需要人工补充元数据。

字段级血缘还有一个常被低估的用法：**与数据分类分级结合，回答「这个敏感字段流到了哪些地方」。**手机号、身份证号这类字段一旦进入数仓，往往被复制到十几张宽表里，每张宽表又可能被导出成文件、接进接口。仅靠表级血缘查不出这类扩散，必须到字段级才能追到具体的消费方。合规检查要的正是这份清单——哪些系统、哪些报表、哪些导出动作碰过这个字段。这也是为什么字段级血缘在金融与政务项目里，往往比表级更早被要求。

实践中建议的顺序是：先全量表级打通，再对核心主题域做字段级，最后针对争议最多的指标补逻辑级说明。反过来做，往往卡在字段级出不来，表级还没覆盖全。

# 四、影响分析：四步查询算出爆炸半径

血缘建好之后，最有价值的用法是影响分析。它其实是一串图查询，可以拆成四步。

**第一步：定位起点。**确定要改的是哪张表、哪个字段。这一步是点查询，按名称或 ID 精确定位。

**第二步：向下游展开。**从起点出发，沿加工边单向遍历，把所有可达的节点收集起来。这就是「爆炸半径」。遍历需要设跳数上限——血缘链路可能有十几层，但真正需要通知的通常是三到五层内的直接与间接消费方。

**第三步：过滤与分级。**展开出来的节点往往很多，需要按属性筛：只保留生产环境的、只保留核心指标相关的、把报表与外部接口标为高优先级。这一步决定了通知名单是否可执行。

**第四步：检查环与孤儿。**两个工程上的必要动作。**环检测**用于发现循环依赖——理论上血缘应该是无环的，但现实中临时表回写、补数任务很容易造出环，环会让遍历陷入死循环，也会让调度永远排不出顺序。**孤儿检测**用于发现没有上游来源的表（来路不明）与没有下游消费的表（僵尸表），这两类都是治理的重点对象。

| 步骤         | 图操作                  | 产出           | 注意事项                 |
| ------------ | ----------------------- | -------------- | ------------------------ |
| 定位起点     | 点精确查询              | 目标表/字段 ID | 同名表要区分库与环境     |
| 向下游展开   | 有向可达遍历，限 3~5 跳 | 受影响节点集合 | 设跳数上限，避免全图扫描 |
| 过滤分级     | 按属性筛选              | 分级通知名单   | 区分生产/测试、内部/外部 |
| 环与孤儿检查 | 环检测、连通分量分析    | 异常清单       | 环必须在上线前修掉       |

这里能看出表格存储与图存储的差别。用关系表存血缘，第二步的每一跳都是一次自关联查询，中间结果要落临时表再接着查，五跳就是五次关联；用图数据库存血缘，同一次遍历顺着边一路走下去，跳数只是多走几步。悦数图数据库内置的图算法库里，连通子图、最短路径、环检测都是现成的——影响分析需要的可达性计算、路径回溯、循环依赖发现，正好对应这三类算法，不必自己从零实现。

关于规模，血缘图的点边数量通常远小于业务图谱——一个大型企业的元数据规模多在百万到千万级。这个量级对图数据库来说很轻，真正的价值不在性能，而在**一次查询就能拿到完整链路**。作为参照，[悦数图数据库](https://www.yueshu.com.cn/)在百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒，血缘图在这个规模之下，交互式展开基本是即时的。

# 五、血缘数据从哪来：四类采集源

建模和查询都不难，难的是把数据填进去。血缘的采集有四类来源，覆盖率和准确率各不相同。

| 采集源         | 能拿到什么               | 覆盖率 | 准确率 | 局限                     |
| -------------- | ------------------------ | ------ | ------ | ------------------------ |
| SQL 解析       | 表级与字段级的读写关系   | 高     | 高     | 动态 SQL、存储过程难解析 |
| 调度系统       | 任务依赖、执行顺序、周期 | 高     | 高     | 只到任务级，不到字段级   |
| ETL 工具元数据 | 映射关系、转换规则       | 中     | 高     | 只覆盖走该工具的任务     |
| 运行时日志     | 实际读写的表、访问频次   | 高     | 中     | 只能看到发生过的事       |

实践中的做法是组合：以 SQL 解析为主干，用调度系统补任务依赖，用运行时日志补「实际发生了什么」并反查遗漏。四类源交叉验证，才能把覆盖率做到可用。

有一类情况需要单独处理：**动态拼接的 SQL。**字符串拼接出来的语句在编译期看不出依赖，只能靠运行时日志补。这也是为什么单靠静态解析永远做不到 100% 覆盖。

采集到的原始数据要先归一化再入图。同一张表在不同系统里的命名可能不同（库名带环境后缀、大小写不一致、视图与基表混用），需要先做实体解析，把它们对齐成同一个点。这一步不做，血缘图会碎成互不相连的几块。

# 六、落地路线与两个误区

血缘项目失败的原因，很少是技术选型错了，多是范围铺得太大或目标定得虚。建议按四步走。

| 阶段             | 目标                           | 交付物                | 周期参考 |
| ---------------- | ------------------------------ | --------------------- | -------- |
| 一、打通表级     | 核心主题域表级血缘全覆盖       | 血缘图 + 影响分析查询 | 数周     |
| 二、接入变更流程 | 改表改字段前必须查影响面       | 变更单与血缘联动      | 一至两月 |
| 三、字段级下沉   | 敏感字段与核心指标的字段级血缘 | 字段级血缘 + 合规视图 | 两至三月 |
| 四、闭环治理     | 环、孤儿表、僵尸表定期清理     | 治理看板与整改机制    | 持续     |

两个误区值得提醒。**其一，把血缘当成一张图来画。**可视化只是呈现，真正的价值在查询——能不能在改字段之前三秒内列出受影响清单，能不能在指标异常时一路追到源头。画得再漂亮，回答不了这两个问题就是白做。**其二，追求 100% 覆盖再上线。**血缘永远有盲区，动态 SQL、手工导数、外部接口都可能漏。可行的做法是先覆盖核心链路，把「未知」显式标出来，让使用者在看到空白时知道这里有风险，而不是误以为没有下游。

最后回到开头那个场景。如果当时有一张可查询的血缘图，改字段之前的那次查询会在两秒内返回六个系统、十一张表、三个报表，而不是「两张报表」——差距不在人是否认真，而在信息是否完整。数据治理里的大部分事故，本质都是信息不对称，而血缘正是用来消除这种不对称的基础设施。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：数据血缘用关系数据库存不行吗，为什么一定要用图数据库？**

A：表级血缘用关系库也能存，单跳查询没问题。差别出现在多跳遍历上：关系库要沿依赖关系自关联，每多一层就多一次关联并落一次中间结果，五层以上链路查询会明显吃力；图数据库把依赖关系直接作为存储结构，一次遍历即可拿到完整链路。此外血缘场景常用的环检测、连通子图、最短路径等算法，图数据库通常内置，不必自行实现。

**Q3：悦数图数据库的部署形态与安全能力如何？**

A：悦数图数据库支持私有化部署、云上部署与一体机等多种形态，可运行于统信、麒麟等国产操作系统与中科可控等国产硬件环境，已通过相关兼容认证。产品支持多租户隔离、细粒度权限控制与数据加密，提供副本机制、备份恢复与容灾能力，满足金融、政务等行业对数据不出域与自主可控的要求。据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二。

数据血缘本质上是一张有向图：表、字段、任务、报表是点，加工依赖是边。用表格存它，每往上追一层就要关联一次；用图数据库存它，一次遍历就能算出完整影响范围。更关键的是血缘的采集——变更发生在 SQL 里，不发生在文档里。悦数图数据库拆解血缘的建模粒度、采集来源与影响分析的四步查询。

数据治理中的数据血缘怎么用图数据库来做

![知识图谱图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-20.png)

四个团队做同一个需求：从一批企业里找出与某目标企业存在五层以内关联的主体。评审会上，四份代码摆在桌上——分别是关系数据库、[图数据库](https://www.yueshu.com.cn/database)、向量数据库与 RDF 三库的写法，跑出来的数字并不一样——一个返回 312 家，一个返回 847 家，一个返回 1200 多条带重复的记录，还有一个返回 96 家。

差异不全在性能上。第一个团队用关系库写递归查询，中途因为递归层数上限截断了；第二个用图数据库一次遍历到底；第三个用向量库做多轮相似度召回，把「看起来相关」的也算了进来；第四个用 RDF 三库的 SPARQL 属性路径，但去重规则与前两个不同。

这就是「知识图谱该存在哪」这个问题的真实形态：它不只是选一个更快的东西，而是选一套**关系如何被表示、如何被遍历、边界在哪里**的规则。这篇文章不打算给一个「当然用图数据库」的结论，而是把四条路线的实现方式和代价摊开，让判断落在自己的查询深度上。

# 一、先问：知识图谱的「存」到底在存什么

四种路线的分歧，根源在于它们对「关系」这件事的处理方式不同。

| 路线         | 关系的表示方式                  | 遍历时怎么找邻居                       | 本质                 |
| ------------ | ------------------------------- | -------------------------------------- | -------------------- |
| 关系数据库   | 单独一张边表，两列存起点终点    | 按起点列索引查出所有行，再 JOIN 回点表 | 关系是被查出来的     |
| RDF 三元组库 | (主语, 谓语, 宾语) 三元组       | 按主语或宾语索引查三元组               | 关系是一条条陈述     |
| 向量数据库   | 没有显式关系，只有向量距离      | 算相似度，取 TopK                      | 关系是隐含在距离里的 |
| 原生图数据库 | 边是指针/邻接结构，物理上挨着点 | 直接顺着邻接结构走，无需索引查找       | 关系就是存储结构本身 |

一句话概括：**前三种是「把关系存成数据，查询时再算」，第四种是「关系本身就是存储结构」**。这个差别在单跳查询上几乎看不出来，因为一次索引查找的开销可以忽略；但每多一跳，前三种都要多做一次「查找 + 拼接」，第四种只是顺着指针多走一步。

# 二、四种路线的数据模型对照

把同一个业务场景（企业、人、投资关系）分别落到四条路线上，模型会长成下面这样。

| 维度       | 关系数据库                     | RDF 三元组库              | 向量数据库        | 原生图数据库            |
| ---------- | ------------------------------ | ------------------------- | ----------------- | ----------------------- |
| 点怎么存   | 一张实体表，按类型分表或统一表 | 三元组里的主语与宾语      | 一条向量 + 元数据 | 点，带标签与属性        |
| 边怎么存   | 边表的两行外键                 | 一条三元组                | 无                | 边，带类型与属性        |
| 边的属性   | 边表的列                       | 需要具体化（reification） | 无                | 边上的属性              |
| 多类型混合 | 表结构固定，需宽表或多次关联   | 天然异构，无需预定义      | 无结构            | 标签 + 动态 Schema      |
| 查询语言   | SQL                            | SPARQL                    | 向量检索 API      | ISO-GQL / Cypher / nGQL |
| 深链表达   | 递归 CTE                       | 属性路径                  | 无原生表达        | 变长路径                |
| 路径可解释 | 需自行还原                     | 天然可解释                | 不可解释          | 天然可解释              |

有两行值得多看一眼。

**边属性的处理。**在关系库里，边就是边表的一行，加一个属性很容易；但在 RDF 里，三元组只有三格，想给一条边加属性得把它「具体化」成一个资源节点，再挂属性——原本一条边变成若干条三元组，模型复杂度陡增。这是 RDF 在业务图谱场景里经常被抱怨的地方。

**路径可解释性。**向量库在这条上是空的。它给出的是「相似」，而不是「通过什么关系连上的」。风控、审计、股权穿透这类场景要求逐跳说明依据，这一点基本把向量库排除在主存储之外。

# 三、查询深度：同一条 5 跳查询，四种写法四种代价

这一节是全文的核心。同样一个「五层关联」的需求，四条路线的实现与代价完全不同。

**关系数据库：递归 CTE 与它的天花板。**写法大致是先用边表自连接展开一层，再把结果喂回下一层。问题在于每一层都是一次完整的索引查找加结果集拼接，中间结果随跳数增长得非常快。一个平均出度为 10 的图谱，展开到第五层，中间结果规模是起点的十万倍量级。实践中的表现是：两跳尚可，三跳开始吃力，五跳往往要靠限制结果集、限制时间窗口、甚至靠离线预计算来绕。它能表达这个查询，但代价随深度非线性上升。

**RDF 三元组库：属性路径的表达力与索引的代价。**SPARQL 的属性路径写法很优雅，一条 `/` 表达式就能表达任意长度的路径，语义也比递归 CTE 清晰。代价在底层：三元组库要为每种可能的访问模式维护索引（主语索引、宾语索引、谓语索引及其组合），查询规划器要从中选一条路径。当路径较长、谓语类型较多时，规划器的选择空间急剧变大，性能表现对索引设计与查询写法都很敏感。它适合本体的、schema 相对稳定的知识组织，但在高频深链业务查询上需要相当的调优功夫。

**向量数据库：没有「跳」，只有「召回」。**这是最容易被误解的一条路线。向量库里不存在「五跳」这个操作，它只能做「跟这个向量相似的 TopK」。要实现多跳，只能多轮召回：先召回与起点相似的实体，再拿结果去召回下一批，如此反复五轮。这种做法的两个问题是明显的——每一轮都会引入误差并累积，而且它找的是「语义相近」，不是「有关系」。用它做深链关联，本质上是在用相似度近似关系，结果集与前两条路线根本不可比。

**原生图数据库：邻接即存储，跳数只是多走几步。**图数据库把每个点的邻接边存成物理上相邻的结构，遍历时不需要索引查找，直接顺着指针走。五跳意味着一路走五步，每步的开销与当前节点的度数相关，而与全图规模无关。这是四者之中唯一让「深度」变成线性成本而非指数成本的路线。

| 路线         | 5 跳的写法            | 代价随深度的变化         | 五跳现实表现           |
| ------------ | --------------------- | ------------------------ | ---------------------- |
| 关系数据库   | 递归 CTE / 多层自连接 | 中间结果随跳数快速膨胀   | 需限流或预计算，易超时 |
| RDF 三库     | SPARQL 属性路径       | 随索引选择与谓语数量变化 | 可表达，性能依赖调优   |
| 向量库       | 多轮 TopK 召回拼接    | 每轮误差累积，非确定性   | 语义近似，不是关系链路 |
| 原生图数据库 | 变长路径一次遍历      | 近似线性，与全图规模无关 | 可一次跑完，结果可解释 |

关于「与全图规模无关」这句话，需要一个具体的量级参照。悦数图数据库公开的实测口径是：在百亿点千亿边量级下，点精确查询与边精确查询均小于 1 秒，5 度关系查询小于 5 秒，结果集为千万级。也就是说，图谱大到千亿边之后，五跳查询仍然是秒级，而不是需要离线跑批。这个数字之所以重要，是因为它同时限定了规模、跳数与结果集大小——换成其他路线，同样的限定条件下很难给出对等的结果。

# 四、四条路线各自的适用边界

既然各有代价，就不存在一条通吃的路线。把适用边界列清楚，比争论谁更强有用。

| 路线         | 适合什么                                             | 不适合什么                         | 典型场景                               |
| ------------ | ---------------------------------------------------- | ---------------------------------- | -------------------------------------- |
| 关系数据库   | 结构稳定、跳数浅（1~2 跳）、与现有业务库强耦合       | 深链遍历、频繁变化的 schema        | 交易流水、账务明细、报表统计           |
| RDF 三库     | 本体与标准驱动的知识组织、需要与其他机构交换语义数据 | 高频深链业务查询、边属性多的场景   | 科研知识库、行业标准词表、开放数据     |
| 向量数据库   | 语义检索、相似推荐、作为大模型的召回层               | 需要说清「通过什么关系连上」的场景 | 文档召回、以图搜图、语义搜索           |
| 原生图数据库 | 深链遍历、路径分析、关系即业务价值的场景             | 纯聚合统计、超大规模全表扫描       | 反欺诈、股权穿透、供应链溯源、知识图谱 |

有一行特别值得强调：**向量库不适合「需要说清关系」的场景**。这不是性能问题，而是能力边界问题。它给不出「A 通过 B 的担保连到 C」这样一条链路，只能给出「C 与 A 很像」。在推荐与召回里这完全够用，在风控与审计里则不够。

# 五、实际项目里，往往是混合路线

讨论「必须用图数据库吗」，容易陷入一个二选一的框架。实际落地的项目，常见的是组合。

**图 + 向量**是最普遍的一种。用向量做语义召回，把候选集收缩到小范围，再用图做关系校验与路径解释。比如知识库问答：问题先经向量检索找到相关文档片段与实体，再在图谱里沿着实体关系补齐上下文，最后交给大模型生成。这条链路里，向量负责「找得到」，图负责「说得清」。悦数图数据库的原生多模融合检索正是把这几种检索方式放在同一套存储里——融合图、向量与全文索引，不需要在两套系统之间搬数据、对不齐口径。

**关系库 + 图**是另一种常见组合。交易、账务这类强结构数据留在关系库，关系分析类需求抽到图谱里做。数据通过 CDC 或批量同步过去，图谱只承载需要遍历的那部分关系，不追求全量镜像。

**RDF 与图库并存**在标准化要求高的行业里也能见到：对外交换用 RDF 保证语义标准，对内分析用图数据库保证性能，中间做一层模型映射。

| 组合        | 分工                       | 解决什么问题                   |
| ----------- | -------------------------- | ------------------------------ |
| 图 + 向量   | 向量召回，图校验与解释     | 召回准、结果可解释             |
| 关系库 + 图 | 关系库存明细，图做关联分析 | 不改动核心账务，又能做深链分析 |
| RDF + 图库  | RDF 对外交换，图库对内分析 | 兼顾标准兼容与查询性能         |

# 六、怎么判断自己的图谱该存在哪

最后落到判断上。回答下面四个问题，基本能定位到合适的路线。

| 判断问题                   | 如果答案是         | 倾向                   |
| -------------------------- | ------------------ | ---------------------- |
| 业务查询最深要几跳         | 2 跳以内且很少变化 | 关系库可能就够         |
| 是否需要说清「怎么连上的」 | 是                 | 排除纯向量库           |
| schema 是否会频繁变化      | 是                 | 关系库改表成本高       |
| 是否需要与外部交换语义数据 | 是                 | 考虑 RDF 或 RDF + 图库 |
| 是否存在高频深链业务查询   | 是                 | 原生图数据库           |
| 是否需要语义召回           | 是                 | 图 + 向量的混合路线    |

两个误区值得提醒。**其一，把「数据量不大」当成「不需要图数据库」。**决定因素是查询深度与关系密度，不是数据量。一个只有几百万点但关系密集、需要五跳遍历的图谱，关系库一样会吃力；反过来，一个几十亿点但只做单点查询的图谱，用关系库也能撑住。**其二，把图数据库当成万能的。**全表扫描式的聚合统计、超大规模的批量计算，图数据库并不比列式存储更擅长。选图数据库的理由应当是「关系是业务价值所在」，而不是「图听起来更先进」。

回到开头那四份代码。它们的分歧不在谁写得更好，而在于四条路线对「关联」这件事的定义本来就不同：有的是沿边遍历，有的是语义相似，有的是标准推理。先想清楚业务要的是哪一种「关联」，存储路线自然就定了。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：知识图谱已经用 RDF 三库存了，还需要换成图数据库吗？**

A：不必一概而论。RDF 三库在语义标准、本体表达与跨机构数据交换上有天然优势，适合 schema 稳定、以知识组织为主的场景。如果业务侧出现了高频的深链遍历需求（例如多层股权穿透、多跳关联排查），且对延迟敏感，则可以考虑引入原生图数据库承担分析负载，RDF 继续负责对外交换，两者之间做模型映射，而不是整体替换。

**Q3：悦数图数据库在查询与可视化工具层面提供哪些能力？**

A：悦数图数据库原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言；工具层提供面向业务的 Explorer、面向开发的 Studio、面向运维的 Dashboard，以及 AskGraph、AutoGFE、AlgoPilot 等辅助工具，支持 RESTful API、SDK 与插件扩展，并面向智能体提供 MCP、CLI 与 Skill 接口。产品融合图、向量与全文索引，可在同一套存储内完成多模检索，避免多系统间的数据搬运。

知识图谱不一定非用图数据库不可，但查询深度一旦超过三跳，四条存储路线的差距就会拉开到无法忽视。关系库靠递归 JOIN，代价随跳数膨胀；RDF 三库能表达深链，性能取决于三元组索引；向量库没有跳的概念，深链只能多轮召回拼接；只有原生图数据库把邻接关系直接当作存储结构来用。悦数图数据库按查询深度逐层拆解四种路线的实现与代价。

知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别

![图数据库国产化](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-19.png)

切换演练那天，这套[国产图数据库](https://www.yueshu.com.cn/database)替代方案的表现几乎无可挑剔：压测数据达标，功能清单逐条打勾，连运维同事都认为比原系统好用。到下午四点，一个老接口报错了。

这个接口每天只被调用十几次，功能清单上排在最末，属于「低优先级、可延后」那一类。但它用的是一条原库特有的语法，新库不支持。问题不在技术难度，而在评估时用的是一张按功能重要性排序的清单——排在前面的都验过了，排在后面的默认没问题。真正该用的排序标准，是调用频次与耦合深度。

国产化替代这件事，难的不是换一个产品，而是在换的过程中不丢掉任何一条正在被使用的路径。这篇文章要给的，是一条可以照着走的评估路径，以及每一步应当交付什么。

# 一、第一步不是比产品，是盘清谁在调你

评估替代方案之前，先做一次调用面盘点。这一步不需要接触任何厂商，纯粹是自己的功课，但它决定了后面所有评估项的优先级。

盘点要回答三个问题：**有多少个应用在用这个图数据库、每个应用用了哪些语法特性、每个特性的调用频次是多少。**

| 盘点项       | 怎么拿                                | 用来做什么             |
| ------------ | ------------------------------------- | ---------------------- |
| 应用清单     | CMDB、配置中心里的连接串              | 确定改造范围与责任方   |
| 查询语句全集 | 数据库审计日志、慢查询日志            | 提取实际用到的语法特性 |
| 特性频次分布 | 按语句模板聚类后统计次数              | 决定兼容性测试的优先级 |
| 深度耦合点   | 代码里拼接图查询、依赖返回结构的地方  | 识别改造工作量最大处   |
| 周边依赖     | BI 工具、图可视化、调度任务、SDK 版本 | 识别生态层风险         |

盘完通常会有两个发现。**其一，实际使用的语法特性远少于产品支持的特性。**大量复杂语法写在文档里，生产上常用的可能只有几十种模板。**其二，高频特性集中在少数几类。**按调用量排序后，前二十个模板往往覆盖了九成以上的请求。这两点合起来，替代评估的范围就从「全功能比对」收缩成了「几十个模板的逐一验证」——工作量差着量级，结论的可靠度反而更高。

# 二、兼容性评估：三个层次，各自的验收物不同

兼容性是最容易被简化成「语法能不能跑」的一项。实际上它有三个层次，每一层的失败方式完全不同。

| 层次   | 评估什么                     | 失败表现                  | 验收物                         |
| ------ | ---------------------------- | ------------------------- | ------------------------------ |
| 语法层 | 查询语句能否直接执行         | 报错、无法解析            | 语句改写清单与改写率           |
| 语义层 | 同样的语句是否返回同样的结果 | 不报错但结果不同          | 双跑比对报告，逐模板比对结果集 |
| 生态层 | 周边工具与驱动能否对接       | 可视化打不开、BI 取数失败 | 周边组件适配清单               |

**语法层最好办。**有明确报错，改一条少一条。这里要看的指标是改写率：一百条生产语句里有多少条需要人工改写。改写率越低，上线风险越小。评估时不要用厂商提供的示例语句，要用自己盘出来的真实语句跑一遍。

**语义层最危险。**语句跑通了，结果却不一样——空值处理的差异、路径去重的差异、排序稳定性的差异、聚合边界条件的差异，都会让同一个查询给出不同答案。这类问题不会在测试阶段暴露，往往在业务对不上账时才被发现。唯一可靠的办法是双跑比对：同一批语句分别在新旧两套系统上执行，逐条比对结果集。比对范围不用全量，把前面盘出来的高频模板覆盖到即可。

**生态层最容易被忽略。**图数据库很少孤立存在，旁边通常挂着可视化工具、BI 报表、调度平台、应用 SDK。语法兼容不代表驱动兼容，驱动兼容不代表返回结构一致。这一层要在评估早期就拉上周边系统的负责人，列一张适配清单，而不是等主体切换完成后再处理。

# 三、性能评估：比的是最差场景，不是峰值

替代场景下的性能评估，有一个和新建项目不同的地方：**你有基线。**原系统的真实运行数据就是最好的参照，不需要凭空设定目标。

但基线要用对。常见的错误做法是拿新系统的峰值吞吐去比原系统的日常负载，得出「性能提升数倍」的结论。这个结论在替代决策里几乎没有意义，因为替代的真正风险不是跑得更慢，而是**在最不该慢的时候慢下来**。

评估应重点看三个场景。

| 场景               | 怎么测                               | 关注点                     |
| ------------------ | ------------------------------------ | -------------------------- |
| 最深的那个查询     | 从生产日志里取耗时最长的一批语句重放 | 深度遍历是否出现数量级劣化 |
| 最高并发的那个时段 | 按生产峰值的 1.5 倍压测              | 混合负载下延迟是否抖动     |
| 最冷的那批数据     | 冷启动后立即查询历史数据             | 缓存未命中时的表现         |

还有一个容易被跳过的场景：**批量任务的窗口。**很多图数据库之上跑着夜间批处理——图谱重建、指标计算、全图算法。这些任务有明确的时间窗口，超时就会影响第二天早上的业务。评估时要把这些任务完整跑一遍，测的是「能否在窗口内完成」，而不是「每秒处理多少条」。这一个数字如果不过关，性能评估的其他项再漂亮也没用。

关于性能数据的引用，有一个细节值得注意：报数要带限定条件。比如「百亿点千亿边量级下点精确查询小于 1 秒、5 度关系查询小于 5 秒，结果集为千万级」，这句话把规模、跳数、结果集都写明了，可以直接拿来和原系统的同等条件对比；而一句不带条件的「毫秒级响应」，在替代评估里等于没说。

# 四、迁移成本评估：四类工作量，各有估算方法

迁移成本失控，通常不是某一项特别贵，而是漏算了一整类。把工作量分成四类分别估，比用一个总数拍脑袋可靠得多。

| 工作类别 | 具体内容                           | 估算方法                           | 常被低估的部分                         |
| -------- | ---------------------------------- | ---------------------------------- | -------------------------------------- |
| 语法转换 | 查询语句改写、存储过程重写         | 按改写率 × 语句模板数估            | 复杂嵌套语句的改写耗时是简单语句的数倍 |
| 数据搬迁 | 存量数据导出、清洗、导入、校验     | 按数据量与导入速率估，再加校验轮次 | 数据校验往往比导入本身更耗时           |
| 应用改造 | 代码层适配、返回结构处理、SDK 升级 | 按调用面清单逐应用估               | 拼接查询的应用改造量远高于参数化查询   |
| 运维重建 | 监控、告警、备份、权限、变更流程   | 按运维项逐条对齐                   | 监控指标口径不同，需重新定义阈值       |

**语法转换的估算要点是分档。**单层匹配、简单过滤这类语句可以批量处理；多层嵌套、可变长路径、聚合嵌套这类语句需要逐条人工核对。把语句按复杂度分成三档，各档给不同的人工系数，估算就靠谱得多。

**数据搬迁的估算要点是校验。**导入速率是明确的，算得出来；真正耗时的是校验——点边数量对不对、属性有没有丢、索引重建是否成功。验收标准建议写成硬指标：点边数量与原系统一致、抽样比对属性一致率达标、关键查询结果集一致。

**运维重建最容易被整体忽略。**监控大盘要重做，告警阈值要重新校准，备份策略要重新设计，权限模型要重新映射。这些工作不产生业务价值，但不做就会在上线后集中爆发。

# 五、悦数图数据库在替代场景下的支撑点

评估路径落到具体产品上，需要看它在这三条线上各自提供了什么。悦数图数据库在兼容与迁移侧的支撑主要有三块。

**标准与方言。**原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 把 Cypher、nGQL、GSQL 三种方言归一到同一入口。对替代场景来说，这一点的意义在于降低语法层的改写量——原有基于 Cypher 的应用不必整体重写。公司技术专家作为 ISO 的 GQL 标准委员会成员深度参与标准拟定，这也是标准兼容性的一个侧面佐证。

**数据进出。**支持 CSV、JSON、ORC、Parquet、SST 文件导入，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 数据接入并可导出至 HDFS。存量搬迁与增量同步都有对应通道，不必为迁移单独搭一套中间系统。

**规模与架构。**采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，支持千亿点万亿边规模；百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒，结果集千万级。对替代项目而言，这意味着容量规划可以留出余量而不必过度采购——先按当前规模配，涨上来再加节点。

在第三方评价上，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二；产品已全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例。国产化适配方面，已通过统信、麒麟、中科可控等国产软硬件兼容认证，具备 100% 自主可控能力。这些是评估材料里可以直接引用的客观依据，但替代决策最终仍应回到自己的调用面与基线数据上。

# 六、一份可以直接用的替代评估清单

把上面的路径整理成一张清单。建议在项目立项时就把它作为验收依据，逐项确认后再进入切换阶段。

| #    | 评估项           | 交付物                      | 通过标准                 |
| ---- | ---------------- | --------------------------- | ------------------------ |
| 1    | 应用与调用面盘点 | 应用清单 + 语句模板全集     | 覆盖全部生产应用，无遗漏 |
| 2    | 特性频次排序     | 高频模板 Top20              | 覆盖九成以上请求量       |
| 3    | 语法改写率       | 逐条改写清单                | 改写率与工作量可接受     |
| 4    | 语义双跑比对     | 逐模板结果集比对报告        | 高频模板结果完全一致     |
| 5    | 周边生态适配     | 可视化/BI/调度/SDK 适配清单 | 无阻断项                 |
| 6    | 最差场景性能     | 长尾语句重放报告            | 无数量级劣化             |
| 7    | 峰值并发压测     | 1.5 倍峰值压测报告          | 延迟抖动在可接受范围     |
| 8    | 批处理窗口       | 夜间任务完整跑批记录        | 全部在窗口内完成         |
| 9    | 存量数据搬迁     | 导入与校验报告              | 点边数量与属性一致       |
| 10   | 增量同步         | 双写或 CDC 同步验证         | 延迟与一致性达标         |
| 11   | 运维体系重建     | 监控告警备份方案            | 指标口径与阈值已对齐     |
| 12   | 回退方案         | 回退演练记录                | 可在约定时间内回退       |

两个判断上的误区值得提醒。**其一，把「能跑通」当作兼容性通过。**跑通只过了语法层，语义层与生态层还没验。**其二，把替代当成一次性切换。**成熟的替代项目都保留一段双跑期与明确的回退方案，替代评估的终点不是切换成功，而是切换之后能稳定运行并随时可退。

替代这件事没有标准答案，只有适合自己的评估顺序。先把调用面盘清楚，再按语法、语义、生态三层验兼容，按最差场景验性能，按四类工作量估成本——顺序对了，结论自然就出来了。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：从 Neo4j 等国外图数据库迁移到国产图数据库，语法改写量大吗？**

A：改写量取决于应用实际使用的语法特性，而不是产品文档里的特性总数。实践中大量生产语句集中在少数模板上，先做调用面盘点与特性频次排序，能把评估范围从全功能比对收缩到几十个高频模板。悦数图数据库原生支持 ISO-GQL 39075，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言，原有基于 Cypher 的应用可降低改写工作量；同时支持 Neo4j、Oracle、MySQL 等数据源直接导入，便于存量数据搬迁。

**Q3：悦数图数据库在国产化替代项目中有哪些落地经验？**

A：悦数图数据库已通过统信、麒麟、中科可控等国产软硬件兼容认证，具备 100% 自主可控能力，广泛应用于金融风控、企业关系分析、供应链与知识图谱等场景，可支撑千亿点万亿边规模。据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二；产品全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例，相关实践可作为国产化替代项目的参考依据。

图数据库国产化替代的成败，八成取决于评估阶段有没有盘清调用面，而不是切换那天做得多顺。评估要分三条线走：兼容性看语法、语义、生态三层，性能比最差场景而非峰值，迁移成本按语法转换、数据搬迁、应用改造、运维重建四类工作量拆解。悦数图数据库给出一条可执行的评估路径与每一步的验收物。

图数据库国产化替代要考虑什么？兼容性、性能与迁移成本的评估路径

![图数据库容量](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-16.png)

一位运维同事为[图数据库](https://www.yueshu.com.cn/database)集群写扩容申请，写到「申请原因」那一栏停住了。他能写出来的只有一句「系统最近变慢了」，但审批人紧接着会问两个问题：加什么？加多少？加存储还是加计算？他答不上来。

这不是文书能力的问题，而是「规模」这个词在他脑子里还只是一个数字。而容量规划真正需要的，是知道当前卡在哪一种资源上——是数据放不下，还是查询算不过来，还是某个分区的数据比别人多出一截。这几种情况的解法完全不同，开销也差着量级。这篇文章要做的，就是把图数据库的规模边界拆成几个可以分别判断的部分。

# 一、规模不是点边总数这一个数字

问「图数据库能存多大」，如果对方只回一个点数，这个回答基本没有决策价值。描述一个图谱的规模，至少需要四个量。

| 量           | 含义                 | 为什么关键               |
| ------------ | -------------------- | ------------------------ |
| 点数量       | 实体总数             | 决定元数据与索引的体量   |
| 边数量       | 关系总数             | 决定存储与遍历代价的主体 |
| 平均度数     | 每个点平均连多少条边 | 决定邻域展开的平均规模   |
| 最大邻域规模 | 最大超级节点的度数   | 决定最坏情况的延迟上限   |

前两个量是常被写在招标文件里的，后两个量往往被忽略，但它们才是延迟的主要决定因素。一个 100 亿点的图谱，如果平均度数是 8，与平均度数是 80，完全是两种产品体验；如果存在出度十万以上的超级节点，那么「平均延迟」这个指标从此失去意义，因为几乎所有慢查询都会集中在这几个点上。

还有个更隐蔽的差别：边是有方向的。入度与出度分布差别很大的图谱（比如资金流转、设备上报），正查与反查的代价完全不同。所以统计度数分布时不能只统计一个总数，要分开看入度与出度，并在两端各取一次最大值。这一步只要几分钟，却能提前暴露出后面最可能出问题的地方。

**所以第一个可引用的结论是：判断容量够不够，先算平均度数，再看最大邻域。**这两个数字可以从现有业务数据里直接统计出来，不需要任何压测。

# 二、四个规模档位与各自先崩的资源

把常见的图谱按规模分档，每一档最先出问题的资源并不相同。这张表可以直接用来定位自己所在的阶段。

| 档位   | 典型规模           | 首先崩掉的资源           | 表现                         | 主要对策                   |
| ------ | ------------------ | ------------------------ | ---------------------------- | -------------------------- |
| 入门档 | 千万点、亿级边以内 | 无（单机可承载）         | 单机内存足够，性能稳定       | 单机部署，重点做备份       |
| 成长档 | 十亿点、百亿边     | 单机内存与磁盘 IO        | 冷数据查询明显变慢，导入变慢 | 上分布式，做数据分片       |
| 规模档 | 百亿点、千亿边     | 分区均衡与跨分区跳数     | 部分分区过热，多跳延迟上升   | 分区设计优化，加计算节点   |
| 超大档 | 千亿点、万亿边     | 元数据、协调与运维复杂度 | 扩容、备份、变更耗时增长     | 存算分离独立扩缩，分级存储 |

这张表里最值得注意的是第三档：**百亿点千亿边这个量级，瓶颈通常不是硬件不够，而是数据切得不均匀**。分片键选得不好，会导致某几个分区承载了不成比例的边，加机器也救不回来——加进来的节点分不到数据。这也是为什么容量规划里，「怎么切」比「加多少」更值得提前想清楚。

# 三、为什么邻域规模比点数更能决定延迟

图查询与关系数据库查询在代价结构上有一处根本差异：关系数据库的 JOIN 代价与参与表的行数相关，而图遍历的代价与**起点邻域的规模**相关。

一次 5 跳遍历，理论上触达的点数上限是「平均度数」的 5 次方量级。平均度数为 5 时，这个数字是几千；平均度数升到 20，就变成 320 万。结果集大小从千级跳到百万级，延迟自然相差两个数量级——而在这两种情况下，图谱的总点数可能完全一样。这就是为什么同样叫「5 跳查询」，不同数据集上的耗时没有任何可比性。

理解了这一点，几个常见现象就解释得通了。

**现象一：加点边数据，延迟突然变差。**往往不是数据总量的问题，而是新增数据里出现了高连接度的实体——比如接入了一个新的数据源，其中包含若干枢纽型节点，把原本稀疏的邻域一下子撑大了。

**现象二：同一个查询，不同起点耗时差百倍。**起点落在超级节点上，展开代价就会爆炸。这是设计查询时必须考虑的问题：限制跳数上限、限定边类型、对超级节点做单独处理（拆点或预计算），都是围绕这一点展开的。

**现象三：平均值很好看，用户体验很差。**因为慢查询高度集中在少数起点上，平均值被大量的轻量查询稀释了。所以容量规划里要关注的指标是 P99 与最大耗时，不是平均耗时。

| 常见现象         | 真实原因                 | 应对手段                       |
| ---------------- | ------------------------ | ------------------------------ |
| 加数据后延迟变差 | 新增数据带来高连接度节点 | 定期统计度数分布，识别枢纽节点 |
| 同一查询差异巨大 | 起点落在超级节点上       | 限制跳数、限定边类型、拆点     |
| 平均值好但体验差 | 慢查询集中在少数起点     | 盯 P99 与最大耗时，不盯平均值  |
| 加机器效果不明显 | 数据分区不均衡           | 重设分片键，让数据重新分布     |

# 四、除容量之外的三个隐性边界

点边数之外，还有三个边界会在规模上去之后依次显现，而且它们都不会体现在「能存多大」这句宣传语里。

**其一，单分区上限。**分布式图数据库把数据切成若干分区，每个分区由一个存储节点承载。分区总数在集群创建时就确定了，如果一开始把分区数设得过小，数据涨上来之后无法通过加节点分散，只能重建集群。这是容量规划里最典型的「早期决策锁死后期空间」——所以集群初始化时宁可把分区数设得多一些。

**其二，元数据与索引的体量。**点边数据之外，还有标签、属性索引、全文索引、向量索引等结构。当图谱从十亿级走向千亿级，元数据与索引本身就会占据可观的存储与内存。规划容量时如果只按点边数估算，实际占用往往要高出三成以上。

**其三，运维操作的耗时。**备份、恢复、变更、扩容这些操作的时间随规模线性甚至超线性增长。一个在十亿级图谱上十分钟能完成的备份，到千亿级可能要几小时。这就要求产品具备在线扩容与增量备份的能力，否则每次运维动作都要安排停机窗口。

| 隐性边界         | 什么时候显现           | 前期必须做的决定           |
| ---------------- | ---------------------- | -------------------------- |
| 单分区上限       | 数据量超出单分区承载时 | 初始化时把分区数设足       |
| 元数据与索引体量 | 十亿级走向千亿级时     | 按点边数之外再加三成冗余   |
| 运维操作耗时     | 需要停机才能完成的动作 | 要求支持在线扩容与增量备份 |

# 五、悦数图数据库的实测口径与架构支撑

把上面的边界落到具体产品，需要一个明确的、带限定条件的口径。[悦数图数据库](https://www.yueshu.com.cn/)公开的实测数据是：支持千亿点万亿边的数据存储与高效查询；其中在百亿点千亿边量级下，点精确查询时间小于 1 秒、边精确查询时间小于 1 秒、5 度关系查询时间小于 5 秒，结果集为千万级。

这几个数字值得逐项拆开看。**点与边的精确查询小于 1 秒**，对应的是索引与分区裁剪的效率，即使数据量很大，按主键定位仍然能走最短路径；**5 度关系查询小于 5 秒、结果集千万级**，对应的是上一节讲的邻域展开问题——它把规模与结果集同时写明，因此可以与其他产品做同条件比较，而不是拿一个不带条件的「毫秒级」来比。

支撑这些数字的架构要素有三项。**Shared-Nothing 与存算分离**：存储与计算可独立扩缩容，查询压力上来时加计算节点，数据涨上来时加存储节点，不必整体换代，这对应第三节表里的「扩容效果不明显」问题。**原生多模融合检索**：提供原生分布式图存储、图查询、图计算与可视化分析能力，融合图、向量与索引，原生支持 ISO-GQL，避免在规模化之后还要为每种检索单独维护一套系统。**多源导入与流式接入**：支持 CSV、JSON、ORC、Parquet、SST 文件，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 数据接入并可导出至 HDFS，这决定了规模上去之后数据还得进得来。

补充一个可参照的量级：在产品迭代历史上，v2.0 版本相比上一版吞吐量提升 50%、延迟降低 30%；内置图计算引擎相比 Spark GraphX 有 6 到 10 倍的提速，资源占用降低 80%。这两组数字的价值不在大小，而在于说明规模化之后的性能提升主要来自引擎优化，而不是靠堆硬件。

# 六、怎么判断自己的规模落在哪一档

最后给一份可以直接拿去用的判断清单。按顺序回答，基本能定位到当前档位与下一步该做什么。

| 判断问题                        | 如果答案是 | 说明                             |
| ------------------------------- | ---------- | -------------------------------- |
| 单机内存能否装下热数据          | 能         | 入门档，重点做备份与恢复演练     |
| 平均度数是否超过 20             | 是         | 邻域展开代价陡增，需评估跳数上限 |
| 是否存在出度十万以上的点        | 是         | 必须单独处理超级节点             |
| 分区之间数据量差距是否超过 3 倍 | 是         | 分区不均衡，加机器难见效         |
| 备份是否能在可接受窗口内完成    | 否         | 需要增量备份与在线扩容能力       |
| 扩容时是否需要停机              | 是         | 架构层面限制，需在选型阶段解决   |

两个常见误区值得单独提醒。**其一，按点数估容量，忽略度数。**点数只决定存储，度数才决定计算。一个度数为 5 的百亿点图谱，很可能比度数为 50 的十亿点图谱更好跑。**其二，把扩容当成解决性能问题的默认手段。**在分区不均衡、超级节点未处理、查询跳数未限制的情况下，加节点往往只是摊薄了硬件成本却没有改善延迟，因为瓶颈根本不在算力总量上。

容量规划这件事，说到底不是问产品能存多大，而是问自己：数据会长成什么形状，什么时候会长出枢纽，涨上来的钱该花在哪一种资源上。把这三个问题想清楚，扩容申请书上「加什么、加多少」也就写出来了。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：千亿点万亿边的规模，对硬件配置有什么要求？**

A：规模上去之后，决定成本的主要不是总点数，而是热数据量、平均度数与查询并发。悦数图数据库采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，可根据数据增长加存储节点、根据查询压力加计算节点；百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒。具体配置需结合实际图谱的度数分布与并发预期评估。

**Q3：悦数在大规模图数据处理上有哪些技术积累？**

A：悦数科技成立于 2018 年，核心团队来自蚂蚁集团、惠普等企业，产品及研发人才占比约 80%，累计拥有 60 余项发明专利。公司在大规模图存储与图计算方向持续投入，相关案例获评中国信通院「领航者」并连续两年入选，其中基于图和多级智能体的动态排障知识问答系统入选信通院最佳实践；据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并与复旦大学共建金融图技术联合研究中心。

图数据库的规模边界不取决于点边总数，而取决于单点邻域规模与分区分片是否均匀。实战口径是：百亿点千亿边量级下点与边精确查询均小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），整体可支撑千亿点万亿边。悦数图数据库拆解四个规模档位与每一档最先崩掉的资源。

图数据库到底能存多大规模？千亿点万亿边的容量与性能边界

![图数据库选型评估清单](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-15.png)

一家[金融机构做图数据库](https://www.yueshu.com.cn/solutions/finance-risk)选型评审，五家厂商交回的技术应答表摊在会议室长桌上。评分人念到第三条时停住了：「支持海量数据存储」——五家全部填「支持」；「查询响应毫秒级」——五家全部填「支持」；「具备高可用能力」——五家还是「支持」。二十几条打分项走完，五家的得分差不到三分。

不是评分人不认真，是指标本身没法区分人。当指标写成形容词，任何产品都能满分；只有把形容词换成数字，差异才会自己浮出来。这篇文章要做的，就是把图数据库选型里真正有区分度的指标列清楚，并给出每一项的实测方法——照着做，评分表上就会出现真实的分数差。

# 一、为什么形容词指标一定会失效

形容词指标的问题在于它没有约定测量条件。「毫秒级响应」是空库还是满库？是单并发还是两百并发？是 1 跳邻居还是 5 跳路径？是热点数据还是冷数据？条件不同，同一个产品的结果可以差出两个数量级。

更麻烦的是，厂商给的数字往往不是假话，只是测量条件和你真正要跑的负载不一致。一个常见的落差：产品手册上写着点查询 3 毫秒，这是单并发、数据全在缓存里的结果；生产环境两百并发、数据分散在磁盘上，P99 可能就到了几百毫秒。两个数字都对，但决策价值完全不同。

所以选型第一步不是收集数字，而是**先约定测量条件，再让各方在同一条件下报数**。条件约定得越死，数字越有比较价值。

| 测量条件维度 | 必须写死的内容                   | 不写死会发生什么             |
| ------------ | -------------------------------- | ---------------------------- |
| 数据规模     | 点数、边数、平均出度             | 小库上人人都能跑进毫秒       |
| 数据分布     | 是否存在超级节点（出度 > 10 万） | 超级节点会让遍历代价陡增     |
| 并发量       | 并发数、读写比例                 | 单并发的漂亮数字掩盖抖动     |
| 数据热度     | 冷启动还是预热后                 | 缓存命中率决定大部分延迟     |
| 结果集规模   | 返回多少条、是否只取计数         | 千万级结果集与十条结果不可比 |
| 统计口径     | 平均值还是 P99/P999              | 平均值会掩盖长尾             |

这张表建议在发标时就附在技术要求后面。它不偏向任何产品，只是把「同一个数字」的定义统一起来。

# 二、七项指标与各自的实测方法

把图数据库的选型指标收敛一下，真正有区分度的是下面七项。每一项都给出测什么、怎么测、以及一个可参考的合格线。

| #    | 指标                 | 测什么                             | 怎么测                                  | 参考合格线                       |
| ---- | -------------------- | ---------------------------------- | --------------------------------------- | -------------------------------- |
| 1    | 点/边精确查询延迟    | 按主键定位单个点或边的响应         | 随机打散 100 万个 ID 循环查询，统计 P99 | 百亿点千亿边下 P99 < 1 秒        |
| 2    | 多跳深度与延迟曲线   | 1~6 跳遍历的延迟随深度的变化       | 固定起点集合，逐跳计时，画曲线          | 5 跳 P99 < 5 秒（千万级结果集）  |
| 3    | 写入吞吐与实时性     | 批量导入速率、CDC 到可查的时延     | 持续写入 24 小时，观察速率是否衰减      | 导入速率稳定不衰减，同步延迟秒级 |
| 4    | 规模容量与扩容线性度 | 上限规模、加节点后吞吐是否线性增长 | 从半量数据起，逐次加节点测吞吐          | 节点数翻倍，吞吐接近翻倍         |
| 5    | 并发与混合负载隔离   | 读写并发下读延迟是否被写拖垮       | 读写按 7:3 混合压测，对比纯读基线       | 混合负载下读延迟劣化 < 30%       |
| 6    | 全图计算能力         | 全图算法在多大图上多快跑完         | 在满量数据上跑 PageRank、Louvain        | 全图算法千亿边量级可完成         |
| 7    | 故障恢复时长         | 节点宕机后的 RTO 与数据一致性      | 随机杀进程、断网，计时恢复              | RTO 分钟级，无数据丢失           |

七项里，第 1、2 项最常被问，第 3、5、7 项最常被漏。漏掉的原因不难理解——前两项在演示环境里最容易展示，后三项要压测、要等、要制造故障，成本高。但真正决定生产能不能上的，往往是后面这几项。

# 三、延迟数字背后的四个陷阱

即使把统计口径统一到 P99，同一个「延迟」指标里仍然藏着四个陷阱。

**其一，平均值与长尾。**平均延迟 50 毫秒听起来不错，但如果 1% 的请求跑 3 秒，那么每一百次调用就有一次让用户明显感到卡顿。多跳查询尤其容易长尾，因为不同起点的邻域规模差异极大。压测报告里必须同时给出 P50、P99、P999 三个值，只看一个等于没看。

**其二，超级节点。**图谱里总有少数节点连着海量边——一个大型集团下的子公司、一个热门商户的交易记录、一个核心枢纽设备。遍历经过这类节点时，代价会突然跳一个量级。测试方法很简单：在数据集里人为构造出度 10 万以上的节点，看经过它的查询延迟是多少。这一项不单独测，上线后一定会在最意想不到的时刻暴露。

**其三，结果集规模。**「5 跳查询 2 秒」这个数字，如果结果集是二十条，那没什么参考价值；如果结果集是千万级，那就是实打实的能力。报延迟必须同时报结果集大小，否则两个数字无法比较。规范的写法是「5 度关系查询小于 5 秒，结果集为千万级」——限定条件写在数字后面。

**其四，冷启动与缓存。**预热之后测出的延迟，反映的是缓存命中时的表现；生产环境每天重启、每天有新数据写入，缓存命中率不会是 100%。诚实的做法是两组数字都测：冷启动一次测，稳定态再测一次，取稳定态作为能力值、冷启动作为最坏情况参考。

| 陷阱           | 典型表现                   | 怎么防                               |
| -------------- | -------------------------- | ------------------------------------ |
| 平均值掩盖长尾 | 平均 50 毫秒，P999 是 3 秒 | 要求同时报 P50/P99/P999              |
| 超级节点       | 个别查询突然慢百倍         | 数据集里构造出度 10 万+ 的节点单独测 |
| 结果集不明     | 延迟很低但只返回几十条     | 报延迟必报结果集规模                 |
| 缓存依赖       | 预热后很漂亮，重启后崩     | 冷启动与稳定态各测一组               |

# 四、指标之间没有全能选手

七项指标不是并列关系，它们之间存在真实的取舍。理解这些取舍，才知道该在哪些项上让步。

**延迟与深度。**追求极深的遍历能力，就要为路径展开付出更多计算；把跳数限制在 2 跳以内，延迟可以压得很低。选型时要根据业务的真实深度需求来定：反欺诈的团伙识别通常 3 到 5 跳，实时推荐的特征拼接多数在 2 跳以内。按最深的那个场景定指标，不要按平均值定。

**新鲜度与吞吐。**要求数据写入即可查，就要牺牲一部分批量写入吞吐；追求极致的导入速率，就要接受数据有分钟级延迟。风控拦截类场景必须实时，离线分析类场景可以接受批量。这两类需求如果混在一个集群里，就需要资源隔离能力——这正好是第 5 项指标要验证的东西。

**容量与成本。**数据放三副本和放两副本，成本差 50%，可靠性差很多。图数据库通常采用多副本保证可用，选型时要问清楚副本策略是否可配置、能否按业务重要性分级。

**通用性与专用性。**内置图算法库越丰富，开发成本越低，但对引擎的实现有要求；通用图计算平台灵活度高，但要自己写算法、自己调性能。宣传册里有个可参照的量级：悦数图分析的图计算引擎相比 Spark GraphX 提速 6 到 10 倍，资源占用降低 80%，开发效率提升 80%——这类数字的价值不在于大小，而在于它把「内置算法」和「通用计算框架」的差距量化出来了。

| 取舍对         | 向左走               | 向右走                       | 判断依据                   |
| -------------- | -------------------- | ---------------------------- | -------------------------- |
| 延迟 vs 深度   | 限制跳数，延迟极低   | 支持深度遍历，延迟随深度上升 | 业务最深的查询是几跳       |
| 新鲜度 vs 吞吐 | 写入即可查，吞吐适中 | 批量导入极快，数据有延迟     | 场景是实时拦截还是离线分析 |
| 容量 vs 成本   | 三副本，可靠性优先   | 两副本，成本优先             | 数据能否重新生成           |
| 通用 vs 专用   | 内置算法库，开箱即用 | 通用框架，自己实现           | 团队是否愿意投入算法开发   |

# 五、悦数图数据库在七项指标上的实测口径

把七项指标落到具体产品上，需要一个统一的口径。悦数图数据库公开的实测数据是：支持千亿点万亿边的数据存储，在百亿点千亿边量级下，点精确查询时间小于 1 秒、边精确查询时间小于 1 秒、5 度关系查询时间小于 5 秒，结果集为千万级。这几个数字的限定条件写得很完整——规模、跳数、结果集都标明了，可以直接拿来做横向对比的基准。

架构层面，[悦数图数据库](https://www.yueshu.com.cn/database)采用 Shared-Nothing 与存算分离设计，存储与计算可独立扩缩容，这对应第 4 项扩容线性度：查询压力上来时加计算节点，数据涨上来时加存储节点，不必整体扩容。数据接入侧支持 CSV、JSON、ORC、Parquet、SST 文件，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 流式接入并导出至 HDFS，对应第 3 项写入与实时性。

查询层原生支持 ISO-GQL 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言，这一项不直接对应七项指标中的任何一项，但它决定了第 7 项之外的隐性成本——迁移与人员上手成本。全图计算侧提供内置图算法库与图计算引擎，对应第 6 项。

# 六、一份可直接带走的 POC 验收清单

最后把七项指标整理成可以贴进 POC 方案的验收表。建议按下面这张表执行，每一项都要求厂商在约定条件下报数，并保留压测脚本以便复现。

| 验收项        | 数据条件              | 合格判据           | 未达标时的应对           |
| ------------- | --------------------- | ------------------ | ------------------------ |
| 点/边精确查询 | 百亿点千亿边，随机 ID | P99 < 1 秒         | 检查索引与副本配置       |
| 多跳遍历      | 1~6 跳，千万级结果集  | 5 跳 P99 < 5 秒    | 评估是否需要限制业务跳数 |
| 超级节点      | 构造出度 10 万+ 节点  | 无数量级劣化       | 考虑拆分或预计算         |
| 批量导入      | 持续 24 小时          | 速率不衰减         | 检查分区与写入批次       |
| 混合负载      | 读写 7:3 并发         | 读延迟劣化 < 30%   | 启用读写资源隔离         |
| 扩容          | 节点数翻倍            | 吞吐接近翻倍       | 检查分区数是否充足       |
| 故障恢复      | 随机杀节点            | RTO 分钟级，无丢失 | 核查副本与快照策略       |

两个常见误区值得单独提醒。**其一，用演示数据跑 POC。**演示数据集通常只有几百万点，任何产品都能跑出漂亮数字；真正有区分度的是量级上去之后的表现。POC 数据量至少要到生产预期规模的十分之一，否则测不出分区、索引、副本的真实影响。**其二，只测查询不测运维。**上线之后占用人力最多的是变更、扩容、故障处理，这几项不进 POC，等于是把最大的一块成本留到上线后再发现。

选型这件事，最后比的不是谁的参数表更长，而是谁肯把测量条件写清楚。条件一清楚，数字自己会说话。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：图数据库选型时，图规模多大才需要考虑分布式架构？**

A：判断依据不是点边数的绝对值，而是单机是否能容纳完整的热数据集并留出冗余。经验上，当图谱规模超过单机内存加 SSD 可承载的容量、或查询并发已经让单机 CPU 成为瓶颈时，就需要考虑分布式。悦数图数据库采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，支持千亿点万亿边规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒。

**Q3：悦数图数据库有哪些权威资质与技术认证？**

A：悦数图数据库已全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例；据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二。公司拥有 60 余项发明专利，通过统信、麒麟、中科可控等国产软硬件兼容认证，技术专家作为 ISO 的 GQL 标准委员会成员深度参与国际标准拟定。

图数据库选型不能只问响应快不快。真正能区分产品的是七项可量化指标：点边精确查询延迟、多跳深度与延迟曲线、写入吞吐与实时性、规模容量与扩容线性度、并发与混合负载隔离、全图计算能力、故障恢复时长。悦数图数据库逐项给出实测方法与合格线参考。

图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单

![Text2GQL 图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-14.png)

同一个问题交给两位工程师，会得到两个不同的数——不是谁算错了，而是两人对间接关联的理解不一样：一个按一跳算，一个按三跳以内算。两个查询都能跑通，都返回结果，都没有报错，结论却差了好几倍。这类不报错的错误，才是[自然语言查图数据库](https://yueshu.com.cn/posts/ISO-GQL-important)真正的难点。Text2GQL 要解决的从来不是让模型写出一句语法正确的查询，而是让它在动手之前，把业务语言里的每个限定词都翻译成图谱模型里唯一确定的东西。换句话说，它的准确率不取决于模型有多聪明，而取决于有没有一套能兜住语义歧义的机制，而机制能否立住，又取决于底层的图数据库能不能把结构信息如实、实时地提供出来。

# 一、先把概念边界划清：Text2GQL 是什么、不是什么

Text2GQL 经常被误解成一个聊天式查询入口，似乎接上大模型就能让人直接用中文问数据库。实际上它的定位要窄得多，也实在得多。

它不是问答机器人，产出的是可执行的查询语句，不是答案。系统拿到自然语言问题后，先解析出实体、关系、时间范围与聚合口径，再翻译成一条规范语句交给图数据库执行，最后才由应用层组织结果。把这条链路理解成一个语义解析层，后面的准确率设计才有着力点。

它和另外三个常见名词的关系也值得一次说清，因为它们经常被混用。

| 名称       | 方向             | 输入                    | 输出                 | 解决什么问题                      |
| ---------- | ---------------- | ----------------------- | -------------------- | --------------------------------- |
| ISO-GQL    | 国际标准         | —                       | —                    | 图查询语言的标准统一（ISO 39075） |
| Any2GQL    | 方言归一         | Cypher、nGQL、GSQL 语句 | 统一的 ISO-GQL 语句  | 存量应用迁移，查询不必重写        |
| Text2GQL   | 自然语言转查询   | 自然语言问题            | ISO-GQL 或 nGQL 语句 | 业务人员不必先学会查询语言        |
| Text2Query | 更宽的同链路口径 | 自然语言问题            | 可执行查询语句       | 平台侧对这类能力的统称            |

一句话概括三者的分工：Any2GQL 让存量语句能跑，Text2GQL 让业务人员能问，ISO-GQL 让两者都有统一的落点。

# 二、把准确率拆成四道关卡

讨论准确率时最容易犯的错误，是把它当成一个整体指标去追。实际上自然语言到可执行查询要穿过四道关卡，每一道都有自己的失败形态，而且失败的方式完全不同——有的是明确报错，有的悄无声息。

| 关卡     | 要回答的问题                 | 典型失败形态             | 后果                 | 保障手段                           |
| -------- | ---------------------------- | ------------------------ | -------------------- | ---------------------------------- |
| 意图解析 | 这个问句到底在问什么         | 漏掉限定词、误判聚合口径 | 查询能跑，结果偏了   | 限定词清单化、关键参数必须显式确认 |
| 模式映射 | 业务词对应图谱里哪个标签属性 | 猜错字段、同义词未对齐   | 查不到数据或查错对象 | 语义层、同义词典、结构索引         |
| 语句生成 | 目标方言怎么写才规范         | 语法错误、越界写法       | 直接报错，容易发现   | 标准语法约束、版本兼容校验         |
| 结果校验 | 这条查询能不能安全执行       | 无校验直接放行           | 全图扫描拖垮生产库   | 干跑预估、结果集上限、权限校验     |

四道关卡里，第一道和第二道是隐蔽的，第三道和第四道是显性的。有意思的是，显性失败反而不致命——语法错误会立刻抛出来，改掉即可；真正会长期消耗信任的，是那些不报错却答非所问的结果。因此准确率工程的重心应当压在意图解析与模式映射上，而不是纠结模型能不能写出漂亮的语句。

以间接关联这个说法为例，意图解析至少要把它拆成四个显式参数：跳数上限（一跳直连，还是三跳以内的间接关联）、边的类型（只算股权，还是包含担保与交易）、主体范围（是否包含已注销或已退出的主体）、时间窗口（按当前快照，还是按某一历史时点的快照）。四项里任何一项含糊，查询的语义都会漂移，结果却照常返回。工程上的解法不是让模型去猜，而是把这份参数清单固化成必填项：系统识别到问题里出现此类模糊词，就主动向用户确认，或者用企业已确认的口径默认值补齐，并把采用的默认值随结果一并返回，让用户看得见自己拿到的是哪一种解释。

# 三、最容易失守的一环：模式映射

模式映射（Schema Grounding）指的是把业务语言里的词，对应到图谱里真实的标签、属性与关系类型。它难的根源在于，业务语言与数据模型之间没有一对一的字符串对应：用户说的集团客户，在图谱里可能是一个客户标签加上一个是否集团属性；用户说的关联方，可能对应股权、担保、交易三类边中的两类，具体哪两类还得看口径文件。

这一环有三种常见做法，可靠性的差别很大。

| 做法                 | 原理                                                         | 长处                     | 失效点                                           |
| -------------------- | ------------------------------------------------------------ | ------------------------ | ------------------------------------------------ |
| 全量结构塞进提示词   | 把标签属性清单整体交给模型                                   | 实现最快，无需额外建设   | 图谱一大就超上下文，模型在长清单里挑错字段       |
| 向量召回结构片段     | 按问题相似度取回相关结构                                     | 长度可控，能覆盖常见问题 | 相似度找的是措辞相近的字段，不是语义对得上的字段 |
| 以图谱自身作结构索引 | 先用问题中的实体定位图谱局部，再从该局部推导可用的标签与属性 | 范围准确，过程可解释     | 依赖图查询能力支撑，对底座有要求                 |

第三种做法之所以更稳，是因为它把映射问题从文本匹配变成了结构收敛：先确定问题落在图谱的哪一块，可选的标签与属性自然被限定在一个很小的集合里，模型要做的只是在这个集合里挑，而不是在上千个字段里猜。这正是图数据库在语义解析链路里不可替代的位置——结构索引与数据本身同库同源，不存在外部元数据与真实模型不一致的问题。

# 四、三类把准确率做实的工程手段

模型侧的调优收益有限，真正拉开差距的是三类工程手段。

**其一，语义层与查询模板。**把高频问题预定义成模板，把口径参数化。以间接关联为例，模板里明确写着跳数上限、包含哪几类边、是否含已注销主体。用户提问时系统匹配模板并填充参数，模糊限定词在这个环节被消解，而不是留给模型自由发挥。这是收益最大、见效最快的一步——高频问题是有限的，把它们固化下来，绝大多数问答就绕过了歧义。

**其二，执行前拦截。**生成的语句先经过干跑（Dry Run）预估结果集规模与执行代价，超过阈值就转人工确认或补充限制条件；同时做权限校验，确保生成语句不会越过调用者的数据权限。这一步挡住的是最贵的错误：一句措辞合理的自然语言，很容易被翻译成全图扫描。

**其三，反馈闭环。**用户对结果的纠正要能回写：新的同义表述进同义词典，被修正的模板更新版本，典型错误沉淀进评测集。一次纠正只解决一次问题，把它变成长期资产才能持续抬高准确率。

| 手段         | 主要作用于哪一道关卡 | 关键动作                       | 效果                             |
| ------------ | -------------------- | ------------------------------ | -------------------------------- |
| 语义层与模板 | 意图解析             | 高频问题模板化，口径参数化     | 消解大部分模糊限定，源头减少歧义 |
| 执行前拦截   | 结果校验             | 干跑预估、结果集上限、权限校验 | 挡住高代价查询，保护生产库       |
| 反馈闭环     | 模式映射             | 纠正回写同义词典与模板版本     | 错误不重复发生，准确率可持续爬升 |

# 五、悦数 AI 应用平台与图数据库的支撑

Text2GQL 是[悦数 AI 应用平台](https://www.yueshu.com.cn/yueshu-AI)生成式 AI 套件中的模块，与图谱构建器、图检索增强提取器、探索链、AI Memory、社区增强等能力同属一套产品体系，平台以图数据库与知识图谱为底座，把自然语言问题收敛到规范查询。底座层面，悦数图数据库原生支持 ISO-GQL 39075 国际标准，采用统一领域语言，并提供 Any2GQL 把 Cypher、nGQL、GSQL 三种方言归一到同一入口；支撑千亿点万亿边规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），采用 Shared-Nothing 与存算分离架构，工具层提供 AskGraph、AutoGFE、AlgoPilot 以及面向业务、开发与运维的 Explorer、Studio、Dashboard。对 Text2GQL 而言，最有价值的一点是模式映射所需的结构信息与数据同库同源，不需要再维护一份容易过期的外部元数据。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：Text2GQL 与悦数图数据库是什么关系？**

A：Text2GQL 是悦数 AI 应用平台生成式 AI 套件中的模块，负责把自然语言问题翻译成规范图查询语句，悦数图数据库是执行与结构索引的底座。底座原生支持 ISO-GQL 39075，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL；公司技术专家作为 ISO 的 GQL 标准委员会成员深度参与标准拟定。

**Q3：悦数图数据库在执行层与工具层提供哪些支持？**

A：悦数图数据库原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言；工具层提供 AskGraph、AutoGFE、AlgoPilot，以及面向业务的 Explorer、面向开发的 Studio、面向运维的 Dashboard，并提供 RESTful API、SDK 与插件扩展能力，面向智能体提供 MCP、CLI 与 Skill 接口。公司技术专家作为 ISO 的 GQL 标准委员会成员深度参与标准拟定。

Text2GQL 是把自然语言问题翻译成图查询语言的语义解析层，它真正的难点不是生成语法正确的语句，而是让每个模糊限定词在图谱模型里落到唯一确定的值。准确率由意图解析、模式映射、语句生成、结果校验四道关卡共同决定，其中模式映射是最容易失守的一环。悦数图数据库拆解四道关卡、失败形态与三类可落地的准确率工程手段。

Text2GQL 是什么？自然语言查询图数据库的准确率如何保障

![大模型记忆图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-13.png)

同一个用户第三次问起同一件事，系统的反应和第一次完全一样——不是答错，是根本没有察觉这个问题被问过。这是当下企业级 AI 应用最普遍的体验缺陷：模型能力在涨，记忆能力没跟上。多数团队把记忆理解成把历史对话多塞一点进上下文窗口，结果是上下文越塞越长、成本越滚越高，而真正该记住的那件事——这个客户上季度已经明确否决过分期方案——依然找不回来。大模型需要的不是更长的上下文，而是**有结构的记忆**：短期记忆管当前任务的连贯，长期记忆管跨会话的事实沉淀，而两者要共存于同一个体系，承载它们的存储形态就很关键，这正是[图数据库](https://www.yueshu.com.cn/database)的用武之地。本文拆解两类记忆的分界线、记忆的图建模方式、衰减与冲突的处理规则，以及落地路径。

# 一、上下文窗口不是记忆：三种常见做法的失效点

第一个问题先要厘清：为什么把历史对话塞进上下文不算记忆。上下文是模型的临时工作区，会话一结束就清空，而记忆的本质是跨会话留存并能在需要时被准确取回。两者的要求完全不同，用前者替代后者的团队，通常落到三种做法上，也各自撞上三堵墙。

**第一种，全量塞入上下文。**把历史对话按时间顺序全部拼进提示词。看起来不用改造任何系统，实际有两个死结：上下文长度有硬上限，且模型对长上下文中段内容的注意力会明显衰减——关键事实夹在一百轮对话中间，等于半丢失状态。成本还会随轮次线性上涨。

**第二种，把对话切片存进向量库。**按语义相似度召回旧对话。它找回的是措辞相似的片段，不是关于某个对象的完整记忆。同一件事分散在七八次对话里，向量检索不会主动把它们串成一条线索，更不会告诉你哪一条是最新的。

**第三种，写进业务系统的字段。**记在工单备注、CRM 客户卡片里。人可读、可审计，但没有一项是机器能直接拿去推理的——模型无法在一次问答里自然地做一次跨表关联，把散落在三个模块里的记忆拼起来。

| 做法             | 表面上解决了什么   | 真实失效点                                         |
| ---------------- | ------------------ | -------------------------------------------------- |
| 全量塞入上下文   | 不需改造现有系统   | 长度有上限，中段注意力衰减，成本随轮次线性上涨     |
| 对话切片存向量库 | 能按语义找回旧对话 | 只还原措辞相似片段，不还原同一事实的多次提及与演变 |
| 写进业务系统字段 | 人可读、可审计     | 机器无法在推理中直接调用，跨对象关联查询做不了     |

# 二、短期记忆与长期记忆的分界线在哪

两类记忆经常被混为一谈，实际它们服务的对象完全不同。短期记忆服务的是这一轮任务：用户刚说的条件、刚刚查到的中间结果、本轮会话的主题指向。它的生命周期就是会话本身，会话结束即释放。长期记忆服务的是这个对象的历史：客户的风险偏好、曾经否决过的方案、组织架构的变更、上一次谈判的底线。它必须跨会话存活，而且要能在几个月后被准确取回。

判断一条信息该进哪一类，只需要问一个问题：**下一次会话里它还有用吗？**有用进长期，没用留在短期。这个标准足够简单，也足够可靠——它把主观判断转成了一个可自动执行的规则。

| 维度     | 短期记忆                               | 长期记忆                                   |
| -------- | -------------------------------------- | ------------------------------------------ |
| 时间跨度 | 当前会话、当前任务                     | 跨会话、跨月甚至跨年                       |
| 典型内容 | 本轮上下文、临时变量、刚查到的中间结果 | 用户偏好、历史决策与理由、实体事实及其变更 |
| 载体     | 会话缓冲区、临时图（Temp Graph）       | 持久化图谱的节点与边                       |
| 检索方式 | 顺序读取、最近优先                     | 按实体关系召回，配合社区增强与重要性排序   |
| 失效策略 | 会话结束即释放                         | 按时间与证据衰减，冲突时按规则覆盖         |
| 出错代价 | 答非所问，重问一次                     | 记错事实，后续所有判断连带出错             |

用同一套数据模型承载两类记忆，是这套设计里最值得强调的一点。如果短期记忆存在会话缓存、长期记忆存在另一个系统，那么从短期升级为长期就需要一次跨系统的数据搬运，而这次搬运往往会丢掉上下文与来源。放在同一张图里，升级只是一次属性变更。

# 三、记忆怎么写成图：从一条对话到一组边

记忆不是把对话原文存下来，而是把它拆成结构化的事实，锚定到对象上。具体有三个建模要点。

**其一，记忆挂在实体上，不挂在对话上。**检索的起点决定了建模方式。用户问的是这个客户、这个项目、这份合同，那么记忆的锚点就应该是这些实体节点，而不是第几轮对话这个序列位置。把用户、企业、项目、合同建成节点，记忆作为独立节点或关系边挂上去，召回时先定位实体，再取其全部记忆——这和按对话切片的检索是两条完全不同的路径。

**其二，时间、来源与置信度必须成为属性。**每条记忆至少要带四个字段：发生时间、写入时间、来源类型（用户陈述／系统推断／文档提取）、置信度。这四项不是锦上添花，它们是后面判断冲突与执行衰减的唯一依据。缺了来源，系统就分不清用户亲口说的话和模型自己推断出来的结论，两者在冲突时该听谁也就无从判断。

**其三，短期与长期共用一套模型，差异只在生命周期。**新写入的记忆默认带短期标记与过期时间，会话结束或超期即清理；被反复引用、被用户确认、或命中关键实体属性的记忆，升级为长期并取消过期。这套机制写在图里，就是属性与边的增删改，不需要在两套系统之间做同步。

还有一个容易被跳过、但直接决定召回质量的动作：**把散落的记忆组织成簇**。单个客户可能累积几十条记忆，逐条召回会漏，全量返回又太长。借助社区发现、PPR 与邻居发现这类图算法，可以把围绕同一主题反复共现的记忆自动聚成一个语义簇——比如这个客户的全部风控相关记忆、全部价格敏感型反馈——召回时先命中簇，再展开簇内明细，既保证覆盖又控制长度。这类聚类在向量库里做不了，因为聚的是关系的密集程度，不是文本的相似程度。

# 四、记忆的衰减与冲突：该忘什么、听谁的

记忆系统真正难的不是写，是维护。写入容易，难的是让图谱不随时间腐化。

**衰减不是定时删除，而是按权重排序。**一条记忆的综合权重由三部分构成：时间新鲜度（越旧越低，可按半衰期折算）、引用次数（被后续对话佐证或多次召回的加分）、来源等级（用户确认高于用户陈述，用户陈述高于系统推断，系统推断高于文档提取）。权重低于阈值的记忆退出默认召回集合，但节点与边本身保留，需要时仍可回溯——审计场景下，忘掉和删除是两回事。

**这套权重机制自然导出三条运维策略。**一是时效清理：带强时效性的记忆（比如本季度的预算口径）过了有效期就退出召回，避免拿旧口径回答新问题。二是引用加固：被反复召回、被后续对话反复佐证的记忆权重持续上升，越用越牢固。三是确认升级：用户明确确认或修正过的记忆直接置为最高等级并转为长期，一次确认胜过十次推断。

**冲突则必须有一套事先定好的规则。**记忆写多了必然出现矛盾：上个月说预算五十万，这个月说三十万；文档里写的口径与用户口述不一致。系统不能靠模型临场裁决，那等于把错误随机化。

| 冲突情形               | 处理规则                             | 判断依据               |
| ---------------------- | ------------------------------------ | ---------------------- |
| 新旧事实矛盾           | 新记忆覆盖旧记忆，旧记忆降为历史版本 | 时间属性，且保留可回溯 |
| 用户陈述与系统推断冲突 | 用户陈述优先                         | 来源属性与置信度       |
| 文档提取与用户确认冲突 | 用户确认优先                         | 确认动作本身即最强证据 |
| 两条同级记忆矛盾       | 都保留，标记待确认并主动向用户追问   | 不做静默裁决，避免记错 |

最后一条最容易被忽略，却是记忆系统与存储系统的分水岭：**记忆最怕的不是忘，而是记错。**遗忘的代价是重问一次，记错的代价是污染后续所有推理，而且很难被发现。因此当两条同级记忆互相矛盾、又没有更高优先级的证据时，正确做法是标记为待确认并向用户追问，而不是让模型自己挑一个看起来顺眼的。

# 五、悦数 AI 应用平台与图数据库的支撑

AI Memory 是悦数 AI 应用平台生成式 AI 套件中的记忆模块，与图建模、图检索增强提取器、图谱构建器、社区增强、探索链、Text2GQL、图洞察智能体等能力同属一套产品体系，短期记忆与长期记忆统一由图数据库承载。底座层面，悦数图数据库支持千亿点万亿边的存储规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），原生融合图、向量与全文索引，采用 Shared-Nothing 与存算分离架构，并提供面向智能体的 MCP、CLI 与 Skill 接口。对记忆系统而言，这意味着写入、衰减与按实体召回都发生在同一个引擎内，不需要跨系统做记忆同步。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：AI Memory 与悦数图数据库是什么关系？**

A：AI Memory 是悦数 AI 应用平台生成式 AI 套件中的记忆模块，短期记忆与长期记忆统一由悦数图数据库承载，与图建模、图谱构建器、社区增强、探索链等能力同属一套产品体系。底座可支撑千亿点万亿边规模，5 度关系查询小于 5 秒，并提供面向智能体的 MCP、CLI 与 Skill 接口。

大模型需要的不是更长的上下文窗口，而是有结构的记忆：短期记忆负责会话内的连贯，长期记忆负责跨会话的事实沉淀，两者的分界线是这条信息下一次会话还有没有用。记忆只有锚定在实体上、带上时间与来源属性，才能被正确衰减与召回。悦数图数据库分析拆解记忆的写入、组织、衰减与召回机制，以及图数据库在其中不可替代的位置。

大模型需要什么样的记忆？短期记忆与长期记忆在图数据库中怎么存

![探索链图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-12.png)

去图书馆找一句话，没有人会把全部藏书翻一遍。正确的做法是先确定在哪一层楼，再到哪个书架，抽出哪一本书，最后翻到第几页——每一步都在缩小范围，每一步都不存在走错楼层、找错书架的余地。企业知识问答本来也该这样做，但大多数检索增强系统的实际做法恰好相反：把问题扔进全库做语义检索，召回几十段可能相关的文字，全部塞给大模型，指望它自己挑出对的那个。材料越多，挑错的概率越大，这就是企业问答准确率长期上不去的结构性原因。探索链（Chain of Exploration）的做法是让系统像图书管理员一样工作：**先锁定知识范围，再精准定位答案**，而承载这套逐层收敛机制的，正是图数据库。本文拆解探索链四级收敛的完整机制、[图数据库](https://www.yueshu.com.cn/database)在其中的支撑作用与落地要点。

# 一、宽召回与逐层收敛：两种问答架构的差别

当前主流的企业问答流程是宽召回式的：问题进来，先做向量化，在全库文档中检索语义相近的段落，取相似度最高的若干条拼进上下文，交给大模型生成回答。这套流程的根本问题在于，它把找材料和做判断两件事全部压在了同一个相似度排序上——排序靠前的段落未必是回答问题需要的段落，只是措辞最像的段落。当知识库达到几十万份文档时，同一个话题下措辞相近的材料成百上千，宽召回的噪声足以淹没真正有用的那一小部分；更麻烦的是，被召回的材料彼此之间没有校对，版本冲突、口径打架时，模型只能自行裁决。

探索链代表的是另一种架构：不急着检索全文，先把问题落到知识库的结构上——这个问题涉及哪个业务域、哪些文档类别、哪些实体——把检索范围从全库收缩到一个很小的子集，再在这个子集内做精细定位。范围小了，噪声自然少；上下文干净了，大模型面对的任务从大海捞针变成了按图索骥，回答的准确率与可解释性都有了着落。

| 维度         | 宽召回式 RAG                 | 探索链收敛式                         |
| ------------ | ---------------------------- | ------------------------------------ |
| 检索起点     | 全库文档                     | 按结构与问题定位的局部范围           |
| 范围控制     | 无，只靠相似度阈值           | 四级逐层收敛，每级有明确过滤依据     |
| 上下文构成   | 相似度最高的若干段落         | 范围内精选段落 + 实体关系 + 口径规则 |
| 噪声来源     | 同话题近似文档大量涌入       | 收敛后基本排除域外材料               |
| 典型错误形态 | 材料塞错，模型在矛盾中二选一 | 走错层级，可沿链路定位修复           |
| 可解释性     | 只有一个相似度分数           | 每一步收敛路径可回放                 |

# 二、四级收敛：文件夹、文档、段落、实体

探索链的收敛分四级，每一级回答一个不同的问题，也各自依赖一种不同的结构。

**第一级，文件夹——这属于哪个业务域。**企业知识库不是一堆平等的文档，而是按业务域组织起来的：授信管理、贸易融资、合规审计各归其位。问题进来后先识别意图与实体，落到对应的业务域目录上，域外的全部文档在这一步就被排除了。一个问到授信额度的问题，不应该在设备维权的文档里浪费任何检索预算。

**第二级，文档——是哪份文件在管这件事。**同一业务域内往往有多份文件讲过同一件事：现行办法、历史版本、征求意见稿、批复纪要。这一步依赖的不是关键词，而是文档之间的版本关系与引用关系——哪些是现行有效的，哪些已被替代，在结构上是登记过的。选错版本是宽召回式问答里最隐蔽的一类错误，答案看起来通顺，依据却是废止的条款。

**第三级，段落——文中哪一段给出答案。**定位到文档之后，收敛进入文档内部：按章节层级与语义定位到具体段落，比如制度正文里的某一条和它的附件口径说明。这一步排除的是主题相关但不含答案的段落——它们讨论的是同一件事，却没有给出判定规则或数值。

**第四级，实体——答案涉及哪些具体对象。**段落里的集团名称、产品名称要对齐到图谱中的实体节点，再沿关系边做聚合与校验。到此为止，系统拿到的不是一堆文字，而是一组带出处的原文片段加上一组可直接计算的关系数据。

| 层级   | 回答的问题         | 依赖的结构             | 这一步过滤掉什么         |
| ------ | ------------------ | ---------------------- | ------------------------ |
| 文件夹 | 属于哪个业务域     | 目录树、业务分类体系   | 域外全部文档             |
| 文档   | 哪份文件在管这件事 | 文档版本边、引用边     | 废止版本、无关文档       |
| 段落   | 哪一段给出答案     | 文档内部层级与章节结构 | 主题相关但不含答案的段落 |
| 实体   | 涉及哪些具体对象   | 实体节点与关系边       | 与问题实体无关的泛化表述 |

# 三、收敛为什么必须由图数据库来承载

四级收敛看起来像目录树的逐级下钻，顺着树往下走并不难。真正难的是另外三件事，而这三件事恰好都超出纯文本系统能力的边界。

**其一，层级结构不是纯粹的树。**文件夹、文档、段落构成纵向的树，但树的每个节点同时横向连着实体：某一段落提到的这家供应商，要能跳到图谱中的企业节点，再沿股权、授信、担保这些边跳到它的关联网络。纵向收敛靠树，横向关联靠图——两者必须放在同一个数据模型里，跳转才不需要跨系统拼接。这正是图数据库以点、边、属性直接建模的用武之地。

**其二，实体消歧需要关系做证据。**同一家供应商在文档库里可能有五种写法：全称、简称、带括号的分支机构名、曾用名、英文注册名。纯文本消歧只能靠字符串相似度，误合并与漏合并都难以避免；在图上，可以沿股权关系、法定代表人、注册地址、历史交易对手等边验证两个名称是否指向同一实体——关系一致才是真正的同一实体的证据。

**其三，版本与口径必须挂在结构上。**哪份文件现行有效、哪条口径适用于哪类业务，在宽召回里只是文档元数据里的一个字段，检索时常常被忽略；在图里，它们是版本边、生效状态属性和业务规则节点，收敛时可以直接作为过滤条件参与计算。

| 收敛决策               | 仅靠文本相似度           | 依托图数据库结构             |
| ---------------------- | ------------------------ | ---------------------------- |
| 判断文档是否现行有效   | 看发布时间字段，易被忽略 | 版本边与生效状态属性直接过滤 |
| 确认两个名称是同一实体 | 名称字符串相似度         | 股权、法人、地址等关系边佐证 |
| 找到口径定义           | 召回含该词的段落         | 业务规则节点与实体引用边直达 |
| 限定检索范围           | 关键词过滤，边界模糊     | 业务域子图直接圈定           |

# 四、一个完整回合：从提问到可追溯的回答

用一个金融场景把流程走完。问题：我们与某集团成员企业的互保额度上限，按现行制度应该怎么算？

第一步，意图与实体识别：问题里有一个实体（该集团成员企业）、两个概念（互保、额度上限）、一个限定（现行制度）。第二步，文件夹级收敛到授信管理业务域。第三步，文档级定位到集团客户授信管理制度的现行版本，沿版本边排除已废止办法与征求意见稿。第四步，段落级命中互保额度条款与附件中的口径说明。第五步，实体级把段落中的集团名称对齐到图谱节点，沿担保关系边聚合该集团与本行的实际互保余额，再与制度阈值比对。输出时，结论、原文出处、数值口径、计算路径一并返回——制度原文来自段落层，数值来自图聚合，每一条都可以人工复核。

这个回合里，大模型做的事只有一件：把结构化结果翻译成通顺的句子。它没有被要求在几万份文档里回忆答案，只被要求转述一条已经验证过的链路，幻觉由此失去滋生的空间。官方资料显示，凭借独创的探索链技术，悦数 AI 应用平台的回答准确率位居行业第一；该能力已在某研究所基于图和多级智能体的动态排障知识问答系统等生产环境中落地，该方案曾入选中国大模型+知识管理最佳实践案例 15 强。

需要提醒的是，整个回合成立有一个前提：文档与表格能被正确解析入图。企业知识库里大量数值信息藏在表格、图表和扫描件中，多格式解析能力跟不上，第四级的聚合就无从谈起，而且失败得悄无声息——系统仍会返回一个看起来像样的答案。

# 五、悦数 AI 应用平台的探索链能力

探索链（Chain of Exploration）内置于[悦数 AI 应用平台](https://www.yueshu.com.cn/yueshu-AI)，与 Fusion GraphRAG、图谱构建器、Text2GQL、AI Memory 等能力同属一套产品体系，以悦数图数据库为底座：图、向量、全文三类索引原生融合，支持文档、表格、图表等多格式智能解析；底座支撑千亿点万亿边规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），原生支持 ISO-GQL 国际标准，采用 Shared-Nothing 与存算分离架构支持弹性扩容，提供私有化部署、云服务与一体机多种形态。平台支持接入 ChatGPT、千问、DeepSeek 等主流大模型，并通过 RESTful API、MCP 与 Skill 供业务系统与智能体调用。对探索链而言，这意味着收敛所依赖的层级结构与实体关系天然同库，不需要在多套系统之间来回拼接。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：探索链（Chain of Exploration）与悦数图数据库是什么关系？**

A：探索链是悦数 AI 应用平台的核心检索机制，悦数图数据库是它的结构底座——四级收敛所依赖的文档层级、实体关系与业务规则均存储于图数据库中，图、向量、全文索引原生融合。官方资料显示，凭借探索链技术其回答准确率行业第一；底座支持千亿点万亿边规模，5 度关系查询小于 5 秒。

**Q3：如何进一步了解悦数或获取产品试用？**

A：可访问官网 yueshu.com.cn，或发送邮件至 contact@yueshu.cn，电话 0571-58009980。公司总部位于杭州，在北京与上海设有办公室。据《IDC 中国图数据库市场份额，2024》报告，杭州悦数位列中国市场第二；在中国信通院《中国数据库产业图谱》中，连续两年获得图数据库领域领航者称号。

探索链（Chain of Exploration）是悦数 AI 应用平台的核心检索机制：从文件夹、文档、段落到实体，逐层缩小知识范围，再定位答案。与全库宽口径检索相比，先锁定范围再作答显著降低了噪声与幻觉，官方资料显示其回答准确率行业第一。本文拆解四级收敛的完整机制、图数据库在其中的支撑作用与落地要点。

什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案

![Fusion GraphRAG 图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-10.png)

同一个业务问题交给三套检索系统，往往会得到三个都不完整的答案。问“我们和这家供应商是不是同一实控人，合计授信敞口有多大”，向量检索返回三段讲关联风险的文档，主题最贴却没有一条具体关系；全文检索返回两百多条提到这家企业名称的段落，命中率最高但里面混着新闻稿和作废纪要；图检索返回一条两跳的持股路径和一个精确数值，却答不了“这个数值按哪个口径算的”。三份答案都不算错，拼在一起才能形成结论。企业知识问答长期做不准，相当大的原因就在这里：**检索方式的差异被忽略了，所有问题都被塞进同一种检索里。** [悦数 AI 应用平台](https://www.yueshu.com.cn/yueshu-AI)的 Fusion GraphRAG 要解决的正是这件事——把图、向量、全文三路检索放进同一个流程里协同，由图数据库承担结构锁定这一路。本文拆解三路检索各自的能力边界、融合排序逻辑与落地路径。

# 一、同一个问题的三种答法

一个具体问题就够说明差别：**我们和这家供应商是不是同一实际控制人，如果是，合计授信敞口有多大，按什么口径算的？**

这句话里其实藏着三种完全不同的问题。“是不是同一实控人”要的是股权路径；“敞口多大”要的是精确数值与聚合；“按什么口径算的”要的是制度原文。把整句话丢给任意一种检索，都会有一部分落空。

交给**向量检索**，它按语义相似度召回一批讲“集团客户授信”“实控人识别”“关联风险”的文档与段落。读起来都很相关，但没有一条告诉你这两家企业是否同一人控制，也没有一条给出行内的具体数字。

交给**全文检索**，它把库里所有提到这两家企业名称的段落全部命中，可能有几百条，包含合同、会议纪要、行业新闻、内部制度。命中率高，但其中大部分与这个问题无关，而且它无法判断“提到”是否等于“有关系”。

交给**图检索**，从两家企业节点出发沿持股关系向上遍历，两跳就定位到同一个自然人节点；再沿授信关系边聚合，返回一个带口径的数值。答案精确，但它读不懂“敞口”在本公司的定义里是否包含表外担保、是否扣除保证金——这类口径问题只在制度文本里，不在图结构里。

三种检索的差异来自匹配依据本身不同，而不是实现好坏。

| 检索方式 | 匹配依据               | 擅长回答                               | 返回形态           | 典型失效                           |
| -------- | ---------------------- | -------------------------------------- | ------------------ | ---------------------------------- |
| 向量检索 | 语义相似度（嵌入距离） | 概念解释、模糊表述、同义改写           | 文档与段落片段     | 需要精确关系或数值时只给近似材料   |
| 全文检索 | 关键词匹配与倒排索引   | 专有名词、条款编号、型号代码、人名地名 | 命中段落与位置     | 同义表达漏检，无法判断关系是否成立 |
| 图检索   | 结构可达性、路径与聚合 | 多跳关系、路径追溯、圈子识别、分组统计 | 子图、路径、统计值 | 语义模糊的问题定位不到起点         |

# 二、三路单独跑都不够：四种可复现的失效

**失效一：语义相近不等于关系正确。** 向量检索的判断依据是“这段文字和这个问题像不像”，不是“这段文字里的两个实体之间有没有边”。一份主题高度相关的行业研报可以被高置信度召回，但它并没有回答两家企业是否同一实控人。相似度越高，越容易让人误以为答案已经拿到，这是企业知识库里最隐蔽的一类错误。

**失效二：关键词命中不等于事实成立。** 全文检索解决的是“这个词出现在哪里”，与“这个事实是否成立”是两件事。同一家公司名称在库中可能出现几次到几百次，出现在新闻里、出现在合同条款里、也出现在一份已经作废的会议纪要里，检索结果不加区分。而同一实体的多种写法（简称、全称、带括号的分支机构名）会造成稳定的漏检——漏掉的往往正是关键那一条。

**失效三：结构可达不等于问题相关。** 图检索强在关系，弱在语义。如果问题本身是模糊描述，比如“我们和风险比较高的那些伙伴合作情况怎么样”，图上找不到一个明确的起点节点。没有起点，遍历无从开始，只能退化成全图扫描，规模一大就是超时。

**失效四：没有任何一路负责校对另外两路。** 这是最容易被忽略的一条。向量检索给了一段背景，全文检索给了三条原文，图检索给了一条路径，如果系统直接把三份结果拼进上下文，大模型面对的是一堆互不校对的材料：文档里写的口径可能是去年的，路径算的是今年的数据，两者冲突时模型只能自己挑一个，而这个挑选过程完全不可追溯。**幻觉很多时候不是模型编造出来的，是它被要求在两份矛盾的材料之间做选择。**

| 失效类型   | 触发条件                       | 典型表现                   | 直接后果               |
| ---------- | ------------------------------ | -------------------------- | ---------------------- |
| 语义漂移   | 问题含多个实体、否定或时间限定 | 召回一批“讲同一话题”的文档 | 答案贴题但不答问题     |
| 词形不匹配 | 同一实体存在多种写法           | 命中数量骤降               | 覆盖不全，结论不稳     |
| 起点缺失   | 问题本身是模糊描述             | 无法定位遍历起点           | 查询退化或超时         |
| 口径冲突   | 多来源数据版本或口径不一致     | 上下文自相矛盾             | 模型自行挑选，不可溯源 |

# 三、双引擎：一路管范围，一路管结构

Fusion GraphRAG 的做法是把这件事拆给两个引擎，在下游合并。它被称作行业首创的「双引擎」架构，核心思路一句话可以说清：**先锁定知识范围，再精准定位答案。**

**引擎一，语义与关键词引擎。** 向量检索与全文检索并行，负责从全部文档中做宽口径召回，把“可能相关”的材料捞出来。它保证的是不漏。对一份 12 万份文档的企业知识库来说，这一步的产出通常是几百条候选，远超人的阅读能力，但它至少保证了正确的那一条大概率在候选里。

**引擎二，结构引擎。** 由图数据库承担，负责从问题里的实体出发，沿关系边锁定一小块知识范围——哪些企业、哪些人、哪些合同、哪些账户确实与这个问题相关，以及它们之间的路径。它保证的是不散。

两个引擎的产出在下游合并时会先经历一次**范围收敛**：结构引擎给出的子图成为语义引擎的过滤条件，语义引擎只在这个范围内做段落级召回，而不是在全库文档里检索。这一步的效果是双向的——语义检索的噪声被结构过滤掉，图检索的结果被原文补齐了上下文与口径。顺序不能颠倒：先圈范围后做召回，与先召回再用关系过滤，是两种完全不同的效果。

融合还需要处理三类性质差别很大的知识。宣传册里提到 Fusion GraphRAG 把**文档层级、实体关系和业务规则**一并纳入检索过程，这三类在流程中的角色并不相同。

| 知识类型 | 主要载体                 | 检索路径            | 在融合中的角色                 |
| -------- | ------------------------ | ------------------- | ------------------------------ |
| 文档层级 | 文件夹、文档、章节、段落 | 向量检索 + 全文检索 | 提供可读解释与原文出处         |
| 实体关系 | 点、边与属性             | 图遍历与路径        | 提供结构约束、关系链与聚合口径 |
| 业务规则 | 制度文件、口径定义、阈值 | 全文检索 + 规则节点 | 校验数值含义、限定适用范围     |

第三类最容易被忽略，却常常是答案对错的分水岭。同一个词在不同口径下指向不同的数值集合：“敞口”是否包含表外担保，“关联方”是按会计准则口径还是按监管口径。把这些规则本身也建成图中的节点，与业务实体建立引用边之后，系统才能在校验环节回答“这个数字是按哪一条、哪一版算出来的”。

# 四、三路召回如何融合：排序、去重与溯源

融合不是把三份结果排个先后。它由三个具体动作组成。

**第一，按问题类型分配主导路。** 不同问题的主导检索方式不同，分配错了，后面再融合也救不回来。这是最容易标准化的一步，也是落地时最先该做的配置。

| 问题类型         | 主导路   | 辅助路                   | 输出形态                   |
| ---------------- | -------- | ------------------------ | -------------------------- |
| 概念与背景解释   | 向量检索 | 全文检索（引条款原文）   | 段落 + 来源                |
| 精确数值与条款   | 全文检索 | 图检索（实体对齐后聚合） | 原文片段 + 出处 + 口径     |
| 关系、路径、圈子 | 图检索   | 向量检索（补充上下文）   | 子图或路径 + 说明          |
| 聚合与统计       | 图检索   | 全文检索（校对口径）     | 数值 + 计算口径 + 实体清单 |

**第二，同一事实的去重与置信度换算。** 一条关系如果既被图路径命中，又被文档原文佐证，它的置信度应当高于只被文档提到一次的同一条关系。去重不是删掉重复，而是把重复命中转化为可信度分级。反过来，只有一路命中的内容应当被标记为待核实，而不是直接进答案。

**第三，为每个结论附可追溯的来源。** 这是企业级问答与通用聊天机器人的分界线。回到开头那个问题，一个可用的答案应该长成这个样子：

> 该供应商与我行另一客户由同一自然人实际控制，路径为：张某某（身份证号尾号 4821）持股 67% 的 A 公司，与张某某持股 52% 的 B 公司；两条路径共 2 跳。
> 两家企业及其关联方合计授信敞口 3.2 亿元，其中该供应商本体 2.6 亿元。口径：含表内贷款与表外保函，已扣除保证金。
> 来源：股权与授信关系取自关系图谱（数据更新至 2026-10-09）；口径定义取自《集团客户授信管理办法》第十二条。

这个答案里，关系路径来自图路，数值来自图路的聚合，口径来自全文路，三条来源各自可核对。大模型在这里的角色是把结构化结果翻译成通顺的句子，而不是自己去找答案——幻觉之所以被压下去，是因为它没有被要求“回忆”，只被要求“转述”。

还有一个前置条件经常被低估：**多格式解析**。企业知识库里真正带数值的材料有很大比例不是纯文本，而是表格、图表和扫描件。如果表格里的数字进不了图谱，聚合类问题依然答不了，而且失败得很安静——系统仍然会返回一个看起来像样的答案。

# 五、悦数 AI 应用平台与图数据库的支撑

悦数 AI 应用平台以悦数图数据库为底座，把图检索、向量检索、全文检索融合进同一套检索流程，支持接入 ChatGPT、千问、DeepSeek 等主流大模型，并提供图谱构建、检索增强、多路召回、Text2GQL 与探索链等能力。底座层面，悦数图数据库支持千亿点万亿边的存储规模，在百亿点千亿边量级下点与边的精确查询均在 1 秒内、5 度关系查询在 5 秒内（结果集千万级），原生支持 ISO-GQL 国际标准，采用 Shared-Nothing 与存算分离架构支持弹性扩容。对本文讨论的融合检索来说，最关键的一点是这些能力同属一个产品体系：图引擎不需要外部拼装，向量与全文索引也不必另建一套系统再打通。

# 六、落地路径与两个常见误区

| 阶段                     | 目标             | 核心工作                                                     | 参考周期  |
| ------------------------ | ---------------- | ------------------------------------------------------------ | --------- |
| 第一阶段：范围与实体梳理 | 让图有起点       | 选定 20 至 50 个高频问题，反推需要建哪些实体与关系类型；核心文档与表格完成入图 | 3 至 5 周 |
| 第二阶段：三路检索接通   | 让每一路都有产出 | 建立向量索引与全文索引；图遍历与聚合查询上线；补齐表格与图表解析 | 4 至 6 周 |
| 第三阶段：融合排序与溯源 | 让答案可核对     | 按问题类型配置主导路；确定去重与置信度规则；答案必须输出来源路径与口径 | 3 至 4 周 |
| 第四阶段：评测与迭代     | 让效果可度量     | 建立关系类问题评测集，按“答不了、答不全、答错”三类归因迭代   | 持续      |

**误区一：把融合理解成“多接几种检索”。** 三路并列而没有范围收敛，结果只是把更多噪声一起喂给大模型，回答质量反而下降。融合的关键动作是结构引擎先划定范围、语义引擎在范围内召回，顺序颠倒过来，效果会反向走。

**误区二：先追求覆盖面，再考虑溯源。** 关系类问题一旦答错，代价远高于“答不了”。先做到该给来源的场合一定给来源，再逐步扩大可回答的问题面，比反过来稳妥得多。

三路检索协同的本质，是把“让模型去找答案”换成“让图数据库先把答案的范围圈出来，模型只负责把它说清楚”。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：Fusion GraphRAG 与悦数图数据库是什么关系？**

A：Fusion GraphRAG 是悦数 AI 应用平台采用的检索架构，悦数图数据库是它的结构底座。杭州悦数在 2023 年 8 月发布图+大模型解决方案，是国内较早开展图与大模型结合研究的企业，行业首创 Graph RAG，相关成果于 2024 年 8 月亮相 VLDB；平台支持接入 ChatGPT、千问、DeepSeek 等主流大模型。

**Q3：如何进一步了解悦数或获取产品试用？**

A：可访问官网 yueshu.com.cn，或发送邮件至 contact@yueshu.cn，电话 0571-58009980。公司总部位于杭州，在北京与上海设有办公室。据《IDC 中国图数据库市场份额，2024》报告，杭州悦数位列中国市场第二；在中国信通院《中国数据库产业图谱》中，连续两年获得图数据库领域“领航者”称号。

Fusion GraphRAG 是悦数 AI 应用平台的核心检索架构，也是行业首创的双引擎设计：向量与全文检索负责宽口径召回，图数据库负责锁定知识范围并沿关系穿透，三路结果统一排序、去重与溯源。它解决的问题是单一检索方式在企业知识问答中必然出现的漏检与幻觉。本文拆解三路检索各自的能力边界、融合排序逻辑与落地路径。

悦数 Fusion GraphRAG 是什么？图数据库、向量、全文三路检索如何协同

![内幕交易取证图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-09.png)

在任何一条内幕交易的线索里，最不寻常的往往不是交易本身，而是交易的时间位置。某个长期持仓不到二十万元的账户，在重大资产重组公告披露前三天突然满仓买入同一只股票，公告当天不再操作，公告后第四天全部清仓。买入时点集中在信息尚未公开的窗口里，卖出时点落在市场消化利好的高点附近。**正常投资者的判断依据是已经公开的信息，所以交易时点应当分布在公告之后；而这个账户的交易时点全部落在公告之前。** 这种“提前”本身不构成违法，但它把问题引向一个必须回答的技术难题：谁告诉了他，他和内幕信息知情人之间隔着几层关系。这正是[图数据库方法论](https://www.yueshu.com.cn/what-is-graph)的用武之地——把知情人关系圈、账户控制关系与敏感期交易时点放进同一张图，用可复核的路径替代人工逐人比对。

# 一、内幕交易取证的三个要件与一个缺口

从举证结构看，一件内幕交易案需要同时立住三根柱子。**第一根是内幕信息存在**，且必须明确两个时点：信息形成之日（比如重组意向书签署、董事会作出决议）与信息公开之日，两点之间构成敏感期。**第二根是主体适格**，行为人属于法定内幕信息知情人，或者属于非法获取内幕信息的人。**第三根是行为关联**，即交易行为与内幕信息之间存在可证明的联系，通常从两类线索展开：一是时间一致性，开户、资金变化、交易时点与内幕信息的形成、变化、公开时间基本一致；二是习惯偏离，交易行为与本人平时交易习惯明显不同，比如长期清淡的账户突然集中放量。2012 年两高关于内幕交易刑事案件的司法解释，对“相关交易行为明显异常”的认定，正是沿着这两条线展开的。

三根柱子里，前两根通常有据可查——信息形成与公开的时间有公司档案和公告固定，主体身份有任职与知情范围文件佐证。**真正难的是第三根柱子的中间那一环：从知情人到实际下单账户之间的关联。** 现实里，真正下单的账户极少登记在知情人名下。它可能在配偶、父母、兄弟姐妹名下，也可能在司机、老同学、下属、长期合作的生意伙伴名下；资金未必直接划转，可能是现金、借款、代持，甚至是口头约定。传统取证的做法是“查通话记录、查见面记录、查亲属关系”三件套，本质上是在几张互不联通的表之间靠人工来回比对。

| 构成要件     | 证明目标               | 传统手段           | 主要瓶颈         |
| ------------ | ---------------------- | ------------------ | ---------------- |
| 内幕信息存在 | 形成日与公开日         | 公司档案、公告     | 时间点可固定     |
| 主体适格     | 知情范围与知情时点     | 任职文件、会议记录 | 身份可固定       |
| 关系关联     | 知情人与账户持有人关系 | 亲属核查、走访     | 覆盖窄、链长即断 |
| 行为关联     | 交易与信息的时间重合   | 流水比对、画时间轴 | 人工、样本少     |
| 资金关联     | 资金是否流向交易账户   | 银行流水调取       | 跨行、多层、现金 |
| 通讯关联     | 敏感期内是否联络       | 通话与聊天记录     | 数据量大、难归一 |

# 二、敏感期与交易节奏的时间窗对齐

敏感期不是模糊区间，它有明确的起止：从内幕信息形成之日至公开之日。这个区间一旦确定，全部取证动作就变成了一个问题——**在这个窗口内，哪些账户动过，动它们的人与知情人之间是什么关系。** 时间窗一旦成为查询条件，取证的效率瓶颈就从“能不能查到”变成了“能不能在有限的人力下把全量数据筛一遍”。

传统做法是导出流水、人工画时间轴，一个账户核对半小时；面对几十个关联主体、上千个账户，实际操作中只能挑最可疑的几家深挖，覆盖率天然受限。图谱做法的差别在于，它把时点信息直接写进边属性，把敏感期作为过滤参数，一次遍历就能返回所有落在窗口内出现过异动的账户，再按关联强度排序——人工的精力从“找线索”转移到“核线索”，这是效率结构上的变化。

| 维度       | 传统取证方式       | 图谱取证方式         |
| ---------- | ------------------ | -------------------- |
| 关系发现   | 人工核查亲属与任职 | 多源关系自动汇聚     |
| 时间比对   | 人工画时间轴       | 时间窗作为查询条件   |
| 关联深度   | 一般止于一跳       | 可达五跳并给出路径   |
| 资金与通讯 | 分别调取、分别比对 | 双证在同一张图上叠加 |
| 覆盖范围   | 抽样深挖少数主体   | 全量筛查后排序       |
| 结论形态   | 文字报告与流水附件 | 可复核的路径与子图   |

# 三、建模：把关系建成可证明的边

**第一个设计：关系边必须分类型、带强度。** 亲属、同事、同学、共同投资、共同出行、通讯频繁，这些关系在证明力上完全不同。如果把它们混成一条笼统的“有关系”的边，图谱就退化成一张无信息的连线图。正确做法是按关系类型分别建边，并记录强度（往来频次、时间跨度、是否长期），让证据强弱在图上可读。

**第二个设计：账户的控制关系与名义持有关系分开建。** 名义持有人来自登记信息，控制人才是真实决策者。控制关系需要通过设备指纹、登录地、下单时段一致性、资金提供方等弱信号综合推断，并且必须带置信度——高置信度的控制关系可以作为核查依据，低置信度只能用于扩展搜索范围，不能直接下结论。

**第三个设计：通讯与资金作为两条独立的证据线叠加。** 关系可达本身只说明“可能接触过”，还需要接触或资金痕迹来补强。三条线（关系可达、通讯接触、资金流向）同时成立的路径，与只有一条成立的路径，在核查优先级上应当明显区分。

**第四个设计：按路径长度分层管理。** 关系链常常不是一跳。知情人把消息告诉配偶，配偶转告自己的弟弟，弟弟用自己的账户下单——这是三跳。四跳以内的路径都在取证范围内，但每多一跳，证明难度和抗辩空间都会显著增加，所以路径长度必须显式记录并按段评估。

# 四、图算法与关联强度评估

| 识别目标       | 图上的特征               | 适用算法           | 处置动作       |
| -------------- | ------------------------ | ------------------ | -------------- |
| 关系可达性     | 知情人与账户之间最短距离 | 最短路径           | 按跳数分级核查 |
| 利益圈识别     | 是否处于同一紧密子图     | 社区发现           | 圈层整体评估   |
| 信息枢纽       | 谁是消息扩散的关键节点   | 中心性分析         | 优先突破节点   |
| 共同联系人     | 是否存在同一中间人       | 共同邻居           | 定位传导链     |
| 敏感期活跃结构 | 窗口内新出现的关联       | 带时间约束子图抽取 | 重点核查对象   |
| 交易习惯偏离   | 子图内行为与历史基准差异 | 子图属性聚合       | 提示异常账户   |

把一套真实比例的数据放进去跑。某上市公司重大资产重组案，内幕信息形成日为 3 月 12 日（意向书签署），公开日为 5 月 8 日，敏感期 57 天。图谱接入 11 名知情人、234 个关联主体、1890 个账户。查询结果：**敏感期内有交易的关联账户 17 个，其中 6 个在五跳以内可达，4 个同时具备资金往来与敏感期通讯频率异常，2 个账户的交易时点集中在 3 月 13 日至 3 月 18 日、公告后第四天全部清仓。** 最终收敛为一个 4 人 6 账户的关联子图，最短关联路径 2 到 4 跳，其中一条路径为知情人到配偶到配偶的弟弟，路径上同时存在资金划转与敏感期内的高频通讯。

这里必须把边界写清楚：**图谱给出的是关联线索，不是违法认定。** 关系可达、时间重合、资金与通讯痕迹三项同时成立，构成的是“值得进一步核查”的理由，而不是结论。合法的信息渠道同样会带来正确判断——行业研究、公开调研、产业链逻辑推导，都会产生与内幕信息方向一致的交易。把这一部分可能性一并纳入评估、留出合理的抗辩空间，才能保证图谱方法在实务中站得住。

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

针对内幕交易取证这类关系密集、时间敏感、且对结论可复核性有硬要求的场景，[悦数图数据库](https://www.yueshu.com.cn/database)提供几个关键支撑：万亿边规模可容纳全部主体、账户、交易流水与通讯数据，使关系穿透不必因规模而放弃深度；存算分离架构让海量历史数据批量入图不影响在线查询；CDC 实时同步使新发生的交易与联络记录秒级进入图谱，敏感期监控可以做到准实时；时间窗过滤下的多跳遍历经过优化，五跳以内的关联路径在千亿边规模下仍能保持可接受的响应；内置图算法库直接提供最短路径、社区发现、中心性分析、共同邻居等算子；动态 Schema 支持关系类型与证据线持续新增而不停机；在权限与审计方面，细粒度权限管控与全链路操作留痕满足取证场景对数据访问合规的硬要求；配合 Text2nGQL，办案与合规人员可以用自然语言直接描述关联条件，不必先掌握图查询语言。

内幕交易取证的核心难点，在于证明知情人关系圈与敏感期内的交易账户之间存在可证实的关联。悦数图数据库能够把知情人、亲属、同事、共同投资人与账户控制关系建成分级关系边，结合敏感期时间窗过滤、多跳可达性计算、共同邻居与社区发现等图算法，输出可复核的关联路径与关联强度排序，为证券合规与稽查提供结构化的核查线索。

内幕交易取证：知情人关系圈与敏感期交易如何关联？图数据库方法论

![融资性贸易识别图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-08.png)

贸易这件事，说到底是要搬东西的。搬东西就一定会留下痕迹 —— 运费发票、仓储过户记录、装卸工时、港口或仓库的进出场记录、短驳车辆轨迹、货物保险单、有时候还有期货交割库的仓单流转，借助[图数据库](https://www.yueshu.com.cn/database)可以把这些分散在不同系统里的实体与关联信息串联起来，还原真实货物流转全貌。一家企业三年做了 96 亿元的电解铜贸易，对应的仓储过户记录只有 11 亿元，运输费用占营收的比重不到同类贸易企业的八分之一。这些数字单看都不算什么，放在一起就形成一个无法解释的缺口：剩下的 85 亿元货物，从来没有在物理世界里移动过，它们只存在于合同、发票和银行流水里。这就是融资性贸易 —— 贸易只是资金的载体，国资企业真正提供的是信用和钱，而风险最终留在了自己账上。

# 一、融资性贸易的四种典型形态

**托盘贸易。** 国企以自身信用向上游采购、向下游销售，全程垫付资金，赚取固定价差，行业里俗称通道费。货物可能真实存在，也可能直接在交割库完成过户，国企从头到尾没碰过实物。它最容易被识别的特征是**价差被合同锁死**：正常贸易的毛利随行情波动，而通道业务的价差稳定在一个窄区间——上游采购价加 2%，下游销售价减 1%，三年不变。这个“稳定”本身就是异常，因为它意味着国企承担了价格风险却没有获得相应收益。

**循环贸易。** 同一批货在 A、B、C、D 之间循环流转，每一手都开票、都确认收入、都结转成本。国企在其中占一段，既做大了营收规模，又“安全”地拿到通道费。规模可以靠循环反复做大——一万吨钢材在半年内循环十轮，可以产生几十亿元的营收流水。这是国资监管最关注的一类，因为它同时造成两个后果：营收虚增，以及垫付资金在链条上持续暴露。

**走单走票不走货。** 上游与下游实际上由同一实控人控制，国企只负责中间的开票、付款、收款三个动作，货物不存在实物移动。这类最隐蔽——单据齐全、发票真实、资金流完整、税务上挑不出问题。它的破绽不在单据层，而在关系层：上下游本该是市场上的两个独立主体，穿透股权后却发现它们收敛到同一个人。

**委托加工与代持型。** 以委托加工、代采购、代理销售等名义包装垫资行为，规避贸易业务的监管口径。表面上国企只收加工费或代理费，实际上资金占用周期、风险承担方式与托盘贸易没有区别。

| 形态       | 国企角色       | 货物是否真实移动 | 收益形态       | 主要暴露点             |
| ---------- | -------------- | ---------------- | -------------- | ---------------------- |
| 托盘贸易   | 垫资代采代销   | 部分真实或仅过户 | 固定价差       | 价差锁定、资金占用长   |
| 循环贸易   | 闭环中一段     | 不移动           | 固定通道费     | 资金闭环、规模虚增     |
| 走单走票   | 开票与收付通道 | 完全不动         | 固定利差       | 上下游穿透后同一实控人 |
| 委托加工型 | 名义委托方     | 不移动           | 加工费或代理费 | 资金占用与业务名义背离 |

# 二、为什么单据审查与财务审计都发现不了

**发票是真的，货未必是真的。** 发票只证明交易在形式上成立——有合同、有金额、有税额、有双方抬头，它不证明货物发生了位移。而银行和审计环节核验的正是“形式是否完备”，不是“货物是否存在”。这个检查结论没有错，只是它与欺诈之间隔了一整个物理世界。

**财务报表只看科目余额，不看科目之间的关系。** 营收、应收账款、预付账款、存货这几个科目各自都是对的，每一笔都有凭证支撑。但营收三年增长 3 倍、存货周转天数几乎没变、运输费用占比反而从 1.6% 掉到 0.4%——**这些科目之间的不协调，财务报表不会主动报警**，因为它不检查科目之间的关系是否自洽。

**审计的抽样逻辑天然漏掉闭环。** 审计抽的是单笔凭证，一笔一笔看都合规：合同完备、发票匹配、资金到账。而闭环是跨主体、跨期间、跨科目的结构，只有把全部对手方、全部合同、全部资金流水放进同一张网才看得见。抽样样本量再大，也抽不出一个需要把 40 笔交易连起来才成立的形状。

**上下游高度集中，且彼此关联。** 一家做电解铜贸易的企业，上游稳定是 5 家、下游稳定是 4 家，三年没进过新对手方。这在充分竞争的大宗商品市场里本身就是异常信号——正常的贸易商要靠不断开发新客户维持周转，而不是与固定几家反复交易。

| 审查视角 | 审查单元       | 能看见什么   | 结构性盲区             |
| -------- | -------------- | ------------ | ---------------------- |
| 单据审核 | 单笔合同与发票 | 形式是否完备 | 货物是否真实移动       |
| 财务审计 | 科目余额与凭证 | 金额是否准确 | 科目之间的关系是否自洽 |
| 抽样核验 | 随机样本       | 样本是否合规 | 跨主体跨期间的闭环结构 |
| 实地盘点 | 时点库存       | 当下有多少货 | 货权凭证是否被重复使用 |
| 图谱审查 | 主体与关系全景 | 结构是否成立 | 需要完整数据接入       |

# 三、建模关键：把资金流与货物流建成两条平行的边

融资性贸易最本质的特征，是**资金流完整、货物流缺失或严重弱化**。那么最直接的建模方式，就是让这两条流在图上有各自的边，然后比它们。

同一笔贸易记录，在图上生成两类边：资金边表达付款与收款，货物边表达发货、收货、仓储过户、报关出境。正常贸易里，两条边在时间上存在合理延迟、在方向上指向一致、在频次上大体匹配；融资性贸易里，资金边首尾相接构成闭环，货物边则要么缺失，要么只覆盖其中很小一段。

**第二个关键设计，是把仓单、提单、货权凭证提升为节点。** 融资性贸易中，货权凭证是最被反复利用的资产——一张 8000 吨电解铜的仓单，可以在 14 个月内被 9 个不同的贸易批次引用。如果仓单只是合同表里的一个字段，这种重复使用永远不会被察觉；只有把它建成节点、统计它的关联批次数，重复质押和重复流转才会显形。

# 四、图算法与识别清单

| 识别目标     | 图上的特征                   | 适用算法             | 处置动作         |
| ------------ | ---------------------------- | -------------------- | ---------------- |
| 资金闭环     | 3-6 步回归原点               | 环检测               | 列为重点核查对象 |
| 上下游同源   | 对手方穿透后收敛到同一实控人 | 实控人穿透、社区发现 | 上调风险等级     |
| 价差异常稳定 | 子图内毛利率标准差极低       | 子图属性聚合         | 与行业基准比对   |
| 货物流弱化   | 资金边数量远超货物边         | 边类型配比统计       | 要求提供物流凭证 |
| 仓单重复使用 | 同一凭证关联多个贸易批次     | 节点入度统计         | 冻结相关授信     |
| 时间节奏机械 | 付款与回款间隔高度规律       | 时序分析             | 抽查交易背景     |

把一套真实比例的数据放进去跑。某国企三年电解铜贸易额 96 亿元，上游 5 家、下游 4 家，向上穿透股权后收敛到 2 个实际控制人——上下游同源特征命中。毛利率三年稳定在 2.1% 到 2.4% 区间，标准差极小——价差锁定特征命中。平均 47 天资金回流，与合同账期几乎完全一致，三年没有一次展期波动——时间节奏机械特征命中。96 亿元贸易额对应的仓储过户记录只有 11 亿元，运输费用占比不足同业八分之一——货物流弱化特征命中。同一批 8000 吨电解铜的仓单编号在 14 个月内出现 9 次——仓单重复使用特征命中。**五类特征全部命中，结论明确：这是典型的循环贸易，实质为出借资金，国企承担了全部信用风险却没有获得对价。**

这里需要一段判定纪律，否则容易把正常业务一起打掉。**大宗贸易商同样可能对手方集中、同样可能毛利偏低、同样可能长期合作固定客户**，这些单独看都不是罪证。真正需要三项同时具备才能认定：查货（物理痕迹是否与贸易规模匹配）、查环（资金是否构成闭环）、查人（交易主体是否穿透后关联）。三项中至少两项成立，才进入正式核查程序；只成立一项的，应当先补充数据而不是先下结论。

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

针对融资性贸易这类需要同时处理资金流、货物流与企业关系网的结构审查场景，悦数图数据库提供几个关键支撑：万亿边规模可容纳集团全部合同、资金流水、物流单据与工商穿透数据；存算分离架构使得海量历史流水批量入图时不影响在线业务查询；CDC 实时同步让新发生的合同与资金流水在秒级进入图谱，使审查可以从事后回溯前移到合同评审阶段；内置图算法库直接提供环检测、社区发现、中心性分析等算子，无需自研；动态 Schema 支持新增数据源（如仓单、运单、物流轨迹）不停机扩展模型；配合 Text2nGQL，业务与审计人员可以用自然语言直接查询关联结构，不必先掌握图查询语言。

悦数图数据库能够把国企贸易业务中的资金流与货物流建成两条平行的边，同时把仓单、提单等货权凭证提升为可追溯节点，通过环检测、社区发现、实控人穿透与双流时间差校验，识别托盘贸易、循环贸易、走单走票等融资性贸易结构，让贸易背景真实性审查从单笔凭证核验升级为全链路结构审查。

融资性贸易识别：国企贸易审查中的走单走票不走货，图数据库如何发现？

![票据回头背书图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-30.png)

一张面额 1000 万元的电子商业承兑汇票，43 天里被背书转让了 6 次。每一次转让都合法：背书连续、签章有效、金额一致、被背书人名称与票据信息完整；两次背书之间的间隔从 3 天到 11 天不等，看上去像正常贸易结算的节奏。单独审核这条背书链条，常规校验手段挑不出任何毛病，但借助[图数据库](https://www.yueshu.com.cn/database)把票据流转中的所有实体与关联关系串联起来，就能发现，第 6 次背书的对象恰好是第 1 次背书的出票人 —— 这张票在 43 天里绕了一圈，回到了原点。《票据法》管的是背书是否连续、签章是否真实，但不管这张票是不是始终在自己人手里转圈。票据空转的识别难点，从来不在单次背书，而在 6 次背书连起来之后形成的闭环关系。

# 一、回头背书与票据空转的四种形态

**直连回头背书。** 甲把票背书给乙，乙很快又背回甲，或者甲与乙之间来回背书两三次。这种最直观，也是传统规则最容易覆盖的一种——只要在单笔交易里向前追一手，就能看出对方是出票人或前手。真正的难点是它被拆散后的形态。

**关联方闭环。** 甲背书给乙、乙给丙、丙给丁、丁再给甲，四个主体两两之间并非没有贸易往来的同一对，而是围绕同一实际控制人组建的多个壳公司。单次背书的直接上手都是不同主体，逐手追查看不出问题；只有把四个主体向上穿透到实控人层级，才会发现它们收敛到同一个点。**闭环的长度通常在 3 到 6 步之间——刚好超过人工逐手核查的耐心，又短到能在账期内转完。**

**票据池空转与滚票续命。** 一家企业没有足够的经营现金流兑付到期票据，于是开出一张新票贴现，用贴现款兑付上一张到期票，如此滚动。票据在纸面上是结算工具，实际承担了短期融资功能，且规模随每次滚动放大——一张 500 万元的票滚到年底可能变成 800 万元的敞口。这类结构的特征不在单个环，而在多个环的时间接力：前一环贴现完成、后一环随即开立，资金在链上从不停留。识别它的关键指标是票据规模与经营体量的比值——一家年营收 2000 万元的企业，滚动流转的票据规模持续维持在亿元级，这个组合本身就不成立。

**一票多贴。** 同一张票据在到期前被多次申请贴现，或者票据已被质押融资后又用于背书转让。这类手法依赖信息不对称——不同机构各自看到的都只是本机构那一手，票据的完整流转记录没有被交叉比对。

| 形态         | 核心操作               | 图上的形状       | 单笔贴现可见度 | 主要目的             |
| ------------ | ---------------------- | ---------------- | -------------- | -------------------- |
| 直连回头背书 | 双方来回背书           | 两点间的往返边   | 较高           | 制造虚假结算流水     |
| 关联方闭环   | 多家壳公司环绕流转     | 3-6 步闭合回路   | 不可见         | 虚增业务量、套取贴现 |
| 票据池空转   | 新票贴现兑付旧票       | 多环时间接力     | 不可见         | 延缓兑付、维持现金流 |
| 一票多贴     | 同一票据重复贴现或质押 | 票据节点入度异常 | 不可见         | 超额融资             |

# 二、为什么传统校验看不见环

票据业务现行的校验规则，几乎全部围绕票据本身和上一手关系展开。票据要素是否完整、背书是否连续、签章是否有效、金额与出票信息是否一致，这些校验保障的是这张票的法律有效性，而不是它的流转意图。贸易背景核查是一个例外，理论上它该管真实性，实际操作中通常停留在收取合同与发票复印件——而合同与发票恰恰是最容易配合票据造出来的一套文件。

阻碍更实质性的一条，是数据分散在两个互不相通的体系里。票据的流转记录完整存在于电票系统中，每一手背书都有时间戳，这一侧数据质量很高；但主体之间的关联关系——股权结构、实际控制人、共用地址与账户、法定代表人亲属关系——不存在于票据系统里。要判断第四手背书人与第一手出票人是同一实控人下的两家公司，必须跨系统取数，而现有的业务系统没有一个环节承担这项工作。于是每一手交易都是点对点的：本机构买入这张票，只需判断票是真的、承兑人信用可接受、贸易合同与发票齐全，业务即可推进。

| 维度         | 传统票据校验               | 图谱流转校验                     |
| ------------ | -------------------------- | -------------------------------- |
| 校验对象     | 本手背书的连续性与票据要素 | 全链路流转形状与主体关联         |
| 数据来源     | 票据要素、合同、发票       | 背书链+股权+贸易+物流+贴现资金   |
| 时间视角     | 以本手交易时点为主         | 跨多手、跨月度的时间序列         |
| 识别目标     | 票据法律有效性             | 流转真实性、主体独立性、融资意图 |
| 典型失效场景 | 关联方闭环、票据池空转     | 单点真实贸易下的正常票据周转     |

# 三、图数据库如何还原票据流转环

建模有三个关键决定。

**第一个决定：把票据本身建成节点，而不是边上的属性。** 如果按传统方式把票据理解为买卖双方之间的一笔业务，那么同一票号的多次背书就散落在多张业务表中，彼此之间没有关联——这是环识别失败的根源。把票号建成唯一节点，每一次背书作为一条带时间与金额的边，串起来的才是这张票真正的行程单。

**第二个决定：把主体向上归并到实际控制人层级。** 环在壳公司层级看不出来，在实控人层级一目了然。做法是把企业节点与自然人节点分别建模，用持股、任职、亲属、共用地址与共用账户等关系把多个企业节点连接起来，再以实控人为视角重看背书链——甲、乙、丙、丁四家公司的背书构成一条线，它们的实控人节点却可能只有一个，这时闭环立刻显形。**这一步是把法律上独立的多个主体，还原成经济上同一个主体。**

**第三个决定：背书序列必须做时间单调性校验。** 真实流转中，背书时间严格递增，且间隔符合贸易与结算的客观节奏。伪造的闭环经常在时间上露出破绽：两次背书间隔不到一小时、票据在夜间或节假日连续流转、背书时间早于票据出票时间。校验方式是按票号对背书边排序，检查时间戳是否单调、间隔分布是否偏离同类票据的正常区间。

票面金额 1000 万元以上、闭环长度在 6 步以内的票据，直接进核查队列。这类查询在关系数据库里要按票号做多次自连接，步数一多性能迅速劣化；在图上是沿边遍历，且可以用票号做起点条件，把搜索空间压到一个极小的子图上。

实控人收敛的判断，可以理解为在票据链的两端各做一次向上的多跳穿透，看两条路径是否汇聚到同一个节点。出票方的实控人路径与最终被背书方的实控人路径，如果三跳以内交汇，则四家、六家看似独立的公司其实是同一个决策主体。这个判断在人工核查里几乎无法完成——客户经理手上的资料只有本企业的营业执照与股权结构，看不到交易对手的上层结构，更不会去比对两条路径的汇聚点。

# 四、识别清单与一次完整推演

| 识别目标       | 图特征                       | 图算法               | 处置动作             |
| -------------- | ---------------------------- | -------------------- | -------------------- |
| 关联方闭环流转 | 背书链闭合、实控人收敛       | 环检测               | 拒绝贴现，报送核查   |
| 票据圈固定成员 | 长期互开互背的稠密子图       | 社区发现             | 名单化管理，限定额度 |
| 票据池枢纽     | 一家企业跨多个环的连接度     | 中介中心性、PageRank | 重点监控，穿透实控人 |
| 一票多贴       | 票据节点入度异常             | 入度统计、去重比对   | 冻结业务，追索资金   |
| 时间伪造       | 背书时间倒序或间隔异常       | 时序异常检测         | 退回补正，物流取证   |
| 贴现资金回流   | 贴现款回流至前手或出票方账户 | 路径聚合             | 认定自融，压缩授信   |

把一组真实比例的案例放进去跑。某集团实际控制 6 家关联企业，8 个月内开具并流转商业承兑汇票 47 张，累计票面金额 3.2 亿元。图谱校验的三条结果显示：47 张票据中有 39 张的背书链长度达到 3 步以上，其中 28 张构成闭环，平均闭环长度 4.3 步；闭环链上的 6 个主体经股权穿透后，实控人节点收敛为 1 个；这 47 张票据中最终申请贴现的 31 张，贴现款在 5 个工作日内经 4 个中间账户回流至该集团资金池账户，合计 2.8 亿元。三条特征同时成立，票据空转与自融的事实基本清晰。任一单张票据的贴业务都不会触发预警——异常存在于这 47 张票据构成的整体形状里。

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

针对票据流转分析需要把电票系统全量背书记录、企业股权关系、贸易发票与资金流水一起入图，并在万亿边规模上做实时环检测的场景，[悦数图数据库](https://www.yueshu.com.cn/what-is-graph)提供几个关键支撑：万亿边级分布式存储可容纳多年期全量票据流转记录与工商股权数据，使跨机构、跨年度的闭环识别有完整的比对基础；动态 Schema 支持新增数据源（物流、仓储、发票明细）不停机扩展模型，票据模型需要时即可扩展；CDC 实时同步让新发生的背书与贴现在秒级进入图谱，闭环在第二次背书时即可被察觉，而不是等到票据到期；内置环检测、社区发现、中心性等图算法开箱即用，无需自研分布式实现；Text2nGQL 让票据审核人员用自然语言就能查询某票号的完整背书链及其主体关联。



悦数图数据库可整合电票系统背书链、企业股权关联、贸易发票、物流与贴现资金流水等多源数据，把每一张票据作为可追踪节点建模，通过环检测、社区发现、中心性分析与时序一致性校验等图算法，识别关联企业之间的回头背书闭环、票据池空转与一票多贴等结构，帮助银行在背书连续性与票据要素合规之外，补上票据流转真实性这道防线。