内容审核

内容审核这个名头下面，其实捆着两个不同的问题：这个请求该不该处理，这个回复该不该发出去。

两者需要在不同的位置做不同的检查。混为一谈，做出来的系统就会拦错东西。

输入审核

在调模型之前跑。便宜，而且省掉了生成一段注定要丢掉的内容的成本。

它擅长拦下的：明显滥用的请求、露骨的违规内容尝试，以及指向自动化滥用的流量特征。

它拦不好的：任何需要上下文的东西。「怎么把我邻居的猫弄走」这句话，放在园艺论坛里和放在别处是两种意思，而分类器只看得到那串字符。

一个要紧的局限是：输入审核看不到模型会产出什么。看着无害的请求可能产出有问题的回复，反过来也一样——提到敏感话题的请求，得到的往往完全应该是一个正常的好答案。

输出审核

在生成之后、交付之前跑。更贵——token 已经付过钱了——但位置更好，因为它检查的是真正会送到用户面前的东西。

真正要紧的检查就该放在这一侧：

敏感数据。 用模式匹配找出本不该出现的标识符、凭据或个人身份信息（PII）。机械，但可靠。

schema 合规。 没过校验的结构化输出绝不该交付。

内容类别。 对生成的文本跑一个分类器。

基于资料作答。 对检索增强生成（RAG）来说，就是看结论有没有检索到的上下文支撑。它拦下的是幻觉而不是危害，却往往是更值钱的那道检查。

分类器应该放在哪儿

单独发一次模型调用，而不是写成主 prompt 里的一句指令。

理由是结构性的：独立的一道检查，没法被那条已经骗过主模型的 prompt 说服着放弃职责。如果你让同一个模型既作答又自我审查，那么能操纵答案的请求，也就能操纵这道审查。

各家厂商的审核接口都有，而且便宜。小的开源分类器可以在本地跑。用一个通用模型配上专门的评分标准也行，就是更贵。

拦得太多也是故障

这句话要用和「拦得太少」同样的力度说出来，因为它总被当成安全的那一侧，而它并不是。

一个拒绝讨论症状的医疗应用是坏的。一个不肯解释某类漏洞的安全工具是坏的。一个因为检测到敌意就拒接恼火客户投诉的客服系统是坏的。

误拦在事故报告里看不见，在用户那里却极其显眼。要测量它们：对正常流量抽样，数一数被拦掉的有多少，把真实请求上的高拒答率当成一个有人负责的 bug。

这里就要说到基准比例。如果一万个请求里才有一个真的在滥用，那么一个假正例率 1% 的分类器，每拦下一个真滥用，就要拦掉一百个正常请求。真正重要的数字，是在你实际的基准比例上算出的精确率，而不是在平衡测试集上的准确率。

拦住之后怎么办

说得具体些。「这个我帮不了」等于什么都没告诉用户。在能安全说明的范围内点出它属于哪一类，用户才有机会把正当的请求换个说法。

把「拒绝」和「故障」区分开。 用户应该能分辨这是策略决定，还是服务挂了。

对有后果的事情给出申诉通道——尤其是账号相关的处理。

把拦截连同输入一起记进日志。 没有这个，你没法测量误拦，而误拦恰恰是你最需要测量的东西。

收窄范围胜过过滤

最强的审核，是一个范围很窄的系统。

一个只根据检索到的上下文回答产品文档问题的助手，产出有害内容的空间极小。它没有工具，没有通用能力，跑题的请求也检索不出任何有用的东西。

通用助手需要真正的审核，因为它什么都能做。如果你不需要通用能力，那不去做它就等于把问题消掉，而不是把它过滤掉——而且一分钱不花。

要点回顾

• 输入审核便宜，但看不见上下文；输出审核位置更好，因为它看得到真正会送到用户面前的东西。
• 把分类器放在单独的调用里——写在主 prompt 里的自我审查，挡不住同一种操纵。
• 敏感数据模式、schema 校验和基于资料作答的检查，都该放在输出侧。
• 拦得太多是真故障：要在你实际的基准比例上测量误拦，而不是在平衡的测试数据上。
• 拦下要说清原因，连同输入记进日志，有后果的处理要给申诉通道。
• 收窄范围消掉的风险，比过滤更多。

下一篇： AI 治理与合规