详细解释
Guardrails（护栏 / 安全护栏，行业常直接用英文原词） 类比高速公路两侧的护栏：你车开歪了不会直接翻下山，而是被护栏弹回去。在 LLM 应用里，“开歪了”就是：用户写了 Prompt Injection、模型输出了涉黄涉暴 幻觉、Function Calling 参数带 SQL 注入、JSON 格式少一个括号……Guardrails 把这些统统拦在用户看到之前、或真正执行副作用之前。
Guardrails 不是单一组件，而是一组分层防御，从”输入前 → 模型推理 → 输出后”分四道：
| 层（按执行顺序） | Guardrails 类型 | 做什么 |
|---|---|---|
| 1. 输入侧护栏（Input Guardrails） | PI 检测 / 越狱 检测 / 内容审核 / PII 识别 | 在 Prompt 还没到模型之前就拦截，比如命中 Base64 编码的恶意指令、带了”忽略之前所有指令”模式 |
| 2. Prompt 护栏（System Prompt Enforcement） | PII 脱敏 / 白名单工具参数校验 / 上下文注入 | 比如把用户输入里的身份证号脱敏再拼进 System Prompt、Function Calling 参数再走一次 JSON Schema 验证 |
| 3. 推理时护栏（In-Time Guardrails） | 对数概率阈值 / Token 黑名单 / 结构化生成 | 开 Logprobs，低 logprob 句子直接丢弃；生成时禁止输出某些词； JSON Mode 强制合法 JSON |
| 4. 输出侧护栏（Output Guardrails） | 内容审核 / RAG 归因检查 / 事实一致性校验 / 代码 AST 检查 / PII 过滤 | 模型输出还没给用户前，再过一遍：发现仇恨言论就替换成”抱歉无法回答”；RAG 回答引用不匹配文档的就删掉对应句子 |
Guardrails ≠ 内容审核 Content Moderation。内容审核只是输出侧护栏的一小块。一个完整的 Guardrails 包含”输入、格式、参数、副作用、事实一致性”等多个维度。
代表开源项目：NeMo Guardrails、Guardrails AI、Llama-Guard 系列；SaaS：唯元智创 网关内置 8 层 Guardrails、Microsoft Azure Content Safety。
一份可用的”基础版”护栏清单（任意 LLM 应用必加 8 条）
| # | 护栏名 | 触发条件 | 动作 |
|---|---|---|---|
| 1 | Prompt Injection 检测 | 命中 20+ 种常用注入模式（忽略之前所有指令 / Base64 可疑块 / 长重复字符 DoS 等） | 直接 400 拒绝，消费上限 计入告警 |
| 2 | 长度熔断 | Prompt tokens 超过配置上限（比如 32K） | 拒绝 + 建议”拆分上传”，防止撑爆 KV |
| 3 | Function 参数白名单校验 | action: delete_order 的 order_id 不在用户可访问的订单集合里 | 拒绝 + 记录风控日志 |
| 4 | JSON Schema 校验 | 模型输出的 结构化 JSON 无法通过 JSONSchema 解析 | 自动 Retry 1 次（“请输出合法 JSON，Schema 如下：…”），再失败走兜底模板 |
| 5 | 有害内容 4 分类（Hate/Sexual/Violence/Self-Harm） | 任一类命中阈值 0.8 以上 | 输出替换为标准拒绝话术 |
| 6 | PII 检测（输出侧） | 模型回复中出现”身份证号 / 银行卡号 / 手机号 / 邮箱 + 姓名组合” | 掩码（138****1234）后再输出 |
| 7 | RAG Groundedness 检查 | 对 RAG 回答逐句算与检索上下文的语义相似度，低于 0.6 的句子来自模型脑补 | 标红 / 整句删除，再让 LLM “只根据提供的上下文重写答案” |
| 8 | 副作用二次确认（Human-in-the-loop） | 操作是”发送邮件 / 打款 / 批量删除 / 发布公告”等有副作用类型 | 暂停执行 → 发审批卡片，等人类点确认再跑 |
以上 8 条，唯元智创 作为聚合网关默认给所有接入方开了 1/2/5/6 四条（开关可关），3/4/7/8 需要你业务传 schema 或规则 ID 启用。
三种典型实现方式（复杂度从低到高）
| 方案 | 原理 | 延迟影响 | 适合谁 |
|---|---|---|---|
| 正则 + 关键词 + LLM-as-Judge | 你自己写 200 条规则 + 用 LLM 再判一次 “以下回复是否违规：[Yes/No]？” | 加 300 ms ~ 2 s（取决于 Judge 模型） | 10 万日活以下 MVP，研发 0.5–2 人周 |
| 开源小模型本地跑 | 部署 Llama-Guard 3 / Qwen-Safety / 自训分类器做推理侧过滤 | 加 50 至 200 ms，吞吐可控 | 中大型公司，数据不出域 |
| 商业 Guardrails SaaS（含人类审核） | 第三方厂商提供 API + 人审工单 + 监管报表 | 200 ms~1s，高可用 | 金融/医疗/教育强监管行业，直接买合规能力 |
常见问题
加了 Guardrails 会把正常请求误杀吗？
会的，这就是”精确率 vs 召回率”的经典权衡。生产上建议先”只记录不拦截”跑一周（Shadow Mode）：你先把 Guardrails 当作纯日志工具，看它标记为”违规”的请求里真实误杀率是多少，再调阈值。否则一上来就拦截，很可能把 5% 的正常用户对话挡在门外，客服炸锅。唯元智创 控制台专门有 Guardrails Shadow Mode 的页面，可直接导出 Excel 分析误杀率。
模型本身的 RLHF 对齐还不够吗，为什么要叠 Guardrails？
不够。RLHF / DPO 对齐解决的是”模型分布层面的安全”——平均来说它愿意回答安全的；Guardrails 是”单条请求层面的程序确定性拦截”——只要出现某个模式就一定拦下。举个生活例子：模型对齐相当于”你从小教孩子不做坏事”，Guardrails 相当于”出门之前检查背包有没有危险品”。两者职责不同，组合起来才是完整的纵深防御。
Guardrails 放在应用侧做还是网关侧做？
推荐”网关做通用 + 应用做业务特有”的双层分工：网关层（如唯元智创）：通用的 PI 检测 / Jailbreak / 4 分类有害内容 / PII / JSON Schema 校验——这些每个应用都需要，统一做最省人力；你的应用侧：业务特有规则，比如”医疗场景回答里不允许出现药名推荐 + 诊断结论”、“财务场景数字必须有来源锚点”——这些和你的业务强绑定，网关没法猜。实践中 90% 的拦截事件都能在网关层解决。