Blog · · Updated · By Dhrumil Barot, Founder
使用去审查（abliteration）模型开展红队测试：面向防御方的 Safe-Bench 方法论
对抗性测试需要愿意参与测试的模型。本方法论涵盖授权范围、测试框架构建、测试套件选择、严谨评分，以及经得起审查的报告。
这份关于对已移除拒答限制模型开展红队测试的指南，是为需要可重复证据而非戏剧化演示的防御者编写的 LLM 红队测试方法论。对抗性测试需要愿意参与测试的模型。对齐模型可能拒绝 prompt、不直接回答反而说教，或出现不一致的配合，这会让结果难以复现、覆盖范围难以衡量。已移除拒答限制模型能通过更直接地响应高难度 prompt 来缓解这一测量问题，但它们本身并不能保证输出正确、可安全部署或合法。本方法论涵盖授权、测试框架构建、测试套件选择、评分、报告和审查。
本文所有内容均以合法、经授权的测试为前提。只测试你拥有或获授权评估的系统和数据。无论使用何种模型，禁止类别始终不变：对未成年人的剥削、人口贩运和非自愿内容均不得纳入任何测试框架。模型选择是范围文档中的一项测量决策，并不意味着可以扩大范围。
LLM 红队测试方法论：以书面形式界定授权范围
在运行任何 prompt 前，先编写范围文档。它应明确受测系统、测试窗口、允许的技术手段、数据处理规则，以及能够叫停演练的紧急联系人。测试团队和系统所有者都要签署该文档。它将红队演练与安全事件区分开来，之后的每一步都应以它为依据。
范围还应限定模型边界。列出本次演练可调用的精确模型 ID 和端点，例如具有公开谱系的托管无审查配置，并禁止使用其余一切。限定模型清单可确保发现结果可归因：每项结果都能追溯到具名权重和端点，而不是当天午后碰巧顺手的某个模型。
在收集 prompt 前先设定数据边界。明确 prompt 是否可包含源代码、机密信息、客户数据、生产环境标识符或合成替代品。说明输出存储在哪里、谁可以审查、保留多久，以及紧急发现如何送达系统所有者。这些控制与 prompt 清单同样重要，因为即使模型从未接触生产环境，一次评测也可能引发数据处理事件。
对已移除拒答限制模型开展红队测试：先构建测试框架，再编写 prompt
测试框架是一条固定流水线：prompt 集、固定解码参数、输出捕获、自动评分和人工抽查。首次运行前，应将每类 prompt 的 temperature 固定为 0.2，并固定最大 token 数，因为参数漂移会使跨周比较失效。捕获完整输出及其时间戳、模型 ID、端点版本和 prompt 哈希，以便重放任何发现。
Use the open reproduction script from our uncensored LLM leaderboard as the harness core. It is described as sending behavior prompts to an OpenAI-compatible endpoint and recording compliance versus refusal with prefix matching, then dumping machine-readable results. Extend it with proprietary prompt sets behind your own access controls. The proprietary prompts should stay inside your environment, while the methodology remains stable enough to compare across quarters.
参考工具的验证可来自包含测试细节记录的已发布消融实验，例如huihui-ai/Qwen3-8B-abliterated，其列表引用的数据为 320 次中 320 次配合；以及Heretic Qwen3-4B 报告，引用数据为每 100 次 3 次拒答，KL 散度为 0.072。应将这些数值归因于所链接的报告。它们验证的是已有公开的测试工具，而非你的模型或 prompt 集必然产生相同结果。
对已移除拒答限制模型开展红队测试：针对不同问题选择测试套件
应运行三套测试，因为它们回答的问题不同。第一套是有害行为配合测试套件，用来衡量模型是否会参与高难度 prompt；它可验证消融或低拒答配置是否改变了行为。第二套是过度拒答测试套件，例如 XSTest，用来衡量模型是否仍能谨慎处理良性但棘手的 prompt；仅当其范围和许可适合你的评测时才使用。第三套是任务专用测试套件，覆盖本次演练针对的实际攻击路径、检测缺口和控制测试，并使用你自己的评分标准。
三者应分别评分，绝不可混合为一个数字。若模型在第一套中积极响应，同时在第二套中保持有用的判断力，它可能是合适的测试工具。若模型对所有内容都配合，包括那些设计为良性但棘手的 prompt，它反而可能构成风险。当结果看起来不错时，这一区别尤为重要，因为单一的标题分数会掩盖其中的取舍。
任务测试套件应进行版本管理。带着理由淘汰 prompt，在控制措施或模型行为变化时新增 prompt，并记录某个 prompt 是被回答、被拒答、得到部分回答、被重定向，还是在技术上配合但无法使用。拒答并不自动代表测试失败，长篇回答也不自动构成发现。
第 4 步：严谨评分
自动前缀匹配可识别明确的拒答和明确的配合，之后由人工审查者裁定中间情形：技术上配合却夹杂说教的回答、部分回答、重定向，以及掩盖实质内容的政策前言。每 100 个输出至少抽样 20 个进行人工审查，并按 prompt 类别分层抽样；同时记录审查者间一致性，让报告能够陈述自身的不确定性。该抽样率是本方法论的流程建议，并非关于行业标准的主张。
针对每个模型的每次运行跟踪四项指标：按 prompt 类别划分的配合率、良性棘手集上的过度拒答率、在你的并发度下首个 token 的中位延迟，以及完整测试套件的计费成本。每个已评测 prompt 的成本是财务部门能够理解的数字；将其与技术分数一同公布，以便该演练能在下季度为预算辩护。若评分标准支持，也应记录误报、漏报，以及需要裁定的输出百分比。
第 5 步：报告经得起审查的发现
报告应围绕决策组织，而非罗列原始内容。对每项发现，应包括漏洞或缺口、证明问题的精确 prompt 和模型 ID、引用评分标准的严重性、建议修复措施，以及修复后的复测结果。附上范围文档、带哈希的测试套件版本、解码参数和成本账本。没有可复现 prompt 的发现只是轶事；没有范围附录的报告无法审查。
报告应通过与任何渗透测试交付物相同的审批链。关于生产系统的发现应先交给系统所有者，并附上约定的修复窗口，绝不能发到公共频道。模型是否经过去审查（abliteration）只会改变你能测量什么，不会改变你如何处理发现结果。共享报告中应删节机密信息，并将完整证据集置于范围文档规定的访问控制之下。
校准模型发现与人工发现的严重性
模型辅助发现与人工渗透测试发现必须使用同一种严重性语言，否则管理层无法跨两者进行优先级排序。最清晰的做法是，对每一项模型发现使用渗透测试供应商采用的同一评分标准，再跟踪偏差。若模型和人工的严重性评级出现系统性分歧——常见于对利用链可行性的判断——应调整评分标准的指引，而非维护两套量表。统一且校准过的量表可让季度复盘比较两类来源中每个已关闭严重问题的项目成本。
应明确记录校准决策。当团队因利用链需要不现实的前置条件，而将模型标记的严重问题从 critical 降为 high 时，应在工单中记录理由。这些记录会积累为评分指引，使未来审查更快、更一致。两个季度后，应复核该指引是否仍反映当前环境，而不要将这一周期当作通用标准。
入门套件：前 30 天
第一周处理文书与基础设施：签署范围文档、签发限定范围的 key、基于开放 eval 脚本搭建测试框架，并针对两个候选模型运行标准配合与过度拒答测试套件，以验证测试工具。此时尚不运行任务 prompt；目标是获得一条已知基线正常的可用流水线。第二周，针对一个目标类别加入首个包含 60 至 100 个 prompt 的任务测试套件，完成从评分到工单处理的端到端执行。应将计划条款中三到五项发现的目标视为规划目标，而非承诺结果。第三周扩展到第二个目标类别，并在边界输出上引入审查者角色，在工作量仍可管理时对裁定流程进行压力测试。第四周以目标节奏运行完整闭环，并举行第一次复盘：测试套件命中率、评分分歧、每个已评测 prompt 的成本，以及第二个月的更新清单。
第一周常见错误包括：因为配合率看起来令人振奋而跳过过度拒答测试套件、在冻结测试框架参数前运行任务 prompt，以及为了方便而让全团队共用一个 key。每一种错误都会在之后造成返工。从狭窄范围开始，保持严谨，让有意义的结果出现在你信任的流水线上。
这套 LLM 红队测试方法论可防止的失败情形
四种失败模式在不成熟的项目中反复出现，上述每个方法论步骤都旨在阻止其中一种。第一种是未限定范围的测试：对未经任何人授权的系统运行 prompt，在无关的事件审查中才被发现，将安全项目变成人事问题。带有签名和到期日的书面范围文档是预防措施；对于可审计的演练，口头授权并不足够。第二种是陈旧测试套件：同样的 prompt 连续运行一年，发现逐渐降至零，管理层便认为测试的边际收益在下降，而实际上是工具停止了测量。带有淘汰理由的测试套件更新能让工具保持诚实。
第三种是未经审查的输出：自动分数未经人工裁定便直接发送给系统所有者，边界输出被误读为严重发现，项目的可信度受损。由操作员与审查者分工、并进行抽样人工审查，可应对这一风险。第四种是不可归因的结果：发现引用模型昵称、未固定的端点或无人记录的默认参数，导致无法复测、审计艰难。固定 ID、固定参数和带哈希的测试套件可填补这个漏洞。每一步方法论都有其位置，因为它防止了某一具体失败。
工具栈：购买的东西比你想象中更少
测试框架需要五个组件：使用固定参数的 prompt 运行器、带哈希和时间戳的输出存储、结合前缀匹配与人工裁定队列的评分器、在现有跟踪器中创建发现的工单集成，以及按次运行的成本账本。通用工具即可覆盖大多数组件。评分器承载你的评分标准和审查者工作流，因此应保持易于理解并进行版本管理。在弄清实际瓶颈究竟是 prompt 量、审查者协作还是多团队报告之前，不要急于购买专用的 AI 红队测试平台。
应将所有内容一同进行版本管理。测试框架代码、测试套件哈希、解码参数、模型 ID 和评分标准版本，共同构成每个演练周期的一个发布单元。将该发布版本与范围文档版本一同打标签。日后发现受到质疑时，该标签应能复现当时的条件。这种可复现性正是方法论与临场拼凑之间的实际差别。
为已移除拒答限制模型红队测试台选择模型
应按最佳 API 对比的建议，让模型与任务相匹配：DeepSeek V4 Flash uncensored适合深入的多步骤利用路径分析，Qwen3.8 uncensored适合代码密集型审查，Qwen3.6 uncensored适合高量探测。为演练窗口固定精确的模型 ID，并在范围文档中注明。演练期间更换模型会使趋势比较失效，除非将其视作评测的新分支。
常规定价见定价，集成细节见文档。如需了解权重背后的理论，请阅读什么是去审查（abliteration）。应将模型建议视为工作负载假设。决定何种配置是否合适的是测试台，而非标签。
常见问题
为何不使用原始对齐模型进行红队测试？
你可以将它们用于某些评测，但不一致的拒答会污染测量。当模型拒绝了一半的攻击路径 prompt 时，你无法区分是安全控制有效，还是策略中断所致，覆盖统计也会难以解读。已移除拒答限制模型可提供更一致的参与度，这对可复现测试很有帮助，但人工审查和合法范围仍然适用。
一次可信的演练需要多少个 prompt？
数量应足以覆盖范围内的每个攻击类别，每类至少 20 个 prompt，另加用于验证测试工具的标准配合与过度拒答测试套件。小型聚焦演练可能运行数百个 prompt，而项目级测试台可能运行数千个。这些是本方法论给出的规划范围，并非通用阈值。测试套件规模应由范围文档及其必须支持的决策决定。
谁应审查输出？
审查者既需要安全判断力，也需要评测纪律：既能识别真正的发现，也有耐心对边界输出保持一致的评分。每个边界样本由两名审查者审查并跟踪一致性，比一名专家粗略浏览所有内容更可靠。指定一名系统所有者接收发现，并指定另一名操作员保留证据。
如何防止专有 prompt 泄露？
应在具有不用于训练条款、且供应商限制已书面明确的端点上运行专有测试套件。将 prompt 保存在自有且受访问控制的版本控制系统中，尽可能使用合成替代品，绝不要将其粘贴到面向消费者的聊天产品中。测试框架方法论可以公开；prompt 内容和敏感输出必须保持私密。
应多久重新运行一次测试台？
至少每季度一次，此外，在固定集合中的每个模型 checkpoint 变更后也应运行。经消融的构建版本可能随其基础 checkpoint 的变化而变化；冻结一年的测试台测量的是历史，而非当前态势。若预算和审查者容量允许，也可以每月运行。