人人都会AI编程

18.2 知识图谱构建：实体抽取、关系抽取、图谱存储

更新时间：2026-07-12

18.2 知识图谱构建：实体抽取、关系抽取、图谱存储

在 RAG 系统中引入知识图谱，本质上是为了弥补向量检索在“精确关联”和“多跳推理”上的不足。向量检索擅长语义相似度匹配，但面对“张三是李四的上级，李四属于哪个部门？”这类需要沿着关系推理的问题时，图谱能够天然支持。构建知识图谱一般分为三个核心环节：实体抽取、关系抽取、图谱存储。

18.2.1 实体抽取

实体抽取的目标是从非结构化文本中识别出有特定意义的名词或短语，例如人名、机构名、产品型号、专业术语、时间、金额等。这是图谱构建的第一步，也是数据源头。

常用方法

  • 规则匹配：适用于格式固定的实体，如产品编号（PROD-\d{6}）、日期、订单号等。优点是准确、快速，不需要训练数据；缺点是无法覆盖多样化的自然表述。
  • 字典匹配：预先维护一个术语表（如公司部门名称、技术术语、药品名），用字符串匹配或模糊匹配在文本中查找。常见的优化是使用 AC 自动机处理大量字典项，能在一次扫描中完成匹配。
  • 预训练 NER 模型：使用通用领域或领域微调的命名实体识别模型，可直接识别人物、地点、组织等通用实体。主流工具包括 spaCy、Hugging Face 上的 BERT-NER 模型、以及 GLiNER 等非结构化实体识别库。
  • 大模型抽取：利用 LLM 通过少量提示示例，直接让模型从文档中抽取出实体。做法简单灵活，适合前期快速验证，但需注意成本和时延。

实践要点

  • 实体类型不要贪多，初期聚焦几个核心类型即可，例如“人员”“部门”“项目”“文档编号”。
  • 对抽取出的实体要做规范化（或称实体对齐），例如将“研发部”“研发中心”“R&D”都归一到同一个实体 ID，避免图谱中出现大量冗余节点。
  • 可同时使用规则和模型，模型负责覆盖主要情况，规则用来修正模型漏掉的高频关键实体。

18.2.2 关系抽取

有了实体，还需要识别它们之间的关系，才能构成图谱的“边”。关系抽取就是从一个句子或段落中，判断两个或多个实体之间是否存在某种语义关联，并标注出关系类型。

常用方式

  • 预定义关系模板：根据业务需求预先定义关系类型（如“工作于”“属于部门”“产生于”“审批人”），然后用规则或模型从文本中抽取三元组 (主体, 关系, 客体)。适合关系类型明确且不多的场景。
  • 远程监督 + 文本分类：利用已有知识库（如已有的结构化表）中的关系对，回标到原始句子中产生训练数据，训练一个关系分类器。这种方法可以逐步扩充数据。
  • 联合抽取模型：使用如 CasRel、SPN 等实体关系联合抽取模型，一次性输出句子中的所有实体和关系。也可利用生成式模型，让 LLM 按指定 schema 直接输出 (头实体, 关系, 尾实体) 列表。
  • 依存句法分析辅助：通过句法分析找到主谓宾等结构，结合规则提取“动词”作为关系名。对于语法规范的文档（如法律、合同）有一定效果，但对口语化文本不够稳定。

实践要点

  • 关系方向要一致：比如始终用“部门→包含→员工”而不是混用“员工→属于→部门”，统一 schema 便于后续查询。
  • 抽取出的关系也需要清洗：过滤掉低置信度的关系，合并同义关系名。
  • 可以先从统计高频共现的实体对入手，用人工标注的方式快速积累首批标注数据，然后训练小模型或微调 LLM。

使用大模型抽取的建议

最近基于生成式大模型直接做实体关系抽取的方式变得非常流行。提示词示例如下：

请从以下文本中抽取实体和关系，关系类型限定为：
“员工-属于-部门”“员工-担任-职位”。

输出格式：[主体，关系，客体]

文本：王伟于2023年加入技术支持部，现任高级工程师。

这种方法省去了训练专用模型的繁琐，适合中小规模的数据处理。但对大批量文档，需注意调用成本和处理时间，可以先用规则抽取高频关系，大模型处理长尾和复杂句。

18.2.3 图谱存储

抽取得到的实体和关系三元组需要存储到图数据库中，以便高效地进行图查询和遍历。选择合适的存储方案直接影响图谱的查询性能和维护便利性。

主流的图存储方案

  • 专用图数据库：如 Neo4j、JanusGraph、ArangoDB、TigerGraph 等。它们使用节点和边的原生存储结构，对深度遍历、最短路径、子图匹配等查询性能优异。Neo4j 的 Cypher 查询语言直观易学，社区活跃，是中小规模图谱的常见选择。
  • 属性图 vs RDF：属性图（如 Neo4j）允许节点和边上存任意属性，灵活性强；RDF 三元组库（如 Apache Jena、GraphDB）遵循 W3C 标准，适合需要发布为开放关联数据的场景。RAG 辅助用途的多采用属性图，更贴近业务灵活建模。
  • 结合向量存储的混合方案：有些架构选择将实体和关系的描述嵌入也存入向量库，在图谱检索时，先通过向量相似度找到候选实体，再在图数据库中展开关系遍历。也可在传统图数据库上叠加全文索引或向量索引增强检索。

图谱存储设计要点

  • 节点和边的属性：为每个节点存储名称、别名列表、来源文档 ID、嵌入向量（可选）等，为每条边存储关系类型、来源、置信度、抽取时间等元信息。
  • 索引优化：对高频查询的属性（如实体名称、类型）建立索引，避免全图扫描。
  • 版本管理：大规模知识图谱也需要像文档一样不断迭代。设计时可考虑给每个三元组加上时间戳或版本号，支持增量更新而非每次重建全图。
  • 轻量化起步：如果图谱规模不大（百万以内节点），单机 Neo4j 或 PostgreSQL+Apache AGE 等方案就足以胜任，无需过早引入分布式架构。

图谱与 RAG 的结合模式

知识图谱建成后，并不替代原有的向量检索，而是作为补充检索源。常见模式是：

  • Graph RAG：在收到问题时，先从图谱中提取相关子图（例如通过实体链接确定查询图中的实体，再取多跳邻居），将子图信息转成自然语言描述，与向量检索到的文档片段一起填入提示词。
  • QA‑over‑Graph：对于明确需要多跳推理的问题，可以先用 Cypher 或 SPARQL 查询得到精确答案，再将结果及其推理路径转述给用户。

通过实体抽取、关系抽取、图谱存储这三个阶段的有序推进，你可以从原始文档中逐步提炼出结构化的知识网络，为 RAG 系统拓展出更强大的结构化问答能力。每一步都建议小范围验证、逐步扩展，避免早期过度设计导致维护负担过重。