基于推理模型+RAG+Agent，作业帮内部安全体系建设实践

深度学习与Python

发布于 2025-04-24 01:50:18

1140

文/作业帮基础架构团队（吕亚霖、尚义龙）

背景

在互联网智能化与 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 应用防火墙，并对数据库操作进行监控。处置结论是生成一个工单，以便进一步跟踪和处理该事件。

第一步语义分段：