项目初期的审核机制
在之前公司的时候，我被调到另外一个项目组，负责一个刚上线的社交项目。 在熟悉项目、体验功能的过程中，我发现了一个比较严重的问题：项目里的朋友圈功能体验非常差。
当时我随手发一条动态，竟然要等好几分钟才能展示出来。 对于社交类产品来说，这几乎是致命的。做过产品的都知道，圈子/动态是用户活跃度的核心指标，这种体验会大大降低用户的留存。
我去找老板聊了下，才知道问题出在审核机制上：
很显然，这样的体验非常不友好。 于是我提了一个改进方案：引入轮班制。
轮班制上线后，朋友圈的审核延迟问题明显改善，用户体验提升非常大。
用户量暴增后的新问题
随着老板不要命地烧钱买量、打广告，用户就像潮水一样涌进来。 朋友圈的发布量、评论量、私信量一夜之间翻了几倍，审核压力瞬间爆表。
虽然我们已经在轮班制的基础上加派了客服人手，但依旧完全跟不上节奏。 总不能要求客服“1 秒 10 审核” ，这显然不太现实。
更麻烦的是，随着监管越来越严格，我们不得不接入机器审核。于是上线了数美天网的机审服务，但很快就踩了坑：
1）成本高得吓人——每一条内容调用机审都要钱，用户量一上来，费用飙得飞快。
2）误判不少——正常的内容也会被误伤。比如“恐龙”被判成涉恐，“黄子韬”被判成涉黄，用户投诉直接爆。
3）不减反增——本来机审是为了减轻人工压力，结果误判太多，反而让客服需要二次处理，工作量不降反升。
老板看到账单后直接拍板：
“成本太高了，必须给我想办法降下来！”
我们也去和合作方谈，希望拿到点大客户折扣。结果对方很淡定：
“能便宜点，但差不多就这样了。”
至于误判问题，对方轻描淡写地说：“你们多调调模型阈值就行。”
但我们都懂，这根本不是一时半会能解决的。
于是我们就陷入了一个死循环：
老板又不愿意加客服，只剩下一条路：
用技术来破局，既要省钱，又要保证体验和准确性。
所以我们只能从技术手段上想办法： 既要降低机审调用量，节省成本， 又要保证用户体验和敏感词拦截的准确性。
梳理最终的核心目标
前面聊到的几个问题，其实归结起来就是：
基于这些现状，我们重新审视了整个内容审核体系，最终梳理出以下几个核心目标：
1）降低机审调用量—— 尽量把能本地拦截的都拦截掉，只在必要时才调用机审。
2）保证用户体验—— 内容审核要快，朋友圈/评论必须秒级展示，不能再出现“发条动态等好几分钟”的情况。
3）减少误判带来的客 —— 允许后台随时加白/加黑，策略能快速调整，避免一错再错。
4）动态可控—— 敏感词库支持实时更新，Redis Pub/Sub 秒级生效，保证新策略能立刻落地。
5）成本可控—— 第三方机审作为兜底，而不是主力，保证整体审核成本可控。
第一步：先建立自己的“黑名单”体系
最开始，我们发现如果每一条用户内容都直接丢给机审平台（比如数美、天网），成本会非常高，而且很多敏感词本身是高度确定的，根本不需要调用机审。比如涉黄、涉政、涉恐、赌博、广告等，这些词没有争议，一旦出现就是必拦。
所以第一步，我们决定先建立一套自己的本地黑名单体系。自己先维护一份“核心高危敏感词库”，把确定要拦截的词都本地化存储并匹配，做到本地优先拦截，减少外部机审调用。我们设计了一张专门的敏感词表 api_sensitive_words，表结构大概如下：
CREATE TABLE `api_sensitive_words` (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增ID',
`keyword` VARCHAR(255) NOT NULL COMMENT '敏感词',
`type` ENUM('BLACK','WHITE','NORMAL') DEFAULT 'NORMAL' COMMENT '类型: 黑名单/白名单/普通',
`category` ENUM('PORN','POLITICS','TERROR','AD','INSULT','OTHER') DEFAULT 'OTHER' COMMENT '分类: 色情/涉政/涉恐/广告/辱骂等',
`source` ENUM('HUMAN','VENDOR','AUDIT') DEFAULT 'HUMAN' COMMENT '来源: 人工录入/机审回流/客服审核回流',
`status` TINYINT(1) DEFAULT 1 COMMENT '状态: 1启用 0停用',
`hit_count` BIGINT DEFAULT 0 COMMENT '命中次数(统计用)',
`updated_by` VARCHAR(64) DEFAULT NULL COMMENT '最后操作人',
`updated_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最后更新时间',
PRIMARY KEY (`id`),
KEY `idx_keyword` (`keyword`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='敏感词表';
这样设计的好处是：
这一部分做好了，就相当于为整个敏感词体系打下了地基。
第二步：引入 Trie + Aho-Corasick 自动机，实现高性能敏感词匹配
建立了自己的黑名单体系后，接下来就遇到了一个问题：怎么高效地做敏感词匹配？ 我们有了 api_sensitive_words 表，里面可能会有几万甚至几十万条敏感词，如果每次用户发朋友圈、评论、昵称、签名都要去查数据库，那基本上等于自杀。
1、 直接 MySQL 模糊匹配的痛点
我们最开始考虑过直接用 MySQL，比如这样：
SELECT keyword FROM api_sensitive_words WHERE INSTR(:content, keyword) > 0;
或者用 LIKE：
SELECT keyword FROM api_sensitive_words WHERE :content LIKE CONCAT('%', keyword, '%');
这种做法有几个致命问题：
1）性能差 一旦词库过万，SQL 就会非常慢，LIKE 和 INSTR 都没法走索引。 如果并发上来，整个 DB 直接被拖垮。
2）匹配不全 比如用户发了“爆gua新闻”，词库里是“爆料新闻”，MySQL 的匹配是基于字符串的，根本识别不出来。
3）更新不及时敏感词库经常在更新，每次都要走数据库，缓存起来又不方便做模糊匹配。
所以很快我们就放弃了这种方案。
2、那用 ES（Elasticsearch）能解决吗？
有同事提出过用 「Elasticsearch」 做全文检索来解决匹配效率问题。 理论上，ES 的倒排索引确实比 MySQL 快很多，但我们分析后觉得并不合适：
所以 ES 对我们来说有点“杀鸡用牛刀”，最后也被否掉了。
3、Trie + Aho-Corasick 自动机
最终我们选择了基于Trie 树 + Aho-Corasick 自动机的方案。
1）Trie 树的优势
2）Aho-Corasick（AC 自动机）的增强
如果只用 Trie，匹配效率还行，但每次遇到不匹配字符时需要回溯，性能会有瓶颈。 AC 自动机在 Trie 的基础上引入了“失败指针”，让匹配可以“平移”而不是回溯，效率更高。 这样即便有几万条敏感词，也能在毫秒级完成匹配。
3）为什么比 MySQL 和 ES 更合适
第三步：基于 Trie + AC 自动机落地高性能审核体系
我们对比了 MySQL、ES 和 Trie + AC 自动机的业务场景区别，最终我们选择了基于 Trie 树 + Aho-Corasick 自动机 的方案。
接下来，我们就简单实现，构建一套高性能、低延迟、可动态更新的敏感词审核体系，确保在海量用户请求下也能稳定高效地工作。
1、架构设计
核心架构围绕MySQL 持久存储 + Redis 缓存 + Go 内存引擎 + 秒级热更新 + 机审兜底：
┌────────────────────────┐
│ api_sensitive_words │ ← MySQL 持久存储敏感词
└──────────┬─────────────┘
│
后台管理系统增删改词
│
┌──────────▼─────────────┐
│ Redis缓存 │ ← 存储最新词表
└──────────┬─────────────┘
│
Redis 发布订阅 (sensitive:update)
│
┌──────────▼─────────────┐
│ Go 服务内存中的 Trie │
│ + Aho-Corasick 自动机 │
└──────────┬─────────────┘
│
用户请求 → 本地匹配
│ 命中 │ 未命中
▼ ▼
拦截 / 标记 / 上报 调用第三方机审
1）核心思路
2）这样设计的效果总结
在这种架构下，用户在发朋友圈、评论、私信时，99% 的请求只需走内存匹配；只有极少数复杂或新型敏感词才会触发机审，既保证了性能，又有效控制了成本。
2、基于 Trie + AC 自动机构建高性能敏感词检测引擎
在完成了敏感词表设计和架构方案分析后，我们就需要落地一个高性能、可热更新的敏感词检测引擎。
核心目标是：
1）设计思路
我们在设计这套敏感词检测引擎时，有几个关键考量：
①词库加载策略
②检测流程
③高并发优化
这样，99% 的请求在 Go 内存中毫秒级返回，只对剩余 1% 的高风险内容调用机审。
2）代码实现：Go + Trie + AC 自动机 + Redis 热更新
这一节我们落地完整方案，做三件事：
我们来实现一个非常简单的demo示例。
①敏感词检测引擎（ACTrie.go）
用 Trie + Aho-Corasick 自动机实现，支持并发检测 + 秒级热更新。
package trie
import (
"container/list"
"sync"
)
type TrieNode struct {
children map[rune]*TrieNode
fail *TrieNode
isEnd bool
word string
}
type ACTrie struct {
root *TrieNode
mu sync.RWMutex
}
func NewACTrie() *ACTrie {
return &ACTrie{
root: &TrieNode{children: make(map[rune]*TrieNode)},
}
}
// 构建 Trie 树 + AC 自动机
func (ac *ACTrie) Build(words []string) {
ac.mu.Lock()
defer ac.mu.Unlock()
// 重新初始化
ac.root = &TrieNode{children: make(map[rune]*TrieNode)}
// 构建 Trie
for _, word := range words {
node := ac.root
for _, ch := range []rune(word) {
if node.children[ch] == nil {
node.children[ch] = &TrieNode{children: make(map[rune]*TrieNode)}
}
node = node.children[ch]
}
node.isEnd = true
node.word = word
}
// 构建 AC 自动机失败指针
ac.buildFailPointers()
}
func (ac *ACTrie) buildFailPointers() {
queue := list.New()
for _, node := range ac.root.children {
node.fail = ac.root
queue.PushBack(node)
}
for queue.Len() > 0 {
e := queue.Front()
queue.Remove(e)
current := e.Value.(*TrieNode)
for ch, child := range current.children {
failNode := current.fail
for failNode != nil && failNode.children[ch] == nil {
failNode = failNode.fail
}
if failNode == nil {
child.fail = ac.root
} else {
child.fail = failNode.children[ch]
}
queue.PushBack(child)
}
}
}
// 匹配文本
func (ac *ACTrie) Match(text string) []string {
ac.mu.RLock()
defer ac.mu.RUnlock()
var result []string
node := ac.root
for _, ch := range []rune(text) {
for node != ac.root && node.children[ch] == nil {
node = node.fail
}
if node.children[ch] != nil {
node = node.children[ch]
}
// 收集所有可能的命中
temp := node
for temp != ac.root {
if temp.isEnd {
result = append(result, temp.word)
}
temp = temp.fail
}
}
return result
}
② Redis 热更新 + 检测逻辑（service.go）
后台添加/删除敏感词 → 发布 sensitive:update → 内存 Trie 自动重建。
package service
import (
"context"
"log"
"time"
"sensitive/trie"
"github.com/redis/go-redis/v9"
)
// 从 Redis 拉取最新词库
func fetchWordsFromRedis(rdb *redis.Client) []string {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
words, err := rdb.SMembers(ctx, "sensitive:words").Result()
if err != nil {
log.Println("获取敏感词失败:", err)
return nil
}
return words
}
// 监听热更新
func ListenUpdate(ac *trie.ACTrie, rdb *redis.Client) {
sub := rdb.Subscribe(context.Background(), "sensitive:update")
for msg := range sub.Channel() {
log.Println("接收到词库更新事件:", msg.Payload)
words := fetchWordsFromRedis(rdb)
ac.Build(words)
log.Println("Trie + AC 引擎已完成热更新")
}
}
③兜底调用第三方机审（audit.go）
这里我们实现 callVendorAudit 方法，模拟调用第三方机审平台（例如数美、天网），并支持异步回调。
package service
import (
"bytes"
"encoding/json"
"io/ioutil"
"log"
"net/http"
)
type VendorAuditRequest struct {
Text string `json:"text"`
UserID int `json:"user_id"`
}
type VendorAuditResponse struct {
Code int `json:"code"`
Message string `json:"message"`
Risk bool `json:"risk"`
}
// 兜底调用第三方机审
func callVendorAudit(text string, userID int) (bool, error) {
payload := VendorAuditRequest{
Text: text,
UserID: userID,
}
body, _ := json.Marshal(payload)
resp, err := http.Post("https://vendor.example.com/audit", "application/json", bytes.NewReader(body))
if err != nil {
log.Println("调用机审失败:", err)
return false, err
}
defer resp.Body.Close()
data, _ := ioutil.ReadAll(resp.Body)
var result VendorAuditResponse
if err := json.Unmarshal(data, &result); err != nil {
log.Println("解析机审响应失败:", err)
return false, err
}
return result.Risk, nil
}
④敏感词检测入口
func CheckContent(ac *trie.ACTrie, text string, userID int) (bool, []string) {
matches := ac.Match(text)
if len(matches) > 0 {
// 本地命中敏感词，直接拦截
return true, matches
}
// 本地未命中 → 调用第三方机审
risk, err := callVendorAudit(text, userID)
if err != nil {
log.Println("调用机审异常:", err)
return false, nil
}
// 如果机审返回高风险 → 拦截
if risk {
return true, []string{"[机审命中]"}
}
// 否则允许通过
return false, nil
}
我们这样设计思路
内存中 Trie + AC 自动机 → 「毫秒级响应」
机审 QPS 成本高且延迟大，本地检测可拦截绝大多数内容
有些谐音、变体、图文混排等复杂场景，本地 Trie 难以覆盖
我们不放弃机审，而是“只用在必要场景”，降低调用量
后台添加/删除敏感词 → 发布更新事件
Go 服务感知 → 重建 AC 引擎，秒级生效
第四步：引入机审回流机制，减少误判率
在上线基于 Trie + AC 自动机的本地高性能检测引擎后，我们在未命中的情况下会调用第三方机审（例如数美、天网）兜底拦截。
但是很快，我们遇到了一个新的问题：机审的误判率偏高。
1、为什么需要机审回流
一开始，我们和数美平台的同学沟通过，他们建议我们在数美后台调整模型阈值，并多喂数据让平台模型更适应我们的业务。但实践证明：
1）模型调优需要时间
数美的后台虽然可以微调大模型，但这通常需要几周甚至几个月，短期内无法解决。
2）误判直接影响用户体验
大量正常用户的评论、昵称、动态会被错误拦截，造成投诉率上升。
3）过度依赖机审，成本偏高
即便我们用Trie + AC 自动机拦了一部分，剩下的“边缘内容”仍然大量送到机审，每次都要消耗调用额度，且返回的结果未必可靠。
所以我们决定引入一层机审回流机制：
机审命中的内容不再直接信任，而是进入我们的本地回流队列，由运营/算法标注后再落地到敏感词库或白名单。
这样，我们既降低了机审误杀用户的风险，又能持续“喂养”我们自己的本地引擎，让检测效果越来越精准。
2、核心思路
整个机审回流机制的核心是“引入人工二次确认”：
1）用户发内容 → 本地 Trie + AC 检测；
2）如果命中敏感词 → 直接拦截，无需机审；
3）如果未命中 → 调用第三方机审；
4）根据机审返回的状态：
5）后台运营审核候选表，确认结果后：
3、第三方机审返回状态
以数美为例，常见返回状态有三种：
|
状态 |
含义 |
我们的处理 |
|
PASS（通过） |
内容安全，无违规 |
暂时放行，但记录可疑词，供运营复核 |
|
REVIEW（可疑） |
机器检测到风险，需人工确认 |
写入候选表，运营二次审核 |
|
REJECT（拒绝） |
明确违规，不允许放行 |
直接拦截，同时写入候选表，等待人工确认 |
这种分级机制让我们在业务层面更加灵活，既不盲目信任机审，又不会因为误判直接影响用户。
4、新增候选敏感词表
我们新增了api_sensitive_candidates 表，用来记录第三方机审命中的可疑词：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
CREATE TABLE `api_sensitive_candidates` (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`keyword` VARCHAR(255) NOT NULL COMMENT '候选敏感词',
`vendor` VARCHAR(64) DEFAULT NULL COMMENT '机审来源，例如数美、天网',
`risk_level` TINYINT DEFAULT 1 COMMENT '1低风险 2中风险 3高风险',
`status` ENUM('PENDING','CONFIRMED','REJECTED') DEFAULT 'PENDING' COMMENT '状态',
`created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='机审候选敏感词';
5、处理流程示例
func auditContent(userID int64, content string) (bool, error) {
// 1. 先走本地 Trie + AC 自动机
if acEngine.Match(content) {
return false, errors.New("命中本地敏感词，拦截")
}
// 2. 调用第三方机审
resp, err := callShumeiAPI(content)
if err != nil {
log.Printf("[ERROR] 调用机审失败: %v", err)
return true, nil // 容错策略：机审挂了就先放行
}
switch resp.RiskLevel {
case "PASS":
// 暂时放行，但写入候选表供人工复核
saveCandidates(resp.HitWords, "数美", 1)
return true, nil
case "REVIEW":
// 写入候选表，等待客服确认
saveCandidates(resp.HitWords, "数美", 2)
return false, errors.New("内容可疑，等待人工复核")
case "REJECT":
// 直接拦截，同时写入候选表
saveCandidates(resp.HitWords, "数美", 3)
return false, errors.New("内容违规，已拦截")
default:
return true, nil
}
}
func saveCandidates(words []string, vendor string, risk int) {
for _, word := range words {
_, err := db.Exec(`
INSERT INTO api_sensitive_candidates (keyword, vendor, risk_level)
VALUES (?, ?, ?)
`, word, vendor, risk)
if err != nil {
log.Printf("[WARN] 保存候选词失败: %v", err)
}
}
}
6、这样设计的机制优势
第五步：智能化词库演进，让系统越用越准
在引入机审回流机制之后，我们的敏感词检测体系已经形成了一个“人机协同”的闭环：
但是，光靠人工去不断确认候选词，仍然有几个问题：
1）人工压力依然存在
机审每天可能返回上千条候选词，如果全部依赖客服逐条确认，工作量依然巨大。
2）词库维护效率不高
敏感词的热词更新非常快，比如某些热点事件、网络流行词，一旦被用户恶意利用，如果没有及时补充到词库，就会产生“窗口期”。
3）重复误判问题
某些词一旦被误判，如果没有白名单兜底，可能会反复影响不同用户。
所以我们在第四步的基础上，进一步做了一个 「智能化词库演进机制」，让系统能“越用越准”。
1、核心思路
我们把候选词的流转分成三个阶段：
1）机审 → 候选词表
第三方机审命中的内容不直接生效，而是进入 api_sensitive_candidates。
2）二次确认 → 黑白名单
人工确认违规 → 写入黑名单，进入 api_sensitive_words 表；
人工确认误判 → 写入白名单，避免后续重复拦截。
3）自动学习 → 热更新引擎
黑名单 / 白名单更新后 → Redis 发布 sensitive:update → Go 内存引擎秒级热更新；
下次用户再发同类内容时，系统直接在本地完成判定，无需机审。
2、处理流程图
3、表设计优化
在第四步中，我们有两个关键表：
1）机审候选敏感词表（待审核池）
CREATE TABLE `api_sensitive_candidates` (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`keyword` VARCHAR(255) NOT NULL,
`vendor` VARCHAR(64) DEFAULT NULL COMMENT '机审来源',
`risk_level` TINYINT DEFAULT 1 COMMENT '1低风险 2中风险 3高风险',
`status` ENUM('PENDING','CONFIRMED','REJECTED') DEFAULT 'PENDING',
`created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='机审候选敏感词';
2）敏感词主表（黑名单 / 白名单）
CREATE TABLE `api_sensitive_words` (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`keyword` VARCHAR(255) NOT NULL,
`type` ENUM('BLACK','WHITE','NORMAL') DEFAULT 'NORMAL' COMMENT '黑名单/白名单/普通',
`category` enum('PORN','POLITICS','TERROR','AD','INSULT','OTHER') DEFAULT 'OTHER' COMMENT '分类',
`source` enum('HUMAN','VENDOR','AUDIT') DEFAULT 'HUMAN' COMMENT '来源: 人工/机审/审核回流',
`status` TINYINT(1) DEFAULT 1 COMMENT '1=启用 0=停用',
`hit_count` bigint(20) DEFAULT '0' COMMENT '命中次数',
`updated_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='敏感词表';
4、智能化优化点
在人工复核的基础上，我们还做了几层优化：
1）高频候选词自动标记
如果某个词连续多次出现在 api_sensitive_candidates，即使还没人工确认，也可以先标记为“高优先级”，提醒运营重点关注。
2）白名单优先级
如果某个词已被确认进入白名单，即使机审再次判定为违规，也会优先放行，避免反复误判。
3）规则兜底
对于某些常见的变体（比如 Emoji、拼音替代），我们在检测层加了一层归一化处理，让“黄d毒”这种形式也能被映射到“黄赌毒”。
5、初步运行效果
经过这一层机制迭代，我们的系统表现明显改善：
1）机审调用量下降 70%+
因为更多的新词被回流到本地引擎，减少了依赖机审。
2）误判率降低到 <1%
白名单机制避免了大规模误拦，用户体验显著提升。
3）客服压力减少 50%
只有真正疑难的词才需要人工二次确认，重复问题被系统自动兜底。
4）系统自我进化
每次机审命中 → 候选池 → 人工确认 → 黑白名单 → 热更新 → 下次直接拦截 / 放行，形成闭环。
做到这一步，我们的敏感词检测体系从纯人工 → 机审兜底 → 回流机制 → 智能演进，形成了一条完整的进化链路。
可以说，这时候的系统已经具备了简单的自我学习、自我修复的能力。
没命中的内容都丢机审？那成本不还是很高吗？
按照我们上面的流程，如果用户的内容在本地敏感词库和黑名单里都没命中，那下一步就会走机审服务去做二次校验。
但这时候可能就会有同学疑问了：“那我正常内容基本都不会被拦截，是不是就等于所有正常内容都要再过一遍机审？正常内容量那么大，本地黑名单和敏感词库不就成了摆设？这样成本不还是一样很高吗？”
其实不是的哈，我们不是“没命中词库就一股脑全发给机审”。
大部分内容，如果本地的敏感词库和黑名单都没命中，系统会默认它是“正常的”，直接放行，根本不会走机审。
那哪些内容会走机审呢？我们设了一套机制来识别“可疑内容”。不是靠人工，而是靠程序根据几个维度来自动打分的，如下图：
上面的风险因子模型这里我大概解释下：
1、混淆/规避行为（+1 到 +2 分）
用户想发违规词，但又不想被系统拦，就开始搞各种变种：
这些写法本身可能不是黑名单词，但看上去就是故意绕规则的，所以会加分。
2、外链或导流线索（+2 分）
如果一条内容里出现了外部联系方式或引流信息，我们会直接加高风险分，因为这类内容通常和广告、灰产、甚至非法交易有关。
常见表现有：
还有一些更隐蔽的写法：
这些内容虽然不一定包含敏感词，但一看就知道是“在绕规则”引导你加好友或者跳出平台。所以即使它没命中黑词，本地打分也会高，后续一定要再机审一遍，防止放漏。
3、和黑名单词很像（+1 到 +2 分）
哪怕没完全命中黑词，但“像”也得引起注意：
我们会比对编辑距离、拼音等，如果太接近，也会加分。
4、场景权重（+1 到 +3 分）
同样一句话，出现在不同地方，影响也不一样：
原因很简单：越隐蔽的地方，违规后果越严重，所以风险分就高一点。
5、账号和设备特征（+1 到 +2 分）
除了看内容，我们还会看是谁发的、怎么发的。现在搞违规的很多都是灰产，一人控制上百个账号轮流发，这种操作靠内容本身很难识别，但行为上一定不正常。
我们会重点加分这些情况：
这些行为我们统称为 “批量操作”，背后常见的是：
我们会根据这些行为给账号打“风险分”，如果高，就会配合内容一起决定要不要送去机审兜底。
6、批量或模板痕迹（+1 分）
如果内容和以前我们记录的垃圾信息很像，比如：
这种内容多半是“复制粘贴发模板”，会直接打上批量标签，加分。
我们是这样决定“走不走机审”的：
每个场景的 T1/T2 也可以独立配置，比如评论区放宽一点，私信就收紧；新账号要求更高。
另外我们也不会完全信任程序判断，系统里还做了两道补充机制：
1）人工随机抽查：比如每隔一段时间，运营同学会从正常放行的内容里，抽一批出来人工看看，确认有没有“漏网之鱼”。
2）用户举报通道：一旦有用户点了“举报”，我们会触发人工审核，并把结果反推给模型，还会给积极举报的用户发奖励积分。
这样双保险兜底，既防止系统“看不到的盲区”，又让用户参与进来，越来越精准。
总的来说，结合我们前面讲的这些流程和规则，其实这套内容安全系统跑起来之后，有几个很直接的好处：
一是大部分正常内容，压根不会进入机审流程。本地检测机制本身就是为了拦住绝大多数无风险的内容，直接放行，减少不必要的审核开销。
二是风险打分的作用就是“筛可疑”，不是谁都送去机审，只有那些带明显特征、风险比较高的内容，才会进一步校验。这部分内容本身就值得多花一点成本，避免漏掉关键问题。
三是后续的机审结果也不是丢掉就完了，我们会做回流，把命中的典型样本或词语更新进本地词库或规则配置，系统用得越久、识别能力也就越强。
整体看下来，我们这套机制的重点就是：本地为主，机审兜底，规则可控。既能压住整体成本，又不牺牲检测效果，适合长期稳定跑在线上。
至于“风险打分”规则本身，是怎么来的？其实都是我们平时不断复盘“漏网之鱼”来的。一旦发现系统没拦住的违规内容，我们就会反过来分析为什么没识别出来，把这些特征总结出来，慢慢沉淀进风险配置里，系统就是这样一点点被打磨出来的。
一路走到这，我们的内容安全体系长这样
回头看这套敏感词检测，基本就是一路“打补丁 → 优化 → 再进化”的过程：
一开始，全靠人工盯，效率低不说，用户体验还特别差；
后来上了 Trie + AC 自动机，本地内存里就能解决大部分情况；
再后来，为了防止遗漏，就接了机审兜底；
但机审的误判实在多，于是加了回流机制，让客服二次确认，把结果再喂回系统。
整条链路其实就一句话：
“能自己搞定的就自己搞定，搞不定的交给机审，机审再回流回来让自己更聪明。”
1、我们这样做的好处
2、那这套方案还能怎么玩
这套机制并不是只能用在评论和朋友圈。
像用户昵称、群聊名字、私信聊天都能走同样流程。
再往后拓展，图片可以先 OCR 把文字识别出来，视频可以先转语音文本，然后也能丢进检测引擎里。
甚至还能做风险分级：比如评论可以稍微宽松点，私信要严格点。
或者智能提示：某些候选词老是出现，就自动标记高优先级，提醒运营重点盯一下。
最后
说实话，如果单看业务需求，靠人工 + 机审也能凑合把内容审核跑起来。
但身为技术，我们需要考虑的不光是能不能用，还要考虑能不能撑得住规模、能不能压下成本。
人工再加人就是烧钱，机审再开额度也是烧钱，最后账一算，公司运营成本根本顶不住。
所以我们才决定用技术来改造这一块：把能在本地搞定的尽量留在本地，把复杂的丢给机审兜底，再通过回流机制让系统自己进化。这样做下来，不光用户体验提升了，公司在成本上也真正省下了一大块。
回头看，这套内容安全体系已经不只是一个“审核工具”，而是一个能跟着业务规模一起成长的系统。它能抗住流量高峰，也能帮公司省钱，更重要的是，它让我切身感受到——用技术解决问题，能直接改变运营成本。
作者丨洛卡卡了
来源丨公众号：稀土掘金技术社区（ID：juejin1024）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
如果字段的最大可能长度超过255字节，那么长度值可能…
只能说作者太用心了，优秀
感谢详解
一般干个7-8年（即30岁左右），能做到年入40w-50w；有…
230721