name: knowledge-graph-creation description: 通过提取实体、映射关系、生成图三元组和可视化结果，从非结构化文本构建结构化知识图谱。 license: MIT metadata: author: awesome-ai-agent-skills version: 1.0.0

知识图谱创建

本技能让 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）、关注的实体类型，或最大图谱规模。

根据以下关于我们微服务架构的文本构建知识图谱。
输出 Neo4j 的 Cypher 查询和一张 Mermaid 图。

文本："API Gateway 将请求路由到 Auth Service 和 Order Service。
Order Service 依赖于 Inventory Service 和 Payment Service。
Payment Service 与 Stripe 和 PayPal 集成。所有服务都向 Event Bus
发布事件，Analytics Service 消费这些事件。"

示例

示例 1：来自技术文档的知识图谱

用户请求：

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

提取的实体：

关系与三元组：

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。"

提取的实体与关系：

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 和 Frontend 团队共同的关键风险区域。

最佳实践

• 使用一致的谓词词表。 在构建图谱前定义一组受控的关系类型（DEPENDS_ON、CREATED_BY、PART_OF 等）。这能支持有意义的查询，并防止同义词碎片化。
• 规范化实体名称。 将别名、缩写和共指解析为单一规范名称。"JS"、"JavaScript"和"ECMAScript"应映射到一个节点，除非区别很重要。
• 包含实体属性。 仅有名称的裸节点不如带有类型、描述和元数据属性的节点有用。更丰富的节点支持更强大的查询。
• 优先考虑关系方向性。 始终将关系建模为有向边，带有清晰的主体和客体。如果双向关系在每个方向上语义不同，应表示为两条有向边。
• 保持图谱聚焦。 并非每个名词都需要成为实体。聚焦于与用户目的相关的实体，排除那些增加噪声而无洞见的泛化术语。

边缘情况

• 歧义实体引用： 当文本包含代词或模糊引用（"it"、"the system"）时，根据上下文将其解析为具体实体。如果解析不确定，注明歧义并请用户澄清。
• 隐含关系： 某些关系是隐含但未明确陈述的（例如"Alice 和 Bob 在 Acme Corp 工作"蕴含两个 WORKS_AT 关系）。提取这些，但标记为推断的而非直接陈述的。
• 非常大的来源文本： 对于超过数千词的文档，分块处理文本，并在块间合并实体图谱，边走边去重。如果结果图谱超过实用的可视化规模（约 50+ 节点），警告用户。
• 矛盾信息： 如果来源文本包含关于关系的冲突陈述（例如一段说"Service A 依赖 Service B"，另一段说"Service A 没有外部依赖"），则两者都包含并标记矛盾。
• 领域特定术语： 在专业领域（医疗、法律、金融），当用户的确需要与现有知识库互操作时，实体类型和关系谓词应反映领域本体（例如医疗用 SNOMED CT，金融用 FIBO）。

这个 Skill 的指导文档质量不错，提供了清晰的工作步骤和丰富的实际案例，展示了如何从文本构建知识图谱并生成可视化图表。最佳实践和常见问题处理写得很有条理。不过它目前只有说明文档，没有可以直接运行的代码或工具，使用时需要用户自己实现具体的提取逻辑。