本體論、知識圖譜與語意層：讓 AI 停止猜測的架構

文章資訊

作者：Vimal Dwarampudi　　日期：2026-06-21

原文標題：Ontologies, Knowledge Graphs, and a Semantic Layer: The Architecture That Makes AI Stop Guessing

Medium 原連結：https://vimal-dwarampudi.medium.com/your-ai-is-guessing-heres-how-to-make-it-stop-e1874bfa312a

⭐ 收藏

🎧 摘要語音

🔊 朗讀全文（收藏後自動生成）

---

📝 重點摘要

TL;DR

LLM 負責生成文字，本體論加知識圖譜加語意編排層才能確保正確而非僅看似合理。

核心問題

LLM 擅長生成流暢文字，卻無法可靠地對結構化領域（產品、病患、財務、法規）進行推理。若應用需要「正確」而非僅「合理」，光靠模型甚至光靠 GraphRAG 都不夠，必須有一套強制語意正確性的架構。

關鍵發現 / 數據

• GraphRAG 能降低幻覺但無法強制語意：模型仍以自己的方式詮釋檢索到的事實，不驗證片段間是否結構一致。
• 三層分工：本體論（OWL）給「意義」、知識圖譜（RDF triple）給「真相」、語意編排層（如 LangGraph）負責「橋接」、LLM 只負責「措辭」。
• POLE+O 框架：Person、Object、Location、Event 四支柱，加上 Ontology 層賦予正式意義，使連結可查詢、可推論。
• 電商範例：把「藍色防水外套、$200 以下、2 日到貨、M 號」拆解為四個獨立約束（顏色屬性、二元特徵、變體庫存、物流選項），於檢索前驗證再交給 LLM。
• 違反本體論規則（如 headphones 標 waterproof）的 triple 會在本體層被攔截，永遠到不了 LLM。

方法亮點

• 本體論非 schema：schema 說有哪些欄位，本體論說那些東西「代表什麼意義」與合法關係/約束。
• 三層解析：Layer 1 裸事實 triple、Layer 2 OWL domain/range 約束守門、Layer 3 語言框架模板化（slot 綁定確定性），讓句子是「事實」而非「生成」。
• 語意編排層職責：意圖映射到本體概念、查詢標註、選取相關實體、依約束驗證資料，再導引 LLM 生成。
• 顛倒順序：模型是最後一步而非第一步，推理交給結構化層，LLM 只填語法。

對我的研究有用嗎？

對 GraphRAG 研究者，本文清楚點出 GraphRAG 作為「技術」而非「架構」的侷限——缺乏本體論層的語意強制與跨片段一致性驗證，值得參考。Layer 1-3 的 triple→OWL 約束→語言框架的分層敘事，以及「設計時一次決定 verbalization」對比「推論時讓 LLM 自行詮釋」，對設計可信賴的 schema-grounded 生成管線有啟發。

評語

觀念正確且敘事清晰，但偏概念佈道、無 benchmark 或量化證據，主張多為斷言；適合快速建立心智模型，不值得作為實證深讀。

---

🌐 中英對照

Author: Vimal Dwarampudi 作者：Vimal Dwarampudi Published: 發布日期： Source: https://vimal-dwarampudi.medium.com/your-ai-is-guessing-heres-how-to-make-it-stop-e1874bfa312a 來源：https://vimal-dwarampudi.medium.com/your-ai-is-guessing-heres-how-to-make-it-stop-e1874bfa312a Fetched: 2026-06-21T11:15:48.831955 擷取時間：2026-06-21T11:15:48.831955

---

Ontologies, Knowledge Graphs, and a Semantic Layer: The Architecture That Makes AI Stop Guessing / 本體論、知識圖譜與語意層：讓 AI 不再瞎猜的架構

Why ontologies, knowledge graphs, and a semantic orchestration layer are the missing pieces most AI architectures skip.

為什麼本體論 (Ontology)、知識圖譜 (Knowledge Graph) 與語意編排層 (Semantic Orchestration Layer) 正是大多數 AI 架構所忽略的缺失環節。

Large language models are extraordinary at generating fluent, convincing text. What they are not designed to do is reason reliably over structured domains — products, patients, financial accounts, legal policies.

大型語言模型 (Large Language Model) 在生成流暢、令人信服的文字方面表現非凡。但它們的設計初衷並不是要在結構化領域中進行可靠的推理——例如產品、病患、金融帳戶、法律政策等。

If your AI application needs to be correct, not just plausible, you need more than a model. You need a proper architecture.

如果你的 AI 應用需要的是正確，而不只是看似合理，那麼你需要的就不只是一個模型，而是一套適切的架構。

This piece breaks down what that architecture looks like, why GraphRAG alone falls short, and what the combination of an ontology, a knowledge graph, and a semantic orchestration layer actually gives you — using an e-commerce example anyone can follow.

本文將拆解這套架構的樣貌、為什麼單靠 GraphRAG 仍有不足，以及本體論、知識圖譜與語意編排層的組合究竟能帶來什麼——並以一個人人都能理解的電子商務範例來說明。

The Problem with "Just Use an LLM" / 「直接用 LLM 就好」的問題所在

Ask a raw LLM to find you a blue waterproof jacket under $200 in size M with 2-day shipping, and it will generate a response that sounds helpful. It may even hallucinate a product name and price with complete confidence.

如果你要求一個未經處理的 LLM 幫你找一件 200 美元以下、M 號、可兩日到貨的藍色防水外套，它會生成一個聽起來很有幫助的回應。它甚至可能信心十足地憑空捏造 (hallucinate，幻覺) 出一個產品名稱和價格。

The model has no verified facts. It has no understanding of what "waterproof" means as a structured product attribute versus a marketing word. It cannot check inventory. It cannot enforce that "2-day shipping" is a real logistical constraint, not a guess.

這個模型沒有任何經過驗證的事實。它無法理解「防水」作為一個結構化的產品屬性與作為一個行銷用語之間有何差別。它無法查詢庫存。它也無法確保「兩日到貨」是一個真實的物流限制條件，而不只是一個猜測。

GraphRAG — the practice of retrieving graph context and passing it to an LLM — helps. But it does not solve the problem. It reduces hallucination, but it does not enforce meaning.

GraphRAG——也就是檢索圖譜情境並將其傳遞給 LLM 的做法——確實有幫助，但並未解決問題。它能減少幻覺，卻無法強制施加意義。

To understand why, you need to understand what three things actually do.

要理解原因，你需要先了解這三樣東西實際上各自扮演什麼角色。

Press enter or click to view image in full size

按 Enter 或點擊以檢視全尺寸圖片

High level Architecture View

高階架構視圖

Press enter or click to view image in full size

按 Enter 或點擊以檢視全尺寸圖片

Ontology is the meaning model. It does not store facts — it defines what kinds of things exist, what relationships between them are legal, and what rules govern valid combinations. Think of it as the rulebook the entire system enforces before any data is processed.

本體論 (Ontology) 是意義模型。它並不儲存事實——它定義了存在哪些種類的事物、它們之間哪些關係是合法的，以及哪些規則規範了有效的組合方式。可以把它想像成整個系統在處理任何資料之前都會強制執行的規則手冊。

RDF is the fact model. Every single statement in the system is expressed as a triple: a Subject, a Predicate, and an Object. ProductA → hasFeature → "waterproof" is one triple. The whole knowledge graph is built from thousands of these. RDF is precise and machine-readable, but without an ontology it has no sense of what any of it means.

RDF（資源描述框架，Resource Description Framework） 是事實模型。系統中的每一條陳述都以一個三元組 (triple) 的形式表達：主詞 (Subject)、謂詞 (Predicate) 與受詞 (Object)。ProductA → hasFeature → "waterproof" 就是一個三元組。整個知識圖譜便是由成千上萬個這樣的三元組構築而成。RDF 精確且可被機器讀取，但若沒有本體論，它對於這一切究竟代表什麼意義毫無概念。

POLE+O is a structural framework originally from law enforcement and intelligence analysis, now applied broadly to any domain where you need to connect entities. The four pillars are Person, Object, Location, and Event — the natural categories that almost every real-world domain reduces to. The +O (Ontology) is the layer that gives the four pillars formal meaning: it defines how a Customer (Person) relates to an Order (Object), how an Order connects to a Warehouse (Location) via a Shipment (Event), and what rules govern those connections. Without the ontology layer, POLE is just a filing system. With it, the connections become queryable, inferable, and semantically grounded.

POLE+O 是一套結構性框架，最初源自執法與情報分析領域，如今則廣泛應用於任何需要連結實體 (entity) 的領域。其四大支柱為人物 (Person)、物件 (Object)、地點 (Location) 與事件 (Event)——這些是幾乎每一個真實世界領域都能歸結出的自然類別。而 +O（本體論，Ontology）則是賦予這四大支柱正式意義的那一層：它定義了一個 Customer（人物）如何與一個 Order（物件）產生關聯、一個 Order 如何透過 Shipment（事件）連結到一個 Warehouse（地點），以及哪些規則規範這些連結。若沒有本體論這一層，POLE 只不過是一套歸檔系統；有了它，這些連結才得以被查詢、被推論，並具備語意上的根基。

Press enter or click to view image in full size

按 Enter 或點擊以檢視全尺寸圖片

Ontology-Driven Linguistic Annotation Model

本體論驅動的語言標註模型 (Ontology-Driven Linguistic Annotation Model)

1. Ontologies: The Rules Engine for Meaning / 1. 本體論：意義的規則引擎

An ontology is not a schema. A schema tells you what fields exist. An ontology tells you what things mean.

本體論不是綱要 (schema)。綱要告訴你存在哪些欄位，本體論則告訴你這些事物代表什麼意義。

In a product domain, an ontology defines:

在一個產品領域中，本體論會定義：

• Concepts and types — Product, Feature, Category, ShippingOption

• 概念與類型——Product、Feature、Category、ShippingOption

• Typed relationships — HAS_FEATURE, IN_CATEGORY, AVAILABLE_IN_SIZE

• 具型別的關係——HAS_FEATURE、IN_CATEGORY、AVAILABLE_IN_SIZE

• Valid attribute constraints — waterproof is a valid feature for jackets; it is not a valid feature for headphones

• 有效的屬性限制條件——waterproof（防水）對外套而言是一個有效的特徵，但對耳機而言則不是

• Semantic disambiguation rules — "fast shipping" maps to a shipping policy class, not a product description

• 語意消歧規則 (Semantic Disambiguation Rules)——「快速到貨」對應到的是一個運送政策類別，而非產品描述

This is what allows the system to recognize that when a user says "under $200 with 2-day shipping," they are expressing two independent constraints — a price filter and a logistics filter — not a single vague preference.

正是這一點，讓系統能夠辨識出：當使用者說「200 美元以下且兩日到貨」時，他們其實表達了兩個獨立的限制條件——一個價格篩選與一個物流篩選——而非單一模糊的偏好。

Without an ontology, you have data. With one, you have meaning.

沒有本體論，你擁有的只是資料；有了它，你才擁有意義。

2. Knowledge Graphs: The Source of Truth / 2. 知識圖譜：真相的來源

A knowledge graph stores the facts that are actually true in your domain right now.

知識圖譜儲存的是你的領域中此時此刻實際為真的事實。

Not generalized knowledge. Not training-data statistics. Actual facts:

不是泛化的知識，也不是訓練資料的統計數據，而是實際的事實：

• ProductA.color = Blue
• ProductA.feature = Waterproof
• ProductA.price = 179.99
• ProductA.stock = 12

• ProductA.shippingTime = 2 days

• ProductA.color = Blue

• ProductA.feature = Waterproof
• ProductA.price = 179.99
• ProductA.stock = 12
• ProductA.shippingTime = 2 days

The graph is provenance-aware and current. It knows which products exist, which are in stock, what they cost, and what features they actually have — not what the model thinks they might have based on similar text it once processed.

這個圖譜具備來源溯源 (provenance) 意識且即時更新。它知道哪些產品存在、哪些有庫存、它們的價格為何，以及它們實際具備哪些特徵——而不是模型根據它曾處理過的相似文字所「以為」它們可能具備的特徵。

The ontology gives meaning. The knowledge graph gives truth. Neither alone is sufficient.

本體論賦予意義，知識圖譜賦予真相。兩者單獨存在都不足夠。

3. The Semantic Orchestration Layer: The Bridge / 3. 語意編排層：橋梁

This is where something like LangGraph (or any comparable agent framework) enters — and where most teams stop short.

這正是像 LangGraph（或任何同類的代理框架 (agent framework)）登場的地方——也是大多數團隊止步不前之處。

The orchestration layer's job is to be the translator between the user's natural language and the structured world of your ontology and knowledge graph. Specifically, it:

編排層的職責是擔任使用者的自然語言與你的本體論及知識圖譜所構成的結構化世界之間的翻譯者。具體而言，它會：

• Maps user intent to ontology concepts

• 將使用者意圖對應到本體論概念

• Annotates queries with domain semantics before retrieval

• 在檢索之前，為查詢標註領域語意

• Decides which graph entities and relationships are relevant

• 判斷哪些圖譜實體與關係是相關的

• Constructs retrieval prompts grounded in graph facts

• 建構以圖譜事實為根基的檢索提示 (prompt)

• Validates retrieved data against schema constraints before the LLM ever sees it

• 在 LLM 看到資料之前，先依綱要限制條件驗證所檢索到的資料

• Guides the LLM's generation with semantically correct context

• 以語意正確的情境引導 LLM 的生成

This is the piece that forces the model to operate within the structured domain rather than around it.

正是這個環節，迫使模型在結構化領域之內運作，而不是繞著它打轉。

LangGraph is one well-known framework for this. Others exist. You could build a custom implementation. The specific tool matters less than the architectural role: a semantic agent layer that sits between user intent and the LLM, enforcing domain correctness at every step.

LangGraph 是其中一個著名的框架，但也存在其他選擇，你甚至可以自行打造客製化的實作。具體採用哪個工具並不如其所扮演的架構角色來得重要：一個位於使用者意圖與 LLM 之間的語意代理層，在每一步都強制確保領域的正確性。

4. Why GraphRAG Alone Is Not Enough / 4. 為什麼單靠 GraphRAG 仍不足夠

GraphRAG typically works like this: retrieve relevant graph context, pass it to the model, let the model generate a response.

GraphRAG 通常的運作方式如下：檢索相關的圖譜情境、將其傳遞給模型、讓模型生成回應。

That sounds solid. Here is what it does not do:

聽起來很穩健。但以下是它做不到的事：

• It does not enforce ontology-based semantics — the model still interprets retrieved facts on its own terms

• 它無法強制施加以本體論為基礎的語意——模型仍然會依照自己的方式詮釋所檢索到的事實

• It does not validate whether retrieved fragments are structurally consistent with each other

• 它無法驗證所檢索到的片段彼此之間在結構上是否一致

• It does not prevent the model from mixing unrelated graph nodes into a plausible-sounding but invalid answer

• 它無法阻止模型把不相關的圖譜節點混入一個聽起來合理卻無效的答案中

• It does not guarantee that constraints like price ranges or variant availability are respected

• 它無法保證諸如價格範圍或款式供應狀況之類的限制條件會被遵守

• It does not stop the model from producing a confident response when retrieved facts are incomplete

• 當所檢索到的事實並不完整時，它無法阻止模型產生一個充滿信心的回應

GraphRAG improves grounding. It does not provide formal domain understanding. The model is still guessing — just with better raw material to guess from.

GraphRAG 改善了根基扎實度 (grounding)，但它並未提供正式的領域理解。模型仍然在猜測——只不過手上有了更好的原始素材可供猜測而已。

5. The Architecture That Actually Works / 5. 真正能奏效的架構

The sequence looks like this:

其流程如下：

Step 1 — Ontology defines semantics What concepts exist, what attributes are valid, what relationships are legal in this domain.

步驟一——本體論定義語意 在此領域中存在哪些概念、哪些屬性是有效的、哪些關係是合法的。

Step 2 — Knowledge graph stores facts Current product data, inventory, feature relationships, pricing, availability.

步驟二——知識圖譜儲存事實 即時的產品資料、庫存、特徵關係、定價、供應狀況。

Step 3 — Semantic orchestration maps intent to schema Annotate the user request, select the right graph queries, validate retrieved facts against ontology constraints.

步驟三——語意編排將意圖對應到綱要 標註使用者的請求、選取正確的圖譜查詢、依本體論限制條件驗證所檢索到的事實。

Step 4 — LLM generates language From grounded, semantically correct, validated data — not from its own interpolations.

步驟四——LLM 生成語言 基於根基扎實、語意正確、經過驗證的資料——而非源自它自己的內插臆測。

The LLM's job becomes writing, not reasoning. The structured layers handle reasoning. That division of labor is what makes the output trustworthy.

LLM 的工作變成了「書寫」，而非「推理」。推理交由結構化的各層來處理。正是這樣的分工，使得輸出結果值得信賴。

6. The E-Commerce Query, Walked Through / 6. 逐步走過電子商務查詢範例

A user asks:

一位使用者問道：

"Find blue waterproof jackets under $200 with 2-day shipping in size M."

「幫我找 200 美元以下、可兩日到貨、M 號的藍色防水外套。」

With GraphRAG only: The system retrieves some jacket-related graph nodes, passes them to the model, and hopes the model correctly interprets "waterproof" as a product feature, "2-day shipping" as a logistics constraint, and "size M" as a variant filter — separately and simultaneously. It might. It might not. There is no guarantee.

只用 GraphRAG 的情況： 系統檢索一些與外套相關的圖譜節點，將其傳遞給模型，然後寄望模型能正確地——分別且同時地——把「防水」詮釋為產品特徵、把「兩日到貨」詮釋為物流限制、把「M 號」詮釋為款式篩選。它有可能做到，也有可能做不到，完全沒有保證。

With ontology + knowledge graph + semantic orchestration:

結合本體論 + 知識圖譜 + 語意編排的情況：

The ontology resolves:

本體論會解析出：

• blue → product color attribute

• blue（藍色）→ 產品顏色屬性

• waterproof → binary product feature

• waterproof（防水）→ 二元的產品特徵

• size M → variant availability filter

• size M（M 號）→ 款式供應篩選

• 2-day shipping → shipping option constraint

• 2-day shipping（兩日到貨）→ 運送選項限制

The knowledge graph provides verified facts for matching products — actual colors, features, prices, stock levels, and shipping windows.

知識圖譜則為符合條件的產品提供經過驗證的事實——實際的顏色、特徵、價格、庫存量與到貨時程。

The orchestration layer builds a precise query:

編排層會建構出一個精確的查詢：

• feature.waterproof = true
• price < 200
• size M in stock
• shippingTime ≤ 2 days

• stock > 0

• feature.waterproof = true

• price < 200
• size M in stock
• shippingTime ≤ 2 days
• stock > 0

The LLM then produces:

接著 LLM 產生出：

"I found three blue waterproof jackets in size M under $200. The best match is the Trailblazer Storm Jacket at $179.99 with 2-day shipping."

「我找到三件 200 美元以下、M 號的藍色防水外套。最符合的是 Trailblazer Storm Jacket，售價 179.99 美元，可兩日到貨。」

That is not a guess. Every claim in that sentence was validated against real data before the model generated a single word.

那不是一個猜測。在模型生成任何一個字之前，這句話中的每一項主張都已經過真實資料的驗證。

Press enter or click to view image in full size

按 Enter 或點擊以檢視全尺寸圖片

Three diagrams, one for each layer — RDF triple, OWL ontology constraints, and linguistic frames — all using the e-commerce jacket example.

三張圖，各對應一個層級——RDF 三元組、OWL 本體論限制條件，以及語言框架 (linguistic frames)——全都採用電子商務外套的範例。

Layer 1 — the triple states a bare fact: ex:ProductA ex:hasFeature "waterproof". The system knows that this relationship exists, but not what it means, whether it is valid for this product type, or how to say it in a sentence.

第一層——三元組 陳述了一個赤裸裸的事實：ex:ProductA ex:hasFeature "waterproof"。系統知道這個關係存在，但不知道它代表什麼意義、是否對此產品類型有效，也不知道如何用一個句子把它說出來。

Layer 2 — the ontology adds the rules. ex:hasFeature is declared an ObjectProperty with domain: Product and range: Feature. The class jacket is a subclass of Product and explicitly permits waterproof as a valid feature — while also recording that waterproof would be invalid for headphones. This is where the semantic guard lives. A triple that violated these rules would be caught here and never reach the LLM.

第二層——本體論 加入了規則。ex:hasFeature 被宣告為一個 ObjectProperty，其 domain: Product（定義域為產品）且 range: Feature（值域為特徵）。類別 jacket（外套）是 Product 的子類別，並明確允許 waterproof 作為一個有效特徵——同時也記錄了 waterproof 對 headphones（耳機）而言是無效的。這正是語意守門員所在之處。任何違反這些規則的三元組都會在此被攔截，永遠不會抵達 LLM。

Layer 3 — the linguistic frame maps the predicate to a template: ex:hasFeature → "The [Product] is [Feature]." The ontology already defined the domain and range, so the slot binding is deterministic — [Product] always binds from the domain side, [Feature] always binds from the range side. The resolved sentence "The Trailblazer Storm Jacket is waterproof." is a fact, not a generation. The LLM receives this sentence as input, not the raw triple, and its job is only to weave it into fluent prose.

第三層——語言框架 將謂詞對應到一個模板：ex:hasFeature → "The [Product] is [Feature]."。由於本體論已經定義了定義域與值域，因此槽位綁定 (slot binding) 是確定性的——[Product] 永遠從定義域那一側綁定，[Feature] 永遠從值域那一側綁定。解析後的句子 "The Trailblazer Storm Jacket is waterproof." 是一個事實，而非一個生成結果。LLM 接收到的輸入是這個句子，而非原始的三元組，它的工作僅僅是將其編織成流暢的文句。

The key distinction from a GraphRAG-only approach: in GraphRAG the LLM decides how to interpret and verbalize the graph data. Here that decision is made at ontology design time, once, correctly — and the model just fills in the grammar.

與純 GraphRAG 做法的關鍵差異在於：在 GraphRAG 中，是由 LLM 決定如何詮釋圖譜資料並將其用語言表達出來；而在這裡，這個決定是在本體論設計階段就一次性、正確地做好了——模型只需要負責填上文法即可。

7. This Pattern Scales Beyond E-Commerce / 7. 此模式可擴展至電子商務以外的領域

The same architecture applies wherever an LLM must answer from precise facts:

只要 LLM 必須根據精確事實來回答問題，同樣的架構就都適用：

• Healthcare — symptoms, diagnoses, treatment protocols, contraindications

• 醫療保健——症狀、診斷、治療規範、禁忌症

• Finance — account states, transaction rules, regulatory constraints

• 金融——帳戶狀態、交易規則、法規限制

• Enterprise search — document policies, approval chains, access controls

• 企業搜尋——文件政策、審批鏈、存取控制

Anywhere the cost of a plausible-but-wrong answer is high, the pattern holds: knowledge graph for truth, ontology for meaning, semantic orchestration for guided retrieval, LLM for fluent output.

任何「看似合理卻錯誤」的答案代價高昂之處，這個模式都成立：以知識圖譜掌管真相、以本體論掌管意義、以語意編排引導檢索、以 LLM 產出流暢的輸出。

Sample Implementation — https://github.com/VimalDwarampudi/semantic-rag

範例實作——https://github.com/VimalDwarampudi/semantic-rag

The Takeaway / 重點總結

GraphRAG is a step in the right direction. But it is not an architecture — it is a technique. And techniques without structure produce inconsistency.

GraphRAG 是朝正確方向邁出的一步。但它不是一套架構——它是一項技術。而缺乏結構的技術只會產生不一致的結果。

The systems that can actually be trusted combine:

真正能被信賴的系統，結合了：

• A knowledge graph to store what is true

• 一個 知識圖譜 來儲存何者為真

• An ontology to define what things mean

• 一套 本體論 來定義事物的意義

• A semantic orchestration layer to connect user intent to structured knowledge

• 一個 語意編排層 來連結使用者意圖與結構化知識

• An LLM to turn validated facts into natural language

• 一個 LLM 來把經過驗證的事實轉化為自然語言

The model is the last step, not the first. Get that order right, and you stop building systems that guess — and start building systems that know.

模型是最後一步，而非第一步。把這個順序擺對，你就能不再打造會「猜測」的系統——轉而開始打造真正「知道」的系統。

The specific orchestration framework — LangGraph, LlamaIndex, a custom agent loop — matters less than the pattern. What matters is that something enforces the semantic contract between the user's intent and the structured domain before the LLM generates a response. Most teams skip that step. That is where correctness is lost.

具體採用哪個編排框架——LangGraph、LlamaIndex,還是一個客製化的代理迴圈——並不如這個模式本身來得重要。真正重要的是：在 LLM 生成回應之前，必須有某個機制強制執行使用者意圖與結構化領域之間的語意契約。大多數團隊都跳過了這一步。而正確性，正是在那裡流失的。

---

🔤 關鍵術語

英文	繁中譯名	文章中的脈絡 / 簡短說明
GraphRAG	圖譜檢索增強生成	檢索圖譜脈絡並傳給 LLM 的做法；能減少幻覺但無法強制語意正確
Ontology	本體論 / 意義模型	定義領域中存在哪些事物、合法關係與規則的「規則書」，賦予資料意義
Knowledge Graph	知識圖譜	儲存領域中當下為真的事實（具來源可追溯性），作為真相來源
Semantic Orchestration Layer	語意編排層	介於使用者意圖與 LLM 之間，將自然語言對映到本體與圖譜並驗證資料的橋接層
RDF (Resource Description Framework)	資源描述框架	以三元組表達事實的事實模型，精確且機器可讀
Triple (Subject-Predicate-Object)	三元組（主詞-謂詞-受詞）	RDF 的基本單位，如 ProductA → hasFeature → "waterproof"
POLE+O	POLE+O 框架	源自執法情報分析的結構框架：Person、Object、Location、Event 四支柱加上 Ontology 層
OWL (Web Ontology Language)	網路本體語言	用來宣告 ObjectProperty、domain、range 等本體約束的語言
ObjectProperty	物件屬性	OWL 中宣告關係（如 hasFeature）的屬性類型，具 domain 與 range
Domain / Range	定義域 / 值域	限定屬性主詞與受詞所屬類別（如 hasFeature 的 domain 為 Product、range 為 Feature）
Subclass	子類別	類別繼承關係，如 jacket 是 Product 的子類別
Hallucination	幻覺	LLM 自信地生成未經查證、不存在的內容（如虛構商品名與價格）
Grounding	落地 / 事實依據	讓模型輸出建立在已驗證圖譜事實之上，而非自身推測
Semantic Disambiguation	語意消歧	將「fast shipping」對映到運送政策類別而非商品描述的規則
Provenance-aware	來源可追溯	知識圖譜能追蹤事實的出處與時效性
Schema Constraints	綱要約束	編排層在送進 LLM 前用以驗證檢索資料的結構限制
Intent Mapping	意圖對映	將使用者自然語言意圖對映到本體概念與圖譜查詢
Linguistic Frame	語言框架	將謂詞對映為句型模板（如 "The [Product] is [Feature]."）以確定性地填槽成句
LangGraph	LangGraph（代理框架）	用於實作語意編排層的代理框架範例之一
LLM (Large Language Model)	大型語言模型	架構中的最後一步，負責把已驗證事實轉為流暢自然語言