基於推理模型+RAG+Agent，作業幫內部安全體系建設實踐

文/作業幫基礎架構團隊（呂亞霖、尚義龍）

背景

在網際網路智慧化與 AI 大模型技術的雙重驅動下，資訊安全領域正遭遇史無前例的複雜挑戰。

從外部環境來看，AI 大模型的應用降低了攻擊門檻。外部攻擊者利用 AI 工具生成自動化攻擊指令碼、繞過傳統檢測規則，進行網路資產測繪和漏洞挖掘，攻擊效率呈指數級增長，同時，攻擊者逐漸呈現出組織化、產業化的趨勢，他們之間分工明確，這無疑加劇了企業遭受針對性網路攻擊及資料洩露風險。進而使得攻擊者的活躍度與攻擊強度逐年攀。以作業幫為例，我們每日攔截的惡意掃描和滲透嘗試，從 23 年 10 萬次攀升到現在幾十萬次。

在企業內部，多元化的業務場景（如網際網路場景、智慧硬體場景、AIGC 場景等）、數萬員工的規模化團隊、全國十幾個工區以及各類 IoT 智慧裝置的接入網路，進一步加大了構建縱深安全防禦體系的難度。

因此在企業內網，我們構建了"網路邊界 – 傳輸鏈路 – 終端裝置"三層防禦體系：

網路層：辦公網實施網路域控隔離、雙因素實名認證准入，在辦公網到生產網的唯一通路上建設內網零信任閘道器，所有訪問內部系統的流量必須經過該閘道器。其功能包括身份鑑權、匹配動態許可權策略、員工辦公審計等。
傳輸層：透過部署威脅檢測和分析系統，將交換機、閘道器、邊界裝置等流量同步到流量探針，深度分析進出網路流量，重點監控木馬、遠控、代理工具等威脅，並利用檔案沙箱對檔案進行隔離檢測，確保安全後放行。
終端層：全覆蓋部署智慧 EDR 系統，防範惡意軟體入侵，保障終端裝置穩定執行。透過 IT 裝置預裝、強裝及網路發現檢測，確保終端安全軟體覆蓋率達到 95% 以上。

面臨的深度運營挑戰

但是現在這套防禦體系在運營能力上達成 SOMM 裡最高階（LEVEL 4 韌性級：高階自動化響應流程，自動化威脅鑑定、調查以及響應流程，完全自主自動化從鑑定到緩解），面臨三重困境：

安全運營能力成熟度模型（Security Operations Maturity Model，簡稱 SOMM）是一個用於評估和改進安全運營有效性的模型。SOMM 模型分為五個級別，從 LEVEL 0 到 LEVEL 4，從無安全運營能力到完全自動化的高階響應流程。

告警過載：內部防毒和威脅監測系統日均 15,000 條安全告警中有效訊號不足 15%，4 萬員工產生的日均 6000 多條行為預警中的有效訊號不足 3%，還有其他 10 條子系統，產生的眾多告警。安全專家深陷告警噪音的"海洋”。
響應遲滯：在內部流量威脅檢測中，高危告警平均處置週期長達 2 小時，給予攻擊者充足的時間視窗。在安全審計場景裡，平均處置週期超過 10 小時。
知識斷層：90% 的威脅研判依賴安全專家經驗，新人員工誤判率高。

反應到具體問題層面：

2.1 告警噪音吞噬運營效能

安全運營中心（SOC）每日需處理來自個 12 個子系統的告警，核心資料表現為：

噪音佔比過高：95% 以上告警屬於可忽略噪聲，真正需要處置的有效告警僅佔 5%。
告警處置效率：人工處置速度約 20 條 / 人 / 小時，與告警產生速度形成 20 倍差距。
研判盲區：1.5 萬條 / 日的低危告警長期未被覆蓋，事後追溯發現 0.12% 的真實安全事件潛伏其中。
決策失誤成本：運營人員能力參差不齊，告警響應準確率不足 89%，錯誤處置導致二次事件。

2.2 知識沉澱與複用困局

針對新型威脅的響應存在"三難"問題：

知識碎片化：典型攻擊場景和內部審計場景的處置經驗分散在多套知識庫和多個專家邏輯裡。
推理邏輯黑盒：大部分判斷標準無法形成可沉澱的規則特徵。以典型審計場景裡「員工獲取敏感資訊」告警為例：需區分獲取數量、所屬部門、具體場景、是否報備、是否使用非法工具獲取，是否誤識別敏感資訊，同時敏感資訊規則也需要不斷最佳化迭代。
響應速度滯後：從發現新型威脅到建立防護規則平均需要 6 小時以上。
這種"人工專家 + 規則 + 系統處置 "的傳統模式，既無法應對告警量級增長，也難以保證威脅發現的準確率與時效性。

解決方案：基於大模型 +

RAG + AI agent 的智慧決策

我們開始從 24 年初摸索 AI 賦能提效，在使用過中發現，單純的使用或者早期通用大模型存在的三個問題：

確定性缺失：存在非事實性回應與隨機輸出現象，同等輸入條件下的細微變化的多次請求結果偏差度超過 30%。以「報警處置推導」任務為例，格式指令"第一行輸出結果並放入 []"與"第一行輸出結果"的細微差異可導致結果置信度波動達 50%。
推理能力差：在複雜安全運營場景中尤為明顯，主要表現為在多步推導情況下，上下文關聯邏輯斷層，無法有效關聯報警上下文中的關鍵要素（如流量方向、資產歸屬、使用者行為模式），導致決策鏈斷裂，甚至不參考關聯向量資料庫檢索之前處置結果。
特定知識匱乏：通用大模型缺少與企業業務相關的資料以及歷史處置方案。在企業實際場景中，僅依賴通用安全知識往往不夠準確。例如，在內部流量威脅檢查報警出現弱密碼，實際上是員工在使用外部系統時設定了弱密碼，通用大模型可能會建議其更改為強密碼，但在企業場景下，考慮到外部系統並非企業資產，該報警應被忽略，這就凸顯了通用大模型在特定業務場景下的知識匱乏問題。

隨著以 deepseek 為代表的長推理模型誕生，推理能力增強，我們構建了推理模型 × 檢索增強生成（RAG） × AI 自主智慧體（Agent）安全大腦，來達成深度安全運營的需求。

3.1. 整體架構

3.2 即時報警處置

步驟一：原始報警資料標準化

對原始報警資料進行標準化處理，僅保留告警事件的核心欄位，為後續分析奠定基礎。

基礎資訊：精準記錄時間、報警 ID，明確標註受害 IP 與攻擊 IP，以便快速定位事件發生時刻及涉及主體。
威脅特徵：詳細登記威脅型別、名稱，全面描述漏洞，為識別威脅性質與潛在影響提供關鍵依據。
網路痕跡：完整儲存請求頭 / 體、響應頭 / 體，這些資訊有助於還原網路通訊過程，發現異常請求與響應模式。
地理位置：精準定位攻擊方與受害方的地理位置，結合地域特徵，輔助判斷攻擊來源與目的。

步驟二：完善補充關鍵資訊

呼叫情報 agent，深度挖掘並補充關鍵資料，提升告警資訊的完整性和可用性

區分內外網：準確區分告警是源於內部員工誤操作還是外部攻擊，這是確定事件性質與後續處置策略的首要環節。
定位責任方：明確發起 IP 和受害 IP 所屬的部門、員工，或是具體伺服器及相關資訊，便於落實責任與精準處置。
識別關鍵裝置：判斷涉及裝置是印表機、核心伺服器還是 PC 電腦等，不同裝置的安全優先順序與處理方式截然不同。
評估威脅：核查外部攻擊 IP 或域名是否存在於黑名單庫，檢驗網路包是否有 APT（高階持續性威脅）標識，從而精準評估威脅等級。

步驟三：向量化（embedding）

採用 BGE-M3 模型進行向量化：

精準捕捉語義：能夠精準捕捉文字語義，有效提高向量檢索的準確性，確保告警資訊的核心要點被充分提取。
強大泛化能力：在大規模中文資料上充分訓練，具備出色的泛化能力，可適應多樣化的告警場景與文字特徵。
效率效果平衡：生成的向量維度適中，在保證計算效率的同時，最大程度保留語義表達能力，避免因向量維度過高或過低導致的資訊丟失或計算資源浪費。

步驟四：召回

從向量資料庫檢索時，若僅依賴語義，在資料量龐大時，容易出現召回不全的情況，尤其在長尾或特定領域查詢場景下，關鍵資訊可能被遺漏。為應對這一挑戰，我們採用多路召回策略，在向量查詢的基礎上，增加基於關鍵詞檢索方法，雙管齊下，有效彌補向量查詢的缺陷，確保最相關資料被精準召回，為後續分析提供全面的資料支撐。

步驟五：大模型處置

召回階段獲取的相關資料作為參考內容，將與本次告警資訊整合，作為大模型推理歸類的關鍵參考。

為提升推理準確性，我們採用了一種最小指令的方式，即儘可能減少指令性描述，讓大模型更依賴參考內容，而非自身的預訓練知識。內部測試表明，當指令與參考內容並重時，大模型易基於自身知識主觀判斷，忽視或誤解參考內容，引發錯誤判斷。透過這一最佳化策略，有效減少模型幻覺問題，使大模型更聚焦於檢索到的高質量資料，告警分類的準確性和可解釋性得以顯著提升。

比如弱密碼這個告警，可能存在很多情況：

目標系統是作業幫系統：需要處理；
目標系統是外部但資產不屬於作業幫：無需關注；
目標系統是內部印表機之類的 IT 服務：無需關注關注；
目標系統是非 IT 類的服務；需要關注

…

如果是存在諸如“如果受害 IP 是公網，除了 XX1、XX2 的外網 IP 均可忽略”，指令與參考內容資訊將產生交叉，使大模型難以準確理解並判斷告警型別。採用最小指令策略，即只傳遞必要的資訊和參考資料，讓模型基於最新的、具體的案例進行推理，從而提高分類效果。

步驟六：多個推理模型交叉驗證

我們以多個通用大模型為基座，構建穩健的驗證體系。

當各基座模型判斷結果一致時，直接採納該結果；

當各基座模型判斷結果出現分歧，我們巧妙利用大模型進行交叉驗證。

例如，QWEN 大模型初步給出處置結果為工單，隨後向其展示 Deepseek 的推理過程，詢問其對推理合理性的看法，要求指出不合理之處及理由。透過這種方式，讓大模型自行檢驗推理鏈路，挖掘可能的矛盾點或錯誤邏輯。若經交叉驗證仍無法達成共識，系統將輸出「不確定」狀態，交由人工處理。

步驟七：呼叫處置 agent 自動化執行

在最終確定處置結果後，我們呼叫 Agent 自動化執行相應操作，以提升響應效率並減少人工干預

下發防毒措施：聯動防毒終端，針對需要防毒的使用者，下發防毒任務；
發起工單：對於需進一步處理的情況，Agent 能自動建立並提交工單，確保問題被持續跟進，直至徹底解決。
誤報加白：一旦判定為誤報，Agent 立即將相關項加入白名單，避免後續誤檢干擾正常業務流程。
高危應急：面對高危威脅，Agent 迅速將其新增至網路黑名單，堅決阻斷惡意行為，全方位加強防護。

步驟八：反饋最佳化向量資料庫

需要人工處理的案例，往往是未曾遇到的特殊情況，極具學習價值。

安全運營人員完成判斷後，系統自動接收處理完成通知，隨即啟動向量資料庫的最佳化更新。

相似度檢索：收到反饋後，系統先在向量資料庫中檢索是否已有相似度大於 95% 的案例。
判定是否入庫：

若向量資料庫中不存在高相似度案例，則將新案例入庫，擴充資料庫知識儲備；
若向量資料庫中存在，暫不入庫，而是通知開發人員，深入分析為何相似告警仍未被正確識別，針對性最佳化召回策略或規則邏輯，讓系統在下次遇到類似情況時表現更出色。

3.3 知識庫構建

主要說步驟一和步驟四，其餘步驟在即時告警流程中已經做過介紹。

步驟一：資料打標

在明確報警分類標準後，我們對歷史報警資料進行全面整理和人工標註。藉助統一的標註平臺，我們將各類報警按照預設標準歸類，同時對非常見案例進行重點稽核，保障準確性。

這一過程至關重要不僅提升資料質量，也為後續向量化、檢索最佳化奠定基礎。

步驟二：分塊

我們採用語義分段 + 滑動視窗的方式進行分塊保證語義的完整性和避免上下文之間的割裂。

以一個簡化版的告警為例：

該事件涉及一起 SQL 注入攻擊，攻擊者試圖透過資料庫伺服器執行任意查詢來獲取敏感資訊或操作資料庫。攻擊者來自 IP 地址 10.106.32.49，目標主機為 10.106.24.3:9000。根據事件的嚴重程度、影響範圍、響應速度和完全遏制事件所需的時間等因素，風險等級評定為 4 級，風險評級為中危。為了防止此類攻擊，建議對使用者輸入資料進行嚴格過濾，部署 Web 應用防火牆，並對資料庫操作進行監控。處置結論是生成一個工單，以便進一步跟蹤和處理該事件。

第一步語義分段：