https://yennj12.js.org/yennj12_blog_V4/tags/knowledge-graph/Recent content in Knowledge Graph on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 29 Jun 2026 13: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）**賦予這些關係可被機器推理的語意。https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part2-construction-zh/Mon, 29 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part2-construction-zh/大多數人以為建知識圖譜就是把資料倒進圖資料庫。 正確答案是：難的不是儲存，是把非結構化文字「抽」成乾淨的三元組。 大多數人忽略實體消歧，於是「蘋果公司」和「蘋果（水果）」變成同一個節點。 正確答案是：消歧與對齊，決定了圖的品質上限。 接續 Part 1 Part 1 我們建立了概念：三元組、本體、RDF 與屬性圖。這一篇要從一段純文字開始，走完整條建構管線（construction pipeline），最後把成果存進 Neo4j、用 Cypher 查詢。 一、核心問題：知識從哪裡來？ 知識圖譜的三元組不會憑空出現。來源大致兩類： 結構化資料：資料庫、CSV、API。相對容易，做欄位映射（mapping）即可。 非結構化資料：文章、新聞、PDF、網頁。佔現實世界 80% 以上的知識，但要先「抽取」。 本篇聚焦最難也最有價值的後者。整條管線如下： ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ 原始文本 │──▶│ 命名實體辨識 │──▶│ 實體消歧/對齊 │──▶│ 關係抽取 │ │ (Raw Text) │ │ (NER) │ │ (Disambig.) │ │ (Relation) │ └──────────────┘ └──────────────┘ └──────────────┘ └──────┬───────┘ │ ┌──────────────┐ ┌──────────────┐ │ │ 圖查詢 │◀──│ 寫入圖資料庫 │◀──────────┘ │ (Cypher) │ │ (Neo4j) │ └──────────────┘ └──────────────┘ 二、Top-Down vs Bottom-Up：兩種建構策略 在動手前，先決定整體策略。這是個影響後續所有工作量的根本選擇。https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part3-comparison-zh/Mon, 29 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part3-comparison-zh/大多數人問「知識圖譜會不會取代資料庫？」 正確答案是：問錯問題了。它們解決的是不同維度的問題。 大多數人看到向量資料庫很紅，就以為知識圖譜過時了。 正確答案是：在 LLM 時代，兩者反而是最佳拍檔（Part 4 詳述）。 接續前文 Part 1 講概念、Part 2 動手建。這一篇要把知識圖譜放到擂台上，和四種常見的資料儲存技術正面比較，幫你建立清楚的選型判斷力。 一、核心問題：四種技術在解什麼問題？ 先用一句話定位每種技術的「世界觀」： ┌──────────────────┬──────────────────────────────────────────────┐ │ 關聯式 (RDBMS) │ 「我有結構化的表格，要保證交易一致性」 │ │ 文件 (Document) │ 「我有半結構化的 JSON，schema 常變」 │ │ 向量 (Vector DB) │ 「我要找『意思相近』的東西（語意相似）」 │ │ 知識圖譜 (KG) │ 「我要表達並推理『實體之間的關係』」 │ └──────────────────┴──────────────────────────────────────────────┘ 關鍵洞察：它們優化的維度不同。RDBMS 優化交易一致性、文件庫優化 schema 彈性、向量庫優化語意相似、知識圖譜優化關係推理。問「誰取代誰」是問錯了；該問的是「我這個問題的本質是哪一種」。 二、知識圖譜 vs 關聯式資料庫（RDBMS） 這是最常被拿來比的一組。差異的核心在於：關係是如何被表示的。 面向 知識圖譜 關聯式資料庫 關係表示 一等公民，直接存在邊上 靠 foreign key + JOIN 隱式重建 多跳查詢 圖遍歷，效能與跳數弱相關 多重 JOIN，跳數越多越慢 Schema 彈性 高，加關係不需 migration 低，改表結構成本高 交易一致性 多數圖庫較弱（部分支援 ACID） 強項，成熟的 ACID 聚合運算 較弱 強（SUM/GROUP BY 等） 成熟度/生態 相對年輕 數十年積累、人人會 SQL 為什麼選知識圖譜不選 RDBMS：當你的查詢核心是「關係的關係」—— 多跳路徑、最短路徑、社群偵測、影響力傳播。例如風控要查「這筆交易的對手方，透過幾層人頭帳戶連到黑名單」。https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part4-llm-graphrag-zh/Mon, 29 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part4-llm-graphrag-zh/大多數人遇到 RAG 答不準，第一反應是換更強的 embedding 模型。 正確答案是：多跳問題的瓶頸不在召回相似度，而在缺少「關係結構」。 大多數人以為知識圖譜和 LLM 是兩個世界。 正確答案是：LLM 負責語言理解，知識圖譜負責事實與推理，合起來才完整。 接續前文 Part 3 我們確立了「知識圖譜與向量庫互補」。這一篇把它落地到 LLM 系統：解釋 GraphRAG 為什麼出現、它如何運作、以及用 LangChain + Neo4j 寫出可跑的程式碼。 一、核心問題：純向量 RAG 在哪裡失敗？ 標準 RAG（Retrieval-Augmented Generation）流程是：把文件切塊（chunk）→ 算 embedding → 存向量庫 → 查詢時找最相似的塊 → 塞進 prompt。這對「事實型單跳問題」很有效，但有兩個致命弱點： 弱點一：多跳推理（multi-hop） 問題：「全面啟動的配樂家，還為哪位導演的哪部片配過樂？」 純向量 RAG 的困境： Query embedding ──▶ 找最相似的塊 │ ▼ 只會召回「提到全面啟動配樂」的段落 但「配樂家 → 其他作品 → 那部片的導演」這條關係鏈 分散在不同文件、不同塊裡，相似度檢索串不起來 ✗ 向量檢索本質是「單跳相似」。它無法沿著「實體 A → 關係 → 實體 B → 關係 → 實體 C」的鏈條走，因為這需要的是結構，不是相似度。https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part5-end-to-end-project-zh/Mon, 29 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part5-end-to-end-project-zh/大多數人學完知識圖譜，卡在「我的文件那麼多，難道要手動建圖？」 正確答案是：在 LLM 時代，抽取交給模型，你只需設計好流程與驗收。 大多數 demo 跑得起來，上線就垮。 正確答案是：把建圖、查詢、校驗拆成可演進的三個階段（POC → MVP → Scale）。 這是系列的最後一塊拼圖 前四篇我們學了概念（Part 1）、建構管線（Part 2）、技術比較（Part 3）、與 LLM 結合（Part 4）。這一篇把它們串成一個端到端、可實際執行的專案： 目標：丟進一批純文字文件 → LLM 自動抽成知識圖譜 → 存進 Neo4j → 用自然語言問答。 一、整體架構：四個階段 ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ ┌──────────────┐ │ 1. 文件載入 │─▶│ 2. LLM 抽取 │─▶│ 3. 寫入 Neo4j │─▶│ 4. GraphRAG │ │ 切塊 │ │ 三元組 + 消歧 │ │ MERGE 去重 │ │ 自然語言問答 │ └─────────────┘ └──────────────┘ └─────────────┘ └──────────────┘ Part 2 Part 2+4 Part 2 Part 4 我們會用：Python、LangChain、langchain-experimental 的 LLMGraphTransformer（把文件直接轉成圖文件）、Neo4j。