推理模型在真实业务里承担问答、代码生成、文档摘要等任务，一旦在推理过程中产出有害内容，轻则引发投诉，重则触犯监管红线。所谓推理安全性，核心是在模型已经训练完成、权重固定的前提下，通过外围控制逻辑限制其输出边界。这和训练时做对齐有所不同，推理期防护更强调实时性、可解释与可紧急下线。
推理期有害内容的产生路径
要防止有害内容，先得搞清楚它从哪里冒出来。最常见的是直接诱导：用户用明确违规的问题试探模型，比如索要制作危险物品的步骤。这类请求在输入阶段就能被规则匹配或部分分类器识别。但更麻烦的是间接越狱，攻击者把违规意图拆进多轮上下文，或者单轮里用编码、翻译、角色扮演包裹，模型在长链路推理中逐渐偏离安全区。
另一类风险来自任务本身的副作用。例如让模型总结一篇含暴力描写的原文，它可能原样复述；或者代码生成场景里，模型写出了带后门的脚本。这些不一定源于恶意提问，而是模型缺乏场景化约束。因此推理安全不能只盯用户输入，还要看输出是否适配当前业务允许的范围。下表列出几类典型路径与可控环节：
| 风险路径 | 触发位置 | 推荐拦截层 |
|---|---|---|
| 直接违规提问 | 输入 | 敏感词与意图分类 |
| 多轮语境越狱 | 上下文 | 对话级策略引擎 |
| 任务副作用复述 | 输出 | 输出内容过滤器 |
| 代码类隐蔽风险 | 输出 | AST扫描与规则 |
理解路径之后，防护设计要遵循最小可用原则：能挡在输入前就不让进模型，能拦在输出前就不返回用户。这样即便模型权重本身有瑕疵，系统整体仍可控。很多团队忽略上下文层，只做单条过滤，结果被多轮对话绕开，这是落地时典型的漏洞。
输入与输出双层过滤实现
输入侧最基础的是敏感词表与正则，但对语义变形效果差。更好的做法是接一个轻量分类模型，把请求分为正常、可疑、违规三类。可疑请求进入二次校验或添加系统提示词，违规直接拒答。下面示例用伪代码展示输入网关逻辑，其中包含转义后的标签说明，比如我们限制包含<script>的请求进入以防注入。
def check_input(user_text):
# 基础敏感词，实际可接词典服务
bad_words = ['违禁品', '攻击教程']
for w in bad_words:
if w in user_text:
return 'block'
# 轻量分类器，返回0正常1可疑2违规
score = intent_model.predict(user_text)
if score == 2:
return 'block'
if score == 1:
return 'review'
return 'pass'
raw = '<script>alert(1)</script> 怎么写攻击教程'
print(check_input(raw))
输出侧同样需要过滤器，因为即使输入干净，模型也可能自由发挥。这里可以用另一个分类器对生成结果打分，也可以使用规则匹配已知有害模式。注意输出过滤要在流式返回时支持中断，否则前半段有害内容已经发出。下列代码展示输出流式检测的简单结构：
def stream_filter(gen_tokens):
buf = ''
for tok in gen_tokens:
buf += tok
if harm_classifier.score(buf) > 0.9:
yield '[已拦截]'
return
yield tok
# 模拟生成器
def fake_gen():
for t in ['教你', '制作', '危险品', '步骤']:
yield t
for piece in stream_filter(fake_gen()):
print(piece)
双层过滤不是简单堆砌，要考虑延迟。输入分类若太重，会拖慢首字时间；输出分类若逐字调用大模型，成本极高。实践中多用小模型加缓存，并把确定性的业务规则写成策略文件，由引擎加载，避免每次改规则都发版。
基于策略引擎的护栏设计
相比硬编码，策略引擎把安全逻辑外置。例如用 JSON 描述什么意图禁止、什么字段必须脱敏。推理服务每次请求先跑策略，再调模型。这样业务方改风控标准不需要动模型代码。下面示例是一个策略片段，指明含特定关键词且来自未登录用户时拒绝。
{
"rules": [
{
"name": "anon_block",
"if": {
"user_level": "anonymous",
"text_match": ["违禁", "入侵"]
},
"then": "reject_with_message"
}
]
}
策略引擎还能做上下文级约束。比如记录最近五轮是否出现越狱特征，若命中则本次强制注入系统拒答提示。这种状态管理在单条过滤里做不到。我们常在服务中间层维护会话状态，而不是交给模型自己记忆，更可靠也方便审计。
落地时要注意策略误杀率。太严会伤正常体验，太松则失效。建议先灰度，把拦截日志接出来人工抽检，再调阈值。同时保留降级开关：当过滤服务故障时，可切到仅关键词模式，保证主流程不挂。推理安全是持续运营的事，不是接一次就结束。
审计与效果评估方法
没有度量就没法优化。推理安全要定期用红队用例集去打系统，统计拦截率、误拦率、漏过类型。红队集应覆盖直接违规、变形提问、多轮诱导等。下面代码展示如何用准确率以外的方式看漏过分布。
reports = {'direct': 2, 'variant': 9, 'multi_turn': 14}
total_leak = sum(reports.values())
for k, v in reports.items():
print(k, v, f'{v/total_leak:.1%}')
# 输出说明哪类漏过最多，指导加固上下文层
除了离线评测，线上还要埋点。记录每次拒答的原因码，便于回溯某时段策略是否过激。审计日志中不要写原始敏感内容，可用哈希代替，既满足追溯又合规。推理安全最终目标是让模型在开放场景可用又不失控，这需要工程、策略、算法一起转。
当系统跑稳后，可把部分高频误拦样本反哺输入分类器训练，形成闭环。但记住推理期护栏永远是第一道也是最后一道闸，不能假设模型自身已绝对安全。把架构、代码、运营结合起来，才能真防住有害内容。
inference_safetycontent_filteringmodel_guardrail修改时间：2026-08-13 23:33:34