本文件為英文原版的機器翻譯。若翻譯版本與英文原版之間存在任何歧義，概以英文原版為準。 閱讀英文原版
裝置端去識別化工具：開發與基準測試
2026-05-22 · Caiioo Team
我們希望解決 AI 系統在真實個人身份資訊上進行訓練和保留所帶來的隱私問題。「零數據保留」政策和協議雖然降低了風險，但卻充滿了例外。它們本質上是在說：「我們不會存儲您的任何提示或輸出，除非是為了：(此處插入一長串例外清單：安全目的、政府監控、訴訟保留、產品開發、錯誤日誌、改進服務……)」。
為了達成此目標，我們開發了一個在用戶自己機器上運行的個人數據過濾器，它在訊息離開裝置之前就能看到訊息，並返回與用戶在未開啟過濾器時所能獲得的相同答案。
所以我們做到了。Caiioo 的下一個版本將包含這個匿名化工具。您可以通過代理聊天中的盾牌圖標以及設定進行訪問。
本白皮書概述了我們隱私過濾系統背後的原理、架構、評估過程和設計原則。
我們的目標
透過數據最小化實現通用隱私保護。 當使用者與遠端模型進行對話時，模型並不需要真實姓名、住址、真實電子郵件或客戶電話號碼就能回答使用者的問題。它需要的是問題的「輪廓」，且必須看起來像一個真實的問題，以免 LLM 將該查詢視為測試而忽略。因此，過濾器會從發送給 AI 的數據中去除真實的識別碼，並在回傳過程中將真實數值重新縫合回去。模型看到的是合成的姓名和識別碼；使用者看到的則是真實的對話內容。
HIPAA 合規協助。 第二種模式針對 HIPAA 安全港規則 (§164.514) 中的 18 項識別碼以及較寬鬆的受限數據集 (Limited Data Set) 變體。臨床醫生、醫療保健管理員或任何處理受監管工作流程的人員，都可以在不向 AI 發送受保護健康資訊 (PHI) 的情況下，與通用模型討論真實案例。我們並非受監管實體的合規官員——但我們可以作為防止 PHI 離開筆記型電腦的第一道防線。我們的評估提供了可衡量的基準，組織可用於評估過濾器是否符合其合規與隱私標準。所有隱私與安全措施均為判斷性決策，應由使用者或使用者實體自行負責。
我們選擇同時開發這兩者，是因為其工程原理相同，且 PHI 使用案例在技術上其實更容易實現，因為它使用的是特定的命名實體，這比「個人數據」類別中更通用的數據更容易進行脫敏處理。HIPAA 過濾也受益於其主要使用英文或西班牙文。我們偵測識別碼，替換為格式相同的穩定偽名和替代識別碼，並在回傳時將其還原，且絕不記錄真實數值。合成資訊與真實資訊之間的映射僅保留在使用者的裝置上，以便使用者能在代理程式的回應中閱讀真實資訊。不同模式之間的差異僅在於類別清單和政策閘道。
為什麼結合 Regex 與機器學習，而非僅用其一
我們的去識別化工具中包含兩種主要的過濾技術：一種是稱為 Regex 的確定性模式識別語言，另一種則是經過訓練的機器學習模型。
Regex 在表面格式上具有無可比擬的優勢。電子郵件地址有其特定的形狀 ([email protected])。IP 地址、信用卡號、IBAN、VIN、SSN (XXX-XX-XXXX) 以及 API 金鑰也是如此。如果格式是可靠的，Regex 每次都能以確定性的方式捕捉到它，且無需加載模型，也沒有推理成本。
然而，Regex 在處理上下文時卻無能為力。「Sarah's chart from last Tuesday」（Sarah 上週二的圖表）包含了一個人名和一個日期，但僅憑格式無法辨識其中任何一個。「The patient at 14 Elm」（位於榆樹街 14 號的患者）包含一個地址，而該地址的格式與上千個非地址內容重疊。「Their MRN is 7741032」（他們的病歷號碼是 7741032）則需要數字周圍的文字才能賦予其意義。
一個經過微調的小型語言模型可以處理上下文 —— 我們的模型是一個經過特殊訓練、擁有 1.1 億參數的編碼器，由多語言微型語言模型蒸餾而成。它閱讀的是句子而非子字串，且體積小到可以在裝置（甚至是行動電話）上極速運行。
基準測試說明了這兩個層級互補的優勢。我們分別對這兩個層級進行了獨立測試，以確保每個層級都確實發揮了作用。在包含 150 個問題的 PrivacyBench-PD 測試集中（其中的問題與答案明確未用於模型訓練）：
| 層級 | 捕捉到的 PII | 捕捉率 |
|---|---|---|
| 僅 Regex | 205 / 670 | 30.6 % |
| 僅 ML | 516 / 670 | 77.0 % |
| 兩者結合 (正式版) | 625 / 670 | 93.3 % |
僅靠 Regex 會遺漏四分之三的識別碼，因為現實散文中的大多數識別碼並非結構化的。僅靠 ML 則會遺漏 Regex 層本可以捕捉到的 16 個百分點 —— 那些純粹取決於其形狀的事物（信用卡看起來就像信用卡；模型沒有額外的信號可以補充）。兩者結合後，便能涵蓋彼此單獨無法處理的範圍。
深入觀察各層級發揮關鍵作用之處：在同一組測試中，有 16 個測試值僅由 Regex 捕捉到（電子郵件、IP、金融帳戶、結構化 ID），而有 327 個測試值僅由 ML 捕捉到（姓名、上下文識別碼、多語言表達方式）。
小巧、智慧、快速——且隨處運行
我們必須讓過濾器在裝置端運行，這是一項工程挑戰。
它必須夠小巧，因為我們的應用程式在多個系統的裝置上運行：瀏覽器擴充功能、macOS 應用程式、iOS 應用程式、Android 應用程式，以及 Windows 和 Linux。每個模型的封裝大小約為 113 MB。共有兩個模型——一個用於一般個人數據，一個用於受保護的健康資訊——而安全港模式會同時運行這兩個模型。在這些設備中，低階 Android 裝置的效能最低，但我們的系統依然運行良好。
它必須夠智慧，因為漏報會導致真實數據洩漏到遠端 LLM，而誤報則會破壞對話。姓名必須被遮蓋；代名詞則不應被遮蓋。轉發郵件中的醫生電子郵件應該被遮蓋；但 [email protected] 這種頁尾資訊可能不需要。
它必須夠快速，因為它直接處於用戶發送或接收每條訊息的路徑上。我們測量到在單個 CPU 線程上的往返開銷低於 200 毫秒，大部分是標記化過程。在 WebGPU 和 Apple 的神經引擎上，與 LLM 調用本身的網路延遲相比，這點開銷微不足道。
它必須能在多個運行環境中執行，因為 Caiioo 是跨平台的。同一個系統運行在 Chrome 擴充功能、macOS 和 iOS、Android 以及 Windows 和 Linux 上。統一的檢測模型、統一的 Regex 庫、統一的合併器、統一的政策——在 Caiioo 運行的每個介面上都有一致的行為。
評分結果
經過多輪測試與訓練，我們最終確定了第 16 版模型。以下是三個基準測試，分別衡量不同的指標。
我們自有的測試集，包含 150 個模型從未見過的問題
在針對公開基準測試進行評估之前，我們先在一個刻意從訓練數據中排除的內部測試集上執行 Personal Data 過濾器——因此偵測器以前從未見過這些問題。這 150 個問題被分為四組（程式碼片段、文件散文、刻意不尋常的措辭，以及 10 種非英語語言），外加一個完全不包含私密數據的「負向」組（用於檢查我們是否過度脫敏的健全性檢查）。結合 regex + ML 的流水線結果如下：
| 子基準測試 | 擷取數 | 比率 |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| 所有 4 個正向基準測試 | 625 / 670 | 93.3 % |
（負向組中沒有需要尋找的私密數據。過濾器遮蔽了一個不該遮蔽的項目——這與下文的精確度數據一致。）
評分標準非常嚴格：每一項預期的私密數據都必須從遮蔽後的輸出中完全消失，該問題才能得分。沒有部分分數，也沒有「足夠接近」。這比要求另一個 LLM 擔任裁判的基準測試更為嚴苛（LLM 裁判往往比較寬容）。若要查看與其他系統直接比較的數據，請參閱下文的對比章節。
PrivacyBenchHIPAA — 40 個醫療保健問題
每個問題都列出了必須脫敏的受保護健康資訊（姓名、病歷號碼等），以及必須保留的訊號（日期、地理位置、90 歲以下的年齡——根據 HIPAA Limited Data Set 規則）。評分器會檢查兩個方向：我們是否移除了該移除的內容，以及是否保留了該保留的內容？
| 模式 | PHI 已脫敏 | 保留項已留存 |
|---|---|---|
| Limited Data Set (保留日期 / 地理 / 年齡 ≤89) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (脫敏所有內容，包括日期) | 99 / 104 (95.2 %) | — |
Limited Data Set 子模式在此基準測試中表現完美。Safe Harbor 模式由於需要脫敏的內容更多，遺漏的機會也隨之增加，涵蓋率為 95.2%。
自有數據的各類別結果，每種模式 200 個樣本
公開基準測試通常將所有內容混為一談。我們的內部測試數據則按類別（姓名、電子郵件、地址等）細分結果，並以三種方式運行每一類：僅限 regex、僅限 ML，以及兩者結合。這能精確告訴我們哪種技術擷取了哪種識別碼，以及各自在何處需要對方的補充。最近一次運行日期為 2026-05-20：
三種過濾模式的總結
| 模式 | 綜合召回率 | 精確度 | F2 | 樣本數 |
|---|---|---|---|---|
| Personal Data 過濾器 | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA 過濾器 — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA 過濾器 — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
這些數據不包括 URL，我們刻意保留了 URL——破壞 URL 會導致下游操作（如「開啟此連結」或「擷取該頁面」）失效。更多相關資訊請參閱下文的工作流章節。
各類別表格前的總體概況：在每種模式下，真正能識別個人身份的識別碼擷取率均達到或接近 100%。姓名、電子郵件、電話號碼、郵寄地址、政府 ID、生物識別 ID、精確地理位置、病歷號碼、出生日期、社會安全號碼——在每個樣本、每次測試中都被成功擷取。低於 100% 的類別是可以預見的：設備 ID（真實文本中的格式極其多樣）、雜項機構 ID（會員卡號、員工 ID——同樣的問題）以及照片（純文本過濾器無法看到圖像內容）。這些都不是「圖表上的姓名」或「草稿中的電子郵件」這類真正關鍵的洩漏識別碼。高風險類別的表現非常可靠。
Personal Data 過濾器
按綜合召回率排序（最優優先），然後按風險等級（T1 = 最敏感）排序。
| 類別 | 等級 | regex 召回率 | ML 召回率 (原始) | 綜合召回率 | 金標數量 n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
從數據可以看出，雙層設計發揮了作用。郵寄地址、出生日期和人名在僅使用 regex 時得分僅為 0–13%——因為沒有固定模式可匹配，只能依靠 ML 模型擷取。電子郵件、電話號碼、IP、政府 ID、生物識別 ID 和精確地理位置在僅使用 regex 時得分為 100%——這些是 ML 模型可以輕鬆處理的表面格式。線上帳號、車輛 ID 和認證密鑰則表現不一：regex 擷取標準格式，ML 擷取其餘部分。在每個類別中，綜合召回率均達到或超過了單層中較強的一方。
設備 ID 和雜項機構 ID 是低於 100% 的類別，原因很明確：這些在真實文本中的格式最為多樣。我們寧願誠實面對召回率下降的類別，也不願假裝過濾器在所有地方都是完美的。
HIPAA 過濾器 — Limited Data Set 子模式
Limited Data Set 子模式依設計保留了日期、地理位置和 89 歲或以下的年齡——這些是 HIPAA 允許組織保留用於合法臨床研究和營運的訊號。
| 類別 | 等級 | regex 召回率 | ML 召回率 (原始) | 綜合召回率 | 金標數量 n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
照片是已知的遺漏項——純文本過濾器無法看到圖像內容。圖像 PHI 是我們尚未發布的另一個獨立問題。此模式下的所有其他類別均達到 100%。
HIPAA 過濾器 — Safe Harbor 子模式
Safe Harbor 會移除 Limited Data Set 子模式所保留的所有內容——日期、89 歲以上的年齡、地理位置。為了獲得最嚴格的覆蓋，它並行運行兩個過濾模型：HIPAA 專用模型和通用個人數據模型。
| 類別 | 等級 | regex 召回率 | ML 召回率 (原始) | 綜合召回率 | 金標數量 n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
這兩個有趣的行是通用日期（regex 100%，ML 30%）和 89 歲以上的年齡（regex 100%，ML 0%）。我們刻意讓 regex 在 Safe Harbor 中處理這兩者：日期具有 regex 每次都能擷取的模式，而且我們不希望概率模型去猜測像「>89」這樣的數值閾值。確定性規則比要求 ML 模型學習相同規則更可靠。
所有類別的總體數據
總結一下：完整的流水線（regex + ML 結合）與單一層相比表現如何？
| 模式 | 層級 | 召回率 | 精確度 | F2 |
|---|---|---|---|---|
| Personal Data | 僅限 regex | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | 僅限 ML | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | 兩者 (完整) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | 僅限 regex | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | 僅限 ML | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | 兩者 (完整) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | 僅限 regex | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | 僅限 ML | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | 兩者 (完整) | 92.4 % | 88.9 % | 91.7 % |
Personal Data 過濾器的「完整」行在每項指標上都優於單層版本——將 regex（處理表面格式）與 ML 模型（處理上下文）結合，確實提供了單層無法實現的效果。本文開頭提到的 97.3% 綜合數據反映了真實用戶獲得的體驗。上表中的數字略低，僅是因為它包含了 URL 類別，而我們為了不破壞連結和工具調用而刻意保留了該類別。
與其他專用隱私過濾器的對比
對於像我們這樣在設備端運行、近乎即時的隱私過濾器，公平的比較對象應該是其他在設備端運行、近乎即時的隱私過濾器，而不是每條消息需要數秒處理且需要網絡往返的大型雲端託管 LLM。我們針對相同的測試集，使用相同的匹配規則運行了該類別中的每個系統。對所有人採用相同的標準。
同類產品包括：
- openai/privacy-filter — OpenAI 的開源專用隱私過濾器。約 5000 萬個參數，小到可以在任何現代瀏覽器中運行。
- piiranha-v1 — 來自 iiiorg 的 2.78 億參數偵測器。其許可證限制僅用於研究和評估（我們可以測量它，但不能商業出貨）。
- Microsoft Presidio — 部署最廣泛的開源脫敏工具，結合了傳統模式匹配與小型語言模型以處理上下文。
- GLiNER PII 系列 — 一系列小型通用實體分類器。Knowledgator 提供 small (~44M)、base (~86M) 和 large (~304M) 變體；NVIDIA 於 2025 年 10 月發布了 570M 變體。
- Caiioo 的三種模式（Personal Data、HIPAA Limited Data Set、HIPAA Safe Harbor）。
五個測試集的召回率，按 Caiioo 優先排序：
| 系統 | PrivacyBench PD-25 | Caiioo 合成 PD-200 | PrivacyBenchHIPAA-40 | Caiioo 合成 PHI-200 | 多語言 PD-40 (10 個地區) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo 在兩個最大的測試（PD-200 和 PHI-200）中領先專用過濾器類別，在公開基準測試中持平或領先，在多語言測試中排名第二。在最小的測試（PrivacyBench PD-25，僅 25 個問題）中，Caiioo 和 openai/privacy-filter 以 96.2% 持平。在多語言方面，openai/privacy-filter 仍以 94.9% 領先，Caiioo 為 92.6%——我們落後最多的語言是中文；在其他所有地方，我們都處於或接近頂尖水平。如果多語言覆蓋是關鍵任務，openai/privacy-filter 是一個合理的選擇。對於該類別中的大多數其他工作負載，Caiioo 則是首選。
HIPAA 的結果是重頭戲。Caiioo 的兩種 HIPAA 模式在每次 HIPAA 測試中都達到了 100% 的召回率——每個患者姓名、每個病歷號碼、每個出生日期、每個帳號都被成功擷取。排名第二的系統是 openai/privacy-filter，在 PrivacyBenchHIPAA 上為 93.7%——在每一次遺漏都代表真實世界洩漏的基準測試中，這有著 6.3 個百分點的差距。
另一個值得關注的數字是：過度脫敏——遮蔽了並非私密數據的內容。過度脫敏不是隱私損害，而是可用性成本。遮蔽過多內容會降低 LLM 的推理能力，導致返回的答案質量下降。Caiioo 在測試集中不必要遮蔽的次數為 1–24 次。Presidio 為 10–51 次。NVIDIA 的 GLiNER 僅在 HIPAA 測試中就達到了 31–64 次。當目標是以最小的暴露風險獲得最佳答案時，精確度與召回率同樣重要。
為什麼不直接使用頂尖 LLM 作為過濾器？
它們確實可以——而且在原始召回率上，它們會勝出。大型通用 LLM（Llama 3.1 8B、Gemma 4、Qwen 3.5 9B 等），無論是在雲端還是本地運行，在包括多語言在內的每項測試中都能獲得 95–100% 的分數。對於需要最高召回率且願意為此付出代價的用戶來說，這是一個真實的選項。
然而，缺點也很明顯：
- 速度慢。 每條消息需要數秒而非毫秒。過濾器位於用戶發送的每條消息之前。
- 要麼消息離開用戶機器，要麼模型離開。 要在雲端過濾，消息必須上傳——這違背了初衷。要在設備端過濾，則需要下載 1–17 GB 的模型。
- 可能被欺騙。 生成式模型可能會在消息中途被誘導不進行脫敏（「提示詞注入」攻擊）。像我們這樣的小型分類器則不會。
- 相同輸入，不同輸出。 生成式模型並不總是對同一個問題給出兩次相同的答案。這會破壞往返流程——發出時遮蔽和返回時取消遮蔽依賴於同一個真實值始終映射到同一個偽造值。
Caiioo 是為這種權衡的另一端而設計的：一個微型、可預測、亞秒級的過濾器，在用戶按下發送鍵之前的編輯器中運行，並且在對話中始終為相同的真實值生成相同的偽造值，從而保持往返流程的一致性。上述同類產品對比表是針對此類用例的對等比較。
實踐是檢驗真理的唯一標準
基準測試只是起點，而非終點。該過濾器已整合至 Caiioo 的新功能：去識別化器（pseudonymizer）—— 這是實際介於編輯器與模型之間的組件。
以下是當使用者按下傳送時所發生的過程。
- 偵測。 正則表達式（regex）層首先執行 —— 它是確定性的，且速度達微秒級。接著由機器學習（ML）模型處理剩餘部分。如果兩層在同一段文本上重疊，我們採用一個簡單規則：表面格式以 regex 為準，上下文語境以 ML 為準。
- 標記自我與他人。 Caiioo 會區分指向「使用者本人」的識別碼與指向「他人」的識別碼。使用者可以選擇僅遮蔽其中之一，或兩者皆遮蔽。使用者加入個人字典的名稱一律視為「自我」。
- 替換。 每個真實數值都會獲得一個穩定且風格匹配的假名。例如「Sarah Goldberg」變成「Maya Hartwell」—— 並且在整個對話過程中保持為「Maya Hartwell」，這樣模型對該人物的推理就不會因為對話輪次而產生斷層。真實與虛假數值的對照表保存在使用者的裝置上，並使用來自平台鑰匙圈（keychain）的密鑰進行加密。
- 傳送。 模型接收到的是完全虛假的信息。任何真實識別碼都不會跨越網路傳輸，且我們的稽核日誌僅記錄計數 —— 絕不記錄數值本身。
- 還原。 串流回應在抵達時會被映射回原值。模型回覆中的「Maya Hartwell」在顯示到螢幕前會變回「Sarah Goldberg」，並以微光膠囊樣式渲染，讓使用者一眼就能看出哪些內容受到了保護。
- 同時還原工具參數。 如果模型調用工具 —— 例如發送電子郵件、提交工單、寫入文件 —— 且參數中包含假名，我們會在工具執行「之前」將真實數值替換回去。模型針對假名進行推理；而實際動作則採用真實數值。
該過濾器並不介意使用的是哪種 AI 服務。它在訊息抵達模型之前就已執行，因此 OpenRouter、Anthropic、Google、OpenAI 以及本地的 Ollama 接收到的都是相同的遮蔽負載。增加新的供應商並不會重新產生隱私漏洞。
保護對象
用戶。 當過濾器開啟時，用戶的姓名、電子郵件、地址、電話、IP 和生物識別標識（這些資訊加在一起可以向數據聚合商識別出一個人）永遠不會離開裝置。
用戶談論的人。 大多數隱私工具只關注輸入的人，但它們忽略了「社會契約」——事實上，我們對他人和對自己一樣負有責任。將「請分析桑德斯先生的不稱職行為」提交給 LLM，並可能被無限期記錄在系統日誌中，是不負責任的（且具有潛在的誹謗性）。向 LLM 尋求幫助處理包含 1,000 個業務聯繫人的 Google 試算表，會將所有這些資訊都存入數據保留的陷阱中（程度取決於實際生效的「零數據保留」政策）。Caiioo 的過濾器也涵蓋了第三方：正在起草合同的客戶、正在分析病歷的患者、電子郵件被貼入上下文的同事。他們並未同意讓遠端 LLM 看到他們的識別碼。過濾器預設尊重這一點；如果工作流程需要，用戶可以切換到「僅限自己」或「僅限他人」。
實體——企業、醫院、公司。 帳號、許可證號、病歷號、財務路由詳情、內部 ID、API 金鑰、客戶名單。企業與個人一樣擁有數據最小化的利益。臨床醫生使用 Caiioo 起草出院小結時，不會將患者的病歷號發送給 OpenAI。律師不會將客戶的帳號發送給 Anthropic。支持工程師不會將客戶日誌中的 API 金鑰發送給 Google。過濾器不會詢問該識別碼屬於個人還是實體——它只會將其保留在裝置上。
最大效用，最小暴露
核心重點在於用戶不應該感覺到過濾器的存在。
大多數隱私工具強迫用戶做出選擇：要麼激進地遮蓋並看著模型的回答變差，要麼保持提示詞可用並看著隱私承諾瓦解。我們拒絕這種權衡。模型仍然會收到一個完整的提示詞——它能看到姓名、地點、日期、病歷號，且都在正確的語法位置上。它看到的只是虛假的資訊。它的推理過程是相同的；只有字串被清洗了。
穩定的替換是使其運作的關鍵。因為在一次對話中，同一個真實值總是映射到同一個虛假值——無論是在用戶的訊息中、引用該姓名的工具返回結果中，還是模型之前提到它的回覆中——模型都有一個連貫的人、地、物來進行推理。多輪對話不會變得混亂。工具調用不會中斷。子代理繼承父對話的映射表，並在整個任務中保持一致。
用戶看到的輸出是真實的對話。提供商看到的數據是連貫的虛構故事。工作發生在這兩種視角之間的間隙中，而目標——唯一的目標——就是讓這個間隙變得隱形。
一個礙事的隱私過濾器會被關閉。一個能融入工作流程的隱私過濾器才是唯一值得發布的。
這就是我們建立的標準。