知识图谱核心 20% — 先把本体设计对

一句话:知识图谱项目失败,90% 不是技术问题,而是实体与关系的粒度没定义清楚。先写 20–50 个核心实体类型和它们之间的关系,再谈抽取和存储。


🎯 这 20% 能解决哪些问题

常见困惑本质本页答案
知识图谱和普通数据库有什么区别以关系为一等公民见「三元组与本体」
实体太多太细,抽不完本体没做收敛见「本体设计四步」
同名实体合并错乱缺少实体对齐见「抽取流水线」
该用 Neo4j 还是关系库查询模式差异见「存储与查询选型」
知识图谱对 RAG 有用吗用途被高估或错配见「在 RAG 中的真实作用」

一、三元组与本体

graph LR
    A["(头实体, 关系, 尾实体)"] --> B["本体 / Schema<br/>类型 + 关系定义"]
    B --> C["实例数据<br/>三元组集合"]
    C --> D["推理<br/>补出新三元组"]
概念说明例子
实体(节点)现实对象张三、某公司
关系(边)有方向的连接就职于、隶属于
属性(字面值)挂在实体上的键值成立于 2010 年
本体类型与关系的约束人—就职于—公司

与关系库的核心差异:关系库用连接跨表,图谱把关系本身存成数据,因此可以表达”关系的属性”(如”就职于”带起止时间),也能承受多跳查询。


二、本体设计四步

步动作产出
1列出业务问题(要回答什么)5–10 个关键问句
2从问句反推实体与关系实体表 + 关系表
3定义约束(基数、必填、类型)校验规则
4定义粒度与命名规范命名词典、同义词表

粒度示例:“公司”要不要区分”母公司/子公司”?“人物”要不要区分”员工/客户”?没有对错,只有是否与你的问句匹配。


三、抽取流水线

环节方法关键点
实体识别NER 模型 / 词典 / LLM领域词典能显著提升
关系抽取监督分类 / 远程监督 / LLM远程监督噪声大,需清洗
属性抽取规则 + 抽取模型数值、日期优先用正则
实体对齐相似度 + 规则 + 人工同名不同实体是最痛的坑
质量校验抽样人工 + 约束检查基数与类型约束能挡一半错误

LLM 抽取的实务要点:给出 Schema、要求输出 JSON、给 2–3 个示例、对结果做约束校验并重试。不要直接信任 LLM 的关系方向,它常搞反 A 收购 B。


四、存储与查询选型

方案适合代价
图数据库(Neo4j 等)多跳查询、路径分析运维与成本
RDF 三元组库标准化、可推理、跨组织交换工具链较重
关系库(两列 + 索引)规模中等、已知查询模式多跳查询写起来复杂
搜索/向量库 + 图结构混合检索需自己拼装

查询语言:属性图用 Cypher,RDF 用 SPARQL。选型的实用判据:如果 90% 的查询是”给定实体找 N 跳邻居”,图数据库才值得;如果只是”查某个人的部门”,关系库足够。


五、在 RAG 中的真实作用

用途有效性
实体归一(同一事物的不同叫法)高
多跳问答(A 的子公司 CEO 是谁)高(这是向量检索的弱项)
结构化约束过滤(时间、类别)高
替代全文检索低(覆盖率永远不够)
自动构建无需人工低(噪声会污染回答)

务实架构:向量检索负责”找到相关段落”,图谱负责”补全实体之间的关系”,两者结果合并后交给生成模型。图谱是增强件,不是替代件。


六、六个高频坑

坑表现纠正
本体过度设计几个月画不出第一版从 20 个类型起步,迭代扩展
实体不对齐同一公司三个节点别名表 + 相似度 + 人工确认
关系方向错上下游颠倒约束校验 + 抽样复核
无时间维度事实更新后新旧共存边加时间戳,查询带时间过滤
只增不删图谱越来越脏建立失效与合并机制
忽视溯源无法判断可信度每条边记录来源文档与置信度

📋 一页速查

问题答案
先设计什么本体(类型与关系)
本体怎么收敛从业务问句反推
最痛的工程问题实体对齐
图数据库何时值得多跳查询为主时
图谱能替代向量检索吗不能,是增强
每条边该带什么时间戳、来源、置信度

🔗 相关链接

主题链接
智能系统概览智能系统
推荐系统推荐系统核心 20%
自然语言处理自然语言处理
文本处理文本处理核心 20%
RAG 实践RAG 检索增强生成