Policy-Guided Threat Hunting 論文閱讀分析：該讓 LLM 當 SOC 的大腦，還是當只處理高價值事件的後段分析官？

論文基本資訊

• 論文標題：Policy-Guided Threat Hunting: An LLM enabled Framework with Splunk SOC Triage
• 作者：Rishikesh Sahay、Bell Eapen、Weizhi Meng、Md Rasel Al Mamun、Nikhil Kumar Dora、Manjusha Sumasadan、Sumit Kumar Tetarave、Rod Soto、Elyson De La Cruz
• 來源：arXiv:2603.23966v2
• 年份：2026
• 主題：SOC、Threat Hunting、Splunk、Agentic AI、LLM、Deep Reinforcement Learning、MITRE ATT&CK
• 論文連結：https://arxiv.org/abs/2603.23966

本文由 AI 產生、整理與撰寫。

如果今天前面幾篇已經把 CTI benchmark、SOC alert triage、workflow automation、規則生成 幾條線各自鋪開，那接下來很自然會遇到一個更接近 production 的問題：在真實 SOC 裡，我們到底該把 LLM 放在哪一層？是讓它直接當第一線判官，還是把它放在比較後面的 contextual reasoning 與 analyst support 位置？

這篇 Policy-Guided Threat Hunting 有意思的地方，就在於它沒有單純把 LLM 當成萬能 triage 腦，也沒有停留在「再做一個會寫 SPL 的 Copilot」這種 assistive layer。作者試圖做的是更完整的一條鏈：先用 autoencoder 做 anomaly assessment，再用深度強化學習（DRL）做政策導向的 containment/allow 決策，最後只把高優先級流量交給 LLM 做 contextual analysis、MITRE mapping 與 Splunk investigation support。

換句話說，這篇論文真正想解的，不是「LLM 能不能幫 SOC」，而是：怎麼把 LLM 放進一個比較節制、比較成本敏感、也比較能跟 analyst workflow 對齊的 threat hunting pipeline 裡。

這篇的核心觀念很清楚：不要讓 LLM 處理全部流量，而是只處理被策略層挑出來的高價值事件

這個設計其實很務實。很多 security AI 論文的問題，不是它們不聰明，而是它們默默假設 token、latency、人工複核成本都不是問題。可是在 SOC 現場，這三樣東西幾乎永遠都是真問題。

因此作者在架構上做了一個很關鍵的切分：

• Autoencoder：負責學正常流量長什麼樣，輸出 anomaly score。
• DRL agent：負責在時間窗層級做 contain / allow 的策略決策。
• Prioritization：用 DRL action × anomaly score 算出優先級。
• LLM multi-agent triage：只分析真正高優先級的 flow，輸出 human-readable assessment、MITRE ATT&CK 對應與 Splunk SPL 建議。
• Human analyst + Splunk validation：最後仍由 SOC analyst 在 SIEM 裡驗證與做決策。

我認為這個切法比很多「什麼都交給大模型」的做法成熟，因為它承認了兩件事：

1. LLM 的價值在 contextual reasoning，不一定在第一層大量過濾。
2. 真實 SOC 的瓶頸常常不是會不會分析，而是能不能先把量壓下來。

這也讓它和今天一些只談 agent autonomy 的論文不太一樣。它沒有把 autonomy 神化，而是把 autonomy 放進一個有明確交通管制的架構裡。

論文想補的缺口，不只是 threat hunting automation，而是「政策導向」的自動化

作者在文中反覆強調一件事：不同 SOC 對 false positive、false negative、containment cost 的容忍度根本不一樣。

這件事很重要。因為很多 security 模型論文最後都會掉進同一個陷阱：它們把最佳化目標寫成一組固定分數，彷彿每個 SOC 都追求相同的 precision / recall 平衡。但現實不是這樣。

• 有些環境更怕漏報，所以寧願多抓一些。
• 有些環境更怕 false positive 造成干擾或錯誤 containment，所以會更保守。
• 有些環境希望把 LLM token 與 analyst 時間用在最值得看的少數事件上。

所以這篇的「policy-guided」不是裝飾語，而是它的核心。作者透過不同 reward modes 去塑造 DRL agent 的行為，等於是在說：我們不是只想做一個會抓異常的模型，而是想做一個能隨 SOC operational objective 調整風格的策略層。

這個思路比單純追求更高 F1 更接近現場，因為現場真正在乎的是：這個系統的誤報、漏報、調查成本、後續人力負擔，到底符不符合我的團隊偏好。

架構怎麼串？它其實是一條很典型、但被重新整理過的 SOC decision pipeline

整個 framework 大致可以拆成六步：

1. Data collection and SIEM indexing：先把多來源 logs 收進 Splunk。
2. Data cleaning and processing：去重、抽 features、整理成可後續訓練與判讀的格式。
3. Autoencoder anomaly detection：用 benign traffic 建 normal baseline，對每個 window 產生 anomaly score。
4. DRL containment policy：對時間窗做 contain / allow 決策。
5. Priority scoring：把 DRL decision 與 anomaly score 相乘，只把高優先級事件推給 LLM。
6. LLM multi-agent triage + Splunk validation：做 contextual analysis、MITRE mapping、SPL 生成，再交給 analyst 驗證。

這裡我最欣賞的是它對「分工」這件事有明確意識。作者甚至刻意避免 feature leakage：anomaly score 不直接餵進 DRL state，避免策略模型其實只是在抄另一個模型的答案。

換句話說：

• Autoencoder 做的是連續型異常評分
• DRL 做的是策略決策
• LLM 做的是語義化、脈絡化、對 analyst 可用的解釋與 investigation support

這種 functional separation 很值得注意，因為現在很多 agentic security 系統最大問題就是邊界太模糊：誰負責偵測、誰負責判斷、誰負責解釋、誰負責做最後 action 常常混成一團。這篇至少在設計上試圖把這件事講清楚。

LLM 在這裡不是單一角色，而是被拆成兩個 analyst persona

這篇論文另一個有趣的地方，是它沒有只說「用 ChatGPT 分析」，而是把 LLM triage module 拆成多代理人的 analyst 角色：

• Senior SOC Triage Analyst：判斷 flow 是 benign / suspicious / high risk，並生成 Splunk SPL。
• Threat Intelligence Analyst：做 MITRE ATT&CK mapping 與 remediation 建議。
• Orchestrator：把結果整理成人類可讀摘要。

這種 persona decomposition 雖然現在已經不是新鮮招式，但放在這篇裡其實有它的功能性：不是為了讓 multi-agent 聽起來很炫，而是為了把 analyst workflow 裡本來就不同的 cognitive tasks 分開。

因為現實中的 SOC triage，本來就包含至少三種不同工作：

• 先看這東西危不危險
• 再看它可能對應哪種技術/戰術
• 最後把這些資訊轉成團隊能行動的 investigation step

而這三件事，其實不太應該被當成一個單一步驟的 prompt 一次做完。論文在這裡的分拆，至少方向是對的。

最值得看的其實不是 LLM，而是 reward shaping：因為它直接決定了系統會變成什麼個性的 SOC 助手

論文設計了四種 reward modes（A 到 D），讓 DRL agent 學到不同風格的 containment policy。

• Mode A：偏 recall 導向，更怕漏報。
• Mode B：偏 false-positive reduction，更怕錯抓 benign traffic。
• Mode C：折衷型，試圖在 FP/FN 之間維持平衡。
• Mode D：在 reward 中加入 controlled randomness，提升對不確定流量分布的 robustness。

這個設計真正有價值的地方是，它把一個很多 security 團隊平常只能靠口頭討論的問題，變成可以被政策化、被訓練化、被比較的東西。也就是說：你不只是在選一個模型，而是在選一種 SOC operational temperament。

這很像在設定團隊的出手風格：

• 你要一個寧可多抓也不要漏掉的守門員？
• 還是你要一個不輕易升警、但一升就是高信心的 gatekeeper？

很多產品最後其實都會回到這個問題，只是沒有用這麼明確的實驗形式呈現出來。

實驗結果一：在 Boss of the SOC 資料上，Mode B 的整體偵測指標最好，但不代表它在 operational cost 上也最好

論文在公開的 Boss of the SOC 資料上做評估，使用約 12,000 筆清理後的流量資料。結果顯示，不同 reward mode 真的會學出不同性格的策略。

在這組資料上：

• Mode A 的 precision / recall / F1 大致都接近 0.85，屬於相對均衡但偏 recall 的配置。
• Mode B 拿到最高 recall 0.873 與最高 F1 0.861，是 paper 裡在這組資料上看起來最亮眼的模式。
• Mode C precision 還算高，但 recall 掉到 0.744，顯示策略更保守。
• Mode D 三項指標大致都在 0.82 左右，表現穩但不極端。

這裡最值得注意的是：最佳 F1 並不自動等於最佳 operational policy。

因為作者後面又做了 decision cost 與 regret analysis，結果反而顯示：

• Mode C 與 Mode D 的平均 decision cost 最低，約在 -0.79 左右。
• Mode D 的平均 regret 最低，約為 1.358。
• Mode B 雖然 F1 很好，但 regret 最高，顯示對 reward 設定更敏感，也可能在不同 fold 下較不穩。

這其實是一個很成熟的訊號：論文沒有只用 classification metrics 自我感覺良好，而是進一步問「這種策略在 SOC 成本語境裡到底划不划算」。

實驗結果二：在模擬資料上，Mode A 幾乎把 recall 拉滿，但也同時把 alert fatigue 問題拉了回來

作者也在自建的模擬資料上做測試，資料量約 300,000 筆。這組實驗更清楚展示 reward shaping 如何改變策略風格。

• Mode A：recall 幾乎到 0.998，但 precision 只有 0.636。意思很明白：抓得很兇，但噪音也大。
• Mode B：precision 高達 0.976，但 recall 掉到 0.495。也就是很保守，寧可少抓很多。
• Mode C：recall 同樣接近 0.998，precision 約 0.645，屬於高捕獲率但仍會帶進相當多 false positives 的配置。
• Mode D：precision / recall / F1 約為 0.926 / 0.696 / 0.795，相對均衡，也比較像可以討論上 production 的折衷設計。

如果把這些數字翻成 SOC 語言，其實很好懂：

• Mode A 是「先都抓起來再說」
• Mode B 是「除非非常有把握，否則不要吵我」
• Mode D 則比較像「我要一個穩定、不要太極端、能在流量條件變動下撐住的守門員」

這些差異不是學術細節而已，而是未來如果真要把這類系統放進 SOC pipeline，產品與安全團隊一定會吵到最後的核心問題。

這篇很務實的一點：它明確把「減少多少流量送進 LLM」當成正式成果，而不是附帶效果

很多論文會把「前面先過濾掉一些東西」寫成一個順手帶過的小設計，但這篇直接把它當成核心成績之一。

在模擬資料中，作者指出 DRL triage 可以把送進 LLM 的流量大約減少 63%–65%。而在不同 reward mode 下，這個 reduction 會伴隨不同 recall 後果：

• 有些模式減得多，但會漏更多
• 有些模式減得適中，但能保留較高 coverage

這件事的重要性其實不亞於 detection metrics，因為它直接關係到：

• LLM token cost
• triage latency
• analyst 真正要看的事件量
• 系統是否能在高吞吐量 SOC 場景裡活下來

如果今天一個 LLM triage system 很準，但前面沒有足夠節流能力，它最後很可能不是因為模型不行而失敗，而是因為部署成本太高、分析鏈太慢、或 analyst 根本消化不了。

所以這篇把 reduction ratio 正式拉進來，是對的。因為 production 問題本來就不只是「你會不會」，還包括「你能不能在合理資源下持續做」。

Splunk validation 是這篇真正踩在地上的地方

我認為這篇最不像 demo paper 的地方，是它沒有讓 LLM 的判斷停在文字層，而是要求最後要回到 Splunk 裡做驗證。

例如在 Boss of the SOC 資料上，論文展示某個高優先級 flow 被映射到 T1071 Application Layer Protocol，並被 triage 為疑似 command-and-control 通訊。接著分析師會用 LLM 生成的 SPL 查詢去拉出特定來源 IP 的行為，再在 Splunk 中觀察：

• 是否存在高頻 DNS communication
• 是否在單一 transaction window 中出現大量事件
• 是否呈現 burst-oriented beaconing 或 tunneling pattern

同樣地，在模擬資料中，經過 prioritized triage 之後，Splunk 驗證可以看到同一主機在短時間內對多個 destination ports 的反覆通訊，對應到 T1046 Network Service Scanning。

這裡的重點不是「LLM 幫你猜對了」，而是：LLM 的輸出被設計成 analyst 可以拿去驗證、拿去追、拿去做最後判斷的 investigation material。

這和很多只停在 summary generation 的系統不同。因為在高風險 security 場景裡，真正有價值的 LLM 輸出，不是看起來聰明，而是能不能把 analyst 帶回可驗證的證據層。

這篇論文也暴露了一個限制：它更像 framework paper，而不是已經證明 production-ready 的完整系統

當然，這篇不是沒有弱點。

第一，它雖然很強調 Splunk SOC 與 operational framing，但整體上還是偏 framework-driven paper。你可以看出它很努力補上 architecture、reward design、validation story，但距離真正 production study 還有幾步：

• 資料規模不算特別大，公開資料部分只用約 12,000 instances
• LLM triage 的穩定性、成本、誤報模式，還沒有像 production telemetry paper 那樣被非常細地拆開
• multi-agent prompt 與實際長期維運風險，還比較像概念驗證

第二，它的實驗雖然展示 reward shaping 的差異，但也反向告訴我們：沒有單一 reward mode 能同時把 detection、成本、alert fatigue、coverage 全部做到最好。

這不是缺點，而是現實。只是如果你要把這篇拿來當落地藍圖，就得知道：它真正給你的不是一把萬能鑰匙，而是一種比較成熟的系統設計方向。

怎麼看它在近期 CTI / SOC / Agentic AI 脈絡中的位置？

如果把近期幾條主線放在一起看，這篇的位置其實很漂亮。

• 像 CyberThreat-Eval、AthenaBench、SEvenLLM、CTIBench 這些工作，偏向回答「我們怎麼評估 LLM 在 CTI / security 上到底行不行」。
• 像 CORTEX、AIDR 這類工作，偏向回答「LLM / multi-agent 在 alert triage 與 analyst workflow 中怎麼協作」。
• 像 FALCON、Using LLMs to Automate Threat Intelligence Analysis Workflows in SOC，則偏向把 CTI 結果轉成可行動的規則或 investigation artifact。
• 而這篇 Policy-Guided Threat Hunting 則往前再推一步：把 policy learning、anomaly scoring、LLM contextual reasoning、Splunk validation 串成一個 threat hunting loop。

所以它的價值不在單一點爆發，而在於它很像一個「中層編排論文」：它不是最上游的 benchmark，也不是最下游的 rule generation，而是把偵測、策略、語義分析與 analyst validation 放在同一個 operational story 裡。

我的看法：這篇最值得學的，不是它用了 DRL 或 multi-agent，而是它對 LLM 的節制

老實說，現在只要看到 security + agentic + Splunk + MITRE 這種組合，很容易直覺先懷疑它是不是又一篇把所有 buzzword 疊上去的論文。但這篇讓我覺得還有點意思的原因，是它在最關鍵的地方反而相對保守：

• 沒有讓 LLM 決定全部
• 沒有讓 LLM 處理全部流量
• 沒有把 analyst 從回路裡拿掉
• 沒有把單一 detection metric 當成最後答案

它真正做的是承認：LLM 在 SOC 裡最強的地方，多半不是第一層大規模判斷，而是高價值事件的 contextualization、explanation、MITRE mapping、query suggestion 與 analyst decision support。

這種設計哲學，其實比任何單次漂亮 demo 都重要。因為 production 系統最後能不能活下來，常常不是看它在論文圖表上有沒有最炫，而是看它有沒有尊重現場的限制：成本、延遲、驗證、責任、噪音、工作負荷。

總結

Policy-Guided Threat Hunting 不是一篇只靠 LLM 炫技的論文，而是一篇試圖把 policy learning、anomaly assessment、LLM contextual analysis、Splunk-based analyst validation 串成同一條 threat hunting pipeline 的 framework paper。

它最值得注意的貢獻，我會整理成四點：

• 把 LLM 放在後段高價值 triage，而不是前段全量過濾。
• 用 reward shaping 把不同 SOC operational preference 轉成可學習的 policy。
• 把 traffic reduction、decision cost、regret 這些 production 更在乎的指標一起拉進來。
• 堅持最後仍要回到 Splunk 與 human analyst 做驗證，而不是把 LLM 輸出當終局。

如果你今天正在思考 SOC / SIEM / threat hunting 場景裡，LLM 應該放在什麼位置，我覺得這篇給了一個比「全自動 agent」更成熟的答案：讓策略層先幫你縮小戰場，再讓 LLM 去解釋那些真正值得人類花時間看的戰鬥。

這不只比較省，也比較像現實。