LLM 内容安全策略引擎与审核系统设计
内容安全不是在 Prompt 里写一句“请遵守规范”，也不是模型返回后只跑一次关键词过滤。生产系统要将输入、检索证据、模型输出、工具参数和外发动作分别置于可解释、可审计、可灰度的策略控制之下。
一、30 秒面试回答
我会把 LLM 安全设计成独立的策略决策与执行控制面。每个请求携带租户、用户角色、场景、数据等级和运行版本；输入、RAG 证据、模型输出、工具调用分别经过适合该阶段的检测器与策略评估。策略引擎输出的不是模糊的“安全/不安全”，而是 allow / redact / transform / require_approval / block / escalate 及原因码、置信度和命中规则。高风险动作在工具执行器处再次做强制授权与业务校验，绝不因模型文本通过审核就放行。所有判定、模型/规则版本、人工复核和最终处置写入审计链路，并通过对抗集、误伤率、漏放率、人工升级时延和业务完成率持续评测。
一句话：Prompt 是行为引导；安全策略引擎是模型之外、不可绕过的执行约束。
二、先拆安全对象：内容、数据、动作不是同一类问题
| 对象 | 典型风险 | 控制点 | 不能只靠 |
|---|---|---|---|
| 用户输入 | 越狱、仇恨、欺诈、恶意指令 | 输入检测、风险路由、频控 | 系统提示词 |
| RAG/网页/附件 | 间接 Prompt 注入、敏感内容、恶意链接 | 来源标记、检索过滤、内容隔离 | “模型会自行忽略” |
| 模型输出 | 有害建议、隐私泄露、幻觉承诺 | 输出审核、引用约束、改写/拒答 | 单一关键词表 |
| 工具参数 | 越权读写、SQL 注入、外发敏感数据 | Schema、授权、业务规则、审批 | 输出审核 |
| 外部副作用 | 发邮件、下单、删除、转账 | 幂等、双人审批、事务/补偿 | 模型置信度 |
面试中先说明：内容审核和权限控制相互配合但不能互相代替。一个回答即使“措辞安全”，也可能泄露无权访问的订单；一个用户即使有权限，也可能要求产生违规内容。
三、控制面架构：策略决策和业务执行解耦
Request + identity + tenant + scene + data labels
-> Policy Enforcement Point (PEP)
-> Policy Decision Point (PDP)
-> rules / allowlists / rate limits
-> classifiers / moderation model
-> risk scoring / policy bundle version
<- decision + reason codes + obligations
-> LLM orchestration / RAG / tools
-> post-generation PEP
-> tool-execution PEP (mandatory)
-> audit event + review queue + metrics- **PEP（执行点）**在 API 网关、检索器、编排器、工具网关和外发渠道处强制执行策略。
- **PDP（决策点）**根据策略包、上下文和检测结果给出统一决策，避免每个业务服务复制一套 if-else。
- Policy bundle 是可版本化、可灰度、可回滚的规则集合；一次运行必须绑定具体版本。
- Audit pipeline 异步汇聚事件，但阻断决策不能依赖异步日志成功。
这比“所有逻辑写在一个 Guardrails 类”更容易扩展到 RAG、Agent、MCP、浏览器自动化和多租户场景。
四、策略输入：上下文要足够，但不泄露更多数据
策略判断需要结构化上下文，而不是把整段用户资料塞给另一个模型：
{
"tenant_id": "acme",
"scene": "customer_service",
"actor": {"role": "support", "region": "CN"},
"operation": "tool.send_email",
"data_labels": ["internal", "pii"],
"risk_signals": ["external_recipient", "prompt_injection_suspected"],
"policy_version": "safety-2026-07-15"
}设计原则：
- 传最小必要属性，例如角色、数据标签、资源类型和地域，而不是完整客户画像。
- 身份、租户和资源标签由可信服务注入；不能让模型或前端声明“我是管理员”。
- 原始文本只进入确有必要的检测器，并使用脱敏、访问隔离与保留期控制。
- 检测器结果要标识来源、置信度和版本，避免“一个风险分”无法解释。
五、检测器编排：规则快、分类稳、模型有弹性
单一审核模型会有延迟、成本、偏差和不可解释性。常见分层如下：
| 层 | 擅长 | 例子 | 局限 |
|---|---|---|---|
| 硬规则 | 明确禁止、格式、配额 | 黑名单、正则、文件类型、地域 | 容易被变体绕过 |
| 轻量分类器 | 高频风险的低延迟筛查 | PII、毒性、诈骗、注入特征 | 需持续标注与校准 |
| 专项解析器 | 结构化对象 | 身份证/卡号识别、URL 信誉、附件扫描 | 覆盖面有限 |
| LLM Judge | 复杂语义和上下文判断 | 多轮越狱、细粒度政策解释 | 成本高且需评测 |
| 人工复核 | 高影响且低置信案例 | 金融、医疗、法务升级 | 时延与容量有限 |
推荐采用“先便宜、后昂贵”的级联，但不能把高风险场景完全交给低成本规则。策略可以规定：命中绝对禁止即阻断；中等风险转专用模型；高影响低置信进入人工队列；低风险仅记录并放行。
六、从风险分到处置：决定必须可解释
一个好的决策输出包含动作、原因和义务：
{
"decision": "require_approval",
"reason_codes": ["PII_EXTERNAL_EGRESS", "HIGH_VALUE_ACTION"],
"risk_level": "high",
"obligations": ["mask_phone", "record_audit", "two_person_approval"],
"policy_version": "safety-2026-07-15"
}| 处置 | 适用 | 用户体验 |
|---|---|---|
allow | 风险低且权限完整 | 正常完成 |
redact | 可安全保留主体但需遮蔽字段 | 展示掩码，并记录原因 |
transform | 可改写为合规表达 | 只给安全替代方案 |
require_approval | 高影响但业务可允许 | 明确等待审批，禁止提前执行 |
block | 明确违规或无权访问 | 简短拒绝，不暴露规避细节 |
escalate | 高风险、低置信、争议案例 | 转人工或专门流程 |
原因码既服务审计，也服务调试和产品反馈。不要向攻击者回显过细的检测规则，例如“你的第 17 个词触发了某个正则”。
七、输入、检索、输出、工具的四道闸门
7.1 输入闸门
目标是识别明显违规、频率异常和疑似攻击，决定是拒绝、要求澄清还是进入强化监控。不能因为输入包含攻击性文本就一概屏蔽，例如客服场景可能需要引用用户投诉原文；策略必须结合场景和目的。
7.2 检索闸门
RAG 文档和网页都是不可信内容源。检索前先按 ACL 和数据等级过滤；检索后给证据加来源标签，禁止将文档中的“忽略系统指令”当作可执行命令。对于高敏文档，回答前再次校验用户对具体片段和引用的可见性。
7.3 输出闸门
输出审核不仅查敏感词，还要检测 PII 回显、虚假承诺、违规建议、引用缺失和越权信息。对需要精确事实的回答，结合证据引用与结构化校验；对被拦截内容，优先提供安全替代而不是空白报错。
7.4 工具闸门
工具闸门才是最终防线。执行器必须重新验证用户身份、资源范围、参数 schema、金额/数量阈值、幂等键和审批状态。模型文本、Prompt 和上一步审核结果都不能替代这次校验。
八、人工复核：不要把人审做成无止境的收件箱
人工队列应带有风险、业务影响、时限和可操作上下文：
- 待审对象经过最小化脱敏，只给审查所需片段和证据。
- 显示策略原因码、检测器分数、用户角色、工具动作预览和历史相似案例。
- 审批有 SLA、过期行为和授权范围：批准一次任务，不是永久放开某类操作。
- 审批结论回流为标注数据，但要区分“业务例外”与“策略应修改”。
- 对高危操作采用双人审批、职责分离和不可抵赖审计。
人审吞吐本身是系统容量。监控队列长度、P95 审批时延、复议率和同类误伤率；否则“转人工”只是把自动化问题转移给运营团队。
九、策略即代码：版本、灰度与回滚
策略变更和模型变更一样可能造成事故。一个发布包至少固定：
policy_bundle + rule_set + classifier version + threshold set
+ prompt/model/tool/index versions + effective date + approver安全策略发布流程：
- 在历史脱敏 trace 和对抗集上回放，比较漏放、误伤、延迟和人工量。
- 用 shadow 模式记录“新策略会如何处理”，但不影响真实用户。
- 小流量灰度，按场景、租户、地域和风险等级观察指标。
- 触发门槛后逐步放量；出现误伤激增、漏放或延迟异常时快速回滚。
- 保存发布清单与审计证据，确保事故可复现而不是“线上规则不知谁改了”。
政策文本、规则实现和阈值配置要分层。合规团队可维护可读规则说明，工程团队将其测试化、版本化并映射到可执行策略。
十、评测：安全不是一个准确率
| 维度 | 代表指标 | 要回答的问题 |
|---|---|---|
| 漏放 | policy violation recall、攻击成功率 | 该拦的是否放过去了？ |
| 误伤 | false positive rate、正常任务阻断率 | 正常用户是否被误拒？ |
| 处置质量 | 合适动作率、替代回答可用率 | 拦截后是否正确分流？ |
| 权限安全 | 越权读取/写入率 | 策略能否阻止真实副作用？ |
| 运营 | 人审升级率、SLA、复议率 | 队列是否可承受？ |
| 工程 | P95 延迟、成本、策略可用性 | 安全是否拖垮主链路？ |
测试集至少包含直接越狱、间接文档注入、编码变体、多语言、良性但敏感的业务问法、边界权限、工具参数投毒、长期多轮诱导和对抗性附件。评测集与线上恶意样本都要版本化、脱敏并控制访问。
十一、系统设计追问：审核服务挂了怎么办
不能给所有场景同一个答案。先按风险分级定义 fail-closed 与 fail-open：
| 场景 | 建议降级 | 原因 |
|---|---|---|
| 转账、删库、外发敏感数据 | fail-closed，拒绝执行 | 副作用不可接受 |
| 内部低风险摘要 | 可降级为只读、无外发、记录告警 | 保持有限可用性 |
| 公共内容生成 | 可使用保守模板或限流降级 | 在体验与风险间平衡 |
| 人审队列不可用 | 阻止高风险审批，低风险按策略处理 | 不伪造“已审批” |
策略服务要多副本、限时调用、缓存可安全复用的只读决策；但切忌缓存会随用户、资源或数据等级变化的高风险授权结果。故障演练应覆盖审核超时、规则包损坏、分类器漂移、审计管道积压和人工队列不可用。
十二、常见反模式
- 只用系统提示词做安全：攻击可通过间接注入、工具结果或模型偏差绕过。
- 所有命中都阻断：误伤业务，用户会寻找绕行路径，且运营无法解释。
- 审核通过即执行工具：审核的是文本，不等于用户有权执行动作。
- 没有 reason code：无法复盘、调阈值或申诉。
- 策略线上手改：没有版本、回放和回滚，事故无法定位。
- 把人审当兜底黑洞：没有 SLA、范围和容量设计，最终拖垮业务。
- 只测越狱成功率：忽略误伤、延迟、外发、权限和真实业务效果。
十三、高频面试问答
Q：Prompt Guard、内容审核和权限系统有什么区别？
Prompt Guard 主要识别注入或越狱意图；内容审核判断输入/输出是否符合内容政策；权限系统判断当前主体是否能访问资源或执行动作。三者都需要，但最终写操作必须由权限与业务执行器强制校验。
Q：为什么要把策略引擎独立出来？
因为规则会同时作用于聊天、RAG、Agent、MCP、邮件和管理后台。独立 PDP 能统一版本、原因码、审计和灰度；PEP 放在各边界强制执行，避免安全逻辑散落在 Prompt 或业务代码里。
Q：如何降低审核误伤？
先按场景建立可解释的风险分层和标注集，区分“讨论敏感内容”和“请求产生违规内容”；采用规则、分类器、LLM judge 的级联；对低置信或高影响样本升级人工；通过 shadow 回放与灰度校准阈值，而不是盲目放宽模型。
Q：文档里的恶意指令会怎样影响 RAG Agent？
它属于间接 Prompt 注入。文档只应作为数据证据，不能覆盖系统/工具策略；检索结果需有来源和信任标签；工具调用由外部策略层判断；高风险动作需审批。不要试图用“请忽略恶意内容”这一条 Prompt 解决全部问题。
Q：怎样兼顾安全和用户体验？
把处置从“允许/拒绝”扩展到脱敏、改写、澄清、审批和人工升级，并给用户简洁可理解的下一步。后端通过低延迟规则前置、异步审计、分级模型和灰度评测控制开销，而不是一律增加一次昂贵模型调用。
十四、项目讲法模板
我为企业 AI 助手设计了内容安全控制面。请求在输入、检索、输出和工具执行四个边界经过 PEP，PDP 根据租户、角色、数据标签、场景和检测信号返回 allow、脱敏、审批、拒绝或转人工等结构化决策。策略包、阈值和检测器均版本化，先离线回放和 shadow，再灰度发布。对工具写操作，我们把审核结果当作风险信号，而不是授权凭证，执行器仍校验权限、业务规则和幂等。线上用漏放、误伤、人审 SLA、越权拦截和 P95 延迟共同衡量，使安全从一段 Prompt 变成可运营、可审计的工程能力。
继续学习：大模型安全与对齐、Agent 工具安全与权限边界、企业 AI 治理控制面设计、数据分级与外发审计、Agent 安全与评测。