这两年我参与过不少AI安全评估相关的工作听过最多的一个抱怨是某个评测报告作者自己都跑不通或者某个安全评分换个环境、换个依赖库版本结果完全对不上。说实话当安全评估本身不可复现的时候我们很难判断这个模型到底是安全还是仅仅“看起来安全”。这正是我想认真聊聊“AI安全中的开放科学”Open Science in AI Safety的原因——这绝不是一个务虚的口号它直接关系到我们能不能在部署一个系统之前真正理解它的风险也关系到整个领域能不能把“安全”从一个宣传词变成一套经得起查验的证据链。有人可能会觉得“开放科学”不就是把代码和数据贴到GitHub上吗如果你也这么想那这篇文章值得往下看。真正意义上的开放科学在AI安全这个特殊场景里远比“开源”复杂得多它既要满足可复现、可审计、可比较的基本要求又要面对恶意利用、商业机密、双重用途等一连串棘手的边界问题。这篇文章我会从“为什么AI安全尤其依赖开放科学”讲起拆解落地维度再结合我自己在实操中总结的一套可配置的开放科学工作流最后聊聊个人、团队和行业分别能往哪个方向使劲。1. 安全评估的“可复现性危机”这道坎为什么绕不开1.1 让人头疼的“一次性评估”AI安全领域的评估和传统软件测试有很大的不同。传统软件测试里一个缺陷是不是存在通常是你运行一次就能得到稳定结论的但AI安全评估的对象是模型行为而模型行为受训练数据、随机种子、解码参数、系统提示词、甚至GPU型号和浮点精度的影响。这带来的直接后果就是很多安全评估报告本质上是一次性的——换了人来跑换了环境来跑结果就漂移了。我亲历过不少这样的场景。某个开源模型在某份安全基准上得分很高团队兴奋地准备复用结果我们按文档里的步骤走把pipeline搭起来之后分数掉了十几个点。排查到最后发现是对方在“某种未明确说明”的后处理环节里做了格式修正而那一步直接影响了对拒绝类回答的判定。你说他们是故意造假吗未必。更可能是评测脚本写得太随意评估过程没有版本化管理跑完就忘了细节。但问题在于安全评测如果不能被别人复现那它本质上就不是“证据”只是“说法”。更麻烦的是这类问题在AI安全领域非常普遍。大家可能还记得过去几年里一些模型声称通过了某些安全基准拿到了很漂亮的数值但在真实部署场景中却很快暴露出越狱、隐私泄露等问题。为什么会出现这种落差很大程度上是因为基准测试本身没有被当成一个严肃的科学实验来做——没有预注册的评估协议没有固定的环境清单没有经过审计的评测集数值自然只能反映“这次跑出来的结果”而不代表“可重复验证的事实”。1.2 不可复现的评估会怎样影响安全决策可复现性不是一个“学术洁癖”问题。安全评估最常见的使用场景是支撑部署决策。一个团队要决定“这个模型能不能上线”或者在什么限制条件下上线依赖的就是安全评估结论。如果评估不可复现那么这个决策就建立在一个无法复核的根基上出了问题连责任都说不清下游用户、监管方、审计方没有办法独立验证模型提供方的安全声明安全团队之间的经验无法沉淀因为你不知道对方那个分数到底意味着什么。打个比方安全评估就像桥梁承重检测。你说一座桥能承重50吨那得别人用同样的方法、同样的加载方式再来测一遍也能得到接近的结果大家才敢放心让车过桥。如果每次检测都“随缘”今天测是50吨明天换台仪器测变成20吨那这个数字对决策者来说不仅没有帮助反而有害——因为它制造了虚假的安全感。在安全领域我们太熟悉“虚假的安全感”有多危险了。所以如果今天AI安全领域只能先解决一个问题我个人会选把评估做成一门可以复核的科学。这也是开放科学在AI安全领域价值最大的切入点。1.3 为什么AI安全比传统安全更“先天”依赖开放有人会问传统的安全研究很多也是黑盒的渗透测试不也照样做为什么AI安全就非要强调开放科学因为两者能观测到的信息密度完全不一样。在传统信息安全里判断一个Web应用有没有SQL注入漏洞黑盒扫描几次就能得到相当可靠的结论漏洞是否存在和业务代码内部实现关系没那么大。但AI安全关心的是模型在对抗性输入下的行为分布而这个行为分布几乎受训练全流程影响。如果评估者只能通过API拿黑盒访问他就很难判断模型当前的安全水平到底是因为“模型真的校准得好”还是因为“评估集恰好被纳入过训练”还是因为“服务端的防火墙拦截了某些提示词”。当然我不是说黑盒评估没有价值很多第三方红队都是黑盒作业也有不小的发现。但作为一个生产者如果我们自己关起门来做安全评测不把评测方法、数据、代码、复现说明一起交出去那么外界对我们的安全声明就只能“听个响”。传统安全尚且知道“不要依赖隐藏来实现安全”security through obscurity 的教训AI安全却动不动把“保密”当成默认选项这从方法论上就是自断一臂。2. 开放科学在AI安全中的六个落地点从基准到红队报告说了这么多必要性那开放科学到底在AI安全里“长什么样”它不是“把所有东西一股脑公开”那么粗暴。下面这六个落地点是我在实践中最常接触到的维度每个维度都有它自己的开放方式。2.1 开放评估基准把“考官”摆在明处边界清晰、版本可控、经过验证的开放评估基准是AI安全开放科学的基石。这些年做得比较有代表性的包括HELM这类追求多维度评测的框架以及BigBench这种靠社区协作长大的评测集。在安全方向MLCommons推出过AI Safety v0.5那一版基准Anthropic等多家机构也都用公开Red Team测试集做过评估。这些基准的意义不仅仅是给模型打分更在于它们把“考官”的意见统一了。没有统一考官就会出现一家机构用一套自定义指标另一家用另一套分数之间毫无可比性。开放基准至少提供了一种通用语言你说你的模型在“危险能力”上得分很低那好请你在统一的基准上跑一遍给大家看。实践中有一个重要原则评估集一旦发布就应该保持稳定不能频繁改动。我就见过某个评测集过几个月偷偷替换了几十道题导致前后两次评估结果根本不能对比。如果要迭代评测集一定要带上版本号和变更记录这才符合科学实验的规范。2.2 开放数据集与数据卡数据血缘要讲清楚数据之于AI安全就像训练者之于运动员。一个模型的安全表现很大程度上取决于它在什么数据上训练、用什么数据进行对齐、用什么数据做评估。所以我一直认为AI安全里的开放科学第一个该开放的不是模型权重而是“数据的故事”。这包括训练集和评测集是怎么收集的经过了哪些清洗步骤有多少重复条目许可证是什么有没有隐私风险理想情况下这些信息应该以结构化文档的方式随数据发布也就是今天大家常说的“数据卡”Data Card。如果完整数据集本身因为版权或隐私原因不能公开至少也应该公开经过脱敏的子集、数据分布的统计摘要以及构建完整数据集的脚本。我见过不少团队在数据血缘上含糊其辞训练数据“来自互联网”、评测数据“内部整理”然后就不管了。这种做法的直接后果就是别人根本没法学你复现也更没法判断你的安全声明在多大程度上依赖了特定数据分布。数据血缘不透明安全评估就永远有一块模糊地带。2.3 开放基线模型没有参照系就没有判断要判断一个模型安不安全得先有一个“参照系”。一个完全未经安全对齐的模型是什么表现一个经过标准安全微调的模型是什么表现如果你的新模型在这些参照系面前没有取得明显优势那“我们模型很安全”这句话就没有依据。这也是开放基线模型在AI安全开放科学中特别重要的原因。基线的意义不在于“开源了多少行代码”而在于它为整个社区提供了一个公共的、可对比的起点。之前Meta开源Llama系列的时候虽然一开始也做gated release但至少大量研究团队可以基于它做安全评测社区很快积累了丰富的安全数据——这个过程反过来推动了越狱防御、红队方法研究的爆发式增长。如果你所在团队没有能力开源完整模型也可以考虑开放某个小规模的安全评测基线模型或者至少公开一份“在不改变评测环境条件下得到的安全基线数据表”。有了这个参照系团队内部的安全评估质量也会提高因为大家不能再自说自话了。2.4 红队报告与方法披露既要透明也别泄露“攻击剧本”红队报告是AI安全开放科学里分寸最难拿捏的部分。一方面红队过程要有透明度和可复现性不能只丢一句“我们做了红队测评模型通过了”另一方面完整公开红队使用的所有攻击脚本和恶意样例又可能变成“攻击教程”被不怀好意的人拿去直接利用。这里我比较倾向于分级披露完全公开红队方法论综述、漏洞类型分布、模型在公开基准上的表现、经过抽象的趋势性统计受控共享具体的高危攻击样例、特定漏洞触发的Prompt模板放在需要审批的受控访问环境中供合规机构和可信研究员使用绝对保密涉及严重高危漏洞且尚未修复的细节直到修复完成后再按步骤释放。这套分级披露的思路借鉴了传统安全领域的“负责任披露”Responsible Disclosure放到AI安全里同样成立。红队报告要开放的不是“武器”而是“结果和方法框架”。让同行能判断你的红队做得够不够专业、覆盖有没有盲区这本身就是一种巨大的进步。2.5 模型卡与评估卡把免责声明变成结构化文档Model Cards模型卡提出已经有几年了现在很多模型发布都会附带一份。但真正的开放科学不能只要一个形式。理想的模型卡至少应该包含训练与微调配置、数据来源与处理流程、不同群体和场景下的性能差异、已知局限性、推荐使用范围与使用边界、安全评测结果及复现方法。在安全相关的评估中我还建议额外维护一份“评估卡”Evaluation Card专门记录用了哪些评估集含版本、每项指标的评测流程、运行环境、随机种子、置信区间。这样做的价值在于把评估从“一个分数”变成“一份可追溯的实验记录”。我见过最好的做法是模型卡里的每个安全评估项都带一个“复现入口”——比如指向一个配置了固定环境、固定依赖、固定数据版本的评估仓库任何人点击进去都能按文档跑出和报告一致的分数。能做到这一步的团队目前还是少数但我觉得这才是安全评估本来应该有的样子。2.6 预注册评估协议防止“看结果下菜碟”预注册Pre-registration是从社会科学借鉴过来的方法核心是在跑实验之前先把研究问题、评估方法、样本范围、成功标准写清楚并公开存档等到实验结果出来后再对照检查。在AI安全评估里预注册的价值被严重低估了。为什么需要预注册因为不提前把评估协议固定下来很容易在拿到结果之后下意识地调低某个阈值的权重或者换一个指标来解释结果——这未必是恶意确实是人性。预注册本质上是用一个流程上的约束来对抗“事后合理化”。安全评估是高风险决策的依据如果协议本身是临场定的那整个评估的科学性就会大打折扣。现在很多AI公司发布安全报告时会公开一份“安全评估计划”但往往是结果出来之后才公示这和真正的预注册有本质区别。我特别建议有条件的团队把安全评测协议在动手评测之前就挂到OSF、Zenodo这类开放存档平台上打上时间戳然后再去跑实验。这个动作成本不高但对公信力的提升非常明显。3. “开放”在AI安全中是双刃剑四类现实阻力与可行边界开放科学在AI安全里推进得远远不够快不是因为没有共识而是因为这四个现实问题切切实实横在每个人面前。我不打算只喊口号下面逐条分析它们的边界在哪里。3.1 双重用途困境实验方法可能被反噬AI安全研究天然存在双重用途问题评估模型危险能力的方法本身也可能教会别人怎么利用这些危险能力。比如一个用来测试模型“是否能帮助制造生物武器”的评测集如果整个公开就等于给恶意者提供了一份“参考答案”。但这里有一个容易忽略的事实恶意行为者获取恶意能力的路径多种多样不一定非要靠你的评测集。封闭研究会拖慢安全社区防御工作的进度却不能真正困住恶意者。所以更合理的思路不是“完全不公开”而是“错峰、分层、条件公开”先让可信研究群体访问同时持续推进自动化评估技术让评估能力最终沉淀为系统层面的防御能力。安全社区与恶意者之间永远存在信息差博弈但战略上透明带来的长期收益通常大于保密带来的短期安全感。3.2 商业化与专有模型的压力企业凭什么要开放商业化公司有充分的动力保护自己的模型权重和训练数据因为这是核心竞争力。你很难要求一家头部AI公司把所有家底都亮出来这不符合商业逻辑也不现实。但突破口在于开放不等于全部开放你可以只开放“安全论证过程”。模型权重可以闭源但你用来论证安全性的评估方法、基准结果、数据集、复现工具链完全可以做得更加透明。事实上这才是安全团队在公司内部体现价值的方式之一如果安全结论只是老板桌上一份密报那它的可信度就只靠老板个人判断如果安全结论在保障不泄露机密的前提下可被审计、可被复核那整个公司的安全品牌力都会不一样。现在几家公司做法越来越精细化比如用gated release或者在模型卡里嵌入一份“第三方评估说明”邀请外部研究者参与审计。这些都是往前走一步。关键是要意识到开放是梯度不是开关。3.3 恶意行为者利用公开信息的风险低成本滥用不可忽视如果说商业阻力是“不愿”那恶意利用风险就是“不敢”。总有那么一些评估工具、越狱样例、攻击模板直接公开确实会降低作恶门槛。举个身边的例子某些公开的红队Prompt模板原本是用来测模型弱点的后来经常被普通网友拿去“玩越狱”导致模型提供方不得不频繁加防御。所以针对这一类高滥用风险的内容我认为“无条件公开”确实不是好方案。更实际的做法是“分级受控访问”研究者实名申请、说明研究用途、接受使用条款约束平台方审核后开放访问权限。这套机制在Hugging Face等平台上已经跑通了虽然不完美但至少比“要么全公开、要么全保密”的二元选择好得多。边界画在哪里很可能需要持续博弈和调整。但一个必须坚持的大方向是恶意利用风险应该用来决定“公开的方式和节奏”而不是拿来当作不公开、不透明、不负责的万能挡箭牌。3.4 快速迭代环境下的科学严谨性时间不够怎么办AI行业迭代节奏极快一个模型从训练完成到上线可能只有几周窗口期而一套严谨的预注册T检验多轮复现的评估流程可能需要数周甚至更长。尤其在我自己做过基准评估之后感受更深跑完一个基准是一回事把整个环境、脚本、数据管线的文档补齐又是一倍的工作量。但我必须说速度不是回避严谨性的充分理由。危机管理里有个概念叫“急事慢做”越是在高压下越需要把关键步骤做扎实。团队可以采取增量式做法第一版先保证核心评估脚本和数据自动存档保证别人能复现第二版再补预注册和模型卡第三版再上受控访问和第三方复核。不需要一步到位但必须开始走。说白了开放科学的严谨性不是“能跑就行”的最高要求而是安全评估的基本职业底线。迭代越快我们越需要一整套自动化、标准化的工作流来支撑而不是靠个人自觉和临时抱佛脚。4. 把开放科学嵌入日常研发一套可落地的桌面工作流前面讲了很多理念和边界接下来这部分是实打实可以照着配的操作。我自己在跑安全评测的时候总结了一套“低摩擦、高可复现”的桌面工作流不需要团队基础设施多强大一台开发机就能起步。这里的核心思路只有一个让你发布出去的任何结果都能被一台“干净的新电脑”复现出来。4.1 先锁环境容器和依赖管理是复现的起点复现失败最常见的原因不是算法而是环境不一致。你用的是PyTorch 2.0别人装了PyTorch 2.3数值可能就对不上你用了某个版本的Transformers库别人用新版可能Tokenize结果都变了。要解决这个问题第一件事就是把环境彻底固化。我的个人习惯是这样评估项目用Docker容器打包镜像内锁定Python版本、CUDA版本、依赖库的确切版本同时在仓库里维护一份requirements.txt和conda lock文件作为备份。评估跑完把镜像标签和commit哈希一并写进结果文件。这样别人拿到的不仅是一堆数字还包括“这组数字是在什么物理条件下生产出来的”这一关键信息。具体配置上推荐使用Dockerfile加固定版本标签。需要提醒的是镜像不要用latest标签一定要用不可变标签或镜像摘要sha256否则半年后你都不知道自己当时跑的是哪份环境。4.2 数据要有“指纹”用DVC或哈希管理数据血缘安全评测离不开数据集但数据集本身也必须纳入版本管理。我不建议把几十GB的数据硬塞进Git更推荐用DVCData Version Control这类数据版本管理工具或者至少对每个数据集文件生成一个哈希值记录下来。DVC的好处是它把数据和代码的版本关系绑定在一起。你可以做到——回退到某个代码commitDVC会自动把对应的数据集版本也拉下来整个实验状态完全可重建。这对评估复现来说太重要了因为很多评测结果差异的根源恰恰在于评测数据被悄无声息地更新过。如果团队暂时不想引入DVC那最低限度也要在评估报告里附上每个数据集的下载地址、版本号和SHA256。这样别人至少能确认“数据集没有中途被换过”。4.3 评估脚本和实验记录必须进版本库参数和种子一个都不能少评估脚本不像训练脚本那么受重视很多人觉得“就是跑个测试而已”。但它恰恰是复现实验最核心的组件。我的要求是评估脚本必须和模型权重、数据集、报告本身处于同一个版本体系下这意味着评估仓库和模型发布repo在逻辑上要能互相追踪。在实验记录方面我在跑评测时一定记录这几类信息模型权重文件的精确commit或hash所有关键超参数温度、top_k、max_tokens等、系统提示词原文随机种子和采样策略推理硬件、CUDA版本、推理框架版本评估脚本自身的commit ID。如果只是简单评测用MLflow或Weights Biases做追踪都可以不想引第三方工具也可以直接把这堆信息写进一个JSON文件和结果一起打入Git。关键是“有”而不在“用什么”。我见过太多报告连生成回答的temperature值都没写别人想复现只能靠猜。4.4 存档、DOI与分级发布别让成果只躺在GitHub上GitHub本身不是长期存档空间仓库被删或账号被封成果可能一夜蒸发。对需要沉淀的科学成果最好再推送到Zenodo、OSF这类支持版本化和分配DOI的开放存档平台。改了版本就发一个新版本DOI长期有效学术引用和复现追溯都有据可查。有安全顾虑的数据集或红队样例可以放在Hugging Face的gated仓库里设置申请审批机制。我记得HF上很多模型都用了这种模式访客可以看到模型卡和文件列表但下载权重需要审核。这套机制可以移植到安全评测数据集上把“开放可获取”和“受控访问”结合起来既保留可审计性又降低滥用风险。4.5 半自动生成模型卡让透明披露成为习惯前面提到模型卡很多人会觉得手写太麻烦。我建议写一个简单的脚本从评估结果JSON里自动提取关键字段填充到模板里再配一个README说明复现入口。模板里至少包含模型概况名称、版本、发布日期训练数据概述及其血缘性能指标分场景安全评估结果对应哪个基准、哪个版本、复现方式已知局限与推荐使用场景半自动化的意义在于它可以降低撰写模型卡的心理门槛。你不知道怎么写“安全评估”段落没关系先把评估命令、环境、结果表格自动贴进去至少让读者能顺着链接找到完整材料。等形成习惯了再逐步补充叙事性解释和定性分析。5. 从呼吁到行动个人、团队与行业的开放科学路线图5.1 个人研究者现在就能做的三件事不一定要等组织推动个人就能立刻开始。第一无论发什么安全评测结果随手附上一份“复现说明”哪怕只是十行字写明环境和运行命令也比光给结论强一百倍。第二把评估脚本纳入Git版本管理哪怕是个人项目养成“脚本和报告同版本”的习惯。第三多参与社区共建的评测基准比如贡献几条高质量的安全测试样例或者在公开评测集上跑出自己的结果并分享。判断标准很简单三个月后有人拿着你的报告来找你复现你还有没有足够的信息和工具让他顺利跑通如果答案是“不确定”那说明开放程度还不够。5.2 团队可以立即建立的机制团队层面我建议至少搭建五样东西一是统一的评测环境镜像Docker做到所有安全评估都在同一环境基线里跑二是预注册制度重大安全评估在动手前先写协议并打时间戳存档三是内部评估结果自动归档哪怕不公开也要保证可追溯四是安全评审脱敏公开机制把会议纪要中不涉及机密的结论定期公开五是定期请外部第三方参与红队或审计哪怕是NDA框架下的小规模外部视角也远好过完全自说自话。这些机制不需要大动干戈但需要有人对“安全评估的质量”负责。很多团队安全研究做得很多但最后连一份能被外界验证的报告都拿不出来这非常可惜。5.3 行业可以共建的公开基础设施最后说行业层面。单靠一两家公司很难撑起真正的开放科学社区。行业需要共建的基础设施包括可互认的安全评估基准库、面向安全研究的受控数据集交换平台、红队方法协作社区以及第三方安全评估机构的行业准则与认证机制。这几年已经有一些苗头。比如MLCommons在尝试制定AI安全基准HELM在推动多维度公开评测一些团队也在探索“模型评估共享”的模式让不同机构在保护各自商业机密的前提下共享安全评估证据。这些尝试还处在相当早期但方向我认为是对的。开放科学从来不是让所有人做一样的公开而是让所有参与者在一个共同认可的框架下尽量提高可复现、可审计、可比较的程度。AI安全领域的容错空间比普通产品小得多我们没资格一直基于不可复核的证据做高风险决策。最后分享一个我自己的习惯每次写完一份安全评估报告我会在提交前问自己一句——“如果明天这组结论被公开质疑我手里有没有一套完整材料能回应所有问题”如果答案是否定的就先别急着发结论把材料补齐再说。这既是对自己负责也是对那些依赖安全评估来做决策的人负责。希望这篇文章能让更多人开始用同样的标准要求自己让“开放科学”在AI安全里不再只是一个口号而成为每天都能落地的默认动作。