知识图谱全链路工程实践：从数据接入到知识应用

0 导读与核心结论

0.1 这份报告解决什么问题

知识图谱项目在技术上”建成”和在业务上”用起来”之间存在一条很宽的鸿沟。跨越这条鸿沟需要回答的不是”用什么本体语言”，而是五个工程问题：

1. 数据从哪来、怎么持续来、上游改字段了怎么办；
2. 三元组存在哪、存多少、怎么备份、查询延迟是多少；
3. 推理规则怎么跑、规则改了能不能不停服、推理崩了怎么降级；
4. 业务系统怎么调、一次问答要几跳、P99 能不能压到 2 秒内；
5. 上线三个月后，怎么知道图谱质量在变好还是变坏。

这两份前置报告分别覆盖了”知识建模与约束”和”数据集成与调度”，但都停在图谱内部。本报告的定位是一份施工图：每一层给出候选产品、明确判据、配置片段与验收指标，使一个 5–8 人的团队能够在 6 个月内交出可运行的最小闭环，并在 18 个月内扩展为生产系统。

判断读者是否用得上这份报告的方法很简单：如果读完仍无法回答”下周该采购/部署哪三个组件、先写哪两个 DAG”，说明报告没写好。

0.2 核心判断

0.3 与两份前置报告的关系

1 全景架构：知识工程六层模型

1.1 为什么必须分层：三个典型失败

不分层的知识图谱项目通常以同样的方式失败。以下三个案例来自工业知识图谱项目的常见复盘，症状、根因与对策一一对应。

三个核心失败模式的共同根因是同一个认知错误：把知识图谱当作一个数据集交付，而不是当作一个系统运营。数据集可以一次交付，系统必须持续运行——而”持续运行”这件事，只能靠分层来承载。

1.2 六层 + 两横切架构

flowchart TB
    subgraph CROSS1["横切 A：治理与可观测（第9章）"]
        G1["质量四维看板 / 血缘溯源 / 版本管理 / 权限安全 / 成本核算"]
    end

    subgraph CROSS2["横切 B：调度编排（第8章）"]
        S1["同步作业 / 加工作业 / 推理作业 / 回归作业 / 发布作业"]
    end

    L1["L1 数据接入层<br/>SeaTunnel 3.0(Zeta) · CDC · 文档解析链<br/>质量门禁"]
    L2["L2 知识加工层<br/>抽取 · 实体链接 · 融合消歧 · 约束校验<br/>LLM 候选 + 规则判定"]
    L3["L3 知识存储层<br/>RDF 主存(GraphDB/RDFox) · LPG 投影(Neo4j)<br/>向量库 · 搜索引擎 · 对象存储"]
    L4["L4 推理与计算层<br/>ELK 分类 · Datalog 规则 · SHACL 校验<br/>图计算(可选)"]
    L5["L5 知识服务层<br/>查询网关 · SPARQL/GraphQL/REST · 混合检索<br/>KGQA · 缓存 · 鉴权限流"]
    L6["L6 知识应用层<br/>问答 · 诊断 · 推荐 · 决策支持 · 报表 · Agent"]

    SRC["数据源<br/>SCADA/DCS · CMMS · ERP · LIMS<br/>检修规程/国标 PDF · 专家经验"]
    SRC --> L1 --> L2 --> L3 --> L4 --> L5 --> L6

    CROSS1 -.-> L2
    CROSS1 -.-> L3
    CROSS1 -.-> L5
    CROSS2 -.-> L1
    CROSS2 -.-> L2
    CROSS2 -.-> L4
    CROSS2 -.-> L5

    L4 --> L3
    L3 --> L2

架构图的关键点不是六个框，而是三条回流箭头：

1. L4 → L3：推理结果必须写回存储（物化），否则每次查询都要重算；
2. L3 → L2：存储中的存量知识是加工的输入（实体链接要靠已有实体库做候选召回，冲突消解要靠存量做基准）；
3. L5 → L4 → L2 的反馈环：服务层的”查询失败/未命中/低置信”日志应回流为加工层的抽取目标与 CQ 扩展来源。这条反馈环是知识图谱从”静态资产”变成”持续进化系统”的唯一机制，也是绝大多数项目缺失的一环。

1.3 各层职责与组件映射

1.4 端到端数据流：一条设备故障知识的完整链路

以水泥厂”3# 回转窑主减速机高速轴轴承外圈剥落”这一条知识为例，走完全链路：

这条链路的工程量分布值得注意：真正花时间的不是第 ③ 步的 LLM 抽取（约占 15% 工作量），而是第 ②、④、⑤、⑨ 步（校验、链接、门禁、血缘，合计约 60%）。这也解释了为什么”用大模型一键建图谱”的 demo 能跑通，但生产系统建不起来。

1.5 分层的关键取舍

一条实操判断：L4 是唯一可以在首年”降级”的层，L3 是唯一”选错就要重做”的层，L5 是唯一”最容易被低估”的层。三者对应的风险分别是”多花钱”、”推倒重来”、”上线即崩”。

1.6 五条架构决策记录（ADR）

架构决策一旦定下，后续所有技术选择都会被它约束。把决策显式记录下来（含”什么情况下该推翻”），比事后争论”当初为什么这么选”成本低得多。

判断：这五条里最容易被推翻又最不该推翻的是 ADR-002。当 LLM 能力持续提升时，”让模型直接判定”的诱惑很大，但工业场景的审计要求不会因模型变强而放松。正确做法是把 LLM 判定包在”候选生成 + 规则/约束过滤 + 人工确认”三层里，而不是取消这三层。

2 L1 数据接入层

2.1 知识工程要接入的四类数据

知识图谱的”知识”来自四类差异极大的数据源，接入方式、频率、质量风险完全不同。把它们当成一类处理是接入层最常见的错误。

判断：四类数据中，结构化库决定图谱的”骨架正确性”（设备、部件、位置、工序的实体是否齐全），非结构化文档决定图谱的”知识密度”（故障机理、处置经验、标准限值），流式信号决定图谱的”时效价值”（当前状态）。骨架错则全盘错，密度低则无人用，时效差则只值一次交付。

2.2 SeaTunnel 在知识工程视角下的用法

前置报告 B 已给出 SeaTunnel 的完整部署与调优细节（Zeta 引擎、Checkpoint、并行度、连接器），此处只写知识工程特有的用法约束，部署细节引用原报告即可。

定位：SeaTunnel 在知识工程中承担”把异构源变成结构一致的规范化表”这一件事，输出的是加工层的输入表，不是图谱本身。不要试图在 SeaTunnel 里做实体抽取或图谱写入——那是 L2 的职责。

四条用法约束（判断）：

1. 只做”到表”的搬运，不做”到图”的建模。SeaTunnel 的输出 sink 统一落 Parquet/ORC 或 Kafka topic，由 L2 消费。理由是抽取逻辑（尤其是 LLM 调用）需要重试、限流、缓存与人工复核，这些能力在流处理引擎里实现代价极高。
2. CDC 只开需要的表，不做整库同步。知识工程需要的表通常只占业务库的 10%–20%（设备主数据、工单、故障代码、点检项）。整库 CDC 会让 Schema Evolution 的风险面扩大 5 倍以上。
3. 在 Source 侧完成”知识友好的字段补齐”。例如给每条工单补 source_system、extract_ts、record_version 三个字段，这三个字段是后续血缘与冲突消解的基础。用 SeaTunnel 的 Transform + Sql 插件即可完成，不需要额外的加工层。
4. 用 zstd 压缩 + 分区落盘。文档与日志类数据量大但冷，压缩比通常在 4–8 倍，直接影响 L3 对象存储成本。

最小可用的 CDC 同步配置（MySQL → Kafka，仅设备与工单两类表）：

env {
  parallelism = 4
  job.mode = "STREAMING"
  checkpoint.interval = 30000
}

source {
  MySQL-CDC {
    base-url = "jdbc:mysql://10.20.3.11:3306/cmms"
    username = "${CMMS_USER}"
    password = "${CMMS_PASS}"
    table-names = [
      "cmms.eq_equipment",
      "cmms.eq_component",
      "cmms.mt_workorder",
      "cmms.mt_fault_code"
    ]
    startup.mode = "initial"          # 首次全量，之后自动切增量
    server-id = 5410-5413
    exactly-once = true
  }
}

transform {
  Sql {
    query = """
      SELECT
        id                AS src_id,
        equip_code        AS equip_code,
        equip_name        AS equip_name,
        parent_code       AS parent_code,
        'CMMS'            AS source_system,
        NOW()             AS extract_ts,
        UNIX_TIMESTAMP()  AS record_version
      FROM cmms.eq_equipment
      WHERE deleted = 0
    """
  }
}

sink {
  Kafka {
    bootstrap.servers = "10.20.5.21:9092,10.20.5.22:9092"
    topic = "kg.ods.equipment"
    format = canal_json
    semantic = "EXACTLY_ONCE"
  }
}

2.3 CDC 增量同步设计与 Schema Evolution 冲击

全量 + 增量的切换是接入层第一个必须设计的动作。三种模式对比：

判断：知识工程一律采用”全量初始化 + 增量追平”，且全量快照必须落到不可变分区（如 snapshot_date=2026-10-31），而不是覆盖。原因在于图谱需要回溯”某条知识在某个时间点的状态”，覆盖式全量会摧毁这个能力。

Schema Evolution 对本体与约束的冲击，是接入层最容易被忽略、后果最严重的问题。上游加一个字段、改一个枚举值、放宽一个非空约束，都会在下游引发连锁反应：

这里有一条硬性工程规则（判断）：图谱中的实体 ID 必须由业务编码派生，绝不能使用源系统的自增主键。水泥厂的设备位号（如 K3-MR-001）比 id=10237 稳定得多。用自增主键做主键，任何一次库迁移都会让整张图谱的实体链接失效。

Schema Evolution 的三道防线：

1. 观察期：源端变更先只进 ODS，L2 在”影子模式”下加工但不入图，观察 7 天；
2. 契约测试：为每个源表维护一份 YAML 契约（字段名、类型、值域、基数），CI 中每日校验，不符则阻断；
3. 本体变更闸门：任何触及本体或 SHACL 的变更必须走 L4 的 CQ 回归（见 8.4），不允许”顺手加个属性”。

# contracts/cmms.eq_equipment.yaml —— 源表契约示例
table: cmms.eq_equipment
owner: 设备管理部
refresh: cdc
columns:
  equip_code:   {type: string,  pattern: "^[A-Z0-9]{1,4}-[A-Z]{2}-[0-9]{3}$", required: true, unique: true}
  equip_name:   {type: string,  max_len: 120, required: true}
  parent_code:  {type: string,  nullable: true}
  equip_class:  {type: enum,    values_from: kg:EquipmentClass, required: true}
  install_date: {type: date,    nullable: true}
  deleted:      {type: int,     values: [0,1], required: true}
evolution:
  forbid: [rename, drop]
  require_alias_months: 3

2.4 非结构化文档接入：解析 → 版面分析 → 分块 → 元数据标注

工业场景中 70% 以上的高价值知识（故障机理、检修工艺、标准限值、图纸参数）藏在 PDF 与扫描件里。这条链路的工程质量直接决定图谱的”知识密度”。

工具链现状（2025–2026）：

判断：自建 IDC 场景一律选 MinerU 为主解析器、Docling 为补充（处理 Office 与 HTML）、PaddleOCR 作为扫描件兜底。理由是三者均可在内网离线部署、均支持 GPU 批处理，且 MinerU 在中文版面与公式上明显优于通用方案。

解析链的四个工程要点：

1. 必须保留页码与坐标（bbox）。这是后续所有溯源能力的地基——没有 bbox，用户看到一条知识无法跳转到原文第 37 页第 2 段，信任就建立不起来。MinerU 与 Docling 均输出 middle.json 含 bbox，务必入库而非丢弃。
2. 版面元素要分类入图，不要全部当文本。表格、公式、图片、图题应分别处理：表格转结构化（或至少保留 HTML 供 LLM 阅读），公式保留 LaTeX，图题作为图片的 dc:description。
3. 分块策略由知识结构决定，不由 token 数决定。工业规程的自然单元是”条款”（如”5.3.2 减速机高速轴轴承温度不得超过 75 ℃”），按条款切分比按 512 token 切分的信息完整性高一个量级。实操规则：先按标题层级切”章—节—条”，再对超长条款按句切分并保留条款号前缀。
4. 元数据标注是分块的一部分，不是后处理。每个块必须携带：doc_id、doc_title、doc_type（国标/行标/企标/说明书/报告）、clause_no、page_no、bbox、effective_date、supersedes、confidentiality。其中 effective_date 与 supersedes 决定了知识的时间有效性，confidentiality 决定了权限过滤。

分块后的规范化 JSON（写入对象存储，供 L2 消费）：

{
  "doc_id": "QJ-JX-2023-017",
  "doc_title": "回转窑主减速机检修规程",
  "doc_type": "enterprise_standard",
  "effective_date": "2023-07-01",
  "supersedes": "QJ-JX-2018-009",
  "confidentiality": "internal",
  "clause_no": "5.3.2",
  "page_no": 37,
  "bbox": [72.5, 214.0, 523.8, 268.4],
  "text": "减速机高速轴轴承温度正常运行时应不高于 75 ℃，超过 85 ℃ 应立即停机检查。",
  "parser": {"tool": "mineru", "version": "2.5", "model": "MinerU2.5-2509-1.2B"}
}

2.5 时序信号与观测事件的接入取舍

流式信号（振动、温度、电流、压力）是工业知识图谱最容易接错的一类数据。核心问题只有一个：时序点要不要进图。

答案（判断）：不进。时序点的量级（5000 台设备 × 20 测点 × 1 s 采样 = 每天 86 亿点）与图谱的量级（百万级三元组）差四个数量级，把时序点入图会让图库在两周内不可用。正确做法是”两级建模”：

这样图谱中每台设备每天只增加 24 条左右的观测事件，五年也只有 4 万余条，完全可控；而原始时序仍可在需要时通过 series_id + 时间窗回查。

观测事件入图的三条规则：

1. 只在”有意义”时入图：越限、突变、趋势反转、人工标注。不要把所有窗口都入图。
2. 必须带量纲与统计口径（QUDT）：kg:value 6.2 ; kg:unit unit:MilliMetrePerSecond ; kg:aggregation "mean" ; kg:window "PT1H"。没有量纲的数值在跨源融合时必然出错。
3. 阈值必须来自标准条款而非硬编码：kg:thresholdSource kg:doc_QJ-JX-2023-017_clause_5.3.2。这样标准更新时，阈值可自动追溯并批量复核。

# 找出所有"阈值仍引用已废止标准"的观测定义（知识老化检测）
SELECT ?sensor ?threshold ?doc ?supersededBy WHERE {
  ?sensor kg:hasThreshold ?threshold ;
          kg:thresholdSource ?clause .
  ?clause kg:docId ?doc .
  ?doc kg:supersedes ?old ; kg:effectiveDate ?eff .
  FILTER(?eff > "2026-01-01"^^xsd:date)
  OPTIONAL { ?doc kg:supersededBy ?supersededBy }
}

2.6 接入层的质量门禁

原则：数据到达即校验，不要等到入库才发现脏数据。门禁放在 L1 的最后一个环节（sink 之前），失败数据进隔离区，不进 L2。

体量门禁常被忽略但极其重要：上游一次误操作清空表，CDC 会把 20 万条删除事件推下来，如果没有体量门禁，图谱会在一夜间被清空，而且回滚需要重放全量。

2.7 自建 IDC 部署要点

SeaTunnel 集群的部署形态、Zeta 引擎参数、Checkpoint 与并行度调优、连接器选型详见前置报告 B，此处只补充知识工程特有的三点：

1. 为文档解析单独划一台 GPU 节点（建议 1×A10 24 GB 或 2×RTX 4090），不要与 CDC 任务混部——文档解析是突发性 CPU/GPU 密集任务，与 CDC 的长连接低延迟特性冲突。
2. Kafka 作为接入层与加工层的唯一解耦点，topic 命名规范 kg.{layer}.{domain}.{entity}，保留 7 天，压缩 lz4。所有下游消费必须幂等（用 (src_id, record_version) 做去重键）。
3. 隔离区必须有独立生命周期策略：隔离数据保留 30 天供人工修复重放，超期归档到对象存储冷层，不要直接删除——很多”脏数据”其实是上游系统的问题，需要作为证据保留。

3 L2 知识加工层

3.1 加工流水线四阶段

抽取 → 消歧链接 → 融合 → 入图

四个阶段的输入输出与失败影响：

判断：这四个阶段的工作量比例约为 抽取 25%、消歧链接 35%、融合 25%、入图 15%。绝大多数团队把 70% 精力放在抽取上，结果得到一个”能抽但连不上”的图谱。

3.2 实体抽取与实体链接

抽取的两条路线：

混合路线的具体做法：先用规则与词典把高确定性的实体（位号、日期、数值+单位、标准号）抽出来并从文本中遮蔽，再把剩余文本交给 LLM 抽取关系与隐含实体。这样 LLM 的输入更短、错误面更小，成本下降 40%–60%。

LLM 抽取提示词的工程要点（判断，基于工业文本实践）：

• 输出必须绑定 JSON Schema（用结构化输出/函数调用），禁止自由文本解析；
• 每条抽取结果必须带 evidence（原文片段）与 confidence，无 evidence 的结果直接丢弃；
• 显式给出”不知道就返回空数组”的指令，否则模型会为凑数而编造；
• 三元组谓词必须来自封闭词表（由本体提供，注入 prompt），不允许模型自创谓词——这是控制”谓词爆炸”的唯一有效手段。

实体链接（Entity Linking）的三个失败模式：

实体链接的工程实现建议（判断）：

1. 候选召回三路并行：别名精确匹配 → 字符相似（rapidfuzz，阈值 85）→ 向量相似（bge-m3 或 bge-large-zh，top-10）；
2. 排序用规则而非模型：类型兼容性 + 上下文路径相似度 + 别名命中，三项加权，权重由人工标注 200 条样本调出；
3. 阈值分段处置：> 0.92 自动链接；0.75–0.92 自动链接但打 needs_review 标；< 0.75 建为新实体并进待审队列。不要设置 0.6 以下的自动链接——错链的修复成本是漏链的 10 倍。

3.3 本体构建与约束生成（可执行结论）

前置报告 A 已完整论证九阶段生命周期与 LLM 四角色矩阵（生成者/校验者/解释者/维护者）。此处只保留可直接施工的结论：

水泥行业设备运维本体的骨架（判断，可直接落地）：

设备域：Equipment → RotaryKiln / RawMill / CementMill / Preheater / Cooler / Fan / Conveyor
部件域：Component → Gearbox / Bearing / Motor / Shell / Refractory / Roller / Seal
故障域：FaultMode → Wear / Fatigue / Overheat / Looseness / Blockage / Leakage / Electrical
       （FaultMode 与 Component 通过 hasApplicableComponent 关联，形成"故障-部件"矩阵）
处置域：Action → Replace / Adjust / Clean / Weld / Lubricate / Monitor
证据域：Observation（复用 SOSA）→ VibrationReading / TemperatureReading / OilAnalysis
溯源域：Provenance（复用 PROV-O）→ WorkOrder / InspectionRecord / StandardClause / ExpertStatement
时序域：TimeInterval（复用 OWL-Time），用于"故障发生期""有效期""检修周期"

关键设计决策（判断）：故障模式必须建成独立类而不是字符串属性。因为”轴承外圈剥落”要参与推理（属于疲劳类故障 → 与振动高频能量上升相关）、要参与统计（同类故障平均修复时长）、要参与推荐（对应的处置动作）。建成字符串属性，这三件事全部做不了。

3.4 多源知识融合与冲突消解

同一实体或同一事实被多个源描述且不一致，是知识工程的常态。典型冲突：设备台账说轴承型号是 32230，检修工单写 32230E，说明书标 32230E-T，标准推荐 32230。

三级裁决机制（判断，推荐）：

实现方式：在图中为每个事实保留多值 + 元数据，查询时按策略取”当前有效值”，而不是在写入时就物理覆盖。这是知识图谱相对关系库的核心优势，用覆盖式写入等于放弃了这个优势。

# 同一属性三个来源，共存于图中，由视图裁决
kg:Equipment_3Kiln_MainReducer kg:bearingModel "32230" ;
    prov:wasGeneratedBy kg:src_ledger_2020 .
kg:Equipment_3Kiln_MainReducer kg:bearingModel "32230E" ;
    prov:wasGeneratedBy kg:src_workorder_20250812 ;
    kg:confidence 0.95 .
kg:Equipment_3Kiln_MainReducer kg:bearingModel "32230E-T" ;
    prov:wasGeneratedBy kg:src_manual_v3 ;
    kg:authorityLevel 4 ;
    kg:effectiveFrom "2024-03-01"^^xsd:date .

裁决通过一个 SPARQL 视图（或应用层的 currentValue 函数）实现：

# 按权威性→时效性取当前有效值
SELECT ?value WHERE {
  kg:Equipment_3Kiln_MainReducer kg:bearingModel ?value .
  ?stmt prov:wasGeneratedBy ?src .
  ?src kg:authorityLevel ?auth ; kg:effectiveFrom ?eff .
}
ORDER BY DESC(?auth) DESC(?eff)
LIMIT 1

冲突的四种类型与处置（不是所有冲突都要”解决”）：

3.5 知识质量度量

四个维度必须可量化、可自动计算、可按周环比。

补充两个复合指标（判断，比单项更有决策价值）：

• 可回答率：CQ 集合中能被图谱正确回答的比例。这是”图谱对业务到底有没有用”的最直接度量，建议每月跑一次全量 CQ 回归。目标：首年 60%，第二年 85%。
• 知识覆盖率：业务系统实际使用的实体/属性占图谱总量的比例。若图谱有 367 类但业务只用了 40 类，说明建模严重超配。

3.6 人工介入点设计：人在回路的三种模式

关键设计：审核队列不能是”一堆待办”，必须是”按影响面排序的工作清单”。排序依据 = 该条知识被下游引用的次数 × 置信度缺口 × 权威等级。这样审核员每天打开界面，看到的第一条就是最该看的那条。

审核界面必须提供三件东西：原文高亮（定位到页码与 bbox）、相似存量知识（避免重复录入）、一键纠错（纠错结果直接回写并作为下一次抽取的 few-shot 样本）。第三项是把人工投入转化为模型改进的唯一闭环，缺了它，人工审核就是纯成本。

3.7 加工层的实现细节

抽取提示词骨架（工业文本，封闭词表注入）：

你是水泥设备运维领域的信息抽取器。从给定文本中抽取三元组。

可用谓词（只能从这里选择，不得自创）：
  hasComponent | hasFaultMode | hasSymptom | hasCause | hasAction
  occursOn | detectedBy | measuredBy | governedBy | precedes

实体类型：Equipment | Component | FaultMode | Symptom | Cause | Action | Document

规则：
1. 每条三元组必须给出 evidence（原文连续片段，不得改写）。
2. 无法确定时返回空数组，禁止推测。
3. 数值必须带单位；时间必须为 ISO 8601。
4. 不确定的置信度给 0.5–0.7；有明确表述给 0.85–0.95。

输出 JSON：{"triples":[{"subject":"","subject_type":"","predicate":"","object":"","object_type":"","evidence":"","confidence":0.0}]}

文本：
"""
{chunk_text}
"""

实体链接的打分公式（可直接实现，权重由 200 条人工标注样本调出）：

def link_score(cand, mention, ctx):
    s_type  = 1.0 if type_compatible(mention.type, cand.type) else 0.0
    s_alias = 1.0 if mention.text in cand.alt_labels else 0.0
    s_str   = fuzz.token_set_ratio(mention.text, cand.label) / 100.0
    s_vec   = cosine(mention.embedding, cand.embedding)          # 0..1
    s_path  = jaccard(ctx.ancestor_path, cand.ancestor_path)     # 上下文路径相似度
    if s_type == 0.0:
        return 0.0                     # 类型不兼容直接否决
    return 0.20*s_alias + 0.20*s_str + 0.25*s_vec + 0.25*s_path + 0.10*s_type

三个阈值：>= 0.92 自动链接；0.75–0.92 自动链接并打 needs_review；< 0.75 建新实体进待审队列。类型否决（s_type == 0 → 0）这一行是最重要的——它把”把通用词链接到具体实例”这类错误从源头挡掉。

融合阶段的优先级裁决 SQL 实现（在图库导出的事实表上做，结果回写图库）：

WITH ranked AS (
  SELECT
    entity_iri, predicate, object_value, source_system,
    authority_level, effective_from, confidence,
    ROW_NUMBER() OVER (
      PARTITION BY entity_iri, predicate
      ORDER BY authority_level DESC, effective_from DESC, confidence DESC
    ) AS rn
  FROM kg_fact_staging
  WHERE valid_to IS NULL
)
SELECT entity_iri, predicate, object_value AS current_value, source_system
FROM ranked WHERE rn = 1;

入图的事务边界：一批三元组 + 对应的 PROV 溯源记录 + change_set 记录必须在一个事务内提交。GraphDB 的 SPARQL Update 支持多操作事务，用 INSERT DATA 分块提交时注意每块不超过 5 万条（超过会触发内存问题）。

4 L3 知识存储层

存储选型是整份报告中唯一”选错就要重做”的决策。它决定了本体表达能力、查询性能上限、运维复杂度与总成本，且迁移成本极高——不仅是数据搬迁，还包括所有查询、所有约束、所有应用代码的重写。

4.1 第一个决策：属性图（LPG）还是 RDF 三元组

flowchart TD
    A["需要形式化语义吗？<br/>OWL 公理 / 类推理 / 标准本体复用"] -->|是| RDF["RDF 三元组存储"]
    A -->|否| B["需要复用行业标准词表吗？<br/>SSN / PROV-O / QUDT / IEC CIM / OPC UA 语义"]
    B -->|是| RDF
    B -->|否| C["查询以多跳遍历为主吗？<br/>2-6 跳、路径分析、社群发现"]
    C -->|是| LPG["属性图（LPG）"]
    C -->|否| D["需要强事务与 ACID 多语句写入吗？"]
    D -->|是| LPG
    D -->|否| E["团队已有 SQL/Java 背景、无图经验？"]
    E -->|是| LPG
    E -->|否| RDF

    RDF --> R1["主存：GraphDB / RDFox / Stardog"]
    LPG --> L1["主存：Neo4j / NebulaGraph / TigerGraph"]
    RDF --> MIX["两者都要？<br/>RDF 主存 + LPG 投影"]
    LPG --> MIX

六个决定性判据（不是”各有优劣”，而是按顺序问）：

水泥设备运维场景的结论（判断）：选 RDF 为主存。理由是判据 1、2、3 全部指向 RDF——故障模式的分类推理（轴承外圈剥落 → 疲劳类故障 → 振动特征）、标准条款的时间有效性（OWL-Time）、量纲统一（QUDT）、溯源（PROV-O）、SHACL 的业务约束校验，这五件事在 LPG 上都需要大量自研。而判据 4 的深链遍历需求在本场景中并不突出（典型查询 3–4 跳），且可通过 LPG 投影解决。

4.2 图数据库横向对比（2025–2026 现状）

以下版本与能力信息来自各厂商官方发布记录与公开文档（2025–2026），链接见附录 C。凡标注”厂商宣称”的性能数字，均需自行 POC 验证。

三条横向观察（判断）：

1. LPG 阵营在 2025–2026 集体向”图 + 向量”融合演进（Neo4j 的 Cypher VECTOR 类型与向量索引、NebulaGraph 企业版 5.2.0 的图+向量+全文单查询、Qdrant 与图引擎组合的混合检索方案），本质是在抢占 GraphRAG 场景。RDF 阵营（GraphDB、Stardog）则强化”推理 + 虚拟化 + 自然语言接口”（Stardog Voicebox），走的是”语义层”路线。
2. 许可证风险是自建 IDC 的第一道筛选。Neo4j Community 的 GPLv3 且缺失热备/细粒度权限/在线备份，生产环境几乎必然要买企业版；GraphDB Free 自 11.0 起限制为 2 并发查询，只够做评估；Stardog 免费许可非开源且需年度续期。采购前必须把”三年 TCO”算清，而不是只看”能否免费下载”。
3. 纯云托管产品（Neptune、GES、GraphCompute）在自建 IDC 约束下直接出局，但其架构设计（存算分离、查询分析一体、内置算法库）值得在自建选型时作为能力对照清单。

4.3 分场景选型建议

默认推荐（判断）：GraphDB 11.x 作为 RDF 主存 + Neo4j 2025.x 作为 LPG 投影（按需）。理由：GraphDB 把推理、SHACL、SPARQL、可视化、备份做到了同一套产品里，是自建 IDC 下”运维面最小”的 RDF 选择；Neo4j 的生态（驱动、可视化、GraphRAG 库、Bloom）在应用侧最成熟，投影层用它可以让应用团队快速上手。

4.4 混合存储架构

单一存储无法同时满足四种访问模式：语义查询、向量相似、关键词精确、大文件原文。混合架构的职责划分：

一致性设计的三条规则（判断）：

1. 只有一个权威源。图库是权威，向量库与搜索索引都是派生。任何”在图库和向量库各改一次”的设计都会在半年内产生无法对账的数据分裂。
2. 异步双写 + 每日对账 + 可重建。向量索引必须能从图库 + 对象存储完整重建（保留原文与分块），这是唯一可靠的一致性兜底。
3. 用 outbox 模式而非双写事务。图库写入成功后落一条 outbox 记录，由独立的同步作业消费并更新向量/搜索/LPG，失败可重试。这样即使向量库宕机 2 小时，恢复后也能追平。

-- outbox 表（与图库写入在同一业务事务的边界内）
CREATE TABLE kg_outbox (
  id           BIGSERIAL PRIMARY KEY,
  entity_iri   TEXT        NOT NULL,
  op           TEXT        NOT NULL,      -- upsert / delete
  payload      JSONB       NOT NULL,      -- 需要同步到派生存储的字段
  target       TEXT[]      NOT NULL,      -- {vector, search, lpg}
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
  processed_at TIMESTAMPTZ,
  retry        INT         NOT NULL DEFAULT 0
);
CREATE INDEX idx_outbox_pending ON kg_outbox (created_at) WHERE processed_at IS NULL;

4.5 容量规划与分片

三元组数量估算方法（以水泥厂 5000 台设备为基数）：

关键结论：溯源三元组的开销与业务三元组同量级，这是绝大多数容量估算漏掉的部分。若省略溯源，容量减半但失去可解释性与冲突消解能力，是典型的”省小钱坏大事”。

资源配比经验值（判断）：

分片策略（RDF 库横向扩展弱，必须靠逻辑分区）：

4.6 备份、容灾与版本快照

版本快照是实现”知识可回溯”的关键能力。三种粒度：

1. 本体版本：owl:versionIRI + 语义化版本，通过 named graph 命名（kg:ontology:v2.3.0）保留历史版本；
2. 数据版本：每日导出”变更集”（新增/删除的三元组清单）而非全量快照，保留 90 天。全量快照成本太高，变更集足以回答”上周改了什么”；
3. 推理结果版本：每次全量推理生成一个结果 named graph（kg:inferred:20261031），切换时原子替换，失败可秒级回滚。

4.7 存储层反模式

4.8 图模型设计规范

存储选型定了之后，下一个决定成败的是建模规范。没有规范的图谱在 6 个月后会变成”属性名各异、同义关系并存、类与实例混用”的泥潭，而清理成本远高于一开始就规范。

命名与 IRI 规则

类与实例的判定（判断，最常出错的地方）：如果一个概念需要”有属性值”或”参与关系”，它才是实例；如果它只是”描述另一类东西的共同特征”，它是类。典型误用：把”轴承型号 32230E”建成类（应建成实例，属于 kg:BearingModel），把”回转窑”建成实例（应建成类 kg:RotaryKiln，具体某台窑才是实例 kg:Equipment_3Kiln）。

外部词表复用优先级（自上而下，能不建就不建）：

属性还是关系：一个判断规则——需要独立查询、需要带属性、需要参与推理的，建成关系或独立节点；否则用数据属性。例如”设备有额定功率”用数据属性 kg:ratedPower；”设备由某班组维护”若需要记录”维护起始日期、责任比例”，就必须建成 kg:MaintenanceAssignment 节点（n 元关系具体化）。

事件的建模（水泥场景 69 类事件）：事件必须建成独立节点而非关系，因为事件需要挂时间、地点、参与者、结果、证据。用 kg:Event 作为顶层类，下分 FaultEvent、MaintenanceEvent、InspectionEvent、AlarmEvent，每个事件通过 kg:occursOn 指向设备、通过 kg:hasCause/kg:hasSymptom 关联故障模式、通过 kg:evidencedBy 指向文档或观测。

六条禁止事项：

1. 禁止在数据属性里塞 JSON 字符串（应展开为结构化三元组，否则无法查询）；
2. 禁止同一个语义用两个谓词（hasPart 与 contains 只能留一个，另一个用 owl:equivalentProperty 对齐）；
3. 禁止无单位的数值属性（必须配 qudt:unit）；
4. 禁止把时间写成字符串（用 xsd:dateTime，否则区间查询失效）；
5. 禁止在类上直接写实例级属性（kg:RotaryKiln kg:ratedPower 5000 是错的）；
6. 禁止删除三元组而不留痕（必须走”失效标记 + change_set”，保留历史版本）。

5 L4 推理与计算层

5.1 推理机选型

前置报告 A 第 12 章对推理机的完整论证不再复述，此处给压缩后的选型表与判断。

推荐组合（判断）：

TBox 分类：ELK（本体变更时触发，结果物化）
ABox 前向链：GraphDB 规则引擎（首年）→ RDFox（数据量 > 2000 万或增量延迟要求 < 5 s 时）
约束校验：pySHACL（入图前 + 每日全量 + CI）
业务规则：Drools 或应用代码（不进本体层）

一条明确的反面建议：不要用 HermiT/Openllet 做生产推理。它们的表达能力强，但复杂度是 2-EXPTIME 量级，在工业本体（数百类、数万个体）上单次推理可达数十分钟，且不支持增量。它们的位置是”本体提交前的 CI 检查”，不是”线上服务”。

5.2 规则引擎与 SWRL/Datalog 的工程边界

规则的五类分类与归属（判断，这条分类决定”什么该进推理机”）：

规则工程的四条硬性要求：

1. 规则必须代码化并进 Git，与本体同仓库，版本号对齐；
2. 每条规则必须有唯一 ID、自然语言描述、责任人和单元测试用例（正例 + 反例）；
3. 规则集必须可独立启停，用于灰度与故障隔离；
4. 规则变更必须跑 CQ 回归（见 8.4），回归不通过不允许发布。

RDFox 规则片段示例（派生属性 + 分类）：

@prefix kg: <http://example.com/cement/kg#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

# R01 设备隐患派生：部件存在疲劳类故障 → 设备存在隐患部件
[?eq, kg:hasHiddenRiskComponent, ?comp] :-
    [?eq, kg:hasComponent, ?comp],
    [?comp, kg:hasFaultMode, ?fm],
    [?fm, rdf:type, kg:FatigueFault] .

# R02 故障等级派生：轴承类故障且振动超限 → 高风险
[?fc, kg:riskLevel, kg:High] :-
    [?fc, rdf:type, kg:FaultCase],
    [?fc, kg:involvesComponent, ?c],
    [?c, rdf:type, kg:Bearing],
    [?fc, kg:vibrationSeverity, ?v],
    FILTER(?v > 4.5) .

# R03 传递闭包：部件层级
[?a, kg:partOf, ?c] :- [?a, kg:partOf, ?b], [?b, kg:partOf, ?c] .

5.3 什么时候需要图计算引擎

产品选择：Neo4j GDS（与 Neo4j 同栈，最省事）、GraphScope（阿里开源，支持 Gremlin/GAIA，适合超大规模）、Spark GraphX（已有 Spark 集群时）、NebulaGraph Algorithm（Nebula 生态内）。判断：水泥设备运维场景首年不需要图计算引擎。设备规模（5000 台、3 万部件）的 PageRank 用单机 Python（networkx）即可在秒级完成，引入分布式图计算引擎是纯浪费。第二年当故障案例超过 5 万条、需要做”故障传播链”分析时再引入。

5.4 物化 vs 虚拟化：成本模型与决策树

这是推理层最重要的工程决策，直接决定查询延迟与运维复杂度。

成本模型：

物化总成本  = (全量推理耗时 × 规则/数据变更次数) + 存储增量成本 + 一致性维护成本
虚拟化总成本 = (查询 QPS × 单次推理耗时 × 查询时长) + 延迟劣化的业务损失

以水泥厂实际参数代入（判断，基于典型值）：

结论：核心结论必须物化，但物化的前提是增量推理。没有增量能力的物化在 CDC 场景下会退化为”每小时全量重算”，成本反而高于虚拟化。

决策树：

flowchart TD
    A["该推理结论是否被查询 > 100 次/日？"] -->|是| B["必须物化"]
    A -->|否| C["查询延迟要求 < 500 ms？"]
    C -->|是| B
    C -->|否| D["结论依赖的数据是否高频变更？"]
    D -->|是| E["虚拟化（避免频繁重算）"]
    D -->|否| F["规则条数 < 50 且单次推理 < 200 ms？"]
    F -->|是| E
    F -->|否| B
    B --> G["是否有增量推理能力？"]
    G -->|是| H["物化 + 增量维护（推荐）"]
    G -->|否| I["物化 + 分区重算（按 named graph 分片，只重算受影响分区）"]

混合策略（推荐）：三层结论分层处置——

5.5 增量推理的工程实现要点

四个必须解决的问题：

分区重算的实用做法（在没有原生增量能力时的兜底）：按”设备”作为推理分区键，把 5,000 台设备分成 50 个 named graph（每图 100 台）。变更只影响所属分区，重算该分区（约 10 s），50 个分区轮转可在 8 min 内完成全量刷新，且单次故障只影响 1/50 的数据。这是用工程手段弥补引擎能力缺口的典型方案。

5.6 推理性能基准与调优参数

推理是”看起来简单、跑起来爆炸”的典型环节。以下是可复用的量级参考（判断，基于公开基准与同类项目经验的保守估计，实际需自测）：

关键调优参数：

# GraphDB 推理与内存（graphdb.properties 节选）
# 堆内存：约为热数据三元组规模的 1.5 倍（500 万三元组约 4–6 GB）
-Xmx8g
# 实体索引与谓词索引的缓存比例
graphdb.entity-index.size=8000000
# 规则集：起步用 rdfs-plus，需要 OWL 语义时换 owl-horst
# 不要一开始就用 owl-max（耗时可能高一个数量级）
# 查询超时（防止单条查询拖垮服务）
graphdb.query.timeout=120

# pySHACL 并行化（按形状文件拆分，多进程跑）
from concurrent.futures import ProcessPoolExecutor
shapes_files = ["shapes/equipment.ttl", "shapes/fault.ttl", "shapes/document.ttl"]
with ProcessPoolExecutor(max_workers=3) as ex:
    results = list(ex.map(validate_one_shapes_file, shapes_files))
# 注意：data_graph 每个进程独立加载，内存需按进程数预乘

三个性能陷阱：

1. 规则数量增长快于预期。每加一条 SWRL 规则，前向链的中间结果可能翻倍。控制规则数在 60 条以内，超出时考虑把部分规则下推到查询层（用 SPARQL 属性路径替代）。
2. owl:sameAs 的传递闭包爆炸。实体消歧产生的 sameAs 链会引发推理膨胀，且难以撤销。判断：不要用 owl:sameAs 做实体合并，改用”主实体 + skos:exactMatch + 视图层归一”的方式。
3. SHACL 的 sh:sparql 约束全表扫描。带 sh:sparql 的形状在大图上会退化为全量扫描，必须配合 sh:targetClass 限定范围。

6 L5 知识服务层

这一层是知识图谱与业务系统之间的唯一通道，也是最容易被低估的一层。前置报告 A 已覆盖推理服务化，本章补齐查询服务、检索服务、问答服务与网关治理。

6.1 服务分层

6.2 接口形态选型

推荐组合（判断）：

对外业务系统 → REST（预定义、强类型、可缓存、带版本号 /v1）
前端详情页 → GraphQL（配 DataLoader + 字段级权限）
分析人员 → SPARQL Endpoint（只读账号 + 查询超时 30 s + 行数上限 10 万）
Agent → MCP Server（封装 6–10 个原子工具，不给原始 SPARQL）

一条明确的反面建议：不要把 SPARQL 直接给 LLM 生成。让 LLM 自由生成 SPARQL 的失败率在工业本体上极高（属性名长、前缀多、约束复杂），且错误查询可能拖垮数据库。正确做法是 LLM 只在”预定义的参数化查询模板”中选择并填参（见 6.4）。

6.3 向量检索与混合检索：三路召回

纯向量检索在工业场景的召回质量不足以支撑生产，必须三路并行。

融合排序的三段式：

1) 三路各取 Top-K（K=30/30/20）→ RRF 融合（k=60）
2) Cross-encoder 重排（bge-reranker-v2-m3）取 Top-10
3) 规则加权：实体类型匹配 + 时间有效性（未废止的标准 +0.15）+ 权威等级

RRF（Reciprocal Rank Fusion）优于加权分数的原因很实际：三路分数量纲不同（BM25 分数无上界、余弦相似度 0–1、图扩展是离散跳数），归一化后的加权和极不稳定，而 RRF 只用排名，鲁棒性高得多。

OpenSearch 侧的混合检索查询骨架：

{
  "size": 30,
  "query": {
    "bool": {
      "should": [
        { "multi_match": { "query": "轴承外圈剥落 征兆", "fields": ["text^2", "title^1.5"], "type": "best_fields" } },
        { "knn": { "embedding": { "vector": [0.013, -0.221, "..."], "k": 30 } } }
      ],
      "filter": [
        { "term": { "confidentiality": "internal" } },
        { "range": { "effective_date": { "lte": "2026-10-31" } } }
      ]
    }
  },
  "collapse": { "field": "doc_id" }
}

注意 filter 里的两个条件：保密级别过滤与生效日期过滤必须在检索阶段完成，而不是在结果后处理。否则会把废止的标准、越权的文档送进 LLM 上下文，形成”合规事故 + 幻觉”的双重风险。

6.4 KGQA：三条技术路线的成熟度与选型

推荐架构（判断）：模板优先 + Agent 兜底，语义解析作为中间层但不作为唯一路径。

flowchart TD
    Q["用户问题"] --> IC["意图分类器<br/>（微调小模型或规则+LLM）"]
    IC -->|命中模板| T["参数化查询模板<br/>（40-60 个覆盖 80% 高频问题）"]
    IC -->|未命中| A["LLM Agent"]
    A --> T1["工具1: 实体检索"]
    A --> T2["工具2: 关系查询"]
    A --> T3["工具3: 相似案例检索"]
    A --> T4["工具4: 标准条款检索"]
    A --> T5["工具5: 时序数据查询"]
    T --> R["结果组装 + 证明链"]
    T1 & T2 & T3 & T4 & T5 --> R
    R --> V["答案生成（LLM 仅做语言组织）"]
    V --> C["引用与置信度校验"]
    C --> OUT["输出"]
    IC -->|无法判断| FB["澄清追问"]

关键工程细节：

• 模板库是资产，必须像代码一样维护（版本、测试用例、覆盖率统计）。40–60 个模板可覆盖 80% 的高频问题，投入产出比远高于 Text2SPARQL。
• 答案生成阶段 LLM 只做语言组织，不允许新增事实。实现方式：把检索结果转成结构化事实列表，prompt 中明确”只能使用以下事实，缺失则回答不知道”。
• 必须输出引用（文档页码 / 图数据库实体 IRI / 工单号），无引用的答案降级为”建议人工确认”。
• 置信度门槛：检索最高分 < 阈值或图查询返回空时，直接回答”未找到相关知识”，不要硬答。工业场景中”不知道”远比”编一个”可接受。

6.5 KG-grounded RAG：为什么纯向量 RAG 在工业场景失效

四个结构性失效点（判断，来自工业问答的实际失败案例）：

KG-grounded RAG 的三种落地形态：

关于微软 GraphRAG 与 LightRAG 的适用边界（2025–2026 现状，事实部分标注来源）：

• 微软 GraphRAG 走”索引期用 LLM 抽实体+关系+社区摘要”的路线，效果好在全局性问题（”这批文档的主要风险主题是什么”），但索引成本极高。其 LazyGraphRAG 变体（2024-11-25 发布）把 LLM 调用推迟到查询期，官方称索引成本与向量 RAG 持平、仅为完整 GraphRAG 的 0.1%，并在 96 项基准对比中全部胜出（厂商宣称，来源：Microsoft Research / aiwiki.ai 汇总）。
• LightRAG（港大数据智能实验室，论文被 EMNLP 2025 接收）用双层检索（实体级 + 主题级）替代社区发现，索引成本低、增量更新友好，2025 年 11 月版本已集成 RAGAS 评测与 Langfuse 追踪（来源：PyPI 发布说明）。
• 判断：这两者解决的是”从零文档自动构图”的问题，适合没有既有图谱的场景。工业设备运维通常已有精心建模的本体与高质量实例，此时引入 GraphRAG 的自动抽取反而是倒退——它的实体类型不受控、关系谓词自由、无法做约束校验。正确做法是用自己的图谱做 grounding，用 LightRAG 式的双层检索做文档侧的补充召回。

6.6 缓存策略

失效设计的核心原则（判断）：用版本号而非逐条失效。维护一个全局 graph_version（每次图谱发布递增），所有缓存 key 前缀带版本号。发布后旧 key 自然过期，无需遍历删除。逐条失效在分布式环境下几乎不可能做对，且一旦漏删就是”用户看到旧数据”的隐性 bug。

6.7 网关、限流、鉴权、多租户

行级权限在图上的实现（难点）：水泥集团多基地场景下，A 基地用户不应看到 B 基地的设备知识。三种方案：

判断：用 Named Graph 隔离 + 共享图单独授权。共享知识（标准、通用故障模式）放 kg:shared 图，所有租户可读；基地私有知识放 kg:tenant_{id} 图，仅本租户可读。查询时 FROM kg:shared FROM kg:tenant_007，既隔离又共享，且性能可控。

6.8 SLA 与容量规划

容量反推：问答接口 10 QPS 峰值意味着 LLM 需要支撑 10 并发生成。以 Qwen2.5-32B + vLLM 在单张 A100 80G 上估算，约可支撑 8–15 并发（取决于上下文长度），因此至少需要 1 张 A100 或 2 张 A10 做问答服务，且必须配置排队与超时（> 15 s 直接返回”系统繁忙，请缩小问题范围”）。

降级预案（必须提前设计）：

| 故障 | 降级动作 | 用户感知 | |—|—|—| | 向量库不可用 | 只走 BM25 + 图扩展 | 检索质量下降，功能可用 | | 推理机不可用 | 返回上次物化结果 + 标注”结论可能过期” | 可用 | | LLM 不可用 | 问答降级为”检索结果列表 + 原文片段” | 可用（体验下降） | | 图库主节点故障 | 切只读副本（数据可能滞后 1 min） | 可用 | | 缓存全失效 | 限流阈值降到 30% | 变慢 |

6.9 检索与问答的评测体系

没有评测集的知识服务无法迭代——每次调整分块、权重、提示词，都只能靠”感觉好像好了点”。评测集是这一层唯一的客观标尺。

评测集构建（判断：300 条起步，成本约 3 人周）：

五个核心指标：

评测执行：

• 每次发布前跑全量 300 条（约 40 min，可并行）；
• 每次改动分块/权重/提示词跑子集 100 条（约 15 min）；
• 每周跑一次并记录趋势，指标下降超过 3 个百分点触发告警。

关于 LLM-as-judge 的边界（判断）：可以用 LLM 做初筛（把明显正确的过滤掉，人工只看有争议的），但不能用 LLM 做最终判定。原因是工业场景的答案正确性依赖领域常识，通用 LLM 判官会把”数值正确但单位错”判为正确。折中做法：LLM 判定 + 20% 人工复核，复核不一致率超过 15% 时提高人工比例。

一个常被忽略的指标：答案的可操作性。”3# 窑主减可能存在问题”与”3# 窑主减振动烈度 6.2 mm/s 超过规程 4.5 mm/s 限值，建议 48 小时内做频谱分析”——前者准确率可能也是”正确”，但对用户毫无价值。建议在评测表中加一列”是否给出下一步动作”，作为定性参考。

6.10 服务降级与故障处置

知识服务挂掉时，业务不能跟着挂。降级方案必须在设计阶段定好，而不是故障时临时决定。

三条处置原则：

1. 宁可少答，不可错答。任何一个依赖不可用时，返回”部分结果 + 明确的缺失说明”，绝不返回未经验证的内容。
2. 降级要可观测。每次降级触发都要打点（kg_degrade_total{reason=...}），否则会长期在降级状态下运行而无人知晓。
3. 降级要能自动恢复。恢复必须基于健康检查而非人工操作，且恢复后要跑一次小规模自检（10 条冒烟查询）再全量放量。

健康检查设计（判断：不要只做端口探活）：

# 图谱服务健康检查三层次
liveness:                       # 进程活着
  http: /healthz
  period: 10s
readiness:                      # 能对外服务（依赖就绪）
  http: /readyz                 # 内部检查图库连接 + 索引加载状态
  period: 15s
  failureThreshold: 3
business_probe:                 # 业务语义可用（每 60s 跑 5 条基准查询）
  script: probes/bench_queries.py
  threshold: 4/5 通过且 P99 < 800ms

7 L6 知识应用层

7.1 应用形态全景

判断：首年只做前两个。同时开三个以上应用场景是知识图谱项目最常见的失败原因——每个场景都需要不同的知识覆盖度、不同的接口形态、不同的评测标准，摊薄后没有一个能用。

7.2 智能问答与知识助手

三个能力层级：

落地路径（判断）：L1 先上（2 个月出可用版本，验证检索质量），L2 在知识覆盖度达标后接入（设备类实体完整率 > 95%），L3 视需求而定。跳过 L1 直接做 L3 的项目，通常因检索质量不达标而无法定位问题出在”检索”还是”编排”。

界面设计的三条硬要求：

1. 答案必须带来源：文档页码可点击跳转原文、图查询结果可展开查看三元组、工单可跳转 CMMS。没有来源的答案在工业场景不被采信。
2. 必须显示”知识边界”：明确告知”该结论基于 2023 版规程，该规程已于 2026-01 被替代”或”图谱中无此类故障记录”。用户知道边界才敢用。
3. 必须能一键纠错：每个答案下方有”反馈”入口，纠错内容直接进 L2 的审核队列。这是知识持续进化的主要来源。

7.3 故障诊断辅助：三级能力

这是知识图谱在工业场景中价值最高的应用，也是最容易做成”花架子”的地方。三级能力的差异必须讲清。

L2 的具体实现（推荐，判断）：

输入：设备位号 + 征兆集合（振动烈度、温度、电流、油液分析、异响描述）
步骤1  实体链接：位号 → 设备 IRI；征兆描述 → 征兆实体（映射到本体中的 Symptom 类）
步骤2  图路径搜索：从设备出发，沿 hasComponent → hasFaultMode → hasSymptom 反向匹配
       找出"能解释这些征兆"的故障模式集合（覆盖率 = 命中征兆数 / 故障模式应有征兆数）
步骤3  规则过滤：排除不满足条件的候选（如"该设备未配备油液监测，油液类故障不可判"）
步骤4  排序：按 (征兆覆盖率 × 历史频次先验 × 设备年龄修正) 排序
步骤5  举证：为每个候选返回支撑证据（命中的征兆、历史案例、标准条款、规则链）
输出：候选列表 + 证据 + 建议的验证动作（"建议做振动频谱分析确认是否为轴承外圈频率"）

关键设计（判断）：必须输出”建议的验证动作”。诊断的价值不在于”猜对了”，而在于”指明了下一步该测什么”。这一步把系统从”猜谜机”变成”诊断助手”，也是工程师愿意使用它的真实原因。

7.4 Agent 与工具调用

知识图谱作为 Agent 的可调用工具时，工具粒度设计决定成败。

推荐的 8 个原子工具（水泥设备运维域）：

MCP 工具定义示例：

{
  "name": "infer_root_cause",
  "description": "根据设备位号与征兆列表，返回根因候选排序及支撑证据。适用于用户询问'为什么''可能是什么原因'类问题。不适用于查询设备基本属性。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "equipment_code": {
        "type": "string",
        "description": "设备位号，如 K3-MR-001。必须是 CMMS 中的标准位号。",
        "pattern": "^[A-Z0-9]{1,4}-[A-Z]{2}-[0-9]{3}$"
      },
      "symptoms": {
        "type": "array",
        "items": {"type": "string"},
        "maxItems": 10,
        "description": "征兆描述列表，如 ['振动烈度上升至 6.2mm/s', '轴承温度 82℃']"
      }
    },
    "required": ["equipment_code", "symptoms"]
  },
  "annotations": {"readOnlyHint": true, "idempotentHint": true}
}

三条安全边界（判断，必须写进工具规范）：

1. 默认全部只读。任何写操作（修改实体、写入知识）都不通过 Agent 工具暴露，只能走人工审核界面。Agent 的幻觉会直接污染图谱，且污染难以追溯。
2. 工具描述必须写清”不适用于什么”。LLM 选错工具的主要原因不是描述不清”能做什么”，而是不知道”不该做什么”。
3. MCP 规范版本锁定。MCP 在 2025 年发布了 2025-03-26、2025-11-25 等版本，2026-07-28 版本转向无状态协议核心（来源：blog.modelcontextprotocol.io）。生产环境必须锁定一个版本并做兼容性测试，不要跟随最新。

7.5 BI 与报表联动

知识图谱对 BI 的价值不是”多一个数据源”，而是补齐维度。

落地方案：每日由 L4 作业生成 4 张宽表（星型模型的维度表 + 事实表），落到 PostgreSQL 或 ClickHouse，BI 工具（Superset/Metabase）直连。不要让 BI 工具直连图库——BI 的查询模式（大范围扫描 + 聚合）会拖垮 OLTP 图库。

-- 维度表：设备-部件-故障模式（由图谱生成）
CREATE TABLE dim_equip_fault AS
SELECT
  e.equip_code,
  e.equip_name,
  c.component_name,
  f.fault_mode_name,
  f.fault_category,
  p.process_name
FROM kg_export.equipment e
JOIN kg_export.has_component hc   ON hc.equip_iri = e.iri
JOIN kg_export.component c        ON c.iri = hc.component_iri
JOIN kg_export.has_fault_mode hf  ON hf.component_iri = c.iri
JOIN kg_export.fault_mode f       ON f.iri = hf.fault_iri
JOIN kg_export.in_process p       ON p.equip_iri = e.iri;

7.6 应用接入规范

统一响应体的字段约定：

{
  "code": 0,
  "data": {
    "answer": "3# 窑主减存在轴承疲劳剥落隐患，建议本周安排振动频谱复测。",
    "evidence": [
      {"type": "graph", "iri": "kg:Equipment_3Kiln_MainReducer", "relation": "hasHiddenRiskComponent"},
      {"type": "document", "doc_id": "QJ-JX-2023-017", "clause": "5.3.2", "page": 37, "bbox": [72.5, 214.0, 523.8, 268.4]},
      {"type": "case", "workorder": "WO-2025-0812-014", "similarity": 0.87}
    ],
    "confidence": 0.82,
    "graph_version": "2026.10.31-1",
    "schema_version": "v1",
    "degraded": false
  }
}

7.7 一个诊断案例的完整走查

以”3# 回转窑主减速机高速轴轴承温度 82 ℃、振动烈度 6.2 mm/s”这一现场报警为例，走一遍 L6 应用的完整链路，看清每一层各自贡献了什么。

用户输入（值班长在诊断界面）：选择设备 K3-MR-001，勾选当前报警”轴承温度高”“振动烈度超限”，补充描述”伴随间断性金属敲击声”。

最终呈现给值班长的内容：

结论：3# 窑主减速机（K3-MR-001）存在轴承疲劳剥落的较高可能性（置信度 0.82）。

依据：
· 振动烈度 30 天内由 4.1 升至 6.2 mm/s（+51%），已超规程限值 4.5 mm/s
  （QJ-JX-2023-017 第 5.3.2 条，第 37 页）
· 轴承温度 82 ℃，接近停机阈值 85 ℃（同上条款）
· 伴随间断性金属敲击声，与"滚动体剥落"征兆特征一致
· 历史上同型号减速机出现同类征兆 5 次，其中 4 次最终确认为轴承外圈剥落
  （最近一次 WO-2025-0812-014，更换轴承，停机 16 h）

排除项：齿轮点蚀（征兆覆盖率仅 0.52，且缺少齿面磨损的铁谱数据支撑）

建议下一步动作：
1. 48 小时内安排振动频谱分析，重点看 BPFO（外圈故障频率）及其谐波
2. 备件核查：32230E-T 轴承库存 2 套，满足更换需求
3. 若频谱确认，建议在下次计划检修窗口（11-05 至 11-07）内更换
4. 更换前将温度报警阈值临时下调至 80 ℃，加强监控频次至 2 小时/次

[查看原文]  [采纳]  [不准确，我来纠正]

这个案例说明了三件事：

1. 每一层都不可替代。L3 提供关系（部件-故障-征兆），L4 提供推理与排序，L5 提供检索与组装，L6 提供语言组织与交互。任何一层的缺失都会让结果降级为”一堆文档”。
2. 端到端 3.2 秒（不含 LLM 生成的 1.8 s），其中 LLM 只占一半，其余是可优化的确定性查询。这解释了为什么”纯 LLM 方案”在这个场景不可行——它无法给出引用、无法排序、无法给出可验证的下一步。
3. 建议的下一步动作是价值核心。用户不是因为”系统猜对了”而采纳，而是因为”系统告诉了我该测什么、备件够不够、什么时候停机”。这也是知识图谱相对文档检索的真正差异点。

7.8 应用接入的三个反模式

反模式一：把图谱当”更快的数据库”

症状：应用直接拼 SPARQL 字符串查单个属性，或用图谱替代原本的关系库查询。 后果：延迟反而更高（图谱对单表点查没有优势），且应用与图谱 schema 强耦合。 对策：应用只调用封装好的语义 API（getEquipmentProfile、findSimilarCases），不拼 SPARQL。schema 变更由 API 层吸收。

反模式二：把 LLM 输出直接当答案

症状：检索到内容后交给 LLM 自由生成，不校验、不引用、不带置信度。 后果：早期演示效果好，生产后偶发严重错误，一次错误就摧毁信任。 对策：强制”结构化优先”——先由图谱给出结构化结论与证据链，LLM 只做语言组织；输出必须带 evidence[] 与 confidence，无证据的内容直接截断。

反模式三：一次接入十个应用

症状：图谱刚上线就被要求同时支撑问答、诊断、报表、大屏、移动端、Agent。 后果：每处都做浅，没有一处达到可用标准，最终全部被弃用。 对策：判断——首年只做 1 个”高频、高价值、可量化”的场景（水泥场景建议选”设备故障诊断辅助”而非”综合问答”），做到日活用户 ≥ 30、周采纳率 ≥ 40% 后再横向复制。

8 调度编排：贯穿全链路的作业体系

8.1 知识工程的五类作业

8.2 触发方式与依赖关系

8.3 DAG 设计模式：主流水线 + 旁路校验 + 回滚链路

flowchart LR
    subgraph MAIN["主流水线"]
        A1["同步-增量"] --> A2["加工-增量"]
        A2 --> A3["SHACL 校验"]
        A3 --> A4["入图（写 change_set）"]
        A4 --> A5["推理-增量"]
        A5 --> A6["物化切换"]
    end

    subgraph SIDE["旁路校验（不阻断主流，只告警）"]
        B1["质量抽样"] --> B2["四维指标计算"]
        B2 --> B3["看板更新"]
        B2 --> B4["阈值告警"]
        B5["血缘采集"] --> B3
    end

    subgraph ROLLBACK["回滚链路（失败时触发）"]
        C1["停止下游触发"] --> C2["恢复上一版物化指针"]
        C2 --> C3["回滚 change_set"]
        C3 --> C4["标记受影响实体待重算"]
        C4 --> C5["触发局部重算作业"]
    end

    A3 -.失败.-> C1
    A5 -.失败.-> C1
    A6 -.失败.-> C1
    A4 -.旁路.-> B1
    A5 -.旁路.-> B5

三个设计要点：

1. 旁路校验不阻断主流。质量指标计算与血缘采集失败不应导致知识无法入库——它们是观测能力，不是门禁能力。真正的门禁（SHACL、结构校验）在主流里。
2. 回滚必须精确到”受影响实体”。全量回滚代价太大（一次回滚等于丢失一天的增量），正确做法是回滚 change_set 并标记受影响实体，触发局部重算。
3. 每个作业必须有幂等键。增量加工的幂等键是 (src_id, record_version)；推理作业是 (graph_version, rule_set_version)；发布作业是 (graph_version)。没有幂等键的重跑会造成重复写入与统计翻倍。

8.4 DolphinScheduler vs Airflow：聚焦知识工程场景的再评估

前置报告 B 已给出两者的完整对比与部署建议。此处只回答一个具体问题：本体构建与 CQ 回归该放进哪个系统？

先给结论（判断）：都不放。本体构建与 CQ 回归属于”代码变更的验证”，应该放在 CI（GitLab CI / Jenkins）里，而不是调度器里。理由是：本体与规则的变更由 Git 提交触发，验证结果的”通过/失败”要作为合并请求的门禁，而调度器的产物是”作业实例状态”，两者语义不匹配。把 CQ 回归塞进调度器，会导致”回归失败但合并已发生”的漏洞。

三者的职责边界：

如果必须二选一（单调度器）：选 DolphinScheduler。四条判据：

结论：数据侧（同步/加工/推理/发布）用 DolphinScheduler，代码门禁（本体与 CQ 回归）用 GitLab CI，LLM 批处理用 Airflow（可选）。三者通过”发布事件”串联：CI 通过 → 打 tag → DS 的发布作业监听 tag → 执行发布。

8.5 端到端 DAG 示例

从 MySQL CDC 到推理物化到 CQ 回归到发布的完整链路（DolphinScheduler 工作流定义的核心片段）：

# workflow: kg_full_pipeline
name: kg_full_pipeline
schedule: "0 0 2 * * ?"          # 每日 02:00
timeout: 21600                    # 6 h
params:
  graph_version: ${system.datetime(yyyyMMdd)}-1

tasks:
  - name: seatunnel_full_sync
    type: SEATUNNEL
    config:
      deploy_mode: cluster
      job_file: /opt/kg/jobs/full_sync.conf
    timeout: 5400

  - name: parse_documents
    type: SHELL
    command: python /opt/kg/bin/parse_docs.py --since ${last_success_time}
    timeout: 3600
    retry: {times: 2, interval: 600}

  - name: extract_and_link
    type: PYTHON
    command: python /opt/kg/bin/pipeline.py --stage extract,link --batch-date ${batch_date}
    timeout: 10800
    retry: {times: 1, interval: 900}

  - name: shacl_validate
    type: PYTHON
    command: python /opt/kg/bin/validate.py --shapes /opt/kg/ontology/shapes.ttl --fail-on-error
    timeout: 1800

  - name: write_graph
    type: SHELL
    command: python /opt/kg/bin/write_graph.py --graph kg:data:${graph_version} --write-changeset
    timeout: 3600

  - name: reason_materialize
    type: SHELL
    command: >
      curl -X POST ${REASONER_API}/jobs
      -d '{"graph":"kg:data:${graph_version}","ruleset":"kg-rules-v2.3","target":"kg:inferred:${graph_version}"}'
    timeout: 3600
    retry: {times: 2, interval: 300}

  - name: switch_pointer
    type: SHELL
    command: python /opt/kg/bin/switch_inferred.py --to ${graph_version}
    timeout: 300

  - name: refresh_projection
    type: SHELL
    command: python /opt/kg/bin/project_lpg.py --version ${graph_version}
    timeout: 1800

  - name: rebuild_bi_tables
    type: SQL
    datasource: pg_bi
    sql: "SELECT kg_refresh_dims('${graph_version}')"
    timeout: 1800

  - name: cq_regression
    type: SHELL
    command: python /opt/kg/bin/cq_regression.py --suite cq_full --report /data/reports/cq_${graph_version}.json
    timeout: 1800

  - name: quality_metrics
    type: PYTHON
    command: python /opt/kg/bin/quality.py --emit-metrics
    timeout: 900

relations:
  - [seatunnel_full_sync, extract_and_link]
  - [parse_documents, extract_and_link]
  - [extract_and_link, shacl_validate]
  - [shacl_validate, write_graph]
  - [write_graph, reason_materialize]
  - [reason_materialize, switch_pointer]
  - [switch_pointer, refresh_projection]
  - [switch_pointer, rebuild_bi_tables]
  - [refresh_projection, cq_regression]
  - [cq_regression, quality_metrics]

CI 侧的本体与 CQ 回归（GitLab CI）：

# .gitlab-ci.yml
stages: [lint, reason, validate, regression, publish]

ontology_lint:
  stage: lint
  script:
    - rapper -i turtle -c ontology/kg-core.ttl > /dev/null
    - robot report --input ontology/kg-core.ttl --output reports/robot.html

consistency_check:
  stage: reason
  script:
    # 用 HermiT 做开发期的严格一致性检查（不进生产）
    - robot reason --reasoner hermit --input ontology/kg-core.ttl --output reports/reasoned.owl
    - robot verify --input reports/reasoned.owl --queries queries/inconsistency.sparql

shacl_validate:
  stage: validate
  script:
    - pyshacl -s ontology/shapes.ttl -e ontology/kg-core.ttl -f human data/sample-instances.ttl

cq_regression:
  stage: regression
  script:
    - python ci/cq_runner.py --suite cq_full --expected ci/expected/cq_expected.json --threshold 0.95
  artifacts:
    reports:
      junit: reports/cq-junit.xml

publish_ontology:
  stage: publish
  rules:
    - if: $CI_COMMIT_TAG =~ /^ont-v/
  script:
    - python ci/publish.py --version $CI_COMMIT_TAG

注意 cq_regression 的 --threshold 0.95：CQ 回归不是”全过或全不过”，而是”通过率不低于阈值”。因为部分 CQ 依赖的数据尚未入库是正常状态，硬性 100% 通过会导致门禁长期红着，团队就会开始忽略它。

8.6 事件驱动 vs 定时触发

事件驱动的一个工程陷阱：CDC 事件在高峰期会瞬时涌入（如月底批量工单录入），若直接触发加工会造成下游雪崩。正确做法是事件 → 缓冲 → 批处理：事件写入 Kafka 后由消费者按”每 5 分钟或累计 5,000 条”两个条件之一触发批次，并在批次级别做背压（下游处理慢时暂停消费）。这条设计能把突发流量平滑成稳定负载，是知识工程流水线稳定性的关键。

8.7 作业失败处置手册

知识工程的作业失败往往不报错，而是”跑完了但结果不对”。因此失败处置要覆盖两类：显式失败与静默失败。

静默失败的通用防线：为每类作业定义 2–3 个”业务基线指标”（增量行数、抽取产出率、链接率、违规数、结论数），每日与 7 日均值比对，偏离超过 40% 即告警。这条防线的价值高于任何单点监控——它能在无人察觉时发现”作业在跑但没干活”。

回滚的三层设计：

第 1 层：作业级重跑（幂等保证）—— 所有加工作业必须幂等，重跑不产生重复数据
第 2 层：批次级回滚 —— 每个 change_set 可逆，按 batch_id 撤销
第 3 层：版本级回滚 —— 图谱整体回到上一个发布版本（快照恢复，RTO < 30 min）

三层必须都具备。只有第 1 层时，遇到”错误数据已流入下游”就无法处理；只有第 3 层时，回滚代价过大导致没人敢回滚。

9 治理与可观测

9.1 知识质量监控：四维实时看板

看板设计的核心原则（判断）：每个指标必须能下钻到具体记录。看板显示”一致性 97.2%”没有行动价值，能点进去看到”这 2.8% 是 137 条三元组，其中 89 条是故障模式值域违规”才有。不能下钻的指标一律不上看板，只会变成装饰。

9.2 血缘与溯源

一条三元组的来源必须能追到原始凭证。三级溯源模型：

# 完整的溯源链示例
kg:stmt_bearing_32230E a kg:Statement ;
    rdf:subject   kg:Equipment_3Kiln_MainReducer ;
    rdf:predicate kg:bearingModel ;
    rdf:object    "32230E" ;
    prov:wasGeneratedBy  kg:job_extract_20261031_0412 ;
    prov:wasAttributedTo kg:doc_QJ-JX-2023-017_clause_5.3.2 ;
    kg:extractModel      "qwen2.5-72b-instruct@v2026-09" ;
    kg:promptVersion     "extract-v7" ;
    kg:confidence        0.93 ;
    kg:reviewedBy        "expert:zhangwei" ;
    kg:reviewedAt        "2026-10-31T14:22:00+08:00" .

kg:doc_QJ-JX-2023-017_clause_5.3.2
    kg:docId     "QJ-JX-2023-017" ;
    kg:clauseNo  "5.3.2" ;
    kg:pageNo    37 ;
    kg:bbox      "[72.5,214.0,523.8,268.4]" ;
    kg:docHash   "sha256:9f2c..." .

血缘的三条工程要求：

1. 溯源三元组与业务三元组同事务写入，不允许异步补写（补写必然漏）。
2. 文档哈希必须记录。文档被替换后，旧知识的溯源会指向新版本内容，哈希可以检出这种”错位引用”。
3. 血缘要能反向查询：”这份文档影响了哪些知识”与”这条知识来自哪里”同样重要——标准更新时，需要知道哪些知识需要复核。

与元数据平台的集成：DataHub 1.x 与 OpenMetadata 1.9.x 都支持 OpenLineage 事件（OpenLineage 1.x 协议已是事实标准，dbt 自 1.9+ 支持列级血缘）。集成方式：加工作业向 OpenLineage 端点发 RunEvent，把”源表 → 加工作业 → 图库数据集”的链路注册进去，实现”从业务库到图谱”的跨系统血缘。

判断：元数据平台是第二年的事。首年用自建 provenance 表 + 简单可视化即可满足；但要在首年就把 source_system、job_id、doc_hash 三个字段埋好，否则第二年补血缘要重跑全量加工。

9.3 版本管理：本体、规则、数据三者协同

三者绑定的实现：每个 graph_version 在元数据表中记录 (ontology_version, ruleset_version, doc_snapshot_date) 三元组。查询时返回 graph_version，用户可据此判断结论基于哪版本体与规则。

CREATE TABLE kg_release (
  graph_version     TEXT PRIMARY KEY,
  ontology_version  TEXT NOT NULL,
  ruleset_version   TEXT NOT NULL,
  doc_snapshot_date DATE NOT NULL,
  triple_count      BIGINT NOT NULL,
  cq_pass_rate      NUMERIC(4,3) NOT NULL,
  released_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
  released_by       TEXT NOT NULL,
  status            TEXT NOT NULL DEFAULT 'active'   -- active / superseded / rolled_back
);

回滚能力：三个版本必须能独立回滚，但组合必须合法。回滚本体版本时，必须同时回滚到与该本体兼容的规则版本与数据版本——这一点在变更前就要做兼容性矩阵，而不是回滚时才发现不兼容。

9.4 权限与安全

一条常被忽略的安全风险：LLM 提示词中的越权数据泄露。检索阶段如果没有做权限过滤，把 restricted 文档块塞进 LLM 上下文，模型会在答案中复述出来。这不是理论风险——多租户场景下这是最高频的数据泄露路径。防线只有一条：权限过滤必须在检索阶段完成，且由服务端强制注入，不能依赖应用层传参。

9.5 监控告警体系：指标、日志、链路追踪

链路追踪的落地要点：一次 KGQA 请求跨 5–7 个组件（网关、实体链接、图查询、向量检索、LLM、结果组装），没有追踪就无法定位”为什么这次回答慢”。必须在网关生成 trace_id 并透传到所有下游，且在图查询的 span 中记录实际执行的 SPARQL/Cypher（截断到 2,000 字符）。这条信息在排查”某个查询突然变慢”时是唯一线索。

告警的降噪原则（判断）：知识工程的告警最容易失效的方式是”告警太多”。三条规则：

1. 只对”需要人立刻行动”的事告警。质量指标下滑用日报，不用告警。
2. 同一根因只发一条。用告警分组（按 service + error_type）而非逐条发送。
3. 每条告警必须附”建议动作”。没有建议动作的告警等于把排查工作推给值班人员。

9.6 成本核算

成本结构的两个反直觉结论（判断）：

1. 人力成本占总成本的 80% 以上，硬件与软件许可合计不到 20%。因此”买贵的工具省人力”通常是正确决策，”省许可费多雇人”通常错误。选型时把”运维一个人能否搞定”作为重要判据，而不是只看许可价格。
2. LLM 成本不是主要成本，但会突然失控。失控场景是”全量重跑抽取”——一次本体大改导致全部文档重抽，2 万文档 × 8k token 在 API 模式下就是数万元。防线：抽取结果必须缓存（按 doc_hash + prompt_version 做键），重跑只处理变更部分。

9.7 质量指标的可执行实现

四个维度的指标必须能跑出数，否则看板就是装饰。以下 SPARQL 可直接挂到定时作业里，结果写入监控库。

完整性：必填属性缺失率

SELECT ?class (COUNT(?s) AS ?total) (SUM(?missing) AS ?miss) 
       ((1.0*SUM(?missing)/COUNT(?s)) AS ?ratio) WHERE {
  VALUES ?class { kg:Equipment kg:Component kg:FaultMode }
  ?s a ?class .
  OPTIONAL { ?s kg:hasCode ?c1 }  BIND(IF(BOUND(?c1),0,1) AS ?m1)
  OPTIONAL { ?s kg:locatedIn ?c2 } BIND(IF(BOUND(?c2),0,1) AS ?m2)
  OPTIONAL { ?s kg:hasResponsibleDept ?c3 } BIND(IF(BOUND(?c3),0,1) AS ?m3)
  BIND(?m1 + ?m2 + ?m3 AS ?missing)
} GROUP BY ?class

一致性：违反 SHACL 约束的实体数（用 pySHACL 输出报告，解析 sh:focusNode 计数）

from pyshacl import validate
conforms, report_graph, report_text = validate(
    data_graph=load_graph("kg_data.ttl"),
    shacl_graph=load_graph("kg_shapes.ttl"),
    ont_graph=load_graph("kg_ontology.ttl"),
    inference="rdfs", advanced=True, js=False,
)
violations = report_graph.query("""
  SELECT ?focus ?shape (COUNT(?r) AS ?n) WHERE {
    ?r a sh:ValidationResult ; sh:focusNode ?focus ; sh:sourceShape ?shape .
  } GROUP BY ?focus ?shape ORDER BY DESC(?n)
""")

准确性：抽样人工校验通过率

-- 从质量抽样表统计，按来源系统分组，找出最不可靠的来源
SELECT source_system,
       COUNT(*)                                        AS sampled,
       SUM(CASE WHEN verdict='correct' THEN 1 ELSE 0 END) AS correct,
       ROUND(1.0*SUM(CASE WHEN verdict='correct' THEN 1 ELSE 0 END)/COUNT(*), 3) AS accuracy
FROM kg_quality_sample
WHERE sample_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY source_system ORDER BY accuracy ASC;

时效性：知识老化分布

SELECT ?bucket (COUNT(?s) AS ?n) WHERE {
  ?s kg:lastVerifiedAt ?t .
  BIND(IF(?t > NOW() - "P90D"^^xsd:duration, "fresh",
      IF(?t > NOW() - "P365D"^^xsd:duration, "aging", "stale")) AS ?bucket)
} GROUP BY ?bucket

四个指标统一写入 kg_metrics_daily 表，看板按”实体类型 × 来源系统”两个维度切片。判断：完整性低于 0.85 或一致性违规数周环比增长超过 30% 时，应暂停新数据接入，先修质量问题——带着坏数据往下游跑，只会让修复成本指数上升。

9.8 知识运营的组织机制

知识图谱不是交付物，是资产；资产需要运营。技术做得再好，没有运营机制，图谱会在 12 个月内变成”没人维护的旧系统”。

三个必须存在的角色（可以是兼职，但必须有明确责任人）：

四个固定节奏：

纠错闭环设计（这是运营的核心机制）：

用户在应用里点"不准确，我来纠正"
  → 生成纠错工单（含问题三元组、用户描述、截图）
  → 自动分类：实体错误 / 关系错误 / 缺失 / 过时
  → 实体与关系错误：进入消歧/融合审核队列（工程师 24h 内处理）
  → 缺失：进入抽取任务池（下一批文档处理时补）
  → 过时：触发源系统重新同步 + 人工确认
  → 闭环后回告用户："您反馈的问题已修正，感谢"

这个闭环有两个作用：一是持续改进质量；二是让用户感知到”我的反馈有用”，这是采纳率能长期维持的前提。判断：没有纠错入口的知识系统，用户第一次遇到错误后就会永久降低使用频率。

采纳率的度量（唯一值得长期跟踪的业务指标）：

采纳率 = 被采纳的建议数 / 被展示的建议数

水泥设备诊断场景的健康值：上线 3 个月 ≥ 25%，6 个月 ≥ 40%，12 个月 ≥ 55%。低于 25% 说明知识或服务有问题，需要停下扩展、回头修质量。

10 技术组件全景清单

10.1 必需组件 vs 可选组件

10.2 分阶段引入顺序

推迟引入的判断依据必须写清。最常见的过度建设是”第一天就上 DataHub + Milvus + Neo4j + RDFox”，结果是四个系统各配了 20%，没有一个能用，团队 80% 的时间在做集成。

10.3 自建 vs 开源 vs 商业的取舍原则

10.4 最小可行栈（MVP）

能跑通端到端的最小组合，全部可离线部署在自建 IDC：

MVP 的验收标准：一条工单从 CDC 到可被问答检索，端到端延迟 < 5 min；CQ 可回答率 ≥ 60%；问答答案带来源引用；SHACL 校验通过率 ≥ 99%。

10.5 完整栈（生产级）

在 MVP 基础上增加：

10.6 组件选型速查表

10.7 国产化替代路径

自建 IDC 的工业客户常有信创要求，需要提前规划替代路径。判断：不要在项目初期就为了国产化而牺牲技术选型的合理性；正确的做法是”架构上保留可替换性，替换时按层推进”。

替代路线的三个工程前提（不满足就换不动）：

1. 查询层不直连数据库方言：所有 SPARQL/Cypher/nGQL 语句收敛到服务层的 20–30 个具名查询，不在应用里散落。换库时只改这一层。
2. 本体与数据格式用标准：Turtle/JSON-LD 而非某家私有格式。这是 RDF 相对 LPG 的一个隐性优势——数据本身是可移植的。
3. 推理与约束不依赖厂商扩展：如果规则用 RDFox 的 .dlog 写，换库时规则全部重写；如果用标准 SWRL/SHACL + SPARQL，可移植性高得多。代价是性能下降，需要权衡。

建议的替代优先级（判断）：先换无痛层（集成、调度、向量、解析，这些本身已是国产主导或开源中立），再换应用层（LLM），最后才动存储层。存储层替代的代价最高，应在选型时就把”能否接受 Jena Fuseki 作为兜底”作为一项评估指标。

11 参考部署架构（自建 IDC）

11.1 物理拓扑

flowchart TB
    subgraph DMZ["安全域 A：DMZ（对外服务）"]
        LB["负载均衡 / WAF<br/>VIP 10.10.1.10"]
        GW1["APISIX 网关 1<br/>10.10.1.21"]
        GW2["APISIX 网关 2<br/>10.10.1.22"]
        LB --> GW1 & GW2
    end

    subgraph APP["安全域 B：应用区（10.10.2.0/24）"]
        API1["KG API 1<br/>4C/8G"]
        API2["KG API 2<br/>4C/8G"]
        QA["问答服务<br/>8C/16G"]
        RD1["Redis 主<br/>4C/16G"]
        RD2["Redis 从<br/>4C/16G"]
        API1 --> RD1
        API2 --> RD1
        RD1 -.复制.-> RD2
    end

    subgraph DATA["安全域 C：数据区（10.10.3.0/24）"]
        GDB["GraphDB 主<br/>16C/64G/NVMe 2T"]
        GDB2["GraphDB 从<br/>16C/64G/NVMe 2T"]
        PG1["PostgreSQL 主<br/>8C/32G"]
        PG2["PostgreSQL 从<br/>8C/32G"]
        OS["OpenSearch 3 节点<br/>8C/32G/SSD 1T"]
        MV["Milvus 3 节点<br/>8C/32G"]
        MINIO["MinIO 4 节点<br/>8C/32G/HDD 8T"]
        GDB -.同步复制.-> GDB2
        PG1 -.流复制.-> PG2
    end

    subgraph COMPUTE["安全域 D：计算区（10.10.4.0/24）"]
        ST["SeaTunnel 集群<br/>3 节点 8C/32G"]
        KF["Kafka 3 节点<br/>8C/32G/SSD 1T"]
        DS["DolphinScheduler<br/>1M2W"]
        WK1["加工 Worker 1<br/>8C/32G"]
        WK2["加工 Worker 2<br/>8C/32G"]
    end

    subgraph GPU["安全域 E：GPU 区（10.10.5.0/24）"]
        G1["LLM 推理节点<br/>2×A100 80G / 128G RAM"]
        G2["文档解析节点<br/>1×A10 24G / 64G RAM"]
    end

    GW1 --> API1 & API2
    GW2 --> API1 & API2
    API1 --> GDB
    API2 --> GDB
    API1 --> OS
    API2 --> MV
    QA --> G1
    ST --> KF
    KF --> WK1 & WK2
    WK1 --> G1
    G2 --> MINIO
    WK1 --> GDB
    DS -.调度.-> ST
    DS -.调度.-> WK1
    DS -.调度.-> WK2
    WK1 --> PG1
    MINIO --> WK1

11.2 资源规划表

11.3 网络分区与安全域

三条硬性网络规则（判断）：

1. GPU 区无外网出口。LLM 节点一旦能访问互联网，就存在把知识数据发出去的风险（无论是有意还是模型行为）。模型权重与依赖包用离线方式导入。
2. 数据区不直接对外。所有查询必须经 B 区服务，禁止业务系统直连图库——否则无法做统一鉴权、限流与审计。
3. 跨域访问白名单 + 双向 TLS。内部服务间也用 mTLS，防止横向移动。

11.4 高可用设计：各组件故障域分析

关键判断：GraphDB 主节点是最大单点。它同时承担写入与推理，故障时虽然可切从库读，但写入与增量推理会停摆。缓解措施有三条：① 从库保持同步复制，切换后数据不丢；② 推理作业设计为可重入（幂等键 = graph_version + ruleset_version），恢复后自动补算；③ 明确接受”故障期间知识不更新”（这是可接受的业务影响，比”知识错误”轻得多）。

11.5 中小规模 vs 大规模两套配置

11.6 容量水位与扩容触发条件

容量规划不是一次性的，要定义”什么时候该扩容”的明确信号，避免靠感觉。

两个容易被忽略的容量项：

1. 图谱快照的存储。每次发布保留一份快照，500 万三元组的快照约 1.5–3 GB（压缩后）。按周发布、保留 12 个版本计算，需要预留 20–40 GB，且需要独立的备份存储而非与主库同盘。
2. 推理产生的中间结果。前向链推理的中间结论可能比原始数据多 2–5 倍。按 3 倍估算：500 万原始三元组 → 物化后 1500–2000 万，磁盘与内存都要按这个规模规划，而不是按原始数据规划。

12 实施路线图

12.1 四阶段划分

gantt
    title 知识图谱工程四阶段实施甘特图
    dateFormat YYYY-MM-DD
    axisFormat %m月

    section P0 打地基
    CQ 清单定稿（30 条）          :p0a, 2026-11-01, 21d
    本体骨架 + SHACL 形状         :p0b, after p0a, 30d
    MVP 栈部署（单机）             :p0c, 2026-11-01, 21d
    2 个源接入 + 1 类文档抽取      :p0d, after p0c, 45d
    端到端演示验收                 :milestone, after p0d, 0d

    section P1 建闭环
    CDC 增量同步                   :p1a, after p0d, 30d
    加工流水线（抽取→消歧→融合）    :p1b, after p0d, 45d
    SHACL 门禁 + 质量看板          :p1c, after p1b, 20d
    DAG 编排 + 发布流程            :p1d, after p1c, 25d
    首个问答应用上线               :p1e, after p1d, 30d
    闭环验收                       :milestone, after p1e, 0d

    section P2 扩覆盖
    全设备域实体 + 故障案例库       :p2a, after p1e, 90d
    标准条款库 + 溯源               :p2b, after p1e, 60d
    混合检索 + 诊断应用             :p2c, after p2a, 60d
    血缘体系 + 治理看板             :p2d, after p2b, 45d
    覆盖率验收                     :milestone, after p2c, 0d

    section P3 深应用
    增量推理 + 图算法               :p3a, after p2c, 75d
    Agent 工具化（MCP）            :p3b, after p2d, 60d
    BI 联动 + 多租户               :p3c, after p3a, 60d
    成本核算 + 运营体系             :p3d, after p3c, 45d
    全面验收                       :milestone, after p3d, 0d

12.2 每阶段交付物与验收标准

12.3 人力配置建议

人力配置的三条判断：

1. 领域专家的投入不能低于 20%。知识图谱的瓶颈从来不是技术，而是”没人能判断这条知识对不对”。领域专家投入不足的项目，最终会产出大量”技术上正确、业务上无用”的三元组。
2. 本体工程师与数据工程师必须分开。一个人同时做本体与管道，结果是本体迁就管道（”这个属性不好抽，删掉吧”），模型逐渐退化为表结构。
3. 前端不能省。审核队列、质量看板、问答界面三者都需要精心设计，缺一个就有一个环节退化为 Excel。

12.4 关键风险与应对

12.5 常见失败模式

13 结论与选型建议

13.1 五条核心建议

建议一：先建”能更新”的链路，再建”更全”的模型。 知识图谱的第一价值不是覆盖多少类，而是能否跟上业务变化。一个只有 60 个类但能每 5 分钟同步、每周自动回归的图谱，价值远高于一个有 400 个类但三个月没更新的图谱。P0 阶段的验收标准应该是”增量链路跑通”，而不是”类数量达标”。

建议二：存储层选 RDF 为主存、LPG 为投影，不要试图用一个数据库解决所有问题。 需要 OWL 分类、SHACL 约束、标准本体复用时，RDF 是唯一合理选择（GraphDB 11.x 起步，规模上去换 RDFox 做增量推理）；需要低延迟深链遍历与图算法时，投影一份 LPG（Neo4j 2025.x）供应用侧使用。两套存储的运维成本远低于”在一套存储上做妥协”的长期代价。

建议三：LLM 只做语言层，判定权交给推理机与校验器。 LLM 的正确用法是：把非结构化文本变成候选三元组、把用户问题变成查询参数、把结构化结果变成人话。它不负责判断”这条知识对不对”——那是 SHACL 与推理机的职责。所有 LLM 输出必须经过”结构校验 → 约束校验 → 置信度门槛 → 人工抽检”四道闸门。

建议四：调度用 DolphinScheduler 跑数据作业，用 CI 跑本体与 CQ 回归，不要把两者混在一起。 数据作业的产物是数据状态，代码变更的产物是门禁结果，两者的语义、失败处置、重跑方式完全不同。混在调度器里会导致”回归失败但代码已合并”的漏洞。三个系统（DS + GitLab CI + 可选 Airflow）通过 tag/事件串联即可。

建议五：把治理做成产品，而不是做成文档。 质量四维看板必须能下钻到记录、血缘必须能追到原文页码、版本必须能独立回滚、成本必须能按层归集。这四件事在首年就要有最简版本（哪怕用 Grafana + 自建表实现），否则第二年的”知识质量下降”将无法定位原因。

13.2 什么情况下不要做知识图谱

知识图谱不是所有问题的答案，以下六种情况下投入知识图谱是资源浪费：

一个简单的反向判据：如果无法列出 30 条”必须跨三个以上数据源才能回答”的业务问题，就不要做知识图谱。能列出 30 条，说明关系价值真实存在；列不出，说明需求还没到那一步。

13.3 关键不确定性

参考

A 术语表

B 组件清单与版本速查

C 主要参考来源

图数据库与知识图谱平台

1. Neo4j Release Notes（2025.10，Cypher VECTOR 类型）— https://neo4j.com/release-notes/database/neo4j-2025-10/
2. Neo4j Fleet Manager 发布（2025-12）— https://neo4j.com/press-releases/neo4j-launches-fleet-manager/
3. NebulaGraph v5.2.0 发布说明（图+向量+全文单查询、库内计算）— https://www.nebula-graph.com.cn/posts/v5.2.0
4. NebulaGraph 社区版 Release Notes（v3.8.0）— https://docs.nebula-graph.com.cn/master/20.appendix/release-notes/nebula-comm-release-note/
5. GraphDB Release Notes（11.x）— https://help.graphwise.ai/en/graphdb/graphdb-release-notes.html
6. Enterprise Knowledge Graph Platforms 2026 对比（含 GraphDB Free 限制、TigerGraph 定价、Neo4j 市场份额、SPARQL 1.2 Working Draft）— https://futureagi.com/blog/enterprise-knowledge-graph-platforms-2026/
7. Stardog 12.1 新特性 — https://community.stardog.com/t/whats-new-in-stardog-12-1/5567
8. AllegroGraph 8.5.3 Release Notes — https://franz.com/agraph/support/documentation/8.5.3/release-notes.html
9. 华为云 GES 产品优势（EYWA 内核、查询分析一体）— https://support.huaweicloud.com/productdesc-ges/ges_04_0002.html
10. 阿里云 GraphCompute 产品概述（自研图引擎、OLAP 侧重）— https://help.aliyun.com/en/graph-compute/product-overview/what-is-graph-compute
11. Virtuoso 08.03.3335 发布说明 — https://www.openlinksw.com/data/html/virtuoso-08-03-3335-ai-release-claude_sonnet_4_6-1.html
12. TigerGraph 架构与 Savanna 平台 — https://atlan.com/know/ai-agent/knowledge-graph/tigergraph-enterprise-graph-database/
13. State of Databases 2026（Neptune openCypher 与 neural search 演进）— https://devnewsletter.com/p/state-of-databases-2026/
14. Palantir Foundry Ontology 概念（Object/Link/Action/Function/Interface）— https://www.palantir.com/docs/foundry/getting-started/foundry-platform-summary-llm
15. Neo4j GraphRAG for Python（Knowledge Graph Builder）— https://neo4j.com/blog/developer/knowledge-graphs-neo4j-graphrag-for-python/
16. RDFox 与 Oxford Semantic Technologies（2024-07 被 Samsung 收购）— https://www.oxfordsemantic.tech/blog/oxford-semantic-technologies-launches-rdfox-mantix
17. Apache Jena 6.1.0 发布（2026-05-03）— https://community.apache.org/blog/2026_05_releases.html

GraphRAG / KGQA

1. LazyGraphRAG 索引成本（官方称与向量 RAG 持平、为完整 GraphRAG 的 0.1%）— https://aiwiki.ai/wiki/graphrag
2. LazyGraphRAG 基准表现与集成情况 — https://www.articsledge.com/post/lazygraphrag-retrieval-augmented-generation
3. LightRAG 发布说明（EMNLP 2025；2025.11 集成 RAGAS 与 Langfuse）— https://pypi.org/project/lightrag-hku/
4. Qdrant 混合检索（dense + sparse + RRF）— https://qdrant.tech/articles/hybrid-search/

文档解析

1. MinerU2.5 论文（解耦式视觉语言模型）— https://arxiv.org/html/2509.22186
2. MinerU PyPI 说明（支持 PDF/图片/DOCX/PPTX/XLSX）— https://pypi.org/project/mineru/
3. Docling（IBM，多格式文档转换）— https://www.ibm.com/products/docling
4. PaddleOCR 更新日志（PP-DocLayout mAP@0.5 90.4%、PaddleOCR-VL）— http://www.paddleocr.ai/main/update/update.html
5. PaddleOCR 3.3.0 发布（2025-10-16）— https://pypi.org/project/paddleocr/

治理、血缘、调度

1. DataHub 端到端血缘能力 — https://datahub.com/blog/end-to-end-data-lineage/
2. OpenMetadata 版本发布记录（1.9.x / 2.0）— https://pypi.org/project/openmetadata-ingestion/
3. Apache Atlas 2.4.0（2025-01）与架构 — https://atlan.com/what-is-apache-atlas/
4. OpenLineage 1.x 与列级血缘（dbt 1.9+）— https://www.wickedsmartdata.com/articles/multi-hop-data-lineage-tracking-across-the-modern-data-stack-connecting-ingestion-transformation-and-consumption-with-openlineage-and-marquez
5. Apache SeaTunnel 3.0.0 发布 — https://seatunnel.apache.org/docs/ ；https://www.cnblogs.com/seatunnel/p/23239448
6. Apache Airflow 3.1.0（Human-in-the-Loop）— https://airflow.apache.org/blog/
7. Apache DolphinScheduler 3.4.2 发布 — https://cloud.tencent.com/developer/article/2685877
8. MCP 规范版本演进（2025-03-26 / 2025-11-25 / 2026-07-28 无状态核心）— http://blog.modelcontextprotocol.io/tags/roadmap/ ；https://blog.modelcontextprotocol.io/posts/2026-07-28/
9. pgvector 0.8.2 发布 — https://www.postgresql.org/about/news/pgvector-082-released-3245/
10. Milvus 2.6.x GA — https://zilliz.com/blog/milvus-2-6-ga-on-zilliz-cloud

版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆

• AINative (5)

• AINative (5)