1. 写在前面数据决定一切攻防场景更是如此这一篇是整个大模型训练全流程实战系列的第十四篇。走到这里读者应该已经经历了从环境搭建、数据预处理、预训练、微调、对齐、评估到推理部署的全链路。前面那些环节里我们反复在讲“数据是模型的燃料”但对于网络安全大模型这个相对垂直的方向这句话的分量比其他任何领域都重。为什么这么说因为通用大模型的数据来源非常丰富网上到处都是文本语料哪怕质量参差不齐只要量级够大模型就能学到一定的语言能力和通识知识。但网络安全领域不一样高质量的中文语料本身就稀缺专业术语密集上下文强相关而且大量真正有价值的攻防经验、漏洞分析、应急响应案例往往散落在各个平台、博客、漏洞库甚至聊天记录里没有形成结构化、体系化的数据集。我在实际做这个项目的时候最直观的感受是数据获取花掉的时间占了整个项目周期的四成以上。而且这个环节完全绕不开直接决定后面所有环节能不能顺利推进。如果你正在计划训练一个网络安全方向的垂直大模型或者只是想把通用模型在安全场景下微调得更可用这篇文章能帮你省下大量“试错”的时间让你搞清楚到底去哪里找数据、怎么筛选数据、怎么清洗数据、怎么把数据整理成模型能直接“吃”的格式。需要先说明一点全篇内容只说数据获取和整理不涉及任何具体的攻击手法细节、漏洞利用实现或敏感的工具操作方式。我们只解决“喂给模型什么”的问题用的是公开合规的语料来源和正当的数据处理思路。这也是做安全领域AI应用必须守住的底线。2. 整体设计思路先想清楚要什么再动手去拿2.1 网络安全大模型的数据需求拆解在动手去网上扒数据之前你要先把“网络安全大模型”这个宽泛的概念拆开。不同用途的模型需要的数据类型完全不同。如果一上来就大而全地把各类数据混在一起训练出来的模型很容易变成一个“什么都懂一点、什么都不精”的缝合怪。按我自己的实践网络安全大模型的数据需求可以拆成四大类每一类对应不同的语料形态和获取渠道第一类是基础知识型语料包括网络协议原理、操作系统安全、加密算法、访问控制模型、安全合规标准比如等级保护、GDPR相关的解读、网络安全教材和公开课件等。这类数据的价值在于帮助模型建立基础的安全知识体系就像给一个新人做岗前培训。这类数据相对好找网络上有大量的公开课程、开源电子书、技术博客都可以用。第二类是威胁情报与漏洞信息型语料包括CVE漏洞描述、漏洞公告、攻击模式分类CAPEC、ATTCK技术库、威胁情报报告、安全厂商的应急响应通告等。这类数据时效性强、结构相对统一是安全模型最核心的“硬知识”。模型能不能准确说出某个漏洞的影响范围、修复建议主要取决于这一块的数据质量。第三类是攻防实战经验型语料包括渗透测试报告脱敏后的、红蓝对抗复盘、CTF比赛的WriteUp、安全社区的高质量技术分享、漏洞分析文章、恶意样本分析报告等。这类数据是最难获取的却是安全垂直模型区别于通用模型的真正壁垒。这类语料里有大量工程化的已知攻防模式、命令用法和排错思路能极大提升模型在具体问题上的可用性。第四类是安全场景对话与工单型语料包括安全运营中心的告警研判记录、安全咨询问答、安全产品的使用手册、客服话术等。如果你训练的是对话式安全助手这一类数据是微调阶段的重点它决定了模型的交互风格和回答问题的套路是否“对味”。把这四类数据列出来之后接下来的问题就变成了每个类型的数据去哪里找、怎么拿、怎么筛、怎么存。下面几个小节我一个个拆开讲。2.2 从通用学科能力到垂直领域能力数据获取的优先级策略在数据获取的过程中一定要想清楚一个投入产出比的问题通用数据要不要拿拿多少很多人第一次做垂直模型容易掉进“多多益善”的坑里什么数据都觉得有用结果数据池子变得又大又杂清洗成本极高训练收益却不明显。我的经验是分两条线走。第一条线是“底座数据”用公开的高质量中文语料比如维基百科、百科类站点、知乎精选、GitHub上的开源语料库来支撑模型的基础语言能力和通识知识。这条线不需要自己动手满世界爬现在有很多现成的开源语料集合可以直接下载比如各种中文预训练语料、通用指令微调数据集拿过来做初步清洗就能用。第二条线才是“垂直数据”也就是上面说的四类安全语料这一块必须自己动手积累因为开源的、成规模的中文安全语料库几乎没有基本要靠从不同渠道一点一点攒。我建议的安全数据获取优先级是漏洞信息与威胁情报 攻防实战经验 安全基础知识 对话工单数据。原因很简单漏洞和威胁情报这份数据决定模型的“硬实力”攻防实战经验决定模型的“真实战斗力”基础知识和对话数据决定模型的“交互体验”。如果时间紧前两类一定要优先保障因为它们才是让安全模型的输出明显区别于通用模型的核心所在。2.3 开源项目与公开平台的取舍逻辑关于数据获取渠道网上能搜到一堆“网络安全学习路线”“SRC漏洞平台汇总”之类的清单这些可以作为线索参考但实际做数据工程时不能照着清单一股脑全上。原因有几层一是很多平台的数据更新频繁但质量差异极大随手抓取会产生大量噪音反而拉低数据质量。比如论坛帖子里的闲聊、灌水内容对模型训练几乎没有正向帮助。二是部分平台有使用协议和版权声明直接抓取全部内容并用于模型训练存在合规风险。合规问题我在后面专门讲这里先提个醒。三是从工程效率来看日常有些SRC漏洞平台和挖洞社区更讲究时效性当日或当周的数据价值高但历史累积数据里重复报告多、描述质量参差不齐需要花大量精力筛选。所以在渠道选择上我建议把目标锁定在数据可靠、结构相对规整、更新相对稳定的来源上官方机构的安全公告、权威漏洞数据库可公开检索的部分、知名厂商的技术博客、大型安全社区的高质量版块。在这些地方下笨功夫远比撒网式采集要划算。3. 四类安全数据的获取方法与渠道详解3.1 漏洞信息与威胁情报数据怎么拿这是安全大模型的“硬通货”也是数据建设的重心。漏洞数据的特点是比较标准化基本围绕CVE编号、影响组件、影响版本、危害等级、攻击路径、修复建议这几个要素展开。正因为结构相对统一它非常利于做数据清洗和格式转换。先说漏洞数据源。可以直接获取结构化漏洞数据的地方包括开源漏洞库、厂商安全公告页、国家信息安全漏洞共享平台CNVD公开部分、CNNVD公开数据、GitHub上爬取的CVE描述数据集等。比如我们常听到的NVDNational Vulnerability Database就提供数据源下载每天同步一次能拿到包含CVE编号、描述、CVSS评分、漏洞类型、参考链接等字段的数据做数据获取时十分稳定。国内开源社区有人维护的CVE中文翻译数据、漏洞信息聚合项目也能作为补充。威胁情报类数据稍微复杂一些因为它不像CVE那样有统一编号数据形态包括安全厂商的威胁分析报告、各类APT组织的攻击活动披露、恶意域名与IP的威胁情报列表公开部分、ATTCK技术库的映射数据等。这一块的获取建议是盯住头部安全厂商的官方博客和研究团队的公开报告周期性下载并解析。比如很多厂商会发布月度或季度的威胁态势报告将这些报告汇总成数据集能够给这个模型补充比较完整的安全背景。实操过程中的关键是不要只把报告原文当成唯一形态要多想想怎么把这些文本进一步提取成模型更好学的形态。比如一份APT报告全文你可以保留正文作为预训练语料但如果你把其中的“攻击链描述”“使用的工具列表”“关联的ATTCK技术编号”单独抽出来整理成问答对这个数据集在微调阶段的价值就会明显高一个台阶。这一点我在后面的数据加工部分展开讲。3.2 攻防实战经验语料重点盯住这三个方向这一类的门槛和稀缺性都排在最前面真正做过攻防实战的人都能理解网上大量文章讲的是“我从入门到放弃”型的水文而不是能指导实战的操练型内容。做数据获取时要重点盯住三块阵地。第一块是专业安全社区的高质量频道。这里暂不指名道姓可以说的是这类社区普遍有长期累积的高质量技术文章涉及漏洞分析、内网渗透思路梳理、免杀技术演进、流量分析、日志审计等内容。获取方式是配合延迟策略、数据明细页爬取。由于这些社区本身开放可读抓取前先阅读robots协议和使用条款以低并发、慢速方式抓取并标注来源是稳妥的做法。第二块是CTF比赛与攻防演练的公开WriteUp。CTF题目覆盖Web、逆向、Pwn、Crypto、Misc等方向每个方向都沉淀了大量经典题型和解题思路。把公开WriteUp收集下来不仅能给模型补充大量技术细节还能让模型理解“遇到一个现象应该从哪里入手排查”的推理过程。这类语料对训练安全模型的分析推理能力很有帮助因为WriteUp天然自带“问题—思路—结论”的叙事结构能引导模型学习技术推理范式。第三块是安全工具的文档与使用手册。比如各类开源扫描器、抓包工具、漏洞利用框架、流量分析工具、日志分析工具的官方文档、参数说明、配置示例、常见错误解决方案等。整理成训练数据后模型面对“如何使用某个工具完成某个任务”这类问题时回答的可操作性会明显提高。工具文档属于容易被忽视但价值很稳定的语料因为文档内容结构化程度高、知识变化慢、可以长期复用。在实际项目中我建议优先按“工具名—功能—参数—示例”四个字段从这些文档中提取知识整理成结构化指令数据。3.3 安全基础知识与规范类数据这一块的获取难度不高难在“怎么整理出不误导人的知识点”。网络安全领域里很多知识是有上下文依赖的同一条命令在不同场景下的用途不同同一类攻击在云环境和传统机房里打法也不同。如果直接用网上的零散教程作为训练数据模型很容易把片面的说法当成普适结论导致以后生成错误建议。我建议基础知识类数据以可靠的体系化来源为主公开教材、大学课程课件、开源电子书、知名百科类站点的计算机安全词条、OWASP Top 10及各类安全标准文档。这类数据先作为预训练或者增量预训练语料用让模型在知识面上兜住底。同时要注意从这些文本中做好实体抽取和知识梳理把零散的知识点、流程步骤、检查项具象化成问答对作为微调时用。这里想特别提一下OWASP Top 10。虽然这个清单很多安全从业者都看过但真正把它做成结构化数据、让模型对每一项漏洞的“成因—场景—检测—修复—案例”形成完整知识链的项目里做得好的并不算多。如果你不想在这一块从零开始设计数据规格可以直接参照OWASP系列文档的章节结构来设计数据字段再结合其他权威标准做交叉验证。3.4 真实场景语料对话工单和安全运营数据如果你的目标产品是“安全运营助手”或“安全问答机器人”这样的对话形态那第四类语料就必须重视。这里包括但不限于安全运营中心积累的告警研判流程数据、安全设备告警日志和对应的处置结果、安全服务工单里的问答内容客户问什么、工程师怎么答、最后怎么解决、论坛里高票答案筛选后的技术问答。这类语料的价值在于它直接反映用户的真实提问习惯和从业者的语言组织方式能让模型的回答更贴近一线人员的实际需求。不过在获取这类数据时要格外注意隐私与合规。工单数据里往往含有客户系统信息、业务架构信息、甚至账号、IP、域名等敏感信息做数据获取时必须先做脱敏处理把可识别身份和具体业务的信息全部替换或删除。如果数据来自第三方来源务必确认你是否有权将这些数据用于模型训练。这一块我没有太多可让步的余地不合规的数据宁可不拿也不要硬塞进数据池。因为一旦数据出了问题整个模型都可能要推倒重来损失远大于当时省下的那点获取时间。4. 数据清洗与格式化的关键步骤4.1 原始数据到训练语料的“五步清洗法”数据获取回来之后不是直接扔给Tokenizer就能训练。原始数据又脏又乱直接使用会导致训练不稳定、模型胡言乱语的概率上升。我自己整理了一套五步走的清洗流程每一步都不复杂但合起来能显著提升数据质量。第一步是去重。同一篇技术文章可能被几十个网站互相转载如果不做去重模型训练时同一段文本反复出现会让模型对某些表达方式过度拟合同时也浪费算力。去重可以用文本相似度算法比如SimHash、MinHash也可以用更简单的办法对全文做MD5哈希先去掉完全重复的再用抽取关键词做指纹比对去掉近似重复的。对安全领域来说建议去重后再做一次“变体重合”检查因为很多文章只是改了标题、正文几乎一致。第二步是去噪。把网页里的导航栏、页脚、广告、推荐位、扫码关注提示、无意义字符、错误编码等去掉。这一步可以从正文提取工具或写正则规则配合处理核心原则是保留有价值的技术内容。比如一篇漏洞分析文章中读者留言区的讨论可能有价值但“谢谢分享”“学习了”这类回复必须过滤掉。第三步是信息抽取与字段化。把原始的段落文本转成结构化字段比如把一份CVE描述转为{编号, 影响组件, 影响版本, 漏洞类型, 危害等级, 修复建议}这样的字典结构。这一步是安全数据处理的特色环节通用文本不需要这么做但安全数据如果只保留原始文本模型的检索和推理效率会大打折扣。信息抽取可以通过规则模板与正则先做一个初版再用人工检查和修正不必一开始就上大模型提取成本太高。第四步是质量过滤。这里要定几个硬性规则完全与大模型无关的内容直接丢弃大量由符号、链接、乱码组成的文档直接过滤字数太少的片段、重复率过高的废话段落可以去掉涉及具体攻击利用细节描述但又没有完整的上下文技术说明的内容视情况降权或剔除。质量过滤很难有统一标准建议先抽样看一批数据再根据这些样本制定过滤规则然后迭代调整。第五步是标准化与编码处理。统一文本编码为UTF-8统一换行符统一标点风格中英文标点共存去除不可见字符和控制字符对特殊的安全符号比如IP地址、域名、哈希值做保留或脱敏处理。4.2 让数据更适配训练任务的三种格式经过清洗后的数据最终要转换成语料格式。我总结下来用三种格式基本能覆盖绝大多数的训练任务第一种是原始文本格式适合预训练阶段。就是纯文本每篇文档作为一条样本文档之间用特殊分隔符隔开。这种格式最简单让模型在大规模文本中学习语言规律和知识。安全类文档按“领域内优先级”排序后进入预训练池通用语料和垂直语料按比例混合。第二种是指令问答格式适合监督微调和指令微调阶段。每条数据由指令Instruction、输入Input、输出Output三部分组成。比如指令是“请分析这个告警事件的潜在风险”输入是一段脱敏后的告警日志输出是一段标准的研判分析结果。这种格式能直接教模型学会“接到任务—处理上下文—生成回答”的行为模式。建议在安全数据集中把问答对做得尽量贴近真实业务场景。第三种是对话多轮格式适合对话模型的继续训练。每条数据由多轮人机对话组成带上说话人标识。这种格式适合从真实工单和客服记录中整理把单轮的“一问一答”扩展为多轮的“追问—澄清—补答”能让模型学会在上下文不完整时主动追问信息而不是硬着头皮瞎猜。我建议这三类数据分开存储、分开管理互不混用因为训练的用途不同、处理时的侧重点也不同。混在一个文件里的做法后期排查数据问题时会十分痛苦。4.3 数据合规不能只挂在嘴边在这里要特意用一个完整小节来讲合规因为在安全领域做数据获取这是一个绝对绕不过去的问题。很多人觉得“网上能抓到的就是公共数据谁都能用”这个想法是大忌。具体的合规注意事项包括第一明确数据来源的版权和使用协议。有些技术博客明确标注“禁止转载”“未经许可不得用于商业用途”如果要把内容用于模型训练需要先去确认是否合规第二涉及个人信息和敏感业务数据的内容必须脱敏处理。网络安全领域的数据里常常夹杂着IP、账号、域名、哈希值等信息这些要按规则处理第三来自商业产品的数据比如某安全产品的告警、漏洞扫描报告要注意厂商授权第四如果你使用的数据和别人合作要明确数据的使用边界避免在训练过程中把数据泄露到不合适的环节。这些不是走过场。我见过一个项目因为用了未经授权的数据模型研发到一半收到来自原网站作者的投诉函最后只能把所有相关数据删掉重新建池。这种事不光毁项目的进度对团队的士气打击也很大。5. 半自动化数据管道怎么持续高效地积累数据5.1 搭一套最小可用的安全数据采集管道数据获取这件事如果全部靠手动下载、手动整理第一版数据集还没凑齐人已经先崩溃了。所以我建议从一开始就搭一套半自动化的数据采集管道哪怕简陋一点也能帮你省下大量时间。一个最小可用的管道大概包括四个部分采集端、解析端、存储端、质检端。采集端负责定时从你选定的数据源抓取更新内容。可以选择简单的定时脚本也可以做一个小型爬虫调度中心。安全领域的数据源更新频率不一漏洞库可能每天更新技术博客可能三五天更新一次社区帖子可能每小时都有新内容。采集频率要和源更新频率匹配避免对对方服务器造成过大压力。解析端负责把抓回来的HTML、PDF、JSON转成干净的文本。HTML解析常用BeautifulSoup或Requests-HTMLPDF解析可以用pdfplumber或PyMuPDFJSON直接按字段提取。解析端往往会遇到很多“脏页面”需要投入一定时间做页面解析模板建议只针对高频数据源做精细解析低频数据源可以甩给算法做通用提取不必追求完美。存储端负责把解析后的数据落库。我用过的方案里最基本的可以是一套按日期、按来源分目录的文件存储每个文件就是一个JSON或Markdown文档稍微正规一点可以用Elasticsearch或MongoDB方便后续检索和筛选。选择什么存储取决于你的数据规模和团队偏好但核心要求是每一条数据都要带上“来源URL、抓取时间、数据源名称”等元信息这会给后续的数据追溯和合规审计带来极大便利。质检端负责对数据做抽样检查。可以每天随机抽几十条新数据人工确认解析结果没有乱码、没有错位、格式符合设计。这个环节最容易被省略但省略后一旦解析模板因为网站改版出了问题你可能攒了一个月的坏数据还不知道到训练时才发现那就非常被动了。我建议至少在自动化管道跑通后的前两周内坚持每天人工抽检一次新入库数据。5.2 数据版本管理像管代码一样管数据数据积累到一定量级后版本管理就成了刚需。你会发现训练完一版模型后数据池又更新了不少但你没法说清楚新数据池和旧数据池改了哪些文件于是对比实验就成了一场糊涂账。我的做法是为一个数据池建立类似Git的管理习惯。不一定要真的用Git当然Git LFS或DVC也行但必须有“快照”的概念。每当你准备启动一轮新的训练就为当前的数据集打一个版本快照记录数据总量、各类别占比、新增数据时间范围、清洗规则的版本号。等模型训练结束后把模型效果和这个数据版本绑定。下一条数据版本上线时就能清楚地对比“数据增量的变化导致模型效果是上升还是下降”。这里也想提一个容易被忽略的点随着网络环境的演进安全语料中的知识也在不断变化。三年前的漏洞分析和威胁情报在今天看可能已经过时或者被新的攻击方式替代。所以数据版本管理还要配套一份“数据时效性清单”明确哪些数据源可以长期保留、哪些按季度清理、哪些在模型迭代时必须重新获取。对安全大模型来说数据不是越多越久越好而是越新、越准越好。5.3 开源工具和框架怎么选关于“有哪些开源的大模型训练平台”这个问题经常有小伙伴来问。这个问题本身很大但在数据获取与预处理这个环节真正要用到的开源工具没那么复杂我按流程列一下实际验证过、比较顺手的工具组合数据采集方面常用的还是Python生态的Requests、Scrapy、Playwright。Requests适合简单页面Scrapy适合需要分布式采集的站点Playwright适合需要执行JavaScript的动态页面。安全社区里面动态加载的页面很多所以Playwright或Selenium在采集端的使用频率不低。HTML清洗方向BeautifulSoup和lxml是主力文本内容更复杂的场景可以用Readability对正文抽取有效或Trafilatura一个专门做正文抽取的Python库实测下来对多类网页的正文提取效果不错。文档解析方面PDF类用pdfplumber或PyMuPDFDOCX用python-docxPPT用python-pptx这些都属于很成熟的库。数据去重与清洗在数据量不大时直接用Pandas处理表格、正则处理文本就够了。数据量大到几十GB甚至上百GB时可以考虑引入Spark或Dask做分布式处理但对安全领域这种体量来说优先级并不高。很多时候单机多进程方式跑完一轮清洗也就是几个小时的事。数据存储与检索可以用Elasticsearch做全文检索也可以只用传统的文件目录和SQLite。如果只是自用SQLite的轻量优势很明显如果团队协作Elasticsearch的检索能力和权限管理体验更好。两者不冲突可以先用文件存原始结构再导一份到ES供检索。需要提醒的事实是工具链只是辅助真正决定数据质量的是你制定的清洗规则和信息抽取模板。工具可以换规则必须沉淀好。6. 实操过程与核心环节实现6.1 一个完整的漏洞数据采集示例空谈分类和思路总觉得太虚我拿一个具体案例来演示整个数据获取链路怎么走通。这里以“采集并整理CVE漏洞数据”为例整个过程从零开始一步步说清楚。第一步先找到数据源。NVD提供的JSON数据包支持全量下载和增量更新这是很理想的漏洞数据源。在国内访问可能有延迟的情况可以找镜像或者用其他的开源漏洞库接口。这里我们不针任何具体数据源做广告只谈通用思路。第二步写一个定时采集脚本。用Python的requests请求数据接口把返回的JSON保存到本地。为了避免给服务器造成压力每次请求加一个合理的时间间隔设置请求头伪装成正常浏览器。一个简化版的代码如下import requests import json import time from datetime import datetime # 示例从漏洞数据接口获取最近7天的漏洞信息保存为json文件 def fetch_vuln_data(days7): headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } url https://example-vuln-api.org/api/vulns params { days: days, format: json } try: resp requests.get(url, headersheaders, paramsparams, timeout30) resp.raise_for_status() data resp.json() except Exception as e: print(获取失败, 重试机制需补充: , e) return None today datetime.now().strftime(%Y%m%d) filename fvuln_data_{today}.json with open(filename, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f数据已保存: {filename}, 共{len(data)}条) return data if __name__ __main__: fetch_vuln_data(days7)第三步解析和结构化。拿到了原始JSON里面可能包含编号、描述、评分、参考链接、影响产品等多个字段。在清洗时把这些字段抽出来去掉不需要的字段再做统一格式。如果描述字段是英文还需要用自动翻译或者人工校对的方式转成中文或中英对照。这里要注意的是自动翻译的结果会有一定错误率不能全信对安全术语尤其要关注比如“privilege escalation”不能简单直译成“特权升级”很多语境下更准确的表达是“提权”。术语的统一是安全语料清洗中必须投入精力做好的细节。第四步补全上下文。只有漏洞编号、描述、评分的原始数据对模型训练来说还是太单薄了。建议把漏洞和对应的修复方案、受影响的版本范围、相关漏洞利用代码的分析报告如果有且合规关联起来形成更完整的知识单元。这一步可以通过规则把CVE编号和已采集的技术博客文章做关联匹配把相关文章全文作为补充上下文与漏洞数据拼接在一起。这样模型学习到的知识就不是“某个漏洞打了7.5分”这种孤立信息而是“漏洞基本信息—影响范围—检测方式—修复方案—实际案例”这样的完整链条。6.2 技术博客与社区文章解析的实战记录第二个具体场景是采集技术博客和社区文章。相比漏洞库的结构化数据这一类的处理难度高一些但价值密度也高一些。我的常规做法是首先梳理出了一份“安全技术源清单”里面把与目标方向强相关的技术博客、社区版块、公众号文章链接全部整理进去。发布频率高的源用定时任务每天拉取发布频率低的源每周拉取一次。考虑到部分站点开启了防爬我常用Playwright模拟浏览器访问等页面渲染完成后提取正文再结合Readability或Trafilatura做正文抽取去掉导航栏、评论区噪音、相关推荐等模块。下面是简化一点的示例逻辑from playwright.sync_api import sync_playwright from trafilatura import extract, fetch_url def fetch_article_content(url): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(url, timeout60000) # 等待关键内容加载出来避免动态渲染未完成 page.wait_for_selector(article, timeout30000) html_content page.content() browser.close() text extract(html_content) return text if __name__ __main__: article_url https://example.com/blog/security-analysis-2024 content fetch_article_content(article_url) print(content[:500])这段代码的思路是先用Playwright渲染出完整HTML再用Trafilatura把正文捞出来。实际使用中不同站点的页面结构差异很大可能遇到“选择器找不到文章标签”“页面弹窗拦截”“滚动加载导致内容没取全”等问题。这种一个个站点适配的工作很琐碎但属于数据获取逃不开的体力活。文章正文拿到手之后只做成纯文本入库又太浪费了。我建议后面再加一道“信息抽取”工序用规则或者小模型去抽取标题、发布日期、作者、标签、涉及的漏洞编号、涉及的组件名称等技术要素。比如一篇标题为“某框架反序列化漏洞分析”的文章可以抽取出“框架名”“漏洞类型”“受影响的版本范围”“利用条件”“修复方式”等结构化字段连同正文一起入库。这样将来在构建微调语料时就可以直接用这些字段做筛选和重组产生出知识密度更高的问答对。6.3 语料平衡怎么做防止模型“偏科”数据获取做到后期一定会遇到一个典型问题采集回来的语料分布严重不均。比如漏洞数据占了一大半攻防实战案例分析只有零星几篇或者Web方向的内容特别多二进制安全方向的内容几乎没有。这种不平衡会让模型出现明显的“偏科”现象说不定它聊Web攻击头头是道问它内核提权相关内容就含糊不清。解决这个问题的核心思路是“分层目标和样本量控制”。在开始数据建设时就为目标模型定一个活列出12到15个核心子方向比如漏洞研究、渗透测试、恶意软件分析、日志分析、安全合规、应急响应等。每一个子方向都设定一个目标样本量的下限和上限下限保证最基本的知识覆盖上限防止单一方向过多挤占其他方向的空间。采集回来的数据按子方向打标签统计每个方向的样本量超出上限的做降采样不足下限的做补充采集。这是有时间成本的却是保证垂直模型均衡性的关键一步。Beta版本我做数据池时没有注意这一点结果模型往一个方向严重倾斜。后来重新整理数据时花了大量时间做类别标注和重新平衡。所以这个“未雨绸缪”的建议含金量很高。7. 常见问题与排查技巧实录7.1 数据源访问失败与页面反爬应对做数据获取一定会遇到访问失败的问题常见原因包括网站的访问频率限制、特定UA被拦截、需要登录或验证码、页面结构变化等。应对频率限制最有效的办法就是控制请求频率在两次请求之间加随机延时避免以固定间隔每秒发请求。加固延时还不够的站点可以用代理池配合轮换但使用代理时要注意合规和成本。遇到需要JavaScript渲染才能看到内容的页面用Playwright或Selenium把渲染这一步模拟掉。遇到的问题再多一些站点启用了比较严格的风控频繁切换IP可能会被临时封禁这时候不要硬刚把采集频率再降一个量级或者改在对方访问低峰期再跑。数据获取本质上是个细水长流的过程没必要为了快一两天把自己IP封了反而更耽误事。页面结构变化也是会频繁遇到的坑。安全社区和其他网站一样会不定期改版解析模板经常会突然失效。解决的策略一是解析模板做配置化不要写死在代码里这样前台调整结构时可以快速在前面改配置恢复二是给数据管道加“异常检测”当某一天某个数据源的解析成功率为0时立即发报警不要等到次日才发现入库数据为零。7.2 数据质量参差不齐怎么把噪音控制在合理范围数据抓回来以后噪音是难免的。有些网页正文里有大量宣传语、跳转链接、无关推荐有些文章是AI批量生产的伪原创内容知识密度几乎为零。建议在入库之前做一次“可读性打分”用文本长度、段落长度、标点分布、专业术语密度等指标给每篇文档打一个基础分低于阈值的直接丢弃。安全数据有一个特殊关注点直接用规则或分类器过滤明显低质的“营销文”。网络安全领域存在大量以卖课、卖工具、引流为目的的软文它们标题很吸引人但内容浅薄、充满广告信息。这类内容如果不加过滤模型会学出一堆“只要提到安全就推荐培训班”的不良倾向。这个过滤规则可以做成关键词黑名单加分类模型的双重机制虽然做不到完全零漏网但能把比例控制在合理范围内。另一个容易被忽视的噪音来源是“翻译腔”和“机翻文”。很多海外安全文章被机翻成中文后术语混乱、语句不通顺放进语料里会拉低模型的语言质量。筛选时建议对这类内容做“术语一致性检查”对高频安全术语列表做一次匹配如果一篇文章里“注入”一会儿被翻译成“注入”一会儿被翻译成“射入”说明机翻质量不高可以直接降权或过滤。7.3 数据量不足怎么办从“找数据”转向“造数据”很多团队做垂直模型时最容易遇到的尴尬问题是数据源的公开语料就那么多挖来挖去就那么些达不到理想的数据量级。这时候有两个方向可以参考。第一个方向是把横向来源扩大把单模态变多模态。比如旧的中文安全论坛内容、安全工具官方文档、开源项目的告示文档、行业峰会公开的演讲PDF、甚至安全类开源书籍内容这些都可以纳入语料。此前只从博客和漏洞库取的思路可以扩大到邮件列表归档如开源安全社区的邮件列表、GitHub仓库里的安全相关README和Wiki页面等。第二个方向是用“数据增强”造一部分高质量数据。近一两年的主流做法是用通用大模型把已有的高质量语料重写、扩写成多种形式的知识点。比如把一篇漏洞分析文章喂给通用大模型让它生成几个不同角度的问答对或者让它把给定内容改写成“初级/中级/高级”三个难度层级的知识讲解。这种方式能显著扩充监督微调阶段的数据量但要注意引入的数据要经过人工抽检或规则校验防止大模型添油加醋带来错误知识。这两个方向可以叠加使用。先扩大来源的量再用数据增强扩大指令数据的多样性。但如果时间有限我的建议是优先保证质量宁可数据量少、覆盖核心子方向也不要盲目拼凑大量低质语料。7.4 数据质量检查清单最后把数据获取阶段容易踩的坑集中整理成一张速查清单。每一轮数据池构建完成后按这份清单过一遍可以省去后续很多麻烦。检查项检查方法通过标准重复率对入库文本计算哈希相似度完全重复率3%近似重复率10%编码一致性全量扫描文本编码与特殊字符统一UTF-8无乱码和特殊控制符号来源标签完整性检查每一条数据是否有来源URL和抓取时间100%具备合规性根据来源协议与内容脱敏要求抽查无未获授权的高风险内容类别均衡度统计各子方向样本量占比核心子方向占比不低于5%不超过30%时效性检查最近更新的数据是否在7天内入库新一轮增量训练时可访问到最新的灾难威胁数据文档长度检查清洗后文档的篇幅分布极短200字和极长50000字文档需人工确认专业术语准确性抽取高频安全术语人眼复核无大面积术语错译、乱译情况这个清单不用做得很重但一定要坚持执行。数据获取环节的问题越早发现修复成本越低。等到模型训完再发现数据有问题就得整个流程重新来时间和算力的浪费都非常可惜。8. 收尾做了这么多轮数据获取与整理工作我个人的体会有两点。一是网络安全大模型的数据建设本质上不是一次性工程而是持续运营的资产积累。数据源会变化、知识会更新、业务需求会调整所以“管道”比“存量”更重要。把时间和精力花在数据管道的稳定性和可维护性上可以在未来每一个新模型版本上线时获得持续的回报。二是给自己的工作留好余量。数据获取涉及的版权、隐私、克制使用问题在项目初期就要想清楚。与其在数据出现纠纷时焦头烂额不如在每一次数据入库之前多问一句“这个数据来源我有没有权限使用”。在合规这件事上慢一点反而更快。这一篇讲到这里关于数据获取和整理的思路基本已经说完。下一篇文章里我计划结合前面搭好的数据池聊聊网络安全大模型训练时的超参调整与调优策略欢迎感兴趣的朋友继续关注。 网络安全大模型数据获取与清洗实战指南
1. 写在前面数据决定一切攻防场景更是如此这一篇是整个大模型训练全流程实战系列的第十四篇。走到这里读者应该已经经历了从环境搭建、数据预处理、预训练、微调、对齐、评估到推理部署的全链路。前面那些环节里我们反复在讲“数据是模型的燃料”但对于网络安全大模型这个相对垂直的方向这句话的分量比其他任何领域都重。为什么这么说因为通用大模型的数据来源非常丰富网上到处都是文本语料哪怕质量参差不齐只要量级够大模型就能学到一定的语言能力和通识知识。但网络安全领域不一样高质量的中文语料本身就稀缺专业术语密集上下文强相关而且大量真正有价值的攻防经验、漏洞分析、应急响应案例往往散落在各个平台、博客、漏洞库甚至聊天记录里没有形成结构化、体系化的数据集。我在实际做这个项目的时候最直观的感受是数据获取花掉的时间占了整个项目周期的四成以上。而且这个环节完全绕不开直接决定后面所有环节能不能顺利推进。如果你正在计划训练一个网络安全方向的垂直大模型或者只是想把通用模型在安全场景下微调得更可用这篇文章能帮你省下大量“试错”的时间让你搞清楚到底去哪里找数据、怎么筛选数据、怎么清洗数据、怎么把数据整理成模型能直接“吃”的格式。需要先说明一点全篇内容只说数据获取和整理不涉及任何具体的攻击手法细节、漏洞利用实现或敏感的工具操作方式。我们只解决“喂给模型什么”的问题用的是公开合规的语料来源和正当的数据处理思路。这也是做安全领域AI应用必须守住的底线。2. 整体设计思路先想清楚要什么再动手去拿2.1 网络安全大模型的数据需求拆解在动手去网上扒数据之前你要先把“网络安全大模型”这个宽泛的概念拆开。不同用途的模型需要的数据类型完全不同。如果一上来就大而全地把各类数据混在一起训练出来的模型很容易变成一个“什么都懂一点、什么都不精”的缝合怪。按我自己的实践网络安全大模型的数据需求可以拆成四大类每一类对应不同的语料形态和获取渠道第一类是基础知识型语料包括网络协议原理、操作系统安全、加密算法、访问控制模型、安全合规标准比如等级保护、GDPR相关的解读、网络安全教材和公开课件等。这类数据的价值在于帮助模型建立基础的安全知识体系就像给一个新人做岗前培训。这类数据相对好找网络上有大量的公开课程、开源电子书、技术博客都可以用。第二类是威胁情报与漏洞信息型语料包括CVE漏洞描述、漏洞公告、攻击模式分类CAPEC、ATTCK技术库、威胁情报报告、安全厂商的应急响应通告等。这类数据时效性强、结构相对统一是安全模型最核心的“硬知识”。模型能不能准确说出某个漏洞的影响范围、修复建议主要取决于这一块的数据质量。第三类是攻防实战经验型语料包括渗透测试报告脱敏后的、红蓝对抗复盘、CTF比赛的WriteUp、安全社区的高质量技术分享、漏洞分析文章、恶意样本分析报告等。这类数据是最难获取的却是安全垂直模型区别于通用模型的真正壁垒。这类语料里有大量工程化的已知攻防模式、命令用法和排错思路能极大提升模型在具体问题上的可用性。第四类是安全场景对话与工单型语料包括安全运营中心的告警研判记录、安全咨询问答、安全产品的使用手册、客服话术等。如果你训练的是对话式安全助手这一类数据是微调阶段的重点它决定了模型的交互风格和回答问题的套路是否“对味”。把这四类数据列出来之后接下来的问题就变成了每个类型的数据去哪里找、怎么拿、怎么筛、怎么存。下面几个小节我一个个拆开讲。2.2 从通用学科能力到垂直领域能力数据获取的优先级策略在数据获取的过程中一定要想清楚一个投入产出比的问题通用数据要不要拿拿多少很多人第一次做垂直模型容易掉进“多多益善”的坑里什么数据都觉得有用结果数据池子变得又大又杂清洗成本极高训练收益却不明显。我的经验是分两条线走。第一条线是“底座数据”用公开的高质量中文语料比如维基百科、百科类站点、知乎精选、GitHub上的开源语料库来支撑模型的基础语言能力和通识知识。这条线不需要自己动手满世界爬现在有很多现成的开源语料集合可以直接下载比如各种中文预训练语料、通用指令微调数据集拿过来做初步清洗就能用。第二条线才是“垂直数据”也就是上面说的四类安全语料这一块必须自己动手积累因为开源的、成规模的中文安全语料库几乎没有基本要靠从不同渠道一点一点攒。我建议的安全数据获取优先级是漏洞信息与威胁情报 攻防实战经验 安全基础知识 对话工单数据。原因很简单漏洞和威胁情报这份数据决定模型的“硬实力”攻防实战经验决定模型的“真实战斗力”基础知识和对话数据决定模型的“交互体验”。如果时间紧前两类一定要优先保障因为它们才是让安全模型的输出明显区别于通用模型的核心所在。2.3 开源项目与公开平台的取舍逻辑关于数据获取渠道网上能搜到一堆“网络安全学习路线”“SRC漏洞平台汇总”之类的清单这些可以作为线索参考但实际做数据工程时不能照着清单一股脑全上。原因有几层一是很多平台的数据更新频繁但质量差异极大随手抓取会产生大量噪音反而拉低数据质量。比如论坛帖子里的闲聊、灌水内容对模型训练几乎没有正向帮助。二是部分平台有使用协议和版权声明直接抓取全部内容并用于模型训练存在合规风险。合规问题我在后面专门讲这里先提个醒。三是从工程效率来看日常有些SRC漏洞平台和挖洞社区更讲究时效性当日或当周的数据价值高但历史累积数据里重复报告多、描述质量参差不齐需要花大量精力筛选。所以在渠道选择上我建议把目标锁定在数据可靠、结构相对规整、更新相对稳定的来源上官方机构的安全公告、权威漏洞数据库可公开检索的部分、知名厂商的技术博客、大型安全社区的高质量版块。在这些地方下笨功夫远比撒网式采集要划算。3. 四类安全数据的获取方法与渠道详解3.1 漏洞信息与威胁情报数据怎么拿这是安全大模型的“硬通货”也是数据建设的重心。漏洞数据的特点是比较标准化基本围绕CVE编号、影响组件、影响版本、危害等级、攻击路径、修复建议这几个要素展开。正因为结构相对统一它非常利于做数据清洗和格式转换。先说漏洞数据源。可以直接获取结构化漏洞数据的地方包括开源漏洞库、厂商安全公告页、国家信息安全漏洞共享平台CNVD公开部分、CNNVD公开数据、GitHub上爬取的CVE描述数据集等。比如我们常听到的NVDNational Vulnerability Database就提供数据源下载每天同步一次能拿到包含CVE编号、描述、CVSS评分、漏洞类型、参考链接等字段的数据做数据获取时十分稳定。国内开源社区有人维护的CVE中文翻译数据、漏洞信息聚合项目也能作为补充。威胁情报类数据稍微复杂一些因为它不像CVE那样有统一编号数据形态包括安全厂商的威胁分析报告、各类APT组织的攻击活动披露、恶意域名与IP的威胁情报列表公开部分、ATTCK技术库的映射数据等。这一块的获取建议是盯住头部安全厂商的官方博客和研究团队的公开报告周期性下载并解析。比如很多厂商会发布月度或季度的威胁态势报告将这些报告汇总成数据集能够给这个模型补充比较完整的安全背景。实操过程中的关键是不要只把报告原文当成唯一形态要多想想怎么把这些文本进一步提取成模型更好学的形态。比如一份APT报告全文你可以保留正文作为预训练语料但如果你把其中的“攻击链描述”“使用的工具列表”“关联的ATTCK技术编号”单独抽出来整理成问答对这个数据集在微调阶段的价值就会明显高一个台阶。这一点我在后面的数据加工部分展开讲。3.2 攻防实战经验语料重点盯住这三个方向这一类的门槛和稀缺性都排在最前面真正做过攻防实战的人都能理解网上大量文章讲的是“我从入门到放弃”型的水文而不是能指导实战的操练型内容。做数据获取时要重点盯住三块阵地。第一块是专业安全社区的高质量频道。这里暂不指名道姓可以说的是这类社区普遍有长期累积的高质量技术文章涉及漏洞分析、内网渗透思路梳理、免杀技术演进、流量分析、日志审计等内容。获取方式是配合延迟策略、数据明细页爬取。由于这些社区本身开放可读抓取前先阅读robots协议和使用条款以低并发、慢速方式抓取并标注来源是稳妥的做法。第二块是CTF比赛与攻防演练的公开WriteUp。CTF题目覆盖Web、逆向、Pwn、Crypto、Misc等方向每个方向都沉淀了大量经典题型和解题思路。把公开WriteUp收集下来不仅能给模型补充大量技术细节还能让模型理解“遇到一个现象应该从哪里入手排查”的推理过程。这类语料对训练安全模型的分析推理能力很有帮助因为WriteUp天然自带“问题—思路—结论”的叙事结构能引导模型学习技术推理范式。第三块是安全工具的文档与使用手册。比如各类开源扫描器、抓包工具、漏洞利用框架、流量分析工具、日志分析工具的官方文档、参数说明、配置示例、常见错误解决方案等。整理成训练数据后模型面对“如何使用某个工具完成某个任务”这类问题时回答的可操作性会明显提高。工具文档属于容易被忽视但价值很稳定的语料因为文档内容结构化程度高、知识变化慢、可以长期复用。在实际项目中我建议优先按“工具名—功能—参数—示例”四个字段从这些文档中提取知识整理成结构化指令数据。3.3 安全基础知识与规范类数据这一块的获取难度不高难在“怎么整理出不误导人的知识点”。网络安全领域里很多知识是有上下文依赖的同一条命令在不同场景下的用途不同同一类攻击在云环境和传统机房里打法也不同。如果直接用网上的零散教程作为训练数据模型很容易把片面的说法当成普适结论导致以后生成错误建议。我建议基础知识类数据以可靠的体系化来源为主公开教材、大学课程课件、开源电子书、知名百科类站点的计算机安全词条、OWASP Top 10及各类安全标准文档。这类数据先作为预训练或者增量预训练语料用让模型在知识面上兜住底。同时要注意从这些文本中做好实体抽取和知识梳理把零散的知识点、流程步骤、检查项具象化成问答对作为微调时用。这里想特别提一下OWASP Top 10。虽然这个清单很多安全从业者都看过但真正把它做成结构化数据、让模型对每一项漏洞的“成因—场景—检测—修复—案例”形成完整知识链的项目里做得好的并不算多。如果你不想在这一块从零开始设计数据规格可以直接参照OWASP系列文档的章节结构来设计数据字段再结合其他权威标准做交叉验证。3.4 真实场景语料对话工单和安全运营数据如果你的目标产品是“安全运营助手”或“安全问答机器人”这样的对话形态那第四类语料就必须重视。这里包括但不限于安全运营中心积累的告警研判流程数据、安全设备告警日志和对应的处置结果、安全服务工单里的问答内容客户问什么、工程师怎么答、最后怎么解决、论坛里高票答案筛选后的技术问答。这类语料的价值在于它直接反映用户的真实提问习惯和从业者的语言组织方式能让模型的回答更贴近一线人员的实际需求。不过在获取这类数据时要格外注意隐私与合规。工单数据里往往含有客户系统信息、业务架构信息、甚至账号、IP、域名等敏感信息做数据获取时必须先做脱敏处理把可识别身份和具体业务的信息全部替换或删除。如果数据来自第三方来源务必确认你是否有权将这些数据用于模型训练。这一块我没有太多可让步的余地不合规的数据宁可不拿也不要硬塞进数据池。因为一旦数据出了问题整个模型都可能要推倒重来损失远大于当时省下的那点获取时间。4. 数据清洗与格式化的关键步骤4.1 原始数据到训练语料的“五步清洗法”数据获取回来之后不是直接扔给Tokenizer就能训练。原始数据又脏又乱直接使用会导致训练不稳定、模型胡言乱语的概率上升。我自己整理了一套五步走的清洗流程每一步都不复杂但合起来能显著提升数据质量。第一步是去重。同一篇技术文章可能被几十个网站互相转载如果不做去重模型训练时同一段文本反复出现会让模型对某些表达方式过度拟合同时也浪费算力。去重可以用文本相似度算法比如SimHash、MinHash也可以用更简单的办法对全文做MD5哈希先去掉完全重复的再用抽取关键词做指纹比对去掉近似重复的。对安全领域来说建议去重后再做一次“变体重合”检查因为很多文章只是改了标题、正文几乎一致。第二步是去噪。把网页里的导航栏、页脚、广告、推荐位、扫码关注提示、无意义字符、错误编码等去掉。这一步可以从正文提取工具或写正则规则配合处理核心原则是保留有价值的技术内容。比如一篇漏洞分析文章中读者留言区的讨论可能有价值但“谢谢分享”“学习了”这类回复必须过滤掉。第三步是信息抽取与字段化。把原始的段落文本转成结构化字段比如把一份CVE描述转为{编号, 影响组件, 影响版本, 漏洞类型, 危害等级, 修复建议}这样的字典结构。这一步是安全数据处理的特色环节通用文本不需要这么做但安全数据如果只保留原始文本模型的检索和推理效率会大打折扣。信息抽取可以通过规则模板与正则先做一个初版再用人工检查和修正不必一开始就上大模型提取成本太高。第四步是质量过滤。这里要定几个硬性规则完全与大模型无关的内容直接丢弃大量由符号、链接、乱码组成的文档直接过滤字数太少的片段、重复率过高的废话段落可以去掉涉及具体攻击利用细节描述但又没有完整的上下文技术说明的内容视情况降权或剔除。质量过滤很难有统一标准建议先抽样看一批数据再根据这些样本制定过滤规则然后迭代调整。第五步是标准化与编码处理。统一文本编码为UTF-8统一换行符统一标点风格中英文标点共存去除不可见字符和控制字符对特殊的安全符号比如IP地址、域名、哈希值做保留或脱敏处理。4.2 让数据更适配训练任务的三种格式经过清洗后的数据最终要转换成语料格式。我总结下来用三种格式基本能覆盖绝大多数的训练任务第一种是原始文本格式适合预训练阶段。就是纯文本每篇文档作为一条样本文档之间用特殊分隔符隔开。这种格式最简单让模型在大规模文本中学习语言规律和知识。安全类文档按“领域内优先级”排序后进入预训练池通用语料和垂直语料按比例混合。第二种是指令问答格式适合监督微调和指令微调阶段。每条数据由指令Instruction、输入Input、输出Output三部分组成。比如指令是“请分析这个告警事件的潜在风险”输入是一段脱敏后的告警日志输出是一段标准的研判分析结果。这种格式能直接教模型学会“接到任务—处理上下文—生成回答”的行为模式。建议在安全数据集中把问答对做得尽量贴近真实业务场景。第三种是对话多轮格式适合对话模型的继续训练。每条数据由多轮人机对话组成带上说话人标识。这种格式适合从真实工单和客服记录中整理把单轮的“一问一答”扩展为多轮的“追问—澄清—补答”能让模型学会在上下文不完整时主动追问信息而不是硬着头皮瞎猜。我建议这三类数据分开存储、分开管理互不混用因为训练的用途不同、处理时的侧重点也不同。混在一个文件里的做法后期排查数据问题时会十分痛苦。4.3 数据合规不能只挂在嘴边在这里要特意用一个完整小节来讲合规因为在安全领域做数据获取这是一个绝对绕不过去的问题。很多人觉得“网上能抓到的就是公共数据谁都能用”这个想法是大忌。具体的合规注意事项包括第一明确数据来源的版权和使用协议。有些技术博客明确标注“禁止转载”“未经许可不得用于商业用途”如果要把内容用于模型训练需要先去确认是否合规第二涉及个人信息和敏感业务数据的内容必须脱敏处理。网络安全领域的数据里常常夹杂着IP、账号、域名、哈希值等信息这些要按规则处理第三来自商业产品的数据比如某安全产品的告警、漏洞扫描报告要注意厂商授权第四如果你使用的数据和别人合作要明确数据的使用边界避免在训练过程中把数据泄露到不合适的环节。这些不是走过场。我见过一个项目因为用了未经授权的数据模型研发到一半收到来自原网站作者的投诉函最后只能把所有相关数据删掉重新建池。这种事不光毁项目的进度对团队的士气打击也很大。5. 半自动化数据管道怎么持续高效地积累数据5.1 搭一套最小可用的安全数据采集管道数据获取这件事如果全部靠手动下载、手动整理第一版数据集还没凑齐人已经先崩溃了。所以我建议从一开始就搭一套半自动化的数据采集管道哪怕简陋一点也能帮你省下大量时间。一个最小可用的管道大概包括四个部分采集端、解析端、存储端、质检端。采集端负责定时从你选定的数据源抓取更新内容。可以选择简单的定时脚本也可以做一个小型爬虫调度中心。安全领域的数据源更新频率不一漏洞库可能每天更新技术博客可能三五天更新一次社区帖子可能每小时都有新内容。采集频率要和源更新频率匹配避免对对方服务器造成过大压力。解析端负责把抓回来的HTML、PDF、JSON转成干净的文本。HTML解析常用BeautifulSoup或Requests-HTMLPDF解析可以用pdfplumber或PyMuPDFJSON直接按字段提取。解析端往往会遇到很多“脏页面”需要投入一定时间做页面解析模板建议只针对高频数据源做精细解析低频数据源可以甩给算法做通用提取不必追求完美。存储端负责把解析后的数据落库。我用过的方案里最基本的可以是一套按日期、按来源分目录的文件存储每个文件就是一个JSON或Markdown文档稍微正规一点可以用Elasticsearch或MongoDB方便后续检索和筛选。选择什么存储取决于你的数据规模和团队偏好但核心要求是每一条数据都要带上“来源URL、抓取时间、数据源名称”等元信息这会给后续的数据追溯和合规审计带来极大便利。质检端负责对数据做抽样检查。可以每天随机抽几十条新数据人工确认解析结果没有乱码、没有错位、格式符合设计。这个环节最容易被省略但省略后一旦解析模板因为网站改版出了问题你可能攒了一个月的坏数据还不知道到训练时才发现那就非常被动了。我建议至少在自动化管道跑通后的前两周内坚持每天人工抽检一次新入库数据。5.2 数据版本管理像管代码一样管数据数据积累到一定量级后版本管理就成了刚需。你会发现训练完一版模型后数据池又更新了不少但你没法说清楚新数据池和旧数据池改了哪些文件于是对比实验就成了一场糊涂账。我的做法是为一个数据池建立类似Git的管理习惯。不一定要真的用Git当然Git LFS或DVC也行但必须有“快照”的概念。每当你准备启动一轮新的训练就为当前的数据集打一个版本快照记录数据总量、各类别占比、新增数据时间范围、清洗规则的版本号。等模型训练结束后把模型效果和这个数据版本绑定。下一条数据版本上线时就能清楚地对比“数据增量的变化导致模型效果是上升还是下降”。这里也想提一个容易被忽略的点随着网络环境的演进安全语料中的知识也在不断变化。三年前的漏洞分析和威胁情报在今天看可能已经过时或者被新的攻击方式替代。所以数据版本管理还要配套一份“数据时效性清单”明确哪些数据源可以长期保留、哪些按季度清理、哪些在模型迭代时必须重新获取。对安全大模型来说数据不是越多越久越好而是越新、越准越好。5.3 开源工具和框架怎么选关于“有哪些开源的大模型训练平台”这个问题经常有小伙伴来问。这个问题本身很大但在数据获取与预处理这个环节真正要用到的开源工具没那么复杂我按流程列一下实际验证过、比较顺手的工具组合数据采集方面常用的还是Python生态的Requests、Scrapy、Playwright。Requests适合简单页面Scrapy适合需要分布式采集的站点Playwright适合需要执行JavaScript的动态页面。安全社区里面动态加载的页面很多所以Playwright或Selenium在采集端的使用频率不低。HTML清洗方向BeautifulSoup和lxml是主力文本内容更复杂的场景可以用Readability对正文抽取有效或Trafilatura一个专门做正文抽取的Python库实测下来对多类网页的正文提取效果不错。文档解析方面PDF类用pdfplumber或PyMuPDFDOCX用python-docxPPT用python-pptx这些都属于很成熟的库。数据去重与清洗在数据量不大时直接用Pandas处理表格、正则处理文本就够了。数据量大到几十GB甚至上百GB时可以考虑引入Spark或Dask做分布式处理但对安全领域这种体量来说优先级并不高。很多时候单机多进程方式跑完一轮清洗也就是几个小时的事。数据存储与检索可以用Elasticsearch做全文检索也可以只用传统的文件目录和SQLite。如果只是自用SQLite的轻量优势很明显如果团队协作Elasticsearch的检索能力和权限管理体验更好。两者不冲突可以先用文件存原始结构再导一份到ES供检索。需要提醒的事实是工具链只是辅助真正决定数据质量的是你制定的清洗规则和信息抽取模板。工具可以换规则必须沉淀好。6. 实操过程与核心环节实现6.1 一个完整的漏洞数据采集示例空谈分类和思路总觉得太虚我拿一个具体案例来演示整个数据获取链路怎么走通。这里以“采集并整理CVE漏洞数据”为例整个过程从零开始一步步说清楚。第一步先找到数据源。NVD提供的JSON数据包支持全量下载和增量更新这是很理想的漏洞数据源。在国内访问可能有延迟的情况可以找镜像或者用其他的开源漏洞库接口。这里我们不针任何具体数据源做广告只谈通用思路。第二步写一个定时采集脚本。用Python的requests请求数据接口把返回的JSON保存到本地。为了避免给服务器造成压力每次请求加一个合理的时间间隔设置请求头伪装成正常浏览器。一个简化版的代码如下import requests import json import time from datetime import datetime # 示例从漏洞数据接口获取最近7天的漏洞信息保存为json文件 def fetch_vuln_data(days7): headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } url https://example-vuln-api.org/api/vulns params { days: days, format: json } try: resp requests.get(url, headersheaders, paramsparams, timeout30) resp.raise_for_status() data resp.json() except Exception as e: print(获取失败, 重试机制需补充: , e) return None today datetime.now().strftime(%Y%m%d) filename fvuln_data_{today}.json with open(filename, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(f数据已保存: {filename}, 共{len(data)}条) return data if __name__ __main__: fetch_vuln_data(days7)第三步解析和结构化。拿到了原始JSON里面可能包含编号、描述、评分、参考链接、影响产品等多个字段。在清洗时把这些字段抽出来去掉不需要的字段再做统一格式。如果描述字段是英文还需要用自动翻译或者人工校对的方式转成中文或中英对照。这里要注意的是自动翻译的结果会有一定错误率不能全信对安全术语尤其要关注比如“privilege escalation”不能简单直译成“特权升级”很多语境下更准确的表达是“提权”。术语的统一是安全语料清洗中必须投入精力做好的细节。第四步补全上下文。只有漏洞编号、描述、评分的原始数据对模型训练来说还是太单薄了。建议把漏洞和对应的修复方案、受影响的版本范围、相关漏洞利用代码的分析报告如果有且合规关联起来形成更完整的知识单元。这一步可以通过规则把CVE编号和已采集的技术博客文章做关联匹配把相关文章全文作为补充上下文与漏洞数据拼接在一起。这样模型学习到的知识就不是“某个漏洞打了7.5分”这种孤立信息而是“漏洞基本信息—影响范围—检测方式—修复方案—实际案例”这样的完整链条。6.2 技术博客与社区文章解析的实战记录第二个具体场景是采集技术博客和社区文章。相比漏洞库的结构化数据这一类的处理难度高一些但价值密度也高一些。我的常规做法是首先梳理出了一份“安全技术源清单”里面把与目标方向强相关的技术博客、社区版块、公众号文章链接全部整理进去。发布频率高的源用定时任务每天拉取发布频率低的源每周拉取一次。考虑到部分站点开启了防爬我常用Playwright模拟浏览器访问等页面渲染完成后提取正文再结合Readability或Trafilatura做正文抽取去掉导航栏、评论区噪音、相关推荐等模块。下面是简化一点的示例逻辑from playwright.sync_api import sync_playwright from trafilatura import extract, fetch_url def fetch_article_content(url): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(url, timeout60000) # 等待关键内容加载出来避免动态渲染未完成 page.wait_for_selector(article, timeout30000) html_content page.content() browser.close() text extract(html_content) return text if __name__ __main__: article_url https://example.com/blog/security-analysis-2024 content fetch_article_content(article_url) print(content[:500])这段代码的思路是先用Playwright渲染出完整HTML再用Trafilatura把正文捞出来。实际使用中不同站点的页面结构差异很大可能遇到“选择器找不到文章标签”“页面弹窗拦截”“滚动加载导致内容没取全”等问题。这种一个个站点适配的工作很琐碎但属于数据获取逃不开的体力活。文章正文拿到手之后只做成纯文本入库又太浪费了。我建议后面再加一道“信息抽取”工序用规则或者小模型去抽取标题、发布日期、作者、标签、涉及的漏洞编号、涉及的组件名称等技术要素。比如一篇标题为“某框架反序列化漏洞分析”的文章可以抽取出“框架名”“漏洞类型”“受影响的版本范围”“利用条件”“修复方式”等结构化字段连同正文一起入库。这样将来在构建微调语料时就可以直接用这些字段做筛选和重组产生出知识密度更高的问答对。6.3 语料平衡怎么做防止模型“偏科”数据获取做到后期一定会遇到一个典型问题采集回来的语料分布严重不均。比如漏洞数据占了一大半攻防实战案例分析只有零星几篇或者Web方向的内容特别多二进制安全方向的内容几乎没有。这种不平衡会让模型出现明显的“偏科”现象说不定它聊Web攻击头头是道问它内核提权相关内容就含糊不清。解决这个问题的核心思路是“分层目标和样本量控制”。在开始数据建设时就为目标模型定一个活列出12到15个核心子方向比如漏洞研究、渗透测试、恶意软件分析、日志分析、安全合规、应急响应等。每一个子方向都设定一个目标样本量的下限和上限下限保证最基本的知识覆盖上限防止单一方向过多挤占其他方向的空间。采集回来的数据按子方向打标签统计每个方向的样本量超出上限的做降采样不足下限的做补充采集。这是有时间成本的却是保证垂直模型均衡性的关键一步。Beta版本我做数据池时没有注意这一点结果模型往一个方向严重倾斜。后来重新整理数据时花了大量时间做类别标注和重新平衡。所以这个“未雨绸缪”的建议含金量很高。7. 常见问题与排查技巧实录7.1 数据源访问失败与页面反爬应对做数据获取一定会遇到访问失败的问题常见原因包括网站的访问频率限制、特定UA被拦截、需要登录或验证码、页面结构变化等。应对频率限制最有效的办法就是控制请求频率在两次请求之间加随机延时避免以固定间隔每秒发请求。加固延时还不够的站点可以用代理池配合轮换但使用代理时要注意合规和成本。遇到需要JavaScript渲染才能看到内容的页面用Playwright或Selenium把渲染这一步模拟掉。遇到的问题再多一些站点启用了比较严格的风控频繁切换IP可能会被临时封禁这时候不要硬刚把采集频率再降一个量级或者改在对方访问低峰期再跑。数据获取本质上是个细水长流的过程没必要为了快一两天把自己IP封了反而更耽误事。页面结构变化也是会频繁遇到的坑。安全社区和其他网站一样会不定期改版解析模板经常会突然失效。解决的策略一是解析模板做配置化不要写死在代码里这样前台调整结构时可以快速在前面改配置恢复二是给数据管道加“异常检测”当某一天某个数据源的解析成功率为0时立即发报警不要等到次日才发现入库数据为零。7.2 数据质量参差不齐怎么把噪音控制在合理范围数据抓回来以后噪音是难免的。有些网页正文里有大量宣传语、跳转链接、无关推荐有些文章是AI批量生产的伪原创内容知识密度几乎为零。建议在入库之前做一次“可读性打分”用文本长度、段落长度、标点分布、专业术语密度等指标给每篇文档打一个基础分低于阈值的直接丢弃。安全数据有一个特殊关注点直接用规则或分类器过滤明显低质的“营销文”。网络安全领域存在大量以卖课、卖工具、引流为目的的软文它们标题很吸引人但内容浅薄、充满广告信息。这类内容如果不加过滤模型会学出一堆“只要提到安全就推荐培训班”的不良倾向。这个过滤规则可以做成关键词黑名单加分类模型的双重机制虽然做不到完全零漏网但能把比例控制在合理范围内。另一个容易被忽视的噪音来源是“翻译腔”和“机翻文”。很多海外安全文章被机翻成中文后术语混乱、语句不通顺放进语料里会拉低模型的语言质量。筛选时建议对这类内容做“术语一致性检查”对高频安全术语列表做一次匹配如果一篇文章里“注入”一会儿被翻译成“注入”一会儿被翻译成“射入”说明机翻质量不高可以直接降权或过滤。7.3 数据量不足怎么办从“找数据”转向“造数据”很多团队做垂直模型时最容易遇到的尴尬问题是数据源的公开语料就那么多挖来挖去就那么些达不到理想的数据量级。这时候有两个方向可以参考。第一个方向是把横向来源扩大把单模态变多模态。比如旧的中文安全论坛内容、安全工具官方文档、开源项目的告示文档、行业峰会公开的演讲PDF、甚至安全类开源书籍内容这些都可以纳入语料。此前只从博客和漏洞库取的思路可以扩大到邮件列表归档如开源安全社区的邮件列表、GitHub仓库里的安全相关README和Wiki页面等。第二个方向是用“数据增强”造一部分高质量数据。近一两年的主流做法是用通用大模型把已有的高质量语料重写、扩写成多种形式的知识点。比如把一篇漏洞分析文章喂给通用大模型让它生成几个不同角度的问答对或者让它把给定内容改写成“初级/中级/高级”三个难度层级的知识讲解。这种方式能显著扩充监督微调阶段的数据量但要注意引入的数据要经过人工抽检或规则校验防止大模型添油加醋带来错误知识。这两个方向可以叠加使用。先扩大来源的量再用数据增强扩大指令数据的多样性。但如果时间有限我的建议是优先保证质量宁可数据量少、覆盖核心子方向也不要盲目拼凑大量低质语料。7.4 数据质量检查清单最后把数据获取阶段容易踩的坑集中整理成一张速查清单。每一轮数据池构建完成后按这份清单过一遍可以省去后续很多麻烦。检查项检查方法通过标准重复率对入库文本计算哈希相似度完全重复率3%近似重复率10%编码一致性全量扫描文本编码与特殊字符统一UTF-8无乱码和特殊控制符号来源标签完整性检查每一条数据是否有来源URL和抓取时间100%具备合规性根据来源协议与内容脱敏要求抽查无未获授权的高风险内容类别均衡度统计各子方向样本量占比核心子方向占比不低于5%不超过30%时效性检查最近更新的数据是否在7天内入库新一轮增量训练时可访问到最新的灾难威胁数据文档长度检查清洗后文档的篇幅分布极短200字和极长50000字文档需人工确认专业术语准确性抽取高频安全术语人眼复核无大面积术语错译、乱译情况这个清单不用做得很重但一定要坚持执行。数据获取环节的问题越早发现修复成本越低。等到模型训完再发现数据有问题就得整个流程重新来时间和算力的浪费都非常可惜。8. 收尾做了这么多轮数据获取与整理工作我个人的体会有两点。一是网络安全大模型的数据建设本质上不是一次性工程而是持续运营的资产积累。数据源会变化、知识会更新、业务需求会调整所以“管道”比“存量”更重要。把时间和精力花在数据管道的稳定性和可维护性上可以在未来每一个新模型版本上线时获得持续的回报。二是给自己的工作留好余量。数据获取涉及的版权、隐私、克制使用问题在项目初期就要想清楚。与其在数据出现纠纷时焦头烂额不如在每一次数据入库之前多问一句“这个数据来源我有没有权限使用”。在合规这件事上慢一点反而更快。这一篇讲到这里关于数据获取和整理的思路基本已经说完。下一篇文章里我计划结合前面搭好的数据池聊聊网络安全大模型训练时的超参调整与调优策略欢迎感兴趣的朋友继续关注。