百度基于大模型安全运营的质效提升实践

分享嘉宾 | 包沉浮

审校 | Kitty

策划 | QCon 全球软件开发大会

百度作为一家业务复杂的大型互联网企业，同时又是关键基础设施，随着网络安全威胁的日益加剧，传统的安全运营手段在效率和效果上都面临巨大挑战。在 InfoQ 举办的 QCon 全球软件开发大会上百度杰出架构师，安全技术委员会主席包沉浮为我们带来了精彩专题演讲“百度基于大模型安全运营的质效提升实践”，分享将介绍百度如何基于大模型构建深度安全推理智能体框架，实现运营效率和效果的双重提升，并展示包括告警自动研判和漏洞事件分析在内的实践经验，希望能给听众带来一些大模型安全领域应用最佳实践的启示。

在即将于 4 月 10 日召开的 QCon 全球软件开发大会（北京站），包沉浮老师作为会议出品人，策划了「大模型安全」专题，涵盖大模型安全的技术趋势和前沿挑战，多模态 AIGC、智能体、具身智能等新兴技术应用的安全风险与应对以及在企业中的应用和实践。专题详情：https://qcon.infoq.cn/2025/beijing/track/1770

内容亮点：

• 从架构设计层面剖析安全运营场景双效提升应遵循的必要准则，提供构建深度安全推理智能体框架的完整视角。

• 细粒度展现告警研判、漏洞分析处置等实际场景的双效提升最佳实践。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

背景和挑战

大模型的重要性不言而喻，它正在加速整个社会的数字化、智能化转型。然而，大模型也带来了更为严峻的安全挑战。一方面，大模型的规模引发了新的安全风险。其算力、数据量和算法规模的持续增长，使得系统的复杂度和应用场景的丰富度不断提升，从而增加了安全风险的复杂性。传统的安全风险在不断增加，同时大模型还引入了许多新兴的安全风险。另一方面，大模型技术可能被用于网络攻击。例如，大模型可用于生成恶意代码和自动化攻击，利用其生成的内容进行深度伪造以实施社会工程学攻击，甚至可以绕过传统的安全防护和检测机制。这些都构成了新的挑战。

大模型也为网络安全领域带来了新的机遇。自去年起，全球网络安全厂商纷纷推出基于大模型的安全产品，如微软的 Security Copilot。国内的深信服、奇安信、360 等大厂也推出了自己的基于大模型的安全产品。大模型在安全领域的应用场景丰富多样，包括安全运营、数据安全、邮件安全、自动化渗透测试等。

安全工作主要分为三类：安全研发、攻防对抗和安全运营。安全研发涉及开发安全系统软件，如防火墙、杀毒软件等；安全运营则是通过流程机制，利用软件和系统持续监控、检测、预防和响应网络攻击与威胁，确保组织的系统、数据和网络安全。由于安全运营高度依赖人力，因此大模型在这一领域的应用备受关注。大模型在安全运营中的潜在应用主要包括告警研判、事件响应与止损、安全事件分析与溯源、受影响资产修复与加固，以及事件报告生成等。

以百度为例，核心安全运营环节是告警研判。百度是一家拥有 20 多年历史的互联网公司，拥有大量网络资产，包括超过 60 万台主机、超过 1,000 万容器以及超过 10 万台办公设备。多年来，百度建立了一套多级纵深威胁感知和防御对抗体系，从网络边界到主机系统、容器环境和应用进程服务，都部署了大量自主研发的安全系统和软件。这些系统会产生大量告警，来源包括办公网中的 EDR 终端检测响应设备、邮件安全检测、杀毒检测，以及 IDC 环境中的 HIDS（主机入侵检测系统）和应用层防护等。百度积累了超过 1,000 条告警规则，每天产生超过 10 万个新增告警。然而，其中大部分告警是无效的，因为许多行为是业务发起的，并非真实攻击，但又难以直接区分。因此，这些告警需要安全专家手动研判分析。

百度在告警研判方面面临诸多挑战。首先，告警研判的质量和效率难以保障。尽管百度有几十名安全运营专家，但仍面临专家稀缺的问题。其次，告警疲劳现象严重，尤其是在节假日或非上班时间，可能导致研判错误。第三，工具分散，需要人工在不同工具之间切换分析，效率低下。最后，研判标准参差不齐，难以统一。不同专家的研判质量不同，且受个人状态影响较大。

系统设计与实践

安全运营场景大模型应用的挑战

我们在系统的设计和实践中，一开始就面临了许多问题和挑战。对于从去年开始接触大模型的同学来说，可能都有类似的感受。一开始看到大模型时，我们都非常兴奋，认为它非常好，尤其是我们身处百度，是国内最早做大模型的公司之一。当时我们热情很高，觉得大模型可以解决很多问题，做 demo 时效果不错，但真正希望将其应用到真实环境中并产生实际价值时，问题就出现了。

我们最初期望将大量告警直接输入大模型。为此，我们做了很多工作，不仅对大模型进行了 SFT（监督微调），还引入了强化学习来引导思维链。我们甚至将当时团队在自动驾驶领域积累的强化学习经验应用到大模型中，希望通过一个强大的大模型结合安全领域的知识，能够端到端地解决问题并给出高质量的研判结果。然而，整个去年，我们在这方面尝试失败了，主要面临以下几个问题。

• 告警类型的适应性差

  我们有 1,000 多个告警类型，希望用统一的处理流程来处理，但发现无法覆盖所有告警类型。许多告警的误报和漏报率非常高，难以通过单一的处理方式解决。

• 研判过程不可控

  大模型的输出通常有其自身的思维链，很难让其按照我们期望的思路运行。它并不是按照安全专家的思路来研判告警的，且输出结果具有随机性。同一次查询可能得到不同的回答，这使得整个研判过程不可控，导致结果不受信任。

• 综合分析能力不足

  大模型有时会忽略告警中的细节，或者在告警信息不足以做出判断时，仍然强行给出解释。这使得其结论的准确性和全面性无法保证。

• 错判、漏判和混杂问题

  在安全领域，召回率和精确率很难同时达到 100%，需要在两者之间找到平衡。对于安全运营场景，我们希望大模型能够真正解决效率问题。但如果告警研判结果既不能保证完全准确，又不能保证完全召回，最终仍需人工逐一审核，那么大模型提供的辅助信息就显得无关紧要，对安全运营人员的帮助不大。

• 缺乏决策透明度和可解释性

  大模型的表达方式较为随机，输出内容冗长且难以快速提取有用信息。这增加了人工审核的难度，也影响了安全运营人员对大模型结果的直接采纳。

• 研判能力评估困难

  安全行业的特点是黑白样本分布不均衡，白样本多而黑样本少。真实环境中缺乏足够的黑样本用于评估新的风险类型。这使得我们在上线新的研判能力时，很难充分评估其效果，难以得出可靠的离线评估结论。

在实现过程中，我们踩了很多坑，最终发现端到端的方式是完全不可行的。

大模型告警研判方案

在不断的迭代过程中，我们针对之前提到的问题逐步进行了修正，并形成了现有的研判方案。下图的整体方案可以分为上下两部分：上面部分是在线研判过程中对告警的处理，当一个告警到来时，系统会进行处理并最终给出 AI 的研判结果，判断告警是否有风险或存在疑似风险；下面部分则是为支持在线研判系统而进行的离线建设工作。针对之前提到的六个挑战，我们采取了以下措施。

• 提升告警类型的适应性

  针对不同告警类型适应性差的问题，我们采用了较为“笨”的方法，即为每种告警类型设计了不同的研判流程。虽然我们有 1,000 多种告警类型，但并不是对每一种都单独处理，而是根据告警的类别（如邮件告警、风险命令告警、扫毒告警、账号告警等）分别设定了研判流程模板。这些模板为大模型提供了固定的思维链，使其能够按照既定流程进行研判，而非随意发挥。

• 研判过程可见可控

  为了提高效率，我们引入了 AI 流程规划，部分流程由 AI 辅助生成，从而限制了大模型的思维过程，使其更加可控。

• 告警信息全面分析

  在大模型的研判过程中，我们不仅依赖静态的流程模板，还允许大模型在接收到告警后，基于已有模板动态生成新的研判要点，形成新的流程。这一过程中涉及工具调用和知识增强等技术，这些技术在智能体领域已经较为常用。通过这种方式，我们能够对告警信息进行全面分析，避免因模板的局限性而遗漏重要信息。

• 无风险遗漏

  我们希望 AI 能够准确判断无风险的告警，从而减少人工审核的负担。因此，在系统设计中，我们特别关注无风险告警的准确性，通过优化算法和模型，确保 AI 给出的“无风险”结论是可靠的，避免因误判而导致安全风险的遗漏。

• 决策透明度高

  无论 AI 的研判结论是否被直接采纳，我们都希望其输出具有可解释性。这意味着 AI 需要提供清晰的解释，说明其判断的依据和推理过程，以便安全运营人员能够快速理解结论并做出进一步的判断。通过增强可解释性，我们提高了人机协作的效率，同时也增强了安全运营人员对 AI 结果的信任度。

• 充分评估研判能力

  为了评估整个研判系统的性能并对其进行优化，我们基于 AI 生成了多样化的攻击数据，从而模拟出大量的告警。这些模拟告警一方面用于评估系统的检测性能，另一方面用于优化研判系统，使其能够更好地应对真实环境中的安全威胁。通过这种方式，我们在有限的真实样本基础上，充分利用模拟数据来提升系统的可靠性和准确性。

在我们的实践中，由于采用了逐个类型逐步攻克的方法，因此需要对告警类型进行优先级划分。我们基于历史统计数据，确定了 1,000 多种告警类型的分组和分类，并根据其历史占比和当前趋势，确定了建设的优先级。这一背景是百度即将参加国家网络攻防演习，作为防守方，我们需要在演习前覆盖重要的告警类型，因此优先级的建设至关重要。

有了优先级后，针对特定告警类型，我们在离线阶段会提前生成一个研判流程的 workflow。最基础的方式是直接与安全运营人员沟通，了解他们对告警的研判逻辑和步骤。然而，安全领域的很多经验是难以言传的，专家往往难以清晰地描述其完整的研判过程。因此，我们采用了以下约束条件：

• 思路约束：提取历史告警规则，利用大模型生成初步的研判要点，然后再由专家进行 review 和补充。这样生成的研判要点可以作为大模型的思维约束，明确其研判的要点和逻辑。

• 工具约束：将现有的所有研判工具列表提供给大模型，作为其工具调用的约束。

• 格式约束：通过流程生成的案例，为大模型提供流程格式的约束。

在离线阶段，通过以上约束，大模型可以自动生成一个研判流程。在线环节中，对于流程完全固定的告警类型，我们直接将模板提供给大模型，由其进行研判。而对于流程可能变化的告警类型，例如告警中包含额外信息的情况，我们会启动要点的动态发现过程，补充具体案例的研判流程。通过这种方式，我们既保证了研判流程的可控性和准确性，又能够灵活应对告警的具体变化。

这里举一个具体的例子，比如针对钓鱼邮件的研判。我们之前通过离线建设，基于邮件本身的告警规则和专家经验生成了一个研判流程模板，这就是图中左边部分的内容。这个模板会被提供给大模型用于研判。然而，在告警信息中，如左下角第四张图所示，可能会包含额外的信息，比如一个 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 作为辅助工具的设计理念。然而，随着技术从自动化迈向智能化，最终实现智能体化，未来的安全运营中心不应再沿用传统的管理界面设计。它将以大模型为核心，人类仅作为辅助存在，整个系统是为大模型服务而非单纯为人设计的。

基于这一理念，未来的安全运营中心将包含三个重要层面：

• 安全工具层：这一层面要求极高的工具集成度，因为所有安全工具都需要能够被大模型直接访问和调用。

• 核心层：以安全大模型为中心的智能引擎，以及基于该引擎的各种智能体和通用安全智能组件，例如意图识别、安全问答、智能知识管理等。

• 接口层：包括告警事件的统一接入、情报、漏洞、资讯的统一接入以及 BI 报表等功能。

通过这样的架构设计，未来的安全运营中心将真正实现以大模型为核心、人类为辅助的模式，人类只需在大模型尚未覆盖的极小部分工作上进行干预。这正是我们持续努力的方向。

演讲嘉宾介绍

包沉浮，百度杰出架构师，安全技术委员会主席，整体负责百度集团安全技术体系建设。当前重点关注人工智能安全技术的研究与应用，包括 AI 技术在网络安全领域的应用，以及大模型的安全保障技术体系。参与制定多项 AI 安全领域重要国家标准，并获得 20 余项国内外授权专利。担任中国人工智能产业联盟安全治理委员会副主任委员。