担保圈风险传染有多快？用图算法做一次真实压力测试

2018 年，某省一家资产规模不到 30 亿的民营制造企业资金链断裂，银行启动代偿。这本该是一个孤立的信用事件——但随后的 72 小时内，为它担保的两家企业被银行要求追加抵押，其中一家自身资金周转困难被迫违约；紧接着，为这两家企业担保的另外四家企业也被卷入，担保链像多米诺骨牌一样逐级倒塌。一个月后，这个"担保圈"里共有 17 家企业被列入不良，涉及银行贷款余额超过 40 亿。事后复盘发现，银行的风控系统在第一笔违约发生时，只标记了直接担保关系中的 3 家企业，完全没有识别出这个担保圈的真实规模——它通过互保、联保、母公司担保、关联企业担保编织出了一张 47 个节点、89 条边的复杂网络，而银行关系型数据库里存的是一张张独立的担保合同表，从来没有把它"连成一张图"。

这个案例不是孤例。中国银某监会的数据显示，商业银行不良贷款中担保圈相关占比长期保持在 25% 以上，部分区域甚至超过 40%。担保圈风险的核心特征是"传染"——一家企业的违约不是终点，而是起点，风险沿着担保关系网络逐级扩散，传导速度和波及范围完全取决于网络拓扑结构。传统的风控手段处理的是单点信用风险，面对网络传染风险，它几乎是无能为力的。问题不在于数据不够——银行的担保数据都在，问题在于没有把数据连成网络、没有用图算法去模拟传染过程。

一、传统担保圈风控为什么"看不见"

传统银行风控系统处理担保关系的方式，本质上是在做"列表查询"：贷款审批时查"这个客户为谁担保了""谁为这个客户担保了"，最多再查一层"担保人的担保人是谁"。这种处理方式有三个结构性盲区。

盲区一：只看直接关系，看不见网络拓扑。 传统系统记录的是"A 为 B 担保"这样的一对一关系。但真实的担保圈不是一条链，而是一张网——A 为 B 担保，B 为 C 担保，C 又为 A 担保，形成互保闭环；D 同时为 A、B、C 担保，D 成了网络中的"超级节点"，一旦 D 出事，A、B、C 同时受冲击。关系型数据库用 JOIN 查询可以做一到两跳的关联，但三跳以上的网络结构就需要多层嵌套查询，性能急剧下降。更重要的是，即使查出来，它呈现的是一张关系列表，业务人员看不到网络拓扑，无法判断哪些节点是"关键枢纽"、哪些边是"核心传导路径"。

盲区二：只有静态标记，没有动态传染模拟。 传统系统对担保圈风险的评估是"打标签"——某企业涉及担保圈则标记"关注"，涉及互保则标记"高风险"。但担保圈的风险不是静态的，它是动态传染的。同样一个 20 家企业组成的担保圈，如果违约企业处于网络边缘，传染范围可能只有 3-5 家；如果违约企业处于网络中心（连接了 8 条担保边），传染范围可能覆盖全部 20 家。静态标记无法区分这两种情况——它只知道"这个圈有风险"，不知道"风险会怎么传、传多快、传到哪里"。

盲区三：只有财务指标，没有网络结构指标。 传统风控对担保圈内企业的评估仍以财务指标为主——资产负债率、流动比率、营业收入。但担保圈风险的引爆点往往不是财务最差的企业，而是网络结构中"中心性"最高的企业。一家财务状况中等但为 12 家企业提供担保的企业，比一家财务状况较差但只为 1 家企业提供担保的企业，对整个担保圈的威胁大得多。传统风控完全没有"网络结构指标"这个维度。

二、图数据库建模担保关系网络

要用图算法做担保圈压力测试，第一步是把担保关系"连成一张图"。图数据库的节点和边结构天然适配担保网络的建模需求。

节点层：四类关键实体。 第一类是企业节点，包含基本信息（注册号、行业、规模）和动态属性（资产负债率、逾期次数、诉讼记录）。第二类是个人节点，即企业法人、实际控制人和自然人担保方。第三类是贷款节点，记录每笔贷款的金额、期限、状态（正常/逾期/不良）。第四类是银行节点，标识贷款发放方。四类节点通过不同类型的边连接，形成完整的担保关系网络。

边层：五类核心关系。 第一类是"担保"边，从担保方指向被担保方，边上携带担保金额、担保方式（一般保证/连带责任）、担保期限。第二类是"股权控制"边，从股东指向企业，携带持股比例——这条边让担保圈与股权关联网络打通，识别"同一实控人下的互保"。第三类是"关联交易"边，标识企业间的资金往来关系——关联企业间的担保往往伴随资金空转，是担保圈风险的高危信号。第四类是"互保"边，当 A 为 B 担保且 B 也为 A 担保时，系统自动识别并标注互保关系。第五类是"联保"边，三家以上企业为同一笔贷款共同担保时形成联保关系——联保体中任一家违约，其余成员承担连带责任。

属性层：风险量化参数。 每条"担保"边上携带传染概率参数——担保金额占担保方净资产的比例越高，传染概率越大。企业节点上携带"违约损失率"参数——一旦违约，给担保方造成的实际损失比例。这些参数不是拍脑袋定的，而是基于历史违约数据回归拟合的。有了这些参数，图算法才能做量化传染模拟，而不只是定性分析。

以悦数图数据库为例，亿级节点规模下支持上述多类型节点、多类型边的混合建模，多跳遍历响应保持在百毫秒级别——这意味着当一家企业发生违约时，系统可以在秒级完成从该节点出发的全网络传染路径扫描，而不需要等几天的批量计算。

三、四大图算法驱动的压力测试

担保关系网络建好之后，压力测试的核心是回答三个问题：风险从哪里来、传到哪里去、传得有多快。四个图算法分别回答这三个问题。

算法一：PageRank——找出担保圈中的"系统性重要节点"。 PageRank 最初是 Google 用来评估网页重要性的算法，但它的数学本质——"一个节点的重要性取决于指向它的节点的重要性"——完美适配担保圈场景。在担保网络中，一个企业的 PageRank 值越高，意味着越多重要企业为它担保或与它关联——一旦这个企业违约，冲击波会传导到网络中最重要的那些节点。压力测试的第一步就是跑一次 PageRank，把全网节点按 PageRank 值排序，排名前 10% 的企业就是"系统性重要节点"——这些企业一旦出事，整个担保圈可能连锁崩塌。某城商行在悦数上跑了一次担保圈 PageRank 分析后发现，排名前 5 的企业中有 3 家的财务评级是"正常"，但它们的担保连接数分别达到 14、11 和 9——传统风控完全没有把这 3 家列入重点监控。

算法二：Louvain 社区发现——识别担保圈中的"子团伙"。 担保圈往往不是一张均匀的网络，而是由若干个"子团伙"组成的——某个行业的 10 家企业互保形成一团，某个园区的 8 家企业联保形成另一团，两个团之间通过一两条担保边连接。Louvain 算法通过最大化模块度（modularity）自动发现网络中的社区结构，将担保圈切分为若干个"子团伙"。这个切分的价值在于——子团伙内部的风险传染速度远高于跨团伙传染。当违约发生在某个子团伙内部时，首先被冲击的是同一团伙的其他企业，跨团伙传导需要经过"桥节点"。识别出桥节点后，风控团队可以在桥节点上设置"防火墙"——比如要求桥节点企业追加抵押，阻断跨团伙传染路径。悦数内置 Louvain 算法，在万级节点的担保网络上秒级完成社区发现，识别出的子团伙数量和桥节点位置为压力测试提供了精准的"切分点"。

算法三：最短路径与广度优先遍历——模拟风险传染路径。 当一家企业违约后，风险怎么传？传到谁？最短路径算法和广度优先遍历（BFS）回答这个问题。从违约节点出发，沿"担保"边做 BFS 遍历，第一层是直接担保方——它们承担代偿责任，冲击最大；第二层是为第一层担保的企业——它们承担"二次传染"风险；第三层依次类推。每一层的传染都伴随概率衰减——如果直接传染概率是 60%，二次传染概率可能降到 30%，三次传染降到 12%。图遍历同时计算每一层的累计暴露金额，输出一张"传染树"——从违约节点到网络中每个可达节点的路径、跳数、累计概率和累计金额。某省联社用悦数跑了一次真实压力测试：一家 PageRank 排名第一的制造企业违约后，BFS 遍历在 1.2 秒内完成了 6 跳传染路径扫描，识别出 43 家受影响企业，累计暴露金额 28 亿——其中第 4-6 跳的 23 家企业此前的风控报告完全没有覆盖。

算法四：介数中心性（Betweenness Centrality）——找出"风险传导的关键咽喉"。 介数中心性衡量一个节点在网络中"处于多少条最短路径上"。在担保圈中，介数中心性高的企业是"咽喉节点"——大量风险传导路径经过它。如果咽喉节点本身财务健康，它就像一个缓冲器，可以吸收部分冲击；但如果咽喉节点本身脆弱，它就是"放大器"——违约冲击经过它后会被放大传导到更多节点。压力测试中，系统会对介数中心性排名前 10 的咽喉节点逐一做"假设违约"模拟——"如果这个节点也违约了，传染范围会扩大多少？"某农商行的模拟结果显示，排名第二的咽喉节点一旦同时违约，受影响企业数从 43 家激增到 67 家，暴露金额从 28 亿扩大到 52 亿——这个增量就是咽喉节点的"系统性风险贡献度"。

四、大模型接入：从数字到决策

图算法输出的是数字——PageRank 值、Louvain 社区标签、传染路径、介数中心性值。这些数字对技术人员有意义，但对风控决策者来说，需要的是"这说明了什么、应该怎么办"。大模型的接入，把算法输出转化为可执行的决策建议。

第一层：Text2nGQL 自然语言查询。 风控经理不需要学 nGQL 查询语言，直接用自然语言提问："把担保圈里 PageRank 排名前十的企业列出来，标注它们的担保连接数和当前财务评级。"Text2nGQL 自动将这段话转化为图查询，调用 PageRank 算法并关联企业财务属性，返回结构化结果。这让图算法能力从技术团队下沉到业务团队——风控经理可以随时发起压力测试查询，不依赖技术人员支持。

第二层：GraphRAG 传染报告自动生成。 一次完整的压力测试涉及数十个节点的传染路径、数百条边的传导概率、多个算法的综合评估结果。大模型基于 GraphRAG 将这些结构化结果与非结构化上下文（企业工商信息、舆情新闻、行业分析报告）融合，自动生成一份完整的压力测试报告——包含违约情景描述、传染路径分析、关键节点识别、受影响企业清单、建议措施。这份报告从触发到生成不超过 5 分钟，而传统方式由分析师手工撰写需要 2-3 天。

第三层：情景推演与预案生成。 大模型不仅能分析"已经发生的违约"，还能推演"假设情景"。"如果行业整体下行 20%，担保圈中哪 5 家企业最可能率先违约？违约后的传染路径是什么？应该在哪些节点设置防火墙？"大模型结合图算法的量化分析结果和行业知识，生成多套情景推演方案和对应的应急预案——哪些企业需要追加抵押、哪些担保关系需要解除、哪些子团伙需要重点监控。

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

担保圈压力测试对图数据库提出了五项核心要求，悦数在每一项上都有明确的工程支撑。

亿级多跳实时遍历。 压力测试的核心操作是从违约节点出发做多跳 BFS 遍历。省级担保网络通常涉及数万家企业、数十万条担保边，一次 6 跳遍历需要访问的节点和边可能达到百万级。悦数在亿级节点规模下保持多跳遍历百毫秒级响应，确保压力测试从触发到出结果不超过秒级——这个速度让风控团队可以在违约事件发生后"实时"评估传染影响，而不是等批量计算跑完再应对。

内置图算法库。 PageRank、Louvain、BFS、最短路径、介数中心性——压力测试需要调用的四个核心算法，悦数全部内置支持，不需要额外安装算法插件或编写 Python 脚本。算法直接在图引擎层面执行，与查询计划深度耦合，避免数据在引擎和应用层之间来回搬运的延迟。一次完整的"PageRank + Louvain + BFS + 介数中心性"四算法联合分析，在万级节点网络上 30 秒内完成。

原生 GraphRAG 语义融合。 压力测试报告的生成需要同时处理结构化图数据和非结构化文本信息。悦数原生 GraphRAG 在引擎层面将图遍历结果与语义检索结果融合，一次查询返回"算法计算的结构化指标 + 企业舆情/工商/行业报告的语义内容"——大模型拿到的是完整的上下文，生成的报告既有数字精度又有业务深度。

动态 Schema 适配担保网络演化。 担保网络不是静态的——企业会新增担保关系、解除旧担保、变更股权结构。悦数动态 Schema 允许在不中断服务的情况下添加新的节点属性和边类型，比如当监管要求增加"隐性担保"边类型时，系统无需停机迁移，直接在现有网络上扩展。担保关系的每一次变更都实时写入图数据库，压力测试基于最新网络状态执行，不存在"数据滞后导致评估失真"的问题。

Studio 可视化推演。 压力测试的结果需要呈现给风控委员会——不是一张数字表格，而是一张可视化的"传染地图"。悦数 Studio 提供图谱可视化界面，支持将传染路径以动态高亮的方式展示——违约节点标红、第一层传染节点标橙、第二层标黄、未受影响节点标绿。风控委员会成员可以直观看到"风险从哪个节点开始、沿什么路径传导、波及范围多大"，点击任何节点查看该企业的详细信息和担保关系。这种可视化能力让压力测试结果从"技术报告"变成"决策工具"。