Knowledge Graph 知識圖譜（三）：與關聯式 / 向量 / 文件資料庫的比較

大多數人問「知識圖譜會不會取代資料庫？」 正確答案是：問錯問題了。它們解決的是不同維度的問題。 大多數人看到向量資料庫很紅，就以為知識圖譜過時了。 正確答案是：在 LLM 時代，兩者反而是最佳拍檔（Part 4 詳述）。

接續前文

Part 1 講概念、Part 2 動手建。這一篇要把知識圖譜放到擂台上，和四種常見的資料儲存技術正面比較，幫你建立清楚的選型判斷力。

一、核心問題：四種技術在解什麼問題？

先用一句話定位每種技術的「世界觀」：

┌──────────────────┬──────────────────────────────────────────────┐
│ 關聯式 (RDBMS)    │ 「我有結構化的表格，要保證交易一致性」          │
│ 文件 (Document)   │ 「我有半結構化的 JSON，schema 常變」            │
│ 向量 (Vector DB)  │ 「我要找『意思相近』的東西（語意相似）」        │
│ 知識圖譜 (KG)     │ 「我要表達並推理『實體之間的關係』」            │
└──────────────────┴──────────────────────────────────────────────┘

關鍵洞察：它們優化的維度不同。RDBMS 優化交易一致性、文件庫優化 schema 彈性、向量庫優化語意相似、知識圖譜優化關係推理。問「誰取代誰」是問錯了；該問的是「我這個問題的本質是哪一種」。

二、知識圖譜 vs 關聯式資料庫（RDBMS）

這是最常被拿來比的一組。差異的核心在於：關係是如何被表示的。

為什麼選知識圖譜不選 RDBMS：當你的查詢核心是「關係的關係」—— 多跳路徑、最短路徑、社群偵測、影響力傳播。例如風控要查「這筆交易的對手方，透過幾層人頭帳戶連到黑名單」。

為什麼選 RDBMS 不選知識圖譜：當你的資料天生是表格、需要強交易一致性、大量聚合報表。例如電商的訂單與庫存系統。翻轉條件：JOIN 超過 4～5 層、且這類查詢是高頻核心時，該認真考慮知識圖譜。

下面這個對比讓差異具體化——「找出第三層的合作關係」：

1-- RDBMS：每多一跳就多一次 self-JOIN，效能隨深度指數惡化
2SELECT DISTINCT c3.name
3FROM collab c1
4JOIN collab c2 ON c1.to_id = c2.from_id
5JOIN collab c3 ON c2.to_id = c3.from_id
6WHERE c1.from_id = 42;

// 知識圖譜：深度只是一個數字，語意一目了然
MATCH (start)-[:COLLAB*3]->(c3) WHERE id(start) = 42
RETURN DISTINCT c3.name;

三、知識圖譜 vs 向量資料庫（Vector Database）

這是 LLM 時代最重要的一組比較，也最容易被混淆。

向量資料庫把資料（文字、圖片）轉成高維向量（embedding），查詢時找「距離最近」的向量——也就是語意相似。知識圖譜查的是明確的結構化關係。

向量資料庫：模糊、相似度
  Query: "降低 LLM 幻覺的方法"
    └─▶ 回傳語意最接近的段落（不保證事實正確，無法解釋為何相關）

知識圖譜：精確、可解釋
  Query: ( GraphRAG )──[ 用於 ]──▶( ? )
    └─▶ 回傳明確連到的實體（可追溯路徑，100% 可解釋）

重點不是二選一，而是互補。 向量庫解決「我不知道確切關鍵字，但要找意思相近的內容」；知識圖譜解決「我要精確、可解釋、多跳的關係答案」。在 LLM/RAG 系統中（Part 4），常見的最佳實踐是兩者並用：向量檢索負責召回相關文件，知識圖譜負責結構化推理與事實校驗。

四、知識圖譜 vs 文件資料庫（Document Store）

文件資料庫（MongoDB、Elasticsearch）存半結構化 JSON，schema 彈性高。它和知識圖譜的差異在於：它把關係「巢狀（nest）」進文件，而非連成網。

文件資料庫：關係靠巢狀，跨文件關係難查
  {
    "movie": "Inception",
    "director": { "name": "Nolan" },
    "actors": [ { "name": "DiCaprio" } ]   // 關係埋在這份文件裡
  }
  問題：要查「DiCaprio 還演過哪些片」需掃描所有文件，沒有原生的反向關係

知識圖譜：關係是邊，雙向、可遍歷
  (DiCaprio)-[:ACTED_IN]->(Inception)
  (DiCaprio)-[:ACTED_IN]->(TheRevenant)   // 反向查詢天生支援

簡單原則：資料的「連結性」越高，越偏向知識圖譜；越「自包含」，越偏向文件資料庫。

五、一張總表：四選一決策指南

你的核心查詢是什麼？
│
├─ 「交易一致性 + 大量聚合報表」 ───────────────▶ 關聯式 RDBMS
│
├─ 「彈性 schema 的自包含文件 / 全文檢索」 ──────▶ 文件資料庫
│
├─ 「找語意相近的非結構化內容（給 LLM 用）」 ───▶ 向量資料庫
│
└─ 「多跳關係、路徑、推理、可解釋」 ────────────▶ 知識圖譜

六、圖資料庫之間的比較（實作選型）

決定要用知識圖譜後，下一個問題是「用哪個圖資料庫？」這裡比較幾個主流選項：

選型心法：

• 入門與多數應用 → Neo4j（生態、文件、社群最成熟，本系列採用）
• 已在 AWS 且要 RDF + 屬性圖雙模 → Neptune
• 需要嚴謹 OWL 推理、跨機構語意整合 → Stardog
• 兆級邊、深度圖分析 → TigerGraph

七、混合架構：真實系統怎麼搭

實務上很少只用一種。一個成熟的 LLM 知識系統，常常是這樣的多層架構：

┌─────────────────────────────────────────────────────────────┐
│                         應用 / LLM 層                          │
└───────────────┬───────────────────────────┬──────────────────┘
                │                           │
        ┌───────▼────────┐         ┌────────▼─────────┐
        │  向量資料庫      │         │   知識圖譜         │
        │  語意召回相關段落 │         │  結構化關係+事實校驗 │
        │ (Pinecone/pgvec)│         │     (Neo4j)       │
        └───────┬────────┘         └────────┬─────────┘
                │                           │
        ┌───────▼───────────────────────────▼─────────┐
        │   關聯式 / 文件資料庫（原始事實來源 SoR）        │
        └───────────────────────────────────────────────┘

各司其職：

• 向量庫：把使用者問題模糊召回相關內容。
• 知識圖譜：對召回結果做多跳推理、補充關係、校驗事實。
• RDBMS / 文件庫：作為原始事實來源（System of Record）。

這正是 Part 4 要深入的 GraphRAG 架構雛形。

八、系統效應：用對技術前後對比

以一個「企業合規盡職調查」場景為例，比較「只用 RDBMS」與「導入知識圖譜」：

數字會因系統而異，但方向是穩定的：當「關係」是問題的核心，知識圖譜帶來的是數量級的差異，而非邊際改善。

九、本篇小結與下一步

1. 四種技術優化不同維度：RDBMS（一致性）、文件庫（彈性）、向量庫（相似）、知識圖譜（關係推理）。
2. 知識圖譜 vs RDBMS 的分水嶺是多跳關係查詢。
3. 知識圖譜 vs 向量庫不是取代，是互補：精確可解釋 vs 模糊語意。
4. 成熟系統用混合架構，這正是 GraphRAG 的基礎。

下一篇（Part 4）是整個系列的高潮：知識圖譜 + LLM。我們會講為什麼純向量 RAG 會在多跳問題上失敗、GraphRAG 如何用知識圖譜補足、以及如何用它降低 LLM 幻覺——附完整可跑的程式碼。

系列導航

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

→ Part 4：知識圖譜 + LLM — GraphRAG 與多跳推理

本文為「Knowledge Graph 知識圖譜」系列第 3 篇，共 5 篇。