knowledge-graph-construction

目录

• 工作流
• 架构选择指南
• 模式设计
• 输出模板

知识图谱构建

工作流

复制此清单并逐步完成：

KG Construction Progress:
- [ ] Step 1: Identify data sources and domain scope
- [ ] Step 2: Select graph data model
- [ ] Step 3: Design schema and ontology
- [ ] Step 4: Configure extraction pipeline
- [ ] Step 5: Define layered architecture
- [ ] Step 6: Validate and quality-check the graph

步骤 1：确定数据源和领域范围

梳理输入数据：文档类型（论文、临床记录、网页、日志）、数据量、更新频率和语言。界定领域边界——明确目标用例涉及哪些实体类型和关系类型。确定知识图谱将用于 RAG 检索、推理、分析，还是多种用途。此范围界定步骤可避免过度提取，并让模式设计保持聚焦。

步骤 2：选择图数据模型

根据架构选择指南选择底层数据模型。主要权衡因素：LPG 灵活且适合快速原型开发；RDF/OWL 支持基于标准的互操作性和推理；超图适用于复杂的 N 元关系；时态图适用于随时间演变的知识。请考虑查询语言、工具成熟度和向量集成需求。有关数据模型的详细比较，请参阅数据模型参考。

步骤 3：设计模式和本体

定义节点类型（实体类）、边类型（关系类）和属性模式。应用模式设计中的模式：简单领域采用实体—关系模式，N 元关系采用事件再化，多源集成采用分层架构。确定是否使用受控词表、基数约束，以及是否采用或扩展现有本体（例如 Schema.org、UMLS、SNOMED）。有关方法的详细信息，请参阅方法参考。

步骤 4：配置抽取流水线

构建用于填充图谱的流水线。核心组件：借助 LLM 并通过多轮验证进行实体抽取；使用基于提示词或依存句法分析的方法抽取关系；实体规范化（合并同义词、关联本体）；以及通过后处理验证来实施模式约束。在提示词中使用少样本示例，以提高抽取一致性。加入第二轮 LLM 验证，以捕获遗漏的实体。有关完整的流水线设计，请参阅方法参考。

步骤 5：定义分层架构

将知识图谱划分为多个层级，以便维护并建立可信度。常见模式：第 1 层（实例数据）存放特定于用户或案例的实体和关系；第 2 层（领域知识）存放来自文献或领域专家的精选事实；第 3 层（规范本体）存放形式化模式和顶层本体。添加来源和证据分层，确保每条事实都可追溯到其源文档、抽取方法和置信度分数。对于知识会不断演变的领域，可使用时态子图记录按时间索引的状态。

步骤 6：验证并检查图谱质量

在多个层面运行验证：模式符合性（所有节点和边是否都符合声明的类型？）、覆盖率（预期的实体类型是否都有数据？）、一致性（是否存在相互矛盾的边？）和完整性（基于抽样的人工审核）。使用第二个 LLM，根据源文档核查抽取出的三元组。计算图统计信息（节点度分布、连通分量、孤立节点），以识别抽取缺口。质量标准定义于质量评估标准。

架构选择指南

按用例分类

模型	灵活性	标准化程度	推理能力	向量集成	查询语言	最适合
LPG	高	低	有限	原生（Neo4j）	Cypher、Gremlin	快速开发、RAG 流水线
RDF/OWL	中	高	完整（OWL-DL）	通过扩展实现	SPARQL	互操作性强、本体密集型领域
超图	高	低	有限	自定义	自定义 API	N 元关系、多实体事件
时序	中	低	基于时间	通过扩展实现	Temporal Cypher	持续演变的知识、情景记忆

按领域分类

领域	推荐模型	理由
生物医学 / 临床	RDF/OWL	UMLS/SNOMED 本体，需要推理
企业 / RAG	LPG	快速迭代、集成向量搜索
事件中心型（新闻、日志）	超图或时序	多参与者事件、随时间演变
法律 / 合规	RDF/OWL	形式化推理、溯源链
科学文献	LPG + 分层	灵活提取、分层信任

模式设计

实体-关系模式

最简单的模式。节点表示实体，边表示二元关系。节点上的属性存储特征；边上的属性存储关系元数据（置信度、来源、时间戳）。

(:Person {name, role}) -[:WORKS_AT {since}]-> (:Organization {name, type})
(:Drug {name, class})  -[:TREATS {efficacy}]-> (:Disease {name, icd_code})

最适合：主要包含二元关系且复杂度适中的领域。

事件重ification模式

将 N 元关系和复杂事件建模为一等节点。事件节点通过带类型的角色边连接所有参与者。这样可以避免将 N 元关系强行转换为二元边而造成的信息丢失。

(:ClinicalTrial {id, phase, start_date})
  -[:HAS_DRUG]->     (:Drug {name})
  -[:HAS_CONDITION]-> (:Disease {name})
  -[:HAS_OUTCOME]->   (:Outcome {measure, value})
  -[:CONDUCTED_BY]->  (:Organization {name})

最适合：涉及多个参与者的事件、临床数据、新闻事件、金融交易。

分层层级模式

将图划分为信任级别不同的层，可单独查询，也可联合查询。

Layer 3 (Canonical Ontology): Formal class hierarchy, relation definitions, constraints
Layer 2 (Domain Knowledge):   Curated facts from literature, expert-validated
Layer 1 (Instance Data):      Extracted from user documents, case-specific, lower confidence

跨层边将实例与领域概念相连，并将领域概念与本体类相连。每条边上的来源元数据会记录：来源文档、提取方法、置信度分数和时间戳。

最适合：多源集成、带信任评分的 RAG、企业知识管理。

输出模板

KNOWLEDGE GRAPH CONSTRUCTION SPECIFICATION
============================================

Domain: [Target domain and scope]
Use Case: [RAG / Reasoning / Analytics / Hybrid]
Data Sources: [List of input data types and volumes]

Data Model: [LPG / RDF / Hypergraph / Temporal]
Query Language: [Cypher / SPARQL / Gremlin / Custom]
Storage Backend: [Neo4j / Amazon Neptune / Virtuoso / etc.]

Schema Definition:
  Node Types:
  1. [EntityType] - [description]
     Properties: [list with types]
  2. [EntityType] - [description]
     Properties: [list with types]
  3. [Continue for each node type...]

  Edge Types:
  1. [RelationType] (source -> target) - [description]
     Properties: [list with types]
  2. [Continue for each edge type...]

  Constraints:
  - [Cardinality, uniqueness, required properties]

Extraction Pipeline:
  1. Entity Extraction
     - Method: [LLM-assisted / NER / Hybrid]
     - Prompt template: [summary or reference]
     - Verification: [Multi-round / Second-LLM / Manual sample]
  2. Relation Extraction
     - Method: [Prompt-based / Dependency parsing / Hybrid]
     - Few-shot examples: [count and source]
  3. Normalization
     - Deduplication: [method]
     - Ontology linking: [target ontology]
     - Synonym resolution: [approach]

Layered Architecture:
  Layer 1 (Instance): [description of instance-level data]
  Layer 2 (Domain):   [description of curated domain knowledge]
  Layer 3 (Ontology): [description of formal schema]
  Provenance: [How source/confidence/timestamp are tracked]

Validation Plan:
  - Schema conformance: [automated checks]
  - Coverage: [expected entity/relation counts]
  - Consistency: [contradiction detection method]
  - Human review: [sampling strategy]

Estimated Scale: [node count, edge count, properties per node]
Key Dependencies: [libraries, APIs, ontologies]

NEXT STEPS:
- Implement extraction pipeline on sample data
- Populate graph and run validation suite
- Iterate schema based on extraction results
- Integrate with downstream application (RAG, reasoning, etc.)