第二章：知识图谱核心技术栈
知识图谱这东西，说白了就是让机器学会「理解关系」。我做了这么多年金融科技，见过太多团队把精力花在算法上，结果数据质量一塌糊涂。今天咱们就把这五个核心环节——知识表示、抽取、融合、推理、存储与查询——掰开揉碎了讲清楚。
核心观点：知识图谱不是一锤子买卖，而是一个持续迭代的工程。五个环节环环相扣，任何一个短板都会拖垮整个系统。
2.1 知识表示：给机器一张「关系地图」
知识表示，就是决定用什么样的数据结构来描述现实世界中的实体和关系。我个人习惯用三元组——(实体, 关系, 实体)或者(实体, 属性, 属性值)。举个例子：(张三, 持有, 股票A)，这就是一个最简单的知识表示。
在金融领域，我遇到过最头疼的问题就是「实体歧义」。比如「苹果」——它到底是水果还是公司？所以我们在做知识表示时，必须引入本体（Ontology）来约束。OWL（Web Ontology Language）是工业界的主流选择，它支持类、属性、约束等丰富的语义表达。
我的经验：刚开始做知识图谱时，别一上来就搞复杂的OWL推理。先用RDF（资源描述框架）把数据组织起来，跑通流程再说。我曾经在一个反欺诈项目中，团队花了两个月设计本体，结果数据一接入发现根本对不上——嗯，教训深刻。
2.2 知识抽取：从非结构化文本中「挖金子」
知识抽取，说白了就是从新闻、研报、公告这些非结构化数据里，把实体和关系捞出来。主要分三步：
- 实体识别（NER）：找出人名、公司名、产品名等。比如「阿里巴巴」是一个组织实体。
- 关系抽取：判断实体之间是什么关系。比如「马云是阿里巴巴的创始人」——这里的关系是「创始人」。
- 属性抽取：提取实体的属性值。比如「阿里巴巴的市值是5000亿美元」——属性是「市值」，值是「5000亿美元」。
我建议用预训练语言模型（如BERT）做实体识别，准确率能到90%以上。但关系抽取就难多了——金融文本里经常出现「A公司收购B公司」这种复杂关系，需要结合依存句法分析。
避坑指南：我曾经在一个项目里直接用正则表达式做关系抽取，结果遇到「A公司未收购B公司」这种否定句，全抽反了。后来改用基于Transformer的序列标注模型，才把准确率提上来。
2.3 知识融合：把碎片拼成完整拼图
知识融合，就是解决「同一个实体在不同数据源里长什么样」的问题。你想想看，同一个人，在工商系统里叫「张三」，在新闻里叫「张先生」，在社交平台上叫「zhangsan123」——机器怎么知道它们是同一个实体？
核心方法有两种：
- 实体对齐：基于属性相似度（如名称、地址、电话）来判断。我常用编辑距离+Jaccard系数做初筛，再用图神经网络做精排。
- 冲突消解：当多个数据源对同一属性的值不一致时，需要决定信谁。比如A数据源说某公司注册资本1亿，B数据源说5000万——这时候需要看数据源的权威性和时效性。
| 数据源 | 实体名称 | 注册资本 | 成立日期 |
|---|---|---|---|
| 工商系统 | 北京字节跳动科技有限公司 | 10000万 | 2012-03-09 |
| 新闻 | 字节跳动 | 未披露 | 2012年 |
| 企业官网 | ByteDance | N/A | 2012 |
上面这个表格，就是典型的融合场景。工商系统最权威，所以注册资本以它为准；新闻里的「字节跳动」和官网的「ByteDance」需要对齐到同一个实体ID。
2.4 知识推理：让机器学会「举一反三」
知识推理，就是基于已有的知识，推导出新的知识。比如已知「A公司是B公司的子公司」和「B公司是C公司的子公司」，可以推理出「A公司是C公司的孙公司」——这就是传递性推理。
在金融风控中，推理特别有用。我记得有个项目是做关联交易检测：已知「张三持有A公司30%股份」和「李四是张三的儿子」，可以推理出「李四与A公司存在关联关系」。这种推理用规则引擎（如Drools）就能实现。
更高级的推理，比如基于图神经网络的链路预测，可以预测两个实体之间是否存在某种关系。我建议先跑规则推理，再上模型推理——规则推理快且可解释，模型推理准但黑盒。
关键点：推理不是万能的。如果知识图谱本身质量差——比如实体识别错了、关系抽反了——推理出来的结果就是「垃圾进，垃圾出」。所以前面三步（表示、抽取、融合）一定要扎实。
2.5 知识存储与查询：让知识「跑起来」
最后一步，就是把知识存起来，并且能高效查询。存储方案主要分两种：
- 关系型数据库（如PostgreSQL）：适合结构化数据，但多跳查询（比如「张三的朋友的朋友的朋友」）性能很差。
- 图数据库（如Neo4j、JanusGraph）：专门为关系查询设计，多跳查询性能极佳。我强烈推荐Neo4j，它的Cypher查询语言非常直观。
举个例子，用Cypher查询「张三直接或间接持有的所有公司」：
MATCH (p:Person {name: '张三'})-[:持有*1..3]->(c:Company)
RETURN c.name, c.注册资本这个查询中的[:持有*1..3]表示「持有关系可以传递1到3层」——这就是图数据库的威力。如果用SQL写同样的逻辑，得写一堆JOIN，性能还差。
我的建议：如果数据量在亿级以下，Neo4j足够用。如果数据量在十亿级以上，可以考虑JanusGraph+HBase的组合。我曾经在千亿级图谱上用过JanusGraph，查询延迟控制在200ms以内——嗯，调优过程很痛苦，但结果值得。
查询这块，除了Cypher，还有SPARQL（用于RDF数据）和Gremlin（用于属性图）。我个人习惯用Cypher，因为它最接近自然语言，业务人员也能看懂。
好了，五个核心技术栈讲完了。你想想看，从知识表示到存储查询，每一步都有坑，但每一步也都有成熟的解决方案。做知识图谱，千万别想着一步到位——先跑通一个最小闭环，再逐步优化。我见过太多团队，一开始就追求完美，结果半年过去了连一个可用的图谱都没跑出来。
记住：知识图谱的本质，是让数据产生「连接的价值」。只要把五个环节串起来，你就能构建一个真正能用的金融知识图谱。