Collaborative Intelligence 論文閱讀分析：當 SOC 分析師真正開始用 LLM，最先被改變的往往不是決策，而是理解速度
論文基本資訊
- 論文標題：Collaborative Intelligence: Topic Modelling of Large Language Model use in Live Cybersecurity Operations
- 年份：2025
- 來源：arXiv:2508.18488
- 論文連結：https://arxiv.org/abs/2508.18488
- DOI：10.48550/arXiv.2508.18488
- 主題：SOC、Human-AI Collaboration、Topic Modelling、LLM、Security Operations、Workflow Design
如果前一篇 LLMs in the SOC 告訴我們「分析師真的開始在現場用 LLM 了」，那這篇 Collaborative Intelligence 更像是在追問下一個更細的問題：他們到底把 LLM 用在哪些具體微任務上？最常出現的互動模式是什麼？而這些使用痕跡，對未來 SOC 工具設計意味著什麼？
這篇論文的價值不在於再證明一次 LLM 很強，而在於它把視角放回真實使用現場。作者研究的不是 benchmark，也不是人造 task，而是 live cybersecurity operations 中分析師對 LLM 的實際使用資料，並透過 topic modelling 去看清楚：這些互動的主要主題到底長什麼樣。這件事很重要，因為很多 SOC copilot 的設計，仍然建立在想像中的 use case；而這篇做的，是把想像拉回紀錄。
這篇論文想回答什麼？
作者關心的問題很務實：當 SOC 團隊已經可以在安全邊界內使用 LLM 時，分析師自然會把它拿來做什麼？是請它幫忙判案、做威脅獵捕、寫報告，還是只是快速解釋一段指令？
換句話說，這篇論文要處理的核心問題不是模型能力上限，而是：
- 真實 SOC 人員最常把 LLM 用在哪類任務？
- 這些任務是高風險判斷，還是低摩擦的理解輔助？
- 如果把 analyst 與 LLM 的互動做主題建模，會浮現出哪些穩定模式？
- 這些模式能不能反過來指導下一代 SOC 工具設計？
這個切法很值得注意。因為很多 AI for SOC 的討論太容易直接跳去「讓 agent 幫你 triage、判定、回應」。但現實世界裡，工具能不能長出黏性，往往不是看它能不能接管整條流程，而是看它有沒有真的幫人省下每天都會遇到的那一小段認知成本。
研究方法：用 topic modelling 看懂現場互動
根據 arXiv 摘要，作者研究的是一組來自真實 Security Operations Centre 的 LLM 使用資料。分析師透過內部部署的 HTTP-based chat application 存取 GPT-4，資料涵蓋 10 個月 的 live security operations 使用紀錄。
方法上，作者做了兩組 topic modelling：
- BERTopic：使用既有成熟的 topic modelling 方法
- Novel topic modelling workflow：作者另外設計的新流程
這種雙軌做法有個好處：它不是只靠單一演算法硬切主題，而是試圖確認，無論用成熟方法還是新流程，最後浮現出來的高頻使用模式是否一致。若兩條路都指出類似結論，那研究結果就比較不像某個 clustering trick 的產物，而更像真實行為的穩定訊號。
核心發現：SOC 分析師最常拿 LLM 來看懂複雜字串，不是拿來替他下判決
這篇最值得記住的結果非常乾脆：不論是 BERTopic 還是作者的新方法，都顯示 SOC 分析師最主要的 LLM 使用情境，是幫助自己理解複雜文字字串。
而且這不是邊角用途，而是主流用途。論文指出，這一類使用的變體合計約占 40% 的 SOC LLM usage。
這代表什麼？代表分析師面對 LLM 時，最自然的需求並不是：
- 「幫我決定這是不是入侵」
- 「幫我直接做最終處置」
- 「幫我從頭到尾跑完 investigation」
而比較像是：
- 這段 command / script / log string 到底在做什麼？
- 這串參數或 artifact 有什麼值得注意？
- 這段技術描述可不可以更快幫我翻成人能用的語言？
- 這些文字背後實際的操作意圖是什麼？
如果把它講白一點，這篇論文的訊息是：在真實 SOC 裡，LLM 最先穩定落地的角色，不是代替 analyst 決策，而是幫 analyst 更快看懂那些又長、又怪、又容易拖慢節奏的技術文字。
為什麼這個發現很重要？
很多人談 AI 進 SOC，直覺會先想到 alert triage automation、incident classification、甚至 autonomous response。但這篇論文反而提醒我們，真正黏得住工作流的第一波價值，可能沒那麼戲劇化。
在 SOC 現場，分析師每天都有大量時間花在：
- 看懂 shell command、PowerShell、Python snippet、regex
- 把可疑行為描述整理成人能讀的說法
- 解釋某個 artifact 或 log 片段代表什麼
- 在高壓節奏下快速補足上下文
這些工作不一定是 headline task，卻很常是 investigation 裡最消耗注意力的 friction point。從這個角度看，LLM 真正先切入 SOC 的位置，比較像 cognitive compression layer：它幫你把複雜文字壓縮成比較容易判讀的形式，讓人能更快回到真正重要的調查與決策。
這篇論文其實在替 SOC copilot 設計劃出方向
作者在摘要裡點得很明白：如果我們已經知道高頻 use case 長什麼樣，下一步就不該再做一個泛用聊天視窗，然後期待分析師自己想像怎麼用；而是應該把工具設計成能貼著這些高頻任務長出來。
論文舉的一個很具體的例子，就是在 SOC 環境內做出 right-click context menu，直接對 command line 片段呼叫 LLM 分析能力。這個例子之所以有意思，是因為它反映出作者的產品觀很成熟：
- 不是把 analyst 拉去另一個 chat world
- 不是要求 analyst 重新學一套 AI workflow
- 而是把 LLM 放進既有操作流程的最近位置
這其實正是很多企業工具最後能不能被持續使用的分水嶺。SOC 分析師不是沒能力跟 AI 聊，而是沒有餘裕每次都切 context、整理 prompt、重講一次背景。真正有用的協作式 AI，不只是回答得好，而是出現在正確的位置、正確的時機、正確的粒度。
和前一波 agentic security 論文相比，這篇更像是在談 adoption reality
最近一大串 agentic security 論文，無論是 runtime boundary、delegation chain、tool supply chain、multi-agent trust propagation，焦點大多在「當 agent 能做更多事時，風險怎麼變大」。這篇則把鏡頭轉回比較少人耐心看的另一面：人在現場到底願不願意用、最先會用在哪裡、什麼能力真正被當成工作的一部分。
這讓它和那些更偏 offensive benchmark、formal security model、guardrail evaluation 的 paper 形成一個很好的互補。因為如果不知道 analyst 真正高頻採用的是哪類 interaction，我們做出再多華麗 agent，也可能只是漂亮 demo，而不是能留在桌面上的工具。
我怎麼看這篇論文？
我覺得這篇論文真正有價值的地方，在於它把「協作」這個詞從抽象口號拉回可觀察行為。很多人說 human-AI collaboration，但實際上常常只是在講「人加上一個很強的模型」。這篇不是。它試圖從真實紀錄裡分辨：這個 collaboration 到底是在什麼工作片段上發生的。
而作者得到的答案相當一致：分析師最先需要的不是 AI 幫他做主，而是 AI 幫他更快把複雜技術語言翻譯成可操作理解。
這個結論很樸素，但也因此很可信。因為真正的安全營運，很少是每小時都在做 grand strategic reasoning；更多時候，是在一堆 command、artifact、log、case note、query、rule 與解釋之間高速切換。誰能先把這層 friction 降下來，誰就比較有機會先被 analyst 接納。
這篇研究的限制
當然，從摘要能看到的範圍來說，這篇也有幾個需要保留的地方：
- 資料來自特定 SOC 場域：不同組織的工作流、工具鏈與資料政策不同，使用模式未必完全一致。
- 重點在 usage pattern，不是直接量 outcome：它告訴我們人怎麼用，但沒有直接回答這些用法能否穩定提升 triage 速度、偵錯品質或 investigation 成效。
- topic modelling 本質上仍是後設歸納：即使有兩種方法交叉驗證，最終仍是在為使用行為做聚類與命名，而不是逐筆精細地驗證每個 task 的實際價值。
不過這不太影響它的實用性。因為這篇的最大貢獻，本來就不是要當 performance benchmark，而是幫我們看清 adoption pattern。
對實務者的啟示
如果你在做 SOC 平台、AI assistant、MDR 內部工具，這篇論文至少給了幾個很實際的提醒：
- 先做 command / string / artifact understanding，再談 autonomous analyst：高頻 use case 往往藏在理解與解釋層。
- 把 LLM 做成 workflow-native capability，而不是外掛聊天室：context menu、inline analysis、artifact-aware assistant 會比單純 chat 視窗更貼地。
- 優先支援 micro-interaction：真正被反覆使用的，常常是幾秒內能補完上下文的小功能。
- 不要過度預設 analyst 想把決策權交出去：人多半先想要理解加速，而不是直接把 verdict outsource 給模型。
總結
Collaborative Intelligence: Topic Modelling of Large Language Model use in Live Cybersecurity Operations 這篇論文最重要的地方，不是又替 LLM 找到一個新能力，而是幫我們更精準地描述：在真實 SOC 裡，人是怎麼把 LLM 納入工作流的。
它給出的答案其實很值得記住：
- LLM 在 SOC 的高頻價值，首先落在複雜文字與技術字串的理解
- 這類用途約占整體使用量的四成
- 這代表最自然的落地點不是全面接管，而是低摩擦、貼流程、補理解
- 真正該做的，不是再造一個更花俏的 chatbot，而是把這種理解能力嵌進分析師本來就在用的操作界面裡
如果說近年的資安 AI 論文常在追問「agent 能不能做更多」，那這篇更像是在提醒我們另一件同樣重要的事：真正能留下來的工具，往往不是最會炫技的那個，而是最懂現場摩擦點在哪裡的那個。
免責聲明
本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。