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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

六、落地顺序与两个误区

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

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

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

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

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

相关阅读

常见问题（FAQ）

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

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

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

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

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

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