論文閱讀分析：大型語言模型其實不可靠於 Cyber Threat Intelligence
論文基本資訊
- 論文標題：Large Language Models Are Unreliable for Cyber Threat Intelligence
- 作者：Emanuele Mezzi、Fabio Massacci、Konrad Tuma
- 年份：2025
- 來源：arXiv:2503.23175v4
- 論文連結：https://arxiv.org/abs/2503.23175
- 主題：CTI、LLM Evaluation、Reliability、Consistency、Calibration、Threat Intelligence Extraction
這篇論文的價值，不在於它又做出一個新的 CTI assistant，而是它反過來問了一個更不舒服、也更重要的問題：如果我們真的把 LLM 放進真實世界的 CTI 流程，它到底靠不靠得住？
作者的答案相當直接：目前還不行，而且問題不只是準確率不夠而已。 真正危險的是三件事同時存在：第一，面對真實長篇 threat reports 時表現不夠好；第二，就算同一份報告、同一個問題、同樣設定重問多次，答案仍可能浮動；第三，模型常常錯得很有自信。如果你把這種系統接到威脅研判、漏洞修補優先序、APT 歸因或報告摘要流程裡，風險其實不小。
這篇論文想打破什麼迷思？
作者對近年 CTI × LLM 文獻有一個核心批判：很多研究的結果看起來很好，是因為測試資料太短、太乾淨、太不像現實。 過去不少論文只拿單句、短段落、甚至比這篇論文摘要還短的文字來做實驗，然後宣稱 LLM 可以有效抽取 APT、CVE、TTP 或建立 threat knowledge graph。
但 CTI 的麻煩就在於，真實世界的報告不是標註乾淨的 benchmark。它們往往很長、資訊混雜、上下文互相干擾，而且一份報告裡可能同時提到：
- 這次事件的真正攻擊者
- 其他曾用過類似手法的威脅組織
- 歷史案例中的相關漏洞
- 旁支說明、背景敘事與補充比較
這時候，模型最容易犯的錯不是完全看不懂，而是把相關但不屬於本案的資訊也當成答案抓進來。這會同時拉高 false positives 與 false negatives，對 CTI 來說比一般 FAQ 類任務嚴重得多。
三個研究問題：不只看準確率，還看穩定性與信心是否可信
這篇論文的設計很完整，作者不是只問「LLM 做 CTI 準不準」，而是拆成三個研究問題：
- RQ1：LLM 在真實尺寸的 CTI 報告上，資訊抽取與資訊生成表現如何？
- RQ2：對同一輸入反覆詢問時，LLM 的輸出到底有多一致？
- RQ3：模型給出的 confidence 能不能信？它是校準良好的，還是其實過度自信？
這三個問題放在一起看，才是這篇論文真正有分量的地方。因為 CTI 不是一般聊天應用；在沒有完整標註資料的實務環境裡，團隊很可能會拿模型信心值來決定「這個結果要不要採用」。如果模型本身不穩定、又沒校準好，那麼它看起來越自信，反而越危險。
資料集與模型：這次真的拿「像樣的」CTI 報告來測
作者使用的是 Di Tizio 等人整理的 APT 資料集，包含 350 份 threat intelligence reports，涵蓋 86 個 APT 群體。這個資料集的重點不是數量特別誇張，而是它的長度與異質性更接近真實世界：
- 平均每份報告約 3,009 words
- 最長可到 21,569 words
- 平均約 4,002 tokens
- 最長可到 27,794 tokens
這跟很多只拿 100 多字、幾百字片段做測試的研究完全不是同一個難度層級。
論文評估兩大任務：
- Information Extraction：從 threat report 中抽取 APT、Campaign、CVE、Attack Vector 等結構化資訊
- Information Generation：只給 APT 名稱與描述，要求模型生成其 country、label、goals、CVE、attack vectors 等資訊
使用的模型則是當時主流且具備大 context window 的三個閉源系統：
- gpt-4o
- gemini-1.5-pro
- mistral-large-2
此外作者也不是只看 zero-shot，而是連 few-shot learning 與 fine-tuning 都一起測，避免有人說「只是 prompt 沒調好」或「還沒針對資料微調」。
方法設計：五步評估流程
作者提出一個五步評估管線，依序檢查：
- Zero-shot 表現
- Few-shot 表現
- Fine-tuning 後表現
- 重複詢問下的 consistency 與 confidence intervals
- confidence calibration（ECE、Brier Score）
這裡最值得注意的是，論文不是把 few-shot 與 fine-tuning 當成「理所當然會變好」的補救手段，而是把它們本身也視為待驗證對象。這點很重要，因為在很多資安場景裡，大家常有一種直覺：只要多塞幾個例子、或再 fine-tune 一下，問題應該就解掉了。作者實際做完之後發現，事情遠沒有這麼樂觀。
RQ1：在真實 CTI 報告上，LLM 沒有想像中可靠
第一個核心結論很明確：一旦把評估環境換成真正長篇、雜訊多、敘事複雜的 threat reports，LLM 的表現就明顯沒有先前文獻講得那麼漂亮。
在 information extraction 任務中，作者指出：
- 最佳情況下，CVE 的 recall 約為 0.90，代表仍有約 10% 的漏洞會被漏掉
- Campaign entity 的 recall 可低到 0.72，也就是可能漏掉 28% 的 campaign 資訊
- Attack vector 的 recall 也並不理想，最低約 0.74
這些數字若放在一般內容分類任務，也許還能說「勉強可用」；但放到 CTI 場景就不是這回事。漏掉 10% CVE，可能代表修補優先順序出錯；漏掉 campaign 或 attack vector，可能代表對攻擊活動的理解與歸因都會偏掉。
更麻煩的是，few-shot 與 fine-tuning 並沒有穩定改善結果。作者觀察到：
- few-shot 有時不但沒幫助，反而讓表現下降
- fine-tuning 在部分項目甚至出現更嚴重退化
- 例如 APT 抽取的 precision / recall，在某些模型上從 0.87 掉到 0.68
- Campaign recall 在某些情況甚至從 0.72 掉到 0.58
這說明一件很重要的事：CTI 不是那種靠幾個 few-shot examples 就能補平資料複雜度的任務。 當報告本身太長、敘事太亂、背景知識太交錯時，模型的錯誤不是表面 prompt engineering 就能輕鬆修好的。
資訊生成也沒比較好：讓模型「憑內部知識」回答更危險
如果說 extraction 至少還有原始報告可依，那 information generation 就更值得提高警覺。這個任務要求模型根據 APT 名稱與描述，生成其國家、類型、目標、使用過的 CVE 與 attack vector 等資訊，本質上更接近很多人想像中的「CTI 助理」或「資安聊天機器人」。
結果並不好看。作者指出：
- APT label 的 recall 最低可到 0.02
- 國家歸屬即使是較好的模型，也仍有大約 20% 錯誤空間
- CVE 生成表現尤其差，某些 fine-tuned 情境下 recall 甚至變成 0.00
這個結果非常值得 CTI 團隊記住。因為很多產品 demo 看起來最吸引人的，就是「你只要問模型某個 APT，它就能即時講出背景、武器庫、目標與活動特徵」。但這篇論文指出，這種看似方便的生成式查詢，其實可能是最不該盲信的部分。
RQ2：同樣問題重問十次，答案還是會晃
第二個重點是 consistency。作者對每個任務、每個模型、同一輸入，重複詢問 10 次，而且還把 temperature 設成 0、seed 固定，盡量逼近「最 deterministic」的情境。照理說，這已經是最有利於穩定輸出的設定了。
結果仍然顯示：模型沒有完全一致。
作者使用 bootstrapping 為 precision、recall、F1 建立 confidence intervals，發現：
- 在 information extraction 任務，某些 entity 的 CI 寬度可達約 0.02
- 在 information generation 任務，不一致性更明顯，最大寬度可達約 0.06
這代表什麼？代表如果 SOC 分析師今天問模型「這份報告涉及哪些 CVE？」，明天同樣問題再問一次，可能得到不同答案；或者今天模型說某 APT 屬於某種類型，隔天又改口。這在閒聊場景或許無傷大雅，但放進漏洞處置、威脅歸因或情資摘要流程裡，就會產生真正的作業風險。
論文還用一個很直白的例子提醒讀者：如果重問兩次，模型給出兩個不同 CVE，那你到底該 patch 哪一個？ 這不是理論問題，是實務問題。
RQ3：最危險的部分是「錯得很有把握」
第三個研究問題談 calibration，我認為這是整篇最有殺傷力的部分。因為很多系統在沒有標註答案可對照時，會拿模型自己的 confidence 當成過濾門檻：高信心就採用，低信心就忽略。
但作者發現，這些模型在 CTI 任務上並沒有良好校準。他們以 gpt-4o 為例，從 log probabilities 推導每個 JSON 欄位的 confidence，然後計算：
- ECE（Expected Calibration Error）
- BS（Brier Score）
這兩個指標越接近 0 越好，代表模型的自信程度與真實正確率越對齊。結果卻顯示，不少欄位在 few-shot 或 fine-tuning 後不但沒改善，反而更糟。
幾個很關鍵的數字包括：
- Extraction 中的 campaign entity，fine-tuning 後 ECE / BS 可升到 0.48 / 0.48
- Generation 中的 CVE，fine-tuning 後 ECE / BS 可到 0.91 / 0.98
- Generation 中的 attack vector，fine-tuning 後甚至到 0.87 / 1.00
這些數字代表什麼？代表模型可能非常有自信地給出一個錯答案，而系統若把這個 confidence 視為可信訊號，就會把錯誤包裝成看似可靠的建議。這比單純 accuracy 低更危險，因為它更容易被自動化流程接受。
為什麼會這樣？作者給出的解釋很合理
作者認為問題的根源，不一定是模型被攻擊或被污染；即使在正常狀態下，LLM 也會因為真實 CTI 報告裡的相關雜訊太多，而把「背景資訊」誤當成「本案資訊」。
例如一篇報告主題明明是某個 APT 的某次 campaign，但文中可能還會提到：
- 別的 APT 也曾使用相似手法
- 歷史案例中的其他 CVE
- 同一攻擊者在不同事件裡用過的不同 attack vectors
這些內容對人類分析師來說是上下文；對模型來說，卻很可能都是候選答案。於是模型不是完全瞎猜，而是在大量「看起來都很像相關答案」的資訊中做出錯誤選擇。這也解釋了為什麼在短文本 benchmark 上看似很強，一旦換成完整報告就開始出問題。
這篇論文的最大貢獻，不是唱衰 LLM，而是幫 CTI 設定更成熟的驗證標準
我覺得這篇論文最值得稱讚的地方，是它不是簡單地說「LLM 沒用」。更準確地說，它是在提醒整個 CTI 社群：你不能只用短文本、單次推論、point estimate accuracy 來驗證一個會被部署到安全流程裡的模型。
如果未來有人要宣稱某個 CTI assistant 很強，至少應該同時回答：
- 它是在真實長篇 threat reports 上測的嗎？
- 它對同一輸入重跑多次會不會飄？
- 它的 confidence 有校準過嗎？
- few-shot 或 fine-tuning 是真的變好，還是只是表面上更像答案？
這些要求聽起來嚴格，但對資安系統來說其實只是基本功。因為 CTI 不是寫摘要、不是客服問答，也不是娛樂對話；它會影響人要不要 patch、要先 patch 哪裡、要不要歸因某個國家級 actor、以及是否把某份情資視為可信。
這篇論文的限制
當然，論文也有它自己的限制。作者很誠實地承認：
- 只評估了一個主要資料集，雖然這個資料集已經比很多研究更貼近真實
- 只測了三個主流模型，未涵蓋更多開源或更新世代系統
- calibration 分析主要能在具備 logprob 支援的模型上做，因此深度還受工具限制
- consistency 分析只重跑 10 次，是成本與可重現性之間的折衷
但說實話，這些限制並沒有削弱核心訊息。因為即使在這樣已經相對寬容的設定下，模型仍暴露出顯著問題，那只代表我們更沒理由在缺乏充分驗證時，就把它接進高風險流程裡。
我的總結
如果要我用一句話總結這篇論文，我會說：它不是在否定 LLM 的潛力，而是在阻止 CTI 社群過早相信一種還沒長好的能力。
這篇論文最值得記住的，不是哪一個模型輸了哪一個模型，而是三個更本質的提醒：
- 提醒 1：真實 CTI 報告比 benchmark 難太多，短文本成績不能直接外推到實務。
- 提醒 2：一致性本身就是安全需求，不是錦上添花的附加指標。
- 提醒 3：模型信心值如果沒校準好，會把錯誤包裝成看似可執行的建議。
對 SOC、threat hunters、CTI 平台開發者、以及想把 LLM 接進自動化分析流程的團隊來說，這篇文章幾乎是必讀。因為它逼你面對一件很現實的事：在資安裡，能回答，不代表能負責；會說得像真的，不代表真的能拿來做決策。
如果未來 CTI × AI 要走向可落地，我反而認為這種「先把不可靠性講清楚」的研究，比又多做一個 flashy demo 更有價值。它幫整個領域把標準拉回到一個成熟的位置：不是看模型多會講，而是看它在風險場景裡，到底值不值得信。