1. 数据获取的定位与整体设计思路1.1 为什么数据获取是大模型训练里最要命的一道坎各位做安全的朋友聊到大模型训练很多人第一反应是“显卡够不够模型选多大训练框架用哪个”。真到自己动手训一个网络安全领域的大模型时才会发现前面这些都不是最疼的最疼的是手里没有数据。我见过好几个团队预算批了机器买了代码也跑通了结果卡在数据准备阶段整整一个月。原因很简单通用语料好找清洗好的安全领域语料奇缺。GitHub上开源的那些安全数据集要么是几年前的样本特征早就变了要么是研究机构为了论文做的实验数据规模小、格式乱、标签不一致压根达不到训练门槛。更尴尬的是安全领域本身就是一个高速对抗的领域攻击手法日新月异昨天的恶意样本今天可能已经变种数据时效性要求极高。所以这篇文章的核心就是把“网络安全大模型的数据从哪来、怎么处理、怎么判断质量”这件事拆开讲清楚。这一篇是实战系列的第十四篇假设你前面已经有了基本的模型训练基础知道什么是SFT、什么是LoRA、什么是数据配比那我们直接进入数据环节。1.2 先想清楚你的模型要做什么再谈数据获取网络安全不是一个单一任务场景它是多个细分方向的合集。搜索引擎、代码补全、告警研判、漏洞分析、日志语义理解、恶意流量分类、钓鱼邮件识别、合规检查辅助、威胁情报抽取这些都是“网络安全大模型”的落地场景但它们对数据的要求完全不一样。我在实际项目里看到最多的错误就是上来先搜了一堆CVE描述、漏洞文章、安全博客堆积几百万条文本然后扔给模型微调。训出来的模型问它“什么是SQL注入”能答得头头是道但让它分析一条真实攻击日志它根本不知道该看什么字段。为什么因为训练数据的分布和任务不匹配。所以在动手指去搞数据之前先回答三个问题这个模型服务谁是安全运营中心的研判分析师还是开发团队做代码安全检查还是给管理层做汇报解读模型要处理的输入是什么是短文本告警、长文档报告、代码片段、还是对话式的安全咨询输出形式是什么是分类标签、抽取的结构化字段、一段解释说明、还是可执行的修复建议这三个问题决定了你要采集的数据类型、数据规模、以及标注方式。我建议你的第一步不是“收集数据”而是“定义数据的Schema”也就是明确每一条数据长什么样输入字段是什么输出字段是什么必须经过怎样的标注。这个Schema会变成你后续所有数据清洗和标注工作的依据。2. 核心数据源解析网络安全大模型的数据从哪来2.1 公开安全语料好用但要会挑开源安全语料是数据基础盘主要包括几类技术博客与文档类。FreeBuf、安全客、Seebug Paper、奇安信威胁情报中心的报告、各厂商的安全通告这些都是中文安全语料的重要来源。英文方面PortSwigger Research、Mandiant、CrowdStrike博客、Project Zero的漏洞分析质量非常高适合训练模型对漏洞原理和安全机制的理解能力。这类语料的优势是自然语言质量高、上下文完整模型能从里面学到安全的思维方式和表达逻辑。CVE和漏洞库描述。NVD的CVE描述、CNVD的漏洞公告这类数据格式相对规整字段明确适合用来训练模型理解漏洞的成因、影响范围、严重程度以及修复方式。需要注意的是CVE描述的写法高度模板化单独用它训练模型会产生严重的“模板腔”一句话翻来覆去就是那几个句式。我一般建议CVE数据占比不要超过语料总量的10%。技术问答数据。Stack Overflow上安全相关的问题、知乎安全话题下的高质量回答、安全社区的技术讨论。这类数据最接近用户实际提问的表达方式对微调阶段很有用能让模型学会“像一个有经验的安全工程师那样回答问题”。Web攻击样本描述、恶意代码分析报告。这类数据比较稀缺很多在安全研究者的个人博客和会议论文里。整理时需要额外注意包含真实攻击代码和恶意样本描述的内容要谨慎处理避免训练出的模型被滥用。选公开语料时要记住一句话宁缺毋滥。网上一堆安全公众号的文章很多是抄来抄去的二手内容质量低、重复度高、甚至有错误。混进训练集里模型学到的不只是正确知识还有错误概念。我要求团队在采集阶段就做初筛低于500字的短文直接过滤同一来源重复超过三次的文章去重带明显营销推广性质的直接丢弃。2.2 内部数据最有价值也最难啃的骨头如果说公开语料解决的是模型的“通识”问题那内部数据解决的就是“专识”问题。真正的甲方安全团队、安全厂商、云平台安全部门手里握着做模型最宝贵的资源。一类是告警日志和研判记录。SIEM里的告警事件、SOC分析师的研判工单、最终确认的误报和真阳记录。这些数据是训练安全运营大模型的黄金数据因为它们包含了完整的输入原始告警源IP、目的IP、协议、端口、特征签名、发生时间和输出分析师结论是否恶意、攻击类型、建议动作。模型学会的是基于上下文判断的能力而不是背概念。另一类是漏洞报告和修复记录。安全团队内部跟踪的漏洞生命周期数据从发现、验证、定级、修复到复测的完整记录。这类数据的核心价值在于“过程”而不是“结论”。有经验的模型需要知道一个漏洞是怎么被一步步确认和修复的而不是只知道一个CVE编号。再有一类是项目文档和历史方案。等保测评报告、渗透测试报告、安全架构设计方案、应急响应总结。这些数据自然语言质量高逻辑严密很适合作为SFT阶段的训练语料或验证数据。但内部数据有个致命问题它们分散在不同的系统里格式千奇百怪很多还是PDF和扫描件甚至存在个人电脑的Word文档里。从业务系统导数据、做脱敏处理、格式转换、文本抽取这套流程通常要占到整个数据准备工作的一到两倍工作量。别急后面我会详细写怎么处理。2.3 指令微调数据的构造与增强基座模型完成预训练后真正让模型“听得懂人话、干得了活”的是指令微调阶段也就是SFT。这一阶段的数据不是从哪“获取”的而是构造出来的。构造SFT数据的第一种方式是把已有的语料转成“问题—答案”结构。比如从渗透测试报告里抽出来一段“我们发现目标系统的XX接口存在越权漏洞原因是后端未校验用户身份攻击者可调用XX接口获取他人数据建议在网关层增加鉴权中间件”把它转成一条指令数据“问什么是越权漏洞它是如何产生的答越权漏洞是指……”或者更任务化的指令“请分析以下渗透测试结论指出漏洞成因和修复建议[原文]”。第二种方式是模拟真实使用场景。这个非常考验功底。你得想象安全运营中心的分析师每天在干什么他收到一条告警需要判断这是不是误报他看到一个IP的行为异常需要决定要不要封禁他读完一篇漏洞分析需要在内部知识库里搜相关的历史处置经验。把这些场景写成指令模型学到的才是真实价值。第三种方式是数据增强。利用LLM本身的泛化能力把已有的数据改写扩写。比如拿1000条高质量的告警研判样本用GPT-4或其他商用模型改写保留核心逻辑变换表达句式、替换实体名称、调整时间描述生成一批语义等价但表述不同的数据。数据增强在文本量不够时很管用但要警惕一个坑增强出来的数据质量再高也是“二手数据”模型学到的分布会被改写模型的语言风格染色。所以增强数据的占比建议控制在SFT数据总量的30%以内而且要人工抽检。3. 实操过程从原始数据到可训练样本的完整流水线3.1 数据采集层四类数据源的抓取方案先把我常用的数据采集方案整体列一下后面逐步展开。第一类是网站页面和RSS订阅。用Python写爬虫针对FreeBuf、安全客这类博客站点做增量抓取。不建议自己从头造爬虫Scrapy框架加Feedparser就够用。需要注意robots协议和抓取频率我一般控制在单站点每秒不超过2个请求避免给目标站点造成压力。已发布的文章里包含完整正文最好如果只有摘要和链接就只保留摘要不要为了补全正文去硬闯登录墙。第二类是GitHub仓库。安全相关的技术文档、规则集、样本库很多都托管在GitHub上。比如各类IDS规则库、公开的恶意域名列表、CVE PoC集合、安全工具的使用文档。用GitHub的Search API按关键词检索仓库筛选star数和更新时间克隆到本地后抽文本。这里要注意版权和License只采集允许使用的数据。第三类是安全知识库和漏洞库。NVD的CVE数据提供完整的JSON数据包可以按时间增量下载。CNVD也有部分公开数据但字段不如NVD规整需要额外解析。国内一些安全公司的威胁情报中心会公开部分报告和数据接口字段质量高适合作为结构化数据的来源。第四类是内部系统导出。从SOC平台、工单系统、漏洞管理平台导出历史数据通常是Excel、CSV、JSON或者数据库Dump。这类数据的处理量最大也最容易出问题我单独在3.2节展开。采集完成后原始数据统一落入一个标准的文件系统目录按来源分类存放。我习惯用下面的结构raw_data/ ├── public_blogs/ # 公开博客 ├── cve_data/ # CVE/CNVD ├── github_repos/ # GitHub仓库 ├── internal_logs/ # 内部告警日志 ├── internal_vulns/ # 内部漏洞记录 ├── reports/ # 安全报告PDF/Word └── sft_samples/ # 人工构造的指令样本3.2 数据清洗与标准化Python脚本实战原始数据不可能直接拿来训练清洗是必须过的关。我直接说核心步骤和关键代码。文本抽取。PDF和Word文档是内部数据最头疼的来源之一。PDF用PyMuPDF库抽取文本先看抽取质量很多扫描件根本没文本层得接OCR。OCR我用的方案是PaddleOCR中英文效果都不错但速度慢、GPU占用高一般机器扛不住大规模跑需要分批处理。Word文档用python-docx抽文本还要注意表格内容很多安全报告的细节都藏在表格里抽取时不能丢。HTML清洗。博客类数据从网页抓下来是HTML结构要剥离标签、保留正文。BeautifulSoup可以完成基础的解析但还需要针对不同站点写不同的正文提取规则简单粗暴的取p标签内容会混入大量导航、页脚、推荐阅读之类的噪声。轻量级的方案是直接用trafilatura这个库它做了正文提取优化大部分博客都能准确提取大大节省时间。格式规整。清洗完的文本要统一成UTF-8纯文本去掉多余空行和不可见字符统一换行符。中文文本还需要处理全角半角混用的问题。这一步看似简单但遗漏了会直接影响后面的分词和模型输入质量。import re import unicodedata def clean_text(text: str) - str: # 标准化Unicode text unicodedata.normalize(NFKC, text) # 去控制字符 text re.sub(r[\x00-\x08\x0b\x0c\x0e-\x1f], , text) # 整理空白 text re.sub(r[ \t], , text) text re.sub(r\n{3,}, \n\n, text) # 去行首行尾空格 lines [line.strip() for line in text.splitlines()] return \n.join(lines)敏感信息处理。这是一个顾不上的大坑。安全数据里面天然带着IP地址、域名、邮件地址、姓名电话甚至还有内部服务器的完整路径和账号信息。这些敏感信息进入训练集轻则给模型“记住”了不该记住的内部信息重则有严重的合规风险。我的策略是所有IP地址脱敏成占位符邮箱地址脱敏成[EMAIL]姓名统一替换为[PERSON]。对于内部系统的主机名、路径、账号名统一替换成对应的角色描述。脱敏后再做一轮人工抽检重点看有没有漏网的。去重。安全的文本数据重复率比你预想的高得多。同一漏洞可能被三四个网站转载脱敏之后再去重效果才好。文本去重我用两步走第一步是全文MD5去重简单高效第二步是SimHash近似去重把重复率在95%以上的近似文章也去掉。SimHash加上汉明距离判断实测能在几百万条数据里高效找到近似重复。# SimHash去重思路 # 1. 对每篇文本分词计算词频权重 # 2. 对每个词哈希为64位指纹按位加权累加 # 3. 降维得到文本的64位SimHash值 # 4. 对SimHash值计算海明距离距离小于3视为重复3.3 安全领域数据的标注方案清洗完的数据还只是语料训练真正要的是“带标签的数据”。如果做的是基座模型的继续预训练清洗后的纯文本就够了但如果做的是指令微调每一行数据都需要“指令—输入—输出”的结构。这就涉及标注。安全数据标注的特殊性在于标注者必须懂安全否则根本分不清告警是真阳还是误报。我不建议外包给做通用文本标注的人来处理安全数据他们可以帮忙做语法纠错和格式整理但语义判断必须由内部安全工程师来完成。标签系统设计建议遵循两个原则一是扁平化不要搞多层级的复杂标签体系安全数据的标签尽可能扁平一个标签就是一个明确的类别避免交叉二是可解释每个标签都要有明确的定义和正例反例标注者在犹豫的时候能直接查表。我举一个实际的例子。告警研判数据标注表长这样字段示例说明alert_title检测到SQL注入攻击尝试告警标题alert_content源IP 192.168.1.23 在42秒内向目标发送了23条包含UNION SELECT的请求告警详情source_ip192.168.1.23已脱敏target_ip10.0.0.8已脱敏labeltrue_positivetrue_positive / false_positive / suspiciousattack_typeSQL_Injection攻击类型分类analysis_notes发送频率异常高UA字段包含自动化工具特征判定为自动化SQL注入扫描分析师的研判依据actionblockblock / monitor / ignore上面每一条标注过的记录都可以转成一条SFT样本输入是前五个字段的拼接文本输出是分析师的研判结论加上处置建议。这样训出来的模型才能在实际告警响应场景中真正帮上忙。标注采集完成的比例建议预训练语料里不需要标注继续预训练阶段可以有少量高质量标注真正需要人工投入的是SFT阶段建议数据量规模在5万到20万条之间这个量级是做的完的也足够覆盖绝大多数任务场景。3.4 从原始数据到训练文件的格式转换数据清洗、标注完成后最后一步是转成模型训练实际用的格式。预训练数据一般用纯文本文件或JSONL格式每行是一个文档。为了提升训练效率会预先做tokenization把文本切分成token序列并保存为二进制格式。不同训练框架处理方式不同比如Megatron-LM用mmap格式DeepSpeed用的是索引加bin文件。这一步建议直接用训练框架配套的数据预处理脚本不要自己造轮子。SFT数据主流格式是JSONL每条数据包含instruction、input、output三个字段。举个例子{instruction: 你是一名资深安全运营分析师请根据以下告警信息判断是否为真实攻击并给出处置建议。, input: 告警标题检测到SQL注入攻击尝试。源IP 192.168.1.23 在42秒内向目标发送了23条包含UNION SELECT的请求。目标为10.0.0.8的Web服务端口80。, output: 判定为真实攻击true positive。理由请求频率异常高包含大量UNION SELECT特征符合自动化SQL注入扫描行为。建议在防火墙层临时阻断源IP连接持续观察10分钟如果无后续告警则提升该内网IP的可信度基线。}注意格式里的几个关键点指令要清晰明确界定好角色和任务输入要提供给模型判断所需的全部上下文输出要有推理过程不只是给结论。只有结论没有推理过程的输出训练出来的模型问答会非常“干”用户问一句它答一句不会解释原因体验很差。这里还有一个容易被忽视的细节数据比例分配。SFT数据里不同任务类型的比例要精心设计。我常用的默认比例是告警研判30%、漏洞分析20%、安全知识问答20%、日志与恶意代码分析15%、报告解读与合规15%。如果你的实际业务场景偏重某一方面再动态调整。4. 数据质量控制训出好模型的关键一道工序4.1 质量评估指标体系数据不是越多越好这个观点我在不同场合反复强调。实测告诉我5万条高质量数据训练出来的模型效果可能比50万条粗糙数据训出来的好得多。所以数据质量评估不能靠感觉要建一套可量化的指标体系。完整性检查每个字段是否有值、是否为空。比如告警研判数据如果三分之一的数据没有analysis_notes那这批数据训练出来的模型只能给出结论给不出推理过程价值大打折扣。准确性抽样人工判断标注是否正确。我的做法是每批次数据标注完成后由经验更丰富的安全专家抽检10%计算标注一致率。一致率达到95%以上才放行进入训练集低于90%的批次退回重新标注。多样性检查数据覆盖了多少种攻击类型、多少种指令模板、多少种表达风格。多样性不足的典型表现是模型过拟合到某几种句式上遇到没见过的表达就完全不会处理。多样性评估可以用简单的方法把全部SFT数据的instruction文本做聚类看每个类簇的占比是否过于集中。时效性数据的时间分布。网络安全领域的攻防技术更新快三年前的攻击特征和现在有明显的差异。过旧的数据建议降低采样权重或者干脆剔除。一致性同一个知识点的不同数据之间是否存在相互矛盾。比如一条数据说“XX漏洞属于高危”另一条数据说“XX漏洞影响有限”模型会被这种矛盾弄糊涂。一致性检查用人工做不现实建议用LLM做交叉比对把所有数据发给一个商用大模型让它标记出互相矛盾的结论再由人工复核。4.2 毒性数据与偏见数据的排查网络安全这个领域本身充满对抗性内容——攻击代码、恶意样本、社工话术、漏洞利用细节。这些数据训练出来的模型如果缺乏安全对齐可能会被利用去生成有害内容。我的做法是分两步。第一步在数据清洗阶段就做规则过滤标题或正文里明确包含攻击工具下载、恶意样本分发、验证码绕过、支付漏洞利用等特征的数据直接剔除从源头上掐断风险。第二步是SFT数据构造完成后用安全分类模型做一遍“毒性检测”凡是标注为高风险的数据必须由人工复核后才能决定是否保留。注意完全剔除攻击类数据也不是最优解因为安全模型确实需要理解攻击原理才能做好防御这里面需要掌握一个度。偏见问题在安全领域同样存在。我遇到过的问题包括训练数据高度集中于某些厂商产品的漏洞导致模型对其他产品的判断明显偏差或者数据主要来自中国大陆的安全社区对全球其他区域的威胁情报和合规体系理解不足再比如数据处理中的语言分布不均衡中英文比例失衡导致模型在中英文安全术语的混用上表现混乱。4.3 人机协同的迭代反馈闭环数据质量不是一锤子买卖而是在训练过程中不断迭代。我的流程是这样第一轮训练用第一批数据跑一个小的实验模型然后让人工评估员拿真实场景去测模型。测试中发现模型在某个特定问题上回答得离谱追溯回去一定是数据的问题要么数据量不足要么数据质量差要么标注标准不一致。找到原因后修正数据集重新训练再次测试。这个闭环要跑好几轮每一轮数据量和数据质量都在提升。我实测下来第三轮迭代后的模型效果才基本能看第一轮、第二轮的问题都会比较多。所以做这个项目一定要有耐心不要指望一步到位。一个可以提效的方式是把人工评估员常问的问题记录下来分析模型的错误模式再反推需要补充什么类型的数据。比如发现模型经常把IDOR漏洞误判为水平越权那就是鉴别这两种漏洞类型的数据不足去补充这方向的数据比盲目增加数据总量效率高得多。5. 常见问题与排查技巧实录5.1 高频问题速查表问题表现原因排查思路模型回答带严重模板腔所有回答都是“根据XXX漏洞的特征该问题可能涉及……”CVE类模板化数据占比过高降低模板化数据配比增加技术博客、报告等自然语言数据模型对IP取整脱敏不彻底生成的回答里出现内部IP或域名清洗阶段脱敏规则漏了某些格式检查脱敏代码补充正则规则重建数据部分任务类型回答极差告警研判效果可以代码安全检查一塌糊涂SFT数据任务比例失衡检查SFT数据中各任务类别占比补充薄弱方向的样本模型重复同一句话长回答中出现大量重复内容数据重复率高SimHash去重没覆盖到加大近似去重阈值重新处理数据集中英文术语混乱中文回答里夹杂大段英文分析中英文语料混合比例不当分开检查中英文语料的比例必要时对训练数据做语言标记敏感信息泄露模型回答中出现了真实脱敏未覆盖的人员姓名内部流出数据存在遗漏全量扫描训练数据中的实体漏网数据剔除或重新脱敏5.2 排查思路与实操技巧定位数据问题的通用方法就四个字纵向追溯。也就是从模型输出反推数据。模型给了一个错误答案找训练集里跟这个问题最相关的3到5条数据一条一条看是哪里出了问题。这个方法比盲改代码高效得多。另外一个小技巧是每次训练前对数据做分布报告把数据总量、类别分布、平均长度、标签占比、时间跨度这些指标打印出来和上次训练的报告做对比。数据分布发生明显变化的批次往往是模型效果波动的根源。这个习惯养成了你排查问题会省很多力。还有个容易被忽略的问题是token长度截断。安全数据里大量存在超长文本特别是漏洞分析报告和应急响应报告动辄几千字。如果统一截断成512或1024个token模型会丢掉大量关键信息。我的做法是先把所有文本按长度分桶统计确定合理的截断长度再对不同长度的文本采取不同策略——短文档直接保留中等长度文档做滑窗采样超长文档用标题和摘要构建摘要版。bash # 统计训练数据长度分布 # 注意不要想当然地按平均长度来定截断阈值 # 重点看P95和P99分位数安全报告的长尾效应非常明显6. 数据获取的未来走向与扩展建议6.1 从静态数据集到动态知识注入现在做网络安全大模型绝大多数还是静态训练的方式数据采集、清洗、训练、发布。但网络安全领域有个特性——威胁情报更新极快。今天训完的模型可能下周就有新的攻击手法不在它的知识范围内。静态数据集训练的模型很快就会“过时”。一种可行的方向是让模型具备动态检索能力训练一个较小的基座模型再外挂一个知识库检索模块。模型遇到问题先从知识库中检索最新的威胁情报和安全公告再结合检索结果生成回答。这样模型的“知识”可以实时更新不需要频繁重训。这类方案的工程复杂度会上升但效果提升非常明显。6.2 高质量安全数据资产的建设思路很多安全团队常说“数据不够”但实际调研下来发现不是数据不够是散落的数据没有被有效整合。SOC里有告警记录渗透测试团队有报告存档漏洞管理平台有修复流程威胁情报平台有IOC数据但它们都是一个个孤岛。把这些孤岛打通就是一套高质量的安全数据资产。我的建议是成立一个数据治理小组明确数据Owner制定数据标准和脱敏规范建立定期的数据导出和更新机制。数据资产的建设不能靠一个人它是一个组织行为。这项工作启动得越早后面训练模型时就越从容。6.3 最后一点经验之谈网络安全大模型的数据获取表面上是技术问题实际上是一个工程管理问题。你需要平衡数据质量与规模需要协调不同团队之间的数据共享需要在合规和效率之间做取舍。这个环节做的扎实不扎实直接决定后续模型训练的成败。我个人的体会这个环节急不来但不能不做。前期多花一个月把数据底子打好后期模型调优能省出两个月。很多团队把数据准备工作压缩到极限省出来的时间最后都会在模型效果不佳、反复调试中加倍还回去。所以请把数据获取当作一个正经的项目来做配备人力、制定计划、设置里程碑——这是整个大模型实战项目中最值得认真对待的环节。