护栏 on WYF 的技术博客

模型安全检测 13：同类安全护栏方案横评（开源框架 + 商用护栏）

Mon, 14 Sep 2026 10:03:15 +0800

状态：✅ 已完成 前置阅读：03-技术架构与业务模块分析——分层架构、请求链路、四大 skill 实现日期：2026-09-14 素材来源：提纲参考链接全文研读 + WebSearch/FetchURL 补充（2025~2026 最新动态，含 GitHub API 核实仓库状态）+ JoySafety 源码逐条核实 读者定位：已读懂 03 篇架构、现在想回答"为什么是 JoySafety、它的差异化和短板在哪"的读者 写作约定：JoySafety 侧结论全部落到源码坐标（path:line，均经 Read/Grep 亲自核实）；外部事实全部附来源链接，汇总见第五章

〇、先建立全局认识

0.1 JoySafety 一分钟回顾（配置流 + 请求流）

横评之前先把"被评对象"的两条链路钉死，后面所有对比维度都挂在它上面（细节见 03 篇，此处只给坐标）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


配置流（配置期）：admin 写库 → api 轮询 → 内存缓存 → DAG 重建
 safety-admin(8006) 配置 CRUD + 版本化状态机（online 禁改、upgrade 原子切换）
 → 写入 MySQL
 → safety-api(8007) 每 60s HTTP 轮询 /config/defense/api/conf
 （DynamicConfigService.java:65 `@Scheduled(fixedRate = 60000)`）
 → 按 lastChangeTimestamp 判断变更 → 全量替换 volatile 配置 Map → 回调重建各业务 DAG

请求流（执行期）：业务方 → 鉴权 → DAG → skill → 响应
 POST /llmsec/api/defense/v2/{accessKey}
 （DefenseApiV2Controller.java:33，注意目录名是 contoller，原仓库笔误）
 → checkParams → Guava 内存级限流 → HMAC-SHA1 验签（accessKey 以 test 开头特赦，:74）
 → 按 responseMode 分派（ResponseMode.java:7-26：sync / free_taxi / mq / http）
 → DAG 从 root 逐跳执行（FunctionExecutorImpl.java:289 的 while 循环）
 → 节点 HTTP 调用 skill 服务（keywords / bert / knowledge）
 → 汇总风险结果响应

一句话定位：JoySafety 不是检测模型，而是"管理和调度一堆检测能力的编排框架"。记住这句话，它是本章分类坐标系的锚点。

0.2 四类玩家坐标系：不要混在一起比

市面上"大模型安全护栏"相关方案看似几十款，实则分属四个完全不同的层，跨层比较没有意义——就像不能拿"安检流程调度中心"和"X 光机"比谁更好：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 「大模型安全护栏」市场全景（四类玩家）
 ┌──────────────────┬──────────────────┬──────────────────┬──────────────────┐
 │ ① 编排框架 │ ② 检测模型 │ ③ 商用护栏 API │ ④ 红队评测工具 │
 │ （调度中心） │ （检测仪器） │ （外包安检公司） │ （演习部队） │
 ├──────────────────┼──────────────────┼──────────────────┼──────────────────┤
 │ JoySafety │ Llama Guard 4 │ 阿里云AI安全护栏 │ garak │
 │ NeMo Guardrails │ Prompt Guard 2 │ 网易易盾 │ PyRIT │
 │ Guardrails AI │ ShieldGemma 2 │ 腾讯云天御 │ Promptfoo │
 │ LLM Guard │ Granite Guardian │ 百度/华为云 │ │
 │ Rebuff │ WildGuard │ Azure/AWS/Lakera │ │
 ├──────────────────┼──────────────────┼──────────────────┼──────────────────┤
 │ 决定"检测能力怎么 │ 决定"单点判得准不 │ 买服务，按量付费 │ 决定"防线漏不漏" │
 │ 组合、怎么流转" │ 准"，是被编排的料 │ 省心但数据出域 │ 离线评测，不在线 │
 │ │ （→ 见 14 篇） │ │ 拦截（→ 见 15 篇）│
 └──────────────────┴──────────────────┴──────────────────┴──────────────────┘

三条认知结论：

模型是被编排的"料"，框架是"厨子"。Llama Guard 4、Prompt Guard 2 这类检测模型的正确用法是包装成原子能力接进编排框架——14 篇就做这个实验，本篇不比模型。
红队工具不在请求链路上。garak/PyRIT 是离线"演习部队"，负责量化拦截率、反哺策略，本篇同样不展开（15 篇专讲）。
本篇的对比范围：①编排框架（开源，与 JoySafety 同层，逐源码级对比）+ ③商用护栏 API（采购视角对比）。

业界同样强调"分层不要混比"：NeMo 管对话流、Guardrails AI 管输出契约、Llama Guard 管内容分类，“生产答案很少是单一工具，而是分层组合”（particula.tech↗）；“约 80% 的企业级护栏本质是 regex + 几个分类器的封装，关键在于你把栅栏放在哪一层”（cloudthrill.ca↗）。

0.3 2025 并购潮：选型前先看"项目还活着吗"

2025 年 AI 安全赛道被传统安全厂商密集收购，直接影响开源项目的存续性，这是 2026 年选型必须先看的一栏：

时间	事件	对开源项目的影响
2025-06	Snyk 收购 Invariant Labs（MCP/Agent 安全研究方）	研究力量被收编（datapace↗）
2025-07	Palo Alto Networks 完成收购 Protect AI（据报道超 5 亿美元，另有口径称近 7 亿）并入 Prisma AIRS	LLM Guard 仓库已归档（最后提交 2026-07-08，GitHub API 实测 `archived: true`）；Rebuff 更早归档（最后提交 2024-08-07）（senthex↗、deepinspect↗）
2025-09/10	Check Point 收购 Lakera（据报道约 3 亿美元，9 月宣布、10 月完成）	Lakera Guard 并入 Check Point Infinity（senthex↗）
2025-08/09	SentinelOne 收购 Prompt Security（据报道约 2.5 亿美元）	独立厂商再少一家（agentswarms↗）

批注：并购潮给选型两条启示——①商用 SaaS 护栏的独立 roadmap 基本都并入了大厂平台，买它就是买生态；②开源核心里"真正属于你"的部分，以仓库是否活跃为准。本文对比表中专门设了"维护状态"一行：NeMo Guardrails（7112 stars，2026-09-11 仍有提交）与 Guardrails AI（7405 stars，2026-09-13 仍有提交）活跃；LLM Guard、Rebuff 已归档，只能当"机制标本"读，不宜作新项目的生产依赖（GitHub API 逐一核实，2026-09-14）。

一、开源编排框架逐个分析

1.1 NeMo Guardrails：Colang 对话流，五种 rails（NVIDIA，Apache 2.0）

机制：用专用 DSL（Colang）定义"对话流"，护栏挂在五个流水阶段上（docs/仓库↗）：

Rail	触发时机	类比到 JoySafety
input rails	用户消息进 LLM 之前	用户输入侧 DAG 链（keyword→bert）
dialog rails	匹配意图、控制对话走向	无对应物（JoySafety 不做对话管理）
retrieval rails	RAG 检索块进上下文之前	kb_search 节点有部分重叠
execution rails	工具调用（tool call）之前	无对应物（见 4.2 短板 5）
output rails	模型输出到达用户之前	机器人输出侧 DAG 链

关键事实：最新版 0.24.0；Colang 1.0 仍是默认、2.0 并行支持（2.0 起支持多模态交互逻辑）（GitHub 仓库说明↗）；GPU 下单次检查 <50ms，CPU 上要为 embedding/意图匹配留预算（particula.tech↗）。

与 JoySafety 的本质差异在抽象层级：

NeMo 的 rail 是对话语义级编排（intent、flow、bot 该说什么不该说什么），groovy router 是检测结果级编排（按 riskCode/概率阈值决定走哪个节点，GroovyRouter.java:27）。一个是"对话该怎么进行"，一个是"检测结果该怎么处置"。
NeMo 的 execution rails 管工具调用，这是 Agent 时代的护城河；JoySafety 的 Function 注册表里没有这个维度——FunctionRegistry.java:20-30 注册的 9 种 Function（dummy/keyword/single_label_pred/multi_label_pred/kb_search/rag_answer/multi_turn_detect/parallel/async）全部是"内容检测"语义，无一面向工具调用。
Colang 学习曲线陡、部署重；JoySafety 的 YAML + groovy 更"土"但贴近检测工程。

1.2 Guardrails AI：输出结构 + validator 生态（Apache 2.0 核心）

机制：把校验器（validator）挂在模型调用的输入/输出上，校验失败可选 raise / 过滤 / re-ask（让模型自我修正重答）。Hub 上约 65 个社区 validator（PII、毒性、竞品提及、JSON schema、SQL 安全……），质量参差；RAIL spec 用 XML 描述输出契约；0.5+ 起提供 server mode（cloudthrill.ca↗、myengineerpath↗）。

值得注意的两个细节：

它的 PII validator 底层调的是微软 Presidio——这个生态是互相套娃的，PII 检测大家都复用同一个轮子（cloudthrill.ca↗）。
单次校验 50~200ms（regex 类便宜、模型类贵），多个 validator 串联时延迟叠加，实践上要"便宜的先跑、命中即短路"（particula.tech↗）——这与 JoySafety 演示策略"keyword 粗筛先行、bert 精检殿后"（docs/strategy_example.yml）是同一个工程直觉。

与 JoySafety 的差异：Guardrails AI 的核心价值是输出结构校验（合法 JSON、字段约束、grounding），这个维度 JoySafety 完全没有——RiskCheckType.java:14-63 的 10 种检测类型里没有"结构/schema 校验"类目。反过来 Guardrails AI 不管对话流、不管异步审核、不管中文内容合规。

1.3 LLM Guard：scanner 矩阵（Protect AI，MIT，⚠️ 已归档）

机制：LLM 专用 WAF，固定清单的 scanner 矩阵——15 个输入 scanner + 20 个输出 scanner，全部跑本地 HuggingFace 小模型，毫秒级（cloudthrill.ca↗）：

1
2
3


输入侧：PromptInjection / Jailbreak / Secrets / InvisibleText / BanTopics ...
输出侧：Toxicity / MaliciousURLs / NoRefusal / FactualConsistency ...
特色：Anonymize/Deanonymize —— PII 检测+脱敏+还原（底层同样是 Presidio 系）

与 JoySafety 对照出的能力空洞：scanner 矩阵里 注入 / PII / secrets / 匿名化 四块，JoySafety 只有注入（bert_prompt_injection 模型）。全仓 grep PII|脱敏|身份证|手机号，命中的只有 bge tokenizer 词表文件，没有任何业务代码——PII 和 secrets 防泄露是 JoySafety 完全缺席的两个专项（4.2 短板 2）。

存续警告：Protect AI 被 Palo Alto 收购后，LLM Guard 仓库已归档↗（GitHub API 实测 archived: true，最后提交 2026-07-08），社区出现"用什么替代已归档的 LLM Guard↗“一类文章。代码仍可自托管（MIT），但检测能力已停止进化——当机制标本读，别当新项目依赖用。

1.4 Rebuff：注入检测四层（⚠️ 已归档的 prototype）

机制：单点做深"提示词注入"一件事，四层防御（Rebuff 仓库↗）：

1
2
3
4


1. Heuristics 启发式：恶意特征快速过滤，挡在 LLM 之前
2. LLM-based detection：专用 LLM 分析输入是否攻击
3. VectorDB：历史攻击样本的 embedding 入库，相似攻击直接识别（自强化）
4. Canary tokens：给 prompt 埋金丝雀词，输出里检出即说明系统提示词已泄露

架构启示（即便项目死了，思想值得吸收）：

第 3 层"攻击样本向量化、以史鉴今"与 JoySafety 的"红线知识库 + kb_search”（07 篇）是同构思路——都是用向量检索把历史风险资产化；
第 4 层 canary token 是独有的"泄露探针"机制，JoySafety 与主流框架都没有对应物。

存续警告：仓库已归档↗（最后提交 2024-08-07，1522 stars），README 自述"still a prototype, cannot provide 100% protection"；自托管还依赖 Pinecone + Supabase + OpenAI 三件套。典型教训：prototype 级项目不能进生产。

1.5 五方对比表（同层横评）

维度	JoySafety	NeMo Guardrails	Guardrails AI	LLM Guard	Rebuff
抽象层级	检测流水线编排（DAG）	对话流编排（5 rails）	输出契约校验（validators）	扫描器矩阵（固定清单）	注入检测四层（固定）
策略表达	YAML 节点 + groovy router	Colang DSL	Python 组合 / RAIL	配置开关	无（写死）
编排灵活度	高（分支/并行/归约，但"DAG"实为链式逐跳，`FunctionExecutorImpl.java:289`）	高（对话语义级）	中（链式组合）	低	低
异步/流式支持	✅ free_taxi 独有（`ResponseMode.java:16`）	同步为主	同步	同步	同步
中文能力	✅ 原生（中文语料训练的 bert + 中文敏感词体系）	依赖底层 LLM，英文为主	依赖 validator 模型，英文为主	英文为主	英文为主
私有化	✅ 全组件自托管（含向量库/embedding 全本地）	✅	✅（另有付费 Pro 托管层）	✅（MIT）	△ 依赖 Pinecone/Supabase/OpenAI
生产验证证据	京东日均亿级调用、95%+ 攻击拦截率（README.md:23）	NVIDIA 生态、Fortune 500 采用（cloudthrill↗）	Hub 社区规模	已并入 Prisma AIRS	无，自述 prototype
维护状态（2026-09 实测）	活跃	活跃（0.24.0）	活跃	❌ 已归档	❌ 已归档
输出结构校验	❌	△	✅ 核心能力	❌	❌
PII/secrets 专项	❌（grep 无业务代码）	△（依赖集成）	✅（Presidio 系）	✅ 专项 scanner	❌
Agent/工具调用防护	❌	✅ execution rails	△	❌	❌

读表结论：五个框架不全是"竞品"——NeMo 强在对话流与 Agent 闸门、Guardrails AI 强在输出契约、LLM Guard/Rebuff 是固定能力的扫描器。JoySafety 在异步流式、中文、私有化、生产证据四行独占优势；在输出结构、PII、Agent 防护三行明显空白——这就是第四章短板清单的来源。

二、商用护栏 API 对比

商用 API 与开源框架不是"谁替代谁"的关系：商用卖的是"检测能力即服务"（含合规背书与审计链路），开源框架卖的是"编排自主权"。数据能不能出域，是第一道分水岭。

2.1 国内：跟着云生态和内容治理走

产品	定位与特色	来源
阿里云 AI 安全护栏	2025-09 云栖大会发布，五项能力：内容合规、敏感数据、提示词攻击、恶意文件/URL、数字水印标识；与百炼、WAF（LLM-WAF）一键集成；覆盖图文音视文档多模态	admin5↗、产品页↗
网易易盾	“AI 生成内容识别 + 大模型输入输出安全 + 多模态审核 + 风险处置"全链路治理；GB/T 45654-2025《网络安全技术生成式人工智能服务安全基本要求》核心起草单位；公开客户含招商银行、人民网等；显式标识（OCR/ASR/元数据/水印解析）+ 隐式生成痕迹双路识别	sohu 六款对比↗
腾讯云天御	UGC+AIGC 混合业务的多模态审核（文本/图/音/视频/直播）+ AI 生成鉴别；另有腾讯云 WAF 大模型安全走"流量层+应用层"边界视角	sohu↗、cnblogs↗
百度智能云 AI 安全护栏	特色是把安全范围延伸到 Agent 运行链路（工具调用、任务执行），传统审核能力（司南）继续覆盖图文音视频	sohu↗
华为云 ModelArts Guard	围绕 ModelArts/盘古的"训练-部署-运行"闭环治理，平台内一致性	cnblogs↗

背景政策锚点：《人工智能生成合成内容标识办法》自 2025-09-01 起施行，要求 AI 生成的图片/音频/视频等添加显式标识及隐式标识（元数据/数字水印）——国内商用护栏集体上线"内容标识/水印"能力就是应此规，而 JoySafety 在该维度为零（4.2 短板 6）（阿里云文档↗）。

2.2 海外：注入检测与幻觉校验是卖点

Azure AI Content Safety：招牌能力 Prompt Shields 把两类注入分开检——Prompt Shields for User Prompts 检直接注入/越狱（用户输入侧），Prompt Shields for Documents 检间接注入（RAG 文档、第三方内容里埋的攻击载荷，覆盖篡改内容、信息探测、编码绕过、角色扮演等类别）（Microsoft Learn↗、Azure Blog↗）。另有 Groundedness Detection（回答是否能在参考资料中找到依据，治幻觉）与受保护材料检测。

对照 JoySafety：bert_prompt_injection 模型不区分直接/间接注入（事实上框架拿不到"哪段文本来自外部文档"的结构化输入，入参就是一段 plain text）。Azure 的拆法提示：间接注入检测的前提是编排层知道数据来源——这是 JoySafety 若要做深注入防护需要补的上下文设计。

AWS Bedrock Guardrails：模块化策略包，六大策略类型——Content Filters（有害内容分类）、Denied Topics（禁止话题）、Word Filters（词表）、Sensitive Information Filters（PII 检测/遮蔽）、Prompt Attack（注入/越狱）、Contextual Grounding Checks（回答与参考资料一致性）；2024 起陆续叠加 Automated Reasoning 策略（宣称在策略定义域内 99% 校验准确率，2025-11 新增从策略文档自动生成测试问答对）（KodeKloud↗、techjacksolutions↗）。最大卖点是跨模型统一策略：一套 guardrail 套在 Bedrock 上所有基础模型外面。

Lakera Guard：注入检测专项冠军——背靠 Gandalf 游戏的对抗数据集（Check Point 公告口径超 8000 万条对抗样本），公开基准 PINT，约 50ms 延迟、100+ 语言；2025-10 起归 Check Point（senthex↗、cloudthrill↗）。代价：SaaS 形态下 prompt 要出域。

2.3 商用对比表（√/×/— = 具备/不具备/未公开）

产品	多模态	敏感数据防泄露	合规审计	内容标识/水印	私有化	计费
阿里云 AI 安全护栏	✅ 图文音视文档	✅ 敏感数据检测	云内日志归档	✅ 数字水印标识（五项能力之一）	公有云/专有云	按量付费 + 资源包 + QPS 扩容包（计费文档↗）
网易易盾	✅ + AI 生成鉴别	✅	✅ 投诉/审计/人工复核链路，国标起草背书	✅ 显式+隐式标识检测	—	商用报价
腾讯云天御	✅ 图文音视直播	✅	云内	✅ AI 生成鉴别	—	按量
百度智能云	✅ + Agent 链路	✅	云内	—	—	按量
华为云 ModelArts Guard	✅ 多场景	✅	平台流水	—	公有/专有	平台计费
Azure AI Content Safety	文本/图片	✅	Azure 生态	△（受保护材料检测，非 AIGC 标识）	公有云	按量
AWS Bedrock Guardrails	文本/图片	✅ PII 过滤器	CloudTrail	❌	公有云	内容过滤 $0.15/千文本单元（2024-12 降价 80% 后）（techjacksolutions↗）
Lakera Guard	文本为主	△	企业版	❌	SaaS 为主（企业版可自托管，senthex↗）	按调用/报价

读表结论：①"内容标识/水印"是国内特色需求（监管驱动），海外产品基本不做；②国内云护栏的优势是生态集成与合规审计，海外（Azure/AWS/Lakera）的优势是注入检测与幻觉校验的技术纵深；③商用 API 的共同软肋是数据出域——金融/政企场景这一条就是否决项，恰是 JoySafety 这类私有化框架的存在理由。

三、选型决策矩阵

选型不是"选最好的”，是"按场景选组合"。下表给场景 × 需求 → 推荐组合：

场景	核心需求	推荐组合
国内大模型客服/导购/办公助手	中文、纯文本、数据不出域、合规处置	JoySafety 自研编排 + 自带 bert/敏感词/知识库纵深防御；PII 需求用 09 篇方法自接 Presidio 类能力
英文对话产品，话题边界与工具调用管控	对话流 + Agent 闸门	NeMo Guardrails（前置可叠加扫描器层）
结构化输出场景（JSON/表单/代码生成）	输出契约	Guardrails AI validators
用户可能粘贴敏感数据进共享模型端点	PII 检测与脱敏	Presidio（或 LLM Guard 思路自研，注意其已归档）
UGC+AIGC 内容平台	多模态审核 + AI 生成标识	网易易盾 / 腾讯云天御
已深度绑定某朵云	集成成本最低	对应云原生护栏（阿里云/AWS Bedrock/Azure）
全球化英文 SaaS，注入是头号风险且接受数据出域	注入检出率	Lakera Guard
金融/政务/医疗高合规	审计留痕 + 私有化 + 国标对齐	JoySafety 私有化为底座 + 商用私有化能力补强（标识/审计）
任何上生产的方案	持续量化拦截率	叠加红队评测（garak/PyRIT/Promptfoo，15 篇）——护栏决定"防不防"，红队决定"知不知道漏没漏"

组合而非单选是业界共识：particula.tech 给出的生产栈是"LLM Guard 前置粗扫 → NeMo 对话轨 → Llama Guard 分类 → Guardrails AI 输出校验"四层串行（来源↗）；国内选型文同样强调"流式检测 + 细粒度权限 + 全链路审计"的基本盘与"拦截率/延迟/误杀率"三元指标（cnblogs↗）。映射到 JoySafety：它的 DAG + groovy router 天然就是"组合器"，缺的不是组合能力，而是可组合的能力件（PII、结构校验、审核大模型）。

四、结论：JoySafety 的差异化与短板清单

4.1 差异化（每条都有源码或官方证据）

DAG 编排 + groovy 策略：检测能力抽象为 Function，策略即 YAML + groovy router（FunctionRegistry.java:20、GroovyRouter.java:27），策略逻辑免发版可改；编排灵活度对标 NeMo，但面向"检测流水线"而非"对话流"，更贴近内容审核工程。
free_taxi 异步模式（业界独有）：把检测从流式输出的同步路径上摘掉，下一次请求顺带带回上一次的检测结果（ResponseMode.java:16，机制走读见 03 篇 3.5 节）。五家开源框架全部为同步模型——流式输出场景这是 JoySafety 的独占解法。
纵深防御策略样板：敏感词粗筛 → BERT 精检 → 知识库双证（docs/strategy_example.yml + docs/ABOUT_DAG.md），每层有成本/准确率权衡，与业界"便宜的先跑"原则一致且落地为可运行配置。
中文原生 + 彻底私有化：中文语料训练的注入/风险分类模型、中文敏感词体系；向量库（Vearch）、embedding（bge ONNX 本地推理）全部自托管，无任何外部 SaaS 依赖。
生产背书：京东内部覆盖 AI 导购、物流客服、医疗问诊等场景，日均亿级调用、95%+ 攻击拦截率（README.md:23）——开源编排框架里唯一给出生产规模证据的。

4.2 短板清单（源码证据 → 反哺 11 篇生产化）

#	短板	源码证据	对标对象	反哺改造方向
1	纯文本：枚举预留了多模态但实际只跑文本	`ContentType.java:8-28` 有 text/picture/audio/video 四种，但 `DefenseApiRequest.java:22` 默认 text、`safety-api/docs/api.md:40` 明示"当前仅运行 text"，且全仓无任何 Function 按 contentType 分支	国内商用护栏全员多模态	11 篇加"多模态能力接入"项：以 09 篇自定义能力机制接入图文模型（14 篇给出候选）
2	无 PII/secrets 专项	`RiskCheckType.java:14-63` 十种类型无 PII 类目；全仓 grep `PII/脱敏/身份证/手机号` 只命中 tokenizer 词表	LLM Guard scanner、Guardrails AI（Presidio）、AWS Sensitive Information Filters	11 篇加"PII 能力"项：regex+NER 自研或包装 Presidio
3	无输出结构校验	`FunctionRegistry.java:20-30` 九种 Function 无 schema/格式校验类	Guardrails AI 核心能力	新增 `json_schema` 类 Function（Function 接口本身就是开放扩展点）
4	审核大模型未集成进框架	README.md:349：审核大模型 `JSL-joysafety-v1` 已在 HuggingFace 开源（API 实测存在，2025-09-24 更新，safetensors/gpt_oss 架构），“后续 Joysafety 集成此系列模型”——即模型已出、集成未做	Llama Guard 4、商用护栏的审核大模型	14 篇可直接做接入实验：按 single_label_pred 协议包装为原子能力
5	无 Agent 安全维度	九种 Function 全为内容检测语义，无 tool-call/执行闸门；入参也无工具调用上下文字段	NeMo execution rails、百度 Agent 链路护栏	中长期项：DAG 节点需扩展"工具调用审核"语义
6	无内容标识/水印	全仓无相关代码	阿里云五项能力之一、《人工智能生成合成内容标识办法》（2025-09-01 施行）	监管强相关业务需外购或自研标识检测能力
7	mq responseMode 是空 stub	`MessageQueueServiceImpl.java:30-33` 两个方法体为空、`// todo 增加输出到mq`	—（工程完整性）	已在 11 篇提纲中，不再重复

对提纲的一处如实修正：提纲写"无审核大模型（官方 roadmap 待出）"，与实际不符——README.md:349 已明确开源了 JSL-joysafety-v1 并预告集成计划，经 HuggingFace API 核实该模型仓库真实存在（最后更新 2025-09-24）。准确的表述是**“审核大模型已开源、但尚未集成进 JoySafety 编排框架”**。这也让它从"纯短板"变成"14 篇可立即动手的接入实验对象"。

4.3 一句话总结

JoySafety 的护城河是"编排自主权 + 中文 + 私有化 + 生产实证"，护城河上的缺口是"能力件不够全"。 横评的真正产出不是"它比谁强"，而是那张短板清单——每一项短板都对应一条明确的、框架架构已经预留好扩展点的改造路径（Function 接口 + admin 注册 + DAG 引用），这正是 09/11/14 三篇要动手填的坑。

五、参考来源汇总

开源框架对比

商用护栏

并购潮

仓库维护状态：NeMo Guardrails / Guardrails AI / LLM Guard / Rebuff 四个 GitHub 仓库的 archived 标志、最后提交时间与 star 数，均为 2026-09-14 通过 GitHub REST API 逐一实测。

JoySafety 侧：所有源码坐标出自本仓库 /Users/wyf/work/maas-safe/JoySafety（safety/ 目录），引用前均经 Read/Grep 核实；审核大模型存在性经 HuggingFace API 核实：jd-opensource/JSL-joysafety-v1↗。

模型安全检测 14：安全检测模型横评与接入实验

Mon, 14 Sep 2026 10:03:15 +0800

状态：✅ 已完成 前置阅读：03-技术架构与业务模块分析、04-DAG编排引擎深入、09-自定义原子能力 调研日期：2026-09-14 素材来源：① 公开资料调研（各家模型卡/论文，链接随文给出）② 本仓库源码核实 ③ maas-safe-doc/安全护栏/poc/ 下的已有测试集与测试记录 读者定位：想搞清楚"开源安全检测模型哪家强、怎么接进 JoySafety、接完怎么比"的读者

结论标记约定（本篇是调研+实验设计，严格区分三种信息）：

标记	含义
【调研】	来自公开资料（模型卡/论文/官方文档），附来源链接
【源码】	本仓库代码核实，附 `path:line` 坐标
【实测记录】	`maas-safe-doc` 里已有的跑分结果（内部服务器，2026-08 批次）
【待实测】	本篇设计好方案、尚未跑出数字的部分

〇、先建立全局认识

0.1 框架与模型的分工

JoySafety 自身不是检测模型，它是"检测能力的编排框架"（03 篇核心结论）。检测模型在它里面是可插拔的原子能力：框架只认 single_label_pred 统一协议（HTTP POST 进、风险标签出），后端挂的是自家 bert 还是 Llama Guard，对 DAG 引擎完全透明。

1
2
3
4
5
6
7


检测模型供给格局（2025-2026）：
 编码器小模型（22M~400M） Prompt Guard 2、JoySafety bert ← 毫秒级，CPU 可跑
 生成式护栏大模型（0.6B~20B） Llama Guard 4、Qwen3Guard、Granite Guardian ← 要 GPU
 多模态护栏 Llama Guard 4、ShieldGemma 2 ← 图文混合场景
 │ 统一包装成 single_label_pred 协议（本文第四章）
 ▼
 JoySafety DAG：keyword → 小模型粗筛 → 大模型精检 → 知识库双证（第六章）

0.2 本篇回答的四个问题

主流开源安全检测模型的能力边界（第一章，【调研】）
JoySafety 自带三个 bert 的真实底细与统一协议（第二章，【源码】）
怎么公平地比：统一评测集建设（第三章）+ 怎么接进来比：接入实验全流程（第四章）
比完之后怎么用：对比表格模板（第五章）+ 快慢分层组合策略（第六章）

一、主流开源安全检测模型清单【调研】

1.1 逐家要点

Llama Guard 4（Meta，2025-04 LlamaCon 发布）：12B 稠密模型，从 Llama 4 Scout 剪枝而来，原生多模态（文本+单图/多图/多轮对话）。分类体系对齐 MLCommons 危害分类 13 类（S1 暴力犯罪…S13），另加 S14 代码解释器滥用，共 S1-S14。输出是生成的文本：safe 或 unsafe\nS9（续输出命中的类别编号）。许可：Llama 4 Community License（商用受限，月活 7 亿红线）。12B 自托管约需 24GB 显存。来源：NVIDIA build 模型卡↗、HF 官方博客↗、PurpleLlama MODEL_CARD↗。

Llama Prompt Guard 2（Meta，2025-04）：编码器分类器，86M（mDeBERTa-base 基座）和 22M（DeBERTa-xsmall 基座）两档，上下文仅 512 token。v2 把 v1 拆开的"注入/越狱"两个标签合并成单一 MALICIOUS 二分类（BENIGN/MALICIOUS），同时覆盖直接越狱与间接注入（第三方数据里埋的恶意指令）。只审输入、不审输出。许可：Llama 许可。来源：LlamaFirewall 论文附录 B↗、ModelScope 模型卡↗。

ShieldGemma 2（Google，2025-03）：基于 Gemma 3 4B 的图像内容审核模型，“策略感知"设计——输入是用户自定义的安全策略 + 图片，输出 Yes/No 违规判定，内置危险内容/色情/暴力血腥三类图像策略。注意区分：ShieldGemma v1 才是文本模型（Gemma 2 的 2B/9B/27B，四类危害，LLM-as-a-judge 的 Yes/No 输出）。许可：Gemma Terms of Use（可商用但非 OSI 开源协议）。来源：ShieldGemma 2 论文↗、Google DeepMind 页面↗。

Granite Guardian（IBM）：谱系 3.0（2B/8B）→ 3.2（5B）→ 3.3（8B，支持 thinking 推理模式）→ 4.1（8B，2026 年新版）。风险覆盖最全的一家：harm/越狱/亵渎/偏见/暴力/色情 + RAG 三件套（上下文相关性/ groundedness/答案相关性幻觉）+ 工具调用幻觉。输出 Yes/No + 置信度。Apache 2.0，许可最干净。来源：granite-guardian GitHub↗、Ollama 4.1 模型卡↗。

WildGuard（Allen AI，NeurIPS 2024 D&B）：基于 Mistral-7B-v0.3 的 7B 模型，一个模型干三件事：用户 prompt 有害性、模型回复有害性、拒答识别。配套 WildGuardMix 92K 训练集 + WildGuardTest 5K 人工标注测试集，论文报告把越狱攻击成功率从 79.8% 压到 2.4%。许可：代码 Apache 2.0，数据集 ODC-BY。来源：WildGuard 论文↗、NeurIPS 页面↗。

NVIDIA Aegis 系列：基于 LlamaGuard/Llama 3.1 微调的内容安全模型家族，13 类关键风险，最大卖点是训练数据（Aegis 2.0 数据集，NeurIPS 2024）商用可用；后继形态为 Llama 3.1 NemoGuard 8B Content Safety。来源：NVIDIA NeMo 文档↗、Aegis 2.0 slides↗。

补充：Qwen3Guard（阿里，2025-10）：提纲外但必须纳入——中文场景绕不开。0.6B/4B/8B 三档，Gen（生成式指令判定）+ Stream（token 级分类头，流式生成中实时打分）两个变体，119 种语言，三级严重度（safe/controversial/unsafe），119 万条训练样本，Apache 2.0。来源：Qwen3Guard 技术报告↗。

1.2 横评大表

模型	参数量	时延量级【实测记录见五章】	中文支持	风险分类体系	输出协议	许可
Llama Guard 4	12B（多模态）	GPU 百 ms 级	弱（Llama 4 官方语言表不含中文，靠零样本泛化）	MLCommons S1-S14	生成文本 `unsafe\nS#`	Llama 4 社区许可
Prompt Guard 2	22M / 86M	CPU 个位数 ms	弱（mDeBERTa 多语基座，训练语料英文为主）	二分类（越狱+注入合并）	张量概率 + 标签	Llama 许可
ShieldGemma 2	4B	GPU 数十~百 ms	弱	图像三类策略（可自定义策略文本）	生成 Yes/No	Gemma ToU
Granite Guardian	2B~8B	GPU 数十~百 ms	弱-中	harm/越狱/RAG 幻觉/工具幻觉等 13+	生成 Yes/No + 置信度	Apache 2.0
WildGuard	7B	GPU 百 ms 级	弱	三任务：prompt 害/回复害/拒答	生成结构化文本	代码 Apache 2.0 / 数据 ODC-BY
NVIDIA Aegis	7B~8B	GPU 百 ms 级	弱	13 类风险	生成文本	数据集 CC 系 / 模型 NVIDIA 许可
Qwen3Guard	0.6B/4B/8B	0.6B 可 CPU	强（119 语言）	三级严重度 × 多类目	Gen 生成 / Stream token 头	Apache 2.0
JoySafety bert_20250916	~102M（MacBERT）	CPU 百 ms 级【源码见 2.1】	强（中文专训）	14 类中文业务风险	张量概率 + 标签	Apache 2.0

批注：一个反直觉的调研结论——模型大小与安全检测能力不相关。arXiv 2605.28830↗ 在 79,331 样本上横评 14 款护栏模型，发现安全场景的核心指标是 recall（漏检代价远高于误报）；Qwen Guard 4B 拿到最高 recall（83.97%），而 Llama Guard 12B、GPT-OSS Safeguard 20B 这类大模型行为保守，最多漏掉 75% 的违规内容。选型别看参数量，看同分布评测集上的 recall。

二、JoySafety 自带模型与统一协议【源码】

2.1 三个自带模型的真实底细（`data/models/`）

模型	基座（config.json 实锤）	类别数	权重体积	演示环境是否注册
`bert_20250916`	chinese-macbert-base（`data/models/bert_20250916/model/config.json` 的 `_name_or_path`）	14 类（0 正常 + 1001 涉政/1002 暴恐/1003 涉黄/1004 涉赌/1005 涉毒/1006 辱骂/2001 歧视/3002 商业违规/4002 侵权/5001 违禁/5002 虚假信息/1007 两性健康/1008 政治非拒答）	390MB	✅
`bert_prompt_injection_20250828`	chinese-roberta-wwm-ext（同上看 `_name_or_path`）	二分类（0 正常 / 201 提示词注入）	390MB	✅
`bert_prompt_injection_20251118`	chinese-roberta-wwm-ext	三分类（正常/明确攻击/疑似风险，见 `README.md:19` 发布说明；红蓝军对抗训练）	390MB	❌ 未注册（`example/safety-skills/safety-knowledge/skills_init.py` 只注册了前两个）

14 类的 riskCode↔文案映射声明在 example/safety-skills/safety-bert/conf/conf_example.json；类别总表也见 safety/safety-skills/model_overview.md:50-74。
三个模型都是 BERT 系 12 层 768 隐层（hidden_size: 768, num_hidden_layers: 12），词表 21128（中文词表），max_position_embeddings: 512——输入超过 512 token 会被截断（safety/safety-skills/safety-bert/app/model/bert_infer.py:36）。
官方还有一个生成式审核模型 JSL-joysafety-v1（基于 gpt-oss-20b 指令微调，见 model_overview.md:12-13），需单独从 HuggingFace 下载，不在 data/models/ 里。

2.2 模型推理服务（safety-bert，8003）

POST /v1/bert/{model_name}，body 带 text_list，逐条返回风险标签。推理核心（safety/safety-skills/safety-bert/app/model/bert_infer.py:48-63）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


def infer(self, query: List[str]):
 softmaxed = self.predict(self.model, query, self.tokenizer, self.device) # ① 整批 softmax
 resp = []
 for i in range(len(softmaxed)):
 max_idx = np.argmax(item) # ② argmax 取 Top1 标签
 max_label = self.labels[max_idx] # ③ labels 来自服务自己的 conf（riskCode 映射表）
 temp = BertResponseData(riskCode=max_label.riskCode, riskMessage=max_label.riskMessage,
 probability=item[max_idx], text=query[i],
 detail=[...]) # ④ detail = 全标签概率分布，策略层调阈值要用
 resp.append(temp)
 return resp

批注：riskCode 映射表（哪个 label 序号对应 1001 还是 201）不在模型权重里，而在 safety-bert 服务的 JSON 配置里（conf_example.json 的 labels 数组）。这就是"模型即配置"的含义——同一套代码换一套 labels 就能服务另一个分类模型。服务响应壳是 {code, message, cost, data}（safety-bert/app/base/__init__.py:21-33，code=0 成功）。

2.3 统一协议：SingleLabelPredFunction 逐段批注

框架与模型服务之间的唯一契约是 single_label_pred 类型。注册表映射：safety/safety-api/src/main/java/com/jd/security/llmsec/service/execute/FunctionRegistry.java:23（single_label_pred → SingleLabelPredFunction）。

初始化（safety/safety-api/src/main/java/com/jd/security/llmsec/service/execute/functions/SingleLabelPredFunction.java:49-96）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


long timeout = 150; // ① 默认超时只有 150ms！
if (this.conf().getTimeoutMilliseconds() != null) {
 timeout = this.conf().getTimeoutMilliseconds(); // ② 用注册时的 timeoutMilliseconds 覆盖
}
switch (this.conf.getModelType()) {
 case textcnn: case llm: case bert: case fasttext: // ③ 四种 modelType 走同一个 HTTP 协议
 FasttextConf fasttextConf = ...(this.conf.getExtra()); // ④ 只需 extra.url 一个字段
 Object resource = FunctionResourcePool.getFunc(type(), url);
 if (resource != null) { this.fasttextClient = (OkHttpClient) resource; }
 else { ... FunctionResourcePool.addFuncIfAbsent(type(), url, temp);
 ScheduleWarmup.appendTask(...); } // ⑤ 每 URL 一个共享 OkHttpClient + 注册 warmup

③④是接入外部模型的关键认知：不管你的模型是 bert 还是 llm 基座，只要包装成同样的 HTTP 接口就能接入；框架对模型架构零感知。
⑤ warmup 的实现：ScheduleWarmup.java:40 的 @Scheduled(initialDelay=5000, fixedRate=60000) 每分钟重放所有 warmup 请求（body 为 text_list=["warmup"]），保持 HTTP 连接池与模型缓存热度。

运行时（同文件 runFasttext():116-155）：

1
2
3
4
5
6
7


SingleLabelPredCheck.SkillsReq req = new SingleLabelPredCheck.SkillsReq();
req.setBusiness_id(context.getBusinessConf().getName()); // 业务名
req.setRequest_id(firstReq.getRequestId());
req.setText_list(Lists.newArrayList(context.getCheckContent())); // 待审文本（单条）
ResponseMessage<List<SkillsResp>> respMessage = HttpHelper.post(this.fasttextClient,
 fasttextConf.getUrl(), HttpHelper.keepaliveHeader(), req, ...); // Keep-Alive 长连接
SingleLabelPredCheck.SkillsResp resp = respMessage.getData().get(0); // 只取 data[0]

请求/响应结构定义在 safety/safety-basic/src/main/java/com/jd/security/llmsec/core/check/SingleLabelPredCheck.java:61-72：

1
2
3
4
5
6
7


public static class SkillsReq { // 请求：四字段
 private String request_id; private String business_id;
 private String session_id; private List<String> text_list;
}
public static class SkillsResp extends RiskInfo { // 响应：riskCode/riskMessage/probability 继承自 RiskInfo
 private String text; private List<RiskInfo> detail; // detail=全标签分布
}

忽略码机制（同文件 doIgnore():157-163）：若返回的 riskCode 命中注册时的 ignoreRiskCode 集合，结果被改写为 defaultRisk（默认 0/正常文本/1.0，safety/safety-basic/.../core/util/LabelUtil.java:13）。演示 DAG 里 bert 节点配了 ignoreRiskCode: [1006]——辱骂类交给关键词层处理、bert 结果直接忽略（example/safety-skills/safety-knowledge/strategy_example.yml:56-63）。

2.4 两条链路的完整图景（接入实验前要烂熟于心）

配置流转（注册新模型走这条路）：

1
2
3
4
5
6


POST admin:8006 /config/defense/manage/function/new + /online
 → MySQL function_conf 表（版本化状态机 init→edit→online，online 禁改）
 → safety-api 每 60s 轮询 admin /config/defense/api/conf
 （DynamicConfigService.java:65，@Scheduled fixedRate=60000）
 → 比对 lastChangeTimestamp 判断变更（同文件 shouldUpdate():113-151）
 → 全量替换 volatile 配置 Map → 回调 listener 重建 DAG（重编译 groovy、重建 OkHttp client）

请求流转（模型被调用的这条路）：

1
2
3
4
5


业务方 POST :8007/llmsec/api/defense/v2/{accessKey}
 → 参数校验 → 限流 → HMAC-SHA1 验签（test 开头免签）
 → DAG 主循环逐节点执行 → parallel 节点线程池并发调各 function
 → SingleLabelPredFunction.runFasttext() → HTTP → 模型服务
 → groovy router 按 riskCode + probability 阈值归约 → 响应

超时两层都要改（02 篇坑 4 的结论，接外部模型时最先踩）：① DAG 并行节点的 timeoutMilliseconds；② function 注册时的 timeoutMilliseconds（→ OkHttp callTimeout，SingleLabelPredFunction.java:54-57、73）。外部大模型动辄数百 ms，两层默认 2000ms 很容易不够。

三、评测集建设方案

3.1 现有素材盘点【实测记录】

maas-safe-doc/安全护栏/poc/测试集/ 下已有三个 CSV（格式已 Read 核实）：

文件	条数	字段	标签分布	说明（`测试集说明.txt`）
`guard_test_set_v6.csv`	993	id,prompt,label,category	unsafe 693 / safe 300	大模型生成并打标；9 个英文类目（Jailbreak 100、Copyright 70、PII 70、Self-Harm 66 等）
`guard_test_set_v7.csv`	2023	id,prompt,label,category,is_obvious	unsafe 1293 / safe 730	v6 + 开源数据集中较明显的违规样本；新增中文类目（违法犯罪 100、淫秽色情 100、政治错误 100、普通安全 430），Jailbreak 扩到 400；is_obvious 标注是否明显违规/安全（明显 1778 / 隐晦 245）
`toxicchat0124_prompt_zh.csv`	2752	id,prompt,label,jailbreaking	safe 2401 / unsafe 351（其中越狱标记 87）	ToxicChat-0124 的中文翻译版，真实用户语料分布（safe 占绝大多数，贴近线上）

三个集合互补：v7 类目标注细、适合看分类明细；toxicchat_zh 分布真实、适合看误判率；jailbreaking 标记可单独切出注入/越狱子集。

3.2 四类样本设计方案（复用 + 补齐）

目标矩阵：注入 / 越狱 / 违规内容 / 正常 × 中 / 英。

维度	数据来源	规模建议	现状
中文违规	v7 中文类目（违法犯罪/淫秽色情/政治错误）+ 普通安全	400+430 已有	✅ 直接复用
中文注入/越狱	v7 Jailbreak 400 + toxicchat_zh 的 jailbreaking=1（87 条）	~500	✅ 复用；间接注入样本需补（可从 RAG 语料里埋指令构造）【待实测】
英文违规/越狱	v6 的 9 个英文类目（AILuminate/ToxicChat 同源风格）	993 已有	✅ 复用
正常样本	v7 Safe/普通安全 730 + toxicchat_zh safe 2401	充足	✅ 复用；建议按业务场景再补真实业务 query【待实测】

建设原则：① 所有模型在同一文件、同一份顺序上跑，避免采样偏差；② 保留 is_obvious 分层统计——明显违规检出率是底线，隐晦违规才拉开差距；③ 每条样本记录文本长度，时延分析要用。

3.3 指标定义（与已有测试报告对齐）

检出率 = Recall(unsafe)：漏检是安全场景最大代价（第一章调研结论），排第一指标
误判率 = FP/(FP+TN)：正常用户被误拦的比例
Accuracy / Precision / F1、混淆矩阵、按 category 的分类明细
时延：mean / P95 / P99（已有报告就是这个格式，见 安全模型测试/L2测试结果/）
资源：进程内存（CPU 模型）或显存（GPU 模型）、加载耗时

四、接入实验：把外部模型包装成 single_label_pred（衔接 09 篇）

4.1 协议契约（2.3 节的 JSON 形态）

1
2
3
4
5


请求 POST {你的服务地址}
 {"request_id":"...","business_id":"test","session_id":"...","text_list":["待审文本"]}
响应 200 + {"code":0,"message":"success","data":[
 {"riskCode":201,"riskMessage":"201提示词注入","probability":0.994,
 "text":"...","detail":[{"riskCode":0,...},{"riskCode":201,...}]}]}

硬性要求（来自 SingleLabelPredFunction.java:126-148 的解析逻辑）：code==0 否则抛错；data 非空数组、只取 [0]；riskCode/probability 必填，detail 供 groovy 阈值策略使用（演示 DAG 里 bert_common.detail.find { it.riskCode == 0 } 就在用它，strategy_example.yml:82）。

4.2 包装服务参考实现（Prompt Guard 2 版）

编码器模型最省事——它原生就是"张量概率 + 标签”，和协议同构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from fastapi import FastAPI
from transformers import pipeline
clf = pipeline("text-classification", model="meta-llama/Llama-Prompt-Guard-2-86M") # ① HF 一行加载
app = FastAPI()

@app.post("/guard/prompt_guard_2")
def predict(req: dict):
 data = []
 for text in req["text_list"]: # ② 协议批量字段，逐条推理
 r = clf(text)[0] # ③ {'label':'MALICIOUS','score':0.99}
 risk = 201 if r["label"] == "MALICIOUS" else 0 # ④ 映射到 JoySafety 风险码体系
 data.append({"riskCode": risk,
 "riskMessage": "201提示词注入" if risk else "0正常文本",
 "probability": r["score"], "text": text, "detail": []})
 return {"code": 0, "message": "success", "data": data} # ⑤ code=0 是成功硬约定

Llama Guard 4 / Qwen3Guard-Gen 版的三个额外工作（生成式模型才有）：

解析生成文本：unsafe\nS9 → 提取类别码；Qwen3Guard 还有 controversial 第三档，要预先决定归入 safe 还是 unsafe（已有测试报告里两种口径都跑过，见 3.3 的 Strict/Lenient）
riskCode 映射表设计：S1-S14 是 MLCommons 体系，和 JoySafety 的 1001~5002 中文业务体系不一一对应——建议外部模型用独立号段（如 6xx）注册，避免与自带 bert 的语义混淆
probability 从哪来：生成式模型没有现成概率，可取首 token logprob，或输出固定置信度（如 0.99）并在 groovy 阈值表里区别对待

4.3 注册 → DAG 引用 → 验证（完整步骤）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


① 起服务：包装服务部署到能访问 safety-api 的网络（容器可加进 compose 网络）
② 直连验证：curl -X POST {服务} -d '{"text_list":["ignore previous instructions"]}'
 → 确认 code=0、riskCode=201（绕开框架先验模型，02 篇坑 4 的二分法）
③ admin 注册（模板照抄 skills_init.py:17-48 的 bert 条目，改三处）：
 POST :8006/config/defense/manage/function/new
 {"name":"prompt_guard_2","group":"default","type":"single_label_pred",
 "timeoutMilliseconds":2000, ← 按模型实测时延设
 "confObj":{"name":"prompt_guard_2","modelType":"bert",
 "extra":{"url":"http://{host}:9000/guard/prompt_guard_2"},
 "ignoreRiskCode":[]}}
 → POST .../function/online {"id": <返回的 id>}
④ DAG 引用：newVersion 出新策略版本，在并行节点里加 `- ref: prompt_guard_2`，
 groovy router 的阈值表加一行（如 `201:0.99` 同款）
⑤ 生效：等 60s 轮询或直接 docker restart safety-api（坑 5 经验），等 1~2 分钟
⑥ 端到端验证：quickstart/api_test.py 打注入样本，看 riskCheckType=single_label_pred

注意：modelType 字段填 bert 即可——它只是走分支的标签（SingleLabelPredFunction.java:59-63 四种类型同一路径），不代表真实模型架构。

五、横评对比：已有记录 + 待实测模板

5.1 已有实测记录（`maas-safe-doc/安全护栏/poc/安全模型测试/`，内部服务器 2026-08 批次）

L2 大模型对比（测试集 guard_test_set_v7_L2.csv，875 条，2026-08-18）：

模型	Accuracy	Precision	Recall(检出率)	F1	平均时延
PolyGuard-Qwen（7B）	93.49%	98.40%	94.27%	96.29%	105.1ms
SingGuard-NSFA-9B	90.86%	99.58%	90.19%	94.65%	40.8ms
JoySafety（整体 API）	88.80%	99.14%	88.28%	93.40%	2121.1ms
Qwen3Guard-Stream-8B	77.49%	99.66%	75.16%	85.69%	48.3ms
Llama Guard 4 12B	70.17%	99.81%	66.88%	80.09%	181.0ms

读表要点：① 全体 precision ≥98%（护栏模型都宁可放过不可错杀），差距全在 recall；② Llama Guard 4 在中文占比高的 v7 上 recall 垫底，印证第一章"中文弱"的调研结论；③ JoySafety 的 2121ms 是整条 DAG 流水线的耗时（含关键词+双 bert 串并行），不是单模型推理时延，比时延不能直接比。

L1 小模型对比（测试集 guard_test_set_v6.csv，993 条，2026-08-17，9 款）节选：

模型	F1	漏报率	误报率	平均时延	QPS
HaloGuard1-Gen-0.8B	92.69%	10.39%	8.67%	187.44ms	5.3
SingGuard-NSFA-0.8B	87.92%	21.21%	1.00%	4.37ms	229.1
Wolf Defender（注入专项）	79.93%	29.58%	13.33%	1.76ms	567.4
Prompt Guard 2（86M）	13.08%	92.93%	2.33%	20.28ms	49.3

最刺眼的一行：Prompt Guard 2 在中文为主的 v6 上 recall 只有 7.07%——英文专训的注入检测模型对中文攻击接近失明。这就是中文业务必须用中文语料微调（JoySafety 自带注入 bert 的价值）或选多语模型（Qwen3Guard 系）的直接证据。【实测记录】

5.2 待实测对比模板【待实测】

在本仓库环境（Mac/Docker 或 GPU 服务器）上，用第三章评测集 + 第四章接入方法，填下表：

模型	检出率 Recall	时延 mean/P95	内存/显存	备注
bert_20250916（自带 14 类）	待填		~390MB 权重	违规内容维度
bert_prompt_injection_20250828（二分类）			~390MB	注入维度
bert_prompt_injection_20251118（三分类）			~390MB	注入维度，需先注册
Prompt Guard 2 86M	预期：中文 recall 很低	预期 CPU <50ms	~350MB	预期英文强
Prompt Guard 2 22M			~90MB	粗筛候选
Qwen3Guard-Gen-0.6B				中文多语候选
Llama Guard 4 12B		需 GPU	~24GB 显存	多模态唯一选项

分维度记录：注入 / 越狱 / 违规 / 正常四类分开统计；is_obvious=0（隐晦样本）单独看检出率。

六、快慢模型分层组合策略

6.1 已有两阶段实验结论【实测记录】

安全模型测试/L1测试结果/L1方案.txt 的两阶段设计：L1 放行侧 HaloGuard+SingGuard+WolfDefender 三个小模型都判 safe 才直接放行；拦截侧 HaloGuard+SingGuard+Siren 都判 unsafe 才直接拦截；不确定样本进 L2 大模型复核。

模型搭配测试报告/compare_report.md 的最优组合（Stage1 小模型 ensemble → Qwen3Guard 复审）：

组合	Stage1 F1	Two-Stage F1	L2 复审率	L2 改判正确率
haloguard + wolfdefender → Qwen3Guard	93.95%	94.59%	28.5%	97.9%

这组数字是分层策略价值的直接证据：71.5% 的流量被毫秒级小模型当场解决，只有 28.5% 进入大模型；大模型改判的 97.9% 是改对的。时延大头只花在难样本上。

6.2 映射到 JoySafety DAG 的实现

JoySafety 的演示 DAG 本身就是分层结构（keyword 粗筛 → bert 精检），把外部模型插进对应层即可：

1
2
3
4
5
6
7
8


start（分流 user/robot）
 └─ user 链路：
 L0 keyword（AC 自动机，亚 ms） ← 黑词短路 / 白词放行
 L1 parallel(小模型粗筛: prompt_guard_2 或 fasttext 级)
 groovy router：高置信（>0.99）直接定结论 ──┐
 L2 parallel(bert_20250916, bert_prompt_injection_*, 外部大模型) ← 只有 L1 不确定才到这
 groovy router：riskCode 差异化阈值表判定（strategy_example.yml:77 的套路）
 L3 （可选）rag_answer + bert 双证：riskCode 一致且概率>0.5 才判风险，防误杀

实现要点：L1→L2 的"不确定才升级"就是 groovy 里一个 if——if (small.hasRisk() && small.probability > 0.99) return null 终结 否则 return 'L2节点'。并行节点的归约（first_risk/groovy_script）见 ParallelFunction.java:57-67。

6.3 融入纵深防御的组合拳（设计建议，部分待实测）

注入防线：Prompt Guard 2 22M（英文流量、个位数 ms）与自带注入 bert（中文流量）并联而非二选一——groovy 里任一高置信命中即拦【待实测：并联后的误判率叠加情况】
违规防线：自带 bert_20250916 主力（中文 14 类是它的主场），Qwen3Guard-0.6B 做第二意见（多语 + controversial 档恰好对应"疑似"语义）
成本公式：全量流量过 L0/L1（~10ms），L2 只接 L1 不确定部分（复审率控制在 30% 内），L3 双证只接 L2 判风险的样本——与已有实验的 28.5% 复审率同构
一号段一模型：外部模型的 riskCode 用独立号段注册（4.2 节），阈值表分行管理，互不污染

七、结论速查

调研结论（可信，附来源）：① 选型看同分布 recall 别看参数量（arXiv 2605.28830）；② 主流开源模型除 Qwen3Guard 外中文都弱；③ 生成式护栏（Llama Guard 4 等）输出要解析+映射才能进 single_label_pred 协议；④ 许可最干净的是 Granite Guardian 和 Qwen3Guard（Apache 2.0），Llama 系有月活限制。

实测记录结论（内部环境，可参考）：① PolyGuard-Qwen 单模型最强（F1 96.29%）；② Prompt Guard 2 中文注入 recall 仅 7%，中文场景不可用；③ 两阶段分层（小模型粗筛 + 大模型复审 28.5% 流量）F1 94.59% 且省时延。

待实测清单（本篇方案的直接产出）：① 第四章包装服务在本仓库环境的端到端验证；② 5.2 表格全部数字；③ 6.3 并联/分层组合在真实评测集上的误判率叠加情况；④ bert_prompt_injection_20251118 三分类注册后的提升幅度。

附录：关键坐标速查

主题	位置
统一协议实现	`safety/safety-api/src/main/java/com/jd/security/llmsec/service/execute/functions/SingleLabelPredFunction.java:116`（runFasttext）
协议请求/响应结构	`safety/safety-basic/.../core/check/SingleLabelPredCheck.java:61-72`
忽略码/默认风险	同上文件 `:157-163`；`safety/safety-basic/.../core/util/LabelUtil.java:13`
modelType 枚举	`safety/safety-basic/.../core/conf/funcs/ModelType.java:8-12`
Function 注册表	`safety/safety-api/.../service/execute/FunctionRegistry.java:23`
warmup 机制	`safety/safety-api/.../service/ScheduleWarmup.java:40`（每 60s 重放）
配置轮询	`safety/safety-api/.../service/DynamicConfigService.java:65`
bert 推理服务	`safety/safety-skills/safety-bert/app/model/bert_infer.py:48-63`
自带模型 labels 映射	`example/safety-skills/safety-bert/conf/conf_example.json`
注册脚本模板	`example/safety-skills/safety-knowledge/skills_init.py:17-48`
演示 DAG 阈值表	`example/safety-skills/safety-knowledge/strategy_example.yml:77-89`
注册接口文档	`safety/safety-admin/docs/api/function_api.md`
评测集	`../maas-safe-doc/安全护栏/poc/测试集/`（v6 993 条 / v7 2023 条 / toxicchat_zh 2752 条）
已有测试报告	`../maas-safe-doc/安全护栏/poc/安全模型测试/`（L1 小模型 9 款、L2 大模型 5 款、两阶段组合 5 组）

参考资料

模型横评基准：Benchmarking Open-Source Safety Guard Models (arXiv 2605.28830)↗
Llama Guard 4：NVIDIA 模型卡↗ / PurpleLlama MODEL_CARD↗
Prompt Guard 2：LlamaFirewall 论文↗ / ModelScope 模型卡↗
ShieldGemma 2：论文↗；Granite Guardian：GitHub↗
WildGuard：论文↗；Qwen3Guard：技术报告↗
NVIDIA Aegis：NeMo 文档↗
JoySafety 模型仓库：https://huggingface.co/jdopensource/JoySafety；生成式审核模型：JSL-joysafety-v1↗

护栏 on WYF 的技术博客

模型安全检测 13：同类安全护栏方案横评（开源框架 + 商用护栏）

〇、先建立全局认识

0.1 JoySafety 一分钟回顾（配置流 + 请求流）

0.2 四类玩家坐标系：不要混在一起比

0.3 2025 并购潮：选型前先看"项目还活着吗"

一、开源编排框架逐个分析

1.1 NeMo Guardrails：Colang 对话流，五种 rails（NVIDIA，Apache 2.0）

1.2 Guardrails AI：输出结构 + validator 生态（Apache 2.0 核心）

1.3 LLM Guard：scanner 矩阵（Protect AI，MIT，⚠️ 已归档）

1.4 Rebuff：注入检测四层（⚠️ 已归档的 prototype）

1.5 五方对比表（同层横评）

二、商用护栏 API 对比

2.1 国内：跟着云生态和内容治理走

2.2 海外：注入检测与幻觉校验是卖点

2.3 商用对比表（√/×/— = 具备/不具备/未公开）

三、选型决策矩阵

四、结论：JoySafety 的差异化与短板清单

4.1 差异化（每条都有源码或官方证据）

4.2 短板清单（源码证据 → 反哺 11 篇生产化）

4.3 一句话总结

五、参考来源汇总

模型安全检测 14：安全检测模型横评与接入实验

〇、先建立全局认识

0.1 框架与模型的分工

0.2 本篇回答的四个问题

一、主流开源安全检测模型清单【调研】

1.1 逐家要点

1.2 横评大表

二、JoySafety 自带模型与统一协议【源码】

2.1 三个自带模型的真实底细（data/models/）

2.2 模型推理服务（safety-bert，8003）

2.3 统一协议：SingleLabelPredFunction 逐段批注

2.4 两条链路的完整图景（接入实验前要烂熟于心）

三、评测集建设方案

3.1 现有素材盘点【实测记录】

3.2 四类样本设计方案（复用 + 补齐）

3.3 指标定义（与已有测试报告对齐）

四、接入实验：把外部模型包装成 single_label_pred（衔接 09 篇）

4.1 协议契约（2.3 节的 JSON 形态）

4.2 包装服务参考实现（Prompt Guard 2 版）

4.3 注册 → DAG 引用 → 验证（完整步骤）

五、横评对比：已有记录 + 待实测模板

5.1 已有实测记录（maas-safe-doc/安全护栏/poc/安全模型测试/，内部服务器 2026-08 批次）

5.2 待实测对比模板【待实测】

六、快慢模型分层组合策略

6.1 已有两阶段实验结论【实测记录】

6.2 映射到 JoySafety DAG 的实现

6.3 融入纵深防御的组合拳（设计建议，部分待实测）

七、结论速查

附录：关键坐标速查

参考资料

2.1 三个自带模型的真实底细（`data/models/`）

5.1 已有实测记录（`maas-safe-doc/安全护栏/poc/安全模型测试/`，内部服务器 2026-08 批次）