大模型安全基准测试有哪些

做安全评估最容易卡在一步：不知道手上这套基准到底测了什么，跑完也说不清结论能不能支撑上线决策。这篇把常见安全基准按考察维度拆开，讲清每类适合回答什么问题、什么情况下不适用，再给一套挑选与组合的动作清单。数字和榜单结果一律到站内对应页面核对。

做安全评估最容易卡在一步：不知道手上这套基准到底测了什么，跑完也说不清结论能不能支撑上线决策。很多人拿能力榜的思路套安全榜，看到分数高就放心，结果上线后才发现题目本身就把关键风险漏掉了。这篇不讲榜单结果，只按考察维度把常见安全基准拆开，讲清每类适合回答什么问题、什么情况下不适用。

数字和榜单结果一律到站内页面核对当时的快照。站内模型资料库和价格追踪页会记录各家的评测标注，具体分数、题量、更新时间以那些页面为准，这里只给判断方法和组合动作，避免拿一份过期报告做决策。

安全基准和能力基准测的根本不是一回事

能力基准问的是「会不会做」，安全基准问的是「什么条件下会做不该做的」。前者答对了就得分，后者守住了才得分，所以两者的分数不能直接比大小。同一条评测集，换一个提示模板、换一种语言，结论可能翻个面，这是对抗性质决定的，不是模型不稳定。

• 能力分数高不代表安全分数高，两者往往独立变化，甚至反向变化
• 安全评测的样本本身带攻击意图，评测集公开后容易被针对性优化
• 同一模型在不同提示模板下的通过率差异，通常比模型之间的差异还大
• 没有固定评测协议时，跑出来的数字只能当参考，不能写进上线结论

按考察维度分：六大类安全基准各自盯什么

市面上的安全基准可以按它盯的风险面归成六类。同一份报告里经常混着好几类，得分口径却不一样，读的时候先分清楚这条分数属于哪一类，再谈好坏。

注意过度拒答也是问题，尤其是第六类之外的场景。一个模型把所有敏感词都拒掉，有害内容那栏很好看，但正常业务请求被误伤，用户体验和客服工单会立刻反映出来。评估时建议把「拒答率」和「误拒率」放在一起看，只看单边数字容易被误导。

各类基准的组合关系

这六类不是并列选择，而是有优先级的：前两类决定能不能上线，中间两类决定能不能过合规，最后一类决定 Agent 产品能不能安全跑起来。具体哪家基准归哪类、覆盖哪些子项，到站内评测目录页核对当时收录的条目，再按自己业务路径挑。

挑基准的四个判断标准

选基准不是选最有名的那个，而是选和你威胁模型对得上的那个。下面四条按重要性排序，第一条不过关，后面几条基本不用看了。

1. 先对齐威胁模型你的场景是公开聊天、内部知识库还是能调工具的 Agent，选的基准要能覆盖这条路径。覆盖不到就直接换，别指望用别的类别补。
2. 再看题目是否饱和被各家刷到接近满分、且题目公开可查的基准，区分度已经很低。到站内评测目录页看当时的分布，如果头部模型挤在一起，这个基准对你就没用了。
3. 检查中文与本地合规覆盖只测英文语料的基准，对中文场景的误判率会明显偏高，尤其涉及监管红线表述时。优先选带中文子集或本地合规维度的。
4. 核对报告口径有没有说明采样次数、判分方式、置信区间。判分靠模型自评的要额外警惕，最好有交叉校验说明，否则分数波动可能来自判分器本身。

这四条里，第一条是硬门槛，后三条是加权项。如果时间有限，就按这个顺序砍：先保证威胁模型能覆盖，再去掉饱和的，再看语言和合规，最后才纠结报告口径。

怎么组合：不同评估目的的基准搭配

单独一份基准很难支撑完整决策，实际评估往往要组合。组合的原则是「每类风险至少有一条基准兜底」，而不是把所有能跑的都跑一遍，那样既费资源又难解释。

对于一家 5 人小团队，最省事的做法是先固定两三条核心基准，再自己攒一份几十题的领域题集。通用基准负责兜底，自建题集负责贴合业务，这样换模型时对比也简单。领域题集不用追求规模，覆盖你真实入口的几类提问就够。

读到一份安全评测报告，先看哪几行

很多人拿到报告直接翻结论页，其实前几行元信息更关键。下面这个阅读顺序能帮你快速判断这份报告值不值得采信，以及它到底能支撑哪种决策。

• 先看评测集构成与样本量：几百题和上万题的结论权重完全不是一个量级
• 再看判分方式：规则判分适合拒答类，人评适合偏见类，模型判分要有交叉校验说明
• 第三看是否标注了版本与时间：模型快照、评测脚本、提示模板任一变化都会影响可比性
• 最后看它没测什么：报告里缺失的维度，往往就是你业务里最可能出事的地方

这套顺序的好处是，前两条不过关就可以直接放下报告，不用往下读。如果一份报告只给总分、不给评测集构成和判分方式，那它更适合当宣传材料，不适合当评估输入。

报告里没写的维度，通常比你看到的分数更值得追问。

自己跑一遍的排查顺序

如果决定自己跑，最容易出的问题不是模型不行，而是评测链路本身有 bug，把正常请求判成了安全失败，或者把判分器的锅算到模型头上。按下面四步走能挡掉大部分低级错误。

1. 固定变量把模型快照、提示模板、温度、采样次数全部写进评测记录。任何一项变了，前后结果就不可比。
2. 小样本试跑先跑几十题，确认判分链路通，并检查有没有把正常请求误判成安全失败。这一步能省下后面重新跑一遍的时间。
3. 看分布不看总分哪些类别集体掉分，比一个平均分有用得多。类别间的差异往往指向具体的安全策略问题。
4. 复现异常把失败样本单独抽出来人工看，区分真绕过和判分误差。真绕过要记进回归集，判分误差要修判分规则。

跑完之后建议把这次用到的评测集、提示模板和判分规则存档，下次换模型时直接复用同一套，前后对比才有意义。站内工具目录里有评测链路的辅助工具，可以按需挑。

安全基准测不出来的东西

最后说清楚边界，避免把基准结果当成万能结论。安全基准测的是模型在特定协议下对特定题目的表现，它测不出部署层面的问题，也测不出你的业务语义。

• 测不出长周期累积风险：单轮拒答率好看，多轮诱导下未必守得住
• 测不出部署层面问题：密钥管理、日志脱敏、权限隔离不在模型基准范围内
• 测不出你的业务语义：垂直领域里的「有害」定义和通用基准往往不一致，需要自建小规模领域题集
• 基准结果不能当合规结论用，只能作为评估输入之一

哪些情况要特别小心：如果业务涉及强监管领域，或者模型能访问内部数据、能对外发请求，那模型基准只是一小部分，权限设计和审计日志的重要性往往更高。这类场景建议把基准结果和架构评审放在一起看，而不是互相替代。