從 Protégé 到 Neo4j GraphRAG：把 OWL 本體變成 AI 可用的知識圖譜

Vishalmysore 寫了一篇實戰文章，講解 Protégé→Neo4j→GraphRAG 的過程，以下是該篇文章摘要：

企業要讓 AI 回答複雜問題，關鍵往往在於知識是否已被結構化到機器能推理、檢索與追溯的程度。一項以 Protégé、Neo4j 與 Qdrant 為基礎的做法，正把 OWL 本體轉換成可操作的知識圖譜，讓大型語言模型能依據明確的領域關係回答資安問題。

以資安領域為例，開發者可以在 Protégé 中以 OWL/RDF 定義一個本體：

WannaCry 勒索軟體利用 CVE-2023-1234 漏洞、APT28 針對企業資產發動攻擊、SQL injection 攻擊來自特定威脅行為者，而 Web 應用程式則由 WAF 與防火牆保護。

這些內容若只存在文件或試算表中，人可以閱讀，系統卻難以直接推理；一旦以 OWL/RDF 正式定義，它們就成為機器可計算的知識。

這套方法要解決的問題很具體：讓大型語言模型回答「哪些惡意軟體利用了我們最關鍵的漏洞，又該如何緩解？」這類跨實體、跨關係的問題，同時保留答案的精確性、可追溯性與實際部署價值。

完整本體可在這裡檢視：
https://github.com/vishalmysore/graphrag/blob/main/graphrag/ontologies/cybersecurity-threat.owl

Neo4j 是一種 Labeled Property Graph（LPG）資料庫。它的節點與關係都是一等公民，可以帶標籤、方向與豐富屬性，因此適合作為本體驅動 GraphRAG 系統的執行層。

把本體載入 Protégé

使用者先在 Protégé 載入 OWL 本體，載入後，可直接透過 Protégé 的外掛，把本體匯出至 Neo4j AuraDB 雲端環境。匯出完成後，系統會顯示已建立的節點、類別與匯出項目數量。

接著登入 Neo4j 雲端主控台，就能直接檢視轉換後的圖譜。這一步的價值很直接：原本存在 Protégé 裡的語意結構，變成可以在圖資料庫中瀏覽、查詢與擴充的運行時資料。

兩種知識表示法

把本體轉成知識圖譜，是將兩種互補的知識表示法接起來：一種是 Protégé/OWL 的語意網模型，另一種是 Neo4j/Cypher 的 Labeled Property Graph。

OWL/RDF：正式的領域藍圖

本體是對某個知識領域的正式、明確規範，作用類似整個領域的 schema 或藍圖。

它關注形式語意、推理與一致性，也就是根據邏輯規則，判斷哪些事實必須成立。RDF 以三元組表示知識，結構為 Subject、Predicate、Object。

Class 定義實體類型，例如 Threat、Malware。
Object Property 定義實體之間的關係，例如 exploits、targets。
Datatype Property 定義實體屬性，例如 cveID、severity。

它的強項在於邏輯推理與資料一致性。透過 OWL reasoner 如 HermiT，系統可以推論某個 Ransomware 實例同時也是 Threat 實例，也能依規則檢查資料是否符合領域限制。

Neo4j LPG：可操作的資料結構

Neo4j 的知識圖譜採用 Labeled Property Graph 模型，重點放在高效儲存、查詢與遍歷大量互相連結的真實資料。

它由四個核心元素組成：

Node 代表實體，例如特定伺服器或特定惡意軟體實例。
Label 用來分類節點，例如 :Server、:Malware；一個節點可以有多個標籤。
Relationship 連接節點，而且具有方向，例如 [:TARGETS]。
Property 以 key-value 形式，同時存在於節點與關係上。

它的強項是快速路徑搜尋、模式比對與圖演算法。透過 Cypher 的 MATCH 與 RETURN，使用者能迅速找出特定關係模式，也能套用 PageRank 一類的圖演算法。

本體如何轉成圖譜

轉換的核心，是把 OWL 的形式語意元件，對應到 LPG 的結構元件。

以本體中的關係為例：

textThreat - Exploits -> Vulnerability

在 Neo4j 中，它會被具體化成：

一個 Threat 節點，例如標籤為 :Ransomware。
一條由 Threat 指向 Vulnerability 的關係，類型為 [:EXPLOITS]。
一個 Vulnerability 節點，例如標籤為 :ZeroDayVulnerability。

對應的 Cypher 查詢如下：

textMATCH (t:Threat)-[:EXPLOITS]->(v:Vulnerability)
RETURN t.label, v.cveID

這個查詢能找出所有正在利用漏洞的威脅，並回傳威脅名稱與漏洞編號。對資安團隊而言，這已經是一個可操作的風險檢視，而不只是文件裡的靜態分類。

兩種模型的互補價值

這套做法的價值，在於把本體的邏輯嚴謹性，與 LPG 的查詢效率結合起來。

本體負責定義領域規則。例如，一個 Vulnerability 必須具備 CVE ID；這類規則能提高資料品質，也讓不同來源的資料有共同語意。Neo4j 則負責儲存與查詢大量實際資料，並以圖的連結關係支援快速遍歷。

LPG 的 schema 具有彈性，適合快速接入不完整、持續變動的資料。本體則可作為上層的語意規範，用來驗證與整理這些資料。兩者搭配後，團隊能兼顧接入速度與資料治理。

另一個關鍵是推論。開發者可以先在本體中定義規則，例如依 CVSS 分數判斷漏洞是否屬於高風險；OWL reasoner 推論出的新事實，可以寫回 Neo4j 圖譜，成為新的節點或關係。圖譜因此會隨著推理結果變得更完整，也更適合被查詢。

這正是 GraphRAG 的基礎。當 LLM 需要回答複雜問題時，圖譜能提供明確、可追溯的知識脈絡，降低模型憑空生成答案的風險，也讓回答能回到具體的漏洞、威脅與防護措施。

適用情境與判斷標準

這套架構適合的場景，是知識之間有明確關係、答案需要跨多個實體推理，而且使用者必須能追溯答案來源的領域。資安、供應鏈、法規合規、醫療知識與企業資產管理，都符合這類條件。

組織若正在評估是否採用，應先回答三個問題：

領域是否已有可明確定義的實體、關係與規則？
使用者的問題是否經常需要跨越多層關係，例如從威脅、漏洞、資產一路追到防護措施？
組織是否需要在 LLM 回答之外，保留可驗證的資料來源與推理路徑？

若三個答案都是肯定的，OWL 本體加上 Neo4j 圖譜，會比把所有資料塞進向量資料庫更值得投入。若資料主要為非結構化文件，而且尚未有穩定的領域模型，先建立本體與圖譜可能反而增加前期成本；此時應從高價值、高重複性的查詢場景開始，逐步驗證價值。

GraphRAG 的競爭力，來自圖譜是否能忠實反映業務關係，並讓 LLM 的回答可以被檢查。模型會持續進步，但缺乏結構化知識與可追溯性的 AI 應用，仍會在企業關鍵決策場景中遇到信任瓶頸。