Knowledge Graph 知識圖譜（一）：核心概念、三元組與語意網路

大多數人把資料庫想成一張張表格，於是用 JOIN 拼湊出「關係」。 知識圖譜的答案是：關係本身就是一等公民，直接存進邊（edge）裡。 大多數人以為知識圖譜只是「漂亮的關係圖」。 正確答案是：它是一套能被機器推理（inference）的語意知識庫。

這個系列會帶你走到哪裡

這是「Knowledge Graph 知識圖譜」五篇系列的第一篇。整個系列的目標是：讓你不只「聽過」知識圖譜，而是能親手建一個、查詢它、並把它接到 LLM 上做問答。

• Part 1（本篇）：核心概念 — 實體、關係、三元組、本體、RDF/OWL/SPARQL
• Part 2：從零建構知識圖譜 — NER、關係抽取、用 Neo4j 與 Cypher 落地
• Part 3：與相似技術比較 — 關聯式資料庫 / 向量資料庫 / 文件資料庫
• Part 4：知識圖譜 + LLM — GraphRAG、多跳推理、降低幻覺
• Part 5：實戰專案 — 用 LLM 自動把文件抽成知識圖譜並做問答

一、核心問題：為什麼需要知識圖譜？

先看一個具體問題。假設你在做一個電影問答系統，使用者問：

「諾蘭導演的電影裡，有哪些演員也演過漫威電影？」

用傳統關聯式資料庫，你得寫一串多重 JOIN：先找出諾蘭的電影、再找這些電影的演員、再去比對哪些演員出現在漫威電影的演員表裡。當問題變成「三跳」「四跳」關係時，SQL 會越寫越痛苦，效能也急遽下降。

知識圖譜的世界觀不同：它把「諾蘭 — 執導 → 全面啟動」「李奧納多 — 演出 → 全面啟動」這種事實直接存成節點與邊。要回答上面的問題，只是在圖上「走路」（graph traversal）—— 從諾蘭出發，沿著邊一步步走到答案。

        ┌──────────┐   執導    ┌────────────┐   演出    ┌──────────────┐
        │  諾蘭     │ ────────▶ │  全面啟動   │ ◀──────── │ 李奧納多      │
        └──────────┘           └────────────┘           └──────┬───────┘
                                                               │ 演出
                                                               ▼
                                                        ┌──────────────┐
                                                        │  神鬼獵人      │
                                                        └──────────────┘

一句話定義：知識圖譜（Knowledge Graph）是一種用「圖結構」來表示與操作知識的知識庫 —— 用**節點（node）表示實體（entity），用邊（edge）表示實體之間的關係（relationship），並透過本體（ontology）**賦予這些關係可被機器推理的語意。

二、最小單位：三元組（Triple）

知識圖譜的原子單位是三元組，格式是「主語 — 謂語 — 賓語」（Subject — Predicate — Object）：

( 主語 Subject )──[ 謂語 Predicate ]──▶( 賓語 Object )

範例：
  ( 諾蘭 )   ──[ 執導 ]──▶ ( 全面啟動 )
  ( 全面啟動 ) ──[ 上映於 ]──▶ ( 2010 )
  ( 李奧納多 ) ──[ 出生於 ]──▶ ( 洛杉磯 )

每一個三元組就是一個「事實」。把成千上萬個三元組疊在一起，重疊的節點自然連成一張網 —— 這張網就是知識圖譜。

這個設計有三個關鍵特性，正是它和傳統資料庫最大的差異：

三、兩大流派：RDF 三元組 vs 屬性圖（Property Graph）

知識圖譜在工程上有兩種主流的資料模型，初學者最容易混淆，這裡一次講清楚。

3.1 RDF（Resource Description Framework）

RDF 來自 W3C 的語意網路（Semantic Web）標準。每個東西都用 URI 唯一標識，知識就是一堆三元組的集合。它強調「全球唯一識別」與「跨資料源互通」。

語意網路標準家族
┌───────────────────────────────────────────────────────┐
│  RDF      用三元組描述資料的基本模型                      │
│  RDFS     定義 class 階層與 property 框架                 │
│  OWL      定義更豐富的本體：等價、傳遞、互逆等邏輯規則      │
│  SPARQL   查詢 RDF 資料的標準語言（類似 SQL 之於關聯式）   │
└───────────────────────────────────────────────────────┘

RDF 三元組長這樣（Turtle 語法）：

1@prefix ex: <http://example.org/> .
2
3ex:Nolan    ex:directed   ex:Inception .
4ex:Inception ex:releasedIn "2010"^^xsd:gdYear .
5ex:DiCaprio ex:actedIn    ex:Inception .
6ex:DiCaprio ex:bornIn     ex:LosAngeles .

3.2 屬性圖（Property Graph）

屬性圖是 Neo4j 等圖資料庫採用的模型。節點和邊都可以掛屬性（key-value），更貼近程式設計師的直覺，也更適合 OLTP 即時查詢。

  ┌─────────────────────┐         directed          ┌──────────────────────┐
  │ (:Person)           │ ───────[since: 2008]─────▶ │ (:Movie)             │
  │  name: "Nolan"      │                            │  title: "Inception"  │
  │  born: 1970         │                            │  year: 2010          │
  └─────────────────────┘                            └──────────────────────┘

注意差異：在屬性圖裡，year: 2010 是節點的屬性；在 RDF 裡，它會是另一個三元組。

3.3 該選哪一個？

選擇心法：如果你的核心需求是「跨機構共享、嚴謹推理、符合語意網路標準」→ RDF；如果是「快速開發、即時查詢、應用導向」→ 屬性圖。本系列的實作部分（Part 2、Part 5）會以 Neo4j 屬性圖為主，因為它對工程師最友善。

四、本體（Ontology）：讓圖能「推理」的關鍵

很多人以為知識圖譜 = 一堆節點和邊。其實真正讓它區別於「畫個關係圖」的，是本體——也就是 schema 層，它定義了：

• 類別（Class）：有哪些類型的實體？（Person、Movie、Company）
• 屬性與關係（Property）：實體之間能有哪些關係？關係的定義域與值域是什麼？
• 規則（Axiom）：例如「執導」的主語一定是 Person、「子公司」關係具有傳遞性

有了本體，機器就能做推理（inference），推導出沒有被明確寫下來的事實：

已知事實：
  ( A 公司 )──[ 子公司 ]──▶( B 公司 )──[ 子公司 ]──▶( C 公司 )

本體規則：
  「子公司」具有傳遞性（transitive）

推理出的隱含事實（沒人寫過，但機器自動得出）：
  ( A 公司 )──[ 子公司 ]──▶( C 公司 )

這就是知識圖譜「比資料庫聰明」的地方：它不只儲存你寫進去的，還能推導出邏輯上必然成立的新知識。OWL 提供了一整套這類規則：owl:TransitiveProperty（傳遞）、owl:inverseOf（互逆，如「執導」與「被執導」）、owl:sameAs（等價，用於實體對齊）等。

五、用 SPARQL 查詢：回到開頭的問題

回到一開始那個問題：「諾蘭的電影裡，有哪些演員也演過漫威電影？」用 SPARQL 表達，幾乎就是把問題逐字翻譯：

1PREFIX ex: <http://example.org/>
2
3SELECT DISTINCT ?actor WHERE {
4  ex:Nolan      ex:directed ?nolanMovie .   # 諾蘭執導的電影
5  ?actor        ex:actedIn  ?nolanMovie .   # 在這些電影演出的演員
6  ?actor        ex:actedIn  ?marvelMovie .  # 這些演員也演出的電影
7  ?marvelMovie  ex:partOf   ex:MarvelUniverse .  # 而那是漫威電影
8}

對比一下 SQL 的版本，你會立刻感受到差異：

1SELECT DISTINCT a.name
2FROM directors d
3JOIN movies m1        ON m1.director_id = d.id
4JOIN cast c1          ON c1.movie_id = m1.id
5JOIN actors a         ON a.id = c1.actor_id
6JOIN cast c2          ON c2.actor_id = a.id
7JOIN movies m2        ON m2.id = c2.movie_id
8JOIN franchises f     ON f.id = m2.franchise_id
9WHERE d.name = 'Nolan' AND f.name = 'Marvel';

SQL 需要七次 JOIN 來「重建」關係；SPARQL（與後面會看到的 Cypher）則是直接描述圖上的「路徑模式」。當關係跳數越多，這個差距越明顯——這正是知識圖譜的核心價值。

六、發展簡史與真實世界的知識圖譜

幾個你可能天天接觸卻沒意識到的知識圖譜：

• 搜尋引擎知識面板：你搜尋一位名人，右側跳出生日、作品、關係人物的卡片，背後就是 5 億以上實體的知識圖譜。
• Wikidata / DBpedia：社群維護的開放知識庫，本系列後面會直接拿來查詢練習。
• 電商商品圖譜：把商品、屬性、分類、評論連成網，用來做「買了這個的人也買了」。
• 金融知識圖譜：把公司、股東、交易、新聞連起來，做 KYC 合規與洗錢偵測（AML）。
• 資安 MITRE ATT&CK：把攻擊者的戰術、技術、流程系統化成圖。

七、知識圖譜的典型應用領域

┌────────────────────────────────────────────────────────────────┐
│                      知識圖譜應用全景                              │
├──────────────┬───────────────────────────────────────────────────┤
│  搜尋與問答   │  知識面板、語意搜尋、智慧助理（Siri/Alexa）          │
│  推薦系統     │  商品/內容圖譜、跨品類推薦、冷啟動緩解               │
│  金融風控     │  KYC、AML、關聯交易偵測、企業關係穿透               │
│  生醫醫療     │  疾病-症狀-藥物關係、輔助診斷、藥物交互作用           │
│  供應鏈       │  溯源、斷鏈風險分析、零件依賴追蹤                   │
│  資安         │  攻擊鏈建模、威脅情報關聯（MITRE ATT&CK）           │
│  企業知識管理 │  打通各部門資料孤島、員工-專案-技能圖譜              │
│  LLM 增強     │  GraphRAG、多跳推理、降低幻覺（Part 4 詳述）         │
└──────────────┴───────────────────────────────────────────────────┘

八、面試／實務常被問到的觀念釐清

Q：知識圖譜和圖資料庫（Graph Database）是同一回事嗎？

不是。圖資料庫是儲存技術（Neo4j、Neptune）；知識圖譜是知識的組織方式，強調語意與本體。你可以用圖資料庫實作知識圖譜，但也可以用 RDF triplestore，甚至在關聯式資料庫上做「虛擬知識圖譜」。圖資料庫是手段，知識圖譜是目的。

Q：知識圖譜和向量資料庫（Vector DB）誰會取代誰？

兩者互補，不是取代關係。向量資料庫擅長「語意相似」的模糊檢索（找出意思相近的段落）；知識圖譜擅長「精確關係」的結構化推理（A 跟 B 是什麼關係）。Part 3 會深入比較，Part 4 會展示兩者如何在 LLM 系統中協作。

Q：本體（Ontology）和 Schema 有什麼不同？

關聯式 schema 主要約束「資料的格式」（欄位型別、外鍵）；本體不只約束格式，還編碼「邏輯規則」（傳遞性、互逆、等價），讓系統能推理出新事實。本體 ⊃ schema。

九、本篇小結與下一步

這篇我們建立了知識圖譜的核心心智模型：

1. 三元組（主-謂-賓）是原子單位，疊起來就成了知識網。
2. 兩大流派：RDF（語意網路標準、強推理）與屬性圖（工程友善、即時查詢）。
3. 本體是讓圖能「推理」的 schema 層，這是它區別於普通關係圖的關鍵。
4. SPARQL / Cypher 讓多跳關係查詢變得直觀，這是相對 SQL 多重 JOIN 的核心優勢。

下一篇（Part 2），我們會捲起袖子，從一段純文字開始，經過 NER（命名實體辨識）→ 關係抽取 → 寫入 Neo4j，親手建出第一個可查詢的知識圖譜，並用 Cypher 把本篇開頭的電影問題跑起來。

系列導航

→ Part 2：從零建構知識圖譜（NER、關係抽取、Neo4j）

本文為「Knowledge Graph 知識圖譜」系列第 1 篇，共 5 篇。系列從核心概念出發，一路帶到用 LLM 自動建構知識圖譜並做問答的完整實作。