PII-TRACE：在個人資料離開裝置之前進行偵測
一個適用於長對話的一致 PII 偵測 13 語言基準，搭配設計用於在本地執行的精簡 0.6B 偵測器。
Mac 上的混合式運算將 Perplexity Computer 任務分配給雲端的前沿模型和 Mac 上的本地模型。雲端代理程式處理研究、推理和規劃，而本地模型則處理私人檔案和敏感資訊。
這個邊界取決於在個人識別資訊（PII）離開裝置之前对其進行偵測。本地隱私閘道將敏感內容保留在 Mac 上、遮罩偵測到的私人資訊，或在將其傳送到雲端之前要求批准。
在漫長且多語言的對話中，偵測變得更加困難。同一個識別碼可能會在不同的對話輪次中出現多次。遺漏任何一次提及，都可能暴露系統旨在保護的資訊。
簡介
今天，我們推出 PII-TRACE （Tracing Recurring PII Across Conversational Exchanges，跨對話交流追蹤重複 PII），這是一個用於評估個人識別資訊（PII）偵測器的新基準，以及用於 PII 偵測的精簡 0.6B 模型 PII-Tracer。
雲端優先的代理程式迫使用戶在上下文、智慧和隱私之間取得平衡。更多的個人上下文可以幫助代理程式理解使用者並產生更好的結果。但提供此上下文通常意味著將私人資訊發送到遠端服務，並可能會洩漏個人資訊。使助理變得有用的資訊可能正是使用者最想保持私密的資訊。
混合式 AI 透過在使用者的裝置和雲端模型之間分配工作，緩解了這種權衡。但只有在裝置能夠在文字傳送到遠端模型之前識別 PII 的情況下，該邊界才能保護隱私。使用者不應該自己檢查每條訊息。裝置需要一個本地 PII 偵測器作為其隱私閘道。在長對話中，同一個識別碼可以在多個輪次中重複出現，而遺漏一次提及就足以讓個人資訊穿透過去。
Perplexity 引入了混合式本地-伺服器推論協調器，可決定哪些工作應在裝置上執行，哪些工作應交由雲端的代理程式處理。模型、代理程式執行 harness、對話和執行軌跡全都駐留在使用者的機器上。需要存取外部世界的任務僅在必要時才會被叫用，並受使用者權限的控管。因此，在使用者批准之前，該內容會一直留在裝置上。
PII-Tracer 透過標記預測包含 PII 的片段，為模型路由提供一個本地控制信號。接著，應用程式會強制執行路由政策。它會將相關輸入保留在本地、遮罩偵測到的片段，或在升級至雲端模型之前要求明確批准。這使得路由更具選擇性。偵測到的 PII 仍留在裝置上，而已批准的內容仍可受益於前沿雲端模型。
選擇性路由取決於整個對話中的一致偵測。同一個識別碼可以在多個輪次中重複出現，而遺漏的提及可能仍然會被傳輸。
在 12 個偵測器中，PII-Tracer 記錄了最高字元 F1 和對重複識別碼最高的一致覆蓋率。該基準解釋了為什麼這兩個結果都很重要：在長對話中，找到大部分 PII 與找到它的每一個複本並不相同。
PII 偵測在混合式 AI 中面臨新挑戰
PII 偵測是一個長期的安全問題，並且已經存在多個基準和偵測器。然而，混合式 AI 設定中的 PII 偵測引入了新的挑戰。特別是，偵測器必須在長而多輪的對話中識別 PII，其中對話上下文決定了字串是否應被視為 PII。例如，姓名在一個對話中可能識別使用者，在另一個對話中可能指代公眾人物，或者只是助理生成的預留位置。單獨的表面形式不足以決定字串是否應被標記為 PII。
現有的 PII 偵測器和基準主要是針對單一記錄。我們發現，設計用於一次處理一個記錄的偵測器在長而複雜的對話中表現不佳。此外，現有的基準通常不會評估跨輪次的一致性。因此，在這些基準上表現優異，不一定能轉化為在長對話和多輪對話中進行有效的 PII 偵測。
PII-TRACE：部署關鍵 PII 偵測的基準
我們圍繞 PII 探測器用於助理對話時的三個重要行為來設計 PII-TRACE。第一是一致的覆蓋範圍：當識別碼出現多次或跨越使用者與助理的輪次時，探測器需要找出每一個提及的地方。第二是對長上下文的強韌性：對話長度從少於 1,000 個字元到超過 100,000 個字元不等，這使得測量歷史記錄增長時的情況成為可能。第三是處理多種語言和混合格式內容：對話可能會切換語言並將散文與程式碼、表格或結構化記錄結合。PII-TRACE 透過評估每個完整對話而不是將其拆分為孤立的記錄來保留這些模式。
該基準在兩個互補的層面上衡量效能。在識別碼層面上，一致偵測提出了更嚴格的問題：偵測器是否涵蓋了同一識別碼每次提及中的每一個字元？我們針對具有多個提及的識別碼以及跨輪次重複的識別碼分別報告此分數。在字元層面上，準確率衡量偵測器標記的文字中有多少被標記為 PII，召回率衡量它找到了多少標記的 PII，而 F1 則平衡了兩者。
PII-TRACE 包含 13,148 個橫跨 13 種語言和 10 種書寫系統的合成使用者與助理對話，其中有 37,431 個在九種 PII 類型中以字元層級標記的識別碼提及。所有對話中有 41% 包含結構化內容。在 5,645 個帶有標記 PII 的對話中，63.8% 包含出現一次以上的識別碼，28.7% 包含跨多個輪次出現的識別碼。
從生產對話建立合成資料集
PII-TRACE 在不發布原始對話的情況下保留了來源對話的輪次結構。管線會重寫每個輪次，並將每個標記的識別碼替換為合成值。
首先，多個語言模型在生產使用者助理對話中標記九種類型的 PII. 基於規則的傳遞將相同類型的重複識別碼分組在一個實體 ID 下。然後，每個標記的值都被替換為帶有類型的預留位置，留下一個保留了輪次順序、PII 類型和提及之間的連結，但沒有任何標記的原始值的範本。
系統會在保持這些預留位置完好無缺的同時改寫每個輪次，然後插入與識別碼類型和格式相符的合成值。在同一個對話中，重複提及會收到相同的值，而不同的對話則使用獨立生成的值。最後的對齊傳遞會重新計算每個字元位移。
三個自動化閘道檢查替換是否與儲存的片段相符、重複提及是否使用相同的值，以及在 Presidio 和正規表示式重新掃描下標記的來源值是否不存在。儲存的位移也必須復原確切的合成子字串。失敗的記錄將被重新生成或捨棄。第二個語言模型會審核樣本，人工則會審核它標記為 PII 的任何內容。
PII-Tracer：用於本地使用的精簡偵測器
PII-Tracer 是一個從 Qwen3 骨幹網路改編而來的 0.6B 雙向編碼器。隱私篩選不同於文字生成，需要尋找相關的 PII 片段並傳回其邊界。因此，PII-Tracer 將 Qwen3 的因果遮罩替換為感知填充的雙向注意力機制，因此每個 token 都可以利用 4,096-token 視窗內較早和較晚的輪次。
對於每個 token，編碼器會產生一個 1,024 維的表示。線性標記頭會為 37 個可能的標籤產生分數：一個用於 PII 片段之外文字的特殊標籤（我們使用 O 來表示），外加九種 PII 類型中每種型別的四個片段位置標籤。在命名實體識別的 BIOES 方案中，B（開頭）、I（內部）和 E（結尾）標記多 token 片段，而 S（單一）標記單 token 片段。輔助頭也會預測對話是否包含敏感素材，例如健康或宗教資訊。
我們對 PII-Tracer 進行了三個 epoch 的訓練，使用了大約 714,000 個訓練樣本，結合了多語言助理對話與單記錄範例。共用的雙向編碼器有兩個訓練頭：一個 37 類別的 BIOES token 頭，用於偵測和標記 PII 片段類型，以及一個二元對話層級頭，用於預測對話是否包含敏感素材。我們使用 聯合訓練這兩個頭。在此， 給予稀少的 PII 標籤更多權重，以便頻繁的 `O` 標籤不會佔據主導地位，而 則提供對話層級的訓練信號；1.5 和 0.3 的係數使片段偵測保持為主要任務。這個輔助信號強化了上下文感知偵測：模型學會在對話中判斷候選片段，而不是將其視為孤立的字串，這有助於減少誤報，同時只在召回率上做出很小的權衡。
在推論時，受約束的 Viterbi 解碼器會搜尋最高得分的有效 BIOES 序列，而不是獨立標記每個 token。例如，B-private_person 可以接續 I-private_person 或以 E-private_person 結尾，但不能切換為 I-private_email。解碼器會將結果對應回確切的字元片段，以便進行遮罩或本地路由。
PII-Tracer 在字元 F1 和重複 PII 方面領先
我們在字元和片段（span）層面上比較了各個偵測器。字元 F1 評估逐字元的偵測能力；片段重疊 F1 衡量偵測器是否識別出 PII 項目的任何部分，而片段包含 F1 則衡量其是否捕捉到整個項目。
在評估的 12 個系統中，PII-Tracer 實現了最高的字元 F1（0.629），以及第二高的片段重疊 F1 和片段包含 F1。前沿模型，即 GPT-5.6-sol 和 Claude Sonnet 5，實現了相當的整體效能。GPT-5.6-sol 在兩個片段層級 F1 指標上獲得了更高的分數，但字元 F1 較低。然而，這些前沿模型具有數千億甚至數萬億個參數，並且是託管在雲端中的閉源模型。因此，它們不適合在未經篩選的文字必須留在本地的混合式 AI 設定中保護敏感的本地資料。相比之下，PII-Tracer 僅用 0.6B 個參數就提供了接近前沿的片段層級偵測，並且可以在本地完全處理未經篩選的文字。其他開源 PII 偵測器的表現顯著劣於 PII-Tracer。
尋找每個重複提及
一致性實驗對相同的預測套用了更嚴格的測試。測試集包含 899 個出現一次的識別碼和 959 個出現一次以上的識別碼；其中 790 個重複出現的識別碼跨越了多個輪次。該圖表報告了四個提及次數級距（一、二、三到五，以及六到十），並且只有在找到識別碼的所有標記字元時才計算該識別碼。它繪製了 PII-Tracer 與三個選定基準的對比，而彙總表格則報告了所有十二個系統的重複和跨輪次分數。
隨著重複次數增加，PII-Tracer 依然保持領先：提及一次時其分數從 0.917 降至提及兩次時的 0.873、三到五次時的 0.796，以及六到十次時的 0.691。在最後一個級距中，GPT-5.6-sol 達到 0.464，而 GLiNER2-PII 和 Claude Opus 4.8 則分別達到 0.073 和 0.045。在完整的評估中，PII-Tracer 找出了 79.4% 的重複識別碼和 77.6% 的跨輪次識別碼的所有提及次數；GPT-5.6-sol在這兩項指標上分別達到 57.0% 和 55.1%。
涵蓋長對話
我們首先按字元長度將所有 1,922 個測試對話分組，並使用 4,096-token 視窗對 PII-Tracer 進行解碼。這些群組包含 167 個 1,000 字元以下的對話、1,292 個 1,000 到 10,000 字元的對話，以及 463 個 10,000 字元或以上的對話。
1,000 字元以下的單視窗召回率為 0.975，1,000 到 10,000 字元之間為 0.955，但對於 1,0000 字元或以上的對話則降至 0.687。準確率在兩個較長的群組中保持在 0.51 附近，這表明輸入覆蓋率是主要問題。
為了研究輸入處理的影響，我們使用 50% 重疊滑動視窗解碼評估了同一個檢查點。這在不重新訓練的情況下，將整體字元召回率從 0.830 提高到 0.965，多提及一致偵測從 0.794 提高到 0.954。
跨語言保持一致
PII-TRACE 涵蓋 13 種語言；語言實驗報告了一個橫跨拉丁字母、斯拉夫字母和諺文指令碼的六種語言片段：英語、德語、法語、義大利語、俄語和韓語。我們在每種語言的所有測試對話上執行相同的 12 個偵測器。在每種語言中，我們將預測的和黃金標準的字元合併並計算字元 F1。
PII-Tracer 在六種語言中的四種（德語 [0.735]、法語 [0.633]、義大利語 [0.676] 和俄語 [0.651]）的字元 F1 中領先，並且在英語和韓語中與最佳結果相差在 0.016 和 0.036 以內。在隨附的分析中，它在所有六個語言子集中都帶來了一致的偵測效果，分數達到 0.80–0.93。各語言的觀點顯示了超越英語的收益。
五個標準基準上的字元 F1 優於隱私過濾器
最後一個實驗移到了 PII-TRACE 之外。我們在 ai4privacy 驗證分割（47,728 個文件）、Nemotron-PII 測試分割（100,000）、固定種子 SPY 集（8,688）、Gretel PII 測試分割（5,000）和 TAB ECHR 測試分割（127）上執行了 PII-Tracer 和 OpenAI 隱私過濾器。
PII-Tracer 在每個資料集上都具有更高的字元 F1：在 ai4privacy 上為 0.950 對 0.907，在 Nemotron-PII 上為 0.847 對 0.709，在 SPY 上為 0.585 對 0.543，在 Gretel PII 上為 0.952 對 0.895，在 TAB 上則為 0.594 對 0.350。TAB 是此群組中唯一由真實、人工標記文字建立的基準。在那裡，PII-Tracer 的準確率達到 0.986 對 0.982，召回率達到 0.425 對 0.213——在基本相同的準確率下，召回率達到兩倍（詳細資訊請參閱論文）。因此，更高的 F1 從 PII-TRACE 對話延續到了此次比較中的所有五個傳統單記錄基準。
結論
混合式 AI 將使用者的裝置整合到推論堆疊中，提供更強大的隱私和更低的成本。雲端中的前沿模型可以處理研究、推理和規劃，而本地模型則處理應保留在裝置上的檔案和個人資料。這種分工取決於在任何敏感資料傳送到雲端之前識別敏感資訊。
PII-Tracer 是一個用於在多輪對話中偵測 PII 的精簡模型，而 PII-TRACE 則評估偵測器是否能在整個對話中一致地識別重複出現的 PII。
統整而言，PII-TRACE 和 PII-Tracer 提供了一個基準和參考模型，用於推進多輪對話和其他長上下文設定中的 PII 偵測。
代理程式正在承擔更長的任務並處理更多的個人上下文。因此，隱私控制應該在整個對話中保持，而不僅僅是初始輸入。混合式 AI 依靠可靠的本地偵測將敏感上下文保留在裝置上。
請閱讀 arXiv 論文以了解有關 PII-TRACE 基準測試、PII-Tracer 模型以及我們評估的詳細資訊。我們計劃很快發布 PII-TRACE 和 PII-Tracer。