Telegram必备实用机器人盘点 敏感词动态审查系统：基于 AC 自动机的高并发电报内容合规性过滤教程

在 Telegram 群组、频道、客服机器人和内容社区中，敏感词过滤已经从简单的关键词查找，逐渐发展为一项需要兼顾准确率、吞吐量和可维护性的工程任务。当系统面对大量并发消息时，逐个词调用字符串查找函数，往往会带来明显的 CPU 消耗和响应延迟。

本教程将围绕AC 自动机展开，介绍如何构建一个支持多模式匹配的动态审查系统，用于识别电报文本中的违规词、广告词、诈骗话术和业务禁用词。文章重点讨论算法原理、工程架构、热更新、并发控制以及误报治理，帮助开发者建立一套可落地的内容合规过滤方案。

🔍 一、为什么普通关键词匹配难以支撑高并发

最直接的实现方式，是将敏感词放在数组中，然后对每条消息执行多次 contains 或正则表达式匹配。如果敏感词数量为 N，单条文本长度为 M，那么重复扫描的整体成本通常接近 O(N×M)。当词库从几百条增长到数十万条时，性能会快速下降。

电报内容还存在大小写混用、全角半角混合、插入空格、特殊符号分隔和同形字符替换等问题。因此，系统不能只判断“是否出现了原始词”，还需要完成文本归一化、匹配策略选择、风险等级判定和审查结果记录。

⚙️ 二、AC 自动机的核心原理

AC 自动机可以理解为“Trie 前缀树 + 失败指针”的组合结构。Trie 负责将多个敏感词共享相同前缀，失败指针则让匹配过程在当前路径失败时，快速跳转到另一条可能成功的路径，而不必回到文本起点重新扫描。

构建流程通常分为三个阶段：首先将所有词条插入 Trie，然后通过广度优先遍历计算每个节点的 fail 指针，最后将节点对应的敏感词编号、风险级别和处置策略保存到输出集合中。

type Node struct {
    Next map[rune]int
    Fail int
    Out  []WordMeta
}

type WordMeta struct {
    ID       int
    Category string
    Level    int
    Action   string
}

构建完成后，文本只需要从左到右扫描一次，匹配复杂度接近 O(M+Z)，其中 M 是文本长度，Z 是命中的词条数量。对于大量固定词库和高频消息场景，这种方式通常比逐词扫描更加稳定。

Telegram必备实用机器人盘点 🧱 三、设计动态敏感词库

敏感词不应直接硬编码在程序中，而应存储在数据库或配置中心。每一条记录至少包含词语、分类、风险等级、替换内容、启用状态、创建人和更新时间，方便后续进行审核、追踪和回滚。

在分类设计上，可以区分诈骗、赌博、色情、恶意广告、政治风险、外链推广和内部业务禁用词。不同类别可以使用不同处置策略，例如低风险词执行替换，中风险词进入人工复核，高风险词直接阻断并记录审计事件。

CREATE TABLE sensitive_words (
    id BIGINT PRIMARY KEY,
    word VARCHAR(255) NOT NULL,
    category VARCHAR(64) NOT NULL,
    risk_level INT NOT NULL DEFAULT 1,
    action VARCHAR(32) NOT NULL DEFAULT 'REVIEW',
    enabled BOOLEAN NOT NULL DEFAULT TRUE,
    updated_at TIMESTAMP NOT NULL
);

动态更新不代表每次新增词条都立即修改线上 Trie。更稳妥的方案是由管理端写入数据库，再发布一个词库版本号，由构建服务在后台生成完整的新实例，校验无误后执行原子切换。

🚀 四、高并发场景下的审查服务架构

推荐将系统拆分为词库管理、词库构建、实时匹配和审计分析四个模块。Telegram Bot 或消息接收服务只负责提取文本并调用匹配接口，复杂的词库构建工作在后台执行，从而避免管理操作阻塞消息处理。

线上匹配实例应设计为只读结构。多个并发请求可以共享同一个 AC 自动机实例，避免为每条消息重复分配内存；词库切换时，先生成新实例，再使用读写锁、原子指针或 RCU 思路完成替换。

func (s *Scanner) Scan(text string) Result {
    machine := s.current.Load()
    normalized := Normalize(text)

    state := 0
    result := Result{}

    for _, ch := range normalized {
        for state != 0 && machine[state].Next[ch] == 0 {
            state = machine[state].Fail
        }
        state = machine[state].Next[ch]

        for _, hit := range machine[state].Out {
            result.Add(hit)
        }
    }
    return result
}

需要注意的是，示例中的 map 访问方式仅用于解释流程，生产环境可以根据字符集使用数组、压缩表或双数组 Trie。对于中文词库，直接按 Unicode 字符遍历通常更容易保证准确性，但需要控制节点数量和内存占用。

Telegram必备实用机器人盘点 🧹 五、文本归一化与反规避处理

匹配前应统一大小写、全角半角、Unicode 兼容字符和常见标点形式。对于中文文本，可以根据业务需要移除部分空格与装饰符号，但不能无条件删除所有字符，否则可能改变原句语义并造成大量误报。

建议同时保留原文和归一化文本：归一化版本用于算法判断，原文用于审计、人工复核和必要的用户提示。对于同形字符、拼音、谐音和图片文字，则应通过规则扩展、OCR 或模型辅助识别，不能仅依赖 AC 自动机解决。

func Normalize(input string) string {
    s := strings.ToLower(input)
    s = norm.NFKC.String(s)
    s = removeSelectedSeparators(s)
    return s
}

归一化规则必须通过样本集验证，尤其要覆盖 URL、用户名、代码片段、电话号码和正常专业术语。对于容易产生争议的词条，应增加上下文规则，例如要求敏感词附近同时出现交易、联系方式或导流表达后再提高风险等级。

🛡️ 六、审查结果、隐私与可观测性

匹配结果不应只有 true 或 false，而应返回命中的词条、位置、类别、最高风险等级、词库版本和建议动作。这样既方便上层服务做差异化处置，也能让运营人员准确定位误报来源。

日志中应避免长期保存不必要的完整聊天内容，可以采用脱敏、哈希或短期留存策略。系统还应监控匹配耗时、平均文本长度、命中率、词库构建耗时、审查失败率和接口超时率，及时发现词库膨胀或异常流量。

{
  "blocked": true,
  "risk_level": 4,
  "categories": ["scam"],
  "matched_ids": [1024, 2048],
  "policy_version": "words-2025-03-01",
  "action": "REVIEW"
}

🧪 七、上线前的测试重点

Telegram必备实用机器人盘点 测试数据应同时包含命中样本、相似词、跨词边界文本、空消息、超长消息和多语言内容。除了验证结果正确，还要进行压力测试，观察不同词库规模下的 P95、P99 延迟、内存占用和垃圾回收次数。

词库热更新必须重点测试版本一致性：新实例构建失败时，旧实例应继续提供服务；切换完成后，所有请求都应能读取到完整结构，而不能出现部分节点更新或数据竞争。部署时还应保留最近几个可用版本，便于快速回滚。

❓ 常见问题解答（FAQ）

AC 自动机适合所有敏感词过滤场景吗？

它非常适合固定词库、多模式匹配和高频文本扫描，但不擅长理解复杂语义。涉及上下文、隐喻、图片或语音内容时，应结合规则引擎、人工审核和模型服务。

新增一个敏感词是否需要重启服务？

不需要。推荐在后台根据最新词库生成新 AC 自动机实例，通过原子指针或读写锁切换，线上请求无需停止即可使用新版本。

如何降低中文审查中的误报率？

可以通过风险等级、上下文窗口、白名单、词条边界和人工复核共同控制。对于常见专业词汇，不建议单独设置强阻断策略，应结合周边语义判断。

Telegram必备实用机器人盘点 系统是否应该直接删除违规电报消息？

处置方式应由平台政策和风险等级决定。低风险内容可以替换或提示，中风险内容进入审核，高风险内容才考虑阻断，同时保留必要的审计信息和申诉渠道。

总体来看，AC 自动机能够显著提升多关键词审查的吞吐能力，但真正可靠的电报内容合规系统，还需要稳定的词库治理、合理的文本归一化、可回滚的热更新机制和完善的人工复核流程。只有将算法效率与运营规则结合起来，才能在高并发、低延迟和低误报之间取得平衡。