网安这个大模型项目做到数据准备阶段的时候最容易产生的一种错觉就是“已经收集了不少数据集接下来可以训练了”。真把数据摊开看坏样本、重复样本、无意义广告文本、日志里的敏感信息、时间错位的旧漏洞描述会让后续训练和评测几乎没法收敛。做网络安全的专用模型跟做通用助手模型不同它需要让模型理解漏洞编号、攻击链、检测规则、资产信息这些强结构化知识而这些知识绝大多数散落在不同来源、不同格式、不同授权条款里。这篇是实战篇第十四篇重点聊清楚网络安全大模型训练里的数据获取环节包括数据源怎么选、采集怎么落地、清洗和脱敏怎么做、去重和质检要留哪些心眼顺手把我确实踩过的一些坑也写出来。1. 为什么网安大模型的建模难点首先出现在数据层1.1 网络安全的“行话”决定了它不能当普通文本处理如果直接把网上的安全博客、论坛帖子、公众号文章拉下来做通用文本清洗训练出来的模型能聊大面儿但一到具体场景就露馅。网络安全的专业内容里大量出现CVE编号、ATTCK技术编号、IP地址、域名、哈希值、端口、协议名、漏洞类型描述这些信息是强结构化的不能用通用清洗规则一把梭。比如CVE-2024-1234这种编号是漏洞的唯一标识任何解析器都会依赖这种格式的稳定性如果清洗时做了大小写归一化、添加空格或者去符号模型就很难学习“CVE编号”与漏洞描述之间的对应关系。我当时在建数据规范的时候就定了一个原则先做领域实体标注与字段抽离再做正文清洗。换句话说不要把CVE编号、IP列表、文件名当纯文本抹掉而要先把它们抽成独立字段保留正文部分再考虑怎么去噪。像“Apache HTTP Server 2.4.49存在路径穿越漏洞”这句话真正有价值的是“Apache HTTP Server 2.4.49”和“路径穿越”之间的关联要是清洗时把件版本号都删掉那这条样本对漏洞检测模型来说就废了。1.2 数据来源必须按用途分层不能一锅炖网安大模型通常不是单一任务而是多任务混合有的做漏洞信息抽取有的做告警降噪有的做检测规则生成有的做安全问答还有的做威胁情报归因。不同任务需要的数据粒度完全不一样。不能把CVE描述、恶意样本分析报告、渗透测试笔记、运维告警日志混在一起直接训练那样任务边界太模糊模型学出来的能力会很稀碎。我通常会把数据池分为三层。第一层是“底座语料”就是通用的安全知识包括经典漏洞库、手册、科普文章、安全标准文档用来做领域继续预训练第二层是“指令微调语料”要的是问题和答案配对比如“如何检测Log4Shell利用特征”和一段可复现的检测规则第三层是“偏好对齐语料”用于后续人类反馈标注要从真实告警处置记录、安全运营报告里提取“好答案”和“坏答案”的对比样本。三层数据在获取方式、清洗粒度和授权要求上差别很大从一开始就分开目录管理会省很多事。1.3 时间维度比想象中重要网络安全数据有非常强的时间属性。2017年的永恒之蓝利用样本和2023年的勒索软件行为模式在方法论上有延续但在具体IoC和检测规则上完全不同。如果训练集里混入了大量过时数据而且没有给模型显式的时间信息模型很容易把旧漏洞当新威胁。这个问题在数据采集阶段就会被放大从网站抓来的文章通常不带时间标签或者页面里写的时间不准确只显示“3天前”这种相对时间直接入库会让数据的时间维度全部错乱。我后来强制要求每一批采集到的原始数据都记录三个时间字段发布源时间、采集时间、入库时间。发布源时间用于切分训练和验证集防止时间泄漏采集时间和入库时间用于问题排障和数据版本回溯。很多团队只记录一个采集时间导致后续做“用2024年以前数据训练、2024年以后数据评测”时会发现测试集里包含了训练阶段后才出现的文本这种脏数据会造成模型真实能力被高估。2. 主流数据源盘点与采集路径设计2.1 公开漏洞库最值得先拿下的底座公开漏洞库是网安数据里结构最规整、质量最稳定的一部分也是首选切入的数据源。NVD和CVE官方提供的JSON数据包支持批量下载里面有CVE编号、描述、CVSS评分、参考链接、受影响产品这套数据可以成为漏洞理解任务的主干。国内的中文漏洞库同样重要因为直接翻译NVD的中文描述往往很僵硬中文安全社区写的漏洞通告更口语化、更贴近实际业务表达。把两类描述混合起来中文表达能力和术语准确性都会有明显提升。除了漏洞本身MITRE ATTCK的战术、技术、子技术描述攻击模式库CAPEC弱点枚举库CWE这些都是高质量领域知识。特别建议把ATTCK的技术名称和描述做成结构化语料很多安全大模型回答“攻击者拿到权限后怎么横向移动”这类问题时如果训练数据里只有百科式列表没有具体攻击背景回答就会很空。这些知识库的表述虽然偏文档化但它们是理解“攻击链”的关键素材。实际操作上直接调用NVD的API逐个请求并不划算接口限流和断点续传都要自己处理。更高效的方式是定期下载全量JSON或增量JSON本地建一个轻量级数据库先存原始记录再按日期、漏洞类型、影响产品等维度生成训练样本。像NVD的CVE记录里references和weaknesses字段往往被忽略但这些字段描述攻击场景时很有价值建议清洗期不要急着删掉。2.2 开源威胁情报与样本报告补齐攻击上下文漏洞库解决的是“有什么漏洞、影响是什么”但模型要真正具备实战判断还依赖攻击工具使用案例、恶意样本分析报告和事件响应复盘。这类数据来源分散主要藏在安全厂商的公开研究报告、技术博客、GitHub仓库里的检测规则、恶意软件分析平台的样本描述以及各类安全论坛的讨论帖中。恶意样本库最好是拿报告文本而不直接拿样本二进制。真正有价值已结构化好的数据源包括MalwareBazaar等公开样本库中的样本标签与家族描述以及厂商发布的勒索软件分析报告、供应链事件复盘。这些文本会反复用到哈希值、互斥量、C2地址、YARA规则等专业字段清洗的时候必须保留这些实体它们恰好是后续生成检测规则任务需要的监督信号。GitHub上的检测规则仓库比如Sigma规则、YARA规则和Suricata规则是非常适合用于“规则生成”能力训练的天然对齐语料。它们本身就是高度结构化的规则文本配上规则所对应的攻击行为描述就可以做成指令样本。这种数据不需要太多几百条到几千条精选规则其实就够了重点是把规则语法与攻击现象关联起来。2.3 采集工程化先看授权再谈并发很多人一上手就想写多线程爬虫去抓网站但第一个要确认的不是并发量而是目标信息的授权范围。公网漏洞库API大多有清晰的请求条款GitHub上的仓库则遵循开源协议论坛和博客则要看robots协议和服务条款。数据获取阶段做一次版权和授权排查比模型上线后收到函要容易处理得多。完全公开的CVE描述和一些政府资助的知识库通常没有授权限制而商业报告、付费知识星球、部分技术社区的内容则需要非常谨慎。采集的执行层面有几个连续的动作可以复用。第一步是做URL层面的注册每个抓取的链接记录来源域名、页面标题、首次抓取时间和最终存储路径。第二步是抽取正文简单HTML解析不够很多页面有目录、页脚、相关推荐、评论我们当时先用readability算法抽正文再配合规则把代码块、表格按原样保留不容易丢专业信息。第三步是正文分块把长文章按标题切段每段单独保存保留标题上下文后续做微调样本时就不用再全文对齐。这里提醒一下很多安全博客站点的访问频率比普通站点敏感得多有些站点会因为访问异常直接封段IP。不要用猛火式并发建议单域名控制在每秒几个请求以内同时做好失败重试和请求失败日志记录。还有下载原始HTML文件保留一个备份副本而不是只存抽取出的正文因为清洗规则要调优时原始页面作为底稿可以在不重新抓取的情况下重新抽取。3. 数据清洗与脱敏把“脏数据”变成训练样本3.1 清洗的第一步不是分词而是字段抽离与结构化专业语料里最怕的是把文本里所有实体当成普通字符给模型带来噪音。比如恶意样本分析报告里常有“MD5: 2f4d...”如果这块内容被清洗成普通句子模型无法建立“MD5哈希”与“文件样本”的关系。我建议清洗前先跑一遍实体识别与标注规则把以下类别抽出来存成独立字段CVE编号、ATTCK编号、IP地址、域名、URL、SHA256/MD5哈希、端口号、漏洞类型、受影响版本、检测规则片段。抽离过程可以用正则先兜底再借助自有安全实体识别模型做二次补充。像IP地址、哈希值这种格式很强的字段正则就够了但“路径穿越”“命令注入”“反序列化”这类漏洞类型词需要建立同义词词表去归一化。比如“RCE”和“远程代码执行”是同一个意思统一成“远程代码执行”模型学出来的语义才不散。注意归一化词表要人工评审不能自动替换很多漏洞类型名称在不同语境下含义有细微差异。字段抽离后再对正文做通用清洗去掉页头和页脚、去乱码、统一全角半角、处理空格、分出标题、摘要和正文。对于代码块建议保留原始缩进因为像SQL注入语句和YARA规则这类内容格式化之后虽然看起来整齐但模型学到的是被改写的代码样式后续生成检测规则时会产生格式污染。3.2 脱敏不能只在发布前做要嵌入清洗流水线网络安全语料大量来自真实告警日志、流量抓包记录、事件复盘这些文本天然包含真实IP、员工账号、域名、文件路径和邮件地址。如果原样进入训练语料既存在数据泄露合规风险也会让模型记忆特定组织的内部资产信息上线后一旦被诱导可能把不该说的内部信息兜出来。我测试过一个简单但实用的脱敏流程。第一类是IP脱敏区分两种情况对于被标记为恶意IoC的IP通常在报告中需要保留到“可作为检测指标”的粒度但作为通用语料时建议把最后一段清零并添加随机扰动对于日志来源的内部IP直接全部抹掉并替换为内网保留地址段。第二类是域名和URL脱敏把可读的真实域名替换成“example.com”风格占位符同时保留域名结构和顶级后缀这样模型能学到URL形态但不会记忆真实域名。第三类是个人信息识别包括邮箱、电话、身份证号、社交账号用正则加模型组合识别并替换。脱敏一定要放在去重之前做还是去重之后做我自己倾向先脱敏再去重。如果先去重同一条日志的多个变体只是换成不同时间戳或IP可能因为内容高度相似被去重掉但实际上它们在训练中能起到增强模型泛化能力的作用。先做占位符统一再做相似度去重就能把真正重复的内容去掉把属于同一事件但细节不同的样本保留下来。3.3 版权、授权与来源留痕不是可有可无的元数据整理训练数据集时最常见的管理习惯是只存正文内容丢了来源链接、作者和授权说明。模型训练完如果遇到版权质疑想回溯每一段文本的具体出处会变成一件特别耗时的事。所以从一开始就要给每个文本样本建立来源元数据至少包含来源URL、标题、作者/机构、原文发布时间、采集时间、授权类型、清洗规则版本这些字段并随样本一起保存。不同来源的授权差异在训练实践中影响很大。比如某些商业安全报告虽然公开可读但明确写了禁止用于模型训练另一些开源项目使用了CC BY-SA协议这种协议允许使用但要求保留署名而且衍生内容也要以相同方式共享CC BY-NC则限制商业用途需要单独评估。在数据源接入时做一个简单的授权评估表把每个来源的许可证和评估结果列出来是很有必要的。4. 去重、质量评估与多任务配比4.1 用MinHash结合LSH完成近重复清洗网络安全文本的实际去重难度比通用语料高很多。同一漏洞的报道在多个平台出现时标题往往只差一两个词正文明明是复制粘贴但中间混入了一两句不同的评论用简单的hash去重完全拿它没办法。这时候要处理的是近重复文本需要计算Jaccard相似度但两两比较十万条文本的复杂度又不可接受。实战中更通用的方案是MinHash与局部敏感哈希联合使用把相似文本映射到同一个桶里再在桶内做细粒度配对。我自己在项目中用datasketch库处理了大概几十万条安全相关文档核心代码看起来是这样。from datasketch import MinHash, MinHashLSH def build_shingles(text, k10): text text.replace(\n, ).strip() if len(text) k: return {text} return {text[i:ik] for i in range(len(text) - k 1)} def text_to_minhash(text, num_perm128): m MinHash(num_permnum_perm) for shingle in build_shingles(text): m.update(shingle.encode(utf-8)) return m lsh MinHashLSH(threshold0.8, num_perm128) index {} for idx, text in enumerate(corpus): m text_to_minhash(text) lsh.insert(fdoc_{idx}, m) index[fdoc_{idx}] (m, text) duplicates set() for idx, text in enumerate(corpus): m text_to_minhash(text) candidates lsh.query(m) for cand in candidates: if cand fdoc_{idx}: continue if (idx, cand) in duplicates or (cand, idx) in duplicates: continue m2, cand_text index[cand] jaccard m.jaccard(m2) if jaccard 0.85: duplicates.add((idx, cand))shingle的k值直接影响结果。中文按字切分时k取8到12比较合适k太小会把不同主题的文本也判成相似k太大会漏掉部分改写。num_perm控制桶的精度128在中等规模数据上效果稳定数据量到千万级可以提高到256但内存和耗时也要成倍增加。还有这个例子只是为了说明流程真正处理时通常先把文本做长度归一化只有长度差异在20%以内的两篇文本才值得做相似度比较否则直接跳过能省下大量计算。4.2 质量过滤从硬规则到模型打分去重只是把重复样本干掉真正的低质量内容还要靠过滤规则和模型打分配合处理。我使用的硬规则包括文本长度过滤、语言类型过滤、敏感词过滤和结构完整度过滤。长度过滤这一项需要区分长文档和短样本做继续预训练的文档至少500字指令微调样本则可以是短问答只要问题与答案配对清晰就行。语言类型过滤对中英混合语料要特别小心不能直接用简单语言检测库处理因为安全文本里英文术语占比很高很多中文句子会被误判成英文。硬规则过滤之后还需要一个质量分数来排序和筛选。可以用一个轻量的二分类模型判断文本是否“像真正的安全技术内容”也可以直接用规则组合打分领域关键词密度高加分包含CVE编号或ATTCK编号加分正文与标题相关性强加分包含大量广告特性词减分文本连续重复程度高减分。这个打分可以作为后续采样概率的依据不用一刀切把低分样本删掉可以直接在采样时降低概率。4.3 数据配比与训练验证隔离是两条硬纪律网安场景中不同任务的数据量天然不均衡漏洞通告类语料量很大且句式相对统一而高质量的入侵检测告警标注数据却非常少可能只有几百条。把这两类数据按原始数量比例机械地丢进训练集模型会大概率过拟合大型类别小类别任务学不出来。整体配比应该在查看分布后人工干预比较稳妥的做法是先确定关键任务所需最低样本量再逐步把通用语料加进来做损失加权训练而不是一次混入全量数据。下面是我在类似任务上常用的起始配比参考具体数值肯定要按自己场景调。数据类别建议起始比例说明通用安全预训练语料60%-70%覆盖CVE库、博客、技术手册漏洞识别与信息抽取10%-15%结构化CVE记录、漏洞通告威胁分析与告警处置8%-10%安全分析报告、告警日志、事件复盘检测规则生成与修复建议5%-8%Sigma/YARA规则、补丁建议安全问答与指令任务5%-10%手工构造或从知识库生成的问答对训练集和验证集的隔离也有特别要求。网安数据时间波动大我强烈建议按原文发布时间切分而不是随机切分。如果随机切分一篇2024年日志的改写版本可能出现在训练集里2025年同一主题的漏洞通告则出现在测试集里这种跨时间泄漏会让模型评估虚高但实际部署到新漏洞上效果就崩。有一个经验是给评估集留足时间间隔比如训练集用2023年6月之前的数据测试集用2023年7月到12月的数据这样更能反映模型面对新出现内容的泛化真实水平。5. 常见问题排查与避坑清单5.1 采集端高频异常不是网站挂了是你的解析有问题做数据采集时最容易遇到的状况是文档下载到一半报错或者HTML解析出的正文全是JavaScript脚本。有些攻击情报站点本身就在前端做了内容混淆或多层过滤直接抓HTML根本拿不到有价值内容需要通过浏览器渲染或调用站点提供的公开API拿数据而不是硬啃反爬。遇到下载中断先看是不是网络代理不稳定再确认数据源是否做了分页限制。采集阶段的日志一定要记录响应状态码和错误原因只记录成功数量会让排查变得特别困难。文本编码问题在中文安全站里很常见。某些老站点页面是GBK编码没有用UTF-8解析就会变成乱码。采集时先根据HTTP响应头里的charset字段确定编码如果响应头缺失再用meta标签检测。入库前统一转成UTF-8并去掉BOM头。转码环节建议单独跑一遍不要等所有数据入库后再批量修复因为乱码文本往往无法恢复只能重新抓取。5.2 清洗阶段的误伤案例去重去掉了关键样例做去重时踩过一个挺典型的坑同一条CVE在不同报告里虽然正文相似度超过0.9但一个版本是漏洞分析另一个版本是应急响应处置流程两者侧重点完全不同。如果仅按相似度直接删掉一条会导致模型看不见同一漏洞在不同生命周期里的表达差异。后来我调整了策略两个样本相似度高于0.95才保留字段更完整的那条相似度在0.8到0.95之间标记为疑似重复不直接删除而是放到待人工抽检队列里或者同时做后续采样降权。另一个容易误伤的是涉及“攻击复现步骤”的案例。很多安全分析报告会把复现细节拆成多个条目或者分成多个步骤解释单看其中一段文本都不够完整整篇文档合并成一条样本才能保持语义完整。所以清洗时不要把一篇长文暴力切成完全不重叠的小段后再去重需要在切段时保留一定的上下文重叠比如每段带上上一段最后一句作为衔接这样模型读起来不会觉得信息突然断开。5.3 质量评估时如何发现“训练集泄漏”模型训练完先不要急着看数学指标可以抽几条新出现的真实漏洞描述丢给模型做漏洞识别看看效果。如果模型对训练集里的老漏洞类表现很好但一遇到最近半年的新威胁就完全答非所问八成是训练集和测试集之间有重叠或时间切分不干净。一个简单而有效的检查方式是拿测试集文本与训练集文本做一次Jaccard相似度抽检重点检查那些相似度大于0.8的样本往往会发现它们的来源URL都指向同一家资讯站点的同一篇科普文章。还有一个小细节值得留意很多数据源会在文章末尾带“相关阅读”或“往期回顾”推荐列表这些列表内容在采集时会被误当成正文导致全文正文与另一个页面的推荐标题出现意外的交叉重复。所以在清洗流程里增加一个“尾部推荐块识别”步骤可以明显减少这类脏重复。若没有做这个步骤去重的压力会成倍增长且大量算力都浪费在处理营销推荐文本上。5.4 数据版本管理不可省几百G数据也要能用一条命令回滚数据集的迭代一定需要版本管理这不是指把原始文件打一个tar包就完了而是要把原始下载包、清洗脚本、清洗参数、中间产物、最终样本集这四个层次全部关联起来。每次清洗脚本更新都记录改动内容与数据产物哈希值。这样当模型效果回归变差排障时第一时间就能确认训练用的到底是哪一批数据清洗规则是什么哪些样本在上一版中不存在。数据集的目录结构建议按数据源和任务类型分两层原始数据保留在raw目录人工标注放在annotated目录预处理后的样本放在processed目录。processed目录下的样本文件命名统一以“任务类型_来源_时间范围_版本号”格式记录能极大缓解多人协同时的混乱。整理数据集这件事不产生直接收益但它决定了后续模型训练和模型调优的效率值得专门花人力管理起来。最后分享一个经验判断数据获取与清洗阶段结束的标志不应该是“收集了多少GB”而应该是“抽检出来的样本内容准确率能稳定超过手写规则可以接受的范围”。当初每次紧急上线新爬虫数据源前至少要抽200条做人工复核专门看实体字段有没有被破坏、答案是否有上下文错位、是否含有明显敏感信息。复核不通过的数据源哪怕总量诱惑再大也会先放一放因为脏语料一旦进入基地模型后期清洗的成本远高于一开始放弃带来的损失。
网络安全大模型训练的数据获取与清洗实战指南
网安这个大模型项目做到数据准备阶段的时候最容易产生的一种错觉就是“已经收集了不少数据集接下来可以训练了”。真把数据摊开看坏样本、重复样本、无意义广告文本、日志里的敏感信息、时间错位的旧漏洞描述会让后续训练和评测几乎没法收敛。做网络安全的专用模型跟做通用助手模型不同它需要让模型理解漏洞编号、攻击链、检测规则、资产信息这些强结构化知识而这些知识绝大多数散落在不同来源、不同格式、不同授权条款里。这篇是实战篇第十四篇重点聊清楚网络安全大模型训练里的数据获取环节包括数据源怎么选、采集怎么落地、清洗和脱敏怎么做、去重和质检要留哪些心眼顺手把我确实踩过的一些坑也写出来。1. 为什么网安大模型的建模难点首先出现在数据层1.1 网络安全的“行话”决定了它不能当普通文本处理如果直接把网上的安全博客、论坛帖子、公众号文章拉下来做通用文本清洗训练出来的模型能聊大面儿但一到具体场景就露馅。网络安全的专业内容里大量出现CVE编号、ATTCK技术编号、IP地址、域名、哈希值、端口、协议名、漏洞类型描述这些信息是强结构化的不能用通用清洗规则一把梭。比如CVE-2024-1234这种编号是漏洞的唯一标识任何解析器都会依赖这种格式的稳定性如果清洗时做了大小写归一化、添加空格或者去符号模型就很难学习“CVE编号”与漏洞描述之间的对应关系。我当时在建数据规范的时候就定了一个原则先做领域实体标注与字段抽离再做正文清洗。换句话说不要把CVE编号、IP列表、文件名当纯文本抹掉而要先把它们抽成独立字段保留正文部分再考虑怎么去噪。像“Apache HTTP Server 2.4.49存在路径穿越漏洞”这句话真正有价值的是“Apache HTTP Server 2.4.49”和“路径穿越”之间的关联要是清洗时把件版本号都删掉那这条样本对漏洞检测模型来说就废了。1.2 数据来源必须按用途分层不能一锅炖网安大模型通常不是单一任务而是多任务混合有的做漏洞信息抽取有的做告警降噪有的做检测规则生成有的做安全问答还有的做威胁情报归因。不同任务需要的数据粒度完全不一样。不能把CVE描述、恶意样本分析报告、渗透测试笔记、运维告警日志混在一起直接训练那样任务边界太模糊模型学出来的能力会很稀碎。我通常会把数据池分为三层。第一层是“底座语料”就是通用的安全知识包括经典漏洞库、手册、科普文章、安全标准文档用来做领域继续预训练第二层是“指令微调语料”要的是问题和答案配对比如“如何检测Log4Shell利用特征”和一段可复现的检测规则第三层是“偏好对齐语料”用于后续人类反馈标注要从真实告警处置记录、安全运营报告里提取“好答案”和“坏答案”的对比样本。三层数据在获取方式、清洗粒度和授权要求上差别很大从一开始就分开目录管理会省很多事。1.3 时间维度比想象中重要网络安全数据有非常强的时间属性。2017年的永恒之蓝利用样本和2023年的勒索软件行为模式在方法论上有延续但在具体IoC和检测规则上完全不同。如果训练集里混入了大量过时数据而且没有给模型显式的时间信息模型很容易把旧漏洞当新威胁。这个问题在数据采集阶段就会被放大从网站抓来的文章通常不带时间标签或者页面里写的时间不准确只显示“3天前”这种相对时间直接入库会让数据的时间维度全部错乱。我后来强制要求每一批采集到的原始数据都记录三个时间字段发布源时间、采集时间、入库时间。发布源时间用于切分训练和验证集防止时间泄漏采集时间和入库时间用于问题排障和数据版本回溯。很多团队只记录一个采集时间导致后续做“用2024年以前数据训练、2024年以后数据评测”时会发现测试集里包含了训练阶段后才出现的文本这种脏数据会造成模型真实能力被高估。2. 主流数据源盘点与采集路径设计2.1 公开漏洞库最值得先拿下的底座公开漏洞库是网安数据里结构最规整、质量最稳定的一部分也是首选切入的数据源。NVD和CVE官方提供的JSON数据包支持批量下载里面有CVE编号、描述、CVSS评分、参考链接、受影响产品这套数据可以成为漏洞理解任务的主干。国内的中文漏洞库同样重要因为直接翻译NVD的中文描述往往很僵硬中文安全社区写的漏洞通告更口语化、更贴近实际业务表达。把两类描述混合起来中文表达能力和术语准确性都会有明显提升。除了漏洞本身MITRE ATTCK的战术、技术、子技术描述攻击模式库CAPEC弱点枚举库CWE这些都是高质量领域知识。特别建议把ATTCK的技术名称和描述做成结构化语料很多安全大模型回答“攻击者拿到权限后怎么横向移动”这类问题时如果训练数据里只有百科式列表没有具体攻击背景回答就会很空。这些知识库的表述虽然偏文档化但它们是理解“攻击链”的关键素材。实际操作上直接调用NVD的API逐个请求并不划算接口限流和断点续传都要自己处理。更高效的方式是定期下载全量JSON或增量JSON本地建一个轻量级数据库先存原始记录再按日期、漏洞类型、影响产品等维度生成训练样本。像NVD的CVE记录里references和weaknesses字段往往被忽略但这些字段描述攻击场景时很有价值建议清洗期不要急着删掉。2.2 开源威胁情报与样本报告补齐攻击上下文漏洞库解决的是“有什么漏洞、影响是什么”但模型要真正具备实战判断还依赖攻击工具使用案例、恶意样本分析报告和事件响应复盘。这类数据来源分散主要藏在安全厂商的公开研究报告、技术博客、GitHub仓库里的检测规则、恶意软件分析平台的样本描述以及各类安全论坛的讨论帖中。恶意样本库最好是拿报告文本而不直接拿样本二进制。真正有价值已结构化好的数据源包括MalwareBazaar等公开样本库中的样本标签与家族描述以及厂商发布的勒索软件分析报告、供应链事件复盘。这些文本会反复用到哈希值、互斥量、C2地址、YARA规则等专业字段清洗的时候必须保留这些实体它们恰好是后续生成检测规则任务需要的监督信号。GitHub上的检测规则仓库比如Sigma规则、YARA规则和Suricata规则是非常适合用于“规则生成”能力训练的天然对齐语料。它们本身就是高度结构化的规则文本配上规则所对应的攻击行为描述就可以做成指令样本。这种数据不需要太多几百条到几千条精选规则其实就够了重点是把规则语法与攻击现象关联起来。2.3 采集工程化先看授权再谈并发很多人一上手就想写多线程爬虫去抓网站但第一个要确认的不是并发量而是目标信息的授权范围。公网漏洞库API大多有清晰的请求条款GitHub上的仓库则遵循开源协议论坛和博客则要看robots协议和服务条款。数据获取阶段做一次版权和授权排查比模型上线后收到函要容易处理得多。完全公开的CVE描述和一些政府资助的知识库通常没有授权限制而商业报告、付费知识星球、部分技术社区的内容则需要非常谨慎。采集的执行层面有几个连续的动作可以复用。第一步是做URL层面的注册每个抓取的链接记录来源域名、页面标题、首次抓取时间和最终存储路径。第二步是抽取正文简单HTML解析不够很多页面有目录、页脚、相关推荐、评论我们当时先用readability算法抽正文再配合规则把代码块、表格按原样保留不容易丢专业信息。第三步是正文分块把长文章按标题切段每段单独保存保留标题上下文后续做微调样本时就不用再全文对齐。这里提醒一下很多安全博客站点的访问频率比普通站点敏感得多有些站点会因为访问异常直接封段IP。不要用猛火式并发建议单域名控制在每秒几个请求以内同时做好失败重试和请求失败日志记录。还有下载原始HTML文件保留一个备份副本而不是只存抽取出的正文因为清洗规则要调优时原始页面作为底稿可以在不重新抓取的情况下重新抽取。3. 数据清洗与脱敏把“脏数据”变成训练样本3.1 清洗的第一步不是分词而是字段抽离与结构化专业语料里最怕的是把文本里所有实体当成普通字符给模型带来噪音。比如恶意样本分析报告里常有“MD5: 2f4d...”如果这块内容被清洗成普通句子模型无法建立“MD5哈希”与“文件样本”的关系。我建议清洗前先跑一遍实体识别与标注规则把以下类别抽出来存成独立字段CVE编号、ATTCK编号、IP地址、域名、URL、SHA256/MD5哈希、端口号、漏洞类型、受影响版本、检测规则片段。抽离过程可以用正则先兜底再借助自有安全实体识别模型做二次补充。像IP地址、哈希值这种格式很强的字段正则就够了但“路径穿越”“命令注入”“反序列化”这类漏洞类型词需要建立同义词词表去归一化。比如“RCE”和“远程代码执行”是同一个意思统一成“远程代码执行”模型学出来的语义才不散。注意归一化词表要人工评审不能自动替换很多漏洞类型名称在不同语境下含义有细微差异。字段抽离后再对正文做通用清洗去掉页头和页脚、去乱码、统一全角半角、处理空格、分出标题、摘要和正文。对于代码块建议保留原始缩进因为像SQL注入语句和YARA规则这类内容格式化之后虽然看起来整齐但模型学到的是被改写的代码样式后续生成检测规则时会产生格式污染。3.2 脱敏不能只在发布前做要嵌入清洗流水线网络安全语料大量来自真实告警日志、流量抓包记录、事件复盘这些文本天然包含真实IP、员工账号、域名、文件路径和邮件地址。如果原样进入训练语料既存在数据泄露合规风险也会让模型记忆特定组织的内部资产信息上线后一旦被诱导可能把不该说的内部信息兜出来。我测试过一个简单但实用的脱敏流程。第一类是IP脱敏区分两种情况对于被标记为恶意IoC的IP通常在报告中需要保留到“可作为检测指标”的粒度但作为通用语料时建议把最后一段清零并添加随机扰动对于日志来源的内部IP直接全部抹掉并替换为内网保留地址段。第二类是域名和URL脱敏把可读的真实域名替换成“example.com”风格占位符同时保留域名结构和顶级后缀这样模型能学到URL形态但不会记忆真实域名。第三类是个人信息识别包括邮箱、电话、身份证号、社交账号用正则加模型组合识别并替换。脱敏一定要放在去重之前做还是去重之后做我自己倾向先脱敏再去重。如果先去重同一条日志的多个变体只是换成不同时间戳或IP可能因为内容高度相似被去重掉但实际上它们在训练中能起到增强模型泛化能力的作用。先做占位符统一再做相似度去重就能把真正重复的内容去掉把属于同一事件但细节不同的样本保留下来。3.3 版权、授权与来源留痕不是可有可无的元数据整理训练数据集时最常见的管理习惯是只存正文内容丢了来源链接、作者和授权说明。模型训练完如果遇到版权质疑想回溯每一段文本的具体出处会变成一件特别耗时的事。所以从一开始就要给每个文本样本建立来源元数据至少包含来源URL、标题、作者/机构、原文发布时间、采集时间、授权类型、清洗规则版本这些字段并随样本一起保存。不同来源的授权差异在训练实践中影响很大。比如某些商业安全报告虽然公开可读但明确写了禁止用于模型训练另一些开源项目使用了CC BY-SA协议这种协议允许使用但要求保留署名而且衍生内容也要以相同方式共享CC BY-NC则限制商业用途需要单独评估。在数据源接入时做一个简单的授权评估表把每个来源的许可证和评估结果列出来是很有必要的。4. 去重、质量评估与多任务配比4.1 用MinHash结合LSH完成近重复清洗网络安全文本的实际去重难度比通用语料高很多。同一漏洞的报道在多个平台出现时标题往往只差一两个词正文明明是复制粘贴但中间混入了一两句不同的评论用简单的hash去重完全拿它没办法。这时候要处理的是近重复文本需要计算Jaccard相似度但两两比较十万条文本的复杂度又不可接受。实战中更通用的方案是MinHash与局部敏感哈希联合使用把相似文本映射到同一个桶里再在桶内做细粒度配对。我自己在项目中用datasketch库处理了大概几十万条安全相关文档核心代码看起来是这样。from datasketch import MinHash, MinHashLSH def build_shingles(text, k10): text text.replace(\n, ).strip() if len(text) k: return {text} return {text[i:ik] for i in range(len(text) - k 1)} def text_to_minhash(text, num_perm128): m MinHash(num_permnum_perm) for shingle in build_shingles(text): m.update(shingle.encode(utf-8)) return m lsh MinHashLSH(threshold0.8, num_perm128) index {} for idx, text in enumerate(corpus): m text_to_minhash(text) lsh.insert(fdoc_{idx}, m) index[fdoc_{idx}] (m, text) duplicates set() for idx, text in enumerate(corpus): m text_to_minhash(text) candidates lsh.query(m) for cand in candidates: if cand fdoc_{idx}: continue if (idx, cand) in duplicates or (cand, idx) in duplicates: continue m2, cand_text index[cand] jaccard m.jaccard(m2) if jaccard 0.85: duplicates.add((idx, cand))shingle的k值直接影响结果。中文按字切分时k取8到12比较合适k太小会把不同主题的文本也判成相似k太大会漏掉部分改写。num_perm控制桶的精度128在中等规模数据上效果稳定数据量到千万级可以提高到256但内存和耗时也要成倍增加。还有这个例子只是为了说明流程真正处理时通常先把文本做长度归一化只有长度差异在20%以内的两篇文本才值得做相似度比较否则直接跳过能省下大量计算。4.2 质量过滤从硬规则到模型打分去重只是把重复样本干掉真正的低质量内容还要靠过滤规则和模型打分配合处理。我使用的硬规则包括文本长度过滤、语言类型过滤、敏感词过滤和结构完整度过滤。长度过滤这一项需要区分长文档和短样本做继续预训练的文档至少500字指令微调样本则可以是短问答只要问题与答案配对清晰就行。语言类型过滤对中英混合语料要特别小心不能直接用简单语言检测库处理因为安全文本里英文术语占比很高很多中文句子会被误判成英文。硬规则过滤之后还需要一个质量分数来排序和筛选。可以用一个轻量的二分类模型判断文本是否“像真正的安全技术内容”也可以直接用规则组合打分领域关键词密度高加分包含CVE编号或ATTCK编号加分正文与标题相关性强加分包含大量广告特性词减分文本连续重复程度高减分。这个打分可以作为后续采样概率的依据不用一刀切把低分样本删掉可以直接在采样时降低概率。4.3 数据配比与训练验证隔离是两条硬纪律网安场景中不同任务的数据量天然不均衡漏洞通告类语料量很大且句式相对统一而高质量的入侵检测告警标注数据却非常少可能只有几百条。把这两类数据按原始数量比例机械地丢进训练集模型会大概率过拟合大型类别小类别任务学不出来。整体配比应该在查看分布后人工干预比较稳妥的做法是先确定关键任务所需最低样本量再逐步把通用语料加进来做损失加权训练而不是一次混入全量数据。下面是我在类似任务上常用的起始配比参考具体数值肯定要按自己场景调。数据类别建议起始比例说明通用安全预训练语料60%-70%覆盖CVE库、博客、技术手册漏洞识别与信息抽取10%-15%结构化CVE记录、漏洞通告威胁分析与告警处置8%-10%安全分析报告、告警日志、事件复盘检测规则生成与修复建议5%-8%Sigma/YARA规则、补丁建议安全问答与指令任务5%-10%手工构造或从知识库生成的问答对训练集和验证集的隔离也有特别要求。网安数据时间波动大我强烈建议按原文发布时间切分而不是随机切分。如果随机切分一篇2024年日志的改写版本可能出现在训练集里2025年同一主题的漏洞通告则出现在测试集里这种跨时间泄漏会让模型评估虚高但实际部署到新漏洞上效果就崩。有一个经验是给评估集留足时间间隔比如训练集用2023年6月之前的数据测试集用2023年7月到12月的数据这样更能反映模型面对新出现内容的泛化真实水平。5. 常见问题排查与避坑清单5.1 采集端高频异常不是网站挂了是你的解析有问题做数据采集时最容易遇到的状况是文档下载到一半报错或者HTML解析出的正文全是JavaScript脚本。有些攻击情报站点本身就在前端做了内容混淆或多层过滤直接抓HTML根本拿不到有价值内容需要通过浏览器渲染或调用站点提供的公开API拿数据而不是硬啃反爬。遇到下载中断先看是不是网络代理不稳定再确认数据源是否做了分页限制。采集阶段的日志一定要记录响应状态码和错误原因只记录成功数量会让排查变得特别困难。文本编码问题在中文安全站里很常见。某些老站点页面是GBK编码没有用UTF-8解析就会变成乱码。采集时先根据HTTP响应头里的charset字段确定编码如果响应头缺失再用meta标签检测。入库前统一转成UTF-8并去掉BOM头。转码环节建议单独跑一遍不要等所有数据入库后再批量修复因为乱码文本往往无法恢复只能重新抓取。5.2 清洗阶段的误伤案例去重去掉了关键样例做去重时踩过一个挺典型的坑同一条CVE在不同报告里虽然正文相似度超过0.9但一个版本是漏洞分析另一个版本是应急响应处置流程两者侧重点完全不同。如果仅按相似度直接删掉一条会导致模型看不见同一漏洞在不同生命周期里的表达差异。后来我调整了策略两个样本相似度高于0.95才保留字段更完整的那条相似度在0.8到0.95之间标记为疑似重复不直接删除而是放到待人工抽检队列里或者同时做后续采样降权。另一个容易误伤的是涉及“攻击复现步骤”的案例。很多安全分析报告会把复现细节拆成多个条目或者分成多个步骤解释单看其中一段文本都不够完整整篇文档合并成一条样本才能保持语义完整。所以清洗时不要把一篇长文暴力切成完全不重叠的小段后再去重需要在切段时保留一定的上下文重叠比如每段带上上一段最后一句作为衔接这样模型读起来不会觉得信息突然断开。5.3 质量评估时如何发现“训练集泄漏”模型训练完先不要急着看数学指标可以抽几条新出现的真实漏洞描述丢给模型做漏洞识别看看效果。如果模型对训练集里的老漏洞类表现很好但一遇到最近半年的新威胁就完全答非所问八成是训练集和测试集之间有重叠或时间切分不干净。一个简单而有效的检查方式是拿测试集文本与训练集文本做一次Jaccard相似度抽检重点检查那些相似度大于0.8的样本往往会发现它们的来源URL都指向同一家资讯站点的同一篇科普文章。还有一个小细节值得留意很多数据源会在文章末尾带“相关阅读”或“往期回顾”推荐列表这些列表内容在采集时会被误当成正文导致全文正文与另一个页面的推荐标题出现意外的交叉重复。所以在清洗流程里增加一个“尾部推荐块识别”步骤可以明显减少这类脏重复。若没有做这个步骤去重的压力会成倍增长且大量算力都浪费在处理营销推荐文本上。5.4 数据版本管理不可省几百G数据也要能用一条命令回滚数据集的迭代一定需要版本管理这不是指把原始文件打一个tar包就完了而是要把原始下载包、清洗脚本、清洗参数、中间产物、最终样本集这四个层次全部关联起来。每次清洗脚本更新都记录改动内容与数据产物哈希值。这样当模型效果回归变差排障时第一时间就能确认训练用的到底是哪一批数据清洗规则是什么哪些样本在上一版中不存在。数据集的目录结构建议按数据源和任务类型分两层原始数据保留在raw目录人工标注放在annotated目录预处理后的样本放在processed目录。processed目录下的样本文件命名统一以“任务类型_来源_时间范围_版本号”格式记录能极大缓解多人协同时的混乱。整理数据集这件事不产生直接收益但它决定了后续模型训练和模型调优的效率值得专门花人力管理起来。最后分享一个经验判断数据获取与清洗阶段结束的标志不应该是“收集了多少GB”而应该是“抽检出来的样本内容准确率能稳定超过手写规则可以接受的范围”。当初每次紧急上线新爬虫数据源前至少要抽200条做人工复核专门看实体字段有没有被破坏、答案是否有上下文错位、是否含有明显敏感信息。复核不通过的数据源哪怕总量诱惑再大也会先放一放因为脏语料一旦进入基地模型后期清洗的成本远高于一开始放弃带来的损失。
和复杂脚本基础)
