知識圖譜（Knowledge Graph）是用圖結構表示和儲存知識的資料結構，由三個核心元素組成：
節點（Node / Entity）：代表一個具體的實體，可以是人物、地點、事件、概念、產品等。例如：「蘋果公司」「iPhone」「史蒂夫·賈伯斯」「庫比蒂諾」都是節點。
邊（Edge / Relation）：代表兩個節點之間的關係，通常是有方向的。例如：「史蒂夫·賈伯斯 → [創辦] → 蘋果公司」「iPhone → [由...製造] → 蘋果公司」「蘋果公司 → [總部位於] → 庫比蒂諾」。
屬性（Properties）：節點和邊可以有附加的屬性。例如：「蘋果公司」節點的屬性可以包括成立年份（1976）、股票代碼（AAPL）、員工數（16 萬）等。
知識圖譜的核心優勢：它保留了資訊之間的明確語意關係，而不只是儲存文字內容。這讓它特別擅長處理需要「多跳推理」的查詢——如「蘋果公司的創辦人的出生城市是哪裡？」（賈伯斯 → [創辦] → 蘋果 → [創辦人是] → 賈伯斯 → [出生於] → 舊金山），這種推理路徑向量搜尋很難高效完成，但知識圖譜的圖遍歷演算法能輕鬆處理。
知識圖譜在 AI 應用裡怎麼和 Claude 配合？GraphRAG 是什麼？
知識圖譜 + RAG 的組合（GraphRAG）：
標準 RAG 的局限是：它用向量相似度搜尋相關內容，適合「找相似的段落」，但對「找有特定關係的實體」效果較差。例如「列出所有和 A 公司有供應關係的公司，再找出這些公司裡有哪些在 2024 年有法律糾紛」——這個查詢涉及實體關係的多層導航，向量搜尋很難精確完成。
GraphRAG 的架構是把向量搜尋和知識圖譜結合：
實際效果：對需要跨多個文件、追蹤實體關係的複雜查詢，GraphRAG 比純向量 RAG 的準確率有顯著提升。微軟在 2024 年發布的 GraphRAG 研究顯示，在需要全局理解的查詢上，GraphRAG 比標準向量 RAG 高出 30-40% 的答案品質評分。
什麼時候需要知識圖譜：如果你的應用的查詢模式主要是「語意相關」而不是「關係導航」，純向量 RAG 通常夠用。只有當你有大量「A 和 B 之間有什麼關係」「X 的所有相關實體是什麼」這類查詢時，才值得投入知識圖譜的構建成本。
構建知識圖譜的實際工程複雜度是多少？有哪些工具選擇？
構建知識圖譜的工程複雜度明顯高於向量資料庫，主要體現在三個方面：
一：實體和關係的模式設計（Schema Design） 需要提前決定你的知識圖譜裡有哪些實體類型（Person、Company、Product、Event...）和關係類型（created_by、located_in、subsidiary_of、reported_in...），以及每種實體和關係的屬性。這個設計決策會影響後續所有的查詢能力。
二：知識抽取（Knowledge Extraction） 從非結構化文本裡抽取實體和關係是一個複雜的 NLP 問題。目前的選擇：人工標注（最準確但成本最高）；基於規則的抽取（適合格式固定的文件）；用 LLM 輔助抽取（Claude 可以從文本裡提取實體和關係，但需要精心設計的提示詞和後處理邏輯）。
三：圖資料庫的選擇和維護 主要選擇：
對大多數 AI 應用的建議：如果你剛開始做 RAG，先用純向量方案（更簡單、維護成本低）；只有在明確識別到「純向量 RAG 在關係查詢上達不到要求」之後，再評估引入知識圖譜的必要性和成本。
知識圖譜在企業應用裡有哪些最成功的落地案例？什麼行業最有價值？
知識圖譜在幾個特定行業有非常成熟的應用：
金融和風控：用知識圖譜追蹤公司、個人、交易之間的關係，識別隱性的關聯和潛在的風險。例如：識別兩個看似不相關的公司實際上通過多層股權結構相互關聯；追蹤資金流動路徑識別洗錢風險。Google Knowledge Graph 在金融詐騙偵測上的應用是這個領域的先驅。
藥物研發和生物醫學：用知識圖譜表示基因、蛋白質、疾病、藥物之間的複雜關係，支援藥物重定向（Drug Repurposing）和副作用預測。OpenBioLink、Hetionet 等生物醫學知識圖譜已有廣泛使用。
企業知識管理：把散落在文件、郵件、系統裡的業務知識結構化，讓員工能問「這個客戶和哪些供應商有關聯」「這個產品的所有相關合規要求是什麼」這類跨系統的查詢。這也是目前 GraphRAG 落地最多的商業場景。
法律和合規：追蹤法律條文、案例、當事人之間的引用關係和判例影響，支援「找所有引用了 X 判例的後續案件」這類查詢。
對一般開發者的建議：如果你的應用資料領域有豐富的「實體關係」（不只是「相似內容」），而且用戶的查詢模式需要多跳推理，知識圖譜值得認真評估。反之，如果資料主要是文本段落、用戶查詢主要是語意搜尋，向量資料庫更簡單且夠用。
一家科技媒體公司想用 AI 回答讀者的深度問題，如「特斯拉和哪些電池供應商有合作，這些供應商同時還為哪些競爭對手供貨？」這個查詢需要多跳關係導航。
只用向量 RAG 的問題：向量搜尋能找到「特斯拉電池相關的文章」，但很難系統性地追蹤「A 供應 B，B 同時供應 C」這條關係鏈。結果可能是召回了很多相關文章，但最終答案仍然不完整（遺漏了某些供應商，或者找不到他們同時服務的競爭對手）。
加入知識圖譜後：他們從文章裡抽取了「公司」「供應關係」「競爭關係」的知識圖譜，Neo4j 裡有 5,000+ 個公司節點、10,000+ 條關係邊。對這個查詢，系統先從圖裡找到特斯拉的所有供應商（第一跳），再找這些供應商同時服務的其他汽車公司（第二跳），然後把這些關係路徑和向量搜尋召回的相關文章一起傳給 Claude，生成一個有完整關係圖的深度分析回答。
效果：這類多跳關係查詢的答案完整性從向量 RAG 的 60% 提升到 GraphRAG 的 88%（內部評估）。
知識圖譜的核心取捨是「查詢精確度 vs 構建和維護成本」。知識圖譜在關係查詢上的準確度顯著高於向量搜尋，但構建成本（Schema 設計、實體抽取、關係標注）和維護成本（新增實體、更新關係、保持一致性）也顯著高於向量資料庫。向量資料庫只需要「嵌入文本」，相對簡單；知識圖譜需要「理解並結構化知識的關係」，本質上是更複雜的知識工程工作。在決定引入知識圖譜之前，建議先評估：你的應用真的有多少查詢是「關係導航」性質的？如果不到 20%，純向量方案可能已經足夠，知識圖譜的投入不一定 ROI 合理。