PII脫敏基準測試：Regex vs NER vs LLM
regex模式、spaCy NER、GLiNER、基於LLM和混合管道在14種PII實體類型上的精確率、召回率、F1分數、速度和誤報率對比。
PII脫敏是任何企業資料管道中風險最高的階段。解析錯誤產生混亂的文字。分塊錯誤降低檢索品質。PII脫敏失敗則暴露個人資料——觸發監管處罰、侵蝕客戶信任並產生法律責任。
儘管風險如此之高，大多數團隊選擇脫敏方法時依據的是便利性而非實測效能。Regex實作快速。NER模型易於匯入。LLM似乎無所不能。但這些方法在真正重要的指標上——精確率、召回率、誤報率和吞吐量——實際表現如何。
本基準測試提供了答案。
測試方法
我們評估了五種PII脫敏方法，每種代表一種不同的技術策略：
Regex模式：使用正規表達式對結構化PII格式（SSN、電話號碼、電子郵件地址、信用卡號）進行確定性模式比對。我們使用了一個包含47種模式的生產級regex函式庫，涵蓋美國、英國和歐盟的PII格式。
spaCy NER (en_core_web_trf)：spaCy基於transformer的命名實體辨識模型，可識別PERSON、ORG、GPE、DATE等實體類型。我們使用自訂實體規則對其進行了擴展，以適應PII特定的模式。
Transformer NER (GLiNER)：一種通用NER模型，在推論時接受實體類型描述，允許零樣本偵測任意PII類別而無需微調。我們使用所有14種PII實體類型的提示進行了測試。
基於LLM（GPT-4等級）：使用前沿語言模型，透過結構化提示指定PII類別並請求實體級標註。我們透過API使用GPT-4o進行測試，承認將PII傳送到雲端API進行脫敏基準測試的諷刺性。在生產中，這種方法將使用本地託管的LLM。
混合管道 (Ertas)：兩遍方法：首先用regex模式處理結構化PII（SSN、電話、電子郵件、信用卡），然後用transformer NER處理上下文實體（姓名、地址、醫療術語、案件編號）。該管道完全在本地執行，沒有雲端相依性。
測試語料庫
我們建構了一個包含10,000個PII實例的基準測試語料庫，涵蓋14種實體類型，嵌入在1,200份合成企業文件中：
| 實體類型 | 數量 | 範例 |
|---|---|---|
| 人名 | 1,500 | 全名、部分名字、帶稱謂的名字 |
| 電子郵件地址 | 800 | 標準、企業、混淆 |
| 電話號碼 | 800 | 美國、英國、國際、分機號 |
| SSN | 600 | 標準（XXX-XX-XXXX）、無連字符、部分 |
| 實體地址 | 700 | 街道、郵政信箱、公寓、國際 |
| 出生日期 | 500 | 多種日期格式 |
| 信用卡 | 400 | Visa、Mastercard、Amex，有/無空格 |
| 醫療記錄號 | 400 | 醫院特定格式 |
| IP地址 | 300 | IPv4、IPv6，帶上下文 |
| 駕照 | 300 | 各州特定格式 |
| 護照號碼 | 200 | 美國、英國、歐盟格式 |
| 銀行帳戶 | 200 | 路由號+帳號、IBAN |
| 案件/檔案編號 | 200 | 法律、醫療、保險 |
| 生物辨識識別碼 | 100 | 裝置ID、註冊參考 |
文件設計為同時包含顯式PII（獨立欄位）和上下文PII（嵌入在敘事文字、表格和腳註中）。這反映了真實的企業文件，PII不僅出現在預期位置，還出現在意想不到的上下文中，如嵌入在合約附錄中的電子郵件簽名。
基準真值由兩名獨立審閱者手動標註，對分歧進行裁定。
基準測試結果
| 方法 | 精確率 | 召回率 | F1分數 | 速度（文件/秒） | 誤報率 |
|---|---|---|---|---|---|
| Regex模式 | 99.1% | 72.4% | 83.9% | 145 | 0.9% |
| spaCy NER (en_core_web_trf) | 91.3% | 88.7% | 89.9% | 42 | 8.7% |
| Transformer NER (GLiNER) | 94.8% | 93.1% | 93.9% | 18 | 5.2% |
| 基於LLM（GPT-4等級） | 96.2% | 95.8% | 96.0% | 2.1 | 3.8% |
| 混合管道 (Ertas) | 97.4% | 96.1% | 96.7% | 28 | 2.6% |
按指標詳細分析
精確率：標記的內容確實是PII嗎
精確率衡量被標記項中確實是PII的百分比。精確率低意味著系統過度標記，產生審查負擔並可能脫敏非PII內容。
Regex達到了最高精確率（99.1%），因為模式比對產生很少的誤報——如果某個內容匹配SSN模式，它幾乎肯定就是SSN。少數誤報來自恰好匹配PII模式的數字（例如SSN格式的產品代碼）。
spaCy的精確率最低（91.3%），誤報率最高（8.7%）。其PERSON實體模型經常將組織名稱、產品名稱和位置引用標記為人名。作為城市名稱出現的「Washington」經常被標記為人名。「Amazon Web Services」不一致地觸發了PERSON和ORG標籤。
混合管道達到了97.4%的精確率，透過將regex用於結構化模式（精確率本身就很高）並將transformer NER限制在regex不擅長的實體類型（姓名、地址、上下文引用）。這種分工讓每種方法都在其優勢領域發揮作用。
召回率：存在的PII中擷取了多少
召回率是合規性的關鍵指標。未偵測到的PII——假陰性——是觸發監管行動的失敗模式。
Regex的召回率僅為72.4%，是所有方法中最低的。它幾乎完全遺漏了三大PII類別：
- 人名：沒有regex模式能可靠匹配無限多樣的人名
- 實體地址：地址格式太多變，確定性模式比對無法應對
- 上下文引用：如「該患者」或「我的客戶Johnson先生」這樣的短語需要理解上下文，而非模式比對
基於LLM的方法達到了最高召回率（95.8%），因為語言模型理解上下文。它們正確識別了「請將此轉發給市中心辦公室的Sarah」這樣的句子中的PII，其中「Sarah」是PII但沒有結構化模式匹配。
混合管道達到了96.1%的召回率——略高於LLM方法——因為regex掃描擷取了transformer NER偶爾遺漏的結構化模式（無連字符的SSN、帶分機號的電話），而NER掃描擷取了regex無法匹配的上下文實體。兩次掃描是互補的而非冗餘的。
按實體類型分解
彙總F1分數掩蓋了各實體類型之間的顯著差異：
| 實體類型 | Regex F1 | spaCy F1 | GLiNER F1 | LLM F1 | 混合 F1 |
|---|---|---|---|---|---|
| SSN | 99.2% | 82.1% | 94.3% | 97.8% | 99.4% |
| 電子郵件 | 99.5% | 78.4% | 91.2% | 96.1% | 99.5% |
| 電話 | 97.8% | 75.9% | 90.1% | 95.4% | 98.1% |
| 信用卡 | 98.9% | 71.3% | 88.7% | 94.2% | 99.0% |
| 人名 | 0.0% | 93.8% | 95.7% | 97.2% | 95.7% |
| 地址 | 12.4% | 87.3% | 92.8% | 96.3% | 93.1% |
| 醫療記錄 | 91.3% | 68.4% | 89.1% | 93.7% | 95.2% |
| 出生日期 | 78.2% | 84.1% | 91.4% | 95.9% | 94.8% |
這一分解揭示了根本性的權衡：regex在結構化實體（SSN、電子郵件、電話、信用卡）上佔主導地位，但在上下文實體（人名、地址）上完全失效。NER模型能很好地處理上下文實體，但在結構化模式上不如regex。
混合方法擷取了兩者的優勢，在每種實體類型上都達到了最高或接近最高的F1分數。
速度和吞吐量
處理速度決定了脫敏方法是否適用於生產工作負載。企業資料管道處理數千到數百萬份文件。
| 方法 | 文件/秒 | 10萬份文件所需時間 | 是否需要GPU |
|---|---|---|---|
| Regex | 145 | 11.5分鐘 | 否 |
| spaCy NER | 42 | 39.7分鐘 | 建議 |
| GLiNER | 18 | 92.6分鐘 | 是 |
| LLM（GPT-4等級） | 2.1 | 13.2小時 | 是（或API） |
| 混合 (Ertas) | 28 | 59.5分鐘 | 建議 |
混合管道每秒處理28份文件——足夠快以進行企業檔案的批次處理，但不適合高流量的即時逐請求脫敏。regex掃描增加的延遲極小；transformer NER掃描是吞吐量瓶頸。
基於LLM的脫敏以2.1文件/秒的速度對大規模批次處理不實用。一個10萬份文件的檔案將需要超過13小時。它更適合作為對已脫敏文件樣本的驗證掃描，而非主要脫敏機制。
誤報率和審查負擔
誤報產生營運成本。如果脫敏管道包含審查步驟，每個被錯誤標記的項目都必須由人工審查；如果不包含，則會靜默脫敏非PII內容。
以spaCy 8.7%的誤報率，處理10萬份文件（每份文件平均標記15個實體）將產生約130,500個需要審查的誤報。以混合管道2.6%的誤報率，這個數字降至39,000——審查工作量減少70%。
對於完全自動化的管道（無人工審查），誤報意味著資訊遺失。脫敏一個恰好匹配電話號碼模式的產品代碼，或脫敏一個匹配人名的城市名稱，會降低文件品質，影響下游AI處理。
混合方法的論證
基準測試資料明確指向混合架構是PII脫敏的生產最佳方法。推理很直接：
結構化PII是一個已解決的問題。 Regex以近乎完美的精確率和召回率處理SSN、電子郵件、電話號碼和信用卡。對這些實體類型使用NER或LLM增加了延遲卻不提高精度。
上下文PII需要理解能力。 姓名、地址和上下文引用無法透過模式比對擷取。Transformer NER提供了所需的語意理解，GLiNER和類似模型在上下文實體類型上達到了超過92%的F1分數。
兩次掃描是互補的。 Regex擷取NER遺漏的內容（非標準SSN格式、電話分機號），NER擷取regex無法嘗試的內容（人名、上下文引用）。按順序執行兩次掃描產生的綜合結果超過任何單一方法。
Ertas在其PII Redactor節點中實作了這種混合方法：regex掃描首先執行（確定性、快速、高精確率），然後transformer NER掃描處理剩餘文字中的上下文實體。兩次掃描在管道中作為子步驟可見，每個實體的信心分數被記錄以供稽核。
按用例推薦
受監管行業（醫療、金融、法律）： 使用混合方法並進行人工審查抽樣。目標召回率超過96%，誤報率低於3%。遺漏PII的成本（監管處罰、違規通知）遠超誤報帶來的審查負擔成本。
向企業客戶交付的服務提供商： 使用混合方法並完整記錄稽核日誌。受監管行業的客戶將要求PII脫敏系統性執行的證據。每個實體的信心分數和處理日誌提供了這種證據。
內部AI訓練資料準備： 如果審查預算有限，使用transformer NER（GLiNER或同等產品）。其93.9%的F1分數和5.2%的誤報率為無法實作完整混合管道的團隊提供了合理的精度與工作量權衡。
即時脫敏（逐請求）： 僅使用regex。以145文件/秒的速度，regex是唯一足夠快的即時處理方法。接受72.4%召回率的限制，並定期補充基於NER的批次審查。
方法論說明
- 所有基準測試在單台工作站（Intel i9-13900K、64GB RAM、RTX 4090）上執行。
- spaCy使用en_core_web_trf模型（基於transformer，最精確的變體）。
- GLiNER使用gliner-large-v2.5檢查點。
- LLM基準測試使用GPT-4o透過API進行結構化輸出提示。延遲包括API來回時間。
- 混合管道（Ertas）完全在本地執行，沒有API呼叫。
- 實體類型遵循NIST SP 800-188去識別化框架，擴展了醫療和法律識別碼。
- 誤報率計算為誤報數除以（真陰性數加誤報數）。
有關包括解析、分塊和嵌入階段在內的完整企業資料管道基準測試，請參閱我們的綜合基準測試報告。
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
2026年企業資料管道基準測試報告：解析、脫敏、分塊與嵌入比較
一份全面的基準測試報告，比較企業資料管道在文件解析精度、PII脫敏可靠性、分塊策略和嵌入吞吐量方面的各種方法，包含方法論、結果和ML工程團隊的關鍵發現。
Docling vs Unstructured：PDF解析精度基準測試
我們在500份企業PDF上對Docling、Unstructured.io和Marker做了正面基準測試，涉及表格擷取、多欄版面、掃描件OCR精度和處理速度。
PII 暴露風險評分卡：AI 管道自我評估
一份包含 10 個評分風險因素的自我評估評分卡，用於評估您的 AI 資料管道中的 PII 和 PHI 暴露情況。評估您的風險等級，在問題變成事故之前識別差距。