做合规或安全岗的人，最近大概率会遇到同一类问题：监管或客户提到「安全评测」时，到底测什么、按什么标准判、自研或引入的模型要不要过一遍，谁也说不清。站里介绍这类评测中心时也常只给一句上线消息。这篇不转述公告，而是把评测中心的角色定位、常见考查维度、以及你要准备的材料清单拆开讲，让你能直接对着做一次内部盘点。
做合规或安全岗的人最近大概率会遇到同一类问题：监管或客户提到「安全评测」时，到底测什么、按什么标准判、自研或引入的模型要不要过一遍，谁也说不清。站里介绍这类评测中心时也常只给一句上线消息。这篇不转述公告，而是把评测中心的角色定位、常见考查维度、以及你要准备的材料清单拆开讲，让你能直接对着做一次内部盘点。
先说清一个前提：下面所有「测什么、怎么判」的说法都是判断框架，不是固定标准。真正的考查项、判定口径和申报材料要求会随规则调整，动手前一律以站内 /safety 页面的当期说明为准；价格类、算力类的信息也不要在这篇里找，去站内对应页面核对当时的数字。
先搞清评测中心是干什么的，别把它当成排行榜
评测中心管的是「底线与风险」，看的是模型在特定输入下会不会输出不该输出的内容、会不会被绕过，能力高低不是它的主要判断对象。想比能力、看横向表现，应该去看 /benchmarks 与 /rankings 这类页面，两件事别混在一个清单里。
- 备案/申报方
- 关心材料是否齐全、结论能否直接用于合规申报，重点在可复现的证据链
- 采购方
- 关心候选模型之间的安全表现差异，以及供应商声明能否落到自己的业务流程
- 自建并对外提供服务方
- 关心模型本体加外围系统整体的抗绕过能力，以及出了问题能否追查
不是所有模型都必须送评测。只看公开榜单选型、且不涉及对外提供服务或敏感数据的场景，多数时候用不上；一旦涉及面向公众输出、行业监管要求或客户尽调，就绕不开。判断顺序建议是：先确认有没有对外输出和敏感数据，再看监管或客户有没有明确要求，最后才考虑主动送评要不要做。
安全与合规的术语边界容易混，官方文件里的名词含糊时，先去 /ai-dict/category/safety 对一遍词，再决定要不要送评。词没对齐就备料，最后往往要在材料上返工。
测评通常覆盖哪几层：模型、系统、还是业务流程
最常被忽略的是「模型本体测评」和「系统级测评」的区别。前者只看模型输出，后者还包含输入过滤、输出审核、权限控制、日志与人工兜底。很多团队只测了前者就以为交差了，等到系统级考查才发现缺项。
| 考查层 | 典型看什么 | 容易漏的点 |
|---|---|---|
| 模型本体 | 特定输入下会不会输出不该输出的内容、能否被诱导绕过 | 只测单轮，不测多轮绕圈和改写伪装 |
| 系统边界 | 越权访问、提示词注入后的行为变化、异常输出能否被拦截 | 过滤规则只做单向，输出侧不复查 |
| 数据链路 | 敏感信息在日志、缓存、会话记录里的残留 | 留存可追溯日志但没做访问权限收口 |
| 行业场景 | 医疗、金融、法律等建议性输出的免责边界 | 通用用例套用，缺少本行业场景化输入 |
行业场景会额外加考，通用评测项未必覆盖。比如涉及建议性输出的领域，更关注措辞边界和免责提示，需要单独准备场景化用例，不能指望通用清单兜住。
送评前自己要做的四步自检
- 第一步：定范围把要送评的模型版本、部署形态（接口调用还是私有化）、对外暴露的入口列成一张表，核对送评版本和上线版本是不是同一个，避免结论对不上实际服务。
- 第二步：搭用例按「明显违规询问、伪装改写、逐步诱导、多轮绕圈」四类各准备一批测试输入，人工跑一遍并记录实际输出，不要只看厂商给的安全声明。
- 第三步：补系统侧确认有没有输入输出双向过滤、有没有留存可追溯日志、异常输出有没有人工复核通道。这三项缺失是系统级评测里最常见的失分点，也是最容易提前补上的。
- 第四步：留证据把用例、跑测记录、拦截结果整理成可复现的材料。评测或客户尽调时，这比口头描述有效得多，也能省掉反复补料的来回。
- 送评前先冻结版本，别在跑评测的同时还在改提示词
- 用例脚本和跑测记录存同一处，标注清楚跑测环境
- 系统侧改动（过滤规则、权限、日志）要和模型版本一起记录
- 材料里写清评测对象与范围，别让单点结论被当成整条业务线的背书
哪些情况不适合走这条路
这条路径并非人人适用，判断时看清边界，能省下大量无效工作量。下面几种情况，完整评测的性价比通常不高，或者时机不对。
- 只是内部做实验、不对外提供服务、也不接触个人信息或行业敏感数据，通常没必要跑完整评测评测，做基本的输出审核即可
- 模型还在频繁迭代、每周都换版本时，先稳定版本再送评，否则结论很快失效，还会在合规材料里留下对不上的版本记录
- 把评测当成一次性通过就万事大吉是误判，它更像体检，规则或模型变了都要补做，建议把用例和跑测脚本沉淀下来下次复用
- 上游厂商声明已通过某些安全评测，不等于你的系统也合规，中间层、接入方式、业务提示词都会改变实际表现，这一条要单独验证
如果暂时不送评，也不等于可以什么都不做。至少保证有基本的输入输出审核、有异常情况的记录和处置流程，等到要送评或客户尽调时，这些记录就是现成的底料。
上线之后怎么持续跟住
安全评测不是拿一张结论就收工。把安全用例纳入日常回归：模型换代、提示词改动、过滤规则调整后都跑一遍，避免只在首次上线做过一次，之后就成了过期材料。
| 触发事件 | 要做什么 | 验证方式 |
|---|---|---|
| 模型换代或换快照 | 重跑安全用例集 | 对比新旧版本的实际输出差异 |
| 提示词或过滤规则调整 | 重跑被影响的那几类用例 | 确认拦截行为没有回退 |
| 服务可用性异常 | 先查接入通道和模型快照有没有变 | 比对线上行为与评测结论是否一致 |
| 行业规则更新 | 回 /safety 页面看当期要求 | 确认现有材料是否要补充 |
盯住服务可用性与响应口径的变化。评测结论和实际线上行为不一致时，先查是不是换了接入通道或模型快照，再考虑是不是模型本身的问题，排查顺序别反了。
评测结论只对评测过的那个对象、那个范围、那个时间点负责。
对外材料里引用评测结论时，写清评测对象、范围与时间口径。行业规则和评测要求会更新，定期回 /safety 页面看当期要求，比到处搜二手解读靠谱得多。
下一步先把你要送评的对象和现有安全措施列成一张表，再对着当期要求勾缺项，比直接问服务商更省时间。→常见问题
大模型安全评测中心上线，是不是意味着所有大模型都要送评？
不是。是否必须送评取决于你的使用场景和适用的监管要求：面向公众提供服务、涉及行业敏感数据或客户尽调，通常需要；纯内部实验、不对外输出也不碰敏感数据，多数情况没必要专门跑完整评测。具体口径建议对照 /safety 的当期说明，别只按网上的二手解读判断。
安全测评没过，是不是模型就不能用了？
要分清是模型本体不达标还是系统层缺失。很多失分点在输入输出过滤、日志留存、人工兜底这些工程环节，补上之后重测往往能过。真正卡在模型本身输出边界的，可以考虑加一层审核、限定使用场景或换模型。先拿到具体不达标项，再决定改哪里，别一上来就换模型。
厂商说自己的模型已经通过安全评测，我还需要自己做吗？
需要，但可以省一部分。厂商结论通常只覆盖模型本体和特定调用方式，你自己的系统提示词、接入层、权限设计和业务数据都会改变实际表现。建议保留厂商材料作为参考，重点自测提示词注入、越权访问和敏感信息残留这几项，再看 /safety 的当期要求补齐。
