Beyond RAG for CTI 論文閱讀分析：真正卡住情資問答的，往往不是找不到文件，而是關係推理、拒答能力與 runtime 穩定性根本沒被一起設計

論文基本資訊

• 論文標題：Beyond RAG for Cyber Threat Intelligence: A Systematic Evaluation of Graph-Based and Agentic Retrieval
• 作者：Dženan Hamzić、Florian Skopik、Max Landauer、Markus Wurzenberger、Andreas Rauber
• 年份：2026
• 來源：arXiv:2604.11419
• 論文連結：https://arxiv.org/abs/2604.11419
• DOI：10.48550/arXiv.2604.11419
• 主題：CTI、GraphRAG、Knowledge Graph、Agentic Retrieval、Multi-hop QA、Hybrid RAG、LLM Evaluation

如果最近幾篇 sectools.tw 的 CTI / AI 論文一路在談 RAG、知識圖譜、情資抽取、agentic workflow，那這篇 Beyond RAG for Cyber Threat Intelligence 很值得補上，因為它不再只是說「Knowledge Graph 很有用」或「Agentic RAG 比較聰明」，而是直接把幾條現在最常見的 CTI 問答架構放到同一個場上比較：一般向量 RAG、Graph-only RAG、會自我修 query 的 Agentic GraphRAG，以及 graph + text 雙路並行的 HybridRAG，到底誰在什麼題型上真的比較可靠？

這篇最有價值的地方，不是它又發明了一個新名詞，而是它終於把很多人嘴上常講、但很少被系統性驗證的事拆開來看：CTI 問答不是單純的文件檢索問題，因為真正重要的答案常常散落在多篇 threat report、跨好幾個 entity 關係、還夾著時間與因果脈絡；但把它全部結構化成 graph 之後，也不會自動變成萬靈丹，因為 graph pipeline 自己會長出另一批故障模式。

這篇論文想解決什麼？

作者抓得很準：CTI 分析師在做問答時，常問的不是「這篇文件哪一段提到某個字」，而是這種比較像 analyst workflow 的問題：

• 某個 threat actor 跟哪些 malware、infrastructure、vulnerability 有關？
• 一組 campaign 的攻擊鏈、目標產業與 TTP 之間有什麼關聯？
• 不同報告分散提到的實體，能不能被串成同一條有意義的 intelligence path？
• 如果資料裡根本沒有答案，系統能不能老實說不知道？

傳統 vector RAG 的弱點就在這裡：它擅長找相似文字片段，但不一定擅長把分散在不同文件、不同段落、不同實體之間的關係鏈拼起來。 對 CTI 這種 heavily relational 的領域來說，光靠 top-k chunk similarity，常常會漏掉真正需要的關聯證據。

所以這篇要回答的核心問題很清楚：

當 CTI 問答開始需要 multi-hop relation reasoning、結構化約束與可靠拒答時，GraphRAG、Agentic GraphRAG、HybridRAG 相較於普通 RAG，到底改善了什麼？又引入了哪些新的 operational 風險？

作者比較了四種架構

這篇 paper 最好記的部分，就是它把四條 retrieval 路線講得很清楚：

1. RAG：標準語意檢索，從 chunked text 裡做向量搜尋，再把片段丟給 LLM 回答。
2. GRAG：把 CTI text 轉成知識圖譜，問題先翻成 Cypher 查詢，直接走 graph retrieval。
3. AGRAG：在 GRAG 上再加 critique-and-repair loop，讓系統在 graph query 失敗時自我修正。
4. HRAG：同時結合 graph query 與 text retrieval，把結構化與非結構化證據一起餵回去。

這個比較設計很重要，因為它不是在比「有沒有 graph」，而是在比四種不同的取捨：

• 只靠語意相似度
• 只靠顯式關係結構
• 在結構檢索上加 agentic 修補
• 讓 graph 與 text 互相補洞

換句話說，這篇真正要驗的是：CTI assistant 往 graph 化、agent 化之後，可靠性到底是變高，還是只是把 failure mode 從「檢索不到」換成「query 產錯、查空、還很有自信」？

方法設計其實很紮實：不是亂問，而是先把評測地板鋪好

很多 RAG paper 的問題，是 benchmark 不夠乾淨，最後很難知道分數差異到底來自 retrieval 架構，還是資料本身、prompt、題型設計或模型亂數。這篇比較不一樣，它花了不少力氣在 evaluation control 上。

作者做法大致如下：

• 從 CTINexus dataset 隨機抽 CTI 報告
• 把非結構化 threat report 轉成 Neo4j property graph
• 由 graph 中的 Cypher 查詢反推出可驗證的 QA pairs
• 讓四種 retrieval 架構都基於相同 knowledge base 與相同題目作答
• 用自動評估 + LLM-as-a-Judge 一起看答案品質與失敗模式

這裡有個很值得記住的設計：問題是從可執行的 Cypher query 反推生成的。 這代表作者盡量確保「正確答案真的存在於共同知識底座裡」，避免一些問答根本不在資料裡、卻硬要系統回答的混亂情況。對比較 retrieval 架構來說，這很關鍵。

資料集怎麼做？

論文總共評估了 3,300 組 CTI question-answer pairs，而且不是單一題型，而是分成五類：

• simple：直接事實查找
• single-hop：一跳關係問題
• multi-hop：需要跨多個 entity / relation 串證據
• guided analyst-style questions：更像分析師真的會問的綜合型問題
• unanswerable：資料不足時應該拒答的問題

我很喜歡它把 unanswerable 單獨拉出來。因為在 CTI 場景裡，不會拒答的系統，往往比偶爾答錯的系統更危險。 如果 assistant 面對不存在於報告中的 actor 關係、錯誤 campaign linkage、或根本沒被資料支持的推論時，還是硬補一個看起來很順的答案，那就不是單純 QA 小失誤，而是會直接污染 analyst situational awareness。

這篇最重要的主張：Graph grounding 確實有用，但不是全面碾壓

論文結果很值得細看，因為它不是「GraphRAG 全面勝利」那種簡單故事。

作者的核心發現可以濃縮成四句：

• Graph grounding 對結構化 factual query 確實明顯有幫助。
• Hybrid graph-text retrieval 在multi-hop 問題上最亮眼。
• Graph-only pipeline 會引入新的 failure mode，特別是 query generation 與空結果處理。
• Agentic query repair 與 hybrid redundancy 讓整體表現比 naïve graph-only 更穩。

其中最值得記的 headline 是：HybridRAG 在 multi-hop 題型上的答案品質，相較 vector RAG 最高可提升 35%。這個結果其實很有 CTI 味道，因為 CTI 問答最麻煩的地方，本來就不是單點事實，而是跨實體、跨文件、跨報告的關係鏈。

也就是說，當問題真的需要把「threat actor → malware → exploited vulnerability → target sector」這類路徑串起來時，光靠相似片段檢索常常不夠；而 graph 結構能把這種顯式關係拉出來，再讓 text 補語義細節，效果就會比單一路線更穩。

但 graph-only 為什麼不夠？

這是我覺得這篇最成熟的地方：它沒有把 graph 神化。

作者明講，純 graph retrieval 會長出幾個很現實的問題：

• text-to-Cypher translation error：問題翻錯 query，後面整條都歪掉
• schema mismatch：模型用到 graph 裡其實沒有的 label / relation / property
• empty-result query：查不到結果時系統不一定會安全收手
• overconfident answering on incomplete evidence：資料不全卻回答得很篤定
• latency instability：反覆修 query 會讓回應時間抖得很兇

這些都不是 UX 小瑕疵，而是安全相關的 operational failure mode。因為 CTI assistant 不是做聊天，它是在支撐防禦判斷。若系統查不到證據時不肯停、schema 對不上時還硬湊、或在時間敏感場景下 latency 突然暴衝，對 analyst 來說都會變成真風險。

Agentic retrieval 在這裡的角色，不是變聰明，而是補救脆弱性

AGRAG 很有意思的地方在於，它不是拿 agent 當 marketing 詞，而是很務實地用來修 graph pipeline 的弱點。作者讓系統在 graph query 失敗時走 critique-and-repair loop，嘗試修正 Cypher，再重新查詢。

這種 agentic 設計的真正價值，不是「多想一步」，而是：

• 降低一次 text-to-query 失敗就全盤歸零的 brittle behavior
• 把 graph retrieval 從 one-shot fragile pipeline，往可恢復流程推進
• 在結構檢索出錯時，給系統一個自我修補機會

但作者也很誠實：repair loop 雖然能救正確率，卻也會帶來 latency 與 runtime variance。 換句話說，agentic retrieval 不是白送的增益，它比較像是在 correctness 與 runtime predictability 之間重新做工程取捨。

HybridRAG 為什麼最後最平衡？

從結果來看，作者最看好的不是 graph-only，也不是純 agentic graph，而是 HybridRAG。原因其實很好理解：

• graph retrieval 提供顯式關係路徑與結構約束
• text retrieval 補足 graph 沒抽完整的語義細節
• 雙路 evidence 互相兜底，降低單一路線失誤的破壞力

對 CTI 來說，這種設計很合理。因為現實中的 threat report 本來就不會被完美抽成 graph；同時，單靠文字檢索又很難穩定支撐跨實體推理。graph 給骨架，text 補血肉，才比較像 analyst 真正需要的 intelligence substrate。

這篇論文對 CTI 實務者的啟示

我覺得這篇對實務最重要的提醒有五個：

1. 不要把 CTI QA 當一般文件問答：它本質上就是關係推理與證據鏈管理問題。
2. GraphRAG 不是自動更安全：它會降低某些 hallucination，但也會新增 query / schema / latency 失敗模式。
3. 拒答能力要被當成一級指標：在 CTI 場景裡，unsafe abstention 失敗非常傷。
4. Agentic retrieval 的意義在恢復力，不只是能力：它更像 runtime repair layer，而不只是更 fancy 的 reasoning。
5. Hybrid 架構更接近 production reality：因為真實 CTI 知識永遠同時活在結構化與非結構化世界裡。

這也讓我想到，很多團隊現在在做 CTI assistant 時，會很快跳去問「我們要不要上 GraphRAG？」但這篇真正提示的是另一件事：你該先問的是，你最怕的是哪種錯。

• 怕漏掉 multi-hop 關係？graph 很重要。
• 怕 query brittle、schema 容易漂？agentic repair 要補上。
• 怕資料抽不全、又怕回答空洞？hybrid 比較現實。
• 怕 system 明明不知道還亂講？就得把 abstention 當核心治理目標。

限制也很明顯

當然，這篇不是沒有保留。

• 它的 graph 是從 CTI text 自動抽出來的，所以結果仍受上游 extraction quality 影響。
• 雖然題型設計很完整，但仍屬 controlled evaluation，不是直接在真實 SOC / CTI desk 長期部署。
• guided analyst-style 問題比純 schema-derived QA 更接近現實，但離真正 analyst 任務還是有距離。
• 它已經談到 poisoning 與 graph robustness 文獻，但這篇自己主要仍在評估 retrieval / runtime，而不是完整 adversarial defense。

不過這些限制並不削弱它的價值，反而讓它更像一篇把 CTI GraphRAG 設計空間整理清楚的地圖 paper：告訴你不同架構各自救了什麼，又會在哪裡摔倒。

重點整理

• 這篇論文系統性比較 RAG、GRAG、AGRAG、HRAG 四種 CTI 問答架構。
• 評估基於 3,300 組 CTI QA pairs，涵蓋 simple、single-hop、multi-hop、guided、unanswerable 五類題型。
• Graph grounding 對結構化事實查找有明顯幫助。
• HybridRAG 在 multi-hop 題型上相較 vector RAG 最高可提升 35% 的答案品質。
• 純 graph pipeline 會引入text-to-Cypher 錯誤、schema mismatch、空結果高自信回答、延遲不穩等新風險。
• Agentic query repair 可以提高 graph retrieval 的恢復力，但會增加 runtime 成本與 latency variance。
• 對 CTI assistant 而言，拒答能力與 runtime 穩定性不該被當成附屬指標，而是核心安全屬性。

Takeaway

Beyond RAG for CTI 真正提醒我們的，不是「GraphRAG 比 RAG 高級」，而是：在 CTI 這種 heavily relational 的場景裡，檢索架構的核心問題從來不只是找不找得到文件，而是能不能把關係鏈接對、在缺證據時肯停、以及在 runtime 出錯時不把 analyst 一起帶偏。

如果要為 sectools.tw 的讀者再翻成更直白的一句話，那就是：未來好用的 CTI assistant，大概不會是單一路線的純向量 RAG，也不會是迷信 graph 的單線神話，而更可能是有 graph grounding、有 text fallback、有 agentic repair、也有明確 abstention policy 的混合式 intelligence system。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。