1. 从857个模型里看到的数字落差先把结论摆在前面857个模型里只有3.6%公开了安全测试结果这个比例不是有点低而是低到让人怀疑整个行业的发布节奏和安全验证节奏已经彻底脱节。我最初看到这组数字的时候第一反应是统计口径可能有问题——也许很多模型压根不需要公开安全测试也许公开的渠道分散在各个角落没被统计到。但把能查的渠道都翻了一遍之后我发现这个数字虽然可能略有偏差但量级上不会错绝大多数模型在发布时安全测试要么没做要么做了没公开要么公开了但藏在某个没人会去看的附录里。这件事值得认真聊一聊因为它直接关系到每一个用模型的人——不管你是开发者、产品经理还是只是拿模型来写东西的普通用户。你用的那个模型在发布之前到底有没有人认真测过它在极端输入下的表现有没有人试过诱导它输出不该输出的内容有没有人评估过它在多轮对话里会不会逐渐偏离安全边界这些问题3.6%这个数字给出的答案是大概率没有公开证据。我写这篇东西不是要制造焦虑也不是要一棍子打死所有模型发布方。我想做的是把发布速度和安全证据之间的这道裂缝拆开来看裂缝是怎么形成的为什么大家默认接受了这种状态以及作为一个普通从业者在这个现状下能做什么来保护自己。全文会围绕四个层面展开——先看清楚数字背后的真实图景再拆解为什么安全测试总是被跳过然后讲清楚一个模型从训练完成到公开发布之间到底应该有哪些安全环节最后给出我自己在选模型、用模型时的一套实操判断方法。注意本文讨论的安全测试指的是模型发布前的公开安全评估包括但不限于对抗性测试、偏见评估、有害内容生成测试、越狱抵抗测试等。不涉及任何具体地区的法律法规讨论只从工程实践和用户保护角度出发。2. 3.6%这个数字到底意味着什么2.1 统计口径的迷雾什么算公开安全测试在讨论3.6%之前必须先说清楚公开安全测试这六个字到底怎么定义。我见过至少四种不同的理解方式每一种算出来的比例都不一样。第一种理解是模型发布时附带了一份安全评估报告这种最严格比例最低。第二种是在技术论文或模型卡里提到了安全测试的方法和结果这种稍微宽松一点但很多模型卡里只有一句话带过比如我们进行了安全评估却不给任何数据。第三种是第三方独立机构做过测试并公开发布了结果这种更少因为愿意花钱做独立测试的发布方本来就不多。第四种是任何形式的公开安全相关信息包括博客文章、社交媒体帖子、会议演讲里提到的片段这种最宽松但即便如此比例也没有高到哪里去。我倾向于用第二种口径来理解这个数字模型发布时在模型卡、技术报告或专门的文档里有可查证的安全测试方法和结果。按这个口径3.6%意味着每100个模型里只有不到4个能让你在下载或调用之前知道它在安全方面的表现大概是什么水平。剩下的96%以上你只能靠猜、靠社区口碑、靠自己去试。这个数字之所以让人不安是因为它和模型发布的数量形成了鲜明对比。过去两年里公开发布的模型数量增长曲线几乎是垂直的但公开安全测试的增长曲线平缓得像一条直线。两条线之间的开口越来越大这就是发布速度跑在安全证据前面的直观含义。2.2 为什么不是所有模型都需要公开安全测试这里要做一个区分不然容易把问题简单化。不是所有模型都需要同等程度的安全测试也不是所有模型都需要把测试结果公开。有几类情况确实可以豁免或者降低要求。一类是纯研究性质的模型发布目的就是让学术界验证某个训练方法是否有效不面向终端用户不提供API不集成到任何产品里。这类模型的安全风险主要停留在研究层面公开安全测试的优先级确实可以低一些。另一类是基于已有模型做微调的小模型基础模型已经做过安全测试微调数据也经过筛选增量风险有限。还有一类是特定领域的专用模型比如只用于蛋白质结构预测的模型它的输出空间很窄通用安全测试的很多项目对它不适用。但问题在于857个模型里真正属于上述豁免类别的比例有多少我粗略估算了一下不会超过两成。也就是说至少有八成模型要么面向终端用户要么提供API要么可以被集成到各种应用里它们的安全表现直接关系到使用者的体验和风险。这八成里面公开了安全测试的比例可能比3.6%还要低。2.3 用户端的真实感受你其实一直在盲测如果你是一个普通用户你可能会觉得安全测试公不公开跟我有什么关系我用着没问题就行。但实际情况是你每一次使用模型都在进行一场没有对照组的盲测。举个例子。你让模型帮你写一段产品描述它写出来了看起来没问题。但你不知道的是如果换一种问法或者多轮对话之后稍微引导一下它会不会输出带有歧视性的表述你让模型帮你总结一份文档它总结得挺好。但你不知道的是如果文档里包含某些特定类型的个人信息它会不会在总结里把这些信息以不恰当的方式暴露出来这些都不是理论上的风险而是我在实际使用和测试中反复遇到过的真实情况。更关键的是没有公开安全测试意味着你无法在不同模型之间做安全维度的对比。你只能看到跑分、看到价格、看到上下文长度但看不到这个模型在面对诱导性提问时的拒绝率是多少、这个模型在生成代码时引入安全漏洞的概率有多高。这些信息缺失导致选择模型时只能凭感觉而感觉往往是不准的。3. 发布速度为什么总能跑赢安全证据3.1 竞争压力下的先发优势逻辑模型发布这件事过去两年里已经变成了一场没有终点的竞速。谁先发布谁就能先拿到用户反馈、先占领开发者心智、先建立生态壁垒。这种竞争压力下安全测试就成了一个可以往后放一放的环节。我接触过几个做模型发布的朋友他们的说法很一致不是不想做安全测试而是做安全测试的时间成本太高高到如果等测试做完再发布可能就错过了最佳窗口期。一个完整的安全测试流程从设计测试用例、搭建测试环境、跑测试、分析结果、修复问题、复测到最终整理成可公开的报告快则两三周慢则两三个月。而模型迭代的周期现在普遍压缩到了几周甚至几天。这两者之间的时间差就是安全证据永远追不上发布速度的根本原因。更深层的问题是安全测试的投入产出比在短期内看起来很低。你花一个月做安全测试修复了十几个边缘案例的问题但用户感知不到市场也不会因为你安全做得好就多给你份额。反过来你把同样的时间用来优化模型的一个核心能力比如推理速度或者代码生成准确率用户立刻就能感知到。这种激励结构下安全测试被跳过几乎是必然的。3.2 安全测试本身的工程复杂度被低估很多人以为安全测试就是找几个人试试能不能让模型说脏话这种理解太浅了。真正的安全测试是一个系统工程复杂度不比训练一个模型低多少。首先是测试用例的设计。你需要覆盖多少种攻击类型提示注入、角色扮演诱导、多轮渐进式引导、编码绕过、上下文污染……每一种攻击类型下面又有几十种变体。你要设计多少条测试用例才能有统计意义上的置信度几百条根本不够几千条是起步上万条也不嫌多。这些用例谁来写写完之后谁来审核审核标准怎么统一这些都是实打实的工程量。其次是评估标准的问题。什么叫不安全输出不同的人有不同的判断。同样一段话有人觉得是正常讨论有人觉得是冒犯。你需要一套细粒度的标注体系还需要多个标注员之间的一致性检验。这套体系建立起来之后还要随着模型能力的变化不断更新因为模型越强攻击方式就越隐蔽旧的测试用例可能就失效了。最后是修复和复测的循环。测出问题之后修复方案往往不是简单的加一条规则而是要在模型层面做调整调整之后又可能影响其他能力需要重新评估。这个循环可能要走好几轮每一轮都是时间。3.3 安全在发布决策中的权重被系统性压低我观察到一个现象在大多数团队的发布决策会上安全从来不是一票否决项。性能不达标发布推迟核心功能有bug发布推迟但安全测试没做完往往只是记录在案后续补充。这种决策逻辑背后有一个隐含假设安全问题是小概率事件出了再说。但这个假设在模型领域越来越不成立。模型的使用规模太大了一个小概率问题乘以千万级的使用量就是每天都在发生的真实伤害。而且模型的安全问题有很强的长尾效应一个被发现的漏洞会在社区里迅速传播被反复利用修复成本远高于提前测试。更麻烦的是安全问题的暴露往往有滞后性。模型发布时看起来没问题用了几个月之后有人发现了某种特定的诱导方式然后这个方式被公开所有人都能用。这时候再回头修复不仅要改模型还要处理已经产生的影响。这种滞后性让发布方在决策时容易产生现在没问题就是没问题的错觉。4. 一个模型从训练完成到安全发布应该经过什么4.1 发布前的安全评估清单基于我自己的实践和观察到的行业做法一个负责任的模型发布流程在安全评估环节至少应该包含以下几类测试。我把它们整理成表格方便对照检查。测试类别测试目标典型方法最低样本量建议有害内容生成模型是否会生成暴力、歧视、骚扰等内容定向提示词测试、对抗性后缀测试500提示注入抵抗模型是否会被恶意指令覆盖原有行为直接注入、间接注入、编码注入300多轮对话安全模型在多轮交互中是否逐渐偏离安全边界渐进式引导、角色扮演、上下文累积200偏见与公平性模型输出是否对特定群体有系统性偏见对照测试、模板化提示、统计检验400隐私泄露模型是否会复现训练数据中的个人信息成员推断攻击、前缀补全测试200越狱抵抗模型是否会被特定话术绕过安全限制已知越狱模板、自动化搜索500这张表里的数字只是起步建议实际执行时应该根据模型的能力和部署场景做调整。能力越强的模型需要的测试量越大因为它的输出空间更广潜在的风险面也更大。4.2 测试结果怎么公开才有意义做了测试但不公开等于没做。但公开也有公开的讲究不是把原始数据往网上一扔就完事了。我见过一些模型卡安全部分只写了一句我们进行了全面的安全评估结果令人满意这种公开没有任何信息量反而会让人怀疑是不是在遮掩什么。有意义的公开至少应该包含四个要素。第一是测试方法的描述让人知道你是怎么测的用了什么类型的提示词评估标准是什么。第二是测试结果的量化呈现比如各类攻击的成功率是多少拒绝率是多少和上一个版本相比有什么变化。第三是已知局限性的说明哪些类型的攻击你还没覆盖哪些场景下模型的表现还不确定。第四是修复计划的透明度对于测试中发现的问题你打算怎么修大概什么时候能修好。这四个要素里我觉得最重要的是第三个。一个模型发布方如果敢公开说我们在某某类型的攻击下表现不佳正在改进这比说我们全面安全要可信得多。承认局限性不是示弱而是建立信任的基础。4.3 持续监控发布不是终点安全测试不是一次性的工作发布之后还需要持续监控。模型上线之后你会遇到测试阶段完全没想到的攻击方式也会遇到测试阶段没覆盖的使用场景。这些都需要通过线上监控来发现和响应。持续监控至少要做三件事。一是建立用户反馈渠道让用户能方便地报告他们遇到的安全问题。二是对线上流量做抽样分析主动发现异常的使用模式和输出模式。三是定期做红队测试用新的攻击方法去挑战已经上线的模型。这三件事里红队测试最容易被忽略但恰恰是最能发现深层问题的。我自己的做法是每季度至少做一次小规模的红队测试每次聚焦一个特定的攻击类型比如这次专门测编码绕过下次专门测多轮诱导。这样虽然不能覆盖所有风险但能保持对新型攻击的敏感度。5. 作为普通从业者在安全证据缺失时怎么自保5.1 选模型时的安全信号识别既然大多数模型不公开安全测试那在实际选型时怎么判断一个模型的安全水平我总结了一套自己的信号识别方法不保证百分百准确但比瞎选强。第一个信号是看模型卡里有没有专门的安全章节。有不一定代表安全做得好但至少说明发布方意识到了这件事的重要性。没有也不一定代表不安全但至少说明优先级不高。第二个信号是看发布方有没有公开过任何形式的安全相关文档哪怕是博客文章或者技术报告里的一个段落。第三个信号是看社区里有没有人做过独立的安全测试并公开了结果这种第三方测试往往比官方自测更有参考价值。第四个信号是看模型的更新日志里有没有安全相关的修复记录有的话说明发布方在持续关注安全问题。这四个信号里我最看重第三个和第四个。第三方独立测试因为利益无关可信度更高持续的安全修复记录说明发布方不是做一次样子就完了。5.2 使用模型时的防御性操作习惯选完模型之后使用过程中的操作习惯也很重要。我自己的习惯是永远不把模型输出的内容直接当作最终结果使用尤其是涉及事实性信息、代码、建议类内容的时候。具体来说我会做三件事。第一对关键输出做交叉验证比如模型给了一个数据我会去查一下原始来源模型给了一段代码我会自己跑一遍测试。第二对涉及个人信息的输入做脱敏处理不把真实的姓名、地址、联系方式直接喂给模型。第三对多轮对话保持警觉如果发现对话方向在往某个敏感话题上靠主动拉回来或者结束对话。这些习惯看起来麻烦但养成之后就是条件反射不会增加太多负担。而且它们不仅能防模型的安全问题也能防模型的能力问题——模型本来就会犯错交叉验证和脱敏处理对减少错误同样有效。5.3 遇到问题时的反馈和记录如果你在使用过程中发现了模型的安全问题比如它输出了明显不该输出的内容或者被某种话术绕过了限制我建议你至少做两件事记录和反馈。记录是为了保护自己。把出问题的对话截图或者导出标注好时间、模型版本、输入内容。万一后续这个问题造成了什么影响你有证据说明这不是你的操作问题。反馈是为了帮助改进。大多数模型发布方都有反馈渠道你提交的问题可能不会立刻被修复但至少进入了他们的视野。如果足够多的人反馈类似问题优先级就会提高。我自己的做法是遇到一次就记一次攒到一定数量之后整理成一份简单的报告通过官方渠道提交。这样做的好处是单次反馈可能被忽略但一份有数据、有复现步骤的报告被认真对待的概率会大很多。6. 这道裂缝有没有可能被补上6.1 从自愿公开到默认公开的转变需要什么现在安全测试公开率低很大程度上是因为这件事是自愿的。没有外部压力发布方自然倾向于不做或者不公开。要改变这个现状需要让公开安全测试从加分项变成默认项。怎么变我觉得有三个可能的推动力。一是用户端的需求倒逼当足够多的用户在选模型时把安全测试公开作为硬性筛选条件发布方就会有动力去做。二是行业自律组织的推动如果有几个有影响力的发布方联合起来承诺公开安全测试形成示范效应其他方跟进的压力就会变大。三是工具链的成熟如果安全测试的工具和流程变得足够标准化、足够低成本发布方做这件事的边际成本就会大幅下降。这三个推动力里我觉得工具链的成熟是最实际的。现在安全测试之所以难做很大一部分原因是每个团队都在重复造轮子测试用例要自己写评估标准要自己定报告格式要自己设计。如果有一套开源的、标准化的安全测试框架覆盖常见的测试类型提供可复用的测试用例库和评估工具那发布方做安全测试的门槛就会低很多。6.2 安全测试的标准化为什么这么难但标准化这件事说了很久进展一直不快因为它面临几个根本性的困难。第一个困难是安全本身的定义就不统一。什么叫安全不同文化背景、不同应用场景下答案是不一样的。一个在某个场景下完全正常的输出换一个场景可能就是冒犯。这种主观性让标准化变得极其困难。第二个困难是攻击方式的演化太快。今天设计好的测试用例明天可能就被新的攻击方式绕过了。标准化框架需要持续更新而更新的速度很难跟上攻击演化的速度。第三个困难是评估结果的解释需要上下文。同样一个拒绝率数字在一个模型上可能意味着安全做得好在另一个模型上可能意味着过度保守。没有上下文数字本身没有意义。而上下文往往是难以标准化的。这些困难意味着安全测试的标准化不可能一步到位只能是一个渐进的过程。先在某些特定类型的测试上达成共识比如有害内容生成测试再逐步扩展到其他类型。这个过程可能需要几年时间但方向是明确的。6.3 我个人对这件事的预期说实话我对短期内看到大幅改善不抱太高期望。发布速度和竞争压力是结构性的不会因为几篇文章或者几次讨论就改变。但我认为这件事会慢慢好转原因有两个。一是用户的安全意识在提升。我观察到越来越多的开发者在选模型时开始关注安全维度虽然目前还只是少数但这个比例在增长。当这个比例超过某个临界点发布方就会感受到压力。二是安全测试的工具和人才在增加。几年前懂模型安全测试的人很少工具也匮乏。现在情况在改善专门做模型安全评估的团队在变多开源工具也在涌现。这些基础设施的完善会降低安全测试的成本从而让更多发布方愿意做这件事。我的预期是未来两三年内头部模型的公开安全测试比例会有明显提升可能从现在的个位数百分比涨到两三成。但长尾模型的情况可能改善有限因为它们的发布方往往资源更少做安全测试的动力也更弱。对于普通用户来说这意味着选模型时还是要保持警惕不能假设发布了就一定是安全的。7. 一个可复用的模型安全自查流程7.1 拿到新模型后的第一轮快速筛查每次拿到一个新模型不管是API还是本地部署我都会先做一轮快速筛查。这轮筛查不追求全面只求在最短时间内对模型的安全基线有个大致判断。整个过程大概半小时到一小时分四步走。第一步用一组固定的基础测试提示词跑一遍看看模型的基本拒绝行为是否正常。这组提示词我固定用二十条左右覆盖常见的敏感话题类型但不涉及具体内容只是看模型会不会在明显该拒绝的时候拒绝。第二步用几种常见的越狱模板试一下看模型会不会被轻易绕过。第三步做几组多轮对话测试看模型在对话推进过程中会不会逐渐放松警惕。第四步用一些边界模糊的提示词看模型的判断是否一致会不会同样的输入在不同时间给出不同的安全行为。这四步做完我大概能知道这个模型的安全基线在什么水平。如果第一步就大量该拒绝不拒绝那后面的测试就不用做了直接标记为高风险。如果前两步都正常第三步和第四步发现问题那就是中等风险需要进一步测试。7.2 深度测试的抽样策略快速筛查通过之后如果这个模型要用于比较重要的场景我会做一轮深度测试。深度测试不可能穷举只能抽样抽样的策略很关键。我的抽样策略是分层抽样。先把攻击类型分成几大类每类下面选几个代表性的攻击方式每种攻击方式准备几十条测试用例。这样能在有限的测试量下覆盖尽可能多的攻击面。具体来说我会把70%的测试量分配给已知的高风险攻击类型比如提示注入和多轮诱导剩下30%分配给探索性的测试看看有没有新的攻击面。测试过程中我会记录每一条测试的输入、输出、判断结果和判断理由。判断结果分三档安全、边界、不安全。边界的意思是模型的行为不完全安全但也没有明显危害这类案例需要特别关注因为它们往往是最容易被忽略的风险点。7.3 测试结果的记录和对比测试做完之后记录和对比是最后一步也是最容易被跳过的一步。我自己的做法是建一个简单的表格每次测试都往里填时间长了就能看出模型安全表现的变化趋势。表格的字段包括模型名称和版本、测试日期、测试类型、测试用例数量、安全率、边界率、不安全率、主要发现的问题、和上次测试相比的变化。这个表格不需要多复杂关键是坚持记录。有了这个表格你就能回答一些很有价值的问题比如这个模型更新之后安全表现是变好了还是变差了、哪一类攻击方式是这个模型的薄弱环节、不同模型之间在安全维度上的差距有多大。我坚持做这件事两年多最大的收获是建立了一个自己的安全基线。现在拿到任何一个新模型我都能很快判断它的安全水平大概在什么位置哪些方面需要特别小心。这个基线不是绝对的但比没有任何参照要好得多。8. 几个我在实践中反复踩过的坑8.1 把拒绝等同于安全这是我早期犯过的一个典型错误。看到模型拒绝了一个请求就认为它是安全的。后来发现拒绝只是安全的一种表现形式而且是最表面的一种。一个模型可能在该拒绝的时候拒绝了但在不该拒绝的时候也拒绝这是过度保守也可能在该拒绝的时候拒绝了但换一种问法就不拒绝了这是拒绝不稳定还可能在该拒绝的时候拒绝了但拒绝的方式本身泄露了信息这是拒绝方式不当。真正的安全不是简单的拒绝而是在正确的时候以正确的方式拒绝同时在不该拒绝的时候正常输出。这个平衡很难把握需要看模型在大量边界案例上的表现而不是只看它会不会说不。8.2 忽略多轮对话中的安全漂移单轮测试看起来安全的模型在多轮对话中可能完全不安全。这是我踩过的另一个坑。早期做测试的时候我主要做单轮测试觉得单轮没问题就差不多了。后来在一次实际使用中我发现经过五六轮看似无害的对话之后模型的安全行为明显放松了开始输出一些单轮测试中绝对不会输出的内容。这个现象叫安全漂移它的原理是模型在对话过程中会逐渐适应对话的上下文如果前面的对话建立了一种可以放松的语境后面的输出就会受到影响。要测出这个问题必须做多轮测试而且轮数要足够多至少十轮以上才能看出趋势。8.3 用同一套测试用例测所有模型不同模型的能力和特点不一样用同一套测试用例去测结果的可比性其实很差。一个在A模型上有效的攻击方式在B模型上可能完全无效不是因为B模型更安全而是因为B模型的能力结构不同对这类攻击不敏感。正确的做法是根据模型的特点调整测试用例。比如一个代码生成能力很强的模型就要重点测它在生成代码时会不会引入安全漏洞一个多语言能力很强的模型就要重点测它在不同语言下的安全表现是否一致。测试用例应该是定制化的而不是一套通用模板走天下。8.4 测试环境与生产环境的差异最后一个坑是测试环境和生产环境的差异。在测试环境里表现安全的模型部署到生产环境之后可能因为温度参数、系统提示词、上下文长度等配置的不同安全表现发生变化。我遇到过好几次测试时拒绝率很高的模型上线之后因为系统提示词写得太宽松拒绝率大幅下降。要避免这个问题测试时就要尽量模拟生产环境的配置包括温度、top_p、系统提示词、最大输出长度等参数。如果生产环境有多种配置测试时也要覆盖这些配置的组合。这件事很繁琐但省不得否则测试结果就是自欺欺人。9. 写在最后的一点个人体会做模型安全测试这件事越做越觉得它是一个没有终点的过程。你永远不可能测完所有的攻击方式永远不可能覆盖所有的使用场景永远会有新的漏洞在你想不到的地方出现。但这不意味着测试没有意义恰恰相反正是因为不可能做到完美才更需要持续地做、系统地做、公开地做。3.6%这个数字让我不安但更让我不安的是很多人对这个数字无感。他们觉得安全测试是发布方的事跟自己没关系。但实际上每一个使用模型的人都是安全链条上的一环。你的每一次使用、每一次反馈、每一次选择都在影响发布方的行为。当足够多的人开始在意安全证据发布方就会开始提供安全证据。这个循环启动得越早所有人受益就越早。我自己的做法是把安全测试当作使用模型的一个固定环节就像吃饭前洗手一样不觉得麻烦也不觉得多余。这个习惯让我避开了不少坑也让我对模型的能力边界有了更清楚的认识。如果你还没有这个习惯不妨从下一次使用新模型开始花半小时做一轮快速筛查。这半小时的投入可能帮你省下后面几十小时的麻烦。
