跳轉到

RAG 中的知識圖譜：從檢索到推理

文章資訊

作者：Chuan Zhang　　日期：2026-06-13

原文標題：Knowledge Graph in RAG: From Retrieval to Reasoning

Medium 原連結：https://chuan-zhang.medium.com/knowledge-graph-in-rag-from-retrieval-to-reasoning-3dace3a345aa

🎧 摘要語音

📝 重點摘要

TL;DR

知識圖譜將 RAG 從「文字相似檢索」升級為「結構化關係推理」。

核心問題

傳統 RAG 把資訊切成孤立文字塊檢索，能找到「相關」但無法表達實體之間的「關係」。面對多跳（multi-hop）、比較型、帶條件約束的問題時，模型被迫在生成時從零散文字推斷關聯，容易遺漏、混淆或產生幻覺。

關鍵發現 / 結論

  • 傳統 RAG 的核心缺陷：retrieves relevance, but does not model relationships（檢索相關性而非關係）。
  • 知識圖譜由 節點（實體）+ 邊（關係）+ 屬性 構成，把隱含關係轉為顯式結構，可在生成前先 filter／traverse／rank 候選答案。
  • KG-RAG 的關鍵差異在於中間的 traversal（圖譜遍歷） 步驟，在醫療、法律、基礎設施等高信任領域尤其重要。
  • 最難的環節不是圖查詢，而是 entity resolution（實體解析）——如 MS 可指多發性硬化症／微軟／質譜，識別不良會讓圖譜噪音化。
  • 本文為兩篇系列首篇，屬概念性介紹，無實證 benchmark 數據；實作示範（Neo4j + Cypher + 媒體供應鏈資料集）留在續篇。

方法亮點

  • 五層架構：資料攝取 → 資訊抽取 → 圖譜建構儲存 → 混合檢索 → LLM 合成與解釋。
  • 四種檢索模式：Graph-first、Vector-first 再以圖譜精修、並行混合、以及把圖譜當作 agent 的記憶／控制層。
  • 強調 source attribution（來源溯源），每個節點/關係應連結文件 ID、段落、信賴分數以利稽核與可解釋性。
  • Query understanding 採混合策略：LLM 產生查詢計畫、確定性程式碼驗證約束。

對我的研究有用嗎？

作為入門級全景梳理頗實用：清楚界定 vector RAG 與 KG-RAG 的分工、整理了四種混合檢索模式與五層 pipeline，可作為設計檢索架構的 checklist。實體解析與來源溯源的論述切中 GraphRAG 實務痛點。但概念多、缺乏量化評估與創新方法，對進階研究者參考價值有限。

評語

品質扎實但偏入門科普、無數據佐證，適合速讀建立框架，不值得深讀。

🌐 中英對照

Author: Chuan Zhang 作者：Chuan Zhang Published: 發布日期： Source: https://chuan-zhang.medium.com/knowledge-graph-in-rag-from-retrieval-to-reasoning-3dace3a345aa 來源：https://chuan-zhang.medium.com/knowledge-graph-in-rag-from-retrieval-to-reasoning-3dace3a345aa Fetched: 2026-06-13T00:23:04.154649 擷取時間：2026-06-13T00:23:04.154649

Knowledge Graph in RAG: From Retrieval to Reasoning / RAG 中的知識圖譜：從檢索到推理

Press enter or click to view image in full size

按 Enter 鍵或點擊以檢視完整大小的圖片

In the rapidly evolving landscape of artificial intelligence, Retrieval-Augmented Generation (RAG) has emerged as a powerful paradigm that enhances large language models (LLMs) with external knowledge. Yet, traditional RAG implementations often hit a critical limitation: they retrieve information as isolated text chunks, missing the rich relationships and contextual meaning that give information its true value.

在快速演進的人工智慧 (Artificial Intelligence) 領域中，檢索增強生成 (Retrieval-Augmented Generation, RAG) 已成為一種強大的範式，能藉由外部知識來增強大型語言模型 (Large Language Models, LLMs)。然而，傳統的 RAG 實作往往遭遇一項關鍵限制：它們以孤立的文字區塊 (text chunks) 形式檢索資訊，遺漏了賦予資訊真正價值的豐富關係與脈絡意涵。

Imagine asking an LLM about “the side effects of medications commonly prescribed for migraines.” A standard RAG system might retrieve disconnected paragraphs about migraine drugs and side effects. A Knowledge Graph-enhanced RAG system, however, would understand that Drug A treats Migraine, which Patient Group B frequently experiences, and that Side Effect C is associated with Drug A but not with Alternative Drug D. It doesn’t just retrieve facts — it retrieves understanding.

想像一下，你詢問 LLM「常用於治療偏頭痛之藥物的副作用」。標準的 RAG 系統可能會檢索出一些彼此不相連、關於偏頭痛藥物與副作用的段落。然而，知識圖譜 (Knowledge Graph) 增強的 RAG 系統則會理解：藥物 A 可治療偏頭痛，而病患族群 B 經常罹患偏頭痛，並且副作用 C 與藥物 A 相關、卻不與替代藥物 D 相關。它檢索的不只是事實——而是理解。

Knowledge Graphs provide a structured representation of real-world entities (people, places, concepts, medications) and their interrelationships. When integrated with RAG, they transform retrieval from a simple text-matching problem into a structured reasoning process. This synergy allows AI systems to navigate complex queries, maintain factual consistency, and generate responses that are not just relevant, but truly insightful.

知識圖譜 提供了真實世界實體（人物、地點、概念、藥物）及其相互關係的結構化表示。當與 RAG 整合時，它們將檢索從一個單純的文字比對問題，轉化為一個結構化的推理過程。這種協同作用讓 AI 系統能夠處理複雜的查詢、維持事實一致性，並產生不僅相關、更具真正洞見的回應。

In this article — the first in a two-part series — we’ll explore how Knowledge Graphs move RAG beyond simple retrieval to intelligent reasoning. You’ll learn how to structure knowledge, connect entities meaningfully, and implement a Knowledge Graph-enhanced RAG system that delivers more accurate, context-aware, and explainable AI responses. Whether you’re building a healthcare assistant, a technical support system, or a research analysis tool, combining Knowledge Graphs with RAG provides the architectural foundation for AI that truly understands.

在本文中——這是兩篇系列文章的第一篇——我們將探討知識圖譜如何讓 RAG 超越單純的檢索，邁向智慧推理。你將學會如何建構知識結構、有意義地連結實體，並實作一套 知識圖譜增強的 RAG 系統，以提供更準確、具脈絡感知且可解釋的 AI 回應。無論你正在建構醫療助理、技術支援系統，或研究分析工具，將知識圖譜與 RAG 結合，都能為真正具有理解能力的 AI 提供架構基礎。

The companion article, Knowledge Graphs in RAG: A Realistic Demo with Neo4j, walks through these same ideas with a concrete implementation: a synthetic media supply-chain dataset loaded into Neo4j, real Cypher queries, and a worked example of passing graph-retrieved context to an LLM.

姊妹篇文章 Knowledge Graphs in RAG: A Realistic Demo with Neo4j（《RAG 中的知識圖譜：以 Neo4j 進行的實際示範》）以具體實作貫穿這些相同的概念：一個載入 Neo4j 的合成 媒體供應鏈 (media supply-chain) 資料集、真實的 Cypher 查詢，以及一個將圖譜檢索得到的脈絡傳遞給 LLM 的實作範例。

Why Traditional RAG Starts to Break Down / 為何傳統 RAG 開始失效

Traditional RAG is powerful because it is simple. Documents are split into chunks and stored in a retrieval system. At query time, the system retrieves the most relevant passages using one or more strategies: keyword search (such as BM25) to match exact terms, semantic search using vector embeddings to capture meaning, hybrid search that combines both sparse and dense signals, or metadata filtering to scope results by date, type, or other attributes. This works well when the answer is contained in one or two relevant chunks and when these retrieval strategies are enough to surface the right context.

傳統 RAG 之所以強大，是因為它簡單。文件被切分成區塊並儲存於檢索系統中。在查詢時，系統會使用一種或多種策略檢索出最相關的段落：關鍵字搜尋 (keyword search)（例如 BM25）以比對精確詞彙、使用 向量嵌入 (vector embeddings) 的 語意搜尋 (semantic search) 以捕捉語意、結合稀疏與稠密訊號的混合搜尋 (hybrid search)，或是 中繼資料過濾 (metadata filtering) 以依日期、類型或其他屬性界定結果範圍。當答案包含在一兩個相關區塊中、且這些檢索策略足以浮現正確脈絡時，這種做法運作良好。

But many real-world questions are not that simple.

但許多真實世界的問題並沒有那麼簡單。

Users often ask multi-hop questions, where the answer depends on joining several facts together. They ask comparative questions, where the system must distinguish between similar entities. They ask constrained questions, where one condition narrows another. In these cases, chunk retrieval alone can struggle because the retrieval unit is still just a fragment of text.

使用者經常提出多跳 (multi-hop) 問題，其答案取決於將多個事實串連在一起。他們會提出比較性問題，此時系統必須區分相似的實體。他們也會提出帶有約束條件的問題，其中一個條件會縮限另一個條件。在這些情況下，僅靠區塊檢索可能難以應付，因為檢索的單位仍只是一段文字的片段。

Consider a few examples:

請思考以下幾個例子：

  • “Which vendors provide encryption services for systems handling customer billing data?”

  • 「哪些供應商為處理客戶帳務資料的系統提供加密服務？」

  • “Which researchers worked on transformer compression methods after publishing work on model distillation?”

  • 「哪些研究人員在發表模型蒸餾 (model distillation) 的研究之後，投入了 transformer 壓縮方法的工作？」

  • “Which migraine medications are effective for adults with hypertension but have a lower risk of drowsiness?”

  • 「哪些偏頭痛藥物對患有高血壓的成人有效，但引起嗜睡的風險較低？」

A vector retriever may return useful passages for each of these questions, but it does not inherently know how the entities are connected. It does not explicitly represent that a vendor supports a product, that a product processes billing data, or that a medication is contraindicated for a certain patient group. The system is forced to infer relationships from scattered text at answer time, which increases the chance of omission, confusion, or hallucination.

向量檢索器 (vector retriever) 可能會為這些問題分別回傳有用的段落，但它本質上並不知道這些實體之間是如何連結的。它不會明確地表示某供應商支援某產品、某產品處理帳務資料，或某藥物對某特定病患族群為禁忌用藥。系統被迫在產生答案時，從零散的文字中推論關係，這增加了遺漏、混淆或幻覺 (hallucination) 的機會。

This is the core limitation: traditional RAG retrieves relevance, but it does not naturally model relationships.

這正是 核心限制：傳統 RAG 檢索的是相關性，卻無法自然地對關係進行建模。

What a Knowledge Graph Adds / 知識圖譜帶來什麼

A Knowledge Graph addresses this limitation by turning implicit relationships into explicit structure.

知識圖譜透過將隱含的關係轉化為明確的結構，來解決這項限制。

At a high level, a Knowledge Graph consists of:

從高層次來看，知識圖譜由以下部分構成：

  • Nodes, which represent entities such as medications, symptoms, products, people, papers, or companies.

  • 節點 (Nodes)，代表 實體 (entities)，例如 藥物、症狀、產品、人物、論文 或 公司。

  • Edges, which represent relationships such as treats, causes, authored, depends_on, located_in, or compatible_with.

  • 邊 (Edges)，代表 關係 (relationships)，例如 治療 (treats)、導致 (causes)、撰寫 (authored)、依賴於 (depends_on)、位於 (located_in) 或 相容於 (compatible_with)。

  • Properties, which store attributes on nodes or edges, such as dosage, date, severity, confidence score, or source reference.

  • 屬性 (Properties)，用以儲存 節點或邊上的屬性，例如 劑量、日期、嚴重程度、信賴分數 (confidence score) 或 來源參照。

Instead of storing knowledge only as prose, a graph stores knowledge as connected facts. It means the retrieval system can answer not just “what text looks similar to this question?” but also “what entities satisfy these constraints, and how are they connected?”

圖譜不只是以散文形式儲存知識，而是以彼此連結的事實儲存知識。這意味著檢索系統不僅能回答「哪段文字看起來與這個問題相似？」，還能回答「哪些實體滿足這些約束條件，而它們之間又是如何連結的？」

This shift matters because many important questions are structural in nature. They depend less on wording and more on relationships. For example, in a healthcare graph, the following facts might exist:

這個轉變之所以重要，是因為許多重要問題本質上是結構性的。它們較不取決於用詞，而更取決於關係。舉例來說，在一個醫療圖譜中，可能存在以下事實：

  • Migraine is treated by Sumatriptan

  • 偏頭痛 (Migraine) 由 舒馬曲坦 (Sumatriptan) 治療

  • Sumatriptan may cause Drowsiness

  • 舒馬曲坦 (Sumatriptan) 可能導致 嗜睡 (Drowsiness)

  • Sumatriptan is not recommended for Patient with uncontrolled hypertension

  • 舒馬曲坦 (Sumatriptan) 不建議用於 血壓控制不良的病患 (Patient with uncontrolled hypertension)

  • Naproxen is an alternative treatment for Migraine

  • 萘普生 (Naproxen) 是 偏頭痛 (Migraine) 的替代療法

  • Naproxen has a different side effect profile

  • 萘普生 (Naproxen) 具有不同的副作用特性

With these relationships represented explicitly, the retrieval stage can filter, traverse, and rank candidate answers more intelligently before the LLM ever starts generating text.

當這些關係被明確表示後，檢索階段就能在 LLM 開始產生文字之前，更智慧地對候選答案進行 過濾、遍歷 (traverse) 與 排序。

This shift also changes how retrieval behaves at runtime. In a graph-aware pipeline, retrieval begins by identifying entities in the user question, resolves them to graph nodes, and then expands to neighboring nodes, follows specific edge types, and applies constraints — only then gathering supporting text from documents linked to those nodes. The graph does not replace the LLM. It strengthens the context the LLM receives, giving it a structured representation of relationships rather than asking it to infer connections from loosely related chunks.

這個轉變也改變了檢索在執行階段的行為。在一個具圖譜感知能力的流程 (graph-aware pipeline) 中，檢索會先辨識使用者問題中的實體、將它們解析對應到圖譜節點，接著擴展至鄰近節點、沿著特定的邊類型前進並套用約束條件——直到此時才從連結到這些節點的文件中蒐集支持性文字。圖譜並未取代 LLM，而是強化 LLM 所接收到的脈絡，賦予它關係的結構化表示，而非要求它從鬆散相關的區塊中推論關聯。

Core Architecture of a Knowledge Graph-Enhanced RAG System / 知識圖譜增強 RAG 系統的核心架構

A simple mental model helps frame this: think of KG-RAG as a three-step loop — understand the question, traverse the knowledge structure, and ground the answer in evidence. That middle step, traversal, is what separates it from standard RAG. Instead of jumping directly from question to a similarity search, the system first maps the question onto the relational structure of the graph. This distinction matters most in domains where trust is critical: in medical, legal, or infrastructure settings, relationship errors are often more damaging than simple wording mistakes.

一個簡單的心智模型有助於框定這件事：把 KG-RAG 想成一個三步驟的循環——理解問題、遍歷知識結構，以及 將答案立基於證據之上。中間那一步——遍歷 (traversal)——正是它與標準 RAG 的區別所在。系統不會直接從問題跳到相似度搜尋，而是先將問題對應到圖譜的關係結構上。這項區別在信任至關重要的領域中最為關鍵：在醫療、法律或基礎設施的情境中，關係上的錯誤往往比單純的用詞錯誤更具破壞性。

A practical KG-RAG system usually contains five layers.

一套實用的 KG-RAG 系統通常包含五個層次。

1. Data Ingestion / 1. 資料攝取

The system collects data from documents, databases, APIs, websites, or internal knowledge sources. These sources may contain both structured and unstructured information.

系統會從文件、資料庫、API、網站或內部知識來源蒐集資料。這些來源可能同時包含結構化與非結構化的資訊。

Examples include:

範例包括：

  • PDFs and reports

  • PDF 與報告

  • technical documentation

  • 技術文件

  • support tickets

  • 支援工單

  • research papers

  • 研究論文

  • database tables

  • 資料庫表格

  • policy documents

  • 政策文件

  • knowledge base articles

  • 知識庫文章

2. Information Extraction / 2. 資訊抽取

Next, the system identifies entities and relationships from the raw data.

接著，系統會從原始資料中辨識出 實體 (entities) 與 關係 (relationships)。

This can be done using:

這可以透過以下方式完成：

  • rule-based extraction

  • 基於規則的抽取

  • named entity recognition models

  • 命名實體辨識 (Named Entity Recognition) 模型

  • relation extraction models

  • 關係抽取 (relation extraction) 模型

  • LLM-based structured extraction

  • 基於 LLM 的結構化抽取

  • existing metadata from upstream systems

  • 來自上游系統的既有中繼資料

At this stage, the goal is to convert raw information into graph-ready facts.

在這個階段，目標是將原始資訊轉換為適合放入圖譜的事實。

For example, from a sentence like:

舉例來說，從以下這樣的句子：

Sumatriptan is commonly prescribed for acute migraine attacks but should be used cautiously in patients with cardiovascular disease.

舒馬曲坦 (Sumatriptan) 常被開立用於急性偏頭痛發作，但在患有心血管疾病的病患身上應謹慎使用。

The system might extract:

系統可能會抽取出：

  • Entity: Sumatriptan as Drug

  • 實體：舒馬曲坦 (Sumatriptan)，類型為 藥物 (Drug)

  • Entity: Migraine as Condition

  • 實體：偏頭痛 (Migraine)，類型為 病症 (Condition)

  • Entity: Cardiovascular disease as RiskFactor

  • 實體：心血管疾病 (Cardiovascular disease)，類型為 風險因子 (RiskFactor)

  • Relationship: Sumatriptan TREATS Migraine

  • 關係：舒馬曲坦 (Sumatriptan) 治療 (TREATS) 偏頭痛 (Migraine)

  • Relationship: Sumatriptan CAUTION_FOR Cardiovascular disease

  • 關係：舒馬曲坦 (Sumatriptan) 對其需謹慎 (CAUTION_FOR) 心血管疾病 (Cardiovascular disease)

3. Graph Construction and Storage / 3. 圖譜建構與儲存

The extracted entities and relationships are then loaded into a graph store such as Neo4j, Memgraph, Amazon Neptune, or another graph-capable database.

抽取出的 實體 與 關係 接著會被載入到圖譜儲存系統中，例如 Neo4j、Memgraph、Amazon Neptune，或其他具備圖譜能力的資料庫。

A well-designed graph schema is critical. If the schema is too generic, the graph becomes difficult to query meaningfully. If it is too rigid, the graph becomes expensive to evolve.

一套設計良好的圖譜綱要 (graph schema) 至關重要。如果綱要過於通用，圖譜就會難以進行有意義的查詢；如果綱要過於僵化，圖譜的演進成本就會變得高昂。

A practical schema often begins with a small number of high-value entity and relation types, then expands incrementally as the system matures.

一套實用的綱要通常從少數高價值的實體與關係類型開始，然後隨著系統的成熟而逐步擴展。

4. Hybrid Retrieval / 4. 混合檢索

When a user submits a question, the system can combine several retrieval strategies:

當使用者提交問題時，系統可以結合數種檢索策略：

  • entity lookup in the graph

  • 在圖譜中查找實體

  • neighborhood expansion around matched nodes

  • 圍繞已匹配節點的鄰域擴展

  • path search across multiple hops

  • 跨越多跳的路徑搜尋

  • symbolic filtering based on relation types or properties

  • 基於關係類型或屬性的符號式過濾

  • vector retrieval of supporting passages attached to graph nodes

  • 對附加於圖譜節點之支持性段落的向量檢索

This hybrid approach is where KG-RAG becomes especially powerful. The graph narrows the logical search space, while vector search brings back the natural-language evidence needed for grounding.

這種混合方法正是 KG-RAG 特別強大之處。圖譜縮小了邏輯搜尋空間，而向量搜尋則帶回了立基 (grounding) 所需的自然語言證據。

5. LLM Synthesis and Explanation / 5. LLM 綜合與解釋

Finally, the system packages the retrieved graph facts and supporting text into a prompt for the LLM.

最後，系統將檢索到的圖譜事實與支持性文字打包成一個提示 (prompt)，提供給 LLM。

The model’s task is no longer to search blindly. Instead, it synthesizes an answer from curated evidence. This improves factual consistency and also makes the answer easier to explain. In some systems, the final response can even cite the traversed graph path or list the entities that led to the conclusion.

模型的任務不再是盲目地搜尋，而是從經過精心整理的證據中綜合出一個答案。這提升了事實一致性，也使答案更易於解釋。在某些系統中，最終的回應甚至能引用所遍歷的圖譜路徑，或列出導向該結論的實體。

Example: How the Same Query Behaves Differently / 範例：同一查詢如何表現出不同結果

Let us compare how a traditional RAG system and a KG-RAG system might respond to the same question.

讓我們比較 傳統 RAG 系統 與 KG-RAG 系統 對同一問題可能會如何回應。

User query:

使用者查詢：

Which migraine medications are commonly used for acute treatment and have fewer sedating side effects than some alternatives?

哪些偏頭痛藥物常用於急性治療，且其鎮靜性副作用比某些替代藥物更少？

Standard RAG approach / 標準 RAG 做法

A standard RAG pipeline may retrieve chunks using keyword search, semantic search, or hybrid scoring. It might surface:

標準 RAG 流程可能會使用 關鍵字搜尋、語意搜尋 或 混合評分 (hybrid scoring) 來檢索區塊。它可能浮現出：

  • a paragraph about acute migraine treatment

  • 一段關於急性偏頭痛治療的段落

  • a separate paragraph about drowsiness side effects

  • 另一段關於嗜睡副作用的段落

  • a section mentioning multiple drugs with partial overlap

  • 一段提及多種藥物、且彼此部分重疊的章節

Even with good retrieval, the LLM must then combine those chunks into a final answer without any explicit representation of how the entities are connected. The reasoning remains implicit and fragile. If the retrieved chunks are incomplete, redundant, or slightly off-topic, the answer quality drops quickly — regardless of the retrieval strategy used.

即使檢索效果良好，LLM 仍必須在缺乏任何明確的實體連結表示的情況下，將這些區塊組合成最終答案。推理過程依舊是隱含且脆弱的。如果檢索到的區塊不完整、冗餘，或略微偏離主題，答案品質就會迅速下降——無論使用哪種檢索策略皆然。

KG-RAG approach / KG-RAG 做法

A Knowledge Graph-enhanced pipeline can:

知識圖譜增強的流程可以：

  • identify migraine, acute treatment, and sedating side effects as important concepts

  • 將 偏頭痛 (migraine)、 急性治療 (acute treatment) 與 鎮靜性副作用 (sedating side effects) 辨識為重要概念

  • retrieve drugs connected to Migraine through TREATS

  • 檢索透過 治療 (TREATS) 關係與 偏頭痛 (Migraine) 相連的藥物

  • filter drugs connected to AcuteMigraine or tagged for acute use

  • 過濾出與 急性偏頭痛 (AcuteMigraine) 相連、或被標記為急性使用的藥物

  • compare linked side effect profiles

  • 比較相連的副作用特性

  • gather the source passages that support those graph facts

  • 蒐集支持這些圖譜事實的來源段落

The final answer is built on structured retrieval rather than on chunk coincidence.

最終答案建立在結構化檢索之上，而非建立在區塊的巧合之上。

This is the practical value of Knowledge Graphs in RAG: better candidate selection before generation.

這正是知識圖譜在 RAG 中的實用價值：在生成之前進行更佳的候選選擇。

Why Explainability Improves / 為何可解釋性會提升

One major advantage of Knowledge Graphs in RAG is explainability.

知識圖譜在 RAG 中的一大優勢便是 可解釋性 (explainability)。

When the system retrieves only chunks, it can be difficult to explain why a particular answer was chosen beyond saying that the text looked similar. But when the system traverses a graph, it can expose the logic of that traversal.

當系統只檢索區塊時，除了說「文字看起來相似」之外，往往難以解釋為何選擇了某個特定答案。但當系統遍歷圖譜時，它能夠揭示該次遍歷的邏輯。

For example, a system might explain:

舉例來說，系統可能會解釋：

  • Sumatriptan was retrieved because it has a TREATS relationship to Migraine

  • 舒馬曲坦 (Sumatriptan) 之所以被檢索出來，是因為它與 偏頭痛 (Migraine) 之間存在 治療 (TREATS) 關係

  • it was flagged for caution due to a CAUTION_FOR relationship with Cardiovascular disease

  • 它因與 心血管疾病 (Cardiovascular disease) 之間存在 需謹慎 (CAUTION_FOR) 關係而被標記為應謹慎使用

  • Naproxen was retrieved as an ALTERNATIVE_TO candidate

  • 萘普生 (Naproxen) 作為 替代藥物 (ALTERNATIVE_TO) 候選而被檢索出來

  • both were supported by passages extracted from specific clinical guidance documents

  • 兩者都有從特定臨床指引文件中抽取出的段落作為支持

This kind of reasoning trace is highly valuable in professional settings. It builds trust, helps debug retrieval behavior, and gives users a clearer sense of why the answer looks the way it does.

這種推理軌跡 (reasoning trace) 在專業情境中極具價值。它能建立信任、有助於除錯檢索行為，並讓使用者更清楚地理解答案為何呈現出這樣的面貌。

Designing the Graph for Retrieval, Not for Decoration / 為檢索而非裝飾來設計圖譜

One common mistake is to build a graph that looks impressive visually but does not actually improve retrieval.

一個常見的錯誤，是建構一個視覺上令人印象深刻、卻實際上無助於改善檢索的圖譜。

A useful Knowledge Graph for RAG is not just a diagram. It is an operational retrieval layer.

一個對 RAG 有用的知識圖譜，不只是一張圖示，而是一個可運作的檢索層 (operational retrieval layer)。

That means every node type, edge type, and property should answer a practical question such as:

這意味著每一種 節點類型、邊類型 與 屬性，都應該回答一個實際的問題，例如：

  • Will this help disambiguate user intent?

  • 這是否有助於釐清使用者意圖的歧義？

  • Will this help constrain retrieval?

  • 這是否有助於約束檢索範圍？

  • Will this help explain the final answer?

  • 這是否有助於解釋最終答案？

  • Will this help connect evidence across documents?

  • 這是否有助於跨文件連結證據？

If the answer is no, the graph element may not be worth modeling. A good schema usually emphasizes:

如果答案是否定的，那麼這個圖譜元素可能就不值得建模。一套好的綱要通常強調：

  • stable entity identity

  • 穩定的實體身分

  • meaningful relationship types

  • 有意義的關係類型

  • traceability back to source documents

  • 可回溯至來源文件的可追溯性

  • properties that support filtering and ranking

  • 支援過濾與排序的屬性

  • a balance between expressiveness and maintainability

  • 表達能力與可維護性之間的平衡

For example, in a research assistant system, it may be more useful to model:

舉例來說，在一個研究助理系統中，建模以下項目可能更為有用：

  • Paper

  • 論文 (Paper)

  • Author

  • 作者 (Author)

  • Method

  • 方法 (Method)

  • Dataset

  • 資料集 (Dataset)

  • Task

  • 任務 (Task)

  • Institution

  • 機構 (Institution)

than to build an overly detailed ontology from the start.

而非一開始就建構一套過於詳盡的本體論 (ontology)。

Start with the relationships that directly improve the questions users actually ask.

從那些能直接改善使用者實際提問的關係開始著手。

Entity Resolution: The Quietly Difficult Part / 實體解析：默默存在的困難環節

In many implementations, the hardest part of KG-RAG is not graph querying. It is entity resolution.

在許多實作中，KG-RAG 最困難的部分並不是圖譜查詢，而是 實體解析 (entity resolution)。

Real data is messy. The same entity may appear under slightly different names. Multiple entities may share the same label. Abbreviations, aliases, synonyms, version names, and spelling variants can all fragment the graph.

真實資料是雜亂的。同一個實體可能以略微不同的名稱出現；多個實體可能共用同一個標籤。縮寫、別名、同義詞、版本名稱與拼寫變體，都可能使圖譜碎片化。

For example:

舉例來說：

  • MS might mean multiple sclerosis, Microsoft, or mass spectrometry.

  • MS 可能指多發性硬化症 (multiple sclerosis)、微軟 (Microsoft)，或 質譜法 (mass spectrometry)。

  • GPT-4 Turbo and gpt4-turbo may refer to the same model.

  • GPT-4 Turbo 與 gpt4-turbo 可能指的是同一個模型。

  • Dr. Smith may refer to several different people.

  • Dr. Smith 可能指涉好幾個不同的人。

If entity resolution is weak, the graph becomes noisy and retrieval quality declines.

如果實體解析很薄弱，圖譜就會變得充滿雜訊，檢索品質也會隨之下降。

This is why many successful systems treat entity normalization as a first-class concern. They invest in canonical IDs, alias tables, metadata enrichment, and confidence-aware merging strategies.

這正是為何許多成功的系統將 實體正規化 (entity normalization) 視為頭等重要的考量。它們投入心力於正規識別碼 (canonical IDs)、別名表、中繼資料增益，以及具信賴感知的合併策略。

A graph is only as useful as the identity quality of its nodes.

一個圖譜的有用程度，取決於其節點的身分品質。

The Role of Source Attribution / 來源歸屬的角色

A strong KG-RAG system should never lose the connection to its original evidence. Graph facts are useful, but without traceabilitythey can become hard to validate. In practice, each extracted node or relationship should ideally be linked to one or more source references, such as:

一個強大的 KG-RAG 系統絕不應失去與其原始證據之間的連結。圖譜事實雖然有用，但若缺乏 可追溯性 (traceability)，它們就會變得難以驗證。在實務上，每一個被抽取出的 節點 或 關係，理想上都應連結到一個或多個來源參照，例如：

  • document IDs

  • 文件識別碼

  • paragraph IDs

  • 段落識別碼

  • URLs

  • 網址 (URL)

  • timestamps

  • 時間戳記

  • extraction confidence scores

  • 抽取信賴分數

This matters for two reasons. First, it keeps the graph auditable. If the system claims that one entity depends on another, the team should be able to inspect where that fact came from. Second, it improves prompting. When the LLM receives both the graph fact and the supporting source passage, it can produce answers that are both more reliable and more explainable.

這有兩個重要原因。第一，它讓圖譜保持可稽核性。如果系統聲稱某個實體依賴於另一個實體，團隊應當能夠檢視該事實的來源出處。第二，它能改善提示 (prompting)。當 LLM 同時接收到圖譜事實與支持性的來源段落時，它就能產生既更可靠、也更可解釋的答案。

Query Understanding in KG-RAG / KG-RAG 中的查詢理解

Once the graph exists, the next challenge is translating a user question into graph actions. This often involves several steps:

一旦圖譜建立完成，下一個挑戰便是將使用者問題轉譯為圖譜上的操作。這通常牽涉到數個步驟：

  • extracting entities mentioned in the query

  • 抽取查詢中所提及的實體

  • identifying the user’s intent

  • 辨識使用者的意圖

  • determining which relation types matter

  • 判定哪些關係類型是重要的

  • inferring filters and constraints

  • 推斷過濾條件與約束條件

  • deciding how many hops are reasonable

  • 決定多少跳數是合理的

  • deciding whether vector search should complement the graph search

  • 決定向量搜尋是否應該補足圖譜搜尋

Some systems perform this with deterministic templates. Others use an LLM to produce a structured query plan. Many production systems combine the two: an LLM proposes the plan, and deterministic code validates or constrains it.

有些系統以 確定性模板 (deterministic templates) 來執行這件事；有些則 使用 LLM 來產生結構化的查詢計畫。許多正式上線的系統則結合兩者：由 LLM 提出計畫，再由 確定性程式碼驗證或約束該計畫。

That hybrid strategy is often safer because it preserves flexibility while reducing the risk of nonsensical queries.

這種混合策略通常較為安全，因為它在保有彈性的同時，降低了產生無意義查詢的風險。

Implementation Patterns That Work Well / 運作良好的實作模式

In practice, there is no single canonical KG-RAG architecture, but several design patterns appear repeatedly.

在實務上，並不存在單一的標準 KG-RAG 架構，但有幾種設計模式反覆出現。

Pattern 1: Graph-first retrieval / 模式一：圖譜優先檢索

Use the graph as the primary retrieval layer. The system first identifies relevant nodes and paths, then pulls supporting text from linked documents.

將圖譜作為主要的檢索層。系統先辨識相關的節點與路徑，然後從相連的文件中抽取支持性文字。

This pattern works well when the domain is highly structured and the questions are relationship-heavy.

當 領域高度結構化且問題以關係為主 時，這種模式運作良好。

Pattern 2: Vector-first, graph-refine / 模式二：向量優先、圖譜精煉

Begin with vector retrieval to get candidate passages, extract entities from those passages, then use the graph to refine, connect, or re-rank the results.

先以向量檢索取得候選段落，從這些段落中抽取實體，然後利用圖譜來精煉、連結或重新排序結果。

This pattern works well when the document corpus is still mostly unstructured but there is some graph structure available.

當 文件語料庫大多仍為非結構化、但已有部分圖譜結構可用 時，這種模式運作良好。

Pattern 3: Parallel hybrid retrieval / 模式三：平行混合檢索

Run vector search and graph search in parallel, then merge the results into a unified context package for the LLM.

平行地執行向量搜尋與圖譜搜尋，然後將結果合併成一個統一的脈絡套件，提供給 LLM。

This is often a pragmatic production design because it balances recall and precision.

這通常是務實的正式上線設計，因為 它在召回率 (recall) 與精確率 (precision) 之間取得平衡。

Pattern 4: Graph as memory and control layer / 模式四：將圖譜作為記憶與控制層

Use the graph not only for retrieval but also for storing system memory, provenance, workflows, or user-specific context.

不僅將圖譜用於檢索，也用以儲存系統記憶、來源出處 (provenance)、工作流程，或特定使用者的脈絡。

This is especially useful in agentic systems, where the graph can help track state, tool outputs, and longer-term context.

這在 代理型系統 (agentic systems) 中特別有用，圖譜在其中能協助追蹤狀態、工具輸出，以及較長期的脈絡。

Minimal Pseudocode for a KG-RAG Pipeline / KG-RAG 流程的最小化虛擬碼

The following pseudocode illustrates the core idea without tying it to a specific framework:

以下的虛擬碼說明了核心概念，且不綁定於任何特定的框架：

question = """  
Which migraine medications are used for acute treatment with   
lower sedation risk?  
"""  

entities = extract_entities(question)  
intent = classify_intent(question)  
constraints = parse_constraints(question)  

matched_nodes = graph.lookup_entities(entities)  
subgraph = graph.expand(  
    nodes=matched_nodes,  
    relations=["TREATS", "HAS_SIDE_EFFECT", "ALTERNATIVE_TO"],  
    constraints=constraints,  
    max_hops=2,  
)  

evidence_docs = vector_store.search(  
    query=question,  
    filters={"entity_ids": subgraph.node_ids},  
    top_k=5,  
)  

prompt_context = build_context(  
    graph_facts=subgraph,  
    evidence=evidence_docs,  
)  

answer = llm.generate(prompt_context, question)

The essential idea is simple:

其核心概念很簡單：

  • use the graph to find the right neighborhood of knowledge

  • 利用圖譜來找出正確的知識鄰域

  • use text retrieval to gather supporting detail

  • 利用文字檢索來蒐集支持性的細節

  • use the LLM to synthesize the final response

  • 利用 LLM 來綜合出最終的回應

When You Should Consider KG-RAG / 何時應考慮使用 KG-RAG

A Knowledge Graph-enhanced RAG system is worth considering when several of the following are true:

當以下數項條件成立時，便值得考慮採用知識圖譜增強的 RAG 系統：

  • your users ask multi-hop questions

  • 你的使用者會提出多跳問題

  • the domain contains stable entities and rich relationships

  • 該領域包含穩定的實體與豐富的關係

  • entity identity matters

  • 實體身分很重要

  • explainability and provenance matter

  • 可解釋性與來源出處很重要

  • users often apply constraints or comparisons

  • 使用者經常套用約束條件或進行比較

  • source documents refer to the same concepts across many files

  • 來源文件在許多檔案中指涉相同的概念

  • you need more than text-based retrieval to retrieve correctly, even when hybrid search and metadata filtering are in play

  • 即使已運用混合搜尋與中繼資料過濾，你仍需要超越基於文字的檢索，才能正確地檢索

If most of these conditions apply, a graph can meaningfully improve retrieval quality. If they do not, standard RAG may still be the better engineering decision.

如果這些條件大多適用，那麼圖譜便能有意義地提升檢索品質。如果並非如此，標準 RAG 可能仍是更好的工程決策。

Common Challenges and Failure Modes / 常見挑戰與失效模式

Knowledge Graph-enhanced RAG is powerful, but it is not free. Several practical challenges appear repeatedly.

知識圖譜增強的 RAG 很強大，但並非毫無代價。有幾項實務上的挑戰反覆出現。

1. Graph construction can be expensive / 1. 圖譜建構可能所費不貲

Extracting high-quality entities and relationships requires time, tooling, and domain knowledge. If the extraction pipeline is weak, the graph becomes unreliable.

抽取高品質的實體與關係需要時間、工具與領域知識。如果抽取流程薄弱，圖譜就會變得不可靠。

2. Schema design can become overcomplicated / 2. 綱要設計可能變得過於複雜

Teams sometimes over-engineer ontologies before validating whether the modeled relationships actually improve retrieval quality.

團隊有時會在驗證所建模的關係是否真能改善檢索品質之前，就過度設計本體論。

3. Query translation is non-trivial / 3. 查詢轉譯並不簡單

Natural language questions do not automatically map cleanly into graph queries. The system needs a robust layer for intent detection and constraint interpretation.

自然語言問題並不會自動乾淨俐落地對應成圖譜查詢。系統需要一個健全的層次來進行意圖偵測與約束條件的詮釋。

4. Not all domains need a graph / 4. 並非所有領域都需要圖譜

If the questions are mostly fact lookup, summarization, or broad semantic search, a graph may add complexity without enough benefit.

如果問題大多是事實查找、摘要，或廣泛的語意搜尋，那麼圖譜可能只會增加複雜度，卻帶來不足的效益。

5. Graphs still need text grounding / 5. 圖譜仍需要文字的立基

A graph alone usually does not contain all the nuance needed for answer generation. The supporting text remains important.

單憑圖譜通常無法涵蓋產生答案所需的所有細微之處。支持性文字依然重要。

In short, Knowledge Graphs should be introduced where they solve a real retrieval problem, not where they merely add architectural novelty.

簡而言之，知識圖譜應當被引入到那些它能解決真實檢索問題的地方，而非僅僅是為了增添架構上的新奇感。

Practical Development Strategy / 務實的開發策略

If you want to implement KG-RAG without overbuilding, a good strategy is to proceed incrementally.

如果你想實作 KG-RAG 卻又不過度建構，一個好的策略是循序漸進地推進。

Step 1: Start with a normal RAG baseline / 步驟一：從一般的 RAG 基線開始

Build a standard RAG system first — this could use keyword search, semantic search, or a hybrid approach with metadata filtering. Measure where it fails.

先建構一套標準的 RAG 系統——這可以使用關鍵字搜尋、語意搜尋，或搭配中繼資料過濾的混合方法。衡量它在哪些地方會失敗。

Step 2: Identify relationship-heavy queries / 步驟二：辨識以關係為主的查詢

Look for the questions that require connections across entities, constraints, or multi-hop reasoning.

找出那些需要跨實體連結、約束條件，或多跳推理的問題。

Step 3: Model only the highest-value entities and edges / 步驟三：只對最高價值的實體與邊進行建模

Do not try to graph everything at once. Model the parts of the domain that improve those failed cases.

不要試圖一次就把所有東西都建成圖譜。只對該領域中能改善那些失敗案例的部分進行建模。

Step 4: Preserve source traceability / 步驟四：保留來源可追溯性

Attach document references to extracted facts so every answer can be grounded.

將文件參照附加到抽取出的事實上，如此一來每個答案都能有所立基。

Step 5: Introduce hybrid retrieval / 步驟五：引入混合檢索

Let graph retrieval and text retrieval reinforce one another rather than forcing one to replace the other.

讓圖譜檢索與文字檢索相互強化，而非強迫其中一者取代另一者。

Step 6: Evaluate with realistic questions / 步驟六：以貼近現實的問題進行評估

Test with real user queries, especially the ones that exposed weaknesses in the baseline system.

以真實的使用者查詢進行測試，尤其是那些暴露出基線系統弱點的查詢。

This iterative approach keeps the system practical and prevents the graph from becoming an isolated artifact with little operational value.

這種迭代式的做法能讓系統保持實用，並避免圖譜淪為一個幾乎不具運作價值的孤立產物。

A Useful Evaluation Mindset / 一種有用的評估心態

When evaluating KG-RAG, do not ask only whether the answer sounds good. Ask whether the retrieval path was better.

在評估 KG-RAG 時，不要只問答案聽起來是否良好，而要問檢索路徑是否更好。

Some useful evaluation questions include:

一些有用的評估問題包括：

  • Did the graph help identify the correct entities?

  • 圖譜是否有助於辨識出正確的實體？

  • Did it reduce irrelevant retrieval?

  • 它是否減少了不相關的檢索？

  • Did it improve multi-hop or constrained reasoning?

  • 它是否改善了多跳或帶約束的推理？

  • Did it improve attribution and explanation?

  • 它是否改善了歸屬與解釋？

  • Did it reduce hallucinations caused by missing connections?

  • 它是否減少了因缺少連結而導致的幻覺？

  • Did the extra complexity produce measurable value?

  • 額外增加的複雜度是否產生了可衡量的價值？

This is important because a graph may improve quality in ways that are not fully visible in a surface-level answer comparison.

這很重要，因為圖譜可能以一些在表面層級答案比較中無法完全顯現的方式來提升品質。

What’s Next / 接下來

The concepts covered here — relational retrieval, hybrid patterns, entity resolution, and schema design — are put into practice in the companion article, Knowledge Graphs in RAG: A Realistic Demo with Neo4j. It walks through a synthetic media supply-chain dataset, shows the full graph schema in Neo4j, demonstrates representative Cypher queries, and illustrates how graph-retrieved facts are packaged into an LLM prompt.

本文所涵蓋的概念——關係式檢索 (relational retrieval)、混合模式、實體解析，以及 綱要設計——都在姊妹篇文章 Knowledge Graphs in RAG: A Realistic Demo with Neo4j 中付諸實踐。該文貫穿一個合成的 媒體供應鏈 資料集，展示 Neo4j 中完整的圖譜綱要、示範具代表性的 Cypher 查詢，並說明圖譜檢索得到的事實如何被打包成一個 LLM 提示。

Final Thoughts / 結語

Knowledge Graphs push RAG from retrieving text toward retrieving meaning. They make entities explicit, relationships navigable, and reasoning paths inspectable. In domains where answers depend on how things are connected rather than merely how they are described, this shift can be transformative.

知識圖譜推動 RAG 從檢索文字邁向檢索意義。它們讓實體變得明確、關係變得可遍歷，推理路徑變得可檢視。在那些答案取決於事物如何彼此連結、而非僅僅取決於它們如何被描述的領域中，這種轉變可能具有變革性的意義。

The most effective KG-RAG systems are not built by replacing everything with a graph. They are built by combining the strengths of structure and language: graphs for relational precision, text retrieval (keyword, semantic, or hybrid) for broad coverage, and LLMs for synthesis and explanation.

最有效的 KG-RAG 系統，並非透過用圖譜取代一切而建構出來。它們是透過結合結構與語言的優勢而建構出來的：以圖譜實現關係上的精確性、以文字檢索（關鍵字、語意或混合）達成廣泛的涵蓋範圍，並以 LLM 進行綜合與解釋。

This combination is what makes Knowledge Graph-enhanced RAG so compelling. It allows us to move beyond isolated chunks and toward systems that can reason across connected knowledge with greater accuracy, transparency, and context-awareness.

正是這種結合，使得知識圖譜增強的 RAG 如此引人入勝。它讓我們得以超越孤立的區塊，邁向能夠跨越彼此連結的知識進行推理、且具備更高準確性、透明度與脈絡感知能力的系統。

As AI applications continue to move into higher-stakes domains, that ability will matter more and more. The future of RAG is not just better retrieval. It is smarter retrieval, grounded in the structure of knowledge itself.

隨著 AI 應用持續邁入風險更高的領域，這種能力將變得愈來愈重要。RAG 的未來不僅僅是更好的檢索，而是更聰明的檢索——立基於知識本身的結構之上。

🔤 關鍵術語

英文 繁中譯名 文章中的脈絡 / 簡短說明
Knowledge Graph (KG) 知識圖譜 以節點與邊結構化表示真實世界實體及其關係的知識表示法
Retrieval-Augmented Generation (RAG) 檢索增強生成 以外部知識強化 LLM 回應的範式，本文核心主題
KG-RAG 知識圖譜增強檢索生成 將知識圖譜整合進 RAG，把檢索從文字比對提升為結構化推理
Large Language Model (LLM) 大型語言模型 在 RAG 流程最後負責綜整證據並生成解釋的模型
Hybrid Retrieval 混合檢索 結合圖譜實體查找、鄰域擴展與向量檢索等多種策略
Vector Embeddings 向量嵌入 語意搜尋的基礎，捕捉文本意義以做相似度比對
Semantic Search 語意搜尋 以向量嵌入按意義檢索而非比對精確字詞
Keyword Search (BM25) 關鍵字搜尋 以 BM25 等方法比對精確詞彙的稀疏檢索
Multi-hop Question 多跳問題 需串接多項事實才能回答的問題，傳統 RAG 易失效之處
Entity Resolution 實體解析 將同一實體的不同名稱／別名統一，KG-RAG 最困難的環節
Entity Normalization 實體正規化 透過正規 ID、別名表與合併策略消除實體碎裂
Named Entity Recognition (NER) 命名實體辨識 資訊抽取階段用來從原始資料辨識實體的模型
Relation Extraction 關係抽取 從文本抽取實體間關係以建構圖譜的技術
Graph Schema 圖譜結構描述 定義節點與關係類型的設計，過於通用或僵化都會降低查詢效益
Neo4j / Cypher Neo4j／Cypher 查詢語言 圖資料庫與其查詢語言，文中示範圖譜儲存與檢索
Neighborhood Expansion 鄰域擴展 從匹配節點向相鄰節點展開以蒐集相關事實
Path Search / Traversal 路徑搜尋／圖遍歷 跨多跳走訪圖譜，是 KG-RAG 區別於標準 RAG 的關鍵步驟
Source Attribution / Traceability 來源歸屬／可追溯性 將每個節點或關係連回原始文件，使圖譜可稽核且可解釋
Explainability 可解釋性 透過暴露遍歷邏輯說明答案來源，建立信任
Hallucination 幻覺 LLM 因缺乏明確關係而從零散文字推論時產生的錯誤資訊
Grounding 落地／證據支撐 以檢索到的原文證據支撐生成答案，提升可靠度