第34章：Tokenizer Fast 内核与特殊符号处理

1 项目背景业务场景客服工单分类系统在处理大量文本时出现了一个诡异的现象：同一个 Tokenizer，用tokenizer(text)（Fast 模式）编码的结果和用tokenizer.encode(text)（Slow 模式）的结果不一致——两串 token ID 差了一个位置。这导致推理时模型收到了和训练时不同的 token 序列，线上准确率波动 2-3 个百分点。排查后发现：代码中混合使用了tokenizer.__call__()和tokenizer.encode()，而前者走的是 Rust 后端的 Fast Tokenizer，后者走的是 Python 后端的 Slow Tokenizer——两者在某些边界情况下的行为有微小差异。更严重的是，运营团队引入了一批新的业务术语（如"闪电退"、“极速赔”），这些词在 BERT 的词表中不存在，全被映射成了[UNK]。分类模型因此完全无法理解包含这些新词的工单。痛点Tokenizer 虽小，但在生产环境中是"多米诺骨牌的第一张"——token 错了，后面全错：Fast vs Slow：Fast Tokenizer 用 Rust 实现，速度快 5-10 倍，但某些边缘情况的处理与 Python 版不同offset_mapping：将 token