百度作為一家業務複雜的大型網際網路企業，同時又是關鍵基礎設施，隨著網路安全威脅的日益加劇，傳統的安全運營手段在效率和效果上都面臨巨大挑戰。在 InfoQ 舉辦的 QCon 全球軟體開發大會上百度傑出架構師，安全技術委員會主席包沉浮為我們帶來了精彩專題演講“百度基於大模型安全運營的質效提升實踐”，分享將介紹百度如何基於大模型構建深度安全推理智慧體框架，實現運營效率和效果的雙重提升，並展示包括告警自動研判和漏洞事件分析在內的實踐經驗，希望能給聽眾帶來一些大模型安全領域應用最佳實踐的啟示。

在即將於 4 月 10 日召開的 QCon 全球軟體開發大會（北京站），包沉浮老師作為會議出品人，策劃了「大模型安全」專題，涵蓋大模型安全的技術趨勢和前沿挑戰，多模態 AIGC、智慧體、具身智慧等新興技術應用的安全風險與應對以及在企業中的應用和實踐。專題詳情：https://qcon.infoq.cn/2025/beijing/track/1770

大模型的重要性不言而喻，它正在加速整個社會的數字化、智慧化轉型。然而，大模型也帶來了更為嚴峻的安全挑戰。一方面，大模型的規模引發了新的安全風險。其算力、資料量和演算法規模的持續增長，使得系統的複雜度和應用場景的豐富度不斷提升，從而增加了安全風險的複雜性。傳統的安全風險在不斷增加，同時大模型還引入了許多新興的安全風險。另一方面，大模型技術可能被用於網路攻擊。例如，大模型可用於生成惡意程式碼和自動化攻擊，利用其生成的內容進行深度偽造以實施社會工程學攻擊，甚至可以繞過傳統的安全防護和檢測機制。這些都構成了新的挑戰。

大模型也為網路安全領域帶來了新的機遇。自去年起，全球網路安全廠商紛紛推出基於大模型的安全產品，如微軟的 Security Copilot。國內的深信服、奇安信、360 等大廠也推出了自己的基於大模型的安全產品。大模型在安全領域的應用場景豐富多樣，包括安全運營、資料安全、郵件安全、自動化滲透測試等。

安全工作主要分為三類：安全研發、攻防對抗和安全運營。安全研發涉及開發安全系統軟體，如防火牆、防毒軟體等；安全運營則是透過流程機制，利用軟體和系統持續監控、檢測、預防和響應網路攻擊與威脅，確保組織的系統、資料和網路安全。由於安全運營高度依賴人力，因此大模型在這一領域的應用備受關注。大模型在安全運營中的潛在應用主要包括告警研判、事件響應與止損、安全事件分析與溯源、受影響資產修復與加固，以及事件報告生成等。

以百度為例，核心安全運營環節是告警研判。百度是一家擁有 20 多年曆史的網際網路公司，擁有大量網路資產，包括超過 60 萬臺主機、超過 1,000 萬容器以及超過 10 萬臺辦公裝置。多年來，百度建立了一套多級縱深威脅感知和防禦對抗體系，從網路邊界到主機系統、容器環境和應用程序服務，都部署了大量自主研發的安全系統和軟體。這些系統會產生大量告警，來源包括辦公網中的 EDR 終端檢測響應裝置、郵件安全檢測、防毒檢測，以及 IDC 環境中的 HIDS（主機入侵檢測系統）和應用層防護等。百度積累了超過 1,000 條告警規則，每天產生超過 10 萬個新增告警。然而，其中大部分告警是無效的，因為許多行為是業務發起的，並非真實攻擊，但又難以直接區分。因此，這些告警需要安全專家手動研判分析。

百度在告警研判方面面臨諸多挑戰。首先，告警研判的質量和效率難以保障。儘管百度有幾十名安全運營專家，但仍面臨專家稀缺的問題。其次，告警疲勞現象嚴重，尤其是在節假日或非上班時間，可能導致研判錯誤。第三，工具分散，需要人工在不同工具之間切換分析，效率低下。最後，研判標準參差不齊，難以統一。不同專家的研判質量不同，且受個人狀態影響較大。

我們在系統的設計和實踐中，一開始就面臨了許多問題和挑戰。對於從去年開始接觸大模型的同學來說，可能都有類似的感受。一開始看到大模型時，我們都非常興奮，認為它非常好，尤其是我們身處百度，是國內最早做大模型的公司之一。當時我們熱情很高，覺得大模型可以解決很多問題，做 demo 時效果不錯，但真正希望將其應用到真實環境中併產生實際價值時，問題就出現了。

我們最初期望將大量告警直接輸入大模型。為此，我們做了很多工作，不僅對大模型進行了 SFT（監督微調），還引入了強化學習來引導思維鏈。我們甚至將當時團隊在自動駕駛領域積累的強化學習經驗應用到大模型中，希望透過一個強大的大模型結合安全領域的知識，能夠端到端地解決問題並給出高質量的研判結果。然而，整個去年，我們在這方面嘗試失敗了，主要面臨以下幾個問題。

在實現過程中，我們踩了很多坑，最終發現端到端的方式是完全不可行的。

在不斷的迭代過程中，我們針對之前提到的問題逐步進行了修正，並形成了現有的研判方案。下圖的整體方案可以分為上下兩部分：上面部分是線上研判過程中對告警的處理，當一個告警到來時，系統會進行處理並最終給出 AI 的研判結果，判斷告警是否有風險或存在疑似風險；下面部分則是為支援線上研判系統而進行的離線建設工作。針對之前提到的六個挑戰，我們採取了以下措施。

在我們的實踐中，由於採用了逐個型別逐步攻克的方法，因此需要對告警型別進行優先順序劃分。我們基於歷史統計資料，確定了 1,000 多種告警型別的分組和分類，並根據其歷史佔比和當前趨勢，確定了建設的優先順序。這一背景是百度即將參加國家網路攻防演習，作為防守方，我們需要在演習前覆蓋重要的告警型別，因此優先順序的建設至關重要。

有了優先順序後，針對特定告警型別，我們在離線階段會提前生成一個研判流程的 workflow。最基礎的方式是直接與安全運營人員溝通，瞭解他們對告警的研判邏輯和步驟。然而，安全領域的很多經驗是難以言傳的，專家往往難以清晰地描述其完整的研判過程。因此，我們採用了以下約束條件：

在離線階段，透過以上約束，大模型可以自動生成一個研判流程。線上環節中，對於流程完全固定的告警型別，我們直接將模板提供給大模型，由其進行研判。而對於流程可能變化的告警型別，例如告警中包含額外資訊的情況，我們會啟動要點的動態發現過程，補充具體案例的研判流程。透過這種方式，我們既保證了研判流程的可控性和準確性，又能夠靈活應對告警的具體變化。

這裡舉一個具體的例子，比如針對釣魚郵件的研判。我們之前透過離線建設，基於郵件本身的告警規則和專家經驗生成了一個研判流程模板，這就是圖中左邊部分的內容。這個模板會被提供給大模型用於研判。然而，在告警資訊中，如左下角第四張圖所示，可能會包含額外的資訊，比如一個 IP 地址。而我們原來的研判流程模板中並沒有包含對 IP 的處理。在大模型進行線上研判時，它會結合告警內容和已有的研判流程模板，動態修改流程。例如，如果告警資訊中包含 IP 地址，大模型會在流程中增加一條新的步驟，呼叫 IP 相關的工具進行分析。

在研判流程中，會用到各種研判工具，這裡涉及兩個問題：一是工具建什麼，二是工具如何建。對於“建什麼”的問題，一方面，我們透過與專家溝通，人工抽象出所有需要的工具；另一方面，利用大模型自身的 AI 研判要點發現能力，允許大模型提出工具需求。例如，在第一次研判時，大模型可能發現需要某個工具，但我們尚未具備，這時就需要去建設這個工具。以釣魚郵件為例，其工具需求主要包括郵箱判斷工具、內容分析工具、資訊查詢工具等，而大模型還發現了對 IP 研判工具的需求。

在具體的工具集建設方面，一方面，我們透過常規方式接入工具，比如利用 API 或指令碼，將歷史上所有的安全工具自動化整合進來。另一方面，我們發現很多需求可以透過大模型統一完成。例如，所有涉及語義理解的工具和資訊獲取的工具，都可以由大模型直接實現。

為了確保大模型的研判全面且準確，我們非常重視環境知識的構建。因為許多告警是否真正存在風險，很大程度上依賴於當前所處的環境資訊。為此，我們構建了一整套底層的資產圖譜，涵蓋從機器到程序、檔案、人員關聯以及場景等多個維度，全面刻畫研判環境。在實際應用中，當發現針對某些資產的告警時，我們會透過資產圖譜提取與該資產相關的所有資訊，並將其輸入大模型，以幫助其做出更準確的研判。

在綜合了模板、工具以及當前環境知識後，大模型會給出一個風險分析說明。然而，我們提出了一個關鍵需求：精確判白，確保沒有風險遺漏。因此，我們採用的是高風險召回的 AI 研判策略，確保所有風險告警的 100% 召回率。只有這樣，運營人員才能信任“無風險”的結論，僅對報風險的告警進行進一步人工研判。否則，系統就會淪為純粹的資訊輔助工具。

為了實現這一目標，我們設計了三重保障機制。首先，在生成風險分析說明後，我們會向大模型明確闡述無漏召的研判原則。結合風險分析說明和這一原則，我們形成一個綜合的 AI 研判提示（Prompt），要求大模型只有在能夠完全排除風險的情況下，才能給出“無風險”的結論，否則不得輕易判定為白。其次，我們會對大模型的結論進行二次審查，再次確保其準確性。最後，我們會結合當前告警的研判結果、相關告警的研判結果以及歷史相似告警的結論，再次輸入大模型進行綜合分析，得出最終結論。透過這三步保障機制，我們確保所有判定為“無風險”的告警是 100% 確定的。

在具體資料方面，針對釣魚郵件、加密執行或掃描類告警，我們目前的無風險判定（判白）精確率達到了 100%。這表明我們能夠透過全自動化的方式解決大部分告警，雖然並非所有告警都能達到 100% 的判白率，但至少大部分告警已經可以透過自動化處理。剩餘的一部分仍需人工進一步研判。

我們設計了一套具有強可解釋性的輸出模板，以確保運營人員能夠清晰地理解研判結果。首先，在研判流程規劃階段，我們將整個研判流程以視覺化的方式儲存下來，明確展示大模型是如何基於特定邏輯對告警進行判斷的。其次，在要點分析階段，如果判定為無風險，我們會給出明確的無風險提示；如果存在風險，則會將具體的風險點逐一彙總。在綜合研判結果階段，我們會專門列出分析過程和建議。透過結構化資料和 Prompt 控制輸出格式，我們在前端進行統一展示，從而為運營人員提供更清晰、更直觀的結果。

針對高風險告警資料稀缺、多樣性不足的問題，我們在研判能力上線前面臨了評估難題。為解決這一問題，我們嘗試利用大模型生成多樣化的攻擊資料。具體方法如下：首先，確保生成的資料能夠觸發告警規則，因此 Prompt 中必須包含告警規則，以保證告警能夠被觸發；其次，確保樣例資料的格式正確；最後，設計一套 Prompt 以確保生成的資料存在風險。透過將這些 Prompt 輸入大模型，利用其多樣化的生成能力，並透過額外的 Prompt 引導，我們能夠生成一系列符合告警規則且具有多樣性的資料。例如，針對常見的 Base 64 編碼執行命令的告警，我們利用大模型生成大量合成數據，豐富告警資料的多樣性。這些合成數據不僅提升了研判評估的效果，還作為資料飛輪進一步優化了整個研判過程。

我們設計了一個安全運營平臺介面。下圖左邊的列表顯示待處理的告警，不同顏色標識代表不同的研判狀態：綠色表示 AI 已明確判定為無風險（判白），紅色表示高度可疑需優先人工研判，灰色表示大模型未找到明確證據判定黑白，需進一步關注。右邊區域則展示了點選左邊告警列表中某一項後的詳細資訊，包括研判建議、要點和過程。目前，我們的研判能力已覆蓋大部分告警型別，線上告警量降低至原來的 18.8%，直接節省了約 80% 的工作量。此外，透過詳細資訊展示，原本需要人工研判的部分也能進一步提速提效。

我們認為大模型在安全運營領域乃至整個安全行業，正呈現出從自動化到智慧化，再到智慧體化的演進趨勢。過去所謂的 AI 更多是實現自動化功能，替代的是傳統機器的工作，例如基於策略或規則的任務，透過機器學習或深度學習解決特定的安全輔助任務。然而，大模型的出現真正推動了智慧化的發展，它輔助人類完成複雜任務，例如安全運營中的流程編排、工具呼叫、知識增強和推理增強。儘管如此，我們尚未完全實現真正的智慧體化。雖然目前大家都在討論智慧體的概念，但直接構建一個端到端的智慧體來完成整個任務仍然具有挑戰性。不過，這無疑是未來的發展方向。我們預期未來大模型能夠端到端地承擔具體任務，例如告警研判智慧體或事件處置智慧體，透過意圖識別智慧體進行任務分發，從而實現安全運營領域任務的協同完成。

從安全運營的角度來看，百度正在重構其安全運營系統。在重構過程中，我們發現當前的安全運營平臺雖然在介面上增加了 AI 按鈕或資訊，但本質上仍然是以人為中心，將 AI 作為輔助工具的設計理念。然而，隨著技術從自動化邁向智慧化，最終實現智慧體化，未來的安全運營中心不應再沿用傳統的管理介面設計。它將以大模型為核心，人類僅作為輔助存在，整個系統是為大模型服務而非單純為人設計的。

基於這一理念，未來的安全運營中心將包含三個重要層面：

透過這樣的架構設計，未來的安全運營中心將真正實現以大模型為核心、人類為輔助的模式，人類只需在大模型尚未覆蓋的極小部分工作上進行干預。這正是我們持續努力的方向。

包沉浮，百度傑出架構師，安全技術委員會主席，整體負責百度集團安全技術體系建設。當前重點關注人工智慧安全技術的研究與應用，包括 AI 技術在網路安全領域的應用，以及大模型的安全保障技術體系。參與制定多項 AI 安全領域重要國家標準，並獲得 20 餘項國內外授權專利。擔任中國人工智慧產業聯盟安全治理委員會副主任委員。

在 AI 大模型重塑軟體開發的時代，我們如何把握變革？如何突破技術邊界？4 月 10-12 日，QCon 全球軟體開發大會· 北京站 邀你共赴 3 天沉浸式學習之約，跳出「技術繭房」，探索前沿科技的無限可能。

本次大會將匯聚頂尖技術專家、創新實踐者，共同探討多行業 AI 落地應用，分享一手實踐經驗，深度參與 DeepSeek 主題圓桌，洞見未來趨勢。