知识图谱基础：从实体关系到智能投研的基石

大家好，我是你们这趟知识图谱之旅的向导。今天咱们聊点实在的——知识图谱到底是个啥？

说实话，我最早接触知识图谱是在2016年，当时给一家券商做智能投研系统。客户说「我们要把研报里的信息结构化」，我心想这不就是建个数据库嘛。结果一做才发现，事情远没那么简单。

知识图谱，说白了就是一种用图结构来组织知识的方式。它不像传统数据库那样存成一张张表格，而是把信息存成「节点」和「边」。节点代表实体，边代表关系。你想想看，这多符合人类的思维方式——我们脑子里记东西，不也是「张三认识李四」、「北京是中国的首都」这种形式吗？

实体、关系、属性：知识图谱的三要素

先说说最基础的概念。知识图谱由三个核心元素构成：

• 实体（Entity）：现实世界中的对象，比如「贵州茅台」、「2023年财报」、「张坤」
• 关系（Relation）：实体之间的连接，比如「发布了」、「持有」、「属于」
• 属性（Property）：描述实体的特征，比如「市值=2.1万亿」、「净利润=747亿」

举个例子你就明白了。在智能投研场景里：

实体：贵州茅台（股票代码：600519）
属性：市值=2.1万亿，行业=白酒，上市日期=2001-08-27
关系：发布了 → 2023年财报
实体：2023年财报
属性：营收=1505亿，净利润=747亿，ROE=30.3%
关系：持有 → 张坤（基金经理）
实体：张坤
属性：管理基金=易方达蓝筹精选，从业年限=10年

我在项目中遇到过最典型的坑是什么？很多人把「属性」和「关系」搞混。比如「市值」是属性还是关系？答案是：如果它描述的是实体本身的固有特征，就是属性；如果它连接了两个不同实体，就是关系。「市值」是茅台的属性，但「市值排名第一」就是关系——因为它连接了茅台和其他股票。

Schema层与数据层：知识图谱的骨架和血肉

知识图谱的架构分为两层，我习惯叫它「骨架」和「血肉」。

Schema层（骨架）：定义知识图谱的「元数据」。它规定了有哪些实体类型、哪些关系类型、哪些属性类型。比如在投研场景中，Schema层会定义：

• 实体类型：公司、财报、基金经理、行业、新闻
• 关系类型：发布了、持有、属于、报道了
• 属性类型：市值、营收、净利润、从业年限

数据层（血肉）：具体的实例数据。比如「贵州茅台」是「公司」类型的一个实例，「2023年财报」是「财报」类型的一个实例。

为什么要分层？我刚开始做的时候也觉得麻烦，直到有一次项目需要扩展——原来只分析股票，后来要加入债券。如果没有Schema层，你得改所有代码。有了Schema层，只需要在Schema里加一个「债券」实体类型，数据层自动适配。这就是架构设计的力量。

下面这张图展示了知识图谱的典型架构：

主流知识图谱数据库对比：Neo4j vs JanusGraph

选数据库是个头疼事。我这些年用过Neo4j、JanusGraph、ArangoDB、TigerGraph，踩过不少坑。今天重点说说最常用的两个：Neo4j和JanusGraph。

对比维度	Neo4j	JanusGraph
底层存储	自研原生图存储	基于HBase/Cassandra/BerkeleyDB
查询语言	Cypher（声明式，类似SQL）	Gremlin（遍历式，类似函数式编程）
事务支持	ACID，强一致性	最终一致性（基于底层存储）
扩展性	单机为主，集群有限	水平扩展，支持分布式
部署复杂度	简单，开箱即用	复杂，需要Hadoop生态
社区生态	成熟，文档丰富	中等，Apache基金会
适用场景	中小规模、快速原型	大规模、分布式环境

来看看两种查询语言的差异。假设我们要查「贵州茅台发布了哪些财报」：

Neo4j（Cypher）：

MATCH (c:Company {name: '贵州茅台'})-[:PUBLISHED]->(r:Report)
RETURN r.name, r.year

JanusGraph（Gremlin）：

g.V().has('Company', 'name', '贵州茅台')
 .out('PUBLISHED')
 .valueMap('name', 'year')

你发现没有？Cypher更像SQL，直观好理解。Gremlin更像函数式编程，灵活但学习曲线陡。我个人习惯是：团队里数据分析师多，用Neo4j；团队里后端工程师多，用JanusGraph。

最后说一句，选数据库没有银弹。我在不同项目里用过不同的方案，关键看你的数据规模、团队技术栈、以及查询模式。嗯，这个我们后面章节还会深入聊。

好了，知识图谱的基础就讲到这里。记住三个核心概念：实体、关系、属性；理解Schema层和数据层的区别；知道Neo4j和JanusGraph的适用场景。这些就是你踏入知识图谱世界的第一步。