2. 金融图谱数据模型：实体识别与关系抽取、图数据库选型（Neo4j vs JanusGraph）、金融图谱Schema设计
2.1 金融图谱数据模型概述
金融图谱的核心是将金融业务中的实体（如企业、个人、账户、合同）与关系（如控股、担保、交易、任职）抽象为图结构。数据模型的设计直接决定了后续推理、查询与模型服务的效率。
关键原则：金融图谱数据模型需满足“高连通性、低延迟查询、可扩展Schema”三大要求。实体与关系的定义必须与业务风险指标（如关联交易识别、担保圈检测）对齐。
2.2 实体识别与关系抽取
实体识别（NER）与关系抽取（RE）是将非结构化文本（如财报、公告、新闻）转化为图谱三元组（实体-关系-实体）的核心NLP任务。
2.2.1 金融实体识别
- 常见实体类型：企业名称、自然人姓名、统一社会信用代码、金额、日期、合同编号、担保物。
- 技术方案：基于BERT的序列标注模型（如BERT-BiLSTM-CRF），结合金融领域词典与正则规则进行后处理。
- 挑战：实体嵌套（如“XX集团子公司”）、简称与全称对齐、跨文档共指消解。
2.2.2 关系抽取
- 常见关系类型：控股（持股比例）、担保（担保金额）、任职（职位）、交易（交易金额、时间）、关联关系。
- 技术方案：基于预训练模型（如RoBERTa）的联合抽取框架（CasRel、TPLinker），同时识别实体与关系。
- 输出格式：三元组
(头实体, 关系类型, 尾实体)，例如(“XX集团”, “控股”, “YY子公司”)。
实践建议：在金融场景中，关系抽取的精度比召回更重要。建议对模型输出进行“置信度阈值过滤 + 人工审核抽样”，避免错误关系污染图谱。
2.3 图数据库选型：Neo4j vs JanusGraph
图数据库是图谱存储与查询的底层引擎。Neo4j 与 JanusGraph 是金融领域最常用的两种方案，其选型需综合考虑事务性、扩展性、查询语言等因素。
| 对比维度 | Neo4j | JanusGraph |
|---|---|---|
| 存储引擎 | 原生图存储（本地文件系统） | 分布式后端（Cassandra / HBase / Bigtable） |
| 查询语言 | Cypher（声明式，易学） | Gremlin（遍历式，灵活） |
| 事务支持 | ACID 强事务 | 最终一致性（依赖后端） |
| 扩展性 | 单机或集群（读扩展为主） | 原生水平扩展（写扩展强） |
| 金融适用场景 | 中小规模图谱、实时风控查询、快速原型 | 超大规模图谱（百亿节点）、跨数据中心部署 |
| 运维复杂度 | 低（开箱即用） | 高（需管理分布式存储与索引） |
选型避坑：若图谱节点数超过 10 亿且需要频繁写入，Neo4j 的集群写扩展会成为瓶颈，此时应优先考虑 JanusGraph。若团队以业务分析师为主，Cypher 的易用性可大幅降低开发成本。
2.4 金融图谱Schema设计
Schema 是图谱的“骨架”，定义了实体类型、属性、关系类型及约束。金融图谱 Schema 设计需遵循“业务驱动、适度冗余、避免过度建模”原则。
2.4.1 实体节点设计
- 企业节点：属性包括企业名称、统一社会信用代码、注册资本、成立日期、行业分类、经营状态。
- 个人节点：属性包括姓名、身份证号（脱敏）、职务、联系方式（脱敏）。
- 合同节点：属性包括合同编号、金额、签署日期、到期日期、合同类型。
- 账户节点：属性包括账号（脱敏）、开户行、账户类型、余额范围。
2.4.2 关系边设计
- 控股关系：方向从股东指向企业，属性包括持股比例、持股起始日期。
- 担保关系：方向从担保人指向被担保人，属性包括担保金额、担保方式、担保期限。
- 任职关系：方向从个人指向企业，属性包括职位名称、任职起始日期、任职结束日期。
- 交易关系：方向从付款方指向收款方，属性包括交易金额、交易时间、交易类型。
2.4.3 Schema 设计示例（Cypher DDL）
// 创建企业节点标签与索引
CREATE CONSTRAINT unique_company_id FOR (c:Company) REQUIRE c.company_id IS UNIQUE;
CREATE INDEX idx_company_name FOR (c:Company) ON (c.name);
// 创建个人节点标签与索引
CREATE CONSTRAINT unique_person_id FOR (p:Person) REQUIRE p.person_id IS UNIQUE;
CREATE INDEX idx_person_name FOR (p:Person) ON (p.name);
// 创建关系类型（隐式定义，在插入时指定）
// 示例：插入控股关系
MATCH (c1:Company {company_id: 'C001'})
MATCH (c2:Company {company_id: 'C002'})
CREATE (c1)-[:HOLDS {ratio: 0.51, start_date: '2020-01-01'}]->(c2);2.5 金融图谱数据模型架构图
下图展示了金融图谱的核心实体、关系以及从数据源到图数据库的流转路径。
2.6 金融图谱Schema设计示例图
下图以“企业-个人-合同”为核心，展示了一个典型的金融图谱 Schema 结构，包含节点类型、关系类型及关键属性。
2.7 金融图谱Schema设计避坑指南
常见错误：
- 过度建模：将每个属性都建模为独立节点，导致查询深度过大、性能下降。应优先将静态属性（如注册资本）作为节点属性存储。
- 忽略时间维度：金融关系（如担保、任职）具有时效性。必须在关系边上携带
start_date和end_date属性，并支持时间范围查询。 - 缺乏索引：未对高频查询字段（如企业名称、信用代码）创建索引，导致全表扫描。需在 Schema 设计阶段就规划好索引策略。
- 关系方向混乱：所有关系必须明确方向（如“控股”从股东指向企业），避免双向关系导致语义歧义。
2.8 本章小结
- 金融图谱数据模型以实体-关系-属性为核心，NER/RE 是构建图谱的入口。
- 图数据库选型需权衡事务性、扩展性、查询语言：Neo4j 适合中小规模实时查询，JanusGraph 适合超大规模分布式场景。
- Schema 设计应业务驱动、适度冗余、明确时间维度，并提前规划索引与关系方向。