按隐私类型拆分测试，揪出静默漏检

脱敏系统最难发现的错误，往往是敏感信息根本没被识别出来：输出正常，日志安静，数据却原样通过。作者用每类约 40 条合成样本，分别检查个人可识别信息（PII）的召回率，发现保加利亚语中的信用卡号识别完全失效。

这次实验的价值，是把「整体效果还行」拆成能定位问题的结果。它还验证了一个实用判断：固定样本的小测试，可以及时发现某类检测能力悄悄消失，但不足以证明真实业务里的脱敏已经可靠。

一个总召回率，为什么会遮住整类漏检

召回率衡量的是：应该识别的敏感信息中，系统找出了多少。脱敏链路里，识别是第一步；这一步漏了，后面的替换和恢复即使完全正确，也无从补救。

作者此前讨论脱敏层时，一位读者指出了两类错误的区别：恢复被遮蔽的值出了问题，输出通常肉眼可见地不对；检测器没认出电话号码，结果却可能看起来毫无异常。

因此，只报一个整体召回率不够。例如 0.85，既可能表示各类信息都识别得尚可，也可能表示邮箱识别很好、信用卡号大量漏掉。平均值相同，修复方向却完全不同。

脱敏测试需要回答「哪一类漏了」，不能只回答「总共找回多少」。

作者采用的办法是植入式金丝雀测试（canary）：主动放入位置已知的假敏感信息，再检查系统是否找到了它们。这里的「金丝雀」就是提前准备的报警样本。

固定的假数据，怎样测出真实配置漏洞

作者用固定随机种子的脚本生成合成数据，并冻结生成方式。测试类型包括名字、姓氏、邮箱、电话、信用卡号、日期、城市、街道，以及通过校验规则、但完全虚构的保加利亚个人号码。

生成器把这些值放进中性句子，例如「请联系某人处理续期」，同时记录准确的字符区间。这样，标准答案在生成时就有了，不需要事后人工标注。数据来自库生成结果或公开公式，没有使用真实登记记录，也没有取自人工标注数据集。

测试沿用作者此前的组件组合：Presidio 负责组织检测流程，XLM-RoBERTa NER 模型识别人名等实体，模式识别器处理有固定格式的标识符。NER 即命名实体识别，可以理解为从句子里找出人名、地名等内容。

本次共测试 240 条英语样本和 280 条保加利亚语样本。邮箱在两种语言中的召回率都是 1.000；信用卡号在英语中只有 0.700，在保加利亚语中则为 0.000。

同一语言内，最好与最差类型的差距，英语达到 30 个百分点，保加利亚语达到 100 个百分点，均超过实验开始前登记的 20 个百分点门槛。

这些结果说明，按类型拆分确实揭示了明显短板。不过，合成样本上的邮箱满分，只能说明这批样本全部通过，不能推导为真实邮件地址都能识别。

信用卡号漏检，问题出在模型之外

保加利亚语信用卡号的召回率为零，作者于是直接检查识别器注册表。

原因很具体：信用卡识别器只注册在英语配置下。一张卡号即使出现在保加利亚语句子中，也不会被交给能够识别它的组件。系统不抛异常，因为执行流程没有报错；缺失的是这组语言与实体类型的检测覆盖。

同一套组件中的一些国家身份标识识别器，会显式注册到所有支持的语言下，信用卡识别器却没有这样配置。这个差异此前没有被对应测试碰到。

另一个缺口与语言无关：长度超出识别器预期范围的卡号，在英语中也会漏检。原文没有给出具体长度范围，无法据此列出完整的失效边界。

作者还做了一次人为故障注入：关闭电话模式识别器，再运行同一批样本。两种语言的电话召回率都下降了 75 个百分点，其他所有类型的召回率变化恰好为零。

这验证了测试能够针对这次故障准确报警。但它模拟的是关闭组件，并没有覆盖阈值调整、模型更新等其他回归方式。

还有一个容易误读的地方：作者所说的持续检查，目前仍是可复现的固定种子脚本，尚未成为定时运行的任务。

我的判断

我认同把「语言 × 实体类型」作为脱敏测试的重要维度。此次最有说服力的发现，是注册配置让一整类输入绕过了识别器。面对这种问题，先核查组件是否参与执行，比直接换模型更切中原因。

与整体召回率相比，分类结果更方便定位；与真实标注语料相比，合成样本的位置准确、成本低，也便于重复运行。两者适合配合使用：合成样本检查已知能力有没有丢，真实语料检验业务表达是否覆盖充分。

局限也很明确。每类约 40 条样本，足以暴露本次这种完全失效，却不足以精确估计一般水平的召回率。中性句子也没有充分模拟真实输入中的噪声和复杂上下文。

实验只覆盖英语和保加利亚语，没有中文结果，也没有检查其他语言。此外，原文没有报告误报率，无法判断提高检出率会不会同时误伤正常内容。

这是一组有效的故障发现证据，还不是整套脱敏方案可靠性的证明。

作者展示了具体漏检和一次回归测试，但没有给出与其他测试方案的成本、效果对照，不能据此断言它是最佳方案。

能拿来做什么

• 在 Node 服务或 AI 应用的脱敏链路中，按实际支持的语言和 PII 类型准备固定合成样本，并在生成时保存字符区间，让每次修改都有可重复的检查依据。
• 如果项目使用 Presidio 或类似的识别器注册机制，逐项核查敏感信息类型是否在目标语言下启用，尤其检查卡号这类容易被当成与语言无关的标识符。
• 修改识别器配置后，分别比较各类型召回率。可以参考作者关闭电话识别器的做法，验证测试是否真的会报警，再将脚本接入现有持续集成流程。
• 将小样本测试用于发现明显缺口；评估上线质量时，再补充符合业务表达的标注样本，并同时检查漏检和误报。