---
name: knowledge-graph-extraction
description: 从文档中抽取实体和关系，整理成知识图谱：实体类型、主语-谓词-宾语三元组（附原文引文和置信度）、把重复项合并到一个规范名称下，输出可直接导出 CSV 的表格和 Mermaid 图。适用于有人想梳理谁和谁合作、哪些客户用了哪些产品，要把文档变成知识图谱、抽取实体和关系、从笔记构建图谱，或为 GraphRAG、Neo4j 准备数据时。
---

# 从文档抽取知识图谱

知识图谱是一组“主语—谓词—宾语”形式的陈述（“恒远科技 — uses — 账易通”），和 W3C RDF 三元组是同样的三段结构。只有每条陈述都能追溯到原文句子、同一个事物始终用同一个名字时，它才有用。所以这里的每个三元组都带着引文和置信度，并且在画图之前先合并重复项。

## 适用场景

- 把会议纪要、合同、CRM 记录或报告整理成一张人、公司、产品及其关系的地图。
- 准备导入图谱工具（Neo4j、Kumu、电子表格数据透视）或 RAG 系统的 CSV。
- 在大量文档中回答“谁和什么有关联？”。
- 不适用于从零设计一个领域的类和规则：如果实体类型还不清楚，先用 ontology-draft。

## 需要准备

- 文档或粘贴的文本。给它们编号（D1、D2……），让每个三元组都能注明出处。
- 重要的实体类型和关系。如果没有给出，通读一遍后提出 4 到 8 个实体类型和 5 到 10 个谓词，标为“[提议]”，然后继续。
- 现有的规范名称清单（客户名单、员工通讯录）。没有的话，在第 4 步建一个。

## 步骤

1. **先确定实体类型和谓词。** 写成一个简短清单：类型用单数名词（Person、Company、Product、Project），谓词用小写动词短语（works_at、uses、owns、reports_to）。一个含义只用一个谓词；“受雇于”和“任职于”都写成 works_at。
2. **逐句抽取三元组。** 只抽取句子明确陈述的内容。每个三元组包含：主语、谓词、宾语、原文引文（60 字以内，一字不改）、文档和位置。不要因为位置相近就推断关系（“在同一段里提到”不算关系）。
3. **评定置信度。** 高：直接陈述（“王敏负责星轨项目”）。中：有陈述但语气含糊或间接（“王敏现在好像在管星轨”）。低：由上下文暗示。这个技能的既定做法：低置信度的三元组保留在表格里，但不放进图中。
4. **把重复项合并到规范名称下。** 把变体（“恒远”“恒远科技”“恒远科技有限公司”）归到一个规范名称下，并记录别名。同名的不同事物加上限定词（“水星（项目）”“水星（供应商）”）。不确定两个名字是否指同一个实体时，分开保留，并列出这个问题。
5. **检查冲突。** 两个不可能同时成立的三元组（王敏 reports_to 赵磊；王敏 reports_to 孙丽）要标出来，附上双方的出处和日期。只有文档带日期时才优先采用较新的来源；否则保留为待解决问题。
6. **写出结果。** 一张实体表、一张可直接导出 CSV 的三元组表（不合并单元格，每行一个三元组），以及一张只含高、中置信度三元组的 Mermaid 流程图。在 Mermaid 中，含空格或括号的标签要加双引号，不要用单独的 end 这个词作节点 id。

## 输出格式

````markdown
## 实体
| id | canonical_name | type | aliases |
|---|---|---|---|
| E1 | [名称] | [类型] | [别名; 别名] |

## 三元组
| subject | predicate | object | confidence | source_quote | source |
|---|---|---|---|---|---|
| [规范名称] | [谓词] | [规范名称] | high/medium/low | "[原文引文]" | D[n]，[章节/行] |

## 关系图（仅高、中置信度）
```mermaid
flowchart LR
  E1["[名称]"] -->|[谓词]| E2["[名称]"]
```

## 待解决问题
- [可能的重复 / 冲突 / 不清楚的关系]，出处 D[n]、D[n]
````

## 示例

**输入：**
D1（通话记录，5月3日）：“恒远科技的王敏说，他们已经给财务团队上线了账易通。他们的 CFO 赵磊批准了。”
D2（邮件，5月10日）：“恒远科技有限公司想加购账易通报表。王敏提到，这个项目可能由刘婷接手。”

**输出：**

````markdown
## 实体
| id | canonical_name | type | aliases |
|---|---|---|---|
| E1 | 恒远科技 | Company | 恒远科技有限公司 |
| E2 | 王敏 | Person | |
| E3 | 赵磊 | Person | |
| E4 | 账易通 | Product | |
| E5 | 账易通报表 | Product | |
| E6 | 刘婷 | Person | |
| E7 | 账易通上线 | Project | |
| E8 | 账易通项目 | Project | |

## 三元组
| subject | predicate | object | confidence | source_quote | source |
|---|---|---|---|---|---|
| 王敏 | works_at | 恒远科技 | high | "恒远科技的王敏" | D1，第 1 行 |
| 恒远科技 | uses | 账易通 | high | "他们已经给财务团队上线了账易通" | D1，第 1 行 |
| 赵磊 | works_at | 恒远科技 | high | "他们的 CFO 赵磊" | D1，第 2 行 |
| 赵磊 | approved | 账易通上线 | high | "赵磊批准了" | D1，第 2 行 |
| 恒远科技 | interested_in | 账易通报表 | high | "想加购账易通报表" | D2，第 1 行 |
| 刘婷 | may_lead | 账易通项目 | medium | "这个项目可能由刘婷接手" | D2，第 2 行 |

## 关系图（仅高、中置信度）
```mermaid
flowchart LR
  E2["王敏"] -->|works_at| E1["恒远科技"]
  E3["赵磊"] -->|works_at| E1
  E1 -->|uses| E4["账易通"]
  E1 -->|interested_in| E5["账易通报表"]
  E3 -->|approved| E7["账易通上线"]
  E6["刘婷"] -->|may_lead| E8["账易通项目"]
```

## 待解决问题
- 刘婷是恒远科技的员工，还是我们公司的？D2 没有说明。
- “账易通上线”和“账易通项目”可能是同一个项目；暂时分开保留。
````

## 发送前检查

- [ ] 每个三元组都有一段确实出现在所注明文档中的原文引文。
- [ ] 现实中的每个实体只用一个规范名称出现，并列出了别名。
- [ ] 每个含义只用一个谓词；没有两个谓词表示同一件事。
- [ ] 关系图只包含高、中置信度的三元组，并且是能正常渲染的 Mermaid。
- [ ] 可能的重复和冲突都列为待解决问题，没有悄悄合并。

## 常见错误

- 把同时出现当成关系。两个名字出现在同一段里，除非有句子说明它们怎么关联，否则不算有关系。
- 让谓词清单膨胀到 40 个近义词。抽取之前先合并。
- 把所有三元组都画出来。超过大约 30 条边的图就看不清了；按实体或类型拆开。