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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 常见问题（FAQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 常见问题（FAQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 常见问题（FAQ）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 四、图算法与识别清单

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建模有三个关键决定。

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

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

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

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

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

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

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

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

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

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



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

票据回头背书：一张票在关联企业间空转，图数据库如何识别环状流转？

![信用证欺诈图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-29.png)

信用证制度有一块基石，叫独立抽象性原则：银行处理的是单据，不是货物，只要单证相符、单单相符，银行必须付款，至于货在不在、质量如何、合同有没有纠纷，一概不问，这个原则让国际贸易有了可流转的信用，也让一桩生意可以简化成三套文件的流转 —— 货物流走实物，单据流走纸面，资金流走账户，原则的反面同样成立：只要三套文件各自做得漂亮，货可以从头到尾不存在，信用证欺诈几乎全部从这条缝隙里长出来，而校验三流不一，本质上不是单纯审单，而是依托[图数据库](https://www.yueshu.com.cn/database)，把三套互不联通的系统记录放回同一张关系网络里对齐，识别虚假贸易背后隐藏的关联风险。

### 一、信用证欺诈的四种典型结构

**虚构贸易背景。** 关联企业之间互为买卖双方，虚构一笔国际或国内贸易，凭合同、发票、提单申请开证，开证后迅速承兑、贴现，把银行资金套出来投入别处，到期前再制造第二笔贸易滚动接续。钢贸危机中暴露的融资性贸易、走单不走货，就是这个结构的国内版本。这类结构每一笔单据都合规，异常在于贸易双方是关联方、贸易在闭环里循环。

**一货多押。** 同一批货物，同一份仓单或提单，在不同银行重复质押融资。货物不动，单据复制，一家银行的库存监管看不到另一家的质押记录。2014 年前后青岛港事件中，同一批金属重复质押的融资规模数百亿元，涉事企业正是利用了各银行之间仓储信息不互通。这类手法后来演化出变种：把仓单拆分成多份分单，每份对应不同银行；或者把一批货在海关监管库、保税区、内贸仓之间倒库，让每一站都产生一份新的库存凭证。

**单据造假。** 伪造提单、变造数量、倒签日期——货还没装船，提单先开出来；或过了信用证最迟装运期，把提单日期改到期限之前。这类造假瞄准的是银行只审单据表面的作业方式，假造得好就能顺利承兑。

**关联定价操纵。** 关联方之间高报进口价格或低报出口价格，放大单笔融资额，或者用价格差把资金沉淀在境外。单笔看是正常贸易定价，异常要在同一批交易对手的多次交易价格对比里才显现：同一种商品、同一时间段，该对手的成交价相对市场基准持续偏离两成以上，且偏离方向始终朝着放大融资额的一侧。价格本身有波动是正常的，**偏离的方向从不改变**才是异常。

| 手法         | 核心操作               | 图上的形状             | 单证审核可见度 |
| ------------ | ---------------------- | ---------------------- | -------------- |
| 虚构贸易背景 | 关联方互开、走单不走货 | 贸易关系成环、资金归集 | 不可见         |
| 一货多押     | 同一货物重复质押       | 仓单/提单节点入度异常  | 不可见         |
| 单据造假     | 伪造提单、倒签日期     | 单据时间与物流记录矛盾 | 部分可见       |
| 关联定价操纵 | 高报或低报价格         | 同对手多笔价格偏离分布 | 不可见         |

### 二、审单为什么审不出三流不一

银行审单的作业单元是一笔业务：审核这张信用证项下的单据是否与信用证条款一致、单据之间是否互相印证。这套流程有两个结构性天花板。

**审单核的是一致性，不是存在性。** 发票、箱单、提单互相印证，只能证明这套文件内部自洽，不能证明船真的开了、货真的在舱里。提单是真签发的，货没装；仓单是真的，货早被提走——文件本身可以全部真实。

**审单是静态逐笔的，欺诈是跨笔跨时间的。** 同一企业两年内与五家境外公司发生贸易，五家公司的注册地址相同、董事重合、资金最终汇入同一账户；同一批货物三个月内在三家银行出现。这些异常都不存在于任何一笔单据里，只存在于记录与记录的关系里。而三流数据恰好分散在三套系统：单据在银行信贷系统，物流与报关在海关和港口系统，资金在支付清算系统，行内还有一部分在核心系统——互相之间没有外键，自然也没有校验。

现行的一些补救手段也都停在单笔层面。发票联网核验能确认发票真伪，核不出这套发票对应的货被押了几次；报关单电子口岸核查能确认报关行为存在，核不出报关的货与仓单里的货是不是同一批；仓储监管能盯住本行质押项下的库存，盯不住同一仓库里为其他银行监管的货。**每个环节都在自己那一段里做了核验，但没有任何环节负责把三段接起来——缝隙不在任何一段内部，缝隙在段与段之间。**

| 维度         | 传统单证审核         | 图谱三流校验                       |
| ------------ | -------------------- | ---------------------------------- |
| 校验单元     | 单笔业务的单证一致性 | 跨笔、跨企业、跨时间的结构         |
| 数据来源     | 本笔信用证项下单据   | 单据+报关+物流+资金+工商多源入图   |
| 时间视角     | 静态时点审核         | 时间轴上的先后与重复               |
| 识别目标     | 单证相符             | 贸易真实性、货物唯一性、对手关联性 |
| 典型失效场景 | 走单不走货、一货多押 | 纯单点贸易、单家银行业务           |

### 三、图数据库如何把三流对齐

建模的关键决定有两个。第一个是把**货物批次和提单建为枢纽节点**，而不是把贸易对手建为中心。因为三流校验的核心问题是同一批货物的单据链是否完整且唯一：一份提单连接发货人、承运人、通知方、报关单、仓单、发票、信用证，如果这串连接里出现了两笔不同银行的质押，货物唯一性即被打破。传统建模把货物理解为贸易合同的一个字段，跨笔校验无从谈起。

第二个是把**时间放在边上做一致性校验**。三流不一是时间维度上的矛盾：提单日期晚于靠泊日期（倒签）、质押日期早于入库日期、报关日期晚于承兑日期。校验方式是对同一货物节点上的所有边做时间单调性检查——物理世界有先后，造出来的单据经常顾不上先后。

同一提单号关联的质押银行数大于等于 2，直接进核查队列。这个查询在关系数据库里需要仓单表、质押表、银行表级联关联再加分组统计，在图上是一次沿边遍历。同理，虚构贸易背景的检测是环查询：A 卖给 B、B 卖给 C、C 卖回 A，四步以内的贸易闭环配合资金回流路径，基本可以判定为走单不走货。

倒签检测的思路类似，校验对象从单据之间换成了单据与物理世界之间。提单上写的装船日期，可以和船舶自动识别系统（AIS）的历史轨迹比对：该轮当天是否真的挂靠了提单载明的装货港、停泊时长是否够完成装货。仓单入库日期可以和港口理货记录、集装箱进场记录比对。物理世界的时间戳分散在各处且由不同主体生成，伪造全部环节的成本远高于伪造一套单据——这正是把物流时间引入图谱后，单据造假难度陡增的原因。

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

| 识别目标       | 图特征               | 图算法               | 处置动作           |
| -------------- | -------------------- | -------------------- | ------------------ |
| 一货多押       | 仓单/提单节点入度    | 入度统计、子图匹配   | 暂停放款，现场查货 |
| 虚构贸易闭环   | 贸易关系环、资金回流 | 环检测、路径聚合     | 冻结额度，穿透核查 |
| 关联对手网络   | 股权、董事、地址重合 | 实体解析、社区发现   | 合并授信，重定价格 |
| 倒签与时间矛盾 | 单据边的时间序列     | 时序异常检测         | 单据退回，物流取证 |
| 资金归集账户   | 汇聚度、跨链枢纽     | PageRank、中介中心性 | 监控账户，追索方向 |

把一个真实比例的案子放进去跑。某贸易公司以其名下 2.7 万吨钢材申请开证，仓单编号在图谱中 45 天内出现 3 次质押记录，涉及 3 家银行、融资合计 1.9 亿元——一货多押特征命中，入度 3。向上穿透，该批货物的上游供应商与该贸易公司共用一个注册地址，且两家公司法定代表人为夫妻关系——关联对手特征命中。资金流出方向：三笔融资款到账后平均 4.2 天汇入同一境外账户，该账户同时是另外 6 笔贸易融资的最终收款方——资金归集特征命中。时间轴上，仓单入库日期为 6 月 18 日，最早一笔质押登记却是 6 月 11 日，货还没入库就先质押了——时序矛盾命中。四类特征命中三项以上，按团伙级欺诈立案，单笔逐单审核永远不会把这四条线索凑到一起。

落地时还需要一套判定纪律，把恶意一货多押与正常的登记瑕疵分开。三种情况叠加才进高危处置：多次质押的间隔极短且金额接近货物评估全值；融资款快速流出且归集到同一账户；货物在此期间从未发生真实出入库。如果只是仓储系统编号规则不一致导致的重复登记、货主确有真实贸易背景、资金用于约定的采购支付，那更可能是数据质量问题，处置动作应是数据治理而不是冻结放款。**误把瑕疵当欺诈，伤的是贸易融资业务本身**——这类业务本来就在收缩，误伤的代价客户经理最清楚。

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

针对贸易融资三流校验需要整合行内单据、海关报关、港口物流、仓储监管、资金流水与工商股权等多源数据，并在全量业务规模上实时校验的场景，悦数图数据库提供几个关键支撑：万亿边级分布式存储可承载多年期全量贸易融资业务与外部数据，使跨行、跨年的一货多押有完整的比对基础；动态 Schema 支持报关单、提单、仓单等新数据源不停机入图；CDC 实时同步让新开证与新质押秒级进入图谱，重复质押在第二家银行进件时即可触发拦截，而不是风险暴露后倒查；内置环检测、社区发现、中心性等图算法开箱即用；Text2nGQL 让审单人员用自然语言即可查询某票货物的完整单据链与资金去向。

两个坑提前说。第一个是把三流校验做成单笔核对——逐笔核对三套单据字段一致，恰好落在欺诈者的舒适区里，结构性欺诈必须靠跨笔跨时间的图特征才能覆盖。第二个是只用行内数据建图——货物流与对手关联性这两块关键拼图都在行外，缺了它们，图建得再好也只是单据网络的自我循环。**三流校验的价值不在于核出哪张单是假的，而在于让同一批货物、同一组对手、同一条资金路径在所有银行面前只有一次出场机会。**



悦数图数据库可整合开证申请、信用证、发票、提单、仓单、报关、物流轨迹与资金流水等多源数据，把货物批次与提单建为枢纽节点，通过入度统计、环检测、时序一致性校验、社区发现与中心性分析等图算法，批量识别一货多押、虚构贸易背景、单据造假与关联闭环交易等信用证欺诈结构，帮助银行在单证相符之外补上贸易真实性这道防线。

信用证欺诈：货物流、单据流、资金流三流不一，图数据库如何校验？

![理赔团伙分图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-28.png)

同一张理赔案件，两套风控模型给出截然相反的结论。传统评分卡核验保单全部字段：被保险人 34 岁、保额 30 万、出险在投保后第 11 个月、三甲医院就诊、票据完整、诊断与用药匹配、无既往理赔记录，综合得分 0.08，判定低风险自动结案。基于[图数据库](https://www.yueshu.com.cn/database)的图谱模型处理的是同一份材料，但它关注的不是单据本身，而是案件背后关联的人物网络，输出 0.87，标记高风险转入人工核查。两个结果都不算错误，它们回答的是不同问题：评分卡判断这张单子单独看是否存在造假疑点，图数据库图谱模型判断这张单子依附于什么样的关系网络。对于团伙骗保而言，他们能把每一份报案材料包装得毫无破绽，却很难彻底抹去团伙成员之间的关联痕迹，这正是图数据库在反欺诈场景里的核心价值。

# 一、团伙骗保的四种结构，只有关系能看见

单案手法可以千变万化，但团伙的组织方式收敛得很快。把它们抽象出来，大致是四类结构，每一类在图上都有清晰的形状。

**同期同网型。** 一批互不相识的人，在同一段时间内集中投保、集中出险、集中理赔，背后的票据来自同一批机构，赔付资金最终流向同一组账户。每个人单独看都是正常客户，异常只存在于“同一时间、同一批机构、同一组账户”这三个重合上。这类结构在图上表现为一个高密度子图，社区发现算法一眼就能圈出来。

**环形互保型。** 投保人 A 为 B 投保、B 为 C 投保、C 又为 A 投保，形成闭环。闭环的用途是让每一份保单都看起来有独立的投保动机，同时让每个人的保单数量保持在风控阈值以下。环结构在关系表里几乎无法表达，因为判断它需要的是路径的起点和终点重合，而不是某几个字段的取值。

**中介聚合型。** 一个代理人、一个保险中介、一个“理赔黄牛”，同时连接着几十个彼此没有其他交集的投保人。这几十个人之间没有任何直接关系，只有这一个共同联系人，属于罕见但极具判别力的图特征：两个素不相识的人共享同一个代理人，这不奇怪；但如果还有同一家医院、同一个查勘员、同一个赔付账户、同一台设备，巧合的层数就超过了自然发生的可能。

**寄生型。** 最隐蔽的一类，不新建虚假业务，而是在真实业务里掺入少量虚假案件。一家确实在经营的修理厂、一家确实有门诊量的诊所、一个确实在带团的旅行社，真实单与虚假单混在一起，比例通常在百分之十到三十之间。这类结构在单案层面完全无法识别，因为虚假单复用了真实单的全部合规外观；只有用机构作为枢纽节点，统计其出险分布、伤情编码分布、赔付金额分布相对同业的偏离度，才会露出尾巴。

| 结构类型   | 图上的形状         | 核心异常信号                     | 单案层面可见度 |
| ---------- | ------------------ | -------------------------------- | -------------- |
| 同期同网型 | 高密度小社区       | 时间聚集、机构重合、资金同汇聚   | 极低           |
| 环形互保型 | 闭环回路           | 投保关系首尾相接、多份保单互指   | 不可见         |
| 中介聚合型 | 单一枢纽星型       | 共同代理人、共同查勘员、共同账户 | 低             |
| 寄生型     | 机构为中心的稠密簇 | 出险分布相对同业显著偏离         | 不可见         |

# 二、图特征从哪里来

给保单打团伙分，前提是先把图上的结构量化成可以进模型的数值。能用的图特征大致分五类，每一类回答一个不同的问题。

**局部结构特征回答“这个实体黏不黏人”。** 节点度（直接关联的实体数量）、聚类系数（邻居之间互相认识的比例）、三角形计数（参与了多少个三人闭环）。一份保单的被保险人如果同时是另外十几份保单的被保险人、投保人或受益人，度数会显著高于正常值——正常人的保险关系通常在一到三份之间。

**全局位置特征回答“它站在网络的什么位置”。** PageRank 衡量节点被多少重要节点指向，中介中心性衡量它在多少条最短路径上。一个代理商如果是多个互不相交社区之间的唯一桥梁，中介中心性会异常突出——他很可能就是那个把不同来源的案件拼装在一起的人。

**共同邻居与路径特征回答“两个实体凭什么连在一起”。** 两个投保人之间共享多少邻居、最短路径是几跳、路径上经过哪些类型的节点。素不相识的两人共享三家医院、两个查勘员、一个赔付账户，这个组合本身就是证据。

**重合度特征回答“他们是不是同一个人在操作”。** 设备指纹、登录 IP、手机号、银行卡、常用地址、甚至提交理赔的时间习惯。用 Jaccard 相似度量化重合程度，比布尔判断更稳健，也更容易设定阈值。

**二阶邻域污染度回答“他身边有多少坏人”。** 这是风控里最有效也最容易被忽略的一类特征：不看这个节点自己怎么样，而看它的邻居中有多少是被标记为高风险或已确认欺诈的实体。二阶邻域（邻居的邻居）的高风险占比，往往比节点自身的所有属性加起来都更能说明问题。

| 维度         | 单案特征                               | 图特征                               |
| ------------ | -------------------------------------- | ------------------------------------ |
| 数据来源     | 本案件字段、被保险人档案、历史理赔     | 跨案件的关系结构、实体重合、网络位置 |
| 回答的问题   | 这张单本身像不像假的                   | 这张单和谁一起出现、出现在哪个结构里 |
| 典型失效场景 | 单案合规的团伙骗保、票据真实的虚假案件 | 偶发的单点欺诈、无关联的独立案件     |
| 规模适应性   | 单条记录计算，成本固定                 | 依赖图遍历与算法，规模决定可行性     |
| 可解释性     | 字段权重，易于说明                     | 需要路径级证据链才能说明，否则是黑箱 |

# 三、团伙分怎么合成，以及为什么必须可拆解

有了特征，接下来是合成分数。这里最容易犯的错，是把图特征直接追加进原有评分卡，当成几十个新变量一起训练。结果是两个问题同时出现：一是双重计数，同一件事在单案特征和图特征里各算了一次，分数被放大；二是不可解释，一个 0.87 的分数背后是哪些关系在起作用，没人说得清，也就没法向调查员交代线索、向合规解释处置依据。

更稳妥的做法是分层合成。第一层是**关系密度类**，由节点度、聚类系数、共同邻居数构成，判断这个实体是否处在超常密度的关系中。第二层是**位置异常类**，由中介中心性、社区跨越数、PageRank 偏离度构成，判断它是否在结构中扮演了不该扮演的角色。第三层是**邻域污染类**，由一阶与二阶高风险邻居占比构成，判断它所处的关系环境是否已被污染。三类各自得出一个分量，再加权合成团伙分，并保留每个分量的贡献值。

保留贡献值的意义在于分数可以往下拆。同样输出 0.87，拆开可能是“二阶邻域污染度 0.9 + 关系密度 0.7 + 位置异常 0.3”，也可能是“位置异常 0.9 + 其余两项中等”——前者指向一个被团伙包裹的真实客户，处置上应当保留申诉通道；后者指向一个主动串联多方的组织者，处置上应当直接移送核查。**同一个分数，两种完全不同的处置。** 这也是为什么团伙分不能只输出一个数字。

# 四、图特征的计算路径

落在工程上，图特征抽取与算法调用是同一个遍历过程的两端。先用查询把候选集及其邻域取出来，再用算法在子图上计算结构与位置指标。判断“某个账户是否是多人共用的赔付出口”，用共同邻居和入度统计就够了；判断“这个社区是不是团伙”，需要社区发现；判断“谁是组织者”，需要中心性度量。

| 识别目标     | 图特征                     | 图算法              | 处置动作               |
| ------------ | -------------------------- | ------------------- | ---------------------- |
| 关系密度异常 | 节点度、聚类系数、三角计数 | 度统计、子图匹配    | 标记观察，纳入名单     |
| 团伙边界划分 | 社区归属、模块度           | 社区发现（Louvain） | 整社区立案移交         |
| 组织者定位   | 中介中心性、PageRank       | 中心性计算          | 优先核查，主犯方向     |
| 资金回流闭环 | 路径首尾重合               | 环检测              | 冻结、追偿             |
| 多案共犯识别 | 共同邻居、多角色频次       | 路径聚合、频次统计  | 提取证据链             |
| 邻域污染传导 | 一阶二阶高风险占比         | 邻域聚合、标签传播  | 分级提示，动态调整额度 |

把前面那张理赔单跑一遍，特征拆出来大致是这样：该被保险人在 90 天内出现在 6 家公司的 11 张保单中，关系密度分量 0.91；同一位“事故见证人”在 27 起案件的签字记录里出现过 9 次，共同邻居特征被触发；就医机构的同一科室、同一诊断编码在半年内出现 43 次，机构偏离度显著；赔付资金经过三层转出后汇聚到 3 个账户，与另外 14 起案件共享其中 2 个出口账户，二阶邻域高风险占比 0.83；投保时间集中在三个月内，与前一张保单间隔 6 天。五条特征里没有一条是靠单案字段能发现的，它们全部来自关系。

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

针对这类需要把全量保单、理赔记录、票据、代理人、赔付账户一起入图，并在万亿边规模上实时抽取图特征的场景，悦数图数据库提供几个关键支撑：万亿边规模的分布式存储可容纳历年全量业务数据与多源外部数据，使图特征有完整的网络基础而不是局部抽样；存算分离架构让批量入图与在线特征抽取互不干扰，模型服务的响应时间不随入图任务波动；内置图算法库直接提供社区发现、PageRank、中心性计算、环检测等算子，图特征无需自研分布式实现；动态 Schema 支持新增数据源（设备指纹、票据编号、就诊记录）不停机扩展模型；CDC 实时同步让新发生的投保与理赔在秒级进入图谱，使团伙分可以在核赔决策的窗口内给出，而不是次日批量计算。

悦数图数据库可整合投保、核保、理赔、医疗票据、代理人、赔付账户与设备环境等多源数据，把每一张保单放回它所在的关联网络中，通过节点度、共同邻居、社区归属、中心性、共同设备、二阶邻域污染度等图特征抽取，配合社区发现、PageRank、环检测、子图匹配等图算法，构建可拆解、可解释的理赔团伙风险分模型，让保险机构在案件维度之外获得关系维度的判别依据，把分散在各系统中的孤立案件重新聚合为团伙线索。

理赔团伙分：图数据库的图特征如何给每张保单打风险分？

![代理人自保件图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-24.png)

有两个数字，放在一起看会互相打架。某分公司上一年度新聘代理人 13 个月留存率只有 8%，也就是说十个人里活下来不到一个；但同期该团队保费收入增长了 40%，人均产能也创了三年新高。留存率极低说明队伍在快速失血，保费却高速增长说明业务在扩张——传统数据表无法穿透数据背后的隐性关联，而依托[**代理人自保件图数据库**](https://www.yueshu.com.cn/database)可精准拆解数据矛盾根源：除非这些保费根本不来自客户。把数据拆开看，答案就出来了：当年新增保费中，有 41% 的投保人是代理人本人或其直系亲属；新人在职期间人均自保件保费 2.6 万元，其中六成集中在入职后前三个月出单；这批保单在次年退保率达到 34%，远高于常规保单的 6%。留存率与增长率同时成立，是因为增长本来就是由那些会离开的人自己掏钱买出来的。自保件本身不是问题——代理人给自己和家人买保险完全合法，问题在于它被当成了转正、保级、拿奖励的工具。

# 一、自保件与增员泡沫的四种操作形态

**新人自购转正。** 大多数公司对新人设有转正门槛，常见形式是首季度保费达到一定额度。达不到就没有底薪、没有续期利益、无法继续展业。对一部分新人来说，最省事的达标方式就是给自己或家人买一份。首月保费 3 万元、佣金按 30% 计约 9000 元，实际支出两万出头，换来的是转正资格与继续留任的机会。这在个体层面是理性选择，在高频出现时就成了系统性问题。

**主管代垫与佣金回流。** 更隐蔽的形式是主管出资让下属出单——钱从主管账户转到新人或新人亲属账户，用新人名义投保，佣金发给新人后再回流给主管。这样新人完成了考核，主管拿到了增员奖与团队业绩，双方都受益。这类结构在图上的特征是：佣金发放对象与保费出资方不是同一人，资金形成闭环。

**虚假增员套取奖励。** 增员奖励通常是"每增一名有效人力奖励若干元"，且要求新人达成一定保费。于是出现凑人头的做法：让亲属、老客户、甚至不存在的人挂名入职，自己出单达标，领取奖励后离职。更极端的形态是"轮回入职"——同一个人离职后换一个身份（配偶、父母）再次入职，重复领取增员奖励与新人津贴。

**团队互买互退循环。** 同团队代理人之间互相投保、互相成为对方客户，完成各自的业绩考核，拿到佣金与奖励后，在犹豫期或次年集中退保。这种循环在单份保单上看完全正常——有投保人、有被保险人、有真实缴费；异常只存在于关系的循环结构与退保的时间一致性上。

| 形态           | 核心操作                     | 单份保单合规性 | 关键异常信号                       | 主要受益方                   |
| -------------- | ---------------------------- | -------------- | ---------------------------------- | ---------------------------- |
| 新人自购转正   | 为自己或家人投保以达标       | 完全合规       | 自保件占比高、集中于入职首季       | 新人（保资格）、团队（业绩） |
| 主管代垫与回佣 | 主管出资、新人出单、佣金回流 | 合规           | 出资人与佣金受领人分离、资金闭环   | 主管（增员奖、团队业绩）     |
| 虚假增员       | 凑人头领取增员奖励           | 合规           | 入职集中、留存极短、新人件即自保件 | 主管与推荐人                 |
| 互买互退循环   | 团队成员互相投保后集中退保   | 合规           | 关系闭环、退保时间聚集             | 团队全体                     |

# 二、为什么内部套利很难被发现

**考核只看总量，不看来源。** 保费、增员数、人均产能都是汇总指标，它们无法区分"来自客户的保费"与"来自代理人自己钱包的保费"。当一个团队的自保件占比从 15% 涨到 40%，汇总报表上看到的只是业绩增长，看不出结构变化。

**自保件在保单字段里没有特殊标记。** 投保人身份与代理人身份分别存在两个系统里：代理人档案在人力系统，保单在业务系统。除非专门做身份比对，否则"这张保单的投保人就是本公司代理人"这件事在业务系统里并不显式存在。亲属关系更是完全没有数据支撑。

**佣金与奖励的追回有时滞。** 佣金当期发放，退保却往往发生在一年甚至更久之后。等到退保数据出来，佣金早已结清、奖励早已兑现，追回在操作上困难、在制度上争议很大。这种时间错配使得套利几乎无风险。

**人力与业务数据不互通。** 组织架构、上下线关系、入职离职记录在人力系统里；出单、佣金、退保存在业务系统里。识别"某主管的增员中，有多少人在短期内离职且留有自保件"这类问题，需要跨系统关联，而在各自独立的系统里，这个查询无法提出。

| 对比维度   | 汇总报表与规则校验     | 图数据库关联图谱                         |
| ---------- | ---------------------- | ---------------------------------------- |
| 观察单元   | 团队与个人的汇总数字   | 代理人—亲属—保单—佣金—退保构成的关系网   |
| 身份比对   | 人力系统与业务系统分离 | 代理人身份作为节点属性，可直接判定自保件 |
| 资金闭环   | 不可见                 | 出资方与佣金受领方的关系路径可直接检出   |
| 增员质量   | 只看人数与留存率       | 增员链、轮回入职、亲属关联可一并呈现     |
| 退保归因   | 只能看整体退保率       | 可区分自保退保与客户退保，并按团队聚合   |
| 处置颗粒度 | 一刀切限制自保件       | 可对具体循环结构定向处置                 |

# 三、图谱怎么建：把代理人也当成客户

**建模的关键，是承认"代理人"与"投保人"这两个身份可能落在同一个节点上。** 图谱里自然人只有一个节点，他既是代理人（带入职时间、职级、所属团队、上线），也可能是投保人或被保险人（带与保单的关系）。这样"这张保单的投保人是不是本公司代理人"就变成节点属性判断，而不是跨系统的身份比对。

亲属关系需要单独处理。多数公司没有代理人亲属数据，可行的做法是通过投保时的受益人、联系电话、联系地址、缴费账户等要素推断关联强度：共用缴费账户、同一联系地址、互为受益人的组合，基本可以确定存在紧密关系；只有单一要素重合的标记为低置信度，不单独作为判定依据。

常用的节点包括自然人、代理人身份、保单、团队、佣金发放记录、退保记录、银行账户；边覆盖雇佣、上下线、亲属推断、投保、缴费、佣金支付、退保等类型，均带时间与金额属性。

这是最基础的一层，回答"这名代理人的保单里有多少投给了自己或家人"。更有价值的是叠加时间维度的查询：这些保单的出单时间是否集中在入职或考核节点的前后，退保时间是否聚集在离职后的一段窗口内。**时间聚集比数量占比更有判别力**——真实的员工保障需求在时间上应当是分散的，而套利行为天然具有节点特征：入职时集中出单，保级前集中补单，离职后集中退保。

# 四、图算法与识别信号清单

| 识别目标           | 图算法           | 判读方式                                             | 处置建议                       |
| ------------------ | ---------------- | ---------------------------------------------------- | ------------------------------ |
| 是否存在资金闭环   | 环检测           | 保费出资方与佣金受领方之间存在闭合路径               | 转入合规调查，核查真实投保意愿 |
| 团队是否系统性自保 | 社区发现         | 团队内部形成密集互投子图，对外客户关系稀疏           | 团队层面专项治理，而非处理个案 |
| 增员是否有真实价值 | 路径聚合         | 增员链上新人留存期短、自保件占比高、无外部客户       | 停发该链路增员奖励并追溯       |
| 是否轮回入职       | 实体解析与相似度 | 同一自然人以不同身份重复入职，或亲属关系高频伴随入职 | 建立黑名单与入职校验规则       |
| 退保是否异常       | 时序异常检测     | 自保件退保率显著高于同期客户保单，且集中在离职窗口   | 调整佣金与奖励的追回规则       |
| 谁在组织           | PageRank         | 连接多条增员链与多条资金闭环的节点                   | 列为重点人员，纳入考核问责     |

一次典型的命中推演：以某团队主管为起点展开三跳，图上出现 17 名下线、43 张保单、9 个银行账户、5 条资金闭环路径。这 17 名下线中有 11 人在职不足 6 个月，43 张保单里有 29 张的投保人是下线本人或其亲属，其中 18 张在离职后 90 天内退保。再沿佣金路径回溯，发现 9 个账户中有 4 个同时出现在"主管出资"与"佣金回流"两端。到这里结论已经很明确：这不是若干代理人各自为家人买保险，而是一条以增员奖励与佣金为目标的稳定通路。

需要注意的是，自保件不应被简单禁止。代理人给自己和家人配置保障，既是合理的个人需求，也是行业长期鼓励的从业者风险意识体现。具备判别力的是三个条件的叠加：**名义客户集中于代理人自身与亲属、佣金与奖励形成回流闭环、保单生命周期在离职或考核节点后集中终止**。只满足其中一条，属于正常现象；三条同时成立，才构成套利结构。

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

针对人力与业务数据分属不同系统、关系结构复杂、需要按团队与个人双向穿透的特点，悦数图数据库提供了几项关键支撑：万亿边规模可容纳全量代理人档案、组织架构、保单、佣金与退保记录，支持多年数据统一构图；动态 Schema 支持新增数据源（如考勤、培训、投诉记录）不停机扩展模型；内置图算法库直接提供环检测、社区发现、PageRank、时序异常检测与路径聚合等算子，无需自研；CDC 实时同步让新出单、新佣金、新退保在秒级内进入图谱，使异常在发生当期即可被感知；配合 Text2nGQL，合规与督导人员可以用自然语言查询某个团队的关系结构，不必先掌握图查询语言。

代理人自保件与增员泡沫之所以长期存在，是因为它恰好落在人力系统与业务系统的接缝处——**两个系统各自的数据都完整，但没有任何一方能看到"这个人既在我的队伍里，又是我的客户"**。图数据库的价值在于把这两个身份放到同一个节点上，让资金、保单、组织关系第一次可以被摆在同一个视野里审视。当结构变得可见，增长与留存这两个数字也就不会再互相打架。

悦数图数据库可整合代理人档案、组织架构、保单、佣金发放、退保记录与客户关系等多源数据，构建保险团队内部关联图谱，把代理人、亲属、上下线与保单之间的关系显式建模，通过循环检测、社区发现、时序异常检测与路径聚合等图算法，识别以套取佣金与增员奖励为目的的自保件循环、虚假增员与互买互退结构，帮助保险公司区分正常员工保障需求与系统性内部套利，降低费差损与虚增人力水分。

代理人自保件与增员泡沫：图数据库如何揭示保险团队的内部套利？

![健康险重复理赔图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-23.png)

算一笔账。某患者住院总费用 8 万元，医保统筹报销 4.6 万元，个人自付 3.4 万元。他在两家公司各买了一份百万医疗险，免赔额都已通过其他就医记录抵充，赔付比例 80%。当前行业缺乏[健康险重复理赔图数据库](https://www.yueshu.com.cn/database)关联校验能力，如果两家公司各自按"自付部分 3.4 万的 80%"全额赔付，他能拿到 2.72 万 × 2 = 5.44 万元——比自己实际掏的 3.4 万元还多出 2 万元。保险的本意是补偿损失，而当赔付金额超过实际支出时，生病就从一件倒霉事变成了一笔有正收益的生意。这不是假设出来的极端情形，而是费用补偿型健康险在设计上就存在的缝隙：理赔审核确认的是"这笔费用真实发生、单据真实、属于保险责任"，从来不问"这笔费用是不是已经在别处被赔过一次"。跨公司之间没有费用核销机制，同一张发票的复印件在两家公司的理赔系统里各自成立，互不知情。

# 一、健康险重复理赔的四种形态

**同一笔费用跨公司重复报销。** 最典型的一种。投保人在两家公司投保费用补偿型医疗险，住院后用同一套材料分头索赔。由于两家公司核赔系统不互通，且赔案之间不存在任何共享标识，重复在技术上无法被发现。部分消费者并不认为这是问题——"我交了两份保费，凭什么只赔一份"，这正是费用补偿原则在消费者认知层面最容易被误解的地方。

**医保已支付部分再向商业险索赔。** 医保统筹支付的部分不属于"个人自付"，本不应再由商业医疗险赔付。但理赔材料如果只提交总费用发票与费用清单，不提交医保结算单，审核人员很难区分哪些是统筹支付、哪些是自付。部分产品通过"区分有无医保"的费率设计间接处理，但核赔环节缺少刚性校验。

**拆分费用、分头索赔。** 把一次住院的费用拆解成门诊、药品、检查等多个部分，分别向不同公司索赔；或者同一疗程的多次就诊，用不同的诊断编码重复申报。这类手法的关键在于"看起来是不同费用"，只有把费用明细与就诊时间轴对齐，才能看出它们指向同一次治疗。

**冒名就医与出借医保卡。** 团伙化的一种：借用他人医保卡就医购药，再用自己的商业保单索赔；或者把他人的检查、治疗记在自己名下。这类行为的异常点在于就诊记录与本人的既往病史、年龄、性别特征不符。

| 形态           | 核心操作             | 单据层面         | 单家公司可见性   | 图上可见信号                 |
| -------------- | -------------------- | ---------------- | ---------------- | ---------------------------- |
| 跨公司重复报销 | 同一套材料分头索赔   | 真实有效         | 只看到本次索赔   | 同一费用凭证节点入度大于 1   |
| 医保已付再索赔 | 隐去医保结算单       | 材料真实但不完整 | 无法判断支付构成 | 凭证金额与自付金额不匹配     |
| 拆分费用索赔   | 一次治疗拆成多笔申报 | 单据各自真实     | 只看到其中一笔   | 就诊时间轴重合、诊断编码相似 |
| 冒名就医       | 借用他人身份就诊     | 就诊记录真实存在 | 无法比对本人病史 | 就诊特征与本人画像不符       |

# 二、为什么核赔环节查不出重复

**理赔审核确认的是真实性，不是唯一性。** 一份理赔案的审核链条是：单据是否真实、费用是否发生、是否属于保险责任、是否在保额与免赔额范围内。这套逻辑里没有"是否重复"这一项，因为"重复"是一个需要跨案件比对才能回答的问题，而核赔人员手上的只有这一个案子。

**费用凭证没有核销状态。** 发票、费用清单在报销完成后不会被标记"已赔付"，它只是一张纸或一份 PDF 的复印件。电子发票普及后，重复打印更加容易，而多数机构的理赔系统甚至没有对发票号码做全局唯一索引。

**医保与商业险数据不打通。** 医保结算数据掌握在医保部门，商业保险公司只能拿到客户提交的材料。客户不提交结算单，公司就不知道统筹支付了多少。近年部分地区推进了医保商保同步结算试点，但覆盖面与字段颗粒度仍不足以支撑逐案校验。

**跨公司信息共享滞后且保守。** 行业层面有反欺诈信息交换机制，但共享的多为已确认欺诈案件与黑名单，且滞后于理赔时效。实时共享投保与理赔明细涉及数据合规与商业竞争，推进难度较大。

| 对比维度   | 单案审核模式         | 图数据库关联图谱                 |
| ---------- | -------------------- | -------------------------------- |
| 审核对象   | 单起理赔案、单套材料 | 凭证、就诊、保单、账户构成的子图 |
| 重复判定   | 无判据，无法回答     | 凭证节点入度直接给出答案         |
| 支付构成   | 依赖客户提交材料     | 可融合医保结算数据交叉验证       |
| 身份校验   | 证件号单点匹配       | 多要素实体解析，识别同人多身份   |
| 发现时机   | 事后抽检或举报       | 核赔环节实时提示                 |
| 给付型险种 | 无法区分，易误伤     | 按险种属性差异化处理，避免误判   |

# 三、图谱怎么建：把费用凭证变成可连接的节点

**建模的第一件事，是把"费用凭证"从附件变成节点。** 在传统理赔系统里，发票是案件的附件，是不可检索的扫描件；在图谱里，每张发票、每次就诊、每笔医保结算都应该是独立节点，与理赔案件、被保险人、医疗机构之间建立带时间与金额属性的边。这样"同一张发票被几家公司的几起案件引用过"就变成一次简单的入度查询，而不是一次跨机构的数据比对。

节点通常包括：自然人、保单、理赔案件、就诊记录、费用凭证、医保结算记录、医疗机构、诊断编码、收款账户。边覆盖索赔、就诊、产生费用、结算支付、包含诊断等类型，均带时间戳与金额。

**实体解析是准确性的前提。** 跨公司数据要连起来，前提是确定"这是同一个人"。姓名加证件号在多数情况下够用，但遇到曾用名、证件换发、家庭成员代持保单时就会断裂。实践中建议用证件号、手机号、银行账号、联系地址、就诊卡号的组合做相似度匹配，高置信度连接直接建边，中低置信度连接标记为待核实，参与连通但不作为单独判据。

这条语句回答的是：这张凭证被几起理赔案件引用过。正常情况下入度为 1，入度大于 1 即需核查是否为重复索赔。这里的难点不在查询本身，而在凭证的标准化——同一笔费用在不同机构可能以不同号码、不同拆分方式出现，因此需要用金额、就诊日期、机构编码做组合匹配，而不只依赖发票号。

**一个必须做的前置区分：给付型与补偿型。** 重疾险、寿险、意外身故伤残属于给付型，确诊即按保额给付，多份保单可以叠加赔付，这是合同约定的正当权益；医疗险属于费用补偿型，赔付以实际支出为上限，重复报销才构成渗漏。图谱里必须给每个险种打上属性标签，让重复识别只对补偿型生效，否则会把大量正常的多份重疾赔付误判为欺诈——这是健康险反欺诈最容易踩的坑。

# 四、图算法与识别信号清单

| 识别目标         | 图算法             | 判读方式                                         | 处置建议                         |
| ---------------- | ------------------ | ------------------------------------------------ | -------------------------------- |
| 同一凭证是否重复 | 入度统计与实体解析 | 凭证节点入度大于 1，或金额与日期高度相似的凭证群 | 核赔环节拦截并协调查证           |
| 支付构成是否真实 | 相似度计算         | 申报自付金额与医保结算记录不一致                 | 要求补充结算单，按统筹后金额重算 |
| 就诊是否拆分申报 | 时序图分析         | 多笔申报的就诊日期重合、诊断编码一致             | 合并计算赔付上限                 |
| 冒名就医         | 画像匹配           | 就诊特征与被保险人既往病史、年龄性别不符         | 启动调查，核对就诊人身份         |
| 团伙化操作       | 社区发现           | 多名被保险人的就诊集中在同一机构与同一账户       | 整片核查，涉及医保的移送         |
| 赔付是否超上限   | 路径聚合           | 沿被保险人聚合所有补偿型赔付，与实际自付总额比对 | 触发追回与后续保单核查           |

一次典型的命中推演：以某被保险人为起点展开两跳，图上出现 3 份医疗险保单、5 起理赔案件、11 张费用凭证、2 家医院。其中 4 张凭证的入度为 2，分别被两家公司的案件引用；进一步核对发现，这 4 张凭证对应的住院日期与医保结算单上的统筹支付金额为 2.8 万元，而两家公司申报的自付金额合计却超过了住院总费用。到这里结论很明确：不仅重复索赔，还把医保已支付部分计入了自付。

值得一提的是，多数医疗险条款里本就写有"其他保险分摊"约定——若被保险人拥有其他费用补偿型保险，各方按比例分摊赔付，合计不超过实际支出。这条条款几乎从未被真正执行过，原因不是保险公司不想执行，而是**执行它需要知道"其他公司赔了多少"，而这个数据拿不到**。图谱在这里的作用不是创造新规则，而是让既有条款第一次具备了可执行的数据基础：哪怕只在本公司范围内打通多份保单，也能先消除内部重复，再把分摊机制延伸到机构间协作场景。

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

针对健康险数据多源、凭证颗粒度细、核赔要实时的特点，[悦数图数据库](https://www.yueshu.com.cn/what-is-graph)提供了几项关键支撑：万亿边规模可容纳全量保单、理赔案件、就诊与费用凭证的关联关系，不做时间截断；动态 Schema 支持新增数据源（如医保结算明细、处方流转数据）不停机扩展模型；内置图算法库直接提供社区发现、PageRank、相似度计算、时序异常检测等算子，无需自研；CDC 实时同步让新发理赔在秒级内进入图谱，核赔当时即可看到凭证关联提示；配合 Text2nGQL，核赔与调查人员可以用自然语言查询某张凭证或某个被保险人的关联网络，不必先掌握图查询语言。

健康险重复理赔之所以普遍，不是因为核赔不认真，而是因为**"这笔钱赔过没有"这个问题，在单案视角下根本无法回答**。图数据库做的不是更严格的审核，而是给每张凭证、每次就诊一个可以被反复引用的身份，让它们在第二次出现时能被认出来。当凭证有了身份，重复就不再是靠运气发现的事。

悦数图数据库可整合保单、理赔案件、医疗费用凭证、医保结算记录、医疗机构与账户信息等多源数据，构建健康险反欺诈关联图谱，把费用凭证与理赔主体作为可连接的节点，通过凭证入度分析、社区发现、实体解析与时序异常检测等图算法，识别同一笔费用跨公司重复报销、医保已付部分再报商业险、拆分费用分头索赔等渗漏结构，帮助保险公司在核赔环节发现重复赔付，同时避免对给付型险种正常叠加赔付的误伤。

健康险重复理赔：跨公司投保记录如何用图数据库的关系串联？

![意外险骗保图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-22.png)

先算一道概率题。一个成年人一年内遭遇导致伤残的意外事故，概率大致在千分之二上下；如果这个人的配偶在同一年也遭遇同类事故，两个独立事件同时发生的概率是百万分之四。某保险公司在回溯一桩案件时发现，一个三人家庭在十四个月内产生了 4 起意外伤残理赔，涉及 6 家保险公司的 11 份保单，受益人集中在同两个人身上。按独立事件计算，这种事发生的概率不到十亿分之一 ——**它当然不是巧合**。但在理赔系统里，这 11 份保单分属 6 家公司、11 个承保系统、11 条互不相干的记录，没有任何一个环节能看到完整的 11。受益人这一栏在投保时被填成 "法定" 或一个人的名字，然后就沉进了保单的字段里，再也没有被当作一个可以拿来连接的主体。意外险骗保之所以屡屡得手，正是利用了这一点：**它不需要伪造得很高明，只需要分散得够开。**而破解这种 "分散"，靠的正是[**意外险骗保图数据库**](https://www.yueshu.com.cn/database)—— 把散落在各公司的保单、受益人、地址、电话、银行账户当作一个个节点，用关系把看似无关的记录连成一张网，让 "同一受益人背后挂着 11 份保单" 这样的异常，从数据孤岛里浮出来。

# 一、意外险骗保的四种典型手法

**短期密集投保。** 在数周内向多家公司投保高额意外险，保费支出相对赔付额微不足道，等待期一过就"出险"。这类手法的关键是分散——单家公司的保额都在核保免检线以下，累计起来却可能高达数百万。由于各公司核保信息不互通，除非主动做行业累计保额查询，否则没人知道这个人在别处还买了多少。

**受益人异常集中。** 被保险人是不同的人——配偶、父母、子女、甚至朋友——但受益人反复指向同一两个人。这在真实投保中并非不可能（家庭主投保人常指定配偶为受益人），但当被保险人与受益人之间不存在可解释的亲属或利益关系，且多份保单重复这一模式时，就需要警惕。更极端的情形是"被保险人不知情"：被保人签名由他人代签，保单由同一人出资购买。

**伤残鉴定套利。** 意外险赔付金额高度依赖伤残等级，而伤残等级由鉴定机构认定。同一家鉴定机构、同一批被鉴定人、相似的事故类型、集中在某一等级临界点上的结论——这种分布特征在正常业务里几乎不会出现。医疗记录与鉴定结论之间的不一致也是常见信号：诊断却为软组织挫伤，鉴定却给出十级伤残。

**旧伤新报与事故再造。** 把投保前就存在的损伤留到保单生效后报案，或对事故时间、地点、经过做技术性修改，使其落入保险责任范围。这类案件材料齐全、流程合规，单看挑不出毛病，异常只体现在时间线与损伤特征的一致性上。

| 手法         | 核心操作                               | 单份保单合规性 | 单家公司可见性     | 图上可见信号                                 |
| ------------ | -------------------------------------- | -------------- | ------------------ | -------------------------------------------- |
| 短期密集投保 | 数周内跨公司投保，单份保额压在免检线下 | 合规           | 只看到自己这一份   | 同一投保人时间窗内保单数量与累计保额异常     |
| 受益人集中   | 多个被保险人的受益人指向同一人         | 合规           | 只看到自己这一份   | 受益人节点入度异常高，且被保险人之间关联薄弱 |
| 伤残鉴定套利 | 集中鉴定机构、等级聚集在临界点         | 有鉴定报告     | 只看到自己这一案   | 鉴定机构节点连通大量相似案件，结论分布异常   |
| 旧伤新报     | 事故时间或责任归属做技术性修改         | 材料齐全       | 无法比对投保前记录 | 损伤特征在不同理赔案中重复出现               |

# 二、为什么这类骗保在核保环节看不见

**核保看的是这一份，不是这一堆。** 核保规则校验的是年龄、职业、健康状况、保额与收入匹配度、既往理赔史。这些信息都在"这一份保单"的上下文里，跨公司的投保行为不在视野之内。即便做了行业信息查询，通常查的也是理赔史与黑名单，而非"此刻正在生效的累计保额"。

**受益人是字段，不是主体。** 这是最根本的问题。在关系模型里，受益人挂在保单下，是保单的一个属性；要做"找出所有以某人为受益人的保单"，需要遍历全表并按字符串匹配姓名，姓名重名、同音不同字、曾用名都会让结果失真。实际上几乎没有公司会做这件事。

**理赔是第一次看到全貌的时候，但那时已经晚了。** 核赔环节能拿到医疗记录、事故证明、鉴定报告，理论上信息最全，但此时赔付义务已经成立，拒赔需要证据而非怀疑，成本极高。

**人工抽查覆盖率有限。** 反欺诈团队通常按金额或随机抽取案件做深度调查，覆盖率往往不足百分之几。骗保者的应对很简单：把单案金额控制在抽查阈值以下。

| 对比维度   | 传统核保与核赔         | 图数据库关联图谱                   |
| ---------- | ---------------------- | ---------------------------------- |
| 观察单元   | 单份保单、单起理赔     | 人、家庭、账户、机构构成的关联子图 |
| 受益人处理 | 保单附属字段，不可检索 | 独立节点，可做入度与出度分析       |
| 累计保额   | 仅本公司可见           | 跨公司数据融合后可实时累计         |
| 时序特征   | 静态快照               | 投保、出险、鉴定、理赔全时间轴     |
| 识别时机   | 理赔后抽查             | 核保与核赔环节实时提示             |
| 证据形态   | 怀疑为主，取证困难     | 结构路径可复核，指向明确           |

# 三、图谱怎么建：把受益人提升为枢纽节点

**建模的第一件事，是把受益人从字段变成节点。** 投保人、被保险人、受益人、代理人、鉴定机构、医疗机构、收款账户都作为独立节点，保单作为连接它们的事件节点。这样"同一个人在多少份保单里担任受益人""这些保单的被保险人之间是什么关系"就变成一次遍历，而不是一次全表扫描。

身份识别是这一步的难点。姓名匹配会引入大量误连，因此需要用多要素做实体对齐：证件号、手机号、银行账号、联系地址、设备指纹的组合匹配优于单一姓名；对无法确定的连接，标记为低置信度边，参与连通但不单独作为判定依据。

**时序约束同样是剪枝的关键。** 在遍历时限定"投保时间在出险时间之前 N 天内"，可以把大量历史路径排除掉，只保留与当前案件相关的时间邻近子图。意外伤害险的等待期通常只有几天到几十天，这个窗口恰好也是骗保行为最集中的区间，因此时间窗既是约束条件，也是识别信号本身。

# 四、图算法与识别信号清单

| 识别目标                 | 图算法                 | 判读方式                                                     | 处置建议                   |
| ------------------------ | ---------------------- | ------------------------------------------------------------ | -------------------------- |
| 受益人是否集中           | 入度统计与社区发现     | 受益人节点入度显著高于同类客户，且被保险人群体分散           | 触发人工核保与关系核实     |
| 投保是否密集             | 时序图异常检测         | 时间窗内新增保单数量与累计保额突然跃升                       | 核保环节要求补充财务告知   |
| 被保险人群体是否真实关联 | 联通子图与亲属关系推断 | 被保险人之间有亲属、雇佣或同址关系则正常；无关联却同受益人需警惕 | 核实投保意愿与签名真实性   |
| 鉴定结论是否异常         | 相似度计算与分布检验   | 同一机构结论集中在等级临界点、伤情描述高度重复               | 启动复勘与机构评估         |
| 谁在组织                 | PageRank               | 连接多份保单、多个被保险人、同一收款账户的核心节点           | 列入重点名单并关联历史案件 |
| 影响范围                 | 最短路径与联通子图     | 量化一次确认骗赔牵连的保单数量与累计保额                     | 决定是否移送与追偿范围     |

一次典型的命中推演：以某受益人为起点展开两跳，图上出现 11 份保单、7 名被保险人、3 家鉴定机构、2 个收款账户。7 名被保险人之间只有两对存在亲属关系，其余五人彼此无关联、不同址、不同职业，却都由同一代理人经手、都指定同一受益人、都在投保后 40 天内出险，且伤残结论全部落在十级。此时判定依据已经不是"某一份保单有问题"，而是"这组投保行为缺乏合理的社会关系解释"。

必须说明的是，结构异常不等于骗保。真实的建筑工人、货车司机、外卖骑手确实会短期购买多份意外险，他们的出险概率也确实高于平均值；一个家庭在同一代理人处分批投保同样常见。可靠的做法是把结构信号与行为证据叠加：投保动机是否可解释、被保险人是否知情、事故是否有客观证据、医疗与鉴定是否一致，四项中至少三项存疑才进入深度调查，避免把高风险职业客户简单地标签化。

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

针对人身险反欺诈多主体、强时序、跨机构的特点，悦数图数据库提供了几项关键支撑：万亿边规模可容纳全量历史保单、被保险人、受益人与机构的关联关系，不做时间截断；动态 Schema 支持新增数据源（如外部医疗记录、行业共享数据）不停机扩展模型；内置图算法库直接提供社区发现、PageRank、子图匹配、相似度计算、时序异常检测等算子，无需自研；CDC 实时同步让新投保与新发理赔在秒级内进入图谱，核保当时就能看到关联提示；配合 Text2nGQL，反欺诈调查人员可以用自然语言查询某个受益人的关联网络，不必先掌握图查询语言。

意外险骗保依赖的不是技术，而是**分散**——把 11 份保单拆到 6 家公司，让每一家都只看到一个不足为奇的片段。图数据库做的事情并不复杂：把这 11 份重新放回同一张图上，让受益人、时间窗、代理人、鉴定机构这些原本互不照面的要素同时出现在一个视野里。当分散失效，巧合就只能是巧合以外的东西。

悦数图数据库可整合保单、投保人、被保险人、受益人、代理人、医疗机构与伤残鉴定等多源数据，构建人身险反欺诈关联图谱，把受益人从保单附属字段提升为枢纽节点，通过时间窗密度统计、社区发现、子图匹配与时序异常检测等图算法，识别短期密集投保、受益人集中、伤残鉴定套利与旧伤新报等骗保结构，帮助保险公司在核保与核赔环节提前发现异常关联，降低赔付渗漏与合规风险。

意外险骗保：同一受益人短期多保单的巧合，图数据库如何识别？

![收款码冒用图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-09-20.png)

一张收款码纸，只能贴在一个地方。这是物理世界的常识，也是收单风控长期默认的前提。但数字世界不遵守这个前提：某家连锁早餐店的静态收款码，在周一早上 7 点 12 分到 7 点 19 分的七分钟里，被 14 个不同城市的付款账户扫了 23 次，而这家店此刻只在苏州开门营业，店里的收银员手里还攥着那张塑封的码牌。同一时间，同一张码，在两个相距三千公里的地方同时被使用——这在物理上不可能，在支付系统里却完全合法。因为系统校验的是"码是否存在、是否有效、是否属于这个商户"，从来不问"扫它的这个人此刻应该站在哪里"。**收款码被冒用之所以难防，根源不是校验不够严，而是校验的对象选错了：查的是码，而不是这张码正在参与的那张关系网。**

### 一、收款码被冒用的四种典型形态

**静态码被翻拍与复制。** 这是最常见的一种。商户把收款码打印张贴在柜台，任何人用手机拍一张照片，就能在别处无限次使用。因为收款码本质是一串商户标识的编码，复制它不需要任何技术门槛，一张照片足矣。被复制的码通常流向两类用途：一是给远程诈骗收款，付款人扫的是"某家小超市"的码，钱实际进了诈骗链路；二是给赌博、色情等违规业务做资金通道，借用正规商户的外衣洗白入账。

**聚合支付子码被套用。** 连锁品牌、商圈市场通常由服务商批量开通子商户码。如果服务商风控松懈，或者内部人员违规操作，一个子码可以被反复下发给不同实际经营者使用。这类冒用的隐蔽性在于：从支付机构视角看，这笔交易在商户档案层面完全合规——有入网资料、有营业执照、有结算账户；真正的问题在于"实际用码的人"和"档案里的人"不是同一个，而这一层信息根本不在交易报文里。

**商户资料冒名入网。** 不法分子用他人身份证、营业执照复印件完成入网审核，拿到的是一张"干净"的码。这类码从第一天起就是为违规用途准备的，前几个月还会刻意模拟正常经营——小额、高频、白天营业时段、金额带零头，把可疑度压到阈值以下，等"养熟"之后再放量。冒名入网的识别难点是：单看任何一笔交易都正常，异常只体现在整体行为结构与真实经营场景的偏离上。

**码牌调包与终端侧篡改。** 商户店内码牌被偷偷替换，或者 POS 终端被改装后把交易上送到另一个商户号。这种手法在餐饮、零售门店偶有发生，往往要等商户对账时发现"今天的流水少了"才暴露，此时损失已经持续了数周。

四种形态的共同点是：**交易本身合法，异常藏在关系结构里**。

| 冒用形态     | 交易层面是否合规 | 商户档案层面             | 主要资金用途           | 可见信号                                        |
| ------------ | ---------------- | ------------------------ | ---------------------- | ----------------------------------------------- |
| 静态码翻拍   | 完全合规         | 真实商户，被动受害       | 远程诈骗收款、违规通道 | 付款地离散、非营业时段、付款人互不相识          |
| 聚合子码套用 | 完全合规         | 档案存在但实际经营者不符 | 套现、分账、规避费率   | 同一子码对应多个设备与结算去向                  |
| 冒名入网     | 完全合规         | 资料虚假或盗用           | 洗钱、赌博资金归集     | 养熟期后金额与频次突变、经营场景缺失            |
| 码牌调包     | 完全合规         | 真实商户，被动受害       | 截留营业款             | 同一门店出现两个活跃受理源、流水与 POS 对账不符 |

### 二、为什么异常入账在入账当时拦不住

**监测单元是"笔"，而异常存在于"网"。** 收单风控的主流做法是对单笔交易打分：金额是否超限、时段是否异常、付款账户是否黑名单、商户当日累计是否超标。这套逻辑对"大额可疑"有用，对冒用场景基本无效——冒用者恰恰是照着规则反着设计的，每笔金额都在阈值以下，时段刻意避开凌晨，付款账户都是全新白户。单笔视角下，23 笔分散在全国的交易每一笔都干净；只有在"这张码今天被哪些人扫了、这些人之间什么关系、他们此刻应该在哪"这个网络视角下，异常才浮出水面。

**关系数据的查询成本让人放弃实时。** 即便风控人员想做网络校验，在关系数据库里也要跨商户表、终端表、账户表、设备表、地理位置表做多表 JOIN，再叠加时间窗聚合。一次校验涉及五六张表、上亿行流水，实际耗时以分钟计，而一笔支付交易留给风控决策的时间通常不超过 200 毫秒。这不是优化能解决的问题，是数据模型的物理限制。

**清算与对账的滞后性。** 冒用造成的损失往往在 T+1 对账时才被发现：商户发现流水少了一块，支付机构发现某码的交易地理分布不对劲。但对账时钱已经结算走了，追回成本极高。更麻烦的是，冒用码一旦被标记，黑产手上还有几十张养熟的备用码，封一张换一张。

| 对比维度   | 规则引擎单笔监测             | 图数据库实时图谱                           |
| ---------- | ---------------------------- | ------------------------------------------ |
| 观察单元   | 单笔交易                     | 码、终端、付款人、设备、地理位置构成的子图 |
| 异常判据   | 阈值与黑名单                 | 拓扑结构偏离（离散度、聚集度、位置一致性） |
| 响应时机   | 准实时至 T+1                 | 入账当时（百毫秒级）                       |
| 跨码关联   | 无法识别同一团伙控制的多张码 | 通过共用设备、共用付款群、共用结算路径识别 |
| 误伤控制   | 阈值一松一紧反复震荡         | 结构证据链可复核，误判可回溯               |
| 对手适应性 | 规则公开后易被规避           | 结构特征难以逐项规避                       |

### 三、实时入账图谱怎么建

**建模的第一件事是把"地理位置"变成一等公民。** 传统收单数据里，位置只是交易报文的一个字段；在图谱里，位置要能参与判断——付款人的常驻地、商户的经营地、设备的历史出现地，三者之间的一致性或矛盾，正是识别冒用的核心信号。常用的节点包括六类：商户、收款码、受理终端、付款账户、设备指纹、地理位置；边则包括扫码支付、终端绑定、设备登录、账户关联、位置出现等，每条边都带时间戳与金额属性。

**实时性靠写入链路而非查询优化。** 冒用拦截的价值窗口只有入账那一瞬，因此图谱必须是流式的：交易发生时即写入节点与边，CDC 同步把新发生的入账在秒级内推入图谱，同时维护一张"码—近 N 分钟付款账户集合"的滑动窗口视图。这样当第 24 笔可疑入账到来时，图谱里已经有前 23 笔构成的完整上下文，可以直接判断这笔是否属于异常结构，而不必回头查历史库。

**核心查询是带时空约束的多跳遍历。** 以被冒用的码为起点，向付款账户、设备、位置扩展两到三跳，同时施加两个约束：时间上限定在最近的时间窗内，空间上要求付款位置与商户经营地的合理半径。

真正把遍历"削"成可实时完成规模的，是空间约束：一旦要求付款位置必须落在商户经营地合理范围内，绝大多数历史路径会被直接剪掉，剩下的才是需要与当前交易比对的有效上下文。这一步剪枝的效果，比任何索引优化都显著。

### 四、图算法给冒用打分

结构信号需要量化才能进决策。以下几类算法在收款码冒用识别中最常被组合使用：

| 识别目标             | 图算法         | 判读方式                                                     | 处置建议               |
| -------------------- | -------------- | ------------------------------------------------------------ | ---------------------- |
| 付款人群是否离散     | 社区发现       | 一个正常商户的付款人应有本地聚集性；冒用码的付款人彼此无连接、跨省分散 | 离散度超阈值转人工核查 |
| 谁在组织用码         | PageRank       | 找出连接多张码、多个付款群的核心账户                         | 列入重点观察名单       |
| 多码是否同源         | 联通子图       | 多张码通过共用设备或共用付款人连成一片                       | 整片降级或暂停结算     |
| 码与终端绑定是否异常 | 子图匹配       | 匹配"一码多终端"或"一终端多码"的可疑模式                     | 触发终端巡检           |
| 行为是否突变         | 时序图异常检测 | 对比养熟期与放量期的度数、金额分布变化                       | 放量期自动提高核查比例 |
| 损失影响面           | 最短路径       | 量化某张冒用码关联到的其他商户与账户数量                     | 决定处置范围与上报层级 |

一次典型的命中推演是这样的：某码在七天内的付款账户从日均 30 个涨到 240 个，付款人所在城市从集中在苏州变成覆盖 11 个省，社区发现显示这些付款人之间几乎无关联，却有 17 个账户共用 3 个设备指纹；进一步扩展两跳，发现这 3 个设备还连接着另外 9 张码，分属 6 个不同商户。此时结论已经不是"这张码可疑"，而是"有一个团伙在批量使用一组码"。这类结构一旦成形，处置成本极低——封一片比封一张有效得多。

需要注意的是，冒用识别必须给商户留申诉通道。静态码被翻拍时，商户本身是受害者，直接关停收款功能会误伤真实经营。更合理的做法是分层处置：轻度可疑保留收款、延迟结算；中度可疑限额并推送商户自查通知；确认冒用后暂停该码、为商户换发新码，并把设备与付款群特征沉淀成后续布控规则。

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

针对收单侧高频写入、实时判断、多源融合的场景特点，[悦数图数据库](https://www.yueshu.com.cn/)提供了几项关键支撑：万亿边规模足以容纳全量商户、码、终端与历史入账的关联关系；存算分离架构让批量入图与在线拦截查询互不干扰；CDC 实时同步把新发生的入账在秒级内推入图谱，支撑入账当时的决策；内置图算法库直接提供社区发现、PageRank、联通子图、子图匹配、时序异常检测等算子，无需自研；动态 Schema 支持新增数据源（如设备指纹、地理位置服务商）不停机扩展模型；配合 Text2nGQL，风控运营人员可以用自然语言查询某张码的关系网络，不必先掌握图查询语言。

收款码被冒用的本质，是一张物理上唯一的码在数字世界里被复制成了无限份，而风控仍然按"一份"来校验。图数据库解决的不是把码变得更难复制，而是让每一笔入账都带着它所属的那张关系网一起被审视——**付款的人该不该出现在这里，扫它的人是不是同一批，这张码是不是还连着别的码**。当这些问题能在入账当时的两百毫秒内被回答，异常入账就不再只能等 T+1 对账时发现。

悦数图数据库可整合商户档案、收款码、受理终端、付款账户、设备指纹与地理位置等多源数据，构建收单侧实时关联图谱，通过时间空间双重约束的多跳遍历与社区发现、异常检测等图算法，在入账发生的瞬间识别码被复制、终端被调包、商户被冒名入网的异常结构，把拦截动作从 T+1 对账提前到交易当时，帮助银行与支付机构降低套现、洗钱与商户侧连带风险。