L3 · 专题文章

知识图谱

知识增强结构化数据RAG推理

本页只讲 4 条最关键判断：本体设计决定上限、图查询替代向量检索、多跳推理需路径验证、维护成本高于静态向量库。

4核心点
先记住图谱不是更好的向量库，而是可验证的推理引擎

向量检索找相似，图谱找关系路径；混淆两者会导致架构臃肿且无法解决幻觉。

先看重点 ↓ 下一步
LIVE
CORE 知识图谱
01 WHAT

是什么

知识图谱是以实体为节点、关系为边的结构化网络，用于显式表达业务事实与逻辑约束。

02 WHY

为什么

大模型缺乏精确事实记忆与可验证推理路径，图谱为 AI 提供可查询、可追溯的确定性知识底座。

03 HOW

怎么做

通过定义本体（Ontology）抽取实体与关系，存入图数据库，再以 Cypher/SPARQL 或图检索接口供下游调用。

04 WHEN

什么时候

适用于强一致性、多跳推理、合规审计场景；纯文本问答或低复杂度检索无需引入。

FOCUS

先记住这些

只留最重要的判断，细节见下方实践
01 本体设计

Schema 决定图谱上限

过度抽象导致查询困难，过度具体丧失复用性；需平衡业务覆盖与查询效率。

02 图查询

关系路径优于向量相似

图谱通过显式边表达逻辑关系，支持精确匹配与约束过滤，避免向量检索的语义漂移。

03 多跳推理

路径组合实现复杂推导

通过 2-3 跳关系链组合可解决多数业务推理，超过 4 跳需评估性能与准确率衰减。

04 维护成本

持续对齐与更新是常态

实体合并、关系修正与增量更新需建立自动化流水线，否则图谱会迅速退化。

PROBLEM / POSITION / INTERFACE

先弄清它为什么存在，以及谁在使用

不从历史开始，从真实工作关系开始。
  1. 01 解决的问题

    当业务需要基于精确事实进行多跳推理、关系查询或合规审计时。

    纯文本检索易产生幻觉，无法保证关系准确性与逻辑可追溯性。

    成功标准
    AI 能基于图谱返回带路径验证的精确答案，且结果可被人工审计。
  2. 02 AI 生态位

    作为大模型的外部确定性知识源，提供可查询的结构化上下文。

    上游
    依赖业务数据库、文档解析、实体抽取模型与关系抽取算法。
    下游
    为 RAG 系统、智能问答、推荐引擎与决策支持提供结构化输入。
  3. 03 人的生态位

    负责定义本体、校验数据质量、验收推理路径的合理性。

    适合使用
    业务涉及复杂实体关系、需多跳推理或强一致性验证时。
    不必使用
    仅需简单关键词匹配、数据量小或关系高度动态变化时。
  4. 04 独特价值

    提供显式关系路径与逻辑约束，支持多跳推理与结果可验证性。

    本体设计易过度抽象，实体对齐与关系抽取质量直接影响可用性。

    复杂度判断
    复杂度不是功能数量，而是控制与验证成本。

INTERFACE FLOW

谁在操作，信息怎样流动

  1. WHO OPERATES

    HUMAN定义本体 Schema、审核抽取质量、验收推理路径

    SYSTEM执行实体对齐、关系存储、图查询与结果格式化

  2. INPUT

    业务实体数据、关系三元组或待查询的自然语言问题。

  3. CONTROL

    本体定义、查询语言（Cypher/SPARQL）、检索阈值、上下文窗口限制。

  4. OUTPUT

    结构化子图、带路径的推理结果或供大模型消费的 JSON 上下文。

FLOW

最小可用流程

01定义本体根据业务场景确定实体类型、属性与关系约束，避免过度设计
02抽取与入库从结构化数据或文本中抽取实体与关系，对齐后存入图数据库
03构建查询编写 Cypher/SPARQL 语句实现多跳检索与路径验证
04对接应用将查询结果格式化为 JSON 上下文，注入大模型 Prompt
CODE / PYTHON最小 Python 调用
import os
from neo4j import GraphDatabase

uri = os.environ["NEO4J_URI"]
auth = (os.environ["NEO4J_USER"], os.environ["NEO4J_PASSWORD"])

def query_kg(cypher: str):
    with GraphDatabase.driver(uri, auth=auth) as driver:
        with driver.session() as session:
            result = session.run(cypher)
            return [record.data() for record in result]

cypher = """
MATCH (p:Person)-[:WORKS_AT]->(c:Company)
WHERE c.name = 'TechCorp'
RETURN p.name, p.role
"""
print(query_kg(cypher))

最短闭环：连接图数据库 → 执行 Cypher 查询 → 返回结构化结果。

JSON / RESPONSE典型返回（示意）
[
  {
    "p.name": "张三",
    "p.role": "算法工程师"
  },
  {
    "p.name": "李四",
    "p.role": "产品经理"
  }
]

PRACTICE

上线前检查

✓本体是否覆盖核心业务实体与关系，无冗余类型
✓实体对齐规则是否明确，重复节点是否已合并
✓查询语句是否限制跳数（≤3 跳）与返回规模
✓是否建立增量更新与质量监控机制

FAQ

常见问题

选型、用法与失败，不复述定义。
01知识图谱和向量检索有什么区别？＋

向量检索基于语义相似度找相关文本，图谱基于显式关系路径找精确事实；前者适合模糊匹配，后者适合逻辑推理。

混淆两者会导致架构臃肿且无法解决幻觉问题。
02最小可用方式是什么？＋

定义 3-5 个核心实体类型与关系，用 Cypher 实现单跳/双跳查询，将结果注入大模型 Prompt。

避免过度设计，快速验证业务价值。
03什么时候不需要知识图谱？＋

数据量小、关系简单或高度动态变化时，使用关系型数据库或向量检索更经济。

控制系统复杂度与维护成本。
04多跳推理的准确率如何保证？＋

限制跳数（≤3）、设置路径权重阈值、结合业务规则过滤无效路径。

防止推理链过长导致结果发散或性能下降。

NEXT

下一步

长期记忆 →