内容审核的 AI 化边界：哪些该用模型，哪些该用规则

内容审核的 AI 化边界：哪些该用模型，哪些该用规则

一、模型万能主义正在让审核系统越来越重

过去两年看过的审核系统方案里，有一个明显的趋势：不管什么审核需求，上来就上 BERT、上多模态大模型、上 Agent 工作流。模型是生产环境里的重型武器，但重型武器不是所有场景都需要。

一个实际的例子可以说明问题。某个内容平台用 NLP 模型做"是否包含联系方式"的检测（手机号、微信号、QQ 号）。模型准确率 97%，P99 延迟 150ms。但用正则表达式，"是否包含手机号"的准确率是 99.99%，延迟不到 0.1ms。在这个场景下，用模型不仅更慢、更贵，准确率反而更低。

基础设施不需要漂亮话。AI 是工具，不是信仰。审核系统设计的核心问题不是"能不能用 AI"，而是"这个审核需求用 AI 和用规则的成本-收益比各是多少"。

二、规则引擎的舒适区：确定性匹配

任何可以穷举、不需要语义理解的审核需求，都应该用规则引擎解决。

正则表达式：手机号、身份证号、银行卡号、IPv4/IPv6 地址、统一社会信用代码。这些信息的格式是确定的，正则可以做到 100% 准确。一个 11 位数字以 1 开头就是手机号，不需要模型来判断。

敏感词匹配（AC 自动机）：任何有明确词库的违规场景——广告词、竞品词、政治敏感词。AC 自动机匹配的时间复杂度 O(n)，n 是文本长度，单线程在 8 核 CPU 上跑 1000 字文本耗时 < 1ms。没有 GPU 排队、没有网络延迟、没有模型推理的不确定性。

黑白名单（Hash 表）：URL 域名黑名单、用户 ID 白名单、IP 段封禁。O(1) 查找，不需要任何"智能"。

这些方案在延迟、成本、准确率、可解释性四个维度上全面优于模型。确定性匹配场景上模型是降级，不是升级。

// 确定性审核：正则 + AC 自动机 + Hash 查找 的复合管道 type DeterministicReviewer struct { phoneRegex *regexp.Regexp idCardRegex *regexp.Regexp urlBlacklist map[string]struct{} // O(1) 查找 sensitiveMatcher *SensitiveWordMatcher } func (r *DeterministicReviewer) Review(text string) *RuleResult { // 优先级 1：联系方式（正则，最确定，最快） if r.phoneRegex.MatchString(text) { return &RuleResult{Level: LevelViolation, Reason: "包含手机号"} } if r.idCardRegex.MatchString(text) { return &RuleResult{Level: LevelViolation, Reason: "包含身份证号"} } // 优先级 2：URL 黑名单（Hash 查找） urls := extractURLs(text) for _, url := range urls { if _, blocked := r.urlBlacklist[url]; blocked { return &RuleResult{Level: LevelViolation, Reason: "包含黑名单 URL"} } } // 优先级 3：敏感词匹配（AC 自动机） matches := r.sensitiveMatcher.Match(text) if len(matches) > 0 { return &RuleResult{Level: LevelViolation, Reason: "敏感词匹配命中", Matches: matches} } return &RuleResult{Level: LevelPass} }

三、模型的不可替代性：语义理解与模糊模式

规则引擎的上限是"你写的规则覆盖到的所有情况"。它的盲区是：

反讽和阴阳怪气："这真是个好人啊"——在特定上下文中可能是在骂人，不是真的夸奖。规则引擎看词语全是正面的，NLP 模型看上下文才能识别反讽。

同音替换和形近字：把违规词中的某个字换成同音字或形近字，规则引擎的 Trie 树匹配不到。模型通过语义向量可以通过上下文推断意图。

图片/视频/音频的违规内容：这些内容的违规特征不是字符级别的，是像素、频谱、时序级别的。规则引擎无法处理非文本数据，只能靠 CV、ASR 等模型。

模型在这些场景下的准确率不是 100%。反讽检测的准确率通常在 70%-85% 之间，同音替换识别在 80%-90%。但规则引擎在这些场景下准确率是 0%——或者说根本没有能力检测。所以"模型 70%" vs "规则 0%"，前者是必要选择。

还有一个不容易被量化的维度是黑产对抗的响应速度。规则引擎的迭代路径是：安全团队发现新违规模式 → 总结为规则 → 写入词库 → 上线。这个周期通常需要数小时到一两天。模型的泛化能力可以在没有新增规则的情况下识别变体违规，在黑产爆发初期提供第一层拦截。等规则团队把变体加入词库后，规则引擎的确定性优势再发挥第二层作用。

四、混合架构建模：按确定性和成本做分流

一个务实的审核架构不是"规则优先"或"模型优先"，而是按审核需求的确定性程度和单次成本做分层分流。

第一层——规则引擎（延迟 < 1ms，成本 ≈ 0）：处理所有确定性匹配需求。正则、AC 自动机、Hash 查找。这一层的目标是拦截所有"明确违规但易于识别"的内容，让它们不要进入后续的昂贵环节。预期拦截率：60%-80%。

第二层——轻量模型（延迟 < 100ms，成本低）：TextCNN、FastText 等轻量 NLP 模型。处理"不是确定匹配但有明显语义特征"的审核需求。例如判断一条评论的情感倾向、是否包含辱骂语义。预期拦截率：剩余内容的 40%-60%。

第三层——重型模型（延迟 < 500ms，成本高）：BERT、多模态大模型。处理前两层都无法确定的模糊边界内容。例如反讽、跨语言违规、图文混合违规。预期拦截率：剩余内容的 30%-50%。

第四层——人工审核：前三层都判定为"疑似"的内容。人工是最昂贵但最准确的最终裁决。

四层的总拦截率目标：99.5%+。每一层拦截后剩余的内容量递减，而越往后单次处理的成本越高。这个漏斗结构的核心目的是把昂贵的模型和人工资源用在真正需要"智能"的边界案例上，而不是浪费在正则就能解决的问题上。

五、总结

内容审核的 AI 化边界，遵循一个简单原则：确定性用规则，模糊性用模型。

1. 正则、AC 自动机、Hash 查找：处理格式确定、穷举完备的审核需求。准确率 99.9%+，延迟 μs 级，成本趋近于零。
2. 轻量 NLP 模型（TextCNN/FastText）：处理有语义特征但不复杂的审核需求。准确率 85%-95%，延迟 < 100ms。
3. 重型模型（BERT/多模态大模型）：处理反讽、跨语言、图文混合等复杂场景。准确率 70%-90%，延迟 < 500ms，但 GPU 成本和排队等待是硬开销。
4. 人工审核：前三层都搞不定的边界案例。人力成本高，但准确率最高。

不要让重模型做轻规则的活。一个用正则就能 100% 解决的问题，用模型不是"更智能"，是更浪费 GPU 和用户时间。