CyberThreat-Eval 論文閱讀分析：我們終於開始用接近真實 analyst workflow 的方式評估 CTI LLM 了嗎？
論文基本資訊
- 論文標題：CyberThreat-Eval: Can Large Language Models Automate Real-World Threat Research?
- 作者：Xiangsen Chen、Xuan Feng、Shuo Chen、Matthieu Maitre、Sudipto Rakshit、Diana Duvieilh、Ashley Picone、Nan Tang
- 來源：Transactions on Machine Learning Research (TMLR)，亦公開於 arXiv:2603.09452
- 年份：2026
- 主題：CTI、OSINT、LLM Evaluation、Benchmark、Threat Research Workflow、SOC
- 論文連結：https://arxiv.org/abs/2603.09452
本文由 AI 產生、整理與撰寫。
如果前面幾篇 CTI / AI 論文已經把 benchmark、RAG、agentic SOC workflow、規則生成一路鋪開，那麼這篇 CyberThreat-Eval 值得接在後面，因為它把問題重新拉回一個很務實、也很少被 benchmark 真正正面處理的地方：今天我們到底是在評估模型會不會答資安題，還是在評估它能不能真的幫分析師做 threat research？
這兩件事看起來很像，其實差很多。很多既有 benchmark 會問模型 ATT&CK、CVE、threat actor attribution、漏洞知識或多選題推理；但真實世界裡的 CTI 分析師不會每天坐在那裡做選擇題。他們面對的是一篇剛冒出來的 OSINT 報導、一串線索還不完整的 incident 記述、幾個彼此重疊或互相矛盾的外部來源，然後必須一路做完：先 triage、再 deep search、最後把材料整理成可以給客戶或內部團隊採用的 threat intelligence draft。
CyberThreat-Eval 的價值，就在於它不再把 CTI automation 看成幾個零碎的小題目，而是嘗試沿著真實 analyst workflow 去問：模型在這整條鏈上，到底哪裡做得到、哪裡其實還差得遠？
這篇論文真正瞄準的，是「工作流落差」而不是單點能力落差
作者一開頭就點出三個既有 CTI benchmark 的核心問題，而我認為這三點抓得很準。
- 第一，任務格式太像考試，不像工作。 多選題、Q&A、事實回憶，容易測，但很難代表分析師真正在做的判斷。
- 第二，評估指標太偏模型中心，不偏分析師中心。 ROUGE、BERTScore、Exact Match 可以算，但不一定等於內容真的有用。
- 第三，幾乎沒有 benchmark 真正覆蓋完整的 end-to-end threat research workflow。
這個批評不是在否定 CTIBench、CyberMetric、SEvenLLM、CTISum 這些前面已經很有貢獻的工作，而是指出：它們大多在回答「模型在某個 CTI 子任務上強不強」，但還沒有完整回答「模型能不能接住現場分析流程」。
而 CyberThreat-Eval 想補的，就是這個落差。作者把真實 threat research workflow 拆成三個階段：
- Triage：先判斷一篇文章值不值得收、要不要進一步分析、優先級多高。
- Deep Search：沿著 seed article 往外搜尋，看能不能找到真正有新增價值的補充來源。
- TI Drafting：把 incident 相關資訊整理成可讀、可用、可交付的 intelligence 內容，包括 IoC、TTP、threat actor 與 root cause 敘事。
這種切法很合理，因為它不是抽象地談「CTI 能力」，而是直接對應到 analyst 每天會做的事。也因此，這篇論文的 benchmark 比較像是在測一個模型能不能進工作現場，而不只是能不能在 leaderboard 上答對更多題。
CyberThreat-Eval 的資料從哪裡來？為什麼這很重要？
論文強調，這套 benchmark 不是純粹靠公開資料庫拼湊，也不是由研究者自己想像 analyst 可能怎麼工作；它是從一家世界級科技公司的日常 CTI workflow 中抽出來，並由專業分析師做標註與驗證。
這種資料來源的意義很大，因為它讓 benchmark 至少更接近兩件事：
- 真實任務分佈：模型面對的不是被過度簡化的 benchmark 題型，而是接近 production analyst 的輸入樣貌。
- 真實評估標準：好壞不是只看語言重疊，而是看 analyst 在乎的可用性、正確性與成本。
論文中給出的資料規模雖然不算巨大，但很有代表性：
- Triage：488 篇文章
- Deep Search：55 個輸入 URL
- TI Drafting：1310 個 IoCs、1565 個 TTPs、412 篇文章用於 threat actor / root cause 生成評估
這裡有一個很值得注意的訊號：作者沒有一味追求資料量，而是選擇讓每個 task 都維持明確的 analyst-facing 定義。這種 benchmark 可能不像大規模 MCQ 題庫那樣容易做出漂亮數字，但它的可解釋性通常更高，也更能告訴你模型到底卡在哪。
第一階段：Triage 不只是「有沒有關」，而是「值不值得投入分析資源」
在真實 CTI 流程裡，triage 是一個很容易被低估的步驟。很多人會以為 triage 只是把不相關文章篩掉，但其實它在做的是更實際的資源配置：這篇 incident 值不值得分析？如果值得，要排多前面？
CyberThreat-Eval 在 triage 階段設計了兩個任務：
- Article triage：判斷文章該不該接受進一步分析。
- Priority score assignment：對被接受的文章分配優先級。
這個設計非常合理，因為它把判斷拆成兩層：
- 先看有沒有值得追的 threat subject / target / actionable signals
- 再看它到底有多重要、多急、多值得投入 analyst 時間
而論文的關鍵發現也很有現場感：LLM 在 triage 上往往 recall 不錯，但 precision 不高。 換句話說，模型通常比較不想漏掉東西，所以傾向把很多文章都收進來；但這在現場不一定是好事，因為它會讓 analyst 被更多低價值項目淹沒。
這其實點出一個很重要的 operational reality：在 security workflow 裡，高 recall 不必然等於高價值。 如果一個 triage assistant 幾乎什麼都說重要，那它在組織內部最終扮演的不是效率放大器，而是額外噪音來源。
第二階段：Deep Search 測的不是「找得到連結」，而是「能不能找出真的有新增資訊的來源」
我覺得這篇論文最有意思的一段，是它對 deep search 的定義非常實務。它不是讓模型單純回傳一些相關網址，也不是用傳統資訊檢索那種表面相關度就算分，而是進一步問：你找回來的這些 URL，是否真的提供了 seed article 沒有的新增價值？
這是現場 analyst 真正在乎的事。因為 deep search 的目的從來不是把相似報導找得更多，而是補齊 incident 的盲點，例如：
- 更多技術細節
- 不同廠商的調查觀點
- 額外的 IoC / TTP 線索
- 對 threat actor、timeline、impact 的補充資訊
論文採用的做法，是把候選 URL 的內容拿去和原始 seed article 比較，再由 LLM-based expert judge 判斷它是否真的包含「additional information」。換句話說，這裡測的不是搜尋系統表面上的相關性，而是檢索結果的增益品質。
而從實驗結論來看，base models 在 deep search 階段往往能找回更多有價值的 URL。這意味著：LLM 在資訊擴展與線索追索上，確實已經有一定可用性。 但問題在於，搜尋只是開始，後面的篩選、交叉驗證與證據整合仍然很難完全自動化。
也就是說，今天的模型可能已經能當一個不錯的「搜尋副駕」，但還很難獨立成為一個可以放心交辦完整 threat research 的 lead analyst。
第三階段：TI Drafting 是真正把模型拉離「抽題作答」舒適圈的地方
CyberThreat-Eval 的重頭戲，毫無疑問是 TI drafting。因為到了這一階段，模型不再只是做分類或檢索，而是必須把資料轉成 analyst 看得懂、團隊用得上、甚至能成為最終報告一部分的內容。
論文在這裡主要測四類能力：
- IoC extraction
- TTP identification
- Threat actor generation
- Root cause generation
這四項其實剛好對應了 threat research 裡四種很不同的 cognitive load。
- IoC extraction 偏結構化抽取，答案相對明確。
- TTP identification 開始涉及專業判斷與 ATT&CK mapping。
- Threat actor generation 需要跨段落整合敘事與歸因線索。
- Root cause generation 更進一步要求模型說清楚事件背後的因果鏈。
而結果非常有代表性：模型在 IoC 這種偏結構化工作上已經有一定實用性，但在 TTP 抽取與 mapping 上仍然明顯吃力；相較之下，它們在 root-cause narrative 的生成上反而表現得更像樣。
這個現象很值得細想。很多人直覺會以為，生成式模型最不可靠的就是 narrative，最穩的應該是 ATT&CK 對應。但論文呈現的卻是另一個現實：對 LLM 來說，把故事講順不見得難；真正難的是把那些故事精確地壓回嚴格定義的安全知識框架。
這也解釋了為什麼很多 security use case 看起來 demo 很漂亮，到了 production 卻會卡住。因為 stakeholder 常常先看到的是敘事流暢度，但 analyst 真正痛的地方，往往是 schema alignment、taxonomy precision 與 evidence-grounded mapping。
這篇論文最成熟的地方：它把成本正式拉回評估桌上
我認為 CyberThreat-Eval 有一個很值得肯定的地方，是它沒有只談正確率，還把 time spent、token cost、content quality、factual accuracy 這些 analyst 更在乎的維度一起納入。
這件事很重要，因為真實世界裡的 CTI automation 從來不是「哪個模型分數最高就贏」。真正的問題通常是：
- 它能不能在合理時間內完成？
- 它的 token 成本會不會高到不能大規模部署？
- 它給出的內容是可採用的，還是只是看起來很像？
- 它會不會把 analyst 的複核成本轉移成另一種更隱性的運維負擔？
如果 benchmark 只看 lexical overlap，那你很容易錯把「語句像 reference answer」當成「真的能用」。CyberThreat-Eval 則更接近一種 operational benchmark：它在問的不是模型能不能答，而是它值不值得被放進工作流。
論文的核心結論：LLM 比較像強力助手，還不像能獨立交件的分析師
綜合整篇論文的結果，我認為作者其實傳達了一個非常清楚、也相對克制的訊息：目前的 LLM 已經能在 threat research workflow 的某些環節提供實質幫助，但距離端到端自動化還有一段不小的距離。
比較具體地說：
- 在 triage，模型能幫你抓出可疑與可能重要的事件，但 precision 仍然不足，容易帶入噪音。
- 在 deep search，模型能幫你擴展資料來源與外部線索，適合當 research accelerator。
- 在 TI drafting，模型對 IoC 抽取與 narrative 生成有一定價值，但在 TTP mapping、細節辨真與知識框架對齊上還不夠穩。
所以更準確的描述不是「LLM 已經能取代 threat researcher」，而是：它已經能成為 workflow 中某些環節的高槓桿輔助者，但前提是你把它放在對的位置，並保留外部知識庫與 human-in-the-loop。
TRA 為什麼重要？因為這篇論文沒有停在批評模型，而是把補救架構也說出來
論文最後提出的方向很務實：既然模型目前還不夠可靠，那真正可行的 CTI workflow 就不該是「把所有事情一次丟給 LLM」，而應該是把兩種東西重新接回來：
- External ground-truth databases
- Human expert feedback loop
作者用 TRA 來描述這種改進後的流程。雖然從論文摘要與主文可見資訊來看，TRA 更像是一種 workflow augmentation 思路，而不是單一神奇模型，但這恰恰是它比較成熟的地方。它承認了一個現實：CTI automation 的瓶頸，不只在模型大小或 prompt engineering，而在於你有沒有把驗證機制、知識依據與專家修正正式編進流程。
這點和近期很多 agentic security 論文其實互相呼應。真正能落地的系統，很少是「一個超強模型包辦全部」，而比較像：
- 模型負責加速搜尋、整理、起草與候選生成
- 外部知識庫負責提供 grounding
- 人類分析師負責最後的判斷、修正與責任承擔
怎麼看這篇論文在近期 CTI / AI 脈絡中的位置？
如果把近期幾條主線放在一起看，CyberThreat-Eval 的角色很清楚。
- 像 CTIBench、AthenaBench、AttackSeqBench、CyberMetric 這些工作，幫我們建立了各式 CTI / cybersecurity benchmark 的能力地圖。
- 像 CyberRAG、CORTEX、FALCON、Using LLMs to Automate Threat Intelligence Analysis Workflows in SOC 這些工作，則開始把模型往更接近實務流程的應用端推。
- CyberThreat-Eval 則剛好站在中間：它不是單純講應用，也不是只做知識題 benchmark，而是用 benchmark 形式直接檢驗 workflow-level automation 到底成熟了多少。
這使它特別有價值。因為當產業開始認真討論「AI agent 能不能進 threat research team」時，最缺的往往不是更多炫技 demo，而是這種能夠老實告訴你：目前哪些環節已經能放，哪些環節還不能放，放了之後成本與風險是什麼。
我的看法：這篇論文不是在證明 LLM 很強，而是在幫產業戒掉過早樂觀
我自己很喜歡這篇的一點，是它沒有落入兩種極端：
- 不是那種「LLM 什麼都做得到，馬上全自動化」的樂觀宣傳。
- 也不是那種「LLM 全都不可靠，所以毫無價值」的全面否定。
它真正說的是：LLM 已經足夠強到讓 threat research workflow 發生結構性變化，但還沒有強到可以把 analyst 從回路裡完全拿掉。
而且它進一步把這件事講得更具體：模型最容易讓人誤判實力的地方，往往不是它不會說，而是它太會說。它可以寫出看起來合理的 threat narrative，可以給你像模像樣的 root-cause 解釋，但一旦進入需要精準 mapping、真偽辨識、細節歸因與 operational prioritization 的地方，錯誤就會開始浮出來。
這其實正是現代 security AI 最需要的清醒感。不是因為模型不夠厲害，而是因為 threat research 從來就不是只靠語言流暢度決定成敗的工作。它牽涉的是證據、脈絡、框架對齊、風險判斷與責任邊界。
總結
CyberThreat-Eval 是一篇很值得放進近期 CTI / AI 閱讀清單的論文，因為它不是再做一個更大的分數表，而是直接把評估問題拉回 analyst workflow 本身。
它最重要的貢獻有三個：
- 把 CTI benchmark 從 quiz-style 任務，往真實 threat research workflow 推進。
- 把 analyst-centric metrics 拉進主舞台，讓正確率不再是唯一答案。
- 用實驗結果清楚指出：LLM 已可成為高槓桿輔助者，但尚不足以獨立完成端到端威脅研究。
如果你正在思考怎麼把 LLM 放進 SOC、CTI 或 threat research pipeline，這篇論文提供的最大價值，不是給你一個「可以全自動化」的幻想，而是給你一個更接近現實的設計原則：把模型用在它最擅長的加速點，把知識庫與專家審核留在它還無法跨過的關卡。
從這個角度看，CyberThreat-Eval 不只是在評模型，也是在替整個產業補上一堂很必要的課：我們真正要自動化的，不是答題，而是工作；而工作這件事，永遠比題目更難。