高并发词汇审查：基于 AC 自动机的 Telegram 群聊发言合规性实时过滤检索

当 Telegram 群聊进入高活跃状态后，每秒可能出现数十甚至数百条新消息。依赖人工审核或逐个关键词遍历，不仅响应速度慢，还容易因并发堆积造成违规内容扩散。

要实现稳定的群聊发言合规性实时过滤，关键不是简单增加服务器，而是选择适合多模式字符串匹配的算法。AC 自动机（Aho-Corasick Automaton）能够在一次扫描中检索大量敏感词，是 Telegram 高并发审核系统的实用基础组件。

🔍 为什么普通关键词匹配扛不住高并发

最直接的实现方式，是让每条消息依次与敏感词库中的词汇进行比较。假设词库包含 10 万个词条，机器人每收到一条消息就执行 10 万次检索，CPU 消耗和响应延迟会迅速上升。

正则表达式虽然比循环匹配灵活，但超大规模正则的编译、回溯和维护成本同样不可忽视。特别是词库频繁更新时，重新构建复杂正则可能阻塞消息处理流程。

AC 自动机将多个关键词组织成Trie 前缀树，再通过失败指针处理匹配跳转。检索阶段只需顺序扫描消息文本，时间复杂度接近 O(N + M)，其中 N 是文本长度，M 是命中结果数量。

⚙️ Telegram 实时审查系统的处理链路

生产环境中的过滤系统不应把所有逻辑塞进 Telegram Bot 的更新回调。更合理的链路是：Webhook 接收更新、消息标准化、AC 自动机匹配、策略判定、执行处置、写入审计日志。

1. 使用 Webhook 接收群聊消息

高并发场景通常优先使用 Webhook，由 Telegram 主动向 HTTPS 接口推送更新。接口应快速完成身份校验和任务入队，避免同步执行耗时审查导致 Telegram 重试。

POST /telegram/webhook
X-Telegram-Bot-Api-Secret-Token: your_secret_token

处理流程：
1. 验证 secret token
2. 提取 update_id、chat_id、message_id
3. 将文本任务写入消息队列
4. 立即返回 HTTP 200

队列可以选用 Redis Streams、RabbitMQ 或 Kafka，具体取决于吞吐量和可靠性要求。消费者必须使用 update_id 或 message_id 实现幂等，防止重复更新导致重复删除、禁言或告警。

2. 在匹配前统一规范化文本

敏感内容经常通过全角字符、大小写变化、零宽字符、同形字或异常空格绕过审查。因此，原始消息不能直接进入关键词匹配器。

normalize(text):
    text = UnicodeNormalizeNFKC(text)
    text = ToLowerCase(text)
    text = RemoveZeroWidthCharacters(text)
    text = CollapseRepeatedSpaces(text)
    return text

标准化规则必须保持可解释性，并保存原文与规范化文本的索引映射。这样在命中关键词后，系统才能准确标记原消息中的对应片段，同时避免误伤表情、链接和多语言字符。

🧠 AC 自动机如何完成多词并行检索

构建阶段先将全部词条插入 Trie，每个节点代表一个字符路径。随后通过广度优先搜索建立 Fail 失败指针，让匹配失败时跳转到当前后缀对应的最长有效前缀。

state = root
for char in normalized_message:
    while state != root and char not in state.next:
        state = state.fail

    if char in state.next:
        state = state.next[char]

    for rule_id in state.outputs:
        emit(rule_id)

词库中即使包含“广告”“违规广告”“代理广告”等重叠模式，自动机也能在一次扫描中返回多个结果。业务层随后根据规则等级、命中位置和上下文决定是否处置。

需要注意，命中关键词不等于确认违规。例如讨论安全案例、引用新闻或管理员发布风险提醒时，也可能包含高风险词汇，因此算法结果应作为策略输入，而不是唯一裁决依据。

🚀 高并发环境下的性能设计

AC 自动机适合构建后重复读取，但不适合在每条消息到达时重新生成。建议将词库编译为不可变自动机快照，由多个工作线程共享，以降低锁竞争和内存复制成本。

词库热更新与版本切换

管理端修改词库后，可在后台构建新版本并完成完整性检查。新自动机准备就绪后，再通过原子引用替换当前实例，正在处理的请求继续使用旧版本，后续请求自动切换到新版本。

activeMatcher = AtomicReference(matcherV1)

newMatcher = BuildMatcher(dictionaryV2)
Validate(newMatcher)
activeMatcher.Store(newMatcher)

词库记录应包含规则 ID、风险等级、语言、启用状态、有效期和策略标签，而不是只保存文本。这样可以支持不同群组使用不同策略，也便于定位某次处置对应的词库版本。

限流、背压与降级

当突发消息量超过消费者处理能力时，系统必须启用背压机制。可以按 chat_id 分区保证同一群聊内的处理顺序，并为高风险群组配置更高优先级。

队列积压时，应优先保留文本审查、管理员告警和严重违规处置。图片 OCR、历史统计等高耗时任务可以异步延迟，避免非核心功能拖慢实时过滤链路。

🛡️ 从关键词命中升级为分级合规策略

成熟系统通常将规则划分为提示、低风险、中风险和严重风险。提示类只记录日志，中风险可折叠或删除消息，严重风险则触发删除、临时禁言及管理员复核。

风险分数 = 关键词权重
         + 重复发送频率
         + 外链风险分
         + 新账号系数
         + 历史违规分

低于 30：记录
30-59：提醒或折叠
60-79：删除并告警
80 以上：删除、限权并人工复核

管理员、可信成员和普通成员可以使用不同阈值，但白名单不应直接绕过全部安全规则。对于诈骗链接、恶意软件下载等严重风险，即使消息来自高权限账号，也应保留检测和告警。

审计日志至少应记录群组、消息、用户、命中规则、自动机版本、执行动作和时间戳。涉及隐私的数据应设置最短必要保留期限，并限制后台访问权限。

📊 上线前必须验证的指标

性能测试不能只看平均耗时，还要关注 P95、P99 延迟、每秒消息处理量、队列积压深度和内存占用。测试数据应覆盖中文、英文、Emoji、超长文本、重复字符和大量链接。

准确率方面需要同时统计误杀率与漏检率，并建立管理员申诉和规则回滚机制。建议先以“只记录不处置”的影子模式运行，再根据真实群聊样本调整阈值。

❓ 常见问题解答（FAQ）

AC 自动机能完全替代正则表达式吗？

不能。AC 自动机适合大规模固定词汇检索，正则更适合电话号码、钱包地址和变形格式等模式识别，两者组合通常更可靠。

词库越大，消息检索速度就越慢吗？

检索耗时主要受消息长度和命中数量影响，不会像逐词遍历那样随词库规模线性增长。词库增大仍会增加自动机构建时间和内存占用，因此应清理重复、过期及无效规则。

机器人为什么无法删除违规消息？

机器人必须加入目标群组，并拥有删除消息所需的管理员权限。同时还要检查消息类型、群组配置以及 Bot API 返回的错误码。

如何减少正常讨论被误判？

可以结合词边界、上下文窗口、成员信誉、发送频率和链接特征进行二次判定。高影响动作应保留人工复核入口，并允许管理员快速恢复消息与修正规则。

基于 AC 自动机的 Telegram 审查系统，真正的价值在于以可预测的性能处理海量词汇，而不是简单地“见词就删”。只有将文本规范化、并发架构、分级策略、审计追踪和人工复核结合起来，才能兼顾实时性、准确性与群聊治理体验。