RAG上下文視窗中的PII洩露：偵測、預防與管線設計

一個使用者向你的RAG助手詢問公司休假政策。系統檢索了相關的政策文件，組裝上下文並傳送給LLM。回答準確且有用。但它也包含了一位人力資源經理的姓名、員工編號和電子郵件地址——這些聯絡資訊嵌入在政策文件中。這就是PII洩露。

透過RAG管線發生的PII洩露並非假設場景。它們每天都在生產系統中發生。RAG的架構——檢索文件、注入LLM提示詞、生成回答——在多個環節創造了個人身份資訊進入上下文視窗並最終出現在面向使用者的輸出中的可能性。LLM不知道什麼是敏感資訊。它平等地對待上下文中的每一個token。

本文映射了RAG管線中PII可能洩露的每一個環節，解釋了每種洩露發生的原因，並提供了一個實用的預防框架。

RAG管線中的PII洩露面

一個標準的RAG管線有六個階段。PII可以在其中五個階段進入和洩露。

階段1：文件攝入 來源文件被載入管線中。PDF、Word文件、電子郵件、資料庫匯出、工單、CRM記錄。

PII風險：來源文件經常在設計上就包含PII。人力資源文件有員工姓名和社會安全號碼。工單有客戶電子郵件和電話號碼。CRM匯出有聯絡方式。醫療記錄有病患識別碼。文件本身就是PII。

階段2：解析和提取 文件被解析為文字。掃描文件使用OCR。試算表進行表格提取。標題和屬性進行中繼資料提取。

PII風險：解析器提取所有內容，包括嵌入在頁首、頁尾、中繼資料欄位和浮水印中的PII——這些是人類讀者可能都不會注意到的。PDF的中繼資料可能包含作者的全名和電子郵件。Word文件的修訂歷史可能包含每個編輯過它的人的姓名。

階段3：分塊 解析後的文字被分割成塊用於嵌入和檢索。

PII風險：分塊不加區分。如果文字中有PII，它就會出現在分塊中。一個包含政策聲明的分塊也會包含出現在同一段落中的任何員工姓名、電話號碼或電子郵件地址。

階段4：嵌入和儲存 分塊被嵌入為向量並與原始分塊文字一起儲存在向量資料庫中。

PII風險：向量資料庫儲存每個分塊的原始文字用於檢索。這創建了一個PII資料儲存，可能不受與來源系統相同的存取控制約束。你的向量資料庫現在是來源文件中每一條PII的副本。

階段5：檢索和上下文組裝 使用者查詢觸發向量搜尋，top-k分塊被組裝到LLM提示詞中。

PII風險：檢索基於語義相似性，而非存取控制。關於「員工福利」的查詢可能檢索到包含某個特定員工福利註冊詳情的分塊，包括其姓名、出生日期和眷屬資訊。檢索系統不會檢查查詢使用者是否有權檢視該員工的資料。

階段6：LLM生成 LLM基於上下文生成回答。

PII風險：LLM將上下文中的PII包含在其回答中。它沒有什麼是敏感資訊的概念。如果上下文包含一個電話號碼，且該號碼與答案相關，LLM就會將其包含在內。

常見的PII洩露場景

以下是我們在生產中最常見的場景：

場景1：熱心的聯絡人。 政策文件包含「如有疑問，請聯繫Jane Doe，信箱jane.doe@company.com或分機4521。」RAG系統檢索到政策分塊，LLM熱心地在每個關於該政策的回答中包含Jane的聯絡資訊——即使使用者沒有請求。

場景2：範本中的範例。 一個表單範本包含範例資料：「姓名：John Smith，SSN：123-45-6789，出生日期：01/15/1980。」範例資料本意是展示如何填寫表單。RAG系統將其視為真實資料，並在相關查詢中檢索到它。

場景3：知識庫中的郵件對話串。 一個支援團隊將其電子郵件歷史索引用於RAG。郵件包含客戶姓名、電子郵件地址、訂單號，有時還有明文支付詳情。每個檢索到的郵件分塊都可能包含客戶PII。

場景4：看似脫敏實則未脫敏的PDF。 一個文件透過在PDF檢視器中用黑色矩形覆蓋敏感文字來「脫敏」。底層文字從未被刪除。PDF解析器提取了視覺遮擋下方的文字，本應脫敏的PII進入了RAG管線。

場景5：多租戶系統中的跨租戶資料。 一個SaaS產品為所有租戶使用共享的向量資料庫。租戶A的查詢檢索到了租戶B的文件分塊，因為檢索層沒有強制執行租戶隔離。租戶B的員工姓名和內部資料出現在租戶A的回答中。

脫敏關卡的放置位置

PII預防需要在管線的特定位置設置脫敏關卡。單一關卡是不夠的——需要縱深防禦，因為沒有單一的脫敏技術能捕獲所有情況。

關卡1：分塊前脫敏（主要防線）

位置： 文件解析之後，分塊和嵌入之前。

功能： 掃描完整的解析文字以查找PII模式，並在文字進入分塊管線之前刪除、遮罩或替換偵測到的PII。

偵測技術：

結構化PII的正規表示式模式（社會安全號碼、電話號碼、電子郵件地址、信用卡號碼）
命名實體辨識（NER）用於姓名、組織和地點
領域特定識別碼的自訂字典（員工編號、病患MRN、帳號）

脫敏策略：

刪除： 完全刪除PII（「聯繫Jane Doe，分機4521」變為「聯繫」）
遮罩： 用佔位符token替換（「聯繫[人名]，[電話分機]」）
泛化： 用類別標籤替換（「聯繫人力資源代表」）

為什麼這個關卡最重要： 一旦PII作為分塊文字的一部分進入向量儲存，刪除它需要重新索引整個受影響的語料庫。在PII被分塊和嵌入之前捕獲它，比之後捕獲要經濟得多。

關卡2：分塊級稽核（次要防線）

位置： 分塊之後，嵌入和儲存之前。

功能： 掃描每個單獨的分塊以查找通過關卡1的PII。這會捕獲在文件中碎片化分佈、只有在分塊中重新組裝後才能被辨識的PII，或第一個關卡的偵測規則遺漏的PII模式。

存在原因： 沒有任何PII偵測系統具有100%的召回率。關卡2使用可能不同的偵測規則提供第二輪檢查（例如，更激進的正規表示式集、不同的NER模型，或對高敏感文件的人工審核）。

關卡3：檢索時過濾（第三防線）

位置： 向量搜尋回傳候選分塊之後，上下文組裝之前。

功能： 在檢索到的分塊被組裝到LLM提示詞之前掃描其中的PII。如果偵測到PII，分塊要麼被即時脫敏，要麼被排除在上下文之外。

權衡： 這個關卡為每個查詢增加了延遲。它也意味著PII仍然存在於向量儲存中——只是在讀取時被過濾。出於合規目的，如果法規要求PII根本不能儲存在向量資料庫中，這可能是不夠的。

何時使用： 作為與關卡1和2配合的安全網，或在你繼承了一個在沒有PII脫敏的情況下索引的向量儲存且無法立即重新索引的情況下。

關卡4：輸出過濾（最後手段）

位置： LLM生成之後，回答展示給使用者之前。

功能： 掃描LLM生成的回答中的PII模式，並在展示前進行脫敏。

局限性： 這個關卡無法阻止LLM看到PII——它只能阻止使用者在回答中看到PII。PII仍然被傳送到了LLM API，這可能違反資料處理協議。如果你使用的是第三方LLM API，在這個關卡觸發時PII已經離開了你的環境。

何時使用： 作為雙重保險措施，絕不能作為主要防線。

檢索中的存取控制

PII脫敏是必要的但不充分的。即使PII已被脫敏，檢索仍應尊重文件級的存取控制。標記為「人力資源機密」的文件不應被普通員工的查詢檢索到，即使其分塊中的所有PII已被刪除。

在檢索層實現存取控制：

基於中繼資料的過濾： 在索引時為每個分塊標記存取控制中繼資料（部門、分類級別、租戶ID）。根據查詢使用者的權限為每個檢索查詢添加強制過濾器。
命名空間隔離： 為不同的存取級別使用單獨的向量儲存命名空間或集合。普通使用者的查詢只搜尋普通命名空間。
列級安全： 如果你的向量資料庫支援，實作列級安全政策來限制給定使用者可以檢索哪些分塊。

實用實施檢查清單

在建構或稽核RAG管線的PII安全性時使用此檢查清單：

盤點你的來源文件。 哪些文件類型包含PII？什麼類型的PII？在建構管線之前建立PII資料地圖。
實施關卡1（分塊前脫敏）。 這對於處理可能包含PII的文件的任何管線都是不可協商的。
用真實文件測試脫敏。 合成測試文件不包含你真實文件中的PII模式。用實際（或逼真的）資料進行測試。
驗證儲存分塊中的脫敏。 索引後，從向量儲存中抽樣分塊並手動檢查是否有倖存的PII。
實施存取控制中繼資料。 為分塊標記存取級別並在檢索時強制執行過濾。
新增關卡3（檢索時過濾）以實現縱深防禦。 在修復之前缺乏脫敏的管線後的過渡期尤其重要。
記錄和稽核。 記錄處理了哪些文件、偵測到並脫敏了什麼PII、以及哪些分塊被提供給了哪些使用者。這個稽核軌跡對合規至關重要。
用對抗性查詢測試。 嘗試透過設計用於獲取敏感資訊的問題來檢索PII。「誰負責福利註冊？」不應回傳特定人員的姓名——如果該姓名本應被脫敏的話。
安排定期PII稽核。 初始管線設定後攝入的新文件可能包含你的偵測規則未涵蓋的PII模式。至少每季稽核一次。

為什麼管線架構很重要

RAG系統中的大多數PII洩露不是由複雜的攻擊造成的。它們是由於沒有人在正確的位置放置脫敏關卡而導致PII進入管線造成的。管線的建構目標是最佳化檢索品質——解析、分塊、嵌入、檢索——而PII處理是事後才想到的，或者在原型階段完全被跳過且在投入生產前從未新增。

Ertas Data Suite包含一個PII Redactor節點，它位於視覺化管線畫布上解析和分塊之間。當你在Ertas中建構RAG索引管線——檔案匯入、解析器、PII Redactor、RAG Chunker、嵌入、Vector Store Writer——脫敏關卡是一個可見的、可稽核的階段。你可以檢查脫敏器偵測到的內容、審查邊界情況，並在脫敏後的分塊到達向量儲存之前驗證其是否乾淨。

脫敏不是隱藏在工具函式中的。不是某人必須記住要執行的後處理腳本。它是畫布上的一個節點，具有記錄的輸入和輸出，精確地放置在管線中它需要在的位置。

當你的合規團隊問「PII在哪裡被脫敏的？」時，你可以向他們展示管線。當稽核員問「你能證明PII在儲存之前被刪除了嗎？」時，你有日誌。這就是將PII預防作為設計原則與將PII預防作為事後補救之間的區別。

監管現實

GDPR第5條要求資料最小化——僅收集和處理為指定目的所必需的個人資料。HIPAA要求在將受保護的健康資訊用於治療、支付或營運以外的目的之前對其進行去識別化。歐盟AI法案對處理個人資料的高風險AI系統施加透明度義務。

一個攝入包含PII的文件、將PII儲存在向量資料庫中、傳送給第三方LLM API並展示給未授權使用者的RAG管線，同時違反了多項法規的多個條款。罰款不是理論上的——GDPR執法已經徵收了數十億歐元的處罰。

RAG管線中的PII脫敏不是錦上添花。它是處理包含個人資料文件的任何系統的合規要求。從一開始就將關卡建入管線中。在資料洩露之後再進行改造在各個方面都更加昂貴。