想象一下,你刚搬进一个小区,想打听“住在 2 栋的张三,他的父亲在哪家医院上班”。传统搜索会丢给你一堆网页,你得自己打开、比对、拼凑。但社区管家周姐手里有一本特殊的花名册,上面除了住址和电话,还画着一张人际关系网:张三的父亲是李四,李四在医院工作,医院是家三甲医院。周姐顺着这张网,几秒钟就能告诉你答案。 这种把“人、事、物”抽出来,再把它们之间的“关系”串成网的方式,就是知识图谱。它的三个基础零件是实体、关系、属性:实体是小区里的住户,关系是住户之间的往来,属性是住户身上的标签。大模型虽然能说会道,但经常不知道“自己不知道”;知识图谱像一张可以查证的城市社交地图,让大模型在开口回答前,先找到确定的人、确定的关系、确定的事实。
掌握知识图谱基础,是让大模型搜索从“猜字面”走向“查事实”的必修课,也是搜索、推荐与 RAG 工程师设计可解释系统的核心能力。
目录
可视化演示
展示知识图谱中实体、关系与属性的组织结构,以及知识图谱增强搜索的实体链接与子图推理过程。
本节配有交互动效(进入视口后自动加载,约 3KB)。
知识图谱三元组结构 实体为节点(人物/地点/概念),关系为有向边(出生地/职业/国籍) 属性描述实体特征(姓名/年龄/职业),存储为属性-值对 KG = {(h, r, t) | h,t ∈ Entities, r ∈ Relations}
知识图谱概念:社区管家周姐的花名册
社区管家周姐手里有一本特殊的花名册,不只是住址和电话,还画着一张人际关系网:张三和李四是父子,李四在医院工作,医院旁边是学校。周姐能秒答“张三的父亲在哪上班”,因为她不是翻一本平面通讯录,而是在一张网上找路径。这种把事实织成网的方式,就是知识图谱。
传统搜索引擎把网页拆成一个个词,像把整本书拆成散页;知识图谱则把散页里的人和事重新抽出来,并标出它们之间的关系。它不追求把所有句子背下来,而是追求“谁和谁有什么关系”的结构化表达。也正因为有了这张网,搜索才能从“找包含关键词的文本”升级为“顺着语义路径找到答案”。
在技术上,知识图谱用一个图模型描述世界,实体是节点,关系是边,属性是节点上挂着的描述信息。一条条知识被写成三元组,例如(张三,父子,李四)表示张三和李四之间是父子关系。用数学语言可以概括为:
没有这本册子,大模型只能凭语感“猜答案”;有了它,搜索就能像周姐一样顺着关系查到确定事实,而不是把一堆网页丢给用户自己拼。
- 实体集合 \(E\)式子里的 \(E\) 是所有实体组成的集合,相当于花名册里的住户,是图中的圆圈。
- 关系集合 \(R\)式子里的 \(R\) 是所有关系类型的集合,相当于住户之间的各种社会联系。
- 属性集合 \(A\)式子里的 \(A\) 是附着在实体上的属性描述,相当于住户身上的标签。
- 三元组 \((h, r, t)\)它是知识图谱的最小单位,相当于花名册里的一行备忘,把主语、谓语、宾语拼成一句话。
实体识别:图谱里能站稳的住户
周姐的花名册里,第一位要记清楚的是“人”。实体就是这样的存在:一个具体的人、组织、地点或物品,比如张三、医院、公司。实体是图谱的最小主角,没有实体的关系无处安放。如果花名册里只有“父子”这个词,却不知道是谁和谁,那这张网就织不起来。
在真实文本里,实体不会提前标好。“张三昨天去了医院”这句话,模型要先认出“张三”是人名、“医院”是机构名,这个动作叫命名实体识别。更麻烦的是,“张三”可能重名:小区里也许有两位张三。此时需要实体消歧和实体链接,把文本中出现的“张三”指称,匹配到知识图谱中确定的那一位。实体链接可以看作一个打分选择,模型从候选实体里挑一个最匹配的:
周姐看到“张三”这个名字,会先看看上下文里的住址、职业,再决定是 2 栋的张三还是 3 栋的张三。实体链接就是让模型也有这种“对号入座”的能力。
- 候选集合 \(C(c)\)根据文本中的指称和上下文,先圈出几个可能对应的实体。
- 相似度 \(\operatorname{sim}(e,c)\)衡量候选实体与当前上下文在语义上有多吻合,比如名字、描述是否对得上。
- 常见度 \(\log \operatorname{freq}(e)\)实体在历史语料中出现频率的对数,相当于优先考虑“更常见的那个张三”。
- \(\arg\max\) 选择在所有候选中挑总分最高的实体作为最终答案。
关系抽取:住户之间的丝线
花名册如果只有住户,那就只是通讯录;只有把父子、同事、邻居这些关系画出来,才叫图谱。关系是连接两个实体的语义线索。没有关系,实体就是一座座孤岛;有了关系,这些孤岛才能连成群岛。
关系抽取的任务,就是从非结构化文本中识别两个实体之间具有什么关系。比如“李四任职于医院”,我们希望在“李四”和“医院”之间填上“任职”这个关系。关系类型可以预先定义,比如父子、同事、工作、位于;也可以保持开放,让模型从文本中自由发现新关系。无论哪种方式,模型最终输出的都是关系类别上的一个概率分布:
关系抽取就是周姐在住户之间“牵红线”,并给每根红线贴上标签。贴得对不对,还要人工或规则验证,避免把“同事”误标成“朋友”。
- 头实体 \(e_h\) 与尾实体 \(e_t\)它们是一段关系的两端,分别相当于关系句里的主语和宾语。
- 关系集合 \(\mathcal{R}\)预先定义好的关系候选类型,相当于周姐手里的一叠关系标签。
- 条件概率 \(P(r \mid e_h, e_t, c)\)在给定实体和上下文时,关系 \(r\) 出现的概率。
- \(\arg\max\) 决策从所有关系标签里挑概率最高的那个,作为最终抽取结果。
属性抽取:住户身上的标签
周姐除了知道谁和谁相识,还知道张三今年 40 岁、职业是教师。这些跟单个实体绑定的描述,就是属性。属性让实体变得丰满:实体回答“是什么”,关系回答“和谁有关”,属性回答“具体怎么样”。
属性抽取从文本中提取实体的属性值。一个医院可以有“床位数量”“等级”“地址”等属性;一个员工可以有“职位”“工龄”“部门”等属性。同一个属性常常有多样写法,比如“医生”“大夫”“主治医师”可能描述同一个人,所以需要属性归一化,把这些写法统一成标准标签。多个来源都给出属性值时,我们可以融合它们的置信度:
属性归一化相当于把“医生”“大夫”“主治医师”统一成“职业:医生”,这样周姐才不会看花眼,图谱上的标签也才整齐可查。
- 信源数量 \(n\)一共有多少个独立来源提供了同一属性的取值。
- 单个信源置信度 \(p_i\)第 \(i\) 个来源对该属性值的相信程度。
- 漏判概率 \(1-p_i\)每个来源看走眼的概率。
- 综合置信度 \(P_{\text{fusion}}\)把所有来源都看走眼的概率相乘,再用 1 减去,得到“至少一个来源说对”的概率。
图谱构建:物业如何编好这本册子
知识图谱不会从天上掉下来。周姐要收集各家报备的信息、物业记录和公开公告,再逐条核对,才能编好这本花名册。知识图谱构建也是一条流水线:确定数据源、设计本体、抽取知识、评估质量、持续更新。
数据源可以是结构化数据库、半结构化网页,也可以是大量非结构化文本。本体相当于花名册的栏目设计:哪些信息该收、实体分成几类、关系怎么命名。抽取完成后,还要做质量评估,否则错误的三元组会让后续搜索“一本正经地胡说八道”。质量评估最朴素的方式是抽样检查正确率:
周姐不能只靠一次上门就永远不问世,小区住户会搬走、工作会变动,图谱也需要定期更新维护,这本册子才能一直“新鲜”。
- 样本集合 \(T\)从图谱中随机抽出的三元组样本。
- 示性函数 \(\mathbb{I}[\text{correct}(t)]\)当三元组 \(t\) 正确时取 1,否则取 0。
- 正确三元组总数对样本中所有正确判断求和。
- 正确率 \(Q(G)\)正确三元组数量除以总样本数量。
增强搜索:管家周姐顺着关系找人
用户问“张三父亲的工作单位是什么”,传统检索会先切词,找同时出现“张三”“父亲”“工作单位”的网页;周姐的花名册则直接给出路径:张三 → 父子 → 李四 → 工作 → 医院。这一过程就是知识图谱增强搜索。
增强搜索的第一步是查询理解,把自然语言问题映射到图中实体和关系;第二步是语义检索,在图谱中沿关系路径寻找候选答案;第三步是生成组织,由大模型把结构化答案组织成自然语言;第四步是可解释性,因为答案来自具体实体和关系,所以每一步都能溯源。对于两步关系的问题,可以用集合描述:
答案不是从网页里碰运气,而是沿着花名册的关系网络一步步走出来的。用户问“为什么是这家医院”,周姐可以理直气壮地说:因为它是李四的工作单位。
- 起点实体 \(e_1\)从用户问题中识别出的起始实体,比如“张三”。
- 中间实体 \(e\)连接两段关系的桥梁实体,比如“李四”。
- 关系 \(r_1, r_2\)依次经过的两条关系边,比如“父子”和“工作”。
- 答案集合 \(A\)所有能通过这两段关系到达的目标实体。
工程实践:把册子放进办事大厅
光有花名册不够,周姐还需要一个方便快速翻阅的档案柜。工程上,知识图谱通常放在图数据库里,用专用查询语言检索,再通过缓存和评估指标保证线上体验。没有这套基础设施,再完整的图谱也没法服务真实搜索。
图数据库把节点和边当成一等公民,避免传统数据库里反复多表连接才能完成的“朋友的朋友”查询。查询语言方面,Neo4j 用 Cypher,知识图谱社区常用 SPARQL。线上系统还会加缓存,把高频路径提前算好。效果评估则用一套可量化的指标,其中 Hit@k 非常直观:
办事大厅窗口再多,也要有排队号和信息屏。图谱工程就是让周姐在大量查询面前,依然能快速翻到花名册里正确的那一页。
- 测试问题集合 \(Q\)一批标注好答案的搜索问题,相当于考试卷。
- 问题数量 \(|Q|\)测试问题的总数。
- 命中指标 \(\mathbb{I}[\cdot]\)某条问题的正确答案是否进入前 \(k\) 个结果,进入取 1,否则取 0。
- Hit@k所有问题中命中的比例,衡量搜索系统“把正确答案排在前面”的能力。
AI 应用场景
智能客服知识问答
阶段:查询理解与知识检索
解决的问题:传统客服依赖关键词匹配,用户问“你们公司保修政策里的时间限制”时,系统很难把“保修时间”映射到具体产品实体和属性。知识图谱把“商品、保修期、售后服务”组织成实体关系网,客服机器人先定位商品实体,再沿“保修期”属性直接取答案,大幅减少答非所问。
具体案例:某手机厂商把手机型号、发布时间、保修政策录入知识图谱。用户问“iPhone 14 的保修期多久”,系统先识别实体“iPhone 14”,再读取属性“保修期=一年”,最后用大模型组织成一句话回复,并附上来源链接。
RAG 知识库增强搜索
阶段:检索增强生成与证据组织
解决的问题:大模型回答企业内部问题时常常“一本正经地胡说八道”,原因是纯参数记忆无法实时更新。知识图谱充当外部事实库,让检索模块先捞出与问题相关的实体与关系子图,再交给大模型生成答案。这既缓解幻觉,又让回答可以溯源。
具体案例:某咨询公司把项目、客户、负责人和交付时间做成知识图谱。用户问“去年智能制造项目的负责人是谁”,系统沿“项目→负责人”关系找到答案,再引用图谱中的实体卡片作为依据,生成一段带证据的回复。
电商商品图谱推荐搜索
阶段:召回排序与多跳理解
解决的问题:用户搜索“适合跑步的轻便运动鞋”,传统关键词召回容易漏掉“鞋类→适用场景→跑步”这种间接关系。知识图谱把商品、品牌、适用场景、材质连接起来,搜索系统可以沿“运动鞋→适合场景→跑步”做多跳召回,再结合大模型做语义排序。
具体案例:电商平台把商品和属性、场景关系录入图谱。用户搜索“户外露营用保温杯”,系统先匹配“保温杯”实体,再通过“适用场景=露营”属性筛选,最后把品牌和价格信息组织成搜索摘要。
Python 演示
# -*- coding: utf-8 -*-"""迷你知识图谱演示: 实体、关系、属性与两跳搜索""" class MiniKG: def __init__(self): self.nodes = set() self.edges = [] self.attrs = {} def add_node(self, name): self.nodes.add(name) def add_edge(self, head, relation, tail): self.edges.append((head, relation, tail)) def add_attr(self, entity, key, value): self.attrs[(entity, key)] = value def neighbors_by_rel(self, entity, relations): result = [] for head, rel, tail in self.edges: if head == entity and rel in relations: result.append((rel, tail)) if tail == entity and rel in relations: result.append(("逆_" + rel, head)) return result def two_hop_query(self, start, relations): frontier = [(start, [])] answers = [] for depth in range(2): nxt = [] for node, path in frontier: for rel, next_node in self.neighbors_by_rel(node, relations): new_path = path + [(rel, next_node)] if depth == 1: answers.append(new_path) else: nxt.append((next_node, new_path)) frontier = nxt return answers def find_entity(self, text): for name in sorted(self.nodes, key=len, reverse=True): if name in text: return name return None def get_attr(self, entity, key): return self.attrs.get((entity, key)) def main(): kg = MiniKG() kg.add_node("张三") kg.add_node("李四") kg.add_node("医院") kg.add_edge("张三", "父子", "李四") kg.add_edge("李四", "工作", "医院") kg.add_attr("李四", "职业", "医生") kg.add_attr("医院", "类型", "三甲") query = "张三父亲的工作单位是什么" start = kg.find_entity(query) if start is None: print("未识别到实体") return print("命中起始实体:", start) paths = kg.two_hop_query(start, {"父子", "工作"}) for path in paths: print("路径:", " -> ".join([start] + [t for _, t in path])) tail = path[-1][1] attr = kg.get_attr(tail, "类型") if attr: print("答案实体属性:", tail, "=", attr) if __name__ == "__main__": main()
self.edges.append((head, relation, tail))用三元组存储一条知识。self.attrs[(entity, key)] = value用字典存储实体的属性。def neighbors_by_rel(self, entity, relations)找出与当前实体有指定关系的邻居。if head == entity and rel in relations处理从关系头出发的正向方向。if tail == entity and rel in relations处理从关系尾出发的反向方向。frontier = [(start, [])]初始化广度优先搜索的队列。for depth in range(2)控制最多走两跳关系。paths = kg.two_hop_query(start, {"父子", "工作"})执行真正的两跳查询。"逆_" + rel给反向关系加前缀,方便理解查询方向。
常见误区
误区知识图谱和普通业务表很像,都是把信息按行存起来,查询时筛选一下就行。
正解普通表按行存储,关系要靠多次连接才能算出来;知识图谱把节点和边作为一等公民,专门为“谁和谁有什么关系”设计。用小区类比,Excel 是一张住户名单,知识图谱是周姐脑子里的关系网,后者能直接回答“张三父亲的同事的邻居是谁”。
为何常见:因为很多新手接触的数据都是表格,容易把图谱想象成多张表的组合,忽略了图结构带来的多跳查询优势。
误区反正都是图谱里的词,随便放在哪个位置都能表达知识。
正解实体是图中的节点,关系是连接两个节点的边,属性是贴在单个节点上的描述。把“医生”当实体还是当属性,会直接影响查询方式。小区里“张三”是实体,“父子”是关系,“职业:医生”是属性,三者分工完全不同。
为何常见:因为自然语言里“名词”都能当主语,初学者容易忽略它们在图模型中的结构性差异。
误区只要从文本里抽出一堆“A,关系,B”,知识图谱就算建好了。
正解抽取后还要做实体消歧、属性归一化、关系验证和质量评估。两个同名实体可能被错误合并,把“同事”标成“朋友”也会污染下游搜索。周姐不能把有人报错的门牌号直接记进花名册。
为何常见:因为三元组看起来很像自然语言句子,让人觉得可读即正确,忽略了知识图谱对唯一性和一致性的要求。
误区大模型什么都知道,直接把问题丢给 GPT 就行,何必再建图谱。
正解大模型的知识是训练时固化下来的,更新慢、易编造;知识图谱可以实时更新,并提供可溯源的实体和关系证据。周姐的经验再丰富,也取代不了实时更新的住户登记系统。两者是互补关系:大模型负责表达,图谱负责事实。
为何常见:因为大模型在开放问答上表现惊艳,很多人误以为它已经完美解决了知识获取和事实一致性问题。
误区知识图谱要一个一个人名、关系手工录入,成本太高,无法规模化。
正解现代知识图谱大量使用自动抽取算法,从文本、表格和网页中抽取三元组,再辅以人工审核和规则校验。周姐不用挨家挨户敲门,可以先让住户填表、再抽查电话核实,自动化与人工审核结合才能建成大规模图谱。
为何常见:因为初学者看到的是小规模手工案例,不了解工业界常见的“自动抽取+人机协同”流水线。
面试题
Q1. 知识图谱中的“节点”主要指什么?
- A.数据表结构
- B.实体对象← 正确答案
- C.关系字段
- D.属性集合
答案:B。知识图谱的核心结构是图,节点对应实体对象,比如“张三”“医院”;关系是边,属性则挂在节点上。数据表结构和关系字段都是传统关系型数据库里的概念,不是图的节点。
Q2. 三元组(张三,父子,李四)里的“父子”是?
- A.图谱实体
- B.关系标签← 正确答案
- C.属性名称
- D.限定条件
答案:B。三元组是“头实体、关系、尾实体”的结构,“父子”连接张三和李四两个实体,所以是关系标签。实体是节点,属性是节点上的描述,限定条件不是三元组的标准成分。
Q3. 实体链接的核心目标是?
- A.切分出文本中的词语
- B.将文本指称对应到实体← 正确答案
- C.计算两个词的编辑距离
- D.为图谱增加初始节点
答案:B。实体链接要解决“文本里说的张三到底是图谱里哪一位”的问题,把指称关联到确定的实体。切分词语是分词,编辑距离是字符串相似度,增加初始节点是构建阶段的事。
Q4. 关系抽取模型主要输出?
- A.实体在句中的边界
- B.两个实体间的关系类别← 正确答案
- C.属性值是否缺失
- D.图谱中的节点数量
答案:B。关系抽取输入句子和两个实体,输出这两个实体之间最可能的关系类别,比如“父子”“工作”“位于”。实体边界是命名实体识别的任务,属性缺失是属性抽取关注的问题。
Q5. 属性归一化的作用是?
- A.减少图谱节点数量
- B.统一属性值的多种写法← 正确答案
- C.删除所有低频实体
- D.把关系全部转成属性
答案:B。同一实体属性可能有不同写法,比如“医生”“大夫”“主治医师”应统一成“医生”。归一化是为了保证属性值一致,而不是减少节点、删实体或把关系改属性。
Q6. 知识图谱的三要素是?
- A.实体← 正确答案
- B.关系← 正确答案
- C.属性← 正确答案
- D.索引
答案:ABC。实体是节点,关系是边,属性是节点上的描述信息,三者构成知识图谱的基础。索引是提升查询性能的工程手段,不是图谱的三要素。
Q7. 关系抽取可以基于哪些方法?
- A.规则模板← 正确答案
- B.统计学习← 正确答案
- C.深度学习← 正确答案
- D.数据库索引
答案:ABC。关系抽取早期用规则模板,后来使用统计学习和深度学习模型从大量文本中自动学习关系分类器。数据库索引只影响查询速度,不参与关系抽取。
Q8. 知识图谱增强搜索的核心优势是?
- A.支持沿关系的多跳查询← 正确答案
- B.可以替代全文检索引擎
- C.不需要任何预训练模型
- D.自动生成搜索训练代码
答案:A。知识图谱把实体和关系变成图结构,可以查询“张三父亲的工作单位”这类需要跨多段关系的问题。它不是全文检索引擎的替代品,也仍然需要预训练模型理解语言,更不能自动生成训练代码。
Q9. 实体消歧主要解决?
- A.同名指称对应到正确实体← 正确答案
- B.让所有实体拥有唯一名字
- C.合并所有相似属性值
- D.提升图谱查询速度
答案:A。实体消歧针对的是“一个名字可能有多个实体”的问题,比如两位“张三”,需要根据上下文判断当前指哪一位。改名、合并属性和提速都不是消歧的目标。
Q10. 在大模型+知识图谱的问答中,知识图谱主要弥补大模型的?
- A.训练算力不足
- B.事实更新滞后← 正确答案
- C.长文本推理能力
- D.答案溯源能力← 正确答案
答案:BD。知识图谱可以实时更新,提供新鲜事实;同时图上的实体和关系路径能让答案附带来源,增强溯源能力。训练算力和长文本推理主要是模型架构和算力层面的问题,不是图谱的补位方向。