PII 偵測實測 : Regex vs BERT-NER vs Ensemble

#ai #security #kubernetes #docker

過去要加 PII 偵測，最常見的多半是利用規則式（Regex）來處理，設計上只抓格式特徵，不需要語意理解而且延遲幾乎是零，那如果要要替 LLM pipeline 加 PII 偵測，最常見的問題是：規則式（Regex）夠不夠用？利用 BERT-NER 能補強什麼？這次我們拿 9 個測試案例來做比較。

結果Ensemble 拿到最高平均 F1 = 0.662，BERT-NER 單獨跑反而只有 0.167，其中又在醫療相關內容上幾乎全滅。

三個方法的設計邏輯

Regex（純規則）：台灣手機格式（09XX-XXX-XXX）、電子郵件、身分證（A123456789）、日期（YYYY-MM-DD）、健保碼，網路上都有很多現成的格式特徵，不需要語意理解，而且延遲幾乎是零（<0.3ms/筆）。
BERT-NER（dslim/bert-base-NER）：只辨識 PER / ORG / LOC / MISC 四類實體，強項是抓中英文姓名和機構名，但對台灣特有的格式（健保碼 AB12345678、MRN 代碼）完全沒有訓練過，延遲約 40ms 到 5900ms（視文本長度，第一次 load 超慢...）。
Ensemble：M1 OR M2，任一方抓到就算命中，理論上兩者可以互補。

9 個測試案例的結果

案例
領域
Regex F1
BERT-NER F1
Ensemble F1

T1-01
商業合約
0.750
0.571
1.000

T1-02
HR 記錄
0.571
0.333
0.750

T1-03
程式碼審查
0.800
0.000
0.800

T2-01
EMR 出院摘要
0.800
0.000
0.800

T2-02
VCF 基因報告
0.833
0.600
0.941

T2-03
放射科報告
0.750
0.000
0.667

T3-01
混淆：分拆格式
1.000
0.000
1.000

T3-02
混淆：同音編碼
0.000
0.000
0.000

T3-03
混淆：語境偽裝
0.000
0.000
0.000

平均

0.612
0.167
0.662

暫時還想不到什麼比較好的評估方法，所以還是利用 F1 Score來確認。

幾個有意思的發現

BERT-NER 在醫療文本上近乎廢掉

T2-01（EMR）和 T2-03（放射科報告）的 F1 都是 0.000，原因很直接：BERT-NER 只認識四類命名實體，對「0912-345-678」這種電話、「MRN: 0987654」這種病歷號碼、「19820712」這種生日格式完全不認識，反而是 Regex 在這幾題反而表現穩定，把大部分有格式特徵的 PII 都抓到了。

程式碼審查（T1-03）裡 BERT-NER 也全滅

測試的案例裡有 API key sk-abc123XYZ 和 email 在程式碼 context 裡，不過 BERT-NER 認不出來，反而是 Regex 靠 sk- prefix 和 email pattern 抓到了 2/3。

混淆格式是三個方法共同的死穴

這邊我塞了幾個以前爬蟲時滿常在台灣的學校網站看到的變形，T3-02 是同音編碼（「零九一二三四五六七八」、「john DOT smith AT example DOT com」），T3-03 是語境偽裝（聊天裡藏的 PII，沒有明確結構），如預期中 Regex 和 BERT-NER 都不是設計來處理這類問題的，這也是未來 LLM-based 解決方案才有機會做到的事。

Ensemble 在大多數標準格式 PII 場景勝出，但在混淆場景同樣無效

T2-03（放射科報告）的 Ensemble 反而比 Regex 低（0.667 vs 0.750），是因為 BERT-NER 把「Taipei Veterans General Hospital」這個機構名抓進來，造成 FP 增加而拉低分數，這可能是利用 OR 邏輯的代價，當 NER 誤判時，Ensemble 沒有辦法自動降權。

跟 Piiranha 的對比

我們之前測過 Piiranha （ FP16 batch-16），整體 F1 = 0.9866，是目前在我們測試集上跑出最高分的方案，相比起來這次的 Ensemble 最高只到 0.662 顯得有點弱，主要是Piiranha 是為 PII 偵測特別訓練的模型，覆蓋的類別更多、格式更廣，而 BERT-NER 只是通用命名實體辨識，根本不是為 PII 設計的，而純 Regex 則天生受限於你苦工處理多少 pattern，以前的 EDR 裡面有超大一坨ＸＤ。

如果你近期也在考慮處理 PII ，剛好手邊有 GPU，Piiranha 一定是目前 ROI 最高的選擇，但是如果只有 CPU-only ，過去 Regex 對格式清楚的商業文件已經夠用，配上 BERT-NER 做姓名補強還算堪用。

而目前針對混淆格式和醫療特有 PII 目前沒有現成的完美解法，要麼利用 LLM 做語意偵測（latency 換準確率），要麼接 openai/privacy-filter 這種 128k context 的大模型來掃整份文件。

幾個在設計 PII pipeline 前要想清楚的問題：