跳转到内容

Scenario 21: Content Moderation 内容审核

你有一个简单的评论区,需要过滤脏话和敏感词。

  • 关键词黑名单(JS数组)
  • 正则匹配检测敏感词
  • 敏感词替换为 ***
  • 实时预览过滤效果

用HTML+CSS+JS做一个带内容过滤的评论发布页面。敏感词列表硬编码在JS数组中 (至少20个词,包含各种变体如拼音、谐音)。用户输入评论时实时检测, 发现敏感词高亮标红提示。发布时敏感词替换为***。评论列表存localStorage。 显示过滤统计:总评论数、被过滤评论数、拦截率。

  • 敏感词实时高亮检测
  • 发布后敏感词被替换为***
  • 评论列表持久化到localStorage
  • 过滤统计数字正确
  • 正则表达式匹配 → Module: 文本处理
  • 实时输入检测 → Module: 事件处理
  • 客户端过滤的局限性 → Module: 安全基础

V2 — 10人用:可配置敏感词库+人工复审

Section titled “V2 — 10人用:可配置敏感词库+人工复审”

敏感词需要动态管理,误判内容需要人工复审。

  • 敏感词库存文件,支持增删改
  • 内容提交后进入审核队列
  • 人工复审界面(通过/拒绝/修改)
  • 审核日志记录

Go+Gin后端。敏感词库存在 data/keywords.txt(一行一个词),提供管理API (GET/POST/DELETE /api/keywords)。内容提交API(POST /api/content), 自动检测敏感词,无敏感词直接通过,有敏感词标记为pending进入审核队列。 SQLite存储内容记录(id, text, status, reviewer, reviewed_at)。 审核台页面:列出pending内容,高亮敏感词,提供通过/拒绝/编辑后通过三个操作。

  • 敏感词库CRUD正常
  • 无敏感词内容自动通过
  • 有敏感词内容进入审核队列
  • 审核操作正确更新状态和日志
  • 审核队列设计 → Module: 工作流
  • 状态机(pending→approved/rejected) → Module: 状态管理
  • 人机协作模式 → Module: 内容安全

内容量增大,纯关键词匹配误判多,需要AI理解语义。

  • 调用外部AI API做文本分类(安全/不安全/疑似)
  • AI自动审核+人工兜底的两级机制
  • 审核结果缓存避免重复调用
  • 审核统计Dashboard

集成AI文本审核。内容提交后:1)先过关键词黑名单(快速拦截明显违规) 2)通过的内容调用AI API(POST到OpenAI/Claude,Prompt:判断内容是否违规, 返回safe/unsafe/suspicious和置信度)。safe且置信度>0.9直接通过, unsafe且置信度>0.9直接拒绝,其余进入人工队列。 PostgreSQL存储审核记录(含AI判断结果和置信度)。Redis缓存相似内容的审核结果 (内容hash → 结果,TTL 1小时)。Dashboard显示:AI准确率、人工处理量、平均审核时长。

  • AI审核正确分类内容
  • 高置信度自动处理,低置信度转人工
  • 缓存命中时不重复调用AI
  • Dashboard统计数据准确
  • AI API集成 → Module: LLM应用
  • 人机协作决策 → Module: 审核系统设计
  • 缓存策略 → Module: 缓存设计

V4 — 1000人用:图片审核+审核工作台

Section titled “V4 — 1000人用:图片审核+审核工作台”

用户开始上传图片,需要图片内容审核能力。

  • 图片OCR提取文字后审核
  • 图片AI鉴黄/鉴暴(调用云服务API)
  • 审核工作台:批量操作、快捷键
  • 审核员绩效统计

图片审核流程:用户上传图片后,1)调用OCR API提取图中文字,对文字走文本审核流程 2)调用图片审核API(模拟调用,返回标签:normal/porn/violence/ad和置信度)。 综合文字和图片审核结果决定通过/拒绝/人工。 审核工作台升级:批量选择+批量通过/拒绝,键盘快捷键(A通过/D拒绝/S跳过), 图片预览+放大。审核员绩效:每人每天审核量、准确率(通过抽检计算)、平均处理时长。

  • 图片OCR+AI审核流程完整
  • 批量操作正确处理多条记录
  • 快捷键操作流畅
  • 绩效统计数据合理
  • OCR集成 → Module: 图像处理
  • 多模态审核 → Module: 内容安全
  • 工作台UX设计 → Module: B端产品设计

V5 — 1万人用:多级审核+SLA监控

Section titled “V5 — 1万人用:多级审核+SLA监控”

审核量巨大,需要分级处理和质量保障。

  • 三级审核流:AI自动 → 规则引擎 → 人工审核
  • 可配置的规则引擎(JSON规则定义)
  • 审核SLA监控(超时告警)
  • 审核质量抽检系统

三级审核流水线:Level1-AI自动审核(处理80%明确内容), Level2-规则引擎(JSON配置规则,如:包含URL且新用户→拒绝, 文本长度>1000且含敏感词→人工),Level3-人工审核(剩余疑难内容)。 规则引擎:支持条件组合(AND/OR)、字段匹配、阈值判断,规则可热更新。 SLA监控:审核队列长度、平均等待时间、超时(>30分钟未处理)告警。 质量抽检:每天随机抽取5%已审核内容,分配给高级审核员复核,计算一致率。

  • 三级审核流转正确
  • 规则引擎规则可热更新
  • SLA超时正确告警
  • 抽检系统不影响正常审核流程
  • 规则引擎设计 → Module: 业务规则引擎
  • SLA监控 → Module: 服务质量管理
  • 审核质量体系 → Module: 质量保障

V6 — 10万+用户:实时流审核+申诉系统

Section titled “V6 — 10万+用户:实时流审核+申诉系统”

海量内容实时产生,需要流式处理和完善的用户申诉机制。

  • Kafka消费内容流,分布式审核worker
  • 审核worker自动扩缩容
  • 用户申诉系统(申诉→复审→结果通知)
  • 审核数据分析(违规趋势、热点话题)

内容发布统一发送到Kafka(topic: content-review)。多个审核worker消费, 每个worker按三级流水线处理。worker无状态,支持水平扩展(根据队列积压自动扩容)。 用户申诉:被拒绝内容可申诉(填写理由),申诉进入独立队列, 由高级审核员处理(不能是原审核员),结果邮件/站内信通知用户。 审核数据分析:违规类型趋势图、新增违规词发现(高频被拒关键词聚类)、 地域/时段违规热力图。数据用于反哺规则引擎和AI模型。

  • Kafka消费无堆积,worker扩缩容正常
  • 申诉流程完整(提交→复审→通知)
  • 申诉不分配给原审核员
  • 违规趋势数据用于规则更新
  • 审核延迟<5分钟(P99)
  • 流式处理架构 → Module: Kafka消费者
  • 分布式worker → Module: 分布式任务
  • 申诉系统设计 → Module: 用户服务