网络安全大模型数据获取实战：从数据源到训练集的全流程解析

网络安全大模型训练这件事，真正动手之后会发现，模型结构、并行策略、调参技巧这些反而不是最先卡住你的环节。最开始卡住我的，就是数据获取。这期实战篇我来好好聊聊“网络安全大模型的数据获取”这个话题，我会把数据源怎么选、采集红线怎么避、清洗流程怎么搭、质量怎么评估这些过程中踩过的坑和验证过的方法都拆开来讲，希望对正在准备数据或者已经卡在数据环节的朋友有一点参考价值。

先说清楚我为什么要单独写一期数据获取。网络安全领域和通用领域有个本质区别：通用大模型可以靠Common Crawl、维基百科、GitHub这些海量公开语料堆出来，但网络安全语料高度分散、极度依赖领域知识，大量有价值的样本藏在漏洞库、安全公告、渗透测试报告、流量日志、红队工具文档里，而且很多内容还有时效性和合规限制。如果不先把数据问题解决掉，后面做预训练、指令微调、RLHF都会变成无米之炊。所以这一篇我会围绕三个核心问题展开：有哪些合法合规的数据来源、如何把这些异构数据变成模型能用的高质量样本、以及数据管线的自动化实现。

1. 网络安全大模型训练数据获取的整体思路

1.1 先想清楚模型要做什么，再决定采集什么数据

在动手写爬虫和脚本之前，我建议你先花一天时间想明白一个事情：这个网络安全大模型到底要解决什么任务？不同任务对数据的需求完全不一样，这里很容易犯“什么都想收集”的毛病。

我做过几个不同类型的项目，数据侧重点差异非常大：

• 如果目标是做安全知识问答助手，重点是漏洞原理、攻击链路、防御方案、合规标准这类解释性语料，需要的是高质量的长文本，类似于“OWASP Top 10漏洞详解”这种结构清晰的资料，数据量不用特别大，几万到几十万条优质问答就够了。
• 如果目标是做威胁情报分析，重点是IOC（失陷指标）、攻击团伙画像、恶意样本行为描述，这部分数据讲究“新”，需要持续从开源威胁情报源增量拉取，一个月前的数据价值都会明显下降。
• 如果目标是做代码安全审计，重点是有漏洞的代码片段和无漏洞的对照代码，这需要从开源仓库、CVE修复提交记录里提取pair样本，数据清洗难度最高，但效果也最明显。
• 如果目标是做日志与流量异常检测，重点是有标签的攻防流量日志，这类数据一般没办法公开采集，多数要靠自己做靶场环境产线，或者找合作单位合规获取，数据成本非常高。

我见过不少团队在数据阶段拼命追求“大而全”，结果数据堆了几百GB，真正对模型能力有帮助的领域适配样本反而不够。我的经验是：先画清楚任务边界和目标能力，再倒推数据需求。哪怕你后面要做全流程预训练，也建议先把垂直任务的数据管线打通，再谈扩展。我给内部团队做方案评审的时候，一定会先看一张“任务—数据映射表”，这张表里每一项能力都对应明确的数据源和预估数据量，没有这张表，后面几乎必然返工。

1.2 自研采集为主、开源数据集为辅，两手都要抓

关于数据获取的技术路线，市面上有两种主流思路：一是尽量找已经整理好的开源安全语料数据集，比如各类GitHub上的安全NLP数据集、漏洞描述数据集；二是自研爬虫和采集管道，从公开渠道批量抓取原始数据，再清洗加工。

我之前一直倾向于前者，因为省事。但实际操作之后发现，现成的开源安全数据集普遍存在三个问题：一是数量太少，二是时效性差，三是任务格式不匹配。比如我想做“CVE描述到修复建议的生成任务”，开源数据集里的CVE描述往往只有两三行英文摘要，根本撑不起一个生成模型的训练需求。反而是自己采集的原始安全公告、补丁说明、漏洞分析文章经过加工后，信息密度和格式丰富度都远高于开源数据集。

最后我采用的方案是“两条腿走路”：开源数据集作为基座和验证集，自研采集管道作为主力数据来源。开源数据集用来冷启动，验证数据格式和标注规范是否合理；自研管道负责规模化生产，按周或者按天增量更新。这套组合的好处是可以快速跑通流程，同时保证数据源是活的、可持续更新的。

2. 合法合规边界与公开数据源的工程化筛选

2.1 哪些数据能用于训练，哪些绝对不能碰

在聊数据源之前，必须先立规矩。这一节可能是整篇文章里最重要的一节，因为网络安全领域的数据获取比其他行业更容易踩到合规红线。我自己在项目启动前都会把合规条款列成清单，逐项确认，宁可进度慢一点，也不碰有风险的数据。

能用于训练的数据主要有四类：一是官方公开的漏洞库和公告，比如CVE、NVD、CNNVD、各厂商安全公告；二是公开技术资料，比如安全博客、会议论文、开源书籍、官方文档、标准规范文件；三是有明确授权或开源协议允许使用的数据集，比如MITRE ATT&CK框架、OWASP项目文档；四是自己在合规环境下产生的数据，比如靶场中的渗透测试日志、自建蜜罐捕获的样本。

绝对不能碰的数据也有四类，这个没有任何商量余地：一是涉及个人隐私的数据，比如真实用户的通讯录、聊天记录、账号密码，哪怕是从公开渠道泄露出来的也不行；二是未公开的漏洞细节和未脱敏的实战渗透报告，这类可能涉及未授权测试或敏感单位信息；三是需要授权才能访问的商业威胁情报数据，脱离授权范围使用就违约了；四是任何暗网渠道、黑产渠道流出的数据。这些红线不是开玩笑的，一旦出事，不光项目完蛋，整个团队都可能背上法律风险。

提示：有朋友可能会问，公开泄露的数据库能不能用来训练？我的明确结论是不能。公开泄露不代表可以合法使用，里面往往包含大量个人信息，使用即违规。这一点我和法务反复确认过，也建议你在项目启动前找专业合规人员做一次数据合规审查。

2.2 值得重点建设的公开数据源清单与优先级

明确了边界之后，我整理了一份网络安全大模型训练中值得重点建设的公开数据源清单。这份清单不是网上随便找的推荐列表，而是我在实际项目中逐项验证过、确实能拿到高质量数据的来源。

第一梯队是官方结构化数据源，优先级最高。NVD和CVE列表提供了漏洞编号、描述、CVSS评分、参考链接等结构化字段，清洗成本最低；MITRE ATT&CK提供了攻击技战术的完整知识体系，是理解攻击链路的骨架；OWASP系列文档覆盖Web安全、API安全、移动安全等主题，特别适合训练问答能力。这些数据源稳定、权威、结构清晰，建议作为整个数据底座的基石。

第二梯队是高质量非结构化内容。安全厂商的公告和技术博客，比如微软安全响应中心、Google Project Zero的帖子，内容深度很好，时效性也很强；顶会论文和开源安全书籍，比如USENIX Security、S&P的论文，学术性强但语言偏抽象，对模型的逻辑推理能力提升帮助很大。这一梯队的数据量不大，但价值密度高，适合作为训练数据中的“精品语料”。

第三梯队是代码与威胁情报相关数据。GitHub上带有安全主题的仓库、CVE修复的commit记录，这些是训练代码审计能力的核心素材；公开的恶意样本分析报告、YARA规则、Snort规则这类规则类文本，可以帮助模型理解检测逻辑。这类数据有一个特点：结构性强但格式混乱，清洗时需要针对不同子类型分别写解析器。

第四梯队是社区讨论和问答数据，比如Stack Overflow上带安全标签的问题、安全论坛的技术讨论。这类数据口语化强、场景丰富，适合让模型学会用接地气的语言回答问题，但噪声也比较大，需要严格过滤掉低质量灌水内容。

数据源建设优先级我可以直接用一句话总结：先官方库打底，再补精华文章，再挖代码和情报，最后看社区内容。这个顺序既考虑了数据质量，也兼顾了合规风险。

3. 核心数据源解析与采集实操

3.1 漏洞库与安全知识库的结构化数据采集

漏洞库是整个网络安全语料里我最推荐优先采集的部分，原因是它同时具备权威性、结构化、增量更新三个优点。以NVD为例，它提供了完整的JSON数据接口，支持按时间批量拉取CVE记录，每条记录里包含漏洞描述、CVSS向量、影响产品、参考链接、CWE分类等多个字段，这是天然的优质训练语料。

采集NVD数据时，我的做法是先做全量历史数据同步，再按天做增量更新。NVD的JSON数据压缩包大约几百MB，解压后是几十万条CVE记录，全量同步一次的时间在一个小时左右。关键是增量部分，我建议用lastModifiedDate字段做增量判断，而不是用发布时间，因为NVD会不时修订历史CVE的描述和评分，修订内容对模型准确性同样有价值。

在实际处理中，CVE描述原文通常比较简短，比如“Buffer overflow in function foo allows remote attackers to execute arbitrary code via a crafted request”，这样一句话对训练来说信息量不够。我的经验是把CVE、CWE、CAPEC、ATT&CK四类数据做关联拼接，用CVE里的参考链接去抓取对应的分析文章、补丁描述、Exploit-DB利用代码，然后生成一条信息完整的“漏洞全景样本”。这种关联后的样本格式大概长这样：

{ "cve_id": "CVE-2024-1234", "cwe_id": "CWE-89", "cvss_score": 9.8, "description": "原始描述", "affected_products": "受影响产品列表", "attack_vector": "来自CAPEC/ATT&CK的攻击路径描述", "patch_reference": "补丁内容摘要", "analysis": "从分析文章提炼的漏洞成因与影响", "remediation": "修复建议" }

这样处理后，一条原本只有几十个token的CVE记录可以扩展到几百甚至上千token，信息密度和关联性都大幅提升，模型训练时能学到的东西明显更多。需要提醒的是，抓取参考链接里的文章时一定要设限速，我通常控制在每请求间隔1到3秒，避免给对方服务器造成压力，这也是一个从业者最基本的素养。

3.2 安全博客、论坛与代码仓库的非结构化采集

非结构化内容采集是数据量最大的来源，也是最容易翻车的地方。安全博客和论坛数据采集的核心难点不是写爬虫本身，而是如何保证“相关性”和“质量”。

我先说相关性。直接把一个科技新闻网站的所有安全频道文章抓下来，里面会混入大量产品发布类、公关类低质内容。我采用的方案是基于关键词白名单加AI预筛选的两级过滤。关键词白名单覆盖漏洞、攻击、恶意软件、钓鱼、渗透、加固、取证、应急响应这些核心词，第一级过滤把完全不相关的页面直接丢掉。第二级用一个小型的text classifier对标题和首段做分类，判断这篇内容偏“技术干货”还是“新闻资讯”，技术干货进入训练池，新闻资讯直接归档为参考材料。

再说质量。安全论坛的内容质量波动很大，比如Reddit的r/netsec板块精品率高，但有些板块的水贴率能到40%以上。我的处理方式是按发帖分数、评论数、回复长度综合排序，只保留综合得分在前30%的高质量讨论串。这里有一个很实用的技巧：用楼层回复的长度和代码块数量来辅助判断质量。一个被大量长回复讨论、且包含代码示例的主题，大概率是有价值的技术讨论；只有一两个“+1”、“mark”的帖子，直接丢弃即可。

代码类数据我主要从GitHub采集，但不会用公共仓库全量镜像那种粗暴方式。我的做法是先用GitHub搜索API按安全关键词拉取候选仓库列表，再通过仓库的star数、更新时间、Liscense类型做一轮过滤，要求优先采集带有MIT、Apache-2.0等宽松协议且近期活跃的仓库。拿到仓库之后，进一步提取两类信息：一是README和docs目录下的技术说明文档，这是训练模型理解安全工具用法的好材料；二是issues和commit message里涉及漏洞修复的讨论文本，这些是理解真实安全问题的金矿。

3.3 数据的增量更新与版本管理

网络安全数据有一个和通用语料完全不同的诉求——强时效性。去年发布的漏洞分析对于通用问答可能还有参考价值，但对于威胁情报类任务几乎没有意义。所以数据管线在设计第一天就要把增量更新和版本管理考虑进去，否则三个月后你会发现模型还在输出已经过时的CVE信息。

我把数据存储设计成了分层结构：raw层存原始抓取结果，按来源和时间分区；processed层存清洗后的标准格式数据；curated层存经过质量评估和去重后的最终训练集。每一层都打上数据版本号，版本规则用“日期+数据源+hash”来表示，比如20250519_cve_full_a3f9c2。这样做的好处是，当训练结果不理想时，可以快速定位是哪一批数据引入的问题，直接回退到上一个数据版本，不需要整个流程重跑。

增量更新的调度策略我用了两套任务：每日增量任务覆盖漏洞库、威胁情报这类高时效数据源，抓取间隔可以设为6到12小时一次；每周全量任务覆盖博客、论坛、论文这类相对稳定的数据源，每周做一次深度抓取即可。这样既保证了时效性，又不会对目标网站造成过大访问压力，服务器开销也控制在合理范围。

4. 数据清洗、标准化与安全合规过滤

4.1 爬虫原始数据的自动清洗与格式统一

从不同数据源抓到的原始数据格式千差万别，有HTML、JSON、Markdown、PDF文本、XML，还有纯文本。清洗的第一步是把所有内容统一成标准Markdown格式，这个步骤看似简单，但细节相当多。

HTML清洗时需要注意三个点：一是去除script、style、iframe等非内容标签，以及追踪参数、分享按钮这类噪声；二是保留结构信息，比如把h1到h6标签转成Markdown标题，把table标签转成Markdown表格，把code标签转成代码块，这样模型能学到结构化的文档排版；三是对正文做编码纠错，我发现很多安全站点是从Word或WPS粘贴发布的内容，会带有全半角混用、弯引号、中文乱码等问题，需要统一做字符规范化。

代码片段在网络安全语料里的重要性非常高，但也是清洗最容易出问题的环节。很多爬虫框架在提取正文时会误删代码块，导致命令行的参数和漏洞代码的语法被破坏。我强烈建议在提取正文时单独把pre和code标签抽出来保存，不要和正文混在一起做标签剥离。我写过一个基于BeautifulSoup的提取器，对页面结构解析后的输出结构大概是这样的：

import re from bs4 import BeautifulSoup, Tag def extract_content(html: str) -> dict: soup = BeautifulSoup(html, "html.parser") # 去掉无意义标签 for tag in soup(["script", "style", "iframe", "noscript"]): tag.decompose() # 单独提取代码块，避免正文清洗时误删 code_blocks = [] for code in soup.find_all(["pre", "code"]): if code.get_text(strip=True): code_blocks.append(code.get_text()) code.replace_with(f"\n```\n{code.get_text()}\n```\n") # 提取正文并转Markdown text = str(soup) # 省略具体Markdown转换逻辑…… return { "title": soup.find("title").get_text(strip=True) if soup.find("title") else "", "content_md": text, "code_blocks": code_blocks, "source_url": canonical_url }

这里面有一个经验之谈：不能只保存清洗后的Markdown，也要把代码块单独存一份，方便后续做安全代码语料的专项提取。

4.2 敏感信息识别与合规过滤

网络安全数据里经常混有一些看起来“很有价值”但实际上不应该进入训练集的内容。最典型的是大量的IP地址、邮箱、手机号、密码哈希片段等敏感信息。我采用的正则规则加实体识别两层过滤方案，能有效控制这部分风险。

第一层用正则做粗过滤，覆盖邮箱、电话号码、身份证号、银行卡号、车牌号等常见PII类型。第二层用NLP实体识别对上下文做判断，比如识别出“admin/admin123”作为示例登录凭证放在技术教程中是可以保留的，但如果是真实生产环境的凭据样例，哪怕打码不完整也不能留。这里的判断标准是：数据是否指向可识别的真实主体，是否包含未脱敏的真实凭证、密钥、内网拓扑信息。

合规过滤规则我维护了一个黑名单词库，包括未公开漏洞利用代码的变体、特定企业内部系统命名（比如内部OA、ERP系统名）、未授权扫描工具的配置片段等，命中即整段删除。这个黑名单需要定期迭代，因为安全社区的语言习惯也在变。训练数据出现合规风险是大事，宁可过滤激进一些，也不要因为漏掉一条敏感信息导致整个数据集作废。关于这块，我在文末还会再给几条具体的部署建议。

4.3 数据去重策略与代码语义去重

训练大模型时数据去重是最影响训练效率的环节之一，尤其是网络安全领域，同一篇漏洞分析会被几十个博客转载，CVSS评分数据会在多个数据源重复出现。如果不去重，模型会把这些重复内容背得滚瓜烂熟，但对新数据的泛化能力反而下降。

去重我分了三个层次。第一层是URL和标题级别的精确去重，直接把相同URL和完全相同标题的内容过滤掉。第二层是正文MinHash去重，计算正文的MinHash签名，用Jaccard相似度阈值0.75以上判为近似重复。第三层是代码片段级去重，对提取出来的代码块单独计算LSH签名，把同一段漏洞代码在各种文章里反复出现的副本删掉。

有效去重后，我的网络安全语料库从最初抓取的几十GB文本，降到约10GB左右的有效数据。一开始我觉得这个损耗率太吓人了，但实际上这10GB的信息密度比未去重版本高了几个量级，最终模型效果也验证了这一点。做数据的人一定要有“舍得删”的心态，保留有价值的信息，而不是保留文件体积。

5. 数据标注与质量评估实战

5.1 标签体系设计与多粒度标注

网络安全语料和通用语料在标注上的区别是，安全领域有比较成熟的知识分类体系，不需要完全从零设计标签。我的标签体系是在MITRE ATT&CK和CWE的基础上扩展出来的多粒度方案，每条训练样本可以打上多个维度的标签。

第一维度是漏洞类型标签，直接采用CWE的分类ID，比如CWE-89对应SQL注入、CWE-79对应XSS，这个维度让模型能识别漏洞的“家族”关系。第二维度是攻击阶段标签，采用ATT&CK的战术阶段，比如初始访问、执行、持久化、横向移动，这个维度帮助模型理解攻击者在某个环节的动作目标。第三维度是数据能力标签，标记这条数据适合训练什么能力，比如漏洞解释、检测规则生成、修复建议、威胁情报分析。第四维度是时间与来源标签，记录数据的原始来源和时间戳，方便后续做时间衰减和溯源。

标注执行上，我采用“规则自动标注为主、人工抽检为辅”的混合策略。自动标注用规则和弱监督模型实现，比如文本中出现“SQL注入”关键词且命中CWE-89对应的特征词表，就自动打上CWE-89标签。人工标注主要用于处理冷门漏洞类型和复杂攻击链描述，这类数据比例不高，但模型能不能区分“不同漏洞之间的细微差异”就靠这部分精标数据。我一般会让两个标注员独立标注，再用Cohen‘s Kappa系数评估一致性，Kappa低于0.6的题目要重新讨论标准。

5.2 数据质量评估指标体系

很多团队做数据只管“量”不管“质”，等模型训练出来效果差，又找不到原因。我建立了一套数据质量的评估体系，在每次数据版本发布前自动跑一遍评分，分数不达标直接拦下来。

我用的核心指标有五个。一是毒性率，用现成的内容审核模型扫描语料的违规比例，网络安全语料的毒性率理论上应该接近0；二是PII命中率，统计数据集中残留的个人信息比例，要求低于万分之一；三是语言质量分，用perplexity或者语法错误率粗略评估文本是否通顺，太低的文本基本是乱码或者机器翻译残次品；四是信息密度分，统计每个样本的有效概念数量，太低的样本可能是灌水内容；五是指令匹配度，需要结合具体任务来评估，比如问答数据要检查是否存在问题和答案错位的情况。

质量评估报告会按数据源维度拆分，这样能直观看到哪个数据源的质量在下滑。比如发现某个安全论坛近期的采集质量持续下降，就可以降低这个来源的采样权重，把算力让给更优质的数据源。这套评估机制上线后，我踩过最典型的例子是：某个看起来内容非常丰富的安全百科站点，毒性率虽然没问题，但语言质量分持续偏低，排查后发现是一部分页面被站方用低质机器翻译覆盖了。如果只靠人工抽查，这个问题很难被发现。

6. 从数据到训练集的数据管道完整实现

6.1 数据管道的整体架构与调度设计

讲完单独的数据处理环节，我把数据获取环节的整体架构做一个串联。这个数据管道不追求太复杂，但要求稳定、可观测、出了问题能快速定位。

我的管道分成五个阶段：采集阶段、解析清洗阶段、去重阶段、质量过滤与标注阶段、格式转换阶段。五个阶段用消息队列串联，各阶段做成独立的worker进程，这样任何一步故障都可以单独重启，不会把整个管道拖死。调度上用到的是基于配置文件的定时任务，每个数据源都有自己的抓取频率和清洗参数，改配置不用重新部署代码。

管道运行状态用一张核心指标表来监控，我会每天看四个指标：采集成功条数、清洗后保留率、去重后唯一率、质量评估合格率。保留率突然下降大概率是清洗逻辑误删了有效内容；唯一率异常升高则可能是新一轮采集出现了数据源重复。用这些指标做预警，基本能做到24小时内发现数据管道异常，而不是等模型效果出来之后才反应过来数据出了问题。

6.2 训练集格式转换与数据配比

数据管道最后输出的训练集，格式要跟着训练阶段走。预训练阶段和指令微调阶段的格式完全不同，需要分别转换。

预训练阶段的数据格式比较简单，我用的是纯文本加文档分隔符的方案，每个样本来自同一个数据源，保持原始段落结构，不做指令模板包装。这个阶段的重点是打乱数据顺序，避免同类数据连续出现导致模型局部过拟合。我的经验是预训练数据里网络安全垂直语料占比控制在15%到25%之间比较合理，如果占比太高，模型的通用能力会下降；占比太低，垂直领域能力又不够突出。

指令微调阶段的数据则需要构造成人机对话格式。这里有一个很关键的经验：指令数据的配比要遵循“难度递进+多任务均衡”原则。先放简单的事实问答，让模型学会基础安全知识，再放需要推理的分析题，比如给一个日志片段问攻击链路是什么，最后放需要生成完整方案的复杂任务，比如“针对某Web应用给出渗透测试方案”。三类数据的比例我一般控制在4:4:2，效果比较稳。指令数据量不需要特别大，质量比数量重要得多，几千条精标指令往往就能带来明显的任务能力提升。

6.3 数据版本管理与训练结果的可追溯性

很多做数据的朋友容易忽略数据版本管理的重要性，导致后面训练出问题根本没法排查。我强烈建议从第一天开始就用数据版本管理工具来管理每一版训练集。

我目前的方案是每次发布训练数据集时，都生成一份数据版本清单，内容包括：数据源的清单和各自占比、清洗参数版本、去重阈值、质量评分报告、随机种子。任何一个训练实验跑完，模型卡的命名都会带上数据版本号，比如safe-model-7b-ds20250519v3。这样当模型效果出现异常或者用户反馈某个安全知识回答错误时，可以精确定位到是哪一版数据引入了问题，是数据源的问题、清洗规则的问题、还是标注标准的问题。

我印象很深的一次排查经历是：模型在其他任务上表现正常，但总是把某个漏洞的CVSS评分答错。靠数据版本回溯后，发现是某一批数据同步时把NVD的一个修订版本漏掉了，导致训练集里保留了旧的错误评分。修复后重新训练，错误率立刻降了下来。这件事让我深刻意识到，数据版本管理和代码版本管理一样重要，是所有可复现性的地基。

7. 常见问题与排查技巧实录

7.1 网络安全语料获取的典型问题速查表

我把实际运行数据管道过程中遇到的频率最高、最让人头疼的问题整理成一张速查表，方便你碰到了直接对照排查。

这张表是我踩坑记录的浓缩版，如果你在实操中遇到了不在这张表里的问题，大概率问题出在某个数据源的页面结构变化上——这是公共数据源采集中最常见的不确定性因素，要习惯性先检查这一项。

7.2 数据源封禁应对与采集限速策略

采集公共网站时被封IP几乎是每个做数据的人都要面对的问题。我的应对经验分三个层次。第一层次是遵守基本礼仪：控制请求频率，加随机延时，设置合理的User-Agent标识自己；第二层次是设计任务队列，让每个抓取任务的qps都可以独立限速，高价值低频率的数据源和低价值高频率的数据源分开调度；第三层次是设计优雅降级机制，连续多次失败时自动暂停该数据源任务并发送告警，而不是无限重试把对方服务器打挂。

这里我想多说一句：做网络安全的人更应该有网络秩序意识，在采集他人数据时守法合规是底线要求。我见过有些人写爬虫完全不设限速，几个小时内把一个技术博客站点抓挂了，这种事既坏了行名声，也给自己带来法律风险。官方提供了API的数据源，优先用API；页面没有提供API的，也要控制频率在合理范围内。“能拿到的数据很多”不等于“应该全部拿下来”，做数据工程要考虑对方服务器的承受以及后续合作的可能性。

7.3 不同应用场景下的数据获取策略

最后聊一个数据获取之外的延伸话题：不同规模的团队做网络安全大模型，数据获取策略应该完全不同，不能照搬同一个方案。

如果你是一个人维护的开源项目或者小团队，我建议直接采用“高价值开源数据集+精标指令集”的轻量方案，不要在自研采集管道上投入过多精力。重点放在整理开放的安全知识库数据、手工构造几千条高质量指令样本上，小模型微调照样能出不错的效果。我自己早期做过一个小参数量的安全问答模型，用的数据量不到5GB，也没有自研采集管道，纯粹靠精心整理公开数据，效果已经能用来做内部安全知识检索了。

如果你是中型团队，有专门的算法工程师和数据工程师，就可以按我前面讲的方案搭建自研采集管道，重点建设官方漏洞库、代码仓库和高质量安全博客三个核心数据源。大型团队则需要考虑更完善的数据合规审查、数据资产管理平台、联邦式数据获取机制，以及和高校、研究机构的合规数据合作。总之一句话：数据获取方案要和团队资源、项目目标匹配，不要为了做数据管道而做数据管道。

我在实际建设中还有一个越来越深的体会：网络安全大模型的数据工作不会一次完成，它更像一个持续运营的数据产品。漏洞在持续出现、攻击技术在持续演进、防御方案在持续更新，这就决定了模型底座数据需要按天或按周持续更新，而不是做完一版就束之高阁。如果团队预算有限，建议至少保证每季度对高时效性数据源做一次全量刷新，两条好的CVE增量数据，可能比一次大规模预训练对模型实际性能的提升更大。希望这期关于数据获取的分享，能让准备做网络安全大模型的朋友少走一些我开始时走过的弯路。