AI 应用的内容审核不是”接一个审核 API 就行”——主流方案是「输入分类器 + 系统提示约束 + 输出分类器 + 工具调用门禁 + 人审兜底」五层堆叠，覆盖文本/图像/视频多模态，落地时再用策略即代码（policy-as-code）把分类阈值、动作、升级路径绑在一起。2024 年 OpenAI Moderation API、Azure AI Content Safety 已成事实标准，2025 年 4 月 Meta 发布 Llama Guard 4（12B，多模态、MLCommons S1–S14 分类法）把开源护栏拉高一个档位，Anthropic 同年公开 Constitutional Classifiers，监管侧《生成式人工智能服务安全基本要求》（GB/T 45654-2025）把”违法信息≤5%、可溯源”写成了强制条款。下文从分层架构、方案选型、落地步骤和常见坑四个角度系统拆解。
一、为什么系统提示不是审核
很多团队第一次做内容审核，会在系统提示里写”拒绝回答违法问题”。这不是审核，是”礼貌请求”——模型在正常输入下会守规矩，遇到对抗输入就会被绕开。把这件事说清楚，是讨论技术方案的前提。
工程上的内容审核，本质是把策略变成可被机器执行、可被版本管理、可被审计的代码，再按”输入/输出/工具/流程”四类切面分别落一层防护。OWASP LLM Top 10 把 Prompt Injection（LLM01）列为风险第一，监管白皮书（EU AI Act、NIST AI RMF）都把”分层防御 + 人工 oversight + 可审计日志”列为基础要求。设计架构时，建议遵循这个五层堆叠思路：
| 层级 | 解决的问题 | 典型实现 |
|---|---|---|
| 输入分类器 | 拦下恶意/越狱/PII 输入 | 正则、Azure AI Content Safety、Llama Guard 4、Prompt Guard 2 |
| 系统提示约束 | 兜底风格、设定身份 | 角色定义、输出格式 schema |
| 输出分类器 | 模型生成后二次兜底 | 安全分类器、LLM-as-Judge、规则改写 |
| 工具调用门禁 | 拦截 Agent 写文件/发邮件等高危动作 | allowlist + 二次确认 + 速率限制 |
| 流程层 | 低置信度/高风险升级到人 | 审核队列、SLA、人工 review、kill switch |
把”分类器 + 提示 + 工具 + 流程”四件事合并起来看，才是”内容审核”真正的工作量；少任何一层都会被对抗流量打穿。
二、主流技术方案对比
不同方案在延迟、覆盖语种、定制难度、合规背书上差异明显。2025 下半年到 2026 年主流方案的横向对比：
| 方案 | 类型 | 覆盖模态 | 延迟量级 | 典型用法 | 备注 |
|---|---|---|---|---|---|
| OpenAI Moderation API | 托管/免费 | 文本 | 毫秒级 | 通用违规打分 | 内置 hate/sexual/violence/self-harm 类别 |
| Azure AI Content Safety | 托管 API | 文本/图像 | 毫秒级 | 严重度 0-7 八级输出 | 2024-09 GA，2025-11 文档更新 |
| Google Perspective API | 托管 API | 文本 | 毫秒级 | 毒性/偏见打分 | 阈值可调，社区广泛 |
| Llama Guard 4（12B） | 开源模型 | 文本/图像 | 秒级（GPU） | 自部署、可定制 | MLCommons S1–S14 分类法 |
| NVIDIA NeMo Guardrails | 框架 | 文本 | 毫秒到秒级 | 主题门禁 + 对话流 | 可编程，Colang DSL |
| Anthropic Constitutional Classifiers | 模型内置 | 文本 | 跟随主调用 | 与 Claude 同源安全策略 | 2025 公开发布 |
| Guardrails AI | Python 框架 | 文本 | 取决于 validator | 声明式 validator | 强类型结构化输出校验 |
| 自建 LLM-as-Judge | 自建 | 文本/多模态 | 秒级 | 用小模型做大模型判官 | 成本可控、可解释 |
选型的反直觉点：免费不等于便宜。OpenAI Moderation API 免费但只覆盖 4 类基本违规，生成侧仍需叠加 Llama Guard 或自家规则；Azure Content Safety 强在企业级 SLA 与多区域部署；自建 Llama Guard 4 一次性成本高、但能跑在自己的合规域里、避开跨境数据流转。2025 年欧盟 AI Act 进入应用阶段，跨境数据合规是绕不开的硬约束。
三、五步落地路径
把审核体系从 0 跑起来，工程上分五步：
- 写策略即代码：用 YAML/JSON 定义”哪些类别、阈值多少、命中后做什么（block / mask / rewrite / escalate / log）”，并在版本库管理。例如
harm_categories.sexual.severity>=3 → block，pii.credit_card → mask； - 接入输入分类器：在请求进入 LLM 之前过一道 Llama Guard 4 或 Azure Content Safety，命中阈值直接返回预定义兜底话术，不进入主模型；
- 生成侧加结构化约束：用 JSON Schema / OpenAPI 限制输出格式，让模型无法”自由发挥”出无法审查的字段；
- 接输出分类器与 LLM-as-Judge：对主模型输出再过一次分类器（自家小模型或第三方 API），高风险内容打回重写或人工审核；
- 建立人工队列与 kill switch：低置信度样本进审核队列并配 SLA（如 1 小时），紧急情况下一键停服。
这套链路搭起来后，运营上还要做两件事：每周用红队用例跑一遍回归，按月更新策略文件。红队测试的具体设计会在本组后续文章里系统展开。
下面给出一段把”输入分类 + 输出分类 + 工具门禁”三件事串起来的最小化 Python 示例，工程上可以直接嵌进 FastAPI 中间件。
import os, re, requests
from dataclasses import dataclass
@dataclass
class ModerationResult:
allowed: bool
reason: str = ""
risk_score: float = 0.0
# 1) 轻量级正则：拦截明显的越狱模板
_INJECTION_PATTERNS = [
r"忽略(之前|以上)(的|所有)?(指令|规则)",
r"ignore (previous|all) instructions",
r"DAN\s*模式",
]
def check_injection(text: str) -> ModerationResult:
for pat in _INJECTION_PATTERNS:
if re.search(pat, text, re.IGNORECASE):
return ModerationResult(False, "prompt_injection_pattern", 0.9)
return ModerationResult(True)
# 2) PII 脱敏：信用卡、身份证号先 mask 再送进模型
_PII_PATTERNS = {
"credit_card": re.compile(r"\b(?:\d[ -]*?){13,16}\b"),
"id_card": re.compile(r"\b\d{17}[\dXx]\b"),
}
def mask_pii(text: str) -> str:
for label, pat in _PII_PATTERNS.items():
text = pat.sub(f"[REDACTED_{label.upper()}]", text)
return text
# 3) 调用云端分类器（Azure Content Safety 风格）
def azure_classify(text: str) -> dict:
endpoint = os.environ["AZURE_CONTENT_SAFETY_ENDPOINT"]
key = os.environ["AZURE_CONTENT_SAFETY_KEY"]
url = f"{endpoint}/contentsafety/text:analyze?api-version=2024-09-01"
headers = {"Ocp-Apim-Subscription-Key": key, "Content-Type": "application/json"}
body = {"text": text, "categories": ["Hate", "Violence", "Sexual", "SelfHarm"],
"outputType": "EightSeverityLevels"}
return requests.post(url, json=body, headers=headers, timeout=3).json()
def enforce_policy(prompt: str) -> ModerationResult:
inj = check_injection(prompt)
if not inj.allowed:
return inj
safe = mask_pii(prompt)
result = azure_classify(safe)
for cat in result.get("categoriesAnalysis", []):
if cat["category"] in ("Sexual", "SelfHarm") and cat["severity"] >= 3:
return ModerationResult(False, f"azure:{cat['category']}", 0.8)
return ModerationResult(True, risk_score=0.1)
# 4) 工具调用门禁：Agent 在执行写操作前必须二次确认
_ALLOWED_TOOLS = {"search", "read_file", "summarize"}
_HIGH_RISK = {"send_email", "delete_file", "transfer_funds"}
def tool_gate(tool_name: str, args: dict) -> bool:
if tool_name in _ALLOWED_TOOLS:
return True
if tool_name in _HIGH_RISK:
# 实际项目里走"人工点击确认"或独立审批流
return False
return False效果上，把上面四段函数拼成一个 FastAPI 中间件，prompt 在到达 LLM 之前就完成注入检测、PII 脱敏、云端分类；模型响应后再过一次对称的输出分类器；Agent 的高危工具调用走 gate 阻断。整条链路的端到端延迟取决于云端分类往返与是否同步调用 LLM-as-Judge，实测从毫秒级到秒级都有，业务上线前应先在准生产链路上跑一遍延迟分布再下结论。
四、策略与运营的关键细节
架构搭起来后，真正决定效果的是策略与运营层。三件最容易踩的坑：
- 阈值过严造成”过度审核”：把”中度”也直接 block，会让合规业务被误伤，损害用户信任。经验做法是把动作拆成”block / mask / rewrite / escalate / log”五档，按类别按风险等级绑定不同动作；
- 多语言/多模态盲区：仅用英文正则与单模态分类器，会在多语种场景下大量漏判；2025 年的工程实践是”正则 + LLM 分类器 + 多模态分类器”三段串联，三类护栏单独看都不完美、叠起来才能把对抗输入的漏判率明显压下来；
- 没有审计链路：所有命中都必须留 trace（请求 ID、用户 ID、分类器版本、阈值、动作），否则事后无法复盘，也无法满足 EU AI Act 第 12 条与 GB/T 45654-2025 对”可审计、可回溯”的硬性要求。
策略侧还应做红队回归与季度审计。OWASP LLM Top 10、MITRE ATLAS、NIST AI RMF 都是常见的基线参考。
到这里，AI 应用的内容审核从分层架构、方案选型、代码落到运营细节就完整了。审核不是”加个 API”，是输入/输出/工具/流程四件事的系统工程；技术选型决定下限，策略与运营决定上限。
常见问题（FAQ）
Q1：系统提示词算不算内容审核？
算辅助层。系统提示对正常输入有效，对抗输入会被绕开，必须再叠分类器。
Q2：免费 API 是否够用？
通用违规打分够用，但跨境合规与多模态仍需付费方案或自建模型补足。
Q3：审核延迟怎么控制？
正则+轻量分类同步跑，LLM 判官与主调用并行或异步批处理。
