![设备排障图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-11-04.png)

手册翻到第 47 页，上面写着「可能原因：供电异常、主板故障、通讯线松动」。三个人围着机柜站了十分钟，谁也没动手。不是不会修，是这页纸给的是三选一，而现场要的是先测哪一个——测供电得拆外壳，测主板得停机，看一眼通讯线只要三十秒。三个动作的代价差着量级，能排除的可能也差着量级。文档检索能答「可能是什么」，答不了「先做什么」，而设备故障排查知识问答的成败，恰恰落在后一半——这也正是[图数据库](https://www.yueshu.com.cn/database)在这类场景里的位置：它存的不是答案，是判断下一步所需要的那些关系。

这篇讲四件事：普通检索在排障上为什么失灵，图里该放哪些点和边，多级智能体怎么分工，以及知识怎么才不至于三年就僵掉。

# 一、排障的终点是一个动作，不是一段文字

判断一套排障问答好不好，有个很粗糙但很准的测法：答完之后，用户还需不需要再问一次。

如果答案是「需要，我得再问它先测哪个」，那这套系统本质上还是个搜索框，只是换了一层皮。这不是模型不够强，是目标从一开始就定错了。文本问答的优化目标是相似度，给一段和问题最像的文字；排障的优化目标是信息增益，给一个做完之后能把候选空间砍掉一半的动作。两个目标不在同一个维度上，指标也就没法互相替代。

举个具体的差别。同一个现象「设备启动后无输出」，手册里列了七条可能原因，每条后面跟一段解释。一位干了五年的师傅会先看一眼风扇转不转——这个动作零成本，却能直接排除四条。这个判断在手册里找不到，因为它不算知识，算策略。策略从来不写在文档里。

这也解释了一个常见现象：同一台设备，老师傅十五分钟定位，新人两个小时还在换件。差的不是文档看得多少，是先做哪个的顺序。

# 二、普通 RAG 在排障上失灵的三层原因

多数团队的第一反应是把手册全部向量化，接个大模型上去。这条路在排障场景里大概率走不通，原因还不在召回率。

**第一层，故障知识是带条件的。** 同一个故障码，在 A 型号上要换部件，在 B 型号上刷一次固件就好。文档里这两段的措辞几乎一样，向量检索会把它们一起召回，模型看到两段都「很像」，于是给一个四平八稳的综合答案。可现场要的是确定的那一个——型号本来就是已知条件，不该被模糊掉。

**第二层，排障是有状态的。** 第二个动作取决于第一个动作的结果。单轮检索没有状态，用户每问一次都得把「我测过什么、结果是多少」重讲一遍，讲到第三轮自己都嫌烦。这不是体验问题，是多轮之后上下文被压缩，最关键的证据在压缩里丢了。

**第三层，最有价值的信息是排除。** 排障里最省时间的知识不是「是什么」，而是「不是什么」——这个点上午测过了、这条路径上个月走过一遍、这个部件是上批换的已经可以排除。这类信息在文档里根本不存在，因为它依赖这一台设备自己的历史。

三层叠起来，结论很清楚：要检索的不是段落，是故障模式到处置工序的映射。映射是结构，结构装不进向量空间。这也是为什么单靠 RAG 补不上这块，[为什么说没有图数据库的 RAG 是不完整的](/posts/graph-database-rag) 从检索链路的角度谈过同一件事，本篇落在排障这一个切面上。

# 三、图里放什么：五类点、六类边

排障知识的骨架其实很稳定，无论行业是电力、机床还是通信设备，拆下来都是下面这几类对象。

| 点类型   | 承载什么                     | 缺了会怎样                         |
| -------- | ---------------------------- | ---------------------------------- |
| 设备型号 | 型号、批次、固件版本         | 同一现象在不同型号上给出同一个答案 |
| 部件     | 可更换单元及其寿命、批次     | 换件建议落到总成一级，成本翻倍     |
| 现象     | 故障码、报警文本、可测量项   | 用户的口语描述无法归一到可查的键   |
| 工序     | 一个具体的检测或处置动作     | 只能回答原因，回答不了动作         |
| 证据     | 测量值、已测项、历史工单结论 | 排除逻辑无处落脚，每次从零开始     |

边比点更要紧，因为排障的判断几乎都发生在边上。

| 边类型   | 语义                         | 举例                                    |
| -------- | ---------------------------- | --------------------------------------- |
| 装配     | 型号包含哪些部件             | 型号 X 含电源模块、主控板、通讯板       |
| 疑似由   | 现象可能指向哪个部件         | 无输出 → 电源模块 / 主控板              |
| 对应处置 | 部件对应哪些工序             | 电源模块 → 测输出电压、测输入电压、替换 |
| 前置条件 | 这道工序要成立，先得满足什么 | 更换主控板 ← 供电输出正常               |
| 排除     | 做完这道工序能排除哪个现象   | 测输入电压正常 → 排除外部供电           |
| 顺序     | 工序之间的先后与依赖         | 先测输入，再测输出                      |

最容易漏的是「前置条件」这条边。工序不是无条件可做的——「更换主控板」必须先确认供电正常，否则换完还是报同一个错，白停机两小时，还多了一次拆装风险。这句话在手册里通常只是一行小字，在图里是一条边，能被校验环节拦住，也能被排序环节算进代价。

第二容易漏的是工序之间的顺序。有些动作做完能排除三种可能，有些动作做完什么也排除不了、纯粹耗时间。文档按「原因」组织，不按「动作」组织，所以这一层在原文里天然缺失，只能靠自己补。

# 四、多级智能体怎么分工：分诊、检索、校验

拆成三级不是为了显得架构复杂，是因为这三件事的输入输出格式本来就不一样，塞进一个提示词里必然互相干扰。

| 层级 | 职责                     | 输入                     | 输出                     | 拿不准时             |
| ---- | ------------------------ | ------------------------ | ------------------------ | -------------------- |
| 分诊 | 把口语描述归一成标准现象 | 「机器嗡嗡响，屏幕黑的」 | 现象编码 + 型号 + 已测项 | 反问一个可测量的项   |
| 检索 | 在图上锁定故障族与工序集 | 现象编码 + 型号          | 候选工序及各自代价       | 扩大一跳，标注不确定 |
| 校验 | 检查前置条件与已排除项   | 候选工序 + 证据状态      | 排序后的下一步建议       | 提示需要人工确认     |

第一个关键设计：级与级之间传结构化状态，不传自然语言。这是多级智能体最容易做错的地方。如果第一级把归一化结果写成一段话交给第二级，第二级再总结一遍交给第三级，到第三级时原始的可测量项已经丢了一半，输出又退化成一段泛泛的解释。分诊的输出应该是一组字段：现象编码、设备型号、已测项、测量值。字段可以被校验，自然语言不能。

第二个关键设计：每一级都要有说「不知道」的权力。分诊置信度低于阈值，就直接回问一句「指示灯是什么颜色」，不要硬猜一个故障族往下走。硬猜一次的代价是后两级全跑在错误分支上，用户拿到一整套像模像样、逻辑自洽、但完全不沾边的建议。这种失败比直接说不知道伤得重得多，因为它消耗的是信任。

第三个关键设计：校验环节的输出是带理由的排序，不是结论。「先测电源输出，这一步能排除四条」和「请更换主控板」是两种东西。给结论的系统没人敢照着做，给理由的系统才有人愿意信，也才有人能在它错的时候发现它错。这套「先锁范围再定位答案」的思路在通用智能问答里已经比较成熟，[动态知识引擎：Graph RAG 构建智能问答系统的实践](/posts/intelligent-question-answering) 有过完整拆解，排障只是把它推到了带动作的那一步。

# 五、「动态」在哪：知识得能长

静态图谱的宿命是装进去那天什么样子，三年后还是什么样子。可设备在老化、工艺在改、备件批次在换，手册的修订周期永远追不上现场。

动态排障的「动态」，指的是图能吸收现场跑出来的东西。

| 回写来源     | 触发时机             | 写回什么                                     | 治什么病             |
| ------------ | -------------------- | -------------------------------------------- | -------------------- |
| 工单闭环     | 工单关闭时           | 实际路径与最终定位件，作为新的顺序边         | 手册没写的经验顺序   |
| 备件更换记录 | 换件登记时           | 批次与故障的关联，同一批次集中报错可提前预警 | 批次性缺陷被当成偶发 |
| 反例记录     | 按建议执行但未解决时 | 该建议在本型号上的失效标记                   | 错误建议反复被推荐   |

第三类最容易被忽略，也最有价值。手册里只有「这样做能修好」，没有「这样做没修好」；而现场真正需要知道的是后一句。

回写要有节制。全量回写会让图里长出一堆只出现过一次的边，噪声盖过信号，跑出来的建议和随机排序差不多。可行的规则是同一路径重复出现若干次才固化为推荐，单次只作备注。这条规则看着保守，其实是在保护图的可信度——一张到处是偶然边的图，比一张小但干净的图更难用。

这条路已经有可参照的实践。2024 年 3 月，助力某研究所打造的行业方案「基于图和多级智能体的动态排障知识问答系统」，入选中国「大模型+知识管理」最佳实践案例 15 强。这个案例值得看的地方不在模型选型，而在于它把排障工序和工序的前置条件建成了图——这正是前两节说的那些边。

# 六、落地顺序与两个常见误区

顺序比技术选型重要。同样的组件，按不同顺序装，结果差很远。

1. **先统一现象字典。** 故障码、报警文本、口语描述对到同一套编码上。这一步通常占到整个项目一半的工作量，跳过去后面全废——因为检索的键都不一致，图建得再漂亮也查不出东西。
2. **选一条高频故障线做全。** 二十个现象、对应的工序、每条工序的前置条件，做实一条线。不要一开始全设备铺开，铺开的结局是每条线都浅。
3. **把前置条件逐条落成边，请老师傅过一遍。** 这一步没有捷径，只能靠人对。但它是全流程里唯一能把隐性经验显性化的环节。
4. **先只做「下一步建议」，不做自动执行。** 让人在旁边看一段时间，看建议被采纳的比例、被跳过时的原因。
5. **用三个月工单回测三个数。** 建议采纳率、首次定位耗时、误判率。三个数里误判率最要紧，它决定系统会不会在第二个月被现场关掉。

两个误区值得单独说。

**误区一：先把手册全部向量化。** 手册是写给人读的，进图要做的是把它拆成工序。一本三百页的手册，拆完大概是两三百条工序，每条带两三个前置条件。这个工作量不小，但它是唯一产生效果的那部分工作；向量化本身只解决了「找得到」，而找得到从来不是排障的瓶颈。

**误区二：把多级智能体理解成多个模型投票。** 不是一回事。投票的前提是各方独立判断同一件事；多级分工是各方判断不同的事，连输出格式都不一样。做成投票，等于把三次推理压成一次平均，什么也没多出来，还多了三倍成本。

排障问答的难度不在模型，在于愿不愿意把「先做哪个」这件事从老师傅脑子里搬到图上来。搬过来了，问答才有终点；搬不过来，再强的模型也只是把手册念得更流畅一点。

**相关阅读**

- [行业首创 Graph RAG：基于知识图谱的检索增强技术与优势对比](/posts/graph-rag)
- [知识图谱推理方法概述](/posts/knowledge-graph-inference-methods)
- [悦数图数据库发布 AI 大模型解决方案，开启「图 + 大模型」应用新范式](/posts/graph-ai-llm)
- [图 + AI 在金融行业的应用及技术前瞻](/posts/graph-database-with-ai-technology)

# 常见问题（FAQ）

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

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边规模的关系数据存储与查询。产品内置图算法库与原生 GraphRAG 能力，图检索、向量检索、全文检索在引擎层融合，可支撑设备排障这类需要「关系 + 条件 + 时序」共同成立的问答场景。

**Q2：排障问答一定要上多级智能体吗？单级模型行不行？**

A：取决于问题里有没有状态。如果场景是「这个故障码什么意思」这类单轮查询，单级模型加检索完全够用，上多级是浪费。但只要出现三种情况之一，单级就会明显吃力：一是需要根据上一次结果决定下一步，二是需要在多个高度相似的候选里按型号、批次做区分，三是答案必须带排除逻辑。这三种情况本质上都需要在两次推理之间保存结构化状态，而单级模型的上下文压缩保不住这些字段。

**Q3：悦数图数据库在大模型与知识管理方向有哪些落地成果？**

A：2024 年 3 月，助力某研究所打造的行业方案「基于图和多级智能体的动态排障知识问答系统」入选中国「大模型+知识管理」最佳实践案例 15 强；2024 年 8 月，悦数 Graph RAG 相关研究亮相 VLDB。产品侧，悦数 AI 应用平台以图数据库与知识图谱为底座，通过 Fusion GraphRAG 把文档层级、实体关系与业务规则纳入检索过程，提供图谱构建、多路召回、Text2GQL 与探索链等能力，并支持接入 DeepSeek 等主流大模型。

排障问答该给的答案不是一段可能原因，而是下一个动作。文档检索解决得了找得到，解决不了先做哪个——因为故障模式到处置工序之间是带条件的结构，不是文本相似度。图数据库把前置条件、排除关系、工序顺序落成边，多级智能体分工做分诊、检索、校验，候选清单才变得出动作建议。附五类点、六类边的建模清单与五步落地顺序。

设备故障排查知识问答怎么落地？图数据库加多级智能体的实践路径

![地理空间图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-11-03.png)

选址报告的第一页写着：候选点位三公里内常住人口十二万。三个备选点位，数字都在十一万到十三万之间，看上去差别不大，评审会上没人多问一句。后来有人在地图上量了一下——其中一个点位和那十二万人之间隔着一条江，最近的桥在三公里外，绕过去七公里。半径是几何问题，可达是图问题，而位置分析真正要回答的多数是后者——这正是[图数据库](https://www.yueshu.com.cn/database)在空间数据里的位置。

这篇要讲三件事：地理空间数据怎么进到图里，进图之后能回答哪些原来答不了的问题，以及哪些事仍然该交给 GIS。

# 一、半径算得出来，可达算不出来

位置上能问的问题，其实分三类，难度是递进的。

**第一类是「离我最近的在哪」。**给定一个坐标，找最近的十个门店。这是纯粹的几何问题，空间索引加 KNN，GIS 和带空间扩展的数据库都能做，百毫秒级。

**第二类是「这个圈里有多少」。**半径内有多少竞品、多少个小区、多少台设备。这是在几何之上再加一层聚合，也还算几何问题，只是数据量大了要预聚合。

**第三类是「从这里能不能到」。**十五分钟车程能覆盖哪些小区、哪些小区到站点要绕行、这个区域的居民到最近的社区医院要经过几个路口。这一类不是几何，是拓扑。

第三类问题的麻烦在于，它必须知道路。没有路网，只能拿直线距离乘以一个系数估算，而那个系数的误差在城区里可以到两三倍。隔着江、隔着铁路、隔着一条封闭快速路，直线一百米，实际两公里。

很多分析报告就停在这一步——用直线距离代替可达距离，然后在下结论时闭口不提这个替换。

| 问题类型   | 需要什么数据               | 谁擅长          |
| ---------- | -------------------------- | --------------- |
| 最近的在哪 | 坐标 + 空间索引            | GIS、空间数据库 |
| 圈里有多少 | 坐标 + 空间索引 + 聚合     | GIS、空间数据库 |
| 能不能到   | 路网拓扑 + 权重 + 多跳遍历 | 图              |

# 二、可达是图问题，因为路网本来就是图

路口是点，路段是边，边的权重是通行时间而不是长度。这么一建，可达性就是带权最短路径，图上跑了二十年的东西。

权重取时间而不是长度，这个选择会影响后面所有建模。一条两公里的快速路和一条八百米的单行道，按长度排前者更远，按时间排后者更慢。更麻烦的是权重本身会变——早高峰和凌晨的同一段路，通行时间差三倍是常事。所以权重不能写死在边上，得按时间段分层，或者存多套权重、查询时选一套。这一层不做，算出来的可达关系在早晚会给出两个答案。

但图真正的价值不在算最短路。最短路 GIS 也能算，而且算得不错。图的价值在于：**可达性可以和别的条件写在同一个查询里。**

举个例子。要判断某个网格适不适合开新店，条件其实有三层叠在一起：这个网格三公里内竞品门店不超过五家、网格覆盖的小区常住人口过万、从最近的配送站十五分钟内可达。第一条是空间聚合，第二条是属性筛选，第三条是路网上的多跳可达。

在分离式架构里，这三条要拆给三个系统做：GIS 算第一条，数仓算第二条，路径规划引擎算第三条，最后靠网格 ID 把三份结果 join 起来。join 一次没问题，但这个分析要跑八千个候选网格，就是八千次跨系统往返。等结果出来，商圈可能已经变了。

在同一个引擎里，这是三段条件串在一条查询上，跑一次。

# 三、位置进图的三种建模法

地理空间数据怎么塞进图，有三种做法，代价完全不同。选错一种，后面所有查询都会别扭。

**第一种：坐标作为点的属性。**门店、设备、事件、站点都带上经纬度字段，查询时用空间条件筛。这是最省事的做法，适合「位置固定的实体」，也适合先用它把数据搬进来再优化。

它的局限在于位置之间没有关系。两个门店相距两百米，这件事在图上没有边，只能每次现算。

**第二种：位置本身是点。**把路口、站点、基站小区、网格都建成独立的点，实体与位置之间用边连接，边上带时间窗。设备驻留在哪个网格、订单从哪个站点发出、车辆经过哪些路口，全都变成边。

这种做法的好处是位置获得了拓扑。两个门店之间的距离，变成「门店 A→所属网格→相邻网格→门店 B」的路径长度；一台设备去过哪些地方，变成沿边走一遍。

代价是点多。一个城市的精细路网就是几百万个路口点，加上网格、站点、基站，规模会比业务实体本身大一个量级。

**第三种：网格化降维。**把连续坐标按固定边长离散成网格 ID，用 ID 建边，坐标只作展示用。精度损失换来了剪枝能力——空间上的邻近判断退化成 ID 相等或相邻，快一个量级。

这种做法的边界很清楚：网格边长决定了能分辨的最小尺度。做商圈分析用五百米网格没问题，做门店门口的人流分析就不够。

| 建模法     | 适合什么                 | 代价                     | 什么时候别用           |
| ---------- | ------------------------ | ------------------------ | ---------------------- |
| 坐标作属性 | 位置固定的实体，快速接入 | 位置之间无拓扑           | 要算可达、要算邻近关系 |
| 位置建点   | 轨迹、驻留、覆盖、路网   | 点数量放大一个量级       | 只需要「离我最近」     |
| 网格降维   | 大范围聚合、商圈分析     | 精度受限，跨网格关系变粗 | 需要米级精度           |

这里有个关键点容易被忽略：**这三种做法不互斥。**实践中常见的是混用——门店用坐标属性，路网用位置建点，商圈分析用网格。同一张图里三种并存，只要点的类型分清楚，查询时各取所需。

# 四、三张网叠起来才有判断力

单个位置维度的判断力很有限，真正有判断力的是几层关系叠在一起。

**门店选址。**要叠三张网：竞品门店网（谁在哪、开了多久）、小区人口网（人在哪、多少人）、路网（从店到小区要多久）。任何一张单独给不出结论——竞品少的地方可能没人，人多的地方可能已经饱和，人多的饱和区可能恰好缺一条直达路径。

**配送分区。**要叠站点、小区、路网三张网。分区调整时真正要看的是「跨越边数」——一条新边界切断了多少个小区到原站点的最短路径。这个数字在纯几何的泰森多边形划分里根本算不出来，因为多边形不知道路。

**设备巡检。**要叠设备网、线路网、故障点三张网。同一个故障点附近三公里内有多少台同型号设备、它们挂在同一条线路上吗、上一次检修是哪个班组去的。空间条件负责缩范围，关系条件负责判断是否同批同源。

| 场景     | 三张网                     | 缺一张会怎样                 |
| -------- | -------------------------- | ---------------------------- |
| 门店选址 | 竞品门店 + 小区人口 + 路网 | 只算半径，选到江对岸         |
| 配送分区 | 站点 + 小区 + 路网         | 分区几何上均衡，实际绕行严重 |
| 设备巡检 | 设备 + 线路 + 故障点       | 只按距离派单，漏掉同批次隐患 |

这三张网里，前两张是关系数据，第三张是空间数据。要让它们同时生效，就得让空间条件和关系条件进同一个执行计划，这也是下一节要说的分工问题。

# 五、什么交给 GIS，什么该放进图

到这里必须说清楚一件事：图数据库不替代 GIS，也不该替代。

**该交给 GIS 的：**栅格计算、缓冲区分析、地图投影转换、图层渲染、栅格影像处理、轨迹抽稀与平滑。这些是空间计算的本行，图数据库做不了，做了也不划算。

**该放进图的：**多跳可达、关联约束、社群切分、路径还原、以及「空间条件 + 关系条件必须同时成立」的那类判断。这些是关系计算的本行，GIS 做不了。

两边真正的结合点在查询层：空间谓词作为过滤条件，图遍历作为判据，两者写在一起。

悦数图数据库在这件事上的做法，是把地理空间作为点和边的一种原生属性类型，与标量属性、向量、全文、时间并列。点可以带空间属性，边也可以带——一条路段的几何线、一段驻留的范围，都挂在边上而不是另存一张表。混合检索把图、向量、全文、地理位置几类条件放在同一个引擎内执行，不需要把数据先拆到几套系统再拼结果。多模融合在工程上的具体做法，[当 AI 遇上图数据库：多模数据融合的创新实践](/posts/database-multimodal)有过展开，本篇只取其中的空间这一路。

这个设计的实际意义在于：拆开拼的时候，空间条件只能当预过滤用，过滤完再进图遍历，中间结果集一旦大了，性能就塌了。写在同一个计划里，优化器可以先按跳数收敛，再在收敛后的候选集上算空间距离，顺序可以自己选。

数据和同步这条路也要提前想清楚。空间数据的来源通常很杂：路网来自测绘或地图服务商的矢量文件，门店与设备地址来自业务库，车辆和设备的实时位置来自物联网平台，三份数据的坐标系、精度、更新节奏都不一样。悦数支持 CSV、JSON、ORC、Parquet、SST 文件导入，也支持从 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源直接导入，Pulsar、Flink 做实时接入，结果可导出至 HDFS。多源数据进图时那条路径查询的性能瓶颈，[多源异构数据构建企业图谱](/posts/multi-source)有过专门讨论。

位置数据本身是流式的。实时接入这条通道不设计进去，后面就只能靠批量补，补出来的时间属性一定有偏差，而位置分析的所有判据都建立在时间上。

规模侧的口径是：支持千亿点万亿边，百亿点千亿边量级下点精确查询小于 1 秒、边精确查询小于 1 秒、5 度关系查询小于 5 秒，结果集为千万级。对城市级路网加业务实体这种规模，这个量级是够用的。

# 六、落地清单与两个误区

把前面的东西收成一张清单，按顺序做。

| #    | 动作                   | 交付物                       | 验收标准                     |
| ---- | ---------------------- | ---------------------------- | ---------------------------- |
| 1    | 分清要答哪类问题       | 问题分类表（最近/圈内/可达） | 每类问题都能对应到一种建模法 |
| 2    | 确定点的粒度           | 点类型清单                   | 路口、网格、站点的取舍写清楚 |
| 3    | 坐标以数值存           | 字段类型确认                 | 不是字符串，能建空间索引     |
| 4    | 路网权重用时间         | 权重来源与更新频率           | 区分工作日与高峰             |
| 5    | 位置变更留时间         | 边上的起止时间               | 不覆盖，只追加               |
| 6    | 空间条件与关系条件同查 | 关键查询清单                 | 至少三条核心查询不跨系统     |
| 7    | 划清 GIS 与图的边界    | 分工表                       | 栅格计算不进图               |

两个误区值得单独说。

**其一，把坐标存成字符串。**「116.404,39.915」这样存进去，读取的时候还得拆，空间索引建不上，空间谓词退化成字符串比较，性能差两个数量级。这个错误在建表阶段就该拦住，事后改要重灌数据。

**其二，位置覆盖更新。**设备换了个网格，就把设备上的网格 ID 改掉——这一步下去，历史全丢了。以后要问「这台设备上个月在哪个片区」，答不出来，因为那个片区已经在字段里被覆盖了。

位置数据天生带时间。正确的做法是把位置建成边，边上带进入时间和离开时间，换位置就是新加一条边、老边补上离开时间。历史留住了，代价是边会一直长——这才是需要分区和归档策略的地方，而不是靠覆盖更新省事。

回到开头那个选址报告。三个点位人口差不多，这个结论没错，只是回答错了问题。真正想知道的是这三个点各自能覆盖多少能走到的人，而那需要先有路，再有图。

**相关阅读**

- [Sensoro 升哲：图分析在城市治理服务的应用与落地](/posts/graph-database-usage-in-city-governance)
- [金融风控图数据库落地方案｜悦数图数据库万亿边团伙欺诈实时识别](/posts/real-time-recognition)
- [图数据库赋能企业数据资产管理：从关系图谱构建到风险穿透](/posts/iso-gql-louvain)
- [基于图数据库的客户关联网络风险洞察](/posts/associative-network)

# 常见问题（FAQ）

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

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边规模的关系数据存储与查询，内置图算法库，并支持图、向量、全文、地理空间的原生多模融合检索。

**Q2：图数据库能替代 GIS 吗？地理空间数据一定要放进图里吗？**

A：不能替代，也不必要。栅格计算、缓冲区分析、地图投影与渲染是 GIS 的本行，图数据库做这些既不擅长也不划算。图数据库解决的是另一类问题：多跳可达、关联约束，以及空间条件与关系条件必须同时成立的判断。判断标准很简单——如果一个问题只需要空间计算，交给 GIS；如果需要「从这里能不能到那里，并且满足某个关系条件」，那就该进图。

**Q3：悦数图数据库在技术积累与标准化方面有哪些进展？**

A：悦数图数据库已累计获得 60 余项国家发明专利，2024 年 11 月全球首发原生支持 ISO-GQL 39075 国际标准，公司技术专家为 ISO GQL 标准委员会成员；2025 年 3 月与复旦大学共建「先进金融图技术校企联合研究中心」。产品全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年入选信通院《中国数据库产业图谱》图数据库「领航者」；据 IDC 2024 年中国图数据库市场份额报告，悦数位列第二。

位置分析真正要回答的问题，多数不是「半径内有多少」，而是「能不能到」。半径是几何问题，GIS 算得出来；可达是图问题，路网本身就是一张图。图数据库把地理空间作为点和边的一种原生属性类型，与标量、向量、全文、时间并列，让空间条件和跳数条件写在同一条查询里一次下推。附三种位置建模法与 GIS 的分工边界。

地理空间数据怎么和图结合？图数据库在位置关联分析中的用法

![电信反诈图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-11-02.png)

举报工单转到核查组时，那个号码多半已经停机了。停机之前它拨出去几百通电话，跨了几个省。核查员去问运营商，回来的信息挑不出毛病：实名登记正常，入网七天，渠道是某家代理点。每一条都对，合起来才不对——七天前刚入网，七天里打了几百通，又在被问到的前一天停了。要把「每条都对、合起来不对」讲清楚，得把号码背后的设备与位置一起摊开，这正是[图数据库](https://www.yueshu.com.cn/database)在电信反诈里的位置。

这类工单在池子里占着不小的比例。换一张卡几十块，走一次核查要两天，这个账怎么算都不划算。所以反诈的抓手从来不在号码本身，而在号码背后那两样换起来更贵的东西：设备和位置。

这篇要回答三件事：三个维度各自能撑多久、怎么建到一张图里、什么条件下才该动手处置。

# 一、号码是最容易换掉的一维

号码的本质是易耗品。开卡便宜，弃号无成本，实名可以借、可以买、可以挂在一个从没见过面的老人名下。

所以任何以号码为主键的名单都注定滞后。名单上有的，对方已经不用了；名单上没有的，正是今天在打的。

但号码并非没有价值。它的价值不在号段和位数，而在三条关系上。

**号码与人的关系。**实名登记信息里能看到一个身份证下挂了几张卡、这些卡是不是同一天开的、开卡人年龄是不是集中在某个区间。

**号码与渠道的关系。**从哪个代理点、哪个营业厅开出来。同一个代理点一周开出几百张卡，这件事本身就值得看，因为它已经脱离了正常零售的节奏。

**号码与号码的关系。**主叫被叫之间形成的通话网——谁给谁打过、打了多久、有没有回拨。这是图数据库最擅长的部分：单个号码只是十一位数字，放进通话网之后，它立刻有了位置，是中心还是末端，是打给一百个人还是只打给三个人。

资金侧的追踪已经有比较成熟的路径，[电信诈骗资金链的分流追踪](/posts/telecom-fraud)讲的是从一级卡到 N 级卡那一段。本篇只看通信侧，也就是钱还没动之前，人和设备已经暴露出来的那部分。

# 二、设备比号码稳，但换标识这个动作本身是信号

一台手机的更换成本远高于一张卡，这是设备维度的价值基础。

设备也会被伪装。改机工具能刷 IMEI，一个工作室可以在一天之内把同一台机器的身份换十几遍。

这里有个容易走偏的地方：很多人把设备维度的目标定成「找到一个唯一且不可篡改的设备标识」。这个目标达不到，也不必要。

换一个目标就通了——**不看标识是否唯一，看标识的变化模式。**

一台设备在 24 小时内出现 17 个不同 IMEI，这件事本身就是最强的信号之一。正常用户换机是几年一次，不是一天十七次。同理，一台设备在三天里绑定过 40 个号码，无论这些号码本身看起来多正常，这个绑定动作的密度已经说明问题。

除 IMEI 之外还有一批更难改的东西：机型与系统版本、屏幕分辨率与时区、传感器噪声特征、开机时长、安装应用列表的哈希。这些字段单独拿出来都很弱，合在一起形成的指纹比 IMEI 稳得多，而改机工具通常只改表层标识，改不动物理传感器留下的偏差。

设备维度真正要抓的是三类结构。

| 结构     | 表现                         | 典型形态           |
| -------- | ---------------------------- | ------------------ |
| 一机多号 | 一台设备短期绑定大量号码     | 猫池、接码平台     |
| 一号多机 | 一个号码在多台设备上轮流登录 | 号卡租用、账号共享 |
| 设备迁徙 | 同一批设备在不同城市交替出现 | 流动窝点           |

第二类要特别当心。一号多机在正常场景里也存在——换手机、平板加手机、家里老人共用，所以它单独不能作为判据，必须和位置、通话行为一起看。这一点在第五节的分级里还会再提。

# 三、位置是最难伪造的一维，但只有加了时间窗才成立

主叫号码可以用改号软件伪造，设备标识可以刷，位置不行。

一台设备夜里停在哪个基站覆盖范围内，这个数据在运营商侧，改不动。三个维度里，位置的可信度最高。

但位置数据有两个陷阱，掉进去的人不少。

**第一个陷阱是把位置当成坐标。**基站覆盖是一个扇区，不是一个点。城区里一个小区可能覆盖几百米，郊区可能几公里，室内还有几十到几百米的漂移。用经纬度做精确匹配或距离阈值，误差会吃掉大部分真实信号，剩下的是噪声。

**第二个陷阱是忽略时间。**同样的两台设备白天都在市中心，什么也说明不了；连续七个夜晚停在同一个小区同一栋楼，性质就完全不同。位置的价值不在「在哪儿」，在「什么时候总在哪儿」。

所以位置维度正确的用法是三个要素叠加：位置、时间窗、聚集度。

具体落到三个判据上。

- **夜间驻留。**连续 5 到 7 个夜晚驻留在同一网格，且该网格不在登记住址范围内。
- **驻留聚集。**同一网格内夜间驻留的嫌疑设备数量超过阈值，阈值按网格类型分别设定，城区小区与城郊村落的正常密度差着量级。
- **位置与申报矛盾。**号码申报地在 A 省，设备长期驻留在 B 省某小区，通话对象又集中在 C 省。三条对不上，才是最有价值的一类。

第三条判据的好处是它不需要知道对方是谁。它只要求三件事互相对不上——而伪造位置的人往往能伪造一处，伪造不了三处同时自洽。各地基站的覆盖粒度与驻留记录口径并不统一，[图数据库在通信行业的应用](/posts/graph-database-application-in-communication-industry)对这类数据基础的差异有过梳理，建模前值得先看一遍。

# 四、三维怎么建到一张图里

三个维度各自的强弱清楚了，接下来的问题是让它们互相印证。

关键在于两句话：**点要选对，边要带时间。**

点不能只有号码。如果把号码当唯一的点，设备和位置就只能退化成号码的属性，那么「两台设备连过同一个号码」这种关系就永远查不出来。设备必须是点，位置也必须是点，代理点同样要是点——否则批量开卡这条线索会断在属性字段里。

| 类型 | 点              | 边                                 | 边上必须带的属性                 |
| ---- | --------------- | ---------------------------------- | -------------------------------- |
| 通信 | 号码            | 呼叫（号码→号码）                  | 起止时间、时长、主被叫、是否接通 |
| 设备 | 设备指纹        | 绑定（设备→号码）                  | 绑定时间、解绑时间、IMSI         |
| 位置 | 基站小区 / 网格 | 驻留（设备→位置）                  | 进入时间、离开时间、停留时长     |
| 人员 | 自然人          | 实名（号码→人）、任职（人→代理点） | 登记时间、证件类型               |
| 渠道 | 代理点 / 营业厅 | 开卡（号码→代理点）                | 开卡时间、开卡人、批次号         |

**边上的时间属性不是可选项。**没有时间的边，会把三年的历史压成一个瞬间，图上所有人都跟所有人连着，整张图退化成一张蜘蛛网，什么也查不出来。这是建图时最常见的错误，而且它的症状很迷惑——数据量看着很大，查询结果却全是噪声。

加上时间窗之后，问题才变成可回答的：过去 7 天里，哪些设备在同一网格夜间驻留，且共用过两个以上号码，且这些号码之间互相通过话。这样的查询在关系型数据库里要写一串自连接，还得自己处理时序，在图里是一次带条件的多跳遍历。

还有一层配合值得提。设备指纹里的应用列表哈希要走近似匹配，通话记录里的关键词要走全文检索，位置要走空间范围筛选，这三类条件经常同时出现在一个查询里。悦数图数据库的原生多模融合检索把图、向量、全文、地理空间几类索引放在同一个引擎内，不需要把数据拆到几套系统再拼结果——拆开拼，时间窗条件就会在拼接处丢掉。

# 五、一维可疑、两维核验、三维处置

建完图之后最容易犯的错，是拿任意一个维度的信号直接触发处置。

后果是误伤。误伤一多，业务方会把系统关掉。风控系统真实的死法不是被绕过，是被关掉。

分级处置的原则只有一句：**维度越多，动作越硬。**

| 命中情况     | 处置动作                           | 人工介入   | 典型场景                                   |
| ------------ | ---------------------------------- | ---------- | ------------------------------------------ |
| 单一维度     | 进观察池，不打扰用户               | 无         | 名单比对、单次异常驻留、单日高频主叫       |
| 两个维度交叉 | 进人工核验队列，按优先级排序       | 抽检加复核 | 一机多号加夜间聚集；号码申报地与驻留地矛盾 |
| 三个维度闭环 | 自动处置，停呼、限制入网、移交线索 | 事后审核   | 三项同时成立且有连续时间证据               |

三个维度之间的权重并不相等。**位置最重**，因为它最难伪造；**设备次之**，因为伪造它需要工具和成本；**号码最轻**，只用它排序，不用它定性。

这条权重顺序不是拍出来的，是从伪造成本推出来的。伪造成本与可信度成反比，这个关系比任何一条人工规则都稳定，也不会因为话术升级而失效。

团伙识别则要靠图算法。Louvain 社区发现能在通话网里切出紧密社群，把「一堆各自看着都正常的号码」变成「一个成员互相高频通话的团」。社区切出来之后再回到前面三个维度核对，命中率会比单点规则高一个量级。

这里有个次序问题值得强调：先用算法找结构，再用规则做判定。反过来做——先定一堆规则筛出可疑号码，再去看它们之间有没有关系——你筛出来的永远是规则本来就认识的那些形态。

# 六、误伤从哪来，怎么控

三维关联不是没有代价的。下面这几类场景天然会产生相似度很高的结构，必须提前排除。

| 误伤场景        | 为什么像                   | 怎么区分                                   |
| --------------- | -------------------------- | ------------------------------------------ |
| 家庭共用设备    | 一机多号，夜间同驻留       | 通话对象集中在少数几个号码，时间跨度以年计 |
| 二手手机        | 设备短时间换绑多个号码     | 换绑间隔长，跨地域但无夜间聚集             |
| 维修店 / 刷机店 | 同一设备短时间出现多个标识 | 设备进出集中在营业时段，无持续通话行为     |
| 代理点批量开卡  | 一个渠道短时间开出大量号码 | 号码有分散的正常通话，无同网格驻留         |
| 工地 / 校园宿舍 | 同一网格夜间大量设备驻留   | 驻留稳定数月，通话网稀疏且外向             |

第五类最容易被忽略。一个工地宿舍夜里几百台设备驻留在同一个基站下，如果不叠加「驻留稳定性」和「通话网外向度」两个条件，它就是教科书级别的团伙形态——排查下来却什么也没有。加这两个条件之后，误伤能降下来，代价是滞后一两天，这个代价是值得付的。

另外两个判断上的误区也值得说。

**其一，把黑名单当模型。**名单只能拦住已经出现过的号，而涉诈号码的生命周期本来就只有几天。名单是结果，不是方法。

**其二，一次性全量建图。**不少项目启动时把历史数据全量灌进去，之后就靠人工每天补一次。正确的做法是把实时链路一起设计进去：通话记录、开卡记录、驻留记录本身就是流式的，用 Pulsar、Flink 这类通道接进来就直接落图，边上的时间属性天然带上，不需要事后回填。回填的时间属性一定有偏差，而时间恰恰是这篇所有判据的基础。

悦数在这类场景上的支撑点比较具体。存算分离加 Shared-Nothing 架构，千亿点万亿边规模下点边精确查询 1 秒内、5 度关系 5 秒内；内置 Louvain、连通子图、最短路径、环路检测等算法，团伙切分和链路还原不用把数据导出到第二套系统；支持 Pulsar、Flink 实时接入，通话与驻留可以边产生边入图。

行业侧有可参照的落地。中国移动用悦数图数据库支撑 9 亿用户规模的数据分析，反欺诈与社区发现是其核心场景之一；中国电信的落地集中在商品管理与智能运维图谱。据 IDC 2024 年中国图数据库市场份额报告，悦数位列第二，并连续两年入选信通院图数据库「领航者」。

最后回到开头那个号码。它停机了，但注册它的那台设备还在开机，那台设备这几天的夜间驻留点没有变过。号码是这三个月里换的第四张，设备是同一台，位置是同一栋楼——这三句话放在一起，才是一个能动手的结论。

**相关阅读**

- [金融风控图数据库落地方案｜悦数图数据库万亿边团伙欺诈实时识别](/posts/real-time-recognition)
- [基于实时图技术的信用卡申请反欺诈应用](/posts/credit-card-anti-fraud-application)
- [基于图数据库的客户关联网络风险洞察](/posts/associative-network)
- [图数据库赋能企业数据资产管理：从关系图谱构建到风险穿透](/posts/iso-gql-louvain)

# 常见问题（FAQ）

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

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边规模的关系数据存储与查询，内置图算法库并支持图、向量、全文、地理空间的原生多模融合检索。

**Q2：电信反诈为什么单靠号码黑名单不够？**

A：号码是易耗品，开卡便宜、弃号无成本、实名可以借，生命周期往往只有几天，所以以号码为主键的名单天然滞后。有效的做法是把号码放回关系里判断：它挂在谁名下、从哪个代理点开出、在通话网里处于什么位置。号码、设备、位置三个维度的伪造成本依次升高，伪造成本越高的维度越该给更高权重，单维命中只入观察池，多维交叉才进核验。

**Q3：悦数图数据库内置哪些图算法，反诈场景用得上哪几个？**

A：悦数图数据库内置图算法库覆盖路径查询、重要性分析、社区发现、风险传播、模式挖掘与图神经网络几类，反诈场景常用的是 Louvain 社区发现用于团伙切分、连通子图用于窝点归并、最短路径用于通话与资金链路还原、环路检测用于识别互相担保与循环转账。产品已全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年入选信通院图数据库「领航者」；据 IDC 2024 年中国图数据库市场份额报告，悦数位列第二。

电信反诈的被动，来自三个维度被伪造的成本不一样：号码几十块就能换，设备指纹刷一次要工具，位置几乎改不动。图数据库把号码、设备、位置建成三类点，把注册、呼叫、驻留建成带时间窗的边，单维可疑只入观察池，两维交叉才进核验，三维闭环才自动处置。附点边建模口径、判定分级与误伤边界。

电信反诈怎么用图数据库？号码、设备与位置的三维关联识别

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

一张供应商准入表，通常十二三个字段。营业执照、开户许可证、业绩合同、体系认证、财务报表、授权委托书——八九个字段是供应商自己填、自己盖章的。审核员能核的是“材料齐不齐、有没有过期、章盖得对不对”，核不了“这家公司和上一轮那四家投标人是不是一伙的”。后面这件事，表格做不到，[图数据库](https://yueshu.com.cn/what-is-graph)做得到。

这就是准入环节的真实困境：审核动作全部指向“这家公司自身合不合格”，而采购风险的大部分来自“这家公司和谁在一起”。前者是资质问题，可以逐项打勾；后者是关系问题，一张表装不下。要把关系装进来，靠的不是更严的表格，而是把供应商放进一张能连起来的关系网里——这正是图数据库在准入环节的位置：不是替代审核，而是把审核员看不见的那一层关系摊开。

# 一、准入核的是材料，材料证明不了关系

把准入材料按“能证明什么、不能证明什么”排一遍，问题就很清楚。

| 材料       | 能证明什么                 | 核不了什么                         |
| ---------- | -------------------------- | ---------------------------------- |
| 营业执照   | 主体真实存在、经营范围匹配 | 与另一家投标人是否同一批人控制     |
| 业绩合同   | 有同类项目经验             | 业绩是否由关联方互相“喂”出来       |
| 体系认证   | 管理流程达到标准           | 实际产能与交付是否由同一套班子完成 |
| 财务报表   | 规模与偿债能力             | 关联方之间是否存在资金空转         |
| 授权委托书 | 经办人有代理权             | 两家供应商的经办人是否为同一人     |

材料审核擅长排除“不合格”，不擅长排除“不合适”。一家注册资本 500 万、有三年同类业绩、证书齐全的供应商，完全可能和另外三家一起围同一个标段——每家单看都合格，放在一起才看得出问题。

这个缺口不是审核员不认真造成的，是数据形态决定的。资质是属性，一条一条挂在主体上；关联是关系，只在主体之间才存在。用属性字段去承载关系，怎么设计都会有漏。

# 二、隐性关联的六种形态，四种在纸面上看不出来

真正需要拦的关联，多数不写在股权结构里，而藏在共用的人、共用的标识、同步的动作里。

| 形态               | 数据从哪来                       | 在图上的样子                     |
| ------------------ | -------------------------------- | -------------------------------- |
| 同址同电话         | 工商登记、投标文件、发票抬头     | 两家供应商指向同一个地址点       |
| 共用财务或社保代缴 | 社保代缴记录、代理记账合同       | 同一自然人或同一中介同时连向多家 |
| 股东高管交叉       | 工商股权与任职信息               | 两条持股边或任职边汇于同一人     |
| 法定代表人亲属     | 户籍、婚姻、诉讼文书             | 两个自然人之间的亲属边           |
| 投标文件同源       | 电子投标文件的作者、创建机器、IP | 多家投标人连向同一设备或同一 IP  |
| 保证金同源         | 银行流水、保函开立行             | 多家投标人的保证金来自同一账户   |

前四种是“静态关联”，靠工商和公开数据就能建；后两种是“行为关联”，只有把投标动作本身记录成边才看得见。

行为关联的价值在于它绕不过去。《招标投标法实施条例》第四十条把六种情形直接视为串通投标：投标文件由同一单位或个人编制、委托同一单位或个人办理投标事宜、投标文件载明的项目管理成员为同一人、投标文件异常一致或报价呈规律性差异、投标文件相互混装、不同投标人的投标保证金从同一单位或个人账户转出。这六条里有五条本质上是“关系证据”，不是“资质证据”。用资质审核去查这五条，方向就错了。供应链场景里做风险预警的整体思路，可参考[图数据库与大模型如何实现智能风险预警](/posts/suppply-chain-database)，本篇只落在准入这一道关口。

拿报价规律举例。四家投标人报价 486 万、512 万、538 万、564 万，两两相差 26 万，整齐得不像市场竞争。单看每一份报价单都挑不出毛病，把四份放在一条数轴上，规律立刻显形。这个规律在人眼里要摆开看，在图里则是一条可以直接查询的模式。电子投标还多一层线索：文档属性里往往留着作者名、创建机器和最后保存人，纸质标书时代不存在的痕迹，现在一条条都在文件里。这些字段单独看毫无意义，按供应商归并之后，同名作者出现在四家投标人的文件里，就成了很难解释的事。

# 三、建模：四类点、三类边，标识点是关键

准入场景的图不用建得很大，四类点就够：供应商、自然人、标识、项目。自然人不只是股东，还包括高管、经办人、财务负责人、评标专家；标识包括地址、电话、银行账户、邮箱、IP、设备指纹；项目是招标包或标段。

边分三类。股权与任职边描述静态结构，投标边描述动作，付款边描述履约。三类边的更新时间完全不同——工商信息按季度变，投标行为按次产生，付款按月发生。混在一张表里就会互相拖累，分开建、按需关联才跑得动。

```
MATCH (s:supplier {sid: $supplier})-[:located_at|uses_phone|uses_account]->(id:identifier)
MATCH (id)<-[:located_at|uses_phone|uses_account]-(peer:supplier)
WHERE peer.sid != s.sid
RETURN peer.sid, count(DISTINCT id) AS shared_idents
ORDER BY shared_idents DESC
```

这条查询问的是：这家供应商的地址、电话、账户，还被哪些供应商共用。共享一个标识可能是巧合——同一个产业园、同一家代理记账公司；共享三个以上，基本可以认定不是巧合。

标识点是整个建模的关键。它把“看不出来的关系”翻译成“看得见的边”：两家公司名称毫无相似之处，股权上也没有交集，但它们把保证金从同一个账户转出、投标文件在同一台电脑上生成、留的联系电话是同一个号码——三条标识边一并，关系就成立了。没有标识点，这三条线索永远躺在三张不同的表里。

# 四、判定：三条路径，分级处置

关联识别不能一票否决，也不能只做提示。可执行的做法是三条路径分别打分，按命中数量分级。输出形态也要克制：不要给审核员一张几千节点的关系图，而是一句话结论加上可展开的证据链——这一包七家投标人分成三个关联簇，其中三家的保证金来自同一账户，点击可以逐条看原始凭证。审核员要的是判断依据，不是图谱。

| 路径     | 典型证据                                     | 证据强度 | 处置动作               |
| -------- | -------------------------------------------- | -------- | ---------------------- |
| 股权关联 | 同一实控人、交叉持股、母子公司同标段         | 强       | 直接不予准入           |
| 人员关联 | 同一经办人、同一财务负责人、法定代表人为亲属 | 强至中   | 两家取一或要求书面说明 |
| 行为关联 | 保证金同源、投标文件同源、报价呈规律性差异   | 强       | 移交合规核查           |
| 标识重合 | 同址、同电话、同邮箱，且无合理解释           | 中至弱   | 列入重点观察，加审     |

分级的意义在于避免两种错误。一种是只凭同址就判死——同一个产业园里几十家公司共用门牌，代理记账公司一个地址挂上百家客户，这类误伤会让采购部门很快不信任系统。另一种是只提示不处置——把关联线索做成一张漂亮的关系图，却没有对应的准入动作，图就成了展示品。

建议的判据是：任一路径命中两条以上独立证据，不予准入；命中一条强证据，要求书面说明并加审；只有标识重合而无其他证据，列入观察名单，在下一次投标时重点比对。三条路径都跑完才出结论，跑一半就下判断，比不跑更容易出错。风控体系里这套判定的完整位置，[供应链金融风控体系图数据库分析](/posts/supply-chain-finance-risk-control-cystem-map-database-analysis)讲得更系统。

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

准入场景的图有两个特点：点不多但边很杂，且要求实时。悦数图数据库采用存算分离与 Shared-Nothing 架构，在千亿点万亿边规模下点边精确查询 1 秒内返回、5 度关系查询 5 秒内返回，供应商与标识之间的多跳关联可以沿边直接遍历，不必把工商、投标、流水三套数据反复 JOIN；动态 Schema 支持不停机新增设备指纹、保函编号等标识类型，招标规则变化时不必重建模型；内置连通子图与社区发现算法，能把一批投标人自动切成若干关联簇；配合 Text2nGQL，采购人员用自然语言就能发起“这批投标人里有没有共用账户的”这类查询。产品 100% 自主可控。

# 六、入库不是终点：动态年审与两个误区

关联是长出来的，不是天生的。一家供应商入库时干干净净，两年后可能因为法人变更、股东新增、地址迁移，和另一家成了关联方。只做准入不做年审，等于只在门口查一次证件。

| 阶段         | 目标           | 核心工作                                                     | 参考周期 |
| ------------ | -------------- | ------------------------------------------------------------ | -------- |
| 一、标识库   | 先把标识收齐   | 归集工商、投标、流水三类数据中的地址、电话、账户、设备，做实体解析去重 | 4~6 周   |
| 二、行为入图 | 让投标动作可查 | 电子投标文件的作者与设备信息、保证金账户、报价序列入图       | 6~8 周   |
| 三、准入判定 | 关联进流程     | 三条路径接入准入系统，输出关联簇与分级处置建议，先并行不阻断 | 4~6 周   |
| 四、年审监测 | 关联变化可预警 | 增量监听工商变更与新增投标，命中关联规则即触发复审           | 持续     |

第一个误区是把同址同电话直接判死。园区注册、代理记账、虚拟办公地址，这三种情况在中小企业里极其普遍，一刀切会把大量正常供应商挡在门外。正确做法是把标识重合当作线索而不是结论，必须叠加人员关联或行为关联才处置。

第二个误区是只建供应商、不建人。关联的载体是人——股东、高管、经办人、财务。只把供应商建成点，人和标识都存成字段，那么“两家公司共用同一个财务”这条最重要的线索，永远无法被查询到。人必须是点，标识也必须是点。

供应商准入的本质，是把“这家公司合不合格”这一个问题，加上“这家公司和谁是一伙的”这第二个问题。第一个问题靠材料，第二个问题只能靠图。

**相关阅读**

- [如何用图数据库解决供应链金融风控问题？](/posts/supply-chain-finance-risk-control-problems-with-graph-databases)
- [基于图数据库的客户关联网络风险洞察](/posts/associative-network)
- [图数据库在业务风控中的应用](/posts/application-of-graph-database-in-business-risk-control)
- [图数据库常见算法有哪些？](/posts/what-are-the-common-algorithms-ingraph-databases)

# 常见问题（FAQ）

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

A：悦数图数据库是杭州悦数科技自主研发的分布式图数据库，面向千亿点万亿边规模的关系数据存储与查询，采用存算分离与 Shared-Nothing 架构，支持动态 Schema、内置图算法与原生多模融合检索，产品 100% 自主可控，已获 60 余项国家发明专利。

**Q2：供应商准入与悦数图数据库是什么关系？**

A：准入环节要判断的是供应商之间的关联，而关联只能沿边查。悦数把供应商、自然人、地址电话账户等标识建成点，把持股、任职、投标建成边，多跳关联一次遍历即可得出；千亿点万亿边规模下点边精确查询 1 秒内、5 度关系 5 秒内，让关联核查能在准入评审的时限内跑完。

**Q3：悦数图数据库在落地行业与场景方面有哪些积累？**

A：悦数已在金融风控、供应链管理、政务与公共安全等领域落地，覆盖反欺诈、反洗钱、企业关联关系分析、N 级供应商风险穿透等场景，中国移动用其支撑 9 亿用户规模的数据分析。按 IDC 2024 年中国图数据库市场份额报告，悦数位列第二，并连续两年入选信通院图数据库“领航者”。

供应商准入审不出问题，往往不是材料不齐，而是材料全是自证的：营业执照、业绩合同、体系认证，能证明这家公司合格，证明不了它和另外三家是不是一伙的。图数据库把供应商、经办人、地址电话账户这些标识建成点，把投标行为建成边，隐性关联才从纸面背后浮出来。

供应商准入怎么审？图数据库识别隐性关联与控制关系的路径

![股权穿透查询图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-29.png)

一家有限合伙企业，普通合伙人出资 0.8%，有限合伙人出资 62%，剩下是十几个跟投的自然人。按出资比例连乘往上穿，穿到顶是那位 62% 的 LP；按谁在合伙协议里执行事务、谁签得了字往上穿，穿到顶是那位 0.8% 的 GP。两套算法、两个答案，而[图数据库](https://yueshu.com.cn/database)要解决的第一件事，是让这两套算法能在同一张关系网上各跑一遍。

同一家公司，两个“实际控制人”。

这不是数据错误，是口径问题。工商登记、监管报送、银行尽调三张表之所以经常对不上，原因往往不是谁填错了，而是三家用的算法根本不是同一个：一家算出资，一家算表决权，一家算实际支配。要把三个答案收成一个，先得把“股权穿透”这个词拆开——图数据库在这里的价值，不是把递归查询跑得更快，而是让这三种算法各有各的载体，能分开算、也能一起算。

# 一、先分清三个问题：谁持股、谁表决、谁说了算

穿透查询看着是一件事，其实是三件。第一件是经济权益：某个自然人对目标公司最终享有多少比例的出资份额，用来算并表、算关联交易、算受益所有人。第二件是表决权：这个人在股东会上能投出多少票，用来判断控股与重大事项能否通过。第三件是实际支配：即便一股不持，能不能决定董事会人选、财务负责人、经营方向。

三件事的输入不同，答案自然可以不同。一个持股 13.2% 的自然人可能是实际控制人，一个持股 51% 的股东也可能只是代持通道。把三者混成一个“穿透比例”，后面所有的判断都会跟着错。

| 口径         | 输入是什么                       | 能回答的问题         | 什么时候失效                   |
| ------------ | -------------------------------- | -------------------- | ------------------------------ |
| 出资比例连乘 | 各层持股比例                     | 最终享有多少经济权益 | 有代持、同股不同权、分层架构时 |
| 表决权比例   | 章程约定的表决权、委托、一致行动 | 股东会能不能通过     | 表决权分散、无一致行动时       |
| 实际支配     | 董事会席位、人事财务权、协议控制 | 谁真正说了算         | 仅有股权关系、无支配证据时     |

判断标准可以先定下来：三种口径算出的答案若一致，结论最稳；若不一致，以实际支配为准，表决权次之，出资比例最后。这条顺序不是偏好，是监管口径的一贯逻辑——实际控制人的定义本身就落在“能够实际支配公司行为”上，而不是落在持股数字上。

# 二、建模：点分三类，边要带五个属性

很多穿透项目失败在建模的第一步：把“股东”存成了企业节点的一个字段。字段化的后果是，超过三层就穿不动，因为第四层的股东在系统里根本不是一个能被继续追溯的实体。关联关系全景画像怎么建，[股东穿透与实际控制人识别](/posts/shareholder-penetration)给过一套场景视角的拆解，本篇只谈建模与判定口径。

正确的做法是把持股主体全部拆成点，分成三类。企业法人，包括境内有限公司、股份公司和境外主体；自然人；以及合伙企业、资管计划、信托这类持股载体。第三类最容易被漏掉，也最容易出错——有限合伙里的普通合伙人与有限合伙人，权利结构完全不同，把它压成一个“股东”点，控制关系就丢了。

边比点更重要。一条持股边至少要带五个属性，缺一个就会在某一类结构上算出错答案。

| 边属性           | 含义                       | 为什么必须单列                    | 缺失的后果             |
| ---------------- | -------------------------- | --------------------------------- | ---------------------- |
| 出资比例         | 认缴出资占注册资本比重     | 算经济权益的基础                  | 并表与关联交易判断失真 |
| 实缴比例         | 实际到位资金占比           | 影响偿债与真实权益                | 空壳股东被当成实力股东 |
| 表决权比例       | 章程或协议约定的投票权     | 同股不同权、AB 股、委托投票都靠它 | 控制权判断整体失效     |
| 生效区间         | 起止日期                   | 股权是时点状态，历史追溯需要      | 只能看现在，查不了当时 |
| 数据来源与更新日 | 工商、年报、公告、内部录入 | 冲突时要能判断谁更新              | 多源冲突无法裁决       |

除了持股边，还要留两类独立边：代持边和表决权委托边。它们不改登记比例，但改真实归属，混进持股边里就再也分不出来。合伙企业则要单独建“执行事务合伙人”边，因为这条边承载的控制权与出资比例无关。

# 三、连乘在这四类结构上必然算错

出资比例连乘是最直观的算法，也是最容易出错的一个。它在简单树状结构上没问题，一碰到下面四类结构就失真。

| 结构                         | 连乘会算出什么                     | 正确的处理口径                           |
| ---------------------------- | ---------------------------------- | ---------------------------------------- |
| 循环持股（A 持 B、B 持 A）   | 递归不收敛，或被人为截断层数       | 先识别环，按环内最小比例折算后再向外展开 |
| 交叉持股（同一股东多条路径） | 多条路径比例相加，可能超过 100%    | 按最终股东合并去重，取控制链而非求和     |
| 有限合伙（GP 出资极少）      | GP 比例接近 0，被判定为无控制      | 以执行事务合伙人身份判定控制，不看比例   |
| 代持与表决权委托             | 登记比例与实际归属一致，看不出差异 | 走代持边与委托边，单独计算实际表决权     |

拿一条三层链算一遍就清楚了。A 持 B 60%，B 持 C 55%，C 持 D 40%。连乘得 60% × 55% × 40% = 13.2%，低于受益所有人常用 25% 的判定线，很多系统到这里就把 A 排除了。但看控制关系：每一层都过了半数，A 对 B 绝对控股，B 对 C 绝对控股，C 是 D 的第一大股东且能实际支配——控制是一层一层传下来的，不是乘出来的。经济权益 13.2%，控制权接近 100%，这两个数字都真实，只是回答的问题不同。

这也是为什么受益所有人的判定标准写的是“直接或间接拥有超过 25% 股权或表决权”，后面还要跟一句“或虽未超过但能实际控制”。前半句交给连乘，后半句交给控制链，两条都算完才算穿透完。

# 四、实控人怎么算：三条判定路径与剪枝规则

实控人识别不是一次查询，是三条路径分别跑、结果合并。

第一条是股权链。沿持股边向上枚举路径，边比例相乘，达到阈值即标记。常用阈值有三个：25% 对应受益所有人判定，50% 对应绝对控股，三分之一对应重大事项否决权。三个阈值对应三种业务用途，不要只留一个。

第二条是表决权支配。把一致行动协议、表决权委托、AB 股安排、章程特别约定一并计入表决权比例。这条路径经常被跳过，因为它的数据不在工商登记里，而在公告、协议和内部档案里。

第三条是实际支配。董事会席位是否过半、财务负责人与总经理能否任免、公章与账户由谁控制、是否存在协议控制安排——这类证据大多是文本，需要与大模型或多模检索配合，从公告和合同里抽出来挂到边上。这类实体与证据的组织方式，在[企业风险知识图谱的构建及应用](/posts/enterprise-risk-kg)里有更完整的讨论。

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

多层穿透的难点在深度与并发：一条十层链要逐层展开，同时还有成千上万条链在并行计算。悦数图数据库采用存算分离与 Shared-Nothing 架构，在千亿点万亿边规模下点边精确查询 1 秒内返回、5 度关系查询 5 秒内返回，路径枚举与连通性计算可以沿边直接遍历，不必用递归 JOIN 反复回表；动态 Schema 支持不停机新增境外主体、资管计划等点类型与表决权委托边，历史股权按时点区间存储，能查当下也能查当时；内置最短路径与连通子图算法，配合 Text2nGQL 让业务人员用自然语言直接发起穿透查询。产品 100% 自主可控。

# 六、验收：用已知答案回测，两个误区

穿透系统上线前，最有效的一次验收不是压测，是回测。取一批监管已披露实际控制人的上市公司或公开发债主体，把系统跑出来的结论与披露口径逐家比对，差异逐条归类：是数据缺失、是结构没建模，还是判定路径没跑。

| 验收项     | 检验方法                       | 合格参考                               |
| ---------- | ------------------------------ | -------------------------------------- |
| 回测命中率 | 取 200 家已知实控人的主体比对  | 一致率是唯一硬指标，差异必须能逐条解释 |
| 路径可解释 | 结论能否给出完整的链与每层比例 | 只给结论不给链的，一律不通过           |
| 深层响应   | 八至十层穿透的单次耗时         | 交互式查询应在百毫秒至秒级             |
| 数据新鲜度 | 工商变更后多久反映到图里       | 决定穿透结论是否可用                   |
| 口径一致性 | 与监管报送口径是否一致         | 三处答案必须能对齐，否则等于没做       |

第一个误区是把工商登记的股东当成全部。合伙企业、资管计划、境外主体、代持安排，这四类在登记信息里都表现为一个普通股东名称，看不出差别。不单独建模，穿透到第三层就断了。

第二个误区是用最短路径代替控制链。最短的那条链往往不是控制链——A 和 D 之间可能有一条两跳的 0.1% 搭桥路径，而真正的控制链要走五层、每层都过半。按跳数排序必然选错，按表决权乘积排序才对。

股权穿透的本质，是把“谁持股”这一个问题，拆成“谁表决”和“谁说了算”两个问题。三个答案能对齐，穿透才叫穿透；只有一个数字，那只是乘法。

**相关阅读**

- [公司风控管理为什么要使用图数据库](/posts/company-risk-management-with-graph-database)
- [图数据库在业务风控中的应用](/posts/application-of-graph-database-in-business-risk-control)
- [图数据库赋能企业数据资产管理：从关系图谱构建到风险穿透](/posts/iso-gql-louvain)
- [图数据库常见算法有哪些？](/posts/what-are-the-common-algorithms-ingraph-databases)

# 常见问题（FAQ）

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

A：悦数图数据库是杭州悦数科技自主研发的分布式图数据库，面向千亿点万亿边规模的关系数据存储与查询，采用存算分离与 Shared-Nothing 架构，支持动态 Schema、内置图算法与原生多模融合检索，产品 100% 自主可控，已获 60 余项国家发明专利。

**Q2：股权穿透查询与悦数图数据库是什么关系？**

A：股权穿透的核心是沿持股边做多层路径枚举与比例计算，这正是图数据库的原生查询形态。悦数在千亿点万亿边规模下做到点边精确查询 1 秒内、5 度关系 5 秒内，支持按时点存储历史股权与动态新增主体类型，是十层穿透能做成交互式查询的前提。

**Q3：悦数图数据库在国产化适配与权威认证方面有哪些进展？**

A：悦数已完成统信、麒麟、中科可控等国产软硬件适配，产品 100% 自主可控，累计 60 余项国家发明专利；2024 年 11 月全球首发原生支持 ISO-GQL，2024 年 6 月成为国内首家通过信通院“可信数据库”图数据库性能测试的产品，并连续两年入选信通院图数据库“领航者”。

股权穿透算不准，多半不是数据缺，而是把“谁持股”当成了“谁说了算”。出资比例连乘得出的 13.2%，和层层过半形成的 100% 控制权，是两个答案。图数据库把企业、自然人、合伙企业建成点，把持股比例与表决权比例拆成两条属性，再沿控制链判定，答案才对得上工商与监管口径。

股权穿透查询怎么做？图数据库多层持股与实控人识别的建模方法

![可疑交易图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-28.png)

风控部门每季度要开一次阈值评审会。这次议题很简单：把可疑交易的金额阈值从 5 万提到 8 万。理由也充分——上季度人工复核队列积压 1.7 万条，单条平均处置 6 分钟，两个人全职干不完。调完之后报送量掉了四成，会开得挺顺。会议室里没人提另一件事：这套规则逐笔看账户，而[图数据库](https://yueshu.com.cn/database)擅长的恰恰是账户之间的关系。

纪要第三页有一行小字没人追问：阈值上调后新增的漏报，抽样复核结果是多少。不是不想算，是算不出来。漏报没有队列、没有工单、没有人在事后去捞那些本该报却没报的交易。误报看得见，漏报看不见，于是每一次调参都朝同一个方向走：阈值越来越高，队列越来越短，模型越来越安静。

真正的问题不在阈值的位置。一笔 4.8 万的分拆转账，和一笔 4.8 万的连锁门店日结，在规则引擎眼里是同一个东西——金额、时间、对手方三个字段凑出来的一个分数。它们唯一的区别在于所处的关系结构，而这个维度在逐笔评分里根本不存在。这正是图数据库要补的那一环。

# 一、误报的根源：一个团伙被拆成两百多笔孤立打分

传统甄别链路的输入单位是“一笔交易”。规则读金额、时点、频次、名单；模型读同一组字段再加一点历史行为；输出的是一条告警和一个置信度。整条链路里，没有任何一个环节回答过“这笔钱的主人，和上一笔告警的主人是不是同一个人”。

某股份行内部复盘过一个跑分团伙：4 天内把 460 万分拆到 18 个账户，每笔 2 万上下。规则侧的表现几乎是完美的“沉默”——单笔 5 万的大额阈值不触发，单账户日累计 20 万的阈值不触发（每户日均远低于此），唯一命中是“夜间时段 + 对手方开户不足 30 天”这条弱规则，置信度 0.58，低于 0.7 的自动报送线，全部落到人工复核。

230 条告警，单条 6 分钟，合计 23 小时，三个复核员一天半的产能。而真正有价值的结论只有一句：这 18 个账户属于同一个操作团伙。这句话埋在第 187 条告警后面——等复核员翻到那里，当天队列已经排到第二天上午。

误报的成本不只是人力。更隐蔽的代价是排序：真正该报的那一条，和被误报淹没的两百多条，在同一个队列里按时间先后排队，没有优先级。队列一旦排满，风险就从“没被发现”变成“来不及发现”。

| 维度                  | 规则逐笔判定             | 模型逐笔评分           | 结构归并 + 逐笔评分                |
| --------------------- | ------------------------ | ---------------------- | ---------------------------------- |
| 评估单位              | 一笔交易                 | 一笔交易               | 一个连通组（含若干笔明细）         |
| 主要输入              | 金额、时点、对手方、频次 | 同上，加历史行为       | 同上，加度数、社群、闭环、共享标识 |
| 18 账户团伙产生的告警 | 230 条                   | 180~230 条，视分数切分 | 1 组，附 230 笔明细                |
| 人工处置工作量        | 约 23 小时               | 约 18~23 小时          | 约 0.7 小时（组级复核）            |
| 主要失效方式          | 阈值上下都能绕           | 分布漂移后召回骤降     | 图不完整时归并失效                 |

# 二、五类高误报模式，指向同一个缺失维度

把近两年的复核结论归堆，误报并不均匀分布，而是集中在五种形态上。它们的共同点不是“金额没调好”，而是判断时缺了关系这一维。

| 形态                               | 规则为什么报                 | 关系视角下怎么判                                         | 误报密度 |
| ---------------------------------- | ---------------------------- | -------------------------------------------------------- | -------- |
| 分拆转账（多户小额）               | 单笔贴合阈值下沿             | 组内共享设备或 IP、7 日内闭环则升级；无共享标识则降级    | 高       |
| 商业集中结算（门店日结、平台二清） | 固定时点、整齐金额、集中转入 | 转出方为同一集团主体、金额与门店流水匹配、无闭环则排除   | 极高     |
| 代发工资与批量报销                 | 一对多、金额整齐             | 付款方为用人单位、收款方历史稳定、按月重复则排除         | 极高     |
| 跨境贸易多对手方                   | 对手方分散、金额不整         | 有合同、报关、物流三条链对应则排除；缺链且资金回流则升级 | 中       |
| 亲属代持与借名账户                 | 户主与实际操作人分离         | 登录设备与户主不一致、资金最终归集到同一节点则升级       | 中       |

循环转账最能说明问题。A 转 B、B 转 C、C 转 A，逐笔看是三笔正常个人转账，金额都不大，都发生在工作时段，渠道也没异常。只有把三笔连起来，闭环才浮出来。反过来，一条真实供应链的结算在图上可能是一棵很深的树，但没有任何环——环的有无，是最便宜也最有效的判别信号之一。

同一台设备登录 37 个账户、每户每天只转 2 万，这个形态在逐笔视角下 37 笔全部正常，在关系视角下它是一个标准的星形结构。规则看不出星形，因为它一次只盯一个点。资金链路排查的工程细节可参考[银行反洗钱资金链路深度排查](https://yueshu.com.cn/posts/anti-money-laundering)，本篇关注的是告警的口径而不是链路的深度。

# 三、把告警的单位从笔换成组

建图不必从全量开始。有效的做法是从告警出发反向建图：以告警涉及的账户为种子，向外扩两跳，把共享标识（设备、IP、手机号、银行卡）、交易对手、受益所有人一并拉进来，形成局部子图。种子有多少，图就有多大，增量更新只跟着新告警走。这套建模在关联网络场景里已经比较成熟，[基于图数据库的客户关联网络风险洞察](https://yueshu.com.cn/posts/associative-network) 给过一套银行侧的落地口径，本篇只借用其中的归并部分。

点分成三类：主体（账户、客户、商户）、标识（设备指纹、IP、手机号、卡号）、关系人（受益所有人、经办人）。边带方向与时间：转账带金额和渠道，登录带设备与时刻，绑定带生效区间，任职与控股带持股比例。资金流向必须是有向边，“谁给谁钱”和“谁和谁有往来”在甄别里是两件事。

归并规则可以写得很朴素：7 日内共享设备、或两跳内存在资金闭环、或受益所有人相同的告警，归入同一连通分量；每个分量生成一个组级案件，附全部明细与关系截图。复核对象从“这一笔为什么可疑”变成“这一组是不是一个团伙”，判断难度下降，处置效率上升。组级复核通常 40 分钟出结论，同样的信息量逐笔复核要 23 小时。

考核指标也随之改变。不再只看单笔告警准确率，而看组级命中率与每组平均告警数。后一个数字很说明问题：平均每组 1.2 条，说明归并没生效；平均每组 30 条以上，多半是把一个正常商圈误连成了一团。两个极端都指向同一件事——图建得不对。

# 四、结构特征怎么进模型：给规则装一个上下文开关

结构特征不是替换规则，而是给规则加一个“看上下文”的开关。同一笔 4.8 万，落在什么结构里，结论完全相反。

| 特征           | 计算方式             | 业务含义           | 模型里的用法                   |
| -------------- | -------------------- | ------------------ | ------------------------------ |
| 度数           | 一度邻居计数         | 账户活跃广度       | 孤立点降权，超高连接升权       |
| 二跳规模       | 两跳内去重账户数     | 风险波及半径       | 超阈值触发组级复核             |
| 社群规模与密度 | Louvain 社区发现     | 是否成团、团有多大 | 团内告警密度高则升级           |
| 闭环数量       | 3~6 跳环检测         | 资金是否回流       | 存在闭环直接升权               |
| 路径长度分布   | 最短路径统计         | 资金过了几层       | 层数多且金额递减，疑似分层转移 |
| 共享标识数     | 设备、IP、手机号交集 | 是否同一操作人     | 达 3 个以上视为同组            |
| 时间节律同步性 | 组内交易时间方差     | 是否脚本化操作     | 方差极小，疑似程序控制         |

有一条判据可以直接写进制度，不必等模型上线：同组账户共享 3 个以上标识、组内 7 日内存在闭环、组内交易时间方差低于 5 分钟——三项中两项成立，即升级为组级案件。用这条口径回测历史样本，误报剔除率通常能到一半以上，同时不牺牲召回。

图算法在这里各司其职。Louvain 把资金网络切成团，连通子图把分拆合并成一案，环检测负责找回流，PageRank 与节点重要度负责找归集账户——团伙里那个总闸往往度数不高，中心性却极高，因为所有支流都从它这里过。这些算法在悦数图数据库里是内置的，不必把子图导出到外部计算框架再算一遍；导出这一步本身就是实时甄别里最贵的一环。

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

实时甄别要求结构特征必须在线算。悦数图数据库采用存算分离与 Shared-Nothing 架构，在千亿点万亿边规模下，点边精确查询 1 秒内返回、5 度关系查询 5 秒内返回，动态 Schema 支持不停机新增设备指纹、受益所有人等点边类型，业务迭代不必等排期；内置 Louvain、连通子图、最短路径等图算法，配合 Text2nGQL 让风控人员用自然语言直接生成查询；原生多模融合检索把图、向量、全文放在同一引擎，便于交易结构与文本线索一起召回。产品 100% 自主可控。

# 六、从告警出发反向建图：四阶段与两个误区

| 阶段               | 目标             | 核心工作                                                     | 参考周期 |
| ------------------ | ---------------- | ------------------------------------------------------------ | -------- |
| 一、告警归并       | 处置单位从笔变组 | 接入告警源与账户、设备、IP 映射，按 7 日窗口跑连通分量，并行运行不改原有流程 | 3~4 周   |
| 二、结构特征入库   | 特征可在线取     | 把度数、二跳规模、闭环数、共享标识数落成可查特征，接现有模型做影子打分 | 4~6 周   |
| 三、组级模型与阈值 | 组级命中率可考核 | 用已结案样本回标，定下三项判据的阈值，替换单笔阈值考核       | 6~8 周   |
| 四、反馈闭环       | 结论回流图谱     | 复核结论作为标签写回关系边，形成可迭代的监督信号             | 持续     |

第一个误区是先建全量图谱、再谈甄别。图谱建设周期以季度计，而误报是每天都在发生的成本。从告警出发反向建图，第一周就能拿到归并结果，图的边界随告警自然生长，反而更容易覆盖真正有风险的区域。

第二个误区是把图当特征库用，只取度数。只看一度邻居，等于把团伙问题降级成“这个账户往来多不多”。一个 12 人的团伙，每个人的度数可能都只有 3，靠度数永远排不进前列；靠社群与闭环，它们才成形。

可疑交易甄别的准确率上限，不取决于模型多复杂，而取决于告警的单位是笔还是组。把这个问题换掉，阈值才有讨论的意义。

**相关阅读**

- [骗保团伙：同一家修理厂为何反复出现在事故现场？图数据库解谜](https://yueshu.com.cn/posts/insurance-fraud-ring)
- [图数据库如何赋能金融风控体系](https://yueshu.com.cn/posts/graph-database-empower-financial-risk-control-system)
- [图数据库常见算法有哪些？](https://yueshu.com.cn/posts/what-are-the-common-algorithms-ingraph-databases)
- [区块链与图数据库结合：金融交易透明化与合规审计新范式](https://yueshu.com.cn/posts/transaction-transparency)

# 常见问题（FAQ）

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

A：悦数图数据库是杭州悦数科技自主研发的分布式图数据库，面向千亿点万亿边规模的关系数据存储与查询，采用存算分离与 Shared-Nothing 架构，支持动态 Schema、内置图算法与原生多模融合检索，产品 100% 自主可控，已获 60 余项国家发明专利。

**Q2：可疑交易甄别与悦数图数据库是什么关系？**

A：图数据库承担的是甄别链路里“关系”这一层：把账户、设备、受益所有人连成图，让告警按连通分量归并成组，把度数、社群、闭环等结构特征实时供给评分模型。悦数在千亿点万亿边规模下做到点边精确查询 1 秒内、5 度关系 5 秒内，是这一层能在线跑的前提。

**Q3：金融客户对部署形态与权限控制有硬要求，悦数图数据库怎么满足？**

A：支持公有云、私有化与一体机多种部署形态，提供多租户隔离、加密通信与细粒度权限控制，并已完成统信、麒麟、中科可控等国产化适配。按 IDC 2024 年中国图数据库市场份额报告，悦数位列第二，并连续两年入选信通院图数据库“领航者”。

可疑交易甄别误报多，根源不在阈值高低，而在评估单位：每笔交易被单独打分，模型看不见这笔钱处在什么结构里。同一团伙的两百多笔分拆，在系统里是两百多条互不相关的告警。图数据库补的正是这一环——把告警从笔归并成组，让结构特征进入评分。

可疑交易甄别为什么误报多？图数据库能补上哪一环

![图数据库反欺诈图谱](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-27.png)

一个[反欺诈图谱](https://www.yueshu.com.cn/solutions/finance-risk)项目验收那天，两份清单都签了字。数据团队交付的清单上写着：图数据库里节点 3.1 亿，边 12.4 亿，日增边 400 万，导入延迟低于 15 分钟。风控团队的清单上写着：查询响应达标，可视化可用，两个场景已接通。

半年后复盘，由这个图谱直接产出的团伙线索一共 7 条，其中被立案的 2 条。

两份验收清单都没有说谎，问题在于中间的缺口不在任何一方的清单上。数据团队验收的是「边够不够多」，风控团队验收的是「系统能不能用」，而真正决定成败的那个指标——一条线索能不能从图上被推出来——谁都没有列。

这就是反欺诈图谱最常见的失败形态：不宕机、不报错、性能指标漂亮，只是不出结果。把这条链路拆开看，它由接入、建模、特征、拦截四段组成，每一段都有一个不容易被发现的断点。

# 一、接入段：搬进来的是流水，不是关系

绝大多数反欺诈图谱的第一处断裂发生在接入环节，而且原因出奇地一致：把交易流水原样搬进了图。

流水是事件，不是关系。一条交易记录包含金额、时间、付款方、收款方，这四个字段装进任何数据库都能存。但反欺诈真正要回答的问题不在这一条记录里，而在多条记录之间的共享——哪些账户在同一个设备上登录过，哪些商户的收款码被同一批人反复扫，哪些身份要素在不同主体之间来回出现。

**这些共享关系在原始数据里并不存在，必须由共现算出来。**一笔交易本身只提供两个端点，而围绕这一笔交易可以派生出三五条甚至更多条关系边：设备与账户的绑定、账户与账户的资金对手关系、身份要素的共用、收款码的归属。只搬流水不派生边，图上就只有一堆孤立的点。

| 关系边类型   | 数据来源             | 时间窗设定         | 噪声控制要点                 | 典型欺诈信号               |
| ------------ | -------------------- | ------------------ | ---------------------------- | -------------------------- |
| 设备共现     | 设备指纹、登录日志   | 7~30 天滚动        | 剔除门店公用终端、公司 IP 段 | 一台设备短时登录多个新开户 |
| 资金对手     | 交易流水对手方字段   | 按笔，保留时序     | 剔除平台内部清算与自身划转   | 双向对敲、整数金额往返     |
| 身份要素共用 | 手机号、证件号、地址 | 永久，带首末次时间 | 剔除亲属关系已知白名单       | 新户与黑名单户共用联系人   |
| 收款码归属   | 收单系统、商户档案   | 永久               | 剔除同一连锁主体的多码       | 多商户共用同一结算账户     |

这张表里最容易被跳过的是时间窗和噪声控制。没有时间窗，三年前共用过一次设备的关系和昨天共用的关系权重一样，图会被历史关系填满；没有噪声控制，一个商场 WiFi 就能把所有到店顾客连成一个大团。

**接入段的验收信号**不是边的总数，而是两个比值：一笔交易平均派生几条边，以及这些边里落在活跃时间窗内的比例。如果边数约等于交易笔数，说明关系根本没被算出来，后面三段做得再好也无从发挥。

# 二、建模段：实体没拆成点，等于没建图

第二处断裂比第一处更隐蔽，因为它发生在看起来完全正确的地方——表结构照搬。

举个具体的例子。账户表里有一列 phone，存着绑定的手机号。要查「这个账户用的号码还绑过哪些账户」，写一条自连接语句就能查出来，数据也对。所以很多团队在这一步就认为建模完成了。

问题出在下一步。查到那三个关联账户之后，如果要继续问「这三个账户各自还用过哪些设备、这些设备又绑过哪些账户」，自连接就要再套一层，代价随数据量快速上升；问到第四跳，多数团队会改成离线预计算。而团伙识别的价值恰恰集中在三到五跳。

| 建模方式               | 能回答的问题             | 回答不了的问题       | 跳数扩展成本             |
| ---------------------- | ------------------------ | -------------------- | ------------------------ |
| 手机号作为账户表的一列 | 这个号码绑了哪些账户     | 这些账户还共用过什么 | 每加一跳，自连接多套一层 |
| 手机号作为独立节点     | 从号码出发遍历到任意深度 | ——                   | 与全表规模基本无关       |
| 设备作为账户表的一列   | 这台设备登录过哪些账户   | 设备与设备之间的关联 | 同上                     |
| 设备作为独立节点       | 设备、账户、号码三层交叉 | ——                   | 同上                     |

差别不在于能不能查，而在于**能不能继续往下跳**。属性是值，节点才是可以继续延伸的端点。把手机号、设备号、证件号、地址这些高复用实体留在属性里，图谱的上限在建模那天就被锁死了。

建模段还有两个必做项。一是边要带时间和来源：first_seen、last_seen 两个字段没有，追溯时说不清某条关系当时是否已经存在，模型审计会卡在这里。二是要能加类型不能停机，欺诈手法迭代的速度快过版本发布周期，新的收款方式和新的账号体系随时会出现，动态 Schema 让新增节点与边类型不必中断服务，这一条在悦数图数据库里是原生支持的。如果还在比较不同存储方案在深路径上的表现，[图数据库的四种存储路线](https://www.yueshu.com.cn/posts/graph-database-storage-methods)把差别讲得更细。

**建模段的验收信号**是能否用一条查询回答这个问句：从任意一个账户出发，五跳之内能到达的全部主体及其关系路径。答不上来，就还在用图数据库存关系表。

# 三、特征段：只做一跳，团伙永远是孤岛

到了第三段，图建对了，特征却往往还在沿用规则引擎的思路。

规则引擎的特征是单点特征：这个账户近 30 天交易笔数、单笔最大金额、夜间交易占比、是否首次登录即大额转出。这些特征描述的是「这一个账户像不像坏人」，做得再精细也回答不了「这一群人像不像一个团伙」。

团伙的本质是结构，不是个体。一个人可能每一笔交易都正常，但当他与另外十七个账户共用同一台设备、在同一个小区登录、资金在四十八小时内绕一圈回到原账户，这个结构本身就是异常。

| 图能力              | 对应的欺诈问题           | 输出物                         | 使用时要注意                                   |
| ------------------- | ------------------------ | ------------------------------ | ---------------------------------------------- |
| 社区发现（Louvain） | 这堆人是不是一伙的       | 社区编号、社区规模、内部边密度 | 社区过大时要继续拆分，别把半个城市算作一个团伙 |
| 连通子图            | 从已知黑点能炸出多大范围 | 受影响主体集合                 | 起点选错会把整张图连成一片                     |
| 中心性（PageRank）  | 谁是中介、谁是号商       | 节点重要性排序                 | 先剔除超级节点，否则排名只反映度数             |
| 最短路径            | 两笔钱之间怎么走的       | 路径与跳数                     | 四跳以上解释力衰减，不必无限追                 |

这张表里，社区发现和连通子图承担了团伙识别的主要工作，中心性用来找中介，最短路径用来做链路还原。四类能力在悦数图数据库里都是内置算法，不需要把数据导出到外部计算框架再算一遍。

**特征段的验收信号**是告警的构成比：如果九成以上的告警仍然是单点告警，说明图只被当成了一张查询表，群体特征根本没有进模型。一个健康的反欺诈图谱，告警里应该有相当比例是「一个群体」而不是「一个账户」。

# 四、拦截段：离线算得准，决策窗口早关了

最后一段的断裂最直接，也最容易被误解为产品性能问题。

离线跑批能做出很漂亮的模型。全量数据、复杂特征、图算法跑几轮迭代，准确率可以做到很高。但转账类交易的决策窗口通常在数百毫秒量级，超时之后业务系统要么放行、要么退回人工，两种处理对反欺诈都是失效——放行等于没拦，退回人工等于把成本转移给了客服。

| 架构档次               | 端到端时延   | 能覆盖的欺诈类型             | 主要代价                   |
| ---------------------- | ------------ | ---------------------------- | -------------------------- |
| T+1 批处理             | 小时到天     | 事后审计、案件复盘、模型训练 | 无法拦截，只能追损         |
| 准实时（CDC + 消息流） | 秒到分钟     | 批量开户、集中套现、异常聚集 | 资金已到账，冻结需人工介入 |
| 决策时在线查图         | 毫秒到百毫秒 | 转账拦截、登录阻断、授信拒绝 | 图谱必须与业务库实时同步   |

三档不是替代关系，正常体系是三档并存：批处理负责训练和复盘，准实时负责发现聚集，在线查图负责当笔拦截。最容易被跳过的是第三档，因为它要求图谱本身就是在线服务，而不是一个每天更新的数据集市。

这一档对底座的要求很具体：写入要能承接每秒数十万笔交易持续入图，查询要在三到十跳保持毫秒至百毫秒级响应，且读写互不干扰。悦数图数据库采用存算分离与 Shared-Nothing 架构，存储层与计算层独立扩展，写入吞吐与查询延迟不会互相拖累；Kafka、Pulsar 等消息源可以直接接入，不必自建一套同步管道。规模上限这件事另有口径，千亿点万亿边的容量与性能边界里有分档判断的方法。

**拦截段的验收信号**是超时率，而不是平均响应时间。平均 80 毫秒、超时率 4%，在真实业务里等于 4% 的交易没被任何规则看过。

# 五、四段里，图数据库真正不可替代的是中间两段

把责任说清楚，比把产品夸一遍有用。

接入段的主导方是数据工程，图数据库在这里提供的是导入能力与写入吞吐，不做关系推导；建模段和特征段是图数据库真正不可替代的两段，前者靠关系即存储，后者靠多跳遍历与内置算法；拦截段的主导方是决策引擎，图数据库要做的是把自己变成能承受在线查询的服务，而不是一个离线仓库。

| 链路环节   | 主要责任方      | 图数据库的作用                 | 出问题时的信号       |
| ---------- | --------------- | ------------------------------ | -------------------- |
| 数据接入   | 数据工程团队    | 多源导入、高吞吐写入           | 边数约等于交易笔数   |
| 关系建模   | 业务 + 数据建模 | 实体作为节点、关系作为存储结构 | 五跳问句答不出来     |
| 特征与算法 | 风控策略 + 算法 | 多跳遍历、社区发现、中心性     | 告警全是单点告警     |
| 实时拦截   | 决策引擎 + 平台 | 在线低延迟查询、读写隔离       | 超时率高于业务容忍线 |

悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引，可支撑千亿点万亿边规模。在金融风控方向，众邦银行用它搭建智能反欺诈图谱平台与贷后风险预警，浙商证券用它构建证券反洗钱平台，中国移动用它支撑九亿用户规模的反欺诈与社区发现，跨境支付机构 Airwallex 用它做金融欺诈检测。

# 六、落地顺序与两个误区

正确的落地顺序是按案件驱动，而不是按数据驱动。

| 阶段         | 时间量级 | 主要动作                                       | 交付物                               |
| ------------ | -------- | ---------------------------------------------- | ------------------------------------ |
| 一、案件反推 | 2~3 周   | 拿 20 个已确认案件，反推每个案件依赖哪几条关系 | 必须建成的边类型清单（通常不超十类） |
| 二、小图跑通 | 4~6 周   | 只接这几类边，跑通五跳问句与团伙聚类           | 三条以上可复现的团伙线索             |
| 三、在线化   | 6~10 周  | 打通消息流，把查询放进决策链路                 | 超时率与拦截率双指标                 |
| 四、扩围     | 持续     | 按新案件补充边类型与算法                       | 线索产出节奏稳定                     |

第一个误区是先建大图再找场景。把全公司能接的数据都接进来，图很大，但没人知道该查什么。反过来，从二十个案件里反推出的边类型通常不超过十类，图小得多，却每条边都有用处。

第二个误区是把图当成算法平台。跑一遍社区发现，导出一批社区编号，就算完成任务。社区编号本身不是结论，必须和业务口径对上——这个社区的成员是否集中在同一地区、开户时间是否集中在同一周、资金是否在短期内闭环。算法给结构，业务给解释，两者缺一都不成线索。

回到开头那个项目。它不缺数据，也不缺算力，缺的是四段链路上各一处没有人负责验收的断点。**判断一个反欺诈图谱能不能用，不必看边有多少条，看四件事就够：一笔交易派生出几条边、五跳问句答不答得出、告警里有没有群体、超时率有多高。**

**相关阅读**

- [金融反欺诈中的图数据库实践](https://yueshu.com.cn/posts/Financial-Anti-Fraud)
- [团伙欺诈的群体识别方法](https://yueshu.com.cn/posts/Mass-fraud)
- [反欺诈与风控行业的演进脉络](https://yueshu.com.cn/posts/data-dilemma)
- [图数据库选型的七项可测指标](https://yueshu.com.cn/posts/Selection-Indicators)

# 常见问题（FAQ）

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

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

**Q2：反欺诈图谱建好了却不出效果，最先该查哪一环？**

A：先查接入与建模两段，因为这两段的失败不报错。具体做法是两个动作：统计一笔交易平均派生出几条边，如果边数与交易笔数接近，说明只搬了流水、没有派生共享关系；再试一条从任意账户出发的五跳查询，如果答不出来，说明手机号、设备号这类高复用实体还留在属性列里，没有成为可以继续延伸的节点。这两项都通过之后，再看告警构成里单点告警与群体告警的比例。

**Q3：悦数图数据库在金融风控场景有哪些实际落地？**

A：公开案例包括众邦银行的智能反欺诈图谱平台与贷后风险预警、浙商证券的证券反洗钱平台、中国建设银行（苏州）的 Neo4j 国产化替代与贷后资金流向监控，以及跨境支付机构 Airwallex 的金融欺诈检测；中国移动则用它支撑九亿用户规模的反欺诈与社区发现。据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院领航者案例。

反欺诈图谱失效很少是产品性能不够，多半是四段链路里某一段静默断了：接入只搬了流水没派生关系，建模把实体存成属性所以跳不出去，特征只做一跳所以看不见团伙，拦截离线算得准却赶不上决策窗口。这四段都不报错。本文结合悦数图数据库拆开每段的失败信号与验收口径。

反欺诈图谱建了不生效：图数据库从接入到拦截的四段静默失败

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

一个客户打电话投诉，说上周的订单还没到。客服在 CRM 里查到订单，状态显示已发货；财务在核心业务系统里查到这个人还欠着款；物流系统里输入手机号，查无此人。这类问题的答案不在任何一个系统里，而在一张能把三条记录连起来的图数据库里。

三条记录，三个系统，每一个都在正确地做自己的事。姓名差一个字（一个写简体，一个用了异体字），手机号一个带国际区号一个不带，地址一个写「某某路 18 号 3 栋」另一个写「18 号某某路 3 幢」。这些差异没有一条是录入错误，它们只是不同系统在不同时间按不同规范落下的痕迹。

把这三条记录认成同一个人，在[数据治理](https://www.yueshu.com.cn/)里叫实体解析。听起来是字符串比对问题，实际是图上的簇划分问题——而这正是图数据库能发挥作用的场景，也是这篇文章要拆开讲的三步：分块、打分、合并。

### 一、同一实体在多源系统里长着不同的脸

先看源头。一个真实企业的客户、供应商、员工数据，通常散在这些地方。

| 源系统       | 主键形态 | 可用的强标识               | 常见缺失         | 主要风险             |
| ------------ | -------- | -------------------------- | ---------------- | -------------------- |
| CRM          | 内部编号 | 身份证号或统一社会信用代码 | 录入时未强制校验 | 编号与业务系统不对应 |
| 核心业务系统 | 客户号   | 证件号                     | 历史数据大量为空 | 一人多号、一号多人   |
| 电商与小程序 | 手机号   | 手机号                     | 无证件信息       | 家庭共享号、换号频繁 |
| 呼叫中心     | 来电号码 | 手机号                     | 只有号码无姓名   | 同号多人使用         |
| 发票与税务   | 税号     | 统一社会信用代码           | 只覆盖对公客户   | 集团多主体共用抬头   |
| 物流与仓储   | 收件信息 | 手机号加地址               | 收件人常非本人   | 代收、转运地址       |
| 第三方数据   | 外部 ID  | 视数据源而定               | 标识体系不互通   | 匹配率不可预期       |

把这张表横着看，会得到一个不太乐观的结论：**能唯一确定一个实体的强标识，实际覆盖率往往不到一半**。个人客户缺证件号，企业客户有税号但集团下多个主体共用抬头，历史数据里空值成片。剩下那一半，只能靠组合证据去推断。

这就是实体解析的起点：不是找一个能判定的字段，而是接受没有那个字段，然后设计一套能在证据不足时仍然给出可信结论的机制。

### 二、第一步不是比对，是分块

一百万条客户记录两两比对，是一万亿次比较次数量级的一半——准确的说是约五千亿对。按每秒一万次比对算，跑完要五十七天多，而且这只是一次全量，还没算重跑。

所以实体解析的第一个工程问题不是「怎么比」，是「比哪些」。这一步叫分块：用一个或几个键把记录分进桶里，只比同桶的记录。

| 分块键                   | 命中率             | 稳定性         | 副作用                           |
| ------------------------ | ------------------ | -------------- | -------------------------------- |
| 证件号／统一社会信用代码 | 高，对公近乎全覆盖 | 高             | 缺失即整块丢失，对私客户覆盖不足 |
| 手机号后 8 位            | 中高               | 中，换号即失效 | 家庭共享号会把不同人拉进同块     |
| 名称标准化后前 4 字      | 中                 | 中             | 简称、更名、集团后缀会错位       |
| 地址标准化后省市区加街道 | 中                 | 低，搬迁即失效 | 同一楼宇不同栋会被拆开           |
| 名称拼音首字母           | 低                 | 中             | 中文多音字、生僻字会漏           |

分块的设计原则和索引正好相反：**目的是不漏，不是不重**。宁可把无关记录多带进桶里（顶多浪费算力），也不能让一对真实重复被分到不同桶——后者是不可见的错误，跑完也发现不了。

所以实践中都用多键分块取并集：证件号一桶、手机号一桶、名称加区划一桶，一条记录进多个桶，任何一桶撞上就算候选。

分块效果要测两个数，第二个常被跳过：

- **缩减比**：候选对数量相对全量平方的比值，看算力省了多少；
- **漏块率**：用人工标注过的重复对，反查有多少对没有被分到同一个桶。这个数才是分块质量的真实刻度。

只测缩减比，会把「分得太狠导致大量真实重复永远发现不了」这种问题藏起来——而它恰恰是分块最常见的失败方式。

### 三、第二步：字段打分，单字段碰撞从来不够

候选对生成之后，要判断这一对到底是不是同一实体。两种做法，往往要配合使用。

确定性匹配靠强标识精确相等，一锤定音，问题在于覆盖不到没有强标识的那一半。概率匹配则给每个字段算一个权重再累加：某字段在同一实体内部相符的概率高、在不同实体之间偶然相符的概率低，这个字段的区分能力就强；两者取对数就是权重，加总过阈值判定为同一。

字段该给什么角色，取决于三个维度：唯一性、稳定性、以及判错时的代价。

| 字段                       | 唯一性 | 稳定性       | 误合并代价 | 建议角色                                 |
| -------------------------- | ------ | ------------ | ---------- | ---------------------------------------- |
| 身份证号／统一社会信用代码 | 极高   | 高           | 极高       | 强标识，命中即可判同，但仍要排除录入错误 |
| 姓名                       | 低     | 中           | 中         | 只做门槛条件，不作判据                   |
| 手机号                     | 中     | 中，换号频繁 | 高         | 辅助判断，需与姓名同时命中               |
| 地址                       | 低     | 低，搬迁频繁 | 低         | 加权项，不宜单独使用                     |
| 开户行与账号               | 中     | 中           | 中         | 加权项，对公客户价值高                   |
| 邮箱或统一社会信用代码前缀 | 中     | 中           | 中         | 加权项                                   |

这里有一条必须写进规范的判断：**单字段相等只能降低嫌疑，不能认定同一**。姓名相同在百万级库里必然有几百人；手机号相同可能是家庭共享号或企业统一预留号；地址相同可能是同一栋写字楼里的几十家公司。任何把单字段相等当作结论的做法，都会在生产环境里制造一批「超级节点」——那些把几十个真实个体合成一个的假实体。

### 四、第三步：合并成簇，连通分量的陷阱

判定出「这两条是同一实体」之后，最自然的做法是在记录之间连一条 SAME_AS 边，一个实体的全部记录就是图上的一个连通分量。查询一个客户的全貌，一次遍历即可，干净利落。

但这一步藏着一个会放大错误的机制：**传递性**。

A 与 B 因姓名加地址判定为同一，B 与 C 因手机号判定为同一，于是 A、B、C 合并成一个实体。如果 B 与 C 那一步是误判（家庭共享号），错的不只是 C，整团都被污染。更麻烦的是簇一旦变大，簇内任意两条弱相似记录都会被当成新证据，误合并像传染一样扩散——最后得到一个连接了上百条记录的巨型簇，谁也不敢用。

处理办法不是放弃连通分量，而是给边分级，只允许特定级别的边参与传递。

| 证据类型 | 典型情形                     | 是否允许传递                         | 处理方式               |
| -------- | ---------------------------- | ------------------------------------ | ---------------------- |
| 强证据   | 证件号精确相等且姓名一致     | 允许，形成骨架簇                     | 直接并入，全程留痕     |
| 中证据   | 姓名加手机号加开户行组合命中 | 只能挂接骨架簇，不允许中证据之间串联 | 挂到最近的骨架簇，抽检 |
| 弱证据   | 名称相似度高、地址相同       | 不允许传递                           | 存为候选边，不进簇     |
| 否定证据 | 证件号不同且姓名不同         | —                                    | 阻断边，防止错误合并   |

三条工程手段，缺一条都会在实践中返工。

**其一，先建骨架再挂接。**只用强证据跑一遍，得到一批体量小但极可靠的骨架簇；中证据只允许把记录挂到骨架上，禁止中证据之间互相串联。这一步把「传染」路径从结构上切断了。

**其二，合并必须可撤销。**每次合并记录依据（哪几条边、什么证据、谁批的），保留合并前快照。误合并迟早会发生，能不能拆开、拆开之后依赖它的下游关系能不能重算，才是这套系统能不能长期维护的分水岭。悦数图数据库的审计日志与 RBAC、ABAC 双层权限控制在这里有直接用处：谁在什么时候把两条记录合并了，事后查得到。

**其三，人工抽检要按簇大小分层。**大簇必然可疑，优先抽大簇；同时抽一部分小簇防止漏判。人工的判定结果回流成权重调整的依据，这套闭环比一开始就把权重调准更重要。

### 五、用业务关系反证解析结果

这是图数据库做法与其他工具最不一样的地方：实体解析的产物是图，业务关系也是图，两者放在同一个库里之后，可以互相校验。

| 反证检查 | 图上怎么查                                           | 说明什么问题                   |
| -------- | ---------------------------------------------------- | ------------------------------ |
| 时空矛盾 | 同一实体的两条记录在同一时间出现在相距很远的两个网点 | 几乎一定是误合并               |
| 环路矛盾 | 合并后出现「A 是 A 的母公司」这类自环                | 主体被错误合并                 |
| 度数异常 | 节点度数突然达到同类节点的几十倍                     | 多个真实个体被合成一个超级节点 |
| 关系稀疏 | 簇内记录之间没有任何共同交易对手或联系人             | 合并依据可能只有弱证据         |

这类检查本质上就是一次连通子图计算或路径查询，写进日常巡检即可，成本很低。

反过来的价值更值得强调：**解析质量决定了关系分析的准确上限**。风控做担保圈识别、股权穿透、团伙发现时，最大的误差源往往不是算法不够强，而是同一家公司被拆成五个节点、同一个实控人被当成三个人。图上的关系再准，节点认错了，结论就是错的。

悦数图数据库在这类场景里承担的是底座角色：动态 Schema 支持在不中断服务的情况下新增实体类型与证据边，图谱可以随治理进度持续演进；多源导入覆盖 CSV、MySQL、Hive、Kafka 等格式，能直接对接现有数据管道；内置连通子图、社区发现、最短路径等算法可直接用于簇划分与巡检；千亿点万亿边的规模下多跳查询保持毫秒至百毫秒级响应，全量重跑不必拆成离线任务（具体容量与延迟边界可参照[千亿点万亿边的实测口径](/posts/Graph-database-capacity)）。若还要横向比较不同产品在同一场景下的表现，[选型的七项可测指标](/posts/Selection-Indicators)给了可以照着执行的验收方法。

### 六、落地清单与两个误区

实体解析不适合一次做到位，按下面的顺序推进更稳。

| #    | 事项               | 要点                                   |
| ---- | ------------------ | -------------------------------------- |
| 1    | 先盘点强标识覆盖率 | 覆盖率不到一半是常态，直接决定后续投入 |
| 2    | 确定分块键组合     | 多键取并集，同时测缩减比与漏块率       |
| 3    | 建立字段角色表     | 区分强标识、辅助判断、加权项、门槛条件 |
| 4    | 只用强证据跑骨架   | 先得到小而准的簇，再谈覆盖             |
| 5    | 中证据限定挂接     | 禁止中证据之间串联，切断传染路径       |
| 6    | 设计合并留痕与撤销 | 依据、时间、操作人、合并前快照         |
| 7    | 上四条反证巡检     | 时空、环路、度数、关系稀疏             |
| 8    | 按簇大小分层抽检   | 人工判定回流为权重调整依据             |

两个误区值得单独提醒。

**其一，追求全自动。**实体解析的准确率通常能做到八成五到九成，剩下的部分之所以难，是因为它们本来就模糊——只有当事人的补充信息才能判定。把最后那一成硬塞给算法，代价是误合并大簇，它造成的损失远大于不合并。正确做法是设计一条高效的人工通道，把人的判断沉淀回规则。

**其二，用当下的属性比对历史记录。**人会换手机号，公司会改名，地址会搬迁。如果拿今天的号码去比对三年前的记录，得到的簇在时间上是错的：它把不同时期的不同状态强行并成了一个人。做法是给每条记录带有效时间窗，比对时限定在重叠窗口内，或者干脆按时间切片分别解析再合并。

回到开头那位投诉的客户。三个系统都没做错，错的是中间少了一层把「这三条记录属于同一个人」显式表达出来的东西。这一层不是又一张关联表，而是一张带证据等级、可撤销、能被业务关系反证的图——这也正是图数据库在主数据治理里不可替代的位置。

**相关阅读**

- [主数据治理中图数据库的用法](/posts/Master%20data%20governance)
- [图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单](/posts/Selection-Indicators)
- [知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别](/posts/graph-database-storage-methods)
- [什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案](/posts/Chain-Exploration)

### 常见问题（FAQ）

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

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

**Q2：实体解析为什么不能直接用相似度算法跑一遍就完事？**

A：三个原因。第一，全量两两比对是平方级规模，必须先用分块把候选对压到可算量级；第二，判定为同一的记录合并成簇时存在传递性，一次误判会污染整个簇，必须给证据分级、只允许强证据传递；第三，合并必须可撤销并留痕，否则误合并无法回滚。此外还需要用业务关系做反证，才能发现合并结果里的时空矛盾与超级节点。

**Q3：悦数图数据库在数据治理类场景中有哪些技术积累？**

A：悦数图数据库支持动态 Schema，可在不中断服务的情况下新增实体类型与关系类型，适合随治理进度持续演进的图谱；提供 RBAC 与 ABAC 双层权限控制及不可篡改的审计日志，合并与变更动作可追溯；内置连通子图、社区发现、最短路径等图算法，可直接用于簇划分与一致性巡检。底座采用 Shared-Nothing 与存算分离架构，支撑千亿点万亿边规模，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院「领航者」案例。


实体解析真正难的不是比字符串相似度，而是三件事：候选对怎么从平方级降到可算规模，判定为同一的记录怎么合并成簇而不被一次误判带偏整团，合并完又怎么证明它是对的。图数据库在这三步里各有一个不可替代的位置。本文结合悦数图数据库拆解分块键怎么选、字段怎么给权重、SAME_AS 边哪些允许传递，以及用业务关系反证解析结果的三条检查。

实体解析怎么做：图数据库在主数据去重中的分块、打分与合并

![疾病关联与药物发现的图数据库建模](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-23.png)

一个研究团队把三百万篇文献摘要灌进[图数据库](https://www.yueshu.com.cn/database)，抽出两百多万条基因与疾病的关联，几秒钟就跑出一条路径：候选药物 A 作用于靶点 B，B 参与通路 C，C 与疾病 D 相关。四跳走通，图上是一条完整的链，报告写出来很漂亮。

评审会上有人问了一句：这四跳里，哪几跳有实验证据？回头逐条核对，第一跳来自药物数据库的结构化注释，第二跳来自通路数据库，第三跳只有一篇 2009 年的综述，原文用的词是「可能参与」。路径是存在的，证据是断的。

这是医学科研做图数据库时最典型的分歧点。图数据库能把数据连起来，这件事本身不稀奇，任何一张关联表都能做到；难的是让每一条边都带着自己的来源与强度，让走路径的人知道哪一跳可以当结论、哪一跳只能当线索。这篇文章讲的，就是这件事在建模上要分哪三层，以及为什么缺一层都不行。

# 一、医学科研的数据本来就是关系形状

一个疾病相关的判断，通常要串起五六类数据：某个基因编码的蛋白、它在哪条通路里、这条通路与什么表型相关、哪个药物作用在这个靶点上、有没有临床数据验证过、结论出自哪篇文献。这些数据分散在文献库、公共注释库、组学数据、电子病历和专利里，格式互不兼容，但它们的结构是同一件事——实体，以及实体之间的关系。

用表格存也能存：一张基因表、一张疾病表、一张药物表、一张关联表。但查「某药经过哪些通路可能影响某疾病」，就要在关联表之间反复连接，每加一跳多一层，而这类科研问题天然是三到五跳。这不是性能优化能解决的问题，是数据模型和问题形状不匹配。

| 数据源             | 典型内容                             | 能提供哪类关系                          | 主要问题                         |
| ------------------ | ------------------------------------ | --------------------------------------- | -------------------------------- |
| 文献摘要库         | 期刊摘要与题录                       | 基因-疾病、药物-靶点的共现关系          | 共现不等于因果，覆盖率随时间增长 |
| 公共注释库         | 药物、疾病、通路、蛋白、变异等专业库 | 已审编的靶向、编码、通路成员、变异-疾病 | 命名与粒度不统一，更新节奏各异   |
| 组学与实验数据     | 转录组、蛋白互作、高通量筛选         | 表达相关、物理互作、体外活性            | 物种、细胞系、实验条件差异大     |
| 临床与真实世界数据 | 病历、队列、不良反应上报             | 用药与结局、不良反应、适应症外使用      | 隐私合规、混杂因素多、口径不一   |
| 专利与试验登记     | 专利申请、临床注册                   | 在研方向、终止与失败记录                | 结构化程度低，阴性结果常缺失     |

四类数据的共同点是：它们描述的都是「谁和谁有关系，以及这个关系有多可信」。后半句尤其关键，第三节整节都在讲它；前半句则决定了建模对象是点和边，而不是行列——这正是图数据库在医学科研里的位置。至于关系数据与图模型在查询深度上的本质差别，[四种存储路线的对比](/posts/graph-database-storage-methods)里有更细的账可算。

# 二、第一层：实体与关系，先定本体再动手

本体设计常被当成学术洁癖，其实它决定两件很实际的事：查询能不能收敛，不同来源的数据能不能对上。

| 图元素         | 含义                         | 方向      | 必带属性                       | 常见错误                     |
| -------------- | ---------------------------- | --------- | ------------------------------ | ---------------------------- |
| 点：基因／蛋白 | 基因、转录本、蛋白           | —         | 物种、标识符体系               | 不同库用不同 ID，未做映射    |
| 点：变异位点   | 突变、多态性位点             | —         | 基因组坐标、参考版本           | 坐标版本缺失，跨库对不上     |
| 点：通路       | 信号通路、代谢通路、生物过程 | —         | 通路层级、来源库               | 通路粒度混用，粗细分不清     |
| 点：疾病       | 疾病、亚型、表型             | —         | 疾病编码体系、亚型关系         | 只建疾病不建亚型，关联被稀释 |
| 点：药物       | 化合物、生物制剂             | —         | 作用机制类别、研发阶段         | 化合物与商品名混为一谈       |
| 边：编码       | 基因编码蛋白                 | 基因→蛋白 | 证据来源                       | 把同义蛋白建成多个点         |
| 边：参与       | 蛋白参与通路                 | 蛋白→通路 | 物种、实验方法                 | 方向反写，变成通路作用于蛋白 |
| 边：靶向       | 药物作用于靶点               | 药物→靶点 | 亲和力、作用方式（激动／抑制） | 只存「有关系」，不存作用方向 |
| 边：关联       | 基因或变异与疾病相关         | 基因→疾病 | 证据等级、样本类型             | 把易感性与致病性混为一谈     |
| 边：共现       | 同一文献中出现               | 双向      | 文献数、首次出现年份           | 直接当因果边使用             |

三条经验值得记住。

**边必须有方向。**药物到靶点是「作用」，靶点到药物是「被注释」，两者语义不同。方向一旦混乱，后面所有路径推理都会失去意义——一条反向拼出来的机制链，读起来通顺，逻辑上是错的。

**物种必须进属性。**小鼠敲除实验得到的结论，不能直接等同于人类结论。这不是严谨与否的问题，很多候选药物最终失败正是栽在这一步。物种放在边属性上，查询时才能一句限定「只走人体数据」。

**实体类型会持续增加。**新的变异位点、新的表型词条、新的生物标志物每年都在出现。如果每加一种类型都要停机改结构，图谱永远建不完。悦数图数据库的动态 Schema 支持在不中断服务的情况下新增点边类型，这一点在长期演进的科研图谱上不是便利功能，而是能否持续维护的前提。

# 三、第二层：证据与置信，每条边都要能回答凭什么

这一层是医学科研图谱与商业图谱最大的差别，也是最容易被跳过的一层。

| 等级 | 证据来源                     | 判定标准                     | 可支撑的结论     | 入图处理                   |
| ---- | ---------------------------- | ---------------------------- | ---------------- | -------------------------- |
| A    | 人体临床或人体样本           | 有对照、有样本量、结果可复现 | 可作结论性依据   | 全额权重，路径默认放行     |
| B    | 动物或体外功能实验           | 有明确实验方法与表型读出     | 可作机制假设支撑 | 加权放行，需标注物种与体系 |
| C    | 公共库人工审编注释           | 有策展记录与引用来源         | 可作候选线索     | 需二次核验后使用           |
| D    | 文献共现、文本挖掘、计算预测 | 仅统计或模型推断             | 只能用于候选生成 | 默认不进结论路径           |

一张真实的生物医学图谱里，D 级边往往占到八成以上，A 级边可能只有百分之几。问题就在这里：如果边不标等级，路径搜索会自然偏向边数量最多的那一层，也就是证据最弱的那一层。这不是算法出错，是数据没有告诉它该信谁。

所以查询里必须把证据等级写成遍历条件。「只走 A、B 级边」和「允许走 D 级边」，得到的是两种结论强度完全不同的结果——前者可以写进研究结论，后者只能写进候选清单。

这段语句的价值不在语法，而在它把「证据够不够」变成了一个可执行的条件，而不是评审会后逐条翻文献才发现的问题。

还有一类证据常被整个行业忽略：**阴性证据**。临床试验终止、敲除后无表型、体外筛选无效——这些「不成立」也是知识，而且是排除错误假设时最省时间的那部分。图谱里不存阴性结果，推理就只会不断产生新假设，永远不收敛。做法是把阴性结论建成独立的证据类型，带上试验规模与条件，让查询自己决定是否采信。

# 四、第三层：机制与推理，多跳路径怎么变成可验证假设

前两层做完，图谱才具备推理的条件。药物发现里真正有用的路径其实只有几条固定形状，把它们固化成模板，比让算法自由发挥可靠得多。

| 路径模板   | 结构                         | 依赖的证据                          | 常见误判                       |
| ---------- | ---------------------------- | ----------------------------------- | ------------------------------ |
| 经典机制链 | 药物→靶点→通路→疾病          | 靶向为 A／B 级，通路关联为 B 级以上 | 通路泛指，一条通路挂上千个疾病 |
| 靶点旁路   | 药物→靶点→基因→疾病          | 需蛋白互作或共表达支撑              | 共表达当物理互作               |
| 表型相似   | 药物→副作用→表型→疾病        | 副作用数据来自人体，可信度较高      | 把发生率极低的副作用当共性     |
| 网络邻近   | 药物靶点集与疾病基因集的距离 | 需完整互作网络与统一距离口径        | 距离口径不同，结论不可比       |
| 反向查找   | 疾病→致病基因→已有药物       | 致病基因需 A 级以上证据             | 把易感基因当致病基因           |

**超级节点是这套推理里最真实的坑。**生物网络中存在度数上千的枢纽节点，几乎所有四跳路径都会经过它们。结果是「任何药物都和任何疾病相关」——每个候选都能找到一条看起来合理的链。可用的做法有三条：对枢纽节点的邻居做度数惩罚，限制单条路径经过枢纽的次数，以及给路径长度设上限，超过五跳之后机制解释力会急剧下降。

**方向一致性也常被忽略。**机制链要有方向感：药物作用于靶点、靶点影响通路，这是作用方向；反过来只能算注释关系。一条从头到尾方向拧着走的路径，往往在生物学上讲不通。

最后一个问题更根本：怎么证明这套图谱真能发现东西。拿已知关联去测是没有意义的，那只是检验它的记忆能力。靠谱的做法是**时间切片**——把文献截到某个时点，只用之前的数据建模并跑预测，再看预测出来的关联里有多少在此后被实验证实。这要求每条边都带发表时间，能按时间切出子图。这也是把时间做成边属性、而不是只做在节点上的直接理由。

| 图操作         | 对应能力                           | 在科研里的用途                   |
| -------------- | ---------------------------------- | -------------------------------- |
| 带属性多跳路径 | 路径查询，限定边类型与证据等级     | 枚举机制链                       |
| 最短路径       | 内置最短路径算法                   | 找中间缺失环节                   |
| 模式匹配       | 子图匹配                           | 定位药物-靶点-通路三角等特定结构 |
| 社区发现       | Louvain 等                         | 划分疾病模块、识别功能簇         |
| 中心性         | PageRank、度中心性                 | 枢纽识别与加权惩罚               |
| 候选打分       | 随机游走、相似性传播（应用层实现） | 对候选药物排序                   |

# 五、边界：图数据库承担什么，不承担什么

把边界说清楚，比罗列能力更有用。

图数据库负责的是**关系层的事实与候选生成**：哪条机制链在证据上说得通、哪个药物与目标疾病在网络位置上接近、哪些中间环节还缺实验。它不负责分子对接与结构模拟，不负责序列比对与组学定量，也不负责统计推断与生存分析。最终的因果关系，仍然要由实验和临床来判定。

| 任务               | 更适合谁             | 原因                     |
| ------------------ | -------------------- | ------------------------ |
| 机制链枚举与筛选   | 图数据库             | 本质是多跳关系遍历       |
| 候选药物排序       | 图 + 算法层          | 关系结构与打分模型配合   |
| 疾病模块划分       | 图数据库（社区发现） | 依赖网络拓扑             |
| 分子对接与结构模拟 | 专业计算工具         | 三维结构计算，非关系问题 |
| 组学定量与差异分析 | 统计工具             | 数值计算与假设检验       |
| 文献语义抽取       | 大模型 + 抽取流水线  | 非结构化文本理解         |

悦数图数据库在这类场景里承担的是底座角色：Shared-Nothing 与存算分离架构支撑千亿点万亿边的科研图谱并保持毫秒至百毫秒级的多跳响应，动态 Schema 让新增实体类型不必停机，内置最短路径、PageRank、Louvain、子图匹配等算法可直接调用，多源导入覆盖 CSV、Kafka、Pulsar 等格式，能对接文献抽取流水线与组学批处理产出；原生 GraphRAG 与 Text2nGQL 让不写查询语言的研究人员也能用自然语言提出关系问题。医疗科研是悦数图数据库公开列出的应用场景之一。至于同一场景下不同产品的横向比较，[选型的七项可测指标](/posts/Selection-Indicators)给了可以照着执行的验收方法。

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

这类图谱不建议一次建成，四步走更现实。

| 阶段       | 目标                 | 范围控制                               | 验收方式                       |
| ---------- | -------------------- | -------------------------------------- | ------------------------------ |
| 一、打底   | 核心实体与高等级证据 | 只做 A、B 级边，实体限疾病、靶点、药物 | 能用一句话答出三条已知机制链   |
| 二、扩边   | 引入文献共现         | D 级边单独标记，只用于候选生成         | 候选清单可解释，每条带证据标注 |
| 三、加时间 | 边带发表时间         | 支持按年份切子图                       | 能跑通一次回溯验证             |
| 四、闭环   | 预测与实验比对       | 实验结果回写为新的证据边               | 命中率与误报率有基线数据       |

两个误区值得单独提醒。

**其一，把共现当因果。**文献共现是最容易拿到、也最容易误导人的一类边。用它生成候选没问题，用它下结论就是把统计巧合包装成了生物学机制。判断标准很简单：这条结论如果被追问「有实验吗」，答不上来就不该写成结论。

**其二，先追求全量覆盖，再回头补证据标注。**很多团队先花半年把能拿到的关系全部灌进去，等图谱长得足够大，才发现九成边没法判断可信度，等于重建一遍。正确的顺序是反过来的：先定证据规范，再扩覆盖；宁可图谱小一半，也要每条边都知道自己是什么。

回到开头那条四跳路径。补上证据等级之后，它并没有消失，而是分成了三种不同的东西：一条完整可用的机制链、一条值得验证的推测、或者一条应当被否定的路径。科研真正缺的从来不是更多路径，而是知道哪一条值得拿去做实验。这件事靠的不是更强的算力，是每条边都记得自己是怎么来的——这正是图数据库在医学科研里不可替代的地方。

**相关阅读**

- [知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别](/posts/graph-database-storage-methods)
- [图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单](/posts/Selection-Indicators)
- [悦数 Fusion GraphRAG 是什么？图数据库、向量、全文三路检索如何协同](/posts/Fusion-GraphRAG)
- [什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案](/posts/Chain-Exploration)

# 常见问题（FAQ）

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

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

**Q2：医学科研的知识图谱和通用企业知识图谱，建模上最大的差别是什么？**

A：差别在证据。通用图谱关心「有没有关系」，科研图谱关心「这个关系有多可信」。因此科研图谱的每条边都必须带证据等级、来源类型、物种与实验方法，并且要能按等级过滤遍历；同时必须存阴性证据，否则推理只会不断产生新假设而无法收敛。此外还需要支持按时间切片建子图，才能用回溯方式验证预测效果。

**Q3：悦数图数据库在支撑科研级大规模图谱方面有哪些技术积累？**

A：悦数图数据库采用 Shared-Nothing 与存算分离架构，支持千亿点万亿边规模与不停服的线性扩缩容，动态 Schema 可在不中断服务的情况下新增点边类型；内置最短路径、PageRank、Louvain、子图匹配等图算法，并提供原生多模融合检索。公司累计拥有 60 余项发明专利，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院「领航者」案例。

疾病关联图谱能不能支撑药物发现，取决于每一跳有没有证据，而不是路径能不能连通。医学科研的图建模要分三层：实体关系层定怎么连，证据置信层定凭什么连，机制推理层定连出来能推出什么。三层缺一层，多跳路径只能当检索结果用，不能当科研假设用。本文结合悦数图数据库拆解三层的建法，以及超级节点与阴性证据两个最容易踩的坑。

疾病关联与药物发现：图数据库在医学科研中的三层建模路径

![运力调度的图数据库建模](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-22.png)

调度系统给一个司机派了两单：上午从城东仓送到城南，下午从城西仓送到城北。系统算出来的两条路线各自都是最短的——分别 18 公里和 21 公里，合计 39 公里。这是很多企业用上图数据库之前的标准做法：每一单都优化到极致。

司机实际跑了 86 公里。中间那 47 公里空驶，不在任何一条路线里，因为它不属于「这一单」，它属于「这两单之间」。

传统的路径规划把每个任务当成一个独立问题：给定起点终点，求最短路径。这套解法在单次配送里无可挑剔，但运力调度要回答的是另一个问题——**同一辆车接下来该干哪几单，才能让整天的总里程最小。**这是两个不同的问题，前者是路径优化，后者是资源与任务在时间轴上的匹配。混为一谈，就会出现「每一单都最优，合起来很糟」的结果。

这篇文章要讲的，是这类问题在图上怎么建模，以及图数据库在其中的作用边界——它能做什么，不能做什么，先说清楚。

# 一、运力调度的三张网叠在一起

把运力调度拆开看，它其实是三张网叠加。理解这一点，才知道图模型该建什么。

| 网     | 节点                     | 边                     | 回答什么                     |
| ------ | ------------------------ | ---------------------- | ---------------------------- |
| 路网   | 路口、路段、收费站       | 通行时间、限行、路况   | 两点之间怎么走最快           |
| 站点网 | 仓库、门店、网点、中转场 | 装卸能力、作业时间窗   | 货该在什么时候到哪           |
| 资源网 | 车辆、司机、班次         | 可执行、接续、工时约束 | 谁能干、干完还能不能接下一单 |

三张网各自都不难建，难的是把它们连起来。路径规划只需要路网，调度必须三网合一——因为一个任务是否可派，同时取决于「路通不通」「站点开不开门」「这辆车和这个司机还有没有余量」。

**这就是图模型的价值所在：三张网天然是同一种结构，可以直接拼成一张图。**换成关系模型，路网是一套表、站点是另一套、车辆排班是第三套，每做一次可行性判断都要跨表关联，而判断本身发生在派单前的实时环节。

拼成一张图之后，规模与延迟的账必须先算清楚：路网的点边、任务的时效、司机的工时全部叠在一张图上，量级会到什么程度。这部分实测口径可参照[图数据库能存多大规模的实测数据](/posts/Graph-database-capacity)。

# 二、点与边该怎么定义

建模的第一步是把业务实体映射成图元素。运力调度场景的常见映射如下。

| 图元素     | 业务实体                | 关键属性                                   |
| ---------- | ----------------------- | ------------------------------------------ |
| 点：站点   | 仓库、门店、中转场      | 经纬度、装卸时长、作业时间窗、日处理上限   |
| 点：车辆   | 自有车、外协车          | 车型、载重、容积、所属车队、可用时段       |
| 点：司机   | 驾驶员                  | 准驾车型、工时余额、熟悉区域、可用时段     |
| 点：任务   | 运输单、配送单          | 取货点、送货点、货物重量体积、要求送达时间 |
| 点：时段   | 时间片（可选）          | 起止时间、所属班次                         |
| 边：可执行 | 车/司机 能否执行 任务   | 匹配度、成本估算                           |
| 边：接续   | 任务 A 之后能否接任务 B | 空驶距离、空驶时间、可行性                 |
| 边：通行   | 站点之间的实际路径      | 距离、时长、路况、限行                     |
| 边：历史   | 车或司机 曾经跑过 路线  | 频次、准点率、异常记录                     |

其中两条边是这套模型的关键，也是最容易被建错的。

**「接续」边是调度的心脏。**任务 A 与任务 B 之间是否可行，取决于三个量：A 的预计结束时间、A 的送货点到 B 的取货点的空驶时间、B 的最晚开始时间。三者一比较，可行或不可行。这条边的存在，让「一天的行程」变成了图上的一条路径——沿着接续边走，走出来的就是一辆车的排班。

**「通行」边要带方向与时间。**早高峰的通行时间和凌晨不一样，单行道的两个方向也不一样。如果边不区分方向，或者时长取全天的平均值，规划结果在真实路况下会失真。严肃的做法是把时长建成带时间段的属性，或者按时间段建多条边。

# 三、时间怎么进图：三种建法各有代价

时间是一般图模型里最难处理的部分，运力调度尤其躲不开。常见有三种建法。

| 建法                     | 做法                         | 优点                               | 代价                             |
| ------------------------ | ---------------------------- | ---------------------------------- | -------------------------------- |
| 时间作为边属性           | 边的时长、时间窗写成属性     | 模型简单、点数不膨胀               | 查询要带时间条件，算法不原生支持 |
| 时间作为点（时间扩展图） | 每个时段一个节点，按时间连边 | 时间约束变成结构约束，算法可直接用 | 点数按时段数倍增                 |
| 时间作为版本             | 按时段建多份子图或边版本     | 各时段独立可优化                   | 存储与管理复杂度上升             |

**推荐的做法是前两种结合。**把「任务-时段」这种粗粒度的时间做成点，把通行时长这类连续的、可近似的量做成边属性。理由很实际：时间扩展图能把「时间窗约束」转化为「图上是否存在通路」，很多算法可以直接用；但把所有时间都展开成点，图会大到难以维护。

需要提醒的是，时间一旦进图，**动态更新就成了必要条件。**路况变了、某一单延误了、某个仓临时封控，图上的边权与可行性都要跟着变。这要求底座具备实时写入能力——悦数图数据库支持 Pulsar、Flink 数据接入，路况与作业状态可以持续同步进图，不必等批处理。

# 四、四类典型问题在图上的表达

模型建好之后，常见的调度问题可以拆成四种图操作。

**其一，两点之间怎么走。**最基础的最短路径。图数据库内置最短路径算法，按权重（距离或时长）求解，带方向约束。这一类问题本身不难，价值在于与其他三类共处一张图。

**其二，一条线路串多点。**多点巡回，本质上是带约束的路径问题。图能做的不是直接求出最优序列（那是指挥求解器的活），而是**先把不可能的接续边剪掉**——超载的、超时的、跨区限行的，一次性排除，剩下的候选空间交给求解器。这一步往往能把搜索空间缩小一到两个数量级。

**其三，这一单派给谁。**车辆-任务匹配是一个多约束筛选问题：载重够不够、车型对不对、司机准驾是否匹配、当前所在位置到取货点的空驶是否在可接受范围、当天工时余额是否足够。用图查询表达，就是沿着「可执行」边做一次带属性条件的遍历，一次拿到候选清单，再按成本排序。

**其四，突发情况怎么重排。**这是最见功力的一类。某车抛锚、某仓封控、某单临时加急，调度要在几分钟内重排。图上的做法是：定位受影响的任务节点（点查询），沿接续边向下游找出受牵连的整条路径（可达性遍历），再对这部分子图重新求解，而不是全局重算。**局部重排而非全局重算，是实时调度能不能做到分钟级的关键。**

| 问题         | 图操作                | 交给图做       | 交给求解器做   |
| ------------ | --------------------- | -------------- | -------------- |
| 两点最短路   | 带权最短路径          | 全部           | 无需           |
| 多点巡回     | 剪枝 + 候选路径生成   | 排除不可行接续 | 序列优化       |
| 车辆任务匹配 | 带属性条件的邻域遍历  | 候选筛选与排序 | 大规模指派优化 |
| 突发重排     | 可达性遍历 + 子图重解 | 圈定受影响范围 | 子问题求解     |

# 五、能力边界：什么该交给图，什么不该

这一节是全文最需要说清楚的部分。运力调度里存在被过度承诺的风险，把边界划清楚反而更容易做对。

**图数据库擅长的三件事。**

第一是**约束传播**。一个约束变动（司机工时少了半小时）会沿着接续关系影响后面若干单，这种「影响面」的计算，本质上是图上的一次遍历，图数据库做得很自然。第二是**候选空间收缩**。前面反复提到的剪枝，就是把一个巨大的组合问题切成若干个小问题，这一步靠图查询比靠代码里的多重循环更清晰、也更快改。第三是**关系即数据**。路线、班次、历史表现这些关系本身就是业务资产，存在图里可以直接查询、直接分析，不必每次现算。

**不该勉强图数据库做的两件事。**

第一是**大规模组合优化本身**。车辆路径问题是 NP-hard，几十辆车、几百个任务的最优解需要专门的求解器（运筹优化库或商用求解引擎）来做。图数据库即使跑图算法，也不该被当成 VRP 求解器。第二是**超大规模的数值聚合**。按天按区统计里程、成本这类分析型查询，列式存储更合适，图数据库的强项是关系遍历，不是扫描聚合。

| 任务                 | 更适合谁  | 原因                 |
| -------------------- | --------- | -------------------- |
| 约束传播与影响面计算 | 图数据库  | 本质是关系遍历       |
| 可行接续剪枝         | 图数据库  | 带属性条件的关系筛选 |
| 受影响任务圈定       | 图数据库  | 可达性查询           |
| 相似线路召回         | 图 + 向量 | 语义相似 + 关系校验  |
| 大规模 VRP 最优解    | 求解器    | NP-hard，需专门算法  |
| 里程成本汇总统计     | 列式存储  | 扫描聚合型负载       |

一个务实的架构是：**图做前置，求解器做后置。**图数据库在一次查询里完成「谁可能干、能干哪几单、哪些接续不可行」的筛选，把候选集缩到求解器能秒级返回的规模；求解结果回写到图上，形成新的排班路径，供下一次查询使用。这个分工让两边各做自己擅长的事，而不是指望一个系统包办全部。

关于地理维度，物流场景的选址与范围筛选离不开空间查询。悦数图数据库提供原生多模融合检索，融合图、向量与全文索引，并支持地理空间索引，位置相关的筛选可以与关系遍历写在同一次查询里——这在「找出取货点 5 公里内、且当天还有工时余额的司机」这类组合条件上，比跨系统拼装要直接。

如果还要横向比较不同产品在同一场景下的表现，[图数据库选型的七项可测指标](/posts/Selection-Indicators)给了可以照着做的验收方法，从延迟分位值到混合负载都有具体测法。

# 六、落地建模清单与两个误区

最后给一份可以直接对照的清单。

| #    | 建模项   | 要点                               | 常见错误                 |
| ---- | -------- | ---------------------------------- | ------------------------ |
| 1    | 站点建模 | 装卸时长与作业时间窗必须进属性     | 只存经纬度，忽略作业能力 |
| 2    | 车辆建模 | 载重与容积分开存                   | 只存载重，装不下体积货   |
| 3    | 司机建模 | 工时余额是动态属性，需实时更新     | 用工时上限代替余额       |
| 4    | 接续边   | 由空驶时间与时间窗推导，需定时重算 | 用直线距离估空驶时间     |
| 5    | 通行边   | 带方向、带时段                     | 双向同权、全平均时长     |
| 6    | 时间处理 | 粗粒度做点，连续量做属性           | 全部展开成点导致图膨胀   |
| 7    | 局部重排 | 先圈定受影响子图再求解             | 每次变动都全局重算       |
| 8    | 结果回写 | 排班结果写回图，供下次查询         | 只存数据库表，图上查不到 |

两个误区值得提醒。**其一，把图数据库当成路径规划引擎。**图数据库能算最短路，但运力调度的核心是约束下的组合优化，这部分要靠求解器。指望图数据库一步到位，最后往往得到一个能跑但质量不高的结果。**其二，把接续关系静态化。**接续的可行性随路况、工时、装卸进度实时变化，如果这张边表一天只重算一次，调度给出的方案在半天之后就已经失真。接续边必须是动态的，这也是这套模型对底座实时写入能力有要求的原因。

开头那位司机多跑的 47 公里，本质上是一次信息缺失：系统的视野只到「单」这一层，看不到「单与单之间」。把这一层补上，不需要换掉求解器，只需要在它前面加一张能表达时间与约束的图。

**相关阅读**

- [图数据库到底能存多大规模？千亿点万亿边的容量与性能边界](/posts/Graph-database-capacity)
- [图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单](/posts/Selection-Indicators)
- [什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案](/posts/Chain-Exploration)
- [悦数 Fusion GraphRAG 是什么？图数据库、向量、全文三路检索如何协同](/posts/Fusion-GraphRAG)

### 常见问题（FAQ）

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

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

**Q2：运力调度已经有成熟的路径规划算法和求解器，为什么还要引入图数据库？**

A：两者解决的问题不同。求解器擅长在给定候选集内求出最优组合，但候选集本身的构造——哪些车能接哪些单、哪些接续在时间窗内可行、某个变动会牵连哪些任务——是关系问题。图数据库的价值在于把车、任务、站点、时段建成一张可遍历的图，用一次查询完成候选筛选与影响面计算，把问题规模缩到求解器能秒级求解的范围，两者是前后衔接而非相互替代。

**Q3：悦数图数据库在实时数据接入与大规模图计算上有哪些技术积累？**

A：悦数图数据库支持 Pulsar、Flink 等流式数据接入，可将路况、作业状态等实时数据持续同步进图，并支持导出至 HDFS 与多源数据导入。平台内置图算法库与图计算引擎，相比 Spark GraphX 有 6 至 10 倍提速，资源占用降低 80%，开发效率提升 80%；底座采用 Shared-Nothing 与存算分离架构，支持千亿点万亿边规模。公司累计拥有 60 余项发明专利，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院「领航者」案例。

运力调度真正的难点不是算最短路径，而是在时间窗、载重、司机工时、装卸能力四重约束下找可行解。图数据库替代不了求解器，它能做的是把车、任务、站点、时段建成一张可遍历的图，先把候选空间收缩到可解规模。悦数图数据库拆解三张网的建模方法、时间进图的三种建法，以及图算法不该越界的地方。

运力调度与路径规划：图数据库先缩候选，求解器再算最优

![数据血缘的图数据库](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 三库能表达深链，性能取决于三元组索引；向量库没有跳的概念，深链只能多轮召回拼接；只有原生图数据库把邻接关系直接当作存储结构来用。悦数图数据库按查询深度逐层拆解四种路线的实现与代价。