https://yennj12.js.org/yennj12_blog_V4/tags/semantic-web/Recent content in Semantic Web on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part1-fundamentals-zh/Mon, 29 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part1-fundamentals-zh/大多數人把資料庫想成一張張表格，於是用 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）**賦予這些關係可被機器推理的語意。