本體導向的知識萃取——從文件到情境感知規則¶

文章資訊

作者：Fanghua (Joshua) Yu　　日期：2026-07-08

原文標題：Ontology-Guided Knowledge Extraction: From Documents to Context-Aware Rules

Medium 原連結：https://medium.com/@yu-joshua/ontology-guided-knowledge-extraction-from-documents-to-context-aware-rules-e957bcb36e0d

🎧 摘要語音

📝 重點摘要¶

TL;DR¶

用本體當語意控制層，把文件知識轉成可治理、可執行、可稽核的決策規則。

核心問題¶

傳統知識萃取只停在實體、關係與事實，適合搜尋與問答，卻無法支援決策。企業真正需要的是「條件成立時、在特定情境下、有證據支持、可推得結論」的操作型知識。本文提出以本體（ontology）作為語意控制層的架構模式，貫穿萃取、情境化、規則生成與治理。

關鍵發現 / 數據¶

提出三層規則架構：Level 1 通用知識規則（可重用領域原則）、Level 2 情境化規則（綁定特定資產／流程）、Level 3 診斷／決策規則（納入觀測與證據）。
定義九階段管線：萃取結構化陳述 → 解讀通用規則 → 綁定本體概念 → 綁定企業情境 → 對應資料 → 加入觀測證據 → 生成受治理草稿 → 驗證審查 → 編譯執行。
提出四層驗證：結構、語意、操作、認知（epistemic）驗證，並要求每條規則含正例、負例、邊界、缺資料、超範疇測試。
強調知識生命週期：取得→萃取→建模→情境化→生成→驗證→核准→執行→觀測→精煉，形成回饋閉環。
區分七種認知狀態關係（如 candidateContributorTo、confirmedCauseOf），杜絕相關性被誤當因果。

方法亮點¶

本體不只是 schema，而是連接文件↔圖譜↔企業資料↔規則↔代理的「語意契約」，用 OWL 做邏輯一致性、SHACL 做結構驗證。
引入中性中介規則表徵，分離「意義／情境／執行技術」，審核通過後才編譯為 SPARQL、Cypher、SWRL 等。
以邏輯「職責」定義七類代理（Interpreter、Grounder、Binder、Mapper、Generator、Validator、Reviewer），而非必然為獨立應用。
原則：缺失閾值／輸入須明示為知識缺口，絕不臆造；人類專家保留啟用決策權。

對我的研究有用嗎？¶

對 GraphRAG 研究者，最有價值的是「從描述性事實升級到條件式操作型知識」的分層框架，以及把 provenance 與 epistemic status 直接寫進規則模型的做法，可強化圖譜推理的可稽核性與可信度。本體作為語意角色與關係約束層的觀念，對設計受控的 LLM 抽取管線頗具參考性。

評語¶

概念架構清晰、治理視角完整，但全篇為設計模式論述，無實作、無 benchmark 數據，屬理念藍圖而非實證研究——值得快讀取其框架，不必深究。

🌐 中英對照¶

Author: Fanghua (Joshua) Yu
Published:
Source: https://medium.com/@yu-joshua/ontology-guided-knowledge-extraction-from-documents-to-context-aware-rules-e957bcb36e0d
Fetched: 2026-07-08T22:21:40.203366

Ontology-Guided Knowledge Extraction: From Documents to Context-Aware Rules / 本體論引導的知識抽取：從文件到情境感知規則¶

Turning domain knowledge into governed, executable, and auditable decision logic / 將領域知識轉化為受治理、可執行且可稽核的決策邏輯¶

Press enter or click to view image in full size

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

Image generated by Gemini by author

圖片由作者使用 Gemini 生成

Introduction / 引言¶

Most knowledge-extraction pipelines stop after identifying entities, relationships, and facts. That is useful for search and question answering, but many enterprise applications ultimately need something more operational:

大多數知識抽取管線 (knowledge-extraction pipeline) 在辨識出實體 (entity)、關係 (relationship) 與事實 (fact) 之後便告一段落。這對於搜尋與問答很有用，但許多企業應用最終需要更具可操作性的東西：

When does a fact matter?
Under what conditions does a principle apply?
What evidence supports a conclusion?
Which variables, thresholds, or observations are still missing?
Can the extracted knowledge be converted into executable rules?
一項事實在何時才重要？
在什麼條件下某項原則才適用？
有哪些證據支持某個結論？
還缺少哪些變數、閾值或觀測值？
抽取出的知識能否轉換為可執行的規則？

The proposed pattern uses an ontology not only as an extraction schema, but as a semantic control layer that guides knowledge interpretation, contextualisation, rule generation, validation, and governance.

所提出的模式不僅將本體論 (Ontology) 用作抽取綱要 (schema)，更將其作為一個語意控制層 (semantic control layer)，引導知識的詮釋、情境化 (contextualisation)、規則生成、驗證與治理。

The source design distinguishes three levels — general mechanism rules, context-specific rules, and diagnostic rules — and proposes a semi-automated process for moving between them. This can be generalised into an industry-independent architecture pattern.

原始設計區分了三個層級——通用機制規則、特定情境規則與診斷規則——並提出一套在它們之間轉換的半自動化流程。這可以被推廣為一種與產業無關的架構模式。

Below is the full Medium draft, revised to remove the implementation-layer, automation-boundary, and implementation-roadmap sections, with the architectural principles consolidated into the summary.

以下為完整的 Medium 草稿，經修訂後移除了實作層 (implementation-layer)、自動化邊界 (automation-boundary) 與實作路線圖 (implementation-roadmap) 等章節，並將架構原則整合進總結中。

A statement such as:

像這樣的一句陳述：

Condition A may contribute to Outcome B.

條件 A 可能促成結果 B。

is not yet enough to support a decision.

這還不足以支撐一項決策。

An operational system needs to understand the context in which the statement applies, the variables required to evaluate it, the evidence supporting it and the limits of the conclusion.

一個可操作的系統需要理解該陳述所適用的情境 (context)、評估它所需的變數、支持它的證據，以及該結論的限制範圍。

This leads to a broader architecture pattern:

這帶出了一種更宏觀的架構模式：

Use an ontology not only as a schema for knowledge extraction, but as a semantic control layer for transforming general knowledge into contextualised, governed and testable rules.

不僅將本體論用作知識抽取的綱要，更將其作為語意控制層，用以把通用知識轉化為情境化、受治理且可測試的規則。

The pattern can be applied across industries. The source knowledge may come from engineering documents, regulations, policies, research papers, operating procedures, incident reports or expert interviews. The resulting rules may support diagnosis, risk assessment, compliance, maintenance, cybersecurity, customer operations or workflow automation.

此模式可跨產業應用。來源知識可能來自工程文件、法規、政策、研究論文、操作程序、事故報告或專家訪談。所產生的規則則可支援診斷、風險評估、合規、維護、網路安全、客戶營運或工作流程自動化。

The domain changes. The architecture remains largely the same.

領域會改變，但架構大致維持不變。

1. Knowledge Extraction for Decision Making / 1. 面向決策的知識抽取¶

A conventional knowledge-extraction pipeline often looks like this:

一個傳統的知識抽取管線通常長這樣：

Documents  
   ↓  
Entities, relationships and facts  
   ↓  
Knowledge graph

This pipeline can answer questions such as:

此管線可以回答如下問題：

What concepts appear in the source?
What properties describe them?
How are they related?
Where did a statement come from?
Which documents mention the same concept?
來源中出現了哪些概念？
有哪些屬性用來描述它們？
它們之間如何關聯？
某個陳述來自何處？
哪些文件提及了相同的概念？

These capabilities are useful for search, discovery, Graph RAG and semantic integration.

這些能力對於搜尋、探索、圖檢索增強生成 (Graph RAG) 與語意整合都很有用。

However, decision-oriented systems need more than descriptive facts.

然而，面向決策的系統需要的不只是描述性的事實。

They often require knowledge in a conditional form:

它們往往需要以條件式形式呈現的知識：

When conditions X and Y hold,  
within context Z,  
conclusion R may be inferred,  
supported by evidence E.

Consider the difference between these two representations:

考慮以下兩種表述之間的差異：

High temperature is associated with component degradation.

and:

以及：

IF a component of type X  
operates above an approved temperature threshold  
for longer than the permitted duration  
under configuration Y,  
THEN degradation risk is elevated.

The second representation contains much more operational structure:

第二種表述包含了更多可操作的結構：

a subject;
a type constraint;
a measurable condition;
a threshold;
a duration;
an operating context;
a conclusion;
an implied evidence requirement.
一個主體；
一個型別約束 (type constraint)；
一個可量測的條件；
一個閾值 (threshold)；
一段持續時間；
一個運作情境；
一個結論；
一項隱含的證據需求。

It can be evaluated, tested, reviewed and potentially executed. The central shift is therefore from extracting isolated facts to extracting and generating structured knowledge statements involving conditions, constraints, context, observations, evidence, conclusions, exceptions, recommended actions and so on.

它可以被評估、測試、審查，並有可能被執行。因此，核心的轉變在於從抽取孤立的事實，轉向抽取並生成涉及條件、約束、情境、觀測、證據、結論、例外、建議行動等的結構化知識陳述 (structured knowledge statements)。

Enterprise knowledge becomes operational when extracted facts can be transformed into contextualised, governed and testable decision logic.

當抽取出的事實能夠被轉化為情境化、受治理且可測試的決策邏輯時，企業知識便成為可操作的知識。

2. The Ontology-Guided Knowledge-to-Rule Pattern / 2. 本體論引導的「知識轉規則」模式¶

The generic architecture can be represented as:

此通用架構可表示如下：

Press enter or click to view image in full size

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

Ontology-Guided Rule Generation Architecture

本體論引導的規則生成架構

The process begins with unstructured or semi-structured knowledge sources.

此流程始於非結構化或半結構化的知識來源。

These sources are interpreted using an ontology that defines the important concepts, relationships, semantic roles and constraints of the domain.

這些來源會透過一個本體論來詮釋，該本體論定義了該領域中重要的概念、關係、語意角色 (semantic role) 與約束。

The first output is not necessarily a production rule. It is often a general knowledge rule describing a reusable relationship between conditions and outcomes.

第一個輸出不一定是生產環境規則 (production rule)。它往往是一條通用知識規則，描述條件與結果之間可重複使用的關係。

The general rule is then bound to a specific context, such as:

接著，通用規則會被繫結 (bind) 到一個特定情境，例如：

a type of asset;
a product configuration;
a process stage;
a system environment;
a transaction type;
an organisational policy;
……
一種資產類型；
一種產品組態；
一個流程階段；
一個系統環境；
一種交易類型；
一項組織政策；
……

Observations, events and measurements are subsequently connected to the contextualised rule. This produces a decision or diagnostic rule draft that can be validated, reviewed and converted into executable logic.

隨後，觀測值、事件與量測值會被連結到已情境化的規則。這會產生一份決策或診斷規則的草稿，該草稿可被驗證、審查並轉換為可執行的邏輯。

However, the resulting output does not always need to be a definitive decision. It may instead represent:

然而，所產生的輸出並不一定總是要成為一個確定性的決策。它也可以代表：

a candidate explanation;
an elevated risk;
a contributing factor;
a policy applicability assessment;
a recommended action;
a request for additional evidence;
a draft conclusion requiring expert review.
一個候選解釋；
一個升高的風險；
一個促成因素；
一項政策適用性評估；
一項建議行動；
一項對額外證據的請求；
一份需要專家審查的結論草稿。

This is important because much enterprise knowledge is conditional, incomplete or probabilistic. A trustworthy system must preserve those distinctions rather than translating every extracted relationship into a deterministic rule.

這很重要，因為許多企業知識是有條件的、不完整的或機率性的。一個值得信賴的系統必須保留這些區別，而非把每一個抽取出的關係都轉譯成確定性規則。

3. Three Levels of Knowledge Rules / 3. 知識規則的三個層級¶

A useful way to structure this architecture is to separate rules into three levels.

建構此架構的一種有效方式，是將規則區分為三個層級。

3.1 Level 1: General Knowledge Rules / 3.1 第一層：通用知識規則¶

General knowledge rules represent reusable domain principles. They do not refer to a specific customer, product, asset, organisation or process instance.

通用知識規則代表可重複使用的領域原則。它們不指涉特定的客戶、產品、資產、組織或流程實例。

A general rule may look like:

一條通用規則可能長這樣：

Condition A  
+ Condition B  
+ Enabling Constraint C  
→ Outcome or Risk R

Examples include:

範例包括：

Repeated overload  
+ inadequate cooling  
→ elevated equipment failure risk

Unusual transaction sequence  
+ shared control indicators  
→ elevated fraud risk

Sensitive activity  
+ missing approval  
→ potential compliance breach

These rules may be extracted from:

這些規則可能抽取自：

research papers;
industry standards;
legislation;
internal policies;
operating manuals;
expert knowledge;
incident reports;
historical investigations.
研究論文；
產業標準；
立法法規；
內部政策；
操作手冊；
專家知識；
事故報告；
歷史調查。

A general rule expresses what may hold across a class of situations. It does not yet determine whether the rule applies to a particular case.

一條通用規則表達的是在某一類情境中可能成立的內容。它尚未決定該規則是否適用於某個特定案例。

3.2 Level 2: Contextualised Rules / 3.2 第二層：情境化規則¶

A contextualised rule binds the general principle to a specific operating environment.

情境化規則將通用原則繫結到一個特定的運作環境。

For example:

例如：

Industrial compressor operates above rated load   
+ cooling-fan capacity is below the required level   
+ high-load operation occurs repeatedly   
→ elevated compressor failure risk

The context may include:

情境可能包括：

asset or product type;
component structure;
customer segment;
geographical location;
contract type;
system configuration;
process stage;
material combination;
equipment model;
operational environment.
資產或產品類型；
元件結構；
客戶區隔；
地理位置；
合約類型；
系統組態；
流程階段；
材料組合；
設備型號；
運作環境。

The ontology guides this binding process by determining whether a candidate concept is valid for a particular semantic role. It can also detect incompatible bindings.

本體論透過判定某個候選概念對特定語意角色是否有效，來引導此繫結流程。它也能偵測不相容的繫結。

For example, a rule requiring an OperatingEnvironment should not be bound to an entity classified as a FinancialTransaction. A rule requiring a MeasuredProperty should not be bound to a document or organisation.

例如，一條需要 OperatingEnvironment（運作環境）的規則，不應被繫結到一個被分類為 FinancialTransaction（金融交易）的實體。一條需要 MeasuredProperty（量測屬性）的規則，不應被繫結到一份文件或一個組織。

Contextualisation therefore does more than substitute variables. It determines the scope and applicability of the rule.

因此，情境化所做的不僅是替換變數。它決定了規則的範圍與適用性。

3.3 Level 3: Decision or Diagnostic Rules / 3.3 第三層：決策或診斷規則¶

The third level incorporates observations, events, measurements or state changes.

第三層納入了觀測、事件、量測或狀態變化。

A decision rule may take the following form:

一條決策規則可能採取以下形式：

Contextualised conditions  
+ observed state  
+ relevant event  
+ available evidence  
→ candidate conclusion

For example:

例如：

IF an asset of type X  
is operating under configuration Y  
AND an abnormal temperature pattern is observed  
AND the cooling system reports reduced capacity  
THEN cooling-related degradation  
is a candidate contributor to the observed condition.

The conclusion should explicitly represent its epistemic status.

該結論應明確地表達其知識論狀態 (epistemic status)。

It may be:

它可能是：

a confirmed conclusion;
a candidate cause;
a contributing factor;
a correlation;
an elevated risk;
an unsupported hypothesis;
an insufficient-evidence result.
一個已確認的結論；
一個候選原因；
一個促成因素；
一個相關性；
一個升高的風險；
一個未獲支持的假設；
一個證據不足的結果。

This prevents the system from converting an association into a confirmed causal claim.

這可防止系統將一個關聯性轉換成一個已確認的因果主張。

4. Ontology as the Semantic Control Layer / 4. 本體論作為語意控制層¶

In this architecture, the ontology does much more than provide a list of entity types. It acts as a semantic control layer across extraction, contextualisation, rule generation and validation.

在此架構中，本體論所做的遠不止提供一份實體類型清單。它在抽取、情境化、規則生成與驗證各階段中，扮演著一個語意控制層的角色。

4.1 Defining Semantic Roles / 4.1 定義語意角色¶

A rule contains different kinds of participants. The ontology can define roles such as:

一條規則包含不同種類的參與者。本體論可以定義如下的角色：

subject;
condition;
process;
event;
observation;
measured property;
constraint;
evidence;
risk;
cause;
action;
conclusion.
主體；
條件；
流程；
事件；
觀測；
量測屬性；
約束；
證據；
風險；
原因；
行動；
結論。

This helps the extraction process distinguish between a concept appearing in a sentence and the function that the concept performs within a knowledge statement.

這有助於抽取流程區分句子中出現的概念，以及該概念在一個知識陳述中所執行的功能。

For example, in the statement:

例如，在以下陳述中：

Extended exposure to moisture may increase corrosion risk for unprotected components.

長時間暴露於濕氣中，可能會提高無保護元件的腐蝕風險。

the ontology can help identify:

本體論可協助辨識出：

MoistureExposure as a condition;
ExposureDuration as a variable;
UnprotectedComponent as a scoped subject;
CorrosionRisk as a conclusion.
MoistureExposure（濕氣暴露）為一個條件；
ExposureDuration（暴露持續時間）為一個變數；
UnprotectedComponent（無保護元件）為一個受範圍限定的主體；
CorrosionRisk（腐蝕風險）為一個結論。

4.2 Defining Valid Relationships / 4.2 定義有效關係¶

The ontology can also constrain which concepts may be related.

本體論也能約束哪些概念之間可以建立關聯。

Examples include:

範例包括：

Asset participatesIn Process  
Observation measures Property  
Event occursDuring ProcessStage  
Policy appliesTo BusinessActivity  
Evidence supports Conclusion  
Configuration constrains Operation

These relationships provide a semantic structure for rule interpretation.

這些關係為規則詮釋提供了一個語意結構。

4.3 Enforcing Constraints / 4.3 強制執行約束¶

Ontology constraints may be used to validate:

本體論約束可用於驗證：

domain and range;
required relationships;
concept compatibility;
unit compatibility;
cardinality;
allowed classifications;
mutually exclusive states;
applicability conditions.
定義域與值域 (domain and range)；
必要關係；
概念相容性；
單位相容性；
基數 (cardinality)；
允許的分類；
互斥狀態；
適用性條件。

OWL reasoning can support logical consistency, while SHACL can validate graph structure, required properties and data-quality conditions.

OWL（網路本體語言）推理可支援邏輯一致性，而 SHACL（形狀約束語言）則可驗證圖結構、必要屬性與資料品質條件。

4.4 Aligning Vocabulary / 4.4 對齊詞彙¶

Documents rarely use perfectly consistent terminology, and quite commonly different sources may use:

文件很少使用完全一致的術語，而且相當常見的情況是，不同來源可能使用：

acronyms;
local names;
legacy terms;
product-specific labels;
synonyms;
abbreviations;
different levels of abstraction.
首字母縮寫；
本地名稱；
遺留術語 (legacy terms)；
特定產品的標籤；
同義詞；
縮寫；
不同層級的抽象。

The ontology provides canonical concepts and mappings from source terminology to enterprise terminology.

本體論提供標準概念 (canonical concepts)，以及從來源術語到企業術語的映射 (mappings)。

This makes it possible to recognise that different documents may be describing the same underlying concept.

這使得辨識出不同文件可能描述著相同的底層概念成為可能。

The ontology therefore becomes a semantic contract connecting:

因此，本體論成為一份連接以下各項的語意契約 (semantic contract)：

Documents  
↔ Knowledge Graph  
↔ Enterprise Data  
↔ Rules  
↔ Agents  
↔ Runtime Systems

5. The End-to-End AI-Native Generation Pipeline / 5. 端到端的 AI 原生生成管線¶

The architecture can be implemented as a sequence of knowledge-transformation stages.

此架構可實作為一系列的知識轉換階段。

Stage 1: Extract Structured Knowledge Statements / 階段 1：抽取結構化知識陳述¶

The extraction process should identify more than nouns and relationships. It should extract statements involving:

抽取流程所辨識的應不僅是名詞與關係。它應抽取涉及以下內容的陳述：

conditions;
outcomes;
causes;
effects;
xceptions;
thresholds;
variables;
constraints;
recommendations;
evidence;
applicability.
條件；
結果；
原因；
效應；
例外；
閾值；
變數；
約束；
建議；
證據；
適用性。

For every extracted statement, the system should retain provenance such as:

對於每一項抽取出的陳述，系統應保留如下的來源出處 (provenance)：

Source document  
Section or page  
Table or figure  
Source sentence  
Extraction method  
Extraction confidence

Provenance is essential because a generated rule must remain traceable to the knowledge that supports it.

來源出處至關重要，因為一條生成的規則必須始終可追溯至支持它的知識。

Stage 2: Interpret the General Rule / 階段 2：詮釋通用規則¶

Natural-language statements are converted into structured rule skeletons.

自然語言陳述會被轉換為結構化的規則骨架。

For example:

例如：

inputs:  
  - condition_a  
  - condition_b  
  - constraint_c  
conclusion:  
  - outcome_r

At this point, the variables may remain abstract. The purpose is to identify the logical structure of the knowledge:

在此階段，變數可以保持抽象。其目的在於辨識知識的邏輯結構：

What conditions are required?
Which variables must be measured?
What constraint enables the outcome?
\What conclusion is supported?
Are there exceptions?
Is the relationship causal, correlational or advisory?
需要哪些條件？
必須量測哪些變數？
什麼約束促成了該結果？
支持了什麼結論？
是否存在例外？
該關係是因果性的、相關性的，還是建議性的？

Stage 3: Bind Variables to Ontology Concepts / 階段 3：將變數繫結至本體論概念¶

The abstract roles are mapped to ontology classes and properties.

抽象角色會被映射到本體論的類別與屬性。

For example:

例如：

condition_a → EnvironmentalCondition  
condition_b → ComponentProperty  
constraint_c → OperationalConstraint  
outcome_r → FailureRisk

The ontology can validate whether these mappings are semantically compatible.

本體論可驗證這些映射在語意上是否相容。

When multiple candidate concepts exist, the system may retain alternatives and request human confirmation rather than choosing silently.

當存在多個候選概念時，系統可保留替代選項並請求人工確認，而非默默地做出選擇。

Stage 4: Bind the Rule to Enterprise Context / 階段 4：將規則繫結至企業情境¶

The general rule is then resolved against a specific environment.

接著，通用規則會針對一個特定環境進行解析。

This may involve binding abstract roles to actual assets, process models, products, organisational units and so on.

這可能涉及將抽象角色繫結到實際的資產、流程模型、產品、組織單位等等。

One general rule may generate multiple contextualised variants. For example, the same general risk principle may be applied differently depending on:

一條通用規則可能生成多個情境化的變體。例如，同一項通用風險原則，可能會依據以下因素而有不同的套用方式：

asset design;
operating environment;
control configuration;
regulatory jurisdiction;
customer entitlement;
service type.
資產設計；
運作環境；
控制組態；
監管管轄權；
客戶權益；
服務類型。

Stage 5: Map Rule Variables to Data / 階段 5：將規則變數映射至資料¶

The system must determine where values required by the rule will come from.

系統必須判定規則所需的值將來自何處。

Examples include:

範例包括：

Ontology property → database column  
Ontology concept → API response  
Observation → event stream  
Threshold → approved parameter registry  
State → knowledge graph assertion

The mapping process should also identify:

映射流程也應辨識出：

data type;
unit;
update frequency;
source ownership;
quality status;
availability;
transformation logic.
資料型別；
單位；
更新頻率；
來源所有權；
品質狀態；
可用性；
轉換邏輯。

Missing fields must be reported explicitly. The system should never invent a runtime value simply because the rule requires it.

缺失的欄位必須被明確地回報。系統絕不應僅因為規則需要某個執行期值 (runtime value)，就憑空捏造出來。

Stage 6: Add Observations and Evidence / 階段 6：加入觀測與證據¶

A contextualised rule becomes operational when it is connected to actual observations.

當一條情境化規則與實際觀測相連結時，它便成為可操作的。

These may include:

這些可能包括：

measurements;
state transitions;
system events;
transactions;
alerts;
inspection results;
user reports;
external signals.
量測值；
狀態轉換；
系統事件；
交易；
警示；
檢查結果；
使用者回報；
外部訊號。

The observations are evaluated against the conditions described by the rule. Evidence should remain distinct from the conclusion. A measurement may support a hypothesis without proving it.

這些觀測會針對規則所描述的條件進行評估。證據應始終與結論有所區別。一項量測值可以支持一個假設，卻不必然證明它。

Stage 7: Generate a Governed Rule Draft / 階段 7：生成受治理的規則草稿¶

The output should initially be created as a governed intermediate rule rather than executable code.

輸出最初應被建立為一條受治理的中介規則，而非可執行的程式碼。

The draft should contain:

該草稿應包含：

rule identity;
rule type;
scope;
ontology bindings;
required inputs;
derived values;
conditions;
conclusion;
evidence;
missing inputs;
thresholds requiring approval;
confidence or status;
review requirements.
規則識別碼；
規則類型；
範圍；
本體論繫結；
必要輸入；
衍生值；
條件；
結論；
證據；
缺失的輸入；
需要核准的閾值；
信心度或狀態；
審查需求。

Stage 8: Validate and Review / 階段 8：驗證與審查¶

Before deployment, the rule should be validated at several levels:

在部署之前，規則應在數個層級上進行驗證：

schema validity;
ontology consistency;
data availability;
unit compatibility;
threshold approval;
evidence sufficiency;
causal wording;
applicability scope;
positive and negative test coverage.
綱要有效性；
本體論一致性；
資料可用性；
單位相容性；
閾值核准；
證據充分性；
因果措辭；
適用範圍；
正向與負向測試涵蓋率。

Human reviewers remain responsible for approving:

人工審查者仍須負責核准：

thresholds;
causal strength;
risk severity;
scope;
production status;
automated actions.
閾值；
因果強度；
風險嚴重性；
範圍；
生產環境狀態；
自動化行動。

Stage 9: Compile the Approved Rule / 階段 9：編譯已核准的規則¶

After approval, the intermediate rule may be transformed into:

核准之後，中介規則可被轉換為：

SPARQL;
SHACL rules;
SWRL;
Cypher;
any custom rule language
SPARQL；
SHACL 規則；
SWRL；
Cypher；
任何自訂的規則語言

The execution technology depends on the use case. The semantic meaning of the rule should remain independent of the runtime language.

執行技術取決於使用案例。規則的語意意義應始終獨立於執行期語言之外。

6. A Neutral Intermediate Rule Representation / 6. 一種中立的中介規則表述¶

Generating executable rules directly from documents is risky, because a runtime language such as Cypher, Drools or SPARQL may obscure assumptions that should be reviewed first.

直接從文件生成可執行規則是有風險的，因為像 Cypher、Drools 或 SPARQL 這樣的執行期語言，可能會掩蓋那些本應先行審查的假設。

A neutral intermediate representation separates three concerns:

一種中立的中介表述將三種關注點分離開來：

the meaning of the knowledge;
the context in which it applies;
the technology used to execute it.
知識的意義；
它所適用的情境；
用來執行它的技術。

A simplified example may look like this:

一個簡化的範例可能長這樣：

rule_id: RULE-001  
rule_type: diagnostic  
status: draft  
scope:  
  subject_type: target_subject_type  
  process_stage: target_process_stage  
bindings:  
  role_a: ontology_concept_a  
  role_b: ontology_concept_b  
inputs:  
  - observed_value_a  
  - observed_value_b  
  - contextual_condition  
derived:  
  difference: abs(observed_value_a - observed_value_b)  
conditions:  
  - difference > ${approved_threshold}  
  - contextual_condition == true  
conclusion:  
  candidate_outcome: target_risk  
  reasoning_status: candidate  
evidence:  
  - source_knowledge  
  - source_data  
  - supporting_observation  
missing_inputs: []  
review_required: true

The same rule definition may later be compiled into different implementations without redefining its semantic meaning.

同一份規則定義稍後可被編譯成不同的實作，而無需重新定義其語意意義。

7. Agent Capabilities Within the Pattern / 7. 此模式中的代理能力¶

The architecture can be implemented using multiple agents or a single orchestrated workflow with specialised capabilities.

此架構可使用多個代理 (agent)，或使用具備專門能力的單一協同編排工作流程來實作。

The term “agent” should therefore be understood as a logical responsibility rather than necessarily a separate autonomous application.

因此，「代理」一詞應被理解為一種邏輯上的職責 (responsibility)，而不一定是一個獨立的自主應用程式。

At high level, we can create the following agents:

在高層次上，我們可以建立以下代理：

1) Knowledge Interpreter transforms narrative knowledge into a structured rule candidate.

1) 知識詮釋器 (Knowledge Interpreter) 將敘述性知識轉化為一個結構化的規則候選項。

2) Ontology Grounder maps source terminology to ontology, and reports ambiguous or unsupported mappings.

2) 本體論接地器 (Ontology Grounder) 將來源術語映射到本體論，並回報模糊或不受支援的映射。

3) Context Binder resolves abstract roles against enterprise context.

3) 情境繫結器 (Context Binder) 針對企業情境解析抽象角色。

4) Data Mapper identifies where required runtime values can be obtained.

4) 資料映射器 (Data Mapper) 辨識所需的執行期值可從何處取得。

5) Rule Generator produces the intermediate rule, derived variables, required thresholds, evidence references, as well as test cases.

5) 規則生成器 (Rule Generator) 產生中介規則、衍生變數、必要閾值、證據參照，以及測試案例。

6) Rule Validator checks schema conformance, ontology compatibility, unit consistency, data availability, unsupported thresholds, missing evidence, and scope conflicts.

6) 規則驗證器 (Rule Validator) 檢查綱要一致性、本體論相容性、單位一致性、資料可用性、不受支援的閾值、缺失的證據，以及範圍衝突。

7) Reviewer reviewer confirms the aspects that require domain accountability e.g.

7) 審查者 (Reviewer) 確認那些需要領域問責的面向，例如：

whether the rule is valid;
whether its scope is appropriate;
whether thresholds are approved;
whether the causal language is justified;
whether the rule may trigger an automated action;
whether the rule is ready for production.
規則是否有效；
其範圍是否適當；
閾值是否已獲核准；
因果性語言是否合理；
該規則是否可以觸發一項自動化行動；
該規則是否已準備好進入生產環境。

8. Evidence, Provenance and Epistemic Status / 8. 證據、來源出處與知識論狀態¶

A trustworthy rule is more than an IF–THEN statement.

一條值得信賴的規則，不僅僅是一句 IF–THEN（若—則）陳述。

Every generated rule should answer:

每一條生成的規則都應回答：

What source supports this rule
Which ontology concepts were used?
Which data fields instantiate its variables?
Which assumptions were introduced?
Which thresholds were externally approved?
What evidence was available at runtime?
What evidence was missing?
Is the result inferred, correlated or confirmed?
Who reviewed and approved the rule?
有什麼來源支持這條規則？
使用了哪些本體論概念？
哪些資料欄位實體化了它的變數？
引入了哪些假設？
哪些閾值是經由外部核准的？
在執行期有哪些可用的證據？
缺少了哪些證據？
結果是推論得出的、相關性的，還是已確認的？
誰審查並核准了這條規則？

This information should be represented as part of the rule model rather than stored in disconnected documentation. The conclusion itself should also communicate the strength of the claim.

這些資訊應被表述為規則模型的一部分，而非儲存於彼此脫節的文件之中。結論本身也應傳達其主張的強度。

Some useful relationships may include:

一些有用的關係可能包括：

candidateContributorTo  
indicatesRiskOf  
supportsHypothesis  
associatedWith  
requiresFurtherEvidence  
confirmedCauseOf

However, these relationships should not be treated as equivalent.

然而，這些關係不應被視為等價。

For example:

例如：

Event A occurs before Outcome B

does not automatically justify:

並不會自動地證成：

Event A causes Outcome B

Similarly:

同樣地：

Condition A is frequently observed with Risk B

does not justify:

並不能證成：

Condition A always produces Risk B

Representing epistemic status allows the knowledge graph to distinguish:

表述知識論狀態，使得知識圖譜 (Knowledge Graph) 能夠區分：

assertion;
hypothesis;
recommendation;
observation;
correlation;
candidate cause;
confirmed cause.
斷言；
假設；
建議；
觀測；
相關性；
候選原因；
已確認原因。

This is essential for auditability and responsible decision support.

這對於可稽核性 (auditability) 與負責任的決策支援而言至關重要。

9. Validation as a First-Class Pipeline Stage / 9. 將驗證作為一級的管線階段¶

Validation should not be treated as a final technical check. It is a core part of the knowledge-generation process.

驗證不應被當作最後的技術性檢查。它是知識生成流程中的核心環節。

Four levels of validation are particularly important.

有四個層級的驗證特別重要。

1. Structural Validation / 1. 結構驗證¶

Structural validation checks whether the generated rule conforms to the intermediate schema.

結構驗證檢查生成的規則是否符合中介綱要。

2. Semantic Validation / 2. 語意驗證¶

Semantic validation checks whether ontology concepts and relationships are used correctly.

語意驗證檢查本體論的概念與關係是否被正確地使用。

3. Operational Validation / 3. 操作驗證¶

Operational validation determines whether the rule can actually be evaluated.

操作驗證判定該規則是否實際上可被評估。

4. Epistemic Validation / 4. 知識論驗證¶

Epistemic validation checks whether the conclusion overstates the available evidence.

知識論驗證檢查結論是否誇大了現有的證據。

It should also identify conclusions that appear deterministic even though the source knowledge is probabilistic or advisory.

它也應辨識出那些看似確定性、但其來源知識實為機率性或建議性的結論。

Every production rule should include at least:

每一條生產環境規則至少應包含：

a positive test;
a negative test;
a boundary test;
a missing-data test;
an out-of-scope test.
一項正向測試；
一項負向測試；
一項邊界測試；
一項資料缺失測試；
一項超出範圍測試。

Validation makes the generated rule not only technically executable, but semantically and operationally trustworthy.

驗證使得生成的規則不僅在技術上可執行，更在語意與操作上值得信賴。

10. From Extraction Pipeline to Knowledge Lifecycle / 10. 從抽取管線到知識生命週期¶

Ontology-guided rule generation should be treated as part of a broader knowledge lifecycle.

本體論引導的規則生成，應被視為一個更宏觀的知識生命週期 (knowledge lifecycle) 的一部分。

Acquire  
   ↓  
Extract  
   ↓  
Model  
   ↓  
Contextualise  
   ↓  
Generate Rules  
   ↓  
Validate  
   ↓  
Approve  
   ↓  
Execute  
   ↓  
Observe Outcomes  
   ↓  
Refine Knowledge

Knowledge is first acquired from documents, experts, data and operational systems. It is then extracted and represented using ontology-aligned concepts and relationships.

知識首先從文件、專家、資料與營運系統中取得。接著，它會被抽取出來，並使用與本體論對齊的概念與關係加以表述。

General knowledge is contextualised and transformed into rule drafts.

通用知識會被情境化，並轉化為規則草稿。

Approved rules are executed within decision systems, reasoning engines, workflows or applications.

已核准的規則會在決策系統、推理引擎、工作流程或應用程式中被執行。

The resulting outcomes should feed back into the knowledge system.

所產生的結果應回饋到知識系統中。

The organisation should be able to ask:

組織應能夠提出以下問題：

Which rules were triggered?
Which conclusions were accepted?
Which recommendations were rejected?
Which evidence was commonly missing?
Did the expected outcome occur?
Were there false positives?
Does the rule require a narrower scope?
Should the underlying knowledge be revised?
哪些規則被觸發了？
哪些結論被接受了？
哪些建議被拒絕了？
通常缺少哪些證據？
預期的結果是否發生了？
是否存在誤報 (false positives)？
該規則是否需要更狹窄的範圍？
底層知識是否應被修訂？

This feedback turns the rule repository into a governed knowledge product rather than a static collection of expert logic.

這種回饋使規則儲存庫成為一項受治理的知識產品，而非一堆靜態的專家邏輯集合。

The lifecycle is especially important because both enterprise context and domain knowledge change over time.

這個生命週期尤其重要，因為企業情境與領域知識都會隨時間而改變。

New evidence may challenge an existing rule. A process may be redesigned. A product configuration may change. A regulation may be updated. A threshold may no longer be appropriate.

新的證據可能對既有規則構成挑戰。流程可能被重新設計。產品組態可能改變。法規可能被更新。某個閾值可能不再適用。

Summary / 總結¶

From Searchable Knowledge to Operational Knowledge

從可搜尋的知識到可操作的知識

Ontology-guided knowledge extraction represents a shift in how enterprise knowledge systems are designed.

本體論引導的知識抽取，代表了企業知識系統設計方式上的一次轉變。

The goal is to transform unstructured expertise into knowledge that can be contextualised, evaluated, governed and used responsibly.

其目標是將非結構化的專業知識，轉化為能夠被情境化、評估、治理並負責任地使用的知識。

Several architectural principles underpin this pattern.

有數項架構原則支撐著此模式。

1. Extract Relationships, Conditions and Constraints / 1. 抽取關係、條件與約束¶

Knowledge extraction should identify more than terminology.

知識抽取所辨識的應不僅是術語。

It should capture:

它應捕捉：

conditions;
effects;
exceptions;
variables;
constraints;
observations;
evidence;
applicability.
條件；
效應；
例外；
變數；
約束；
觀測；
證據；
適用性。

2. Separate General Knowledge from Local Context / 2. 將通用知識與在地情境分離¶

A reusable domain principle should not be embedded directly into a single product, process, customer or application implementation.

一項可重複使用的領域原則，不應被直接嵌入到單一的產品、流程、客戶或應用程式實作之中。

General knowledge should remain independent and be contextualised through explicit bindings.

通用知識應保持獨立，並透過明確的繫結來加以情境化。

3. Treat the Ontology as a Control Plane / 3. 將本體論視為控制平面¶

The ontology guides:

本體論引導：

extraction;
terminology alignment;
semantic-role identification;
context binding;
data mapping;
validation;
explanation.
抽取；
術語對齊；
語意角色辨識；
情境繫結；
資料映射；
驗證；
解釋。

It provides the semantic contract connecting documents, graphs, rules and applications.

它提供了連接文件、圖、規則與應用程式的語意契約。

4. Generate a Neutral Rule Before Executable Code / 4. 在可執行程式碼之前先生成中立規則¶

The intermediate representation preserves:

中介表述保留了：

meaning;
provenance;
assumptions;
scope;
missing information;
review status.
意義；
來源出處；
假設；
範圍；
缺失的資訊；
審查狀態。

Executable code should be generated only after the semantic rule has been validated and approved.

唯有在語意規則經過驗證與核准之後，才應生成可執行的程式碼。

5. Never Invent Missing Thresholds or Inputs / 5. 絕不憑空捏造缺失的閾值或輸入¶

Unknown information should be represented as a knowledge gap.

未知的資訊應被表述為一個知識缺口。

The system should identify:

系統應辨識出：

missing fields;
missing observations;
missing thresholds;
missing evidence;
unresolved mappings.
缺失的欄位；
缺失的觀測；
缺失的閾值；
缺失的證據；
未解決的映射。

Silently inventing these values turns an assisted knowledge process into an unreliable one.

默默地捏造這些值，會將一個受輔助的知識流程變成一個不可靠的流程。

6. Preserve Uncertainty and Causal Strength / 6. 保留不確定性與因果強度¶

Candidate causes should remain candidate causes.

候選原因應始終保持為候選原因。

Correlations should remain correlations.

相關性應始終保持為相關性。

Recommendations should not automatically become mandatory actions.

建議不應自動變成強制性的行動。

The rule model must represent the strength and status of every conclusion.

規則模型必須表述每一項結論的強度與狀態。

7. Make Provenance Part of the Rule / 7. 讓來源出處成為規則的一部分¶

A rule without traceable evidence cannot be properly reviewed, explained or audited.

一條缺乏可追溯證據的規則，無法被妥善地審查、解釋或稽核。

The knowledge source, ontology bindings, data sources and approval history should travel with the rule throughout its lifecycle.

知識來源、本體論繫結、資料來源與核准歷史，應在規則的整個生命週期中隨其一同流轉。

8. Keep Humans Responsible for Activation / 8. 讓人類為啟用負責¶

AI systems can accelerate data extraction, interpretation, binding, mapping, drafting, validation and even test generation, but authorised experts remain responsible for approving operational use, especially where rules affect safety, compliance, financial outcomes or customer decisions.

AI 系統可以加速資料抽取、詮釋、繫結、映射、草擬、驗證，甚至測試生成，但獲授權的專家仍負責核准實際的操作使用，尤其是在規則影響到安全、合規、財務結果或客戶決策之處。

Enterprise knowledge can be understood across three levels of maturity:

企業知識可以從三個成熟度層級來理解：

Level 1 — Searchable knowledge
Facts can be found.

第一層——可搜尋的知識
事實可以被找到。

Level 2 — Connected knowledge
Facts can be traversed and interpreted in context.

第二層——已連接的知識
事實可以在情境中被遍歷與詮釋。

Level 3 — Operational knowledge
Facts can support governed decisions, rules and actions.

第三層——可操作的知識
事實可以支援受治理的決策、規則與行動。

Ontology-guided knowledge extraction is therefore not simply a better way to populate a knowledge graph, but rather an architecture pattern for turning documents, data and expert knowledge into contextualised, testable and governable operational knowledge.

因此，本體論引導的知識抽取，並不只是填充知識圖譜的一種更好方法，而是一種將文件、資料與專家知識轉化為情境化、可測試且可治理之可操作知識的架構模式。

🔤 關鍵術語¶

英文	繁中譯名	文章中的脈絡 / 簡短說明
Ontology	本體論 / 領域本體	全文核心；不只作為抽取 schema，更作為引導知識詮釋、規則生成與治理的「語意控制層」
Knowledge Extraction	知識抽取	從文件中辨識實體、關係與事實的流程；本文主張進一步抽取「結構化知識陳述」
Knowledge Graph	知識圖譜	知識抽取管線的產出，用於搜尋、探索與語意整合
Graph RAG	圖譜檢索增強生成	描述性事實可支援的應用之一（搜尋、發現、語意整合）
Semantic Control Layer	語意控制層	本體橫跨抽取、脈絡化、規則生成與驗證的角色定位
Semantic Role	語意角色	本體定義規則中參與者的功能（主體、條件、觀察、證據、結論等）
Contextualised Rule	脈絡化規則	Level 2 規則；將通用原則綁定到特定營運環境
Diagnostic Rule	診斷規則	Level 3 規則；納入觀察、事件、量測後產生候選結論
Provenance	溯源 / 出處	保留來源文件、章節、句子、抽取信心，使規則可追溯至支持知識
Epistemic Status	知識論狀態 / 認知狀態	明確表達結論屬確認、候選、相關或證據不足，避免將關聯誤作因果
OWL	網頁本體語言	支援邏輯一致性推理
SHACL	形狀約束語言	驗證圖結構、必要屬性與資料品質條件
SPARQL	SPARQL 查詢語言	已核准規則可編譯成的執行技術之一
SWRL	語意網規則語言	中介規則可編譯的目標規則語言之一
Cypher	Cypher 查詢語言	圖資料庫的執行語言；直接由文件生成被視為有風險
Domain and Range	定義域與值域	本體約束用於驗證關係的合法性
Cardinality	基數	本體約束項目之一，限制關係數量
Canonical Concept	規範概念	本體提供的標準概念與映射，用以對齊來源詞彙
Intermediate Rule Representation	中介規則表示	分離「意義／脈絡／執行技術」三關注點的中立規則格式
Reasoning Engine	推理引擎	已核准規則得以執行的決策系統之一