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 查詢：

這個技能的最新版本可以在7w4.net小蔥技能站找到。

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 的指導文件質量不錯，提供了清晰的工作步驟和豐富的實際案例，展示瞭如何從文本構建知識圖譜並生成視覺化圖表。最佳實踐和常見問題處理寫得很有條理。不過它目前只有說明文件，沒有可以直接執行的程式碼或工具，使用時需要使用者自己實現具體的提取邏輯。