論文閱讀分析：用本體論與大型語言模型打造透明化 CTI 結構化輸出
論文基本資訊
- 論文標題：Enabling Transparent Cyber Threat Intelligence Combining Large Language Models and Domain Ontologies
- 來源：XAI-KRKG@ECAI 2025 Workshop / arXiv
- 年份：2025
- 作者：Luca Cotti、Anisa Rula、Devis Bianchini、Federico Cerutti
- 論文連結：https://arxiv.org/abs/2509.00081
- 主題：CTI、LLM、Ontology、SHACL、Structured Output、Explainable AI、Log-based Intelligence Extraction
這篇 Enabling Transparent Cyber Threat Intelligence Combining Large Language Models and Domain Ontologies 的核心問題很有代表性：當我們用 LLM 從資安日誌或安全事件文本中抽取威脅情報時，怎麼避免輸出只是看起來合理、但結構不穩、語義不一致、難以驗證的自由文字？
作者的答案不是再加更大的模型，而是把 domain ontology 與 SHACL constraints 接進 LLM pipeline，讓模型的輸出從一開始就被約束為較可驗證、可結構化、可進一步查詢的形式。換句話說，這篇論文真正關心的不是單純的 extraction accuracy，而是：如何把 LLM 的輸出從黑箱文字，變成透明、可檢查、可落到知識圖結構中的 CTI 資料。
研究問題
這篇研究處理的場景，和一般從 threat reports 中抽 IOC / TTP 稍有不同。作者聚焦的是 cybersecurity system logs 與偏日誌型、事件型的資料來源，特別是 honeypot logs 這種幾乎全是惡意活動的環境。
在這類資料中，常見困難包括：
- log entries 天然缺乏結構一致性
- 同一事件可能以不同語言表達
- 有些訊息模糊、片段化、甚至語義不完整
- LLM 即使抽出資訊，也可能產生 schema 不一致或語意不合法的結果
因此，作者實際要解決的問題可以寫成：
- 如何讓 LLM 從資安日誌中抽出的資訊，不只是自然語言摘要，而是可被語義系統接受的結構化知識？
- 如何在 extraction 階段就加入 ontology-level constraints，降低語意不一致與結構錯誤？
- 如何提升 extraction 的 explainability，讓輸出可被後續 graph-based analysis 與查詢使用？
方法概觀
這篇論文提出的方法，核心是把三個元素接在一起：
- LLM：負責從非結構化安全日誌中萃取資訊
- Domain Ontology：定義可接受的概念類型與語義關係
- SHACL Constraints：對輸出圖結構做驗證與約束
整體 pipeline 可以概括成：
Cybersecurity logs
↓
LLM-based information extraction
↓
Ontology-driven structured output generation
↓
SHACL-based semantic validation
↓
Ontology-enriched graph database
↓
semantic analysis / querying / downstream CTI use這條 pipeline 的關鍵不在於「把 log 轉成文字摘要」，而在於「把 log 轉成能落進知識圖系統的結構化圖資料」。
核心設計一：Ontology-Driven Structured Outputs
這篇論文最重要的概念之一，就是 ontology-driven structured outputs。它的基本想法是：不要讓 LLM 自由生成一大段 extraction 結果，而是讓模型在一個由領域 ontology 預先界定好的語義空間中輸出。
這樣做有幾個好處：
- 避免同一概念被模型用不同名字反覆表示
- 讓輸出更容易映射到 graph schema
- 降低自由生成導致的 relation inconsistency
- 使後續查詢與 reasoning 更穩定
從知識表示角度看，這其實是在把 LLM 從「自由文本產生器」往「受約束的語義抽取器」方向推。這個設計非常適合 CTI，因為 CTI 本來就不是只要寫得通順，而是要能落進結構化情資流程。
核心設計二：SHACL-Based Constraints
另一個技術重點是 SHACL。SHACL（Shapes Constraint Language）本來就是拿來驗證 RDF / graph data 是否符合既定 schema 與限制條件的語言。作者把它用在這篇裡，目的是在 LLM 輸出轉成圖之後，進一步驗證：
- 節點類型是否合理
- 屬性是否缺失
- 關係是否符合定義
- 整體 graph 是否滿足 ontology 預期的形狀與語義規則
這一點非常關鍵。因為很多 LLM + KG 系統只做到「讓模型吐三元組」，但沒有真的檢查這些三元組是否語義合法。結果就是表面上結構化了，實際上卻充滿類型錯誤、角色錯置與邊關係不一致。
作者在這裡做的改進，是把 semantic validity 明確納入 pipeline。也就是說，模型不是只需要產出 something that looks structured，而是要產出 something that satisfies ontology + SHACL constraints。
核心設計三：Ontology-Enriched Graph Database
抽出的資訊最後不是停在 JSON 或表格，而是被組織進 ontology-enriched graph database。這意味著系統的終點不是 extraction 本身，而是後續可做：
- semantic querying
- graph traversal
- 關聯分析
- 未來的知識整合與 reasoning
這和前面幾篇 CTI KG 文章有一個有趣的差異：前面的研究比較偏向從報告、論壇、威脅文章中抽取知識；這篇則更強調從 log-based inputs 做 extraction，並以 ontology 為支架，直接把輸出收斂成可查詢圖結構。
為什麼 honeypot logs 是合理場景？
作者特別提到，整個方法的設計動機和 honeypot log analysis 有關。這是合理的，因為 honeypot logs 有幾個特性：
- 幾乎全是惡意或可疑活動
- 資料量大、重複模式多
- 對 analyst 來說閱讀成本高
- 很適合作為觀察攻擊行為與抽取 CTI 的原始素材
不過作者也說明，雖然方法設計動機來自 honeypot 場景，實驗評估則採用公開資料集，而不是只在私有 honeypot log 上做封閉測試。這使方法比較有外部可比性。
這篇論文真正想修補的是什麼缺點？
這篇研究真正批評的，不是 LLM 本身不夠強，而是傳統 prompt-only 方法有幾個系統性缺陷：
- 輸出格式容易漂移
- 語義類型不夠穩定
- 關係與實體對應常不一致
- 很難直接接進 graph-based analysis pipeline
- 分析師不容易理解或驗證模型輸出
所以作者的方法其實是在補一個很重要、但常被忽略的層：從生成式抽取走向可驗證知識表示的中介層。
實驗結果
根據摘要，作者的結果顯示：
- 方法在 information extraction accuracy 上優於傳統 prompt-only baseline
- 其設計重點刻意放在 extraction quality，而不是處理速度
這一點很值得肯定，因為很多論文會把效能、速度、靈活性、泛化性全部一起講，但這篇反而很明確：作者最在乎的是 extraction 是否更準、更透明、更能被語義系統接受，而不是是否跑得更快。
從研究設計的角度看，這種取捨是合理的。因為在 CTI 場景裡，若 extraction 本身不可靠，後面再快都沒有意義。
這篇論文的技術價值
如果把這篇論文放在整個 CTI × LLM 的脈絡裡，它的價值可以理解為：
- 不是只做 extraction
- 不是只做 explainability
- 而是把 structured extraction + semantic validation + transparent knowledge representation 放進同一條流程裡
這一點很重要。因為目前很多資安 LLM 系統要嘛只回答問題、要嘛只抽三元組、要嘛只做一點 graph visualization，但很少真正處理「如何確保輸出符合領域本體與語義限制」這個問題。
這篇論文正好補上這一塊。
和 RAGRecon、KGV、LRCTI 的關係
如果把這篇放進你現在站上的系列脈絡，位置大概是這樣：
- KGV / LRCTI：偏向 CTI credibility verification
- RAGRecon：偏向 explainable CTI question answering
- 這篇 ontology-driven paper：偏向 explainable structured extraction from logs / events
也就是說，它的貢獻點更接近「讓 CTI extraction 的結果從一開始就更適合被知識系統接收」，而不是把 extract 完的東西再拿來問答或驗真。
限制與值得進一步關注的點
這篇論文雖然方向很好，但也有幾個值得後續觀察的地方：
- 對 ontology 品質有依賴：若領域 ontology 本身不完整，structured output 再受約束也會受限
- SHACL 驗證能保證結構合法，不等於語意一定正確：圖形狀正確，不代表抽出的 threat semantics 一定對
- 偏 log-based intelligence extraction：和純報告型 CTI extraction 的困難點不完全相同
- 速度被刻意放在次要位置：若要進 SOC 即時分析流程，未來仍需考慮 latency 與 cost
不過即便如此，這篇論文仍然非常值得注意，因為它處理的是一個非常基礎的問題：怎麼讓 LLM 輸出真的能被知識工程流程接住。
重點整理
- 這篇論文提出一套將 LLM + domain ontology + SHACL constraints 結合的 CTI extraction 方法。
- 目標是從 cybersecurity logs 中抽出透明、可驗證、可結構化的威脅情報。
- ontology-driven structured outputs 用來限制模型輸出語義空間。
- SHACL-based validation 用來檢查輸出圖是否符合結構與語義規則。
- 抽出的結果會進入 ontology-enriched graph database，支援後續 semantic querying 與 graph analysis。
- 作者強調方法的重點在於 extraction quality 與 explainability，而不是速度。
- 相較傳統 prompt-only 方法，該方法在 extraction accuracy 上有提升。
Takeaway
這篇論文最值得記住的一點，是它把資安領域裡一個常見但被低估的問題講清楚了：LLM 產生的文字結果，如果沒有 ontology 與 constraints 的支撐，往往很難真正成為可靠的 CTI 結構化資產。
作者的方法提醒我們，若想把 LLM 真正帶入 CTI pipeline，不能只追求「抽得出來」，還要思考「抽出來的東西能不能被驗證、能不能被圖資料庫接受、能不能被後續分析重用」。從這個角度來看，ontology-driven structured outputs 不是額外裝飾，而是讓透明化 CTI 成立的基礎。
免責聲明
本文由 AI 整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。