knowledge-graph-creation

知识图谱创建

此技能可让 AI Agent 将非结构化文本转换为结构化知识图谱。Agent 会提取实体（人物、组织、技术、概念），识别实体之间的关系，生成正式的图三元组（主语－谓语－宾语），并以可查询格式（Neo4j 的 Cypher、JSON-LD）和可视化图示（Mermaid）输出图谱。知识图谱有助于理解复杂领域、支持语义搜索、发现隐含联系和构建推荐系统。

工作流

1. 分析源材料： 阅读输入文本，判断其领域、范围和复杂程度。确定文本中可能出现的实体类型（人物、组织、地点、技术概念、事件等），以及适用于图谱的粒度。技术架构文档需要细化到组件级别的实体，而新闻文章可能只需要较粗略的参与者级别实体。

2. 提取实体： 识别文本中的所有命名实体和重要概念。对于每个实体，记录其规范名称、类型（人物、组织、技术、概念、事件、地点）及提及的显著属性（例如，成立日期、版本号、角色）。对以不同名称或缩写出现的实体进行去重。

3. 映射关系： 对于文本中存在交互的每一对实体，识别它们之间的关系。将每种关系表示为有向三元组：（主语）-[谓语]->（宾语）。从一致的词汇表中选择谓语（例如，WORKS_AT、DEPENDS_ON、CREATED_BY、PART_OF、COMPETES_WITH）。记录关系来源句，便于追溯。

4. 生成图三元组和模式： 将提取的数据整理成结构化格式。以以下一种或多种格式输出三元组：用于 Neo4j 的 Cypher CREATE 语句、用于 Web 互操作性的 JSON-LD，或由（主语、谓语、宾语）行组成的简单 CSV。定义一个轻量级模式，列出实体类型和有效的关系类型。

5. 可视化图谱： 生成易于阅读的图谱可视化。使用 Mermaid 语法嵌入 Markdown，或为 D3.js、Gephi 或 Neo4j Browser 等工具描述布局。突出显示中心节点和关键关系簇。

6. 验证和优化： 检查图谱的完整性和准确性。检查孤立节点（没有关系的实体）、文本隐含但缺失的关系，以及过于笼统、可以进一步细化的谓语。请用户确认、纠正图谱，或要求扩展特定子图。

用法

向 Agent 提供一段文本、一份文档或一组文档。也可以指定所需的输出格式（Cypher、JSON-LD、Mermaid）、关注的实体类型或图谱的最大规模。

Build a knowledge graph from the following text about our microservices architecture.
Output Cypher queries for Neo4j and a Mermaid diagram.

Text: "The API Gateway routes requests to the Auth Service and the Order Service.
The Order Service depends on the Inventory Service and the Payment Service.
The Payment Service integrates with Stripe and PayPal. All services publish
events to the Event Bus, which the Analytics Service consumes."

示例

示例 1：从技术文档构建知识图谱

用户请求：

根据以下文本构建知识图谱： “Kubernetes 在集群中编排容器化应用。Pod 是 Kubernetes 中最小的可部署单元，包含一个或多个容器。Pod 由 Deployment 管理，Deployment 会确保副本数量符合预期。Service 将 Pod 暴露给网络流量。Ingress 将外部 HTTP 流量路由到 Service。etcd 存储所有集群状态数据，并由 API Server 访问。kubectl 是与 API Server 通信的 CLI 工具。”

提取的实体：

实体	类型	属性
Kubernetes	技术	容器编排平台
Pod	概念	最小的可部署单元
Container	概念	Pod 内的运行时单元
Deployment	概念	管理 Pod 副本
Service	概念	网络暴露层
Ingress	概念	外部 HTTP 路由
etcd	技术	分布式键值存储
API Server	组件	中央管理接口
kubectl	工具	CLI 客户端

关系和三元组：

主体	谓词	客体
Kubernetes	ORCHESTRATES	Pod
Pod	CONTAINS	Container
Deployment	MANAGES	Pod
Service	EXPOSES	Pod
Ingress	ROUTES_TO	Service
etcd	STORES_STATE_FOR	Kubernetes
API Server	READS_FROM	etcd
kubectl	COMMUNICATES_WITH	API Server

Cypher 查询：

CREATE (k:Technology {name: 'Kubernetes', description: 'Container orchestration platform'})
CREATE (pod:Concept {name: 'Pod', description: 'Smallest deployable unit'})
CREATE (container:Concept {name: 'Container', description: 'Runtime unit'})
CREATE (deploy:Concept {name: 'Deployment', description: 'Manages Pod replicas'})
CREATE (svc:Concept {name: 'Service', description: 'Network exposure layer'})
CREATE (ing:Concept {name: 'Ingress', description: 'External HTTP routing'})
CREATE (etcd:Technology {name: 'etcd', description: 'Distributed key-value store'})
CREATE (api:Component {name: 'API Server', description: 'Central management interface'})
CREATE (ctl:Tool {name: 'kubectl', description: 'CLI client'})

CREATE (k)-[:ORCHESTRATES]->(pod)
CREATE (pod)-[:CONTAINS]->(container)
CREATE (deploy)-[:MANAGES]->(pod)
CREATE (svc)-[:EXPOSES]->(pod)
CREATE (ing)-[:ROUTES_TO]->(svc)
CREATE (etcd)-[:STORES_STATE_FOR]->(k)
CREATE (api)-[:READS_FROM]->(etcd)
CREATE (ctl)-[:COMMUNICATES_WITH]->(api)

---

示例 2：知识图谱的 Mermaid 可视化

用户请求：

根据以下文本，用 Mermaid 图创建知识图谱： “Alice 领导 Backend Team。Bob 是 Backend Team 的成员，并维护 Payment Service。Payment Service 依赖 PostgreSQL Database 和 Redis Cache。Carol 领导 Frontend Team，并构建了 Dashboard App；该应用会调用 Payment Service API。”

提取的实体和关系：

主体	谓词	客体
Alice	LEADS	Backend Team
Bob	MEMBER_OF	Backend Team
Bob	MAINTAINS	Payment Service
Payment Service	DEPENDS_ON	PostgreSQL Database
Payment Service	DEPENDS_ON	Redis Cache
Carol	LEADS	Frontend Team
Carol	BUILT	Dashboard App
Dashboard App	CALLS	Payment Service

Mermaid 图：

graph LR
    Alice["Alice (Person)"] -->|LEADS| BT["Backend Team"]
    Bob["Bob (Person)"] -->|MEMBER_OF| BT
    Bob -->|MAINTAINS| PS["Payment Service"]
    PS -->|DEPENDS_ON| PG["PostgreSQL Database"]
    PS -->|DEPENDS_ON| RC["Redis Cache"]
    Carol["Carol (Person)"] -->|LEADS| FT["Frontend Team"]
    Carol -->|BUILT| DA["Dashboard App"]
    DA -->|CALLS| PS

该可视化立即显示，Payment Service 是一个连接度很高的中心节点：它由 Bob 维护，被 Dashboard App 依赖，并且自身依赖两个数据存储。这使它成为 Backend Team 和 Frontend Team 都需要重点关注的风险区域。

最佳实践

• 使用一致的谓词词汇。 在构建图谱之前，定义一组受控的关系类型（DEPENDS_ON、CREATED_BY、PART_OF 等）。这样可以支持有意义的查询，并避免同义词分散。
• 规范化实体名称。 将别名、缩写和共指统一到一个规范名称。除非需要区分，否则 “JS”、“JavaScript” 和 “ECMAScript” 应映射到同一个节点。
• 包含实体属性。 只有名称的简单节点，不如包含类型、描述和元数据属性的节点实用。信息更丰富的节点可以支持更强大的查询。
• 优先明确关系方向。 始终将关系建模为具有明确主体和客体的有向边。如果双向关系在两个方向上的语义不同，应将其表示为两条有向边。
• 保持图谱聚焦。 并非每个名词都需要成为实体。应聚焦于与用户目的相关的实体，并排除那些只会增加噪声、却没有带来洞见的通用术语。

边缘情况

• 指代对象模糊： 如果文本中包含代词或含糊的指代（“它”“该系统”等），请结合上下文将其解析为具体实体。如果无法确定，请指出歧义并请用户澄清。
• 隐含关系： 某些关系是隐含的，并未明确说明（例如，“Alice 和 Bob 在 Acme Corp 工作”意味着两条 WORKS_AT 关系）。请提取这些关系，但标记为推断所得，而非直接陈述。
• 超长源文本： 对于超过几千字的文档，请分块处理，并在处理过程中合并各块的实体图、去除重复项。如果生成的图超出实用的可视化规模（约 50 个以上节点），请提醒用户。
• 相互矛盾的信息： 如果源文本中包含相互冲突的关系陈述（例如，一段中说“Service A 依赖 Service B”，另一段中说“Service A 没有外部依赖”），请同时纳入这两条陈述并标记矛盾。
• 领域专用术语： 在专业领域（医疗、法律、金融）中，如果用户要求与现有知识库互操作，实体类型和关系谓词应遵循相应的领域本体（例如，医疗领域使用 SNOMED CT，金融领域使用 FIBO）。