数据工程·PII 脱敏实验室
《AI 数据全书》· 第 8 章 · PII 识别与脱敏「张主任下周来视察」——正则零命中、NER 置信度 0.58、只有 LLM-Judge 能定。检测精度决定「能不能信」，处置动作决定「信了之后怎么办」
⚖️ 合规框架切换后下方 13 类目按该法规重排「必处理」优先级
GDPR任何个人信息必须脱敏或征得同意
诚实性说明：第 1 层「正则 + 校验和」在浏览器内真实执行——15 条 pattern 是真实 JS RegExp，身份证校验和按 GB 11643 加权模 11-2 真算，改正则即时重算。 第 2 层 DeBERTa-v3 NER 与第 3 层 LLM-Judge 的命中区间是人工标注的真值，本工具不调用任何模型；三层的召回率/延迟数字引自 §8.2.5 表格的文献值，非本工具实测。
🧪 八篇陷阱样本（每篇都让某一层单独失败）
S1 职务称谓「张主任」
第 1 层完全失效真值待脱敏实体：张主任
内部通知：张主任下周来我司视察工作，请各部门做好准备。
§8.2.5 原文点名的例子。正则零命中（没有号码/邮箱这类固定形态）；NER 置信度 0.58，低于常见 0.6 阈值会被直接丢掉；只有第 3 层能结合「内部通知 + 视察」的语境判定它指向某个特定自然人。
🧑⚖️ 本样本属 RedactionBench 的 contextual（上下文）档 —— 人在这个档位上只有 47.7% 一致
张主任（conf 0.88）—— 职务称谓是否指向特定自然人，完全取决于「内部通知 + 视察」的上下文。既然人在这个档只有 47.7% 一致，评估 LLM-judge 时不应期待 90%+ 的一致率； 上面对 span 给出的 0.8x–0.9x 这种「比人还自信」的读数本身就是可疑的。（📖 arXiv:2606.18782，200 份人工标注文档 / 11 领域 / 80+ 参与者；强制档 89.4%、安全保留档 94.1%）
合并后 span（按位置排序）
L2L3
张主任PERSONTier1conf 0.94✓ 真值结合「内部通知 + 视察」语境，判定为指代特定个人的称谓
📊 召回 / 误报仪表
仅第 1 层 · 召回0.0%
TP 0 / FP 0 / FN 1
第 1+2 层 · 召回100.0%
TP 1 / FP 0 / FN 0
三层合并 · 召回100.0%
TP 1 / FP 0 / FN 0
三层合并 · 精确率（1 − 误报占比）100.0%
全 8 篇样本累计（真值共 9 个实体）
L1
TP 3
FP 0
L1+2
TP 7
FP 1
L1+2+3
TP 9
FP 2
注：这是 8 篇陷阱样本上的表现，样本是刻意挑选的困难案例，不代表 §8.2.5 的 ~92% / 95-97% / 99.4% 全量指标。
🏗️ 三层防御架构（§8.2.5 文献值）
第 1 层 · 正则 + 校验和(Checksum)本工具真跑
召回 ~92% · 延迟 <1ms/doc · 高精度快速过滤
第 2 层 · DeBERTa-v3 NER人工标注
召回 95-97% · 延迟 ~10ms/doc · 高召回语义识别
第 3 层 · LLM-Judge (gpt-4o-mini / Claude Haiku)人工标注
召回 ~99.4%（合并后） · 延迟 ~500ms/span · 歧义消解 + 跨句共指
三层合并后总体指标：召回 99.4%、误报 1.7%（§8.2.5 原文）。
🔀 merge 层四步（§8.2.5 原文）
span 去重
同一位置的多层命中合并为一个 span（按文本定位，本工具以字符串定位代替偏移量比对）
本样本merge 过程
第 1 层原始命中0 个
第 2 层标注命中1 个
第 3 层标注命中 / veto1 / 0
合并最终结果1 个
🔴 第 2 步「标签规范化」默认了一个已被证伪的前提
🔴 类型名对齐 ≠ 标注可比：2610.22597 合并 77 个公开数据集时发现，即便把所有类别映射到同一 schema，各数据源对「什么算一次检出」的判定仍会互相矛盾（span 边界怎么划、上下文词算不算进 span），该工作为此对 1.12M 样例全部重新打标。
对本工具的直接后果：在合并之前必须先统一「检出」的定义 —— 否则「多层交叉验证加权」是在给不可比的量做加权平均：加权后的置信度看起来更可信，实际是把口径差异伪装成了置信度。
对本工具的直接后果：在合并之前必须先统一「检出」的定义 —— 否则「多层交叉验证加权」是在给不可比的量做加权平均：加权后的置信度看起来更可信，实际是把口径差异伪装成了置信度。
「什么算一次检出」的定义：
只框实体本身，不含修饰词与标点
原文：
患者 张伟 于上月入院检出 span：
张伟长度 2 字符原文：
联系方式：13812345678。检出 span：
13812345678长度 11 字符原文：
北京市海淀区中关村南大街5号检出 span：
北 京市海淀区中关村南大街5号长度 14 字符🧮三种定义下，加权置信度都是同一个数
把三条 span 都当作「三层一致命中」（conf 0.80 / 0.78 / 0.76）喂给
mergeConfidence()， 三种定义下算出的置信度全是 0.90 ——数值相同，含义完全不同。这就是「口径差异被伪装成置信度」的可亲手复现形态。⚠️ 修法：合并之前先统一「检出」的定义，否则加权只是在给不可比的量做平均。🧩 第 1 层正则表（§8.2.1，浏览器内真实执行）
🐛 找 bug 卡：本工具自己的银行卡正则曾漏检 16/17 位卡号（off-by-two， 已修）
修复前
\b62(?:2202|...|2240)\d{12,15}\b：6 位 BIN + 12–15 位 = 总长 18–21 位， 而银联卡号标准 16–19 位 → 16 位与 17 位卡号整体漏检。工具 S8 样本恰好取了 19 位，所以这个 bug 从未暴露。现已改为 16–19 位。16 位
旧✕新✓
17 位
旧✕新✓
18 位
旧✓新✓
19 位
旧✓新✓
⚠️ 顺带一提：书籍自己的正则 BIN 白名单漏了 22 → 它连 §8.1.1 类目表里自己举的 622202xxxxxxxxxxxx 都匹配不上。建议反馈书籍编辑。
身份证校验和按 GB 11643 加权模 11-2 真算：权重
[7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2]，校验码表 1,0,X,9,8,7,6,5,4,3,2。 S3 的 11010119900307231X 校验位应为 6，实际 X，因此被判为无效号码。📋 13 类 PII「必处理」优先级 · 按 GDPR 重排（§8.1.1 原表）
| # | 类目 | 例子 | 风险等级 | 必处理 |
|---|---|---|---|---|
| 1 | 身份证号 | 110101199001011234 | 极高 | 必脱敏 |
| 2 | 护照号 | E12345678 | 极高 | 必脱敏 |
| 3 | 银行卡号 | 622202xxxxxxxxxxxx | 极高 | 必脱敏 |
| 4 | 信用卡号 | 4532-xxxx-xxxx-xxxx | 极高 | 必脱敏 |
| 5 | 医疗信息 | 糖尿病、HIV | 极高 | 必脱敏 |
| 6 | 种族宗教 | 维吾尔族 / 穆斯林 | 高 | 视场景 |
| 7 | 生物特征 | 指纹 / 虹膜 / 人脸 | 极高 | 必脱敏 |
| 8 | 邮箱 | user@gmail.com | 高 | 必脱敏 |
| 9 | 电话 | +86 138-xxxx-xxxx | 高 | 必脱敏 |
| 10 | API Key | sk-xxxxxxxxxx | 高 | 必脱敏 |
| 11 | AWS Key | AKIA... | 高 | 必脱敏 |
| 12 | 姓名地址 | 张三 / 北京市海淀区... | 高 | 视场景 |
| 13 | IP 地址 | 192.168.1.1 | 中 | 推荐脱敏 |
排序 = 风险等级（极高 3 / 高 2 / 中 1）+ 该法规的侧重加权；风险等级与「必/推荐/视场景」标记全部照抄 §8.1.1 原表，加权为本工具为实现排序所加。 切到 HIPAA 看医疗信息如何跃居首位。
内容参考《AI 数据全书》第 8 章「PII 识别与脱敏」· 阅读原章节 → · 系列首页：数据工程·全景驾驶舱 →
第 1 层「正则 + 校验和」在浏览器内真实执行（15 条 JS RegExp + GB 11643 加权模 11-2 校验位），改正则即时重算； 第 2 层 DeBERTa-v3 NER 与第 3 层 LLM-Judge 的命中区间为人工标注的真值，不调用任何模型； 三层召回率/延迟（~92% / 95-97% / 99.4%，误报 1.7%）为引自 §8.2.5 表格的文献值，非本工具实测 —— 且这三个数字全章无脚注、无引 用、无评测集描述，是工程经验值、不是公开基准实测，不能当 SLA 用（口径限定与 REDACT 反证见 Tab ⑤）。 哈希为 FNV-1a 32bit、加盐为 mulberry32 确定性伪随机，均为演示用途，不是密码学强度。 章节中标注「待验证」的内容（§8.2.5 Tier 分级、§8.4.1 可逆脱敏失败模式、Presidio 三条兼容性必测项）已在对应面板标注出处。
数据与口径快照：2026-10-29（📖 / 🧮 / ⚠️ 三标记：📖 = 论文或书籍文献值；🧮 = 浏览器内真算；⚠️ = 教学模型或编辑判断，非论文结论）。 REDACT 覆盖 25 语种 / 9 种书写系统，锁定语言分层样本 1,000 条；25 语种分摊后单语种样本量很小，中文上宜作相对比较而非绝对 SLA。
🔗 一手源：REDACT（多语种 PII 检测基准） · Strong Multilingual Privacy Tagging at Encoder Speed · Broad and Efficient PII Detection with Unified Labels · RedactionBench（人工一致率分档） · RAT-Bench（重识别风险） · Veil-Then-Reveal（可逆伪匿名化） · Meddies-PII（合成临床语料） · PyPI · presidio-analyzer
第 1 层「正则 + 校验和」在浏览器内真实执行（15 条 JS RegExp + GB 11643 加权模 11-2 校验位），改正则即时重算； 第 2 层 DeBERTa-v3 NER 与第 3 层 LLM-Judge 的命中区间为人工标注的真值，不调用任何模型； 三层召回率/延迟（~92% / 95-97% / 99.4%，误报 1.7%）为引自 §8.2.5 表格的文献值，非本工具实测 —— 且这三个数字全章无脚注、无引 用、无评测集描述，是工程经验值、不是公开基准实测，不能当 SLA 用（口径限定与 REDACT 反证见 Tab ⑤）。 哈希为 FNV-1a 32bit、加盐为 mulberry32 确定性伪随机，均为演示用途，不是密码学强度。 章节中标注「待验证」的内容（§8.2.5 Tier 分级、§8.4.1 可逆脱敏失败模式、Presidio 三条兼容性必测项）已在对应面板标注出处。
数据与口径快照：2026-10-29（📖 / 🧮 / ⚠️ 三标记：📖 = 论文或书籍文献值；🧮 = 浏览器内真算；⚠️ = 教学模型或编辑判断，非论文结论）。 REDACT 覆盖 25 语种 / 9 种书写系统，锁定语言分层样本 1,000 条；25 语种分摊后单语种样本量很小，中文上宜作相对比较而非绝对 SLA。
🔗 一手源：REDACT（多语种 PII 检测基准） · Strong Multilingual Privacy Tagging at Encoder Speed · Broad and Efficient PII Detection with Unified Labels · RedactionBench（人工一致率分档） · RAT-Bench（重识别风险） · Veil-Then-Reveal（可逆伪匿名化） · Meddies-PII（合成临床语料） · PyPI · presidio-analyzer