3、PII数据类型与识别：常见PII的格式、正则表达式与实体识别方法

端侧PII masking的首要任务，是准确且高效地识别出文本中存在的个人身份信息（Personally Identifiable Information, PII）。在资源受限的端侧环境中，识别策略的选择直接决定了性能开销与掩码覆盖率之间的平衡。本章将系统梳理常见PII（姓名、身份证号、手机号、邮箱、地址等）的格式特征，深入讲解正则表达式（Regex）与基于模型的命名实体识别（NER）两种主流方法，并给出端侧场景下的选型建议与实战案例。

3.1 常见PII的格式特征与分类体系

PII的格式特征决定了识别方法的选择。从端侧工程视角出发，我们将PII分为两大类：强格式PII（具有明确、可枚举的字符模式）与弱格式PII（依赖语义上下文，格式多变）。这种分类直接影响了后续正则表达式与NER模型的权重分配。

3.2 正则表达式：强格式PII的精准识别

正则表达式是端侧PII识别的第一道防线。一个设计良好的正则表达式，可以在微秒级完成匹配，且不消耗额外的内存。但正则表达式也有其局限性：无法处理语义歧义、容易产生误报（如将订单号误判为手机号）、且难以覆盖所有边界情况。

3.2.1 核心正则模式库

// 中国大陆手机号（2023年后新号段）
String regexPhone = "(?<![0-9])(1[3-9]\\d{9})(?![0-9])";

// 身份证号（18位，含X结尾）
String regexIDCard = "(?<![0-9])([1-9]\\d{5}(19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}[0-9Xx])(?![0-9])";

// 电子邮箱（简化版，覆盖绝大多数场景）
String regexEmail = "(?<![A-Za-z0-9])([A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,})(?![A-Za-z0-9])";

// 银行卡号（16-19位，使用Luhn算法二次校验）
String regexBankCard = "(?<![0-9])(\\d{16,19})(?![0-9])";

上述正则中使用了负向零宽断言（(?<![0-9])和(?![0-9])），这是端侧PII masking中极易被忽略的关键细节。如果不加边界断言，一个18位数字中的任意11位连续数字都可能被误判为手机号，导致过度掩码，破坏文本的可读性。

3.2.2 正则匹配的工程化处理

在端侧环境中，正则匹配不能简单地“找到就掩码”。需要考虑以下工程问题：

1. 重叠匹配问题：例如文本“联系电话13812345678转8012”，手机号正则可能匹配到“13812345678”和“13812345678转801”等多个重叠结果。应使用非重叠匹配，或按优先级排序后取最长匹配。
2. 上下文校验：身份证号正则匹配后，应进一步校验出生日期是否合法（如月份01-12，日期01-31），以及校验位是否正确。这能将误报率降低约30%。
3. 性能优化：Java/Android端可使用Pattern预编译；iOS端使用NSRegularExpression预编译。避免在热路径上重复编译正则。

3.3 实体识别（NER）：弱格式PII的语义理解

姓名、地址等弱格式PII无法通过正则有效覆盖。例如，“张三”和“张伟”都是合法姓名，但正则无法枚举所有可能性。此时需要引入基于统计模型的命名实体识别（NER）。端侧常用的NER方案包括：基于CRF（条件随机场）的传统机器学习模型、基于BERT的轻量化预训练模型（如ALBERT、TinyBERT）、以及基于规则+词典的混合方法。

3.3.1 端侧NER模型选型对比

3.3.2 NER模型的端侧部署要点

将NER模型部署到端侧并非简单的模型转换。以下是三个关键工程步骤：

1. 模型量化：将FP32权重量化为INT8，模型体积缩小4倍，推理速度提升2-3倍，精度损失通常控制在1-2%以内。Android端可使用TFLite的Post-training quantization，iOS端可使用Core ML的Weight Quantization。
2. 输入裁剪：NER模型通常有最大序列长度限制（如128/256 tokens）。对于长文本，应使用滑窗策略，但滑窗重叠区域会产生重复识别，需要做去重后处理。
3. 标签映射：模型输出的是BIO标签序列（B-PER、I-PER、B-LOC等），需要转换为实际的PII实体边界。注意处理嵌套实体（如地址中包含公司名）。

3.4 实战案例：混合策略在端侧IM应用中的落地

某即时通讯（IM）应用需要在端侧对聊天消息进行实时PII masking，以保护用户隐私。约束条件为：中端Android手机（骁龙7系CPU），单条消息处理延迟不超过50ms，内存占用不超过30MB。

3.4.1 初始现象与目标

初始方案仅使用正则表达式，覆盖手机号、身份证号、邮箱三类强格式PII。上线后用户反馈：聊天中发送的“张三的地址是北京市朝阳区XX路1号”这类消息，姓名和地址完全未掩码，隐私保护不达标。目标是将PII覆盖率从62%提升至90%以上，同时保持延迟在50ms以内。

3.4.2 分析判断过程

通过日志分析发现：

• 正则部分耗时稳定在2ms，覆盖率62%（仅覆盖强格式PII）。
• 未覆盖的38%中，姓名占18%，地址占15%，其他（如微信号、QQ号）占5%。
• CPU和内存余量充足（当前峰值CPU 15%，内存12MB）。

决策：引入ALBERT-Tiny + CRF的NER模型，采用“正则优先、NER兜底”的混合策略。即先运行正则匹配，对未匹配的文本片段送入NER模型。

3.4.3 实际操作步骤

// 伪代码：混合PII识别流程
List<PIIEntity> results = new ArrayList<>();

// Step 1: 正则匹配（强格式PII）
results.addAll(regexEngine.match(text));

// Step 2: 对正则未覆盖的文本片段，执行NER
List<Span> uncoveredSpans = getUncoveredSpans(text, results);
for (Span span : uncoveredSpans) {
    List<NEREntity> nerResults = nerModel.predict(span.text);
    for (NEREntity entity : nerResults) {
        if (entity.confidence > 0.85) {
            results.add(entity.toPIIEntity(span.startOffset));
        }
    }
}

// Step 3: 去重与排序
results = deduplicateAndSort(results);

3.4.4 结果对比与复盘

复盘经验：混合策略的核心价值在于“让规则处理确定性高的部分，让模型处理语义性强的部分”。但需要注意，NER模型引入的额外延迟并非线性增长——当文本中强格式PII占比高时，送入NER的文本片段少，延迟增量小；反之则延迟增量大。建议在端侧增加一个简单的“PII密度预估”逻辑，当检测到文本中强格式PII占比低于30%时，直接跳过正则阶段，全量送入NER，避免双重处理的开销。

3.5 常见误区与总结复盘

在端侧PII识别实践中，以下误区需要特别警惕：

• 误区一：正则表达式越复杂越好。复杂的正则（如包含大量分支和嵌套）会导致回溯爆炸，性能下降10倍以上。应优先使用简单、确定性的模式，配合后置校验（如Luhn算法、日期合法性检查）。
• 误区二：NER模型精度越高越好。在端侧，模型精度与推理耗时、内存占用呈正相关。一个F1=0.95的BERT-large模型在端侧可能需要200ms+，完全不可用。应选择轻量化模型，并通过置信度阈值和规则兜底来弥补精度损失。
• 误区三：忽略边界情况。例如，手机号正则未加边界断言，导致“订单号13812345678”中的数字被误判；邮箱正则未处理中文域名，导致漏报。边界情况需要在测试集中显式覆盖。
• 误区四：不做性能监控。端侧环境复杂（不同CPU、不同负载），PII识别模块应内置性能日志，记录每次调用的耗时、内存增量、匹配数量。当发现P95延迟超过预算时，应自动降级（如关闭NER，仅保留正则）。