最佳內建PII脫敏的RAG管道：為什麼沒有脫敏的檢索是合規風險

檢索增強生成已成為企業AI應用的預設架構，用於針對內部文件回答問題。該模式很簡單：將文件分塊，嵌入到向量儲存中，在查詢時檢索相關上下文，以便將LLM的回應建立在您自己的資料之上。

問題在於大多數RAG管道在PII完好無損的情況下索引原始文件。姓名、電子郵件地址、社會安全號碼、醫療記錄識別碼、金融帳號——所有這些都與業務內容一起被嵌入。一旦這些資料進入向量儲存，任何在嵌入空間中足夠接近的查詢都可以檢索到它們。

向量資料庫並非設計為在記錄層級進行存取控制。它們最佳化的是相似性搜尋，而非授權。關於「第三季度營收目標」的查詢可能會傳回碰巧包含客戶家庭住址的分塊，因為兩者出現在同一個合約段落中。根據2024年IAPP的一項調查，67%的組織報告其AI系統在沒有充分保障措施的情況下處理個人資料，而向量儲存是一個日益增長的盲區。

這不是理論上的風險。這是違反GDPR第25條（透過設計保護資料）、HIPAA最小必要標準以及歐盟AI法案透明度和資料治理要求的合規違規行為。建構具有PII脫敏功能的RAG的最佳方法是在資料到達嵌入步驟之前剝離敏感資料。

為什麼PII脫敏必須在嵌入之前進行

有一個常見的誤解，認為可以在檢索之後脫敏PII——在上下文到達LLM提示詞之前進行過濾。這種方法會因三個原因而失敗。

嵌入在語義上編碼PII。 當您嵌入一個句子，例如「患者John Smith，出生日期1982年3月15日，被診斷為2型糖尿病」時，嵌入向量捕獲了整個句子的語義含義，包括個人識別碼。向量本身成為PII的表示。即使您從檢索的文字中刪除了姓名，向量儲存仍然包含一個將該人身份與其醫療狀況一起編碼的嵌入。

檢索後過濾不完整。 對檢索分塊的命名實體辨識可以捕獲明顯的模式——姓名、電話號碼、標準格式的SSN。但它會遺漏嵌入在敘述性文字中的PII、拼寫錯誤的姓名、內部員工ID、自訂識別碼格式以及組合起來具有識別性的上下文。一個提到「2024年3月從Google DeepMind團隊加入的工程副總裁」的分塊透過模式比對不包含任何PII，但它精確地識別了一個人。

無法從向量儲存中選擇性刪除。 GDPR第17條賦予個人被遺忘權。如果客戶請求刪除，而其PII嵌入在500個向量分塊中，則無法在不重新嵌入整個文件集的情況下精確刪除其資料。在RAG索引之前進行PII脫敏完全消除了這個問題——因為PII從未被儲存，所以沒有什麼需要刪除。

正確的架構在文件解析和分塊之間執行脫敏，這樣分塊器和嵌入模型只會看到脫敏後的文字。這就是GDPR合規RAG管道與創建持續合規責任的管道之間的區別。

Ertas如何透過視覺化管道解決這個問題

Ertas Data Suite是一個基於Tauri 2.0（Rust和React）建構的本地桌面應用程式，提供具有8個類別25種節點類型的視覺化節點圖管道建構器。您無需撰寫LangChain腳本和新增自訂PII偵測，而是透過在畫布上連接節點來建構整個RAG管道。

索引管道流程如下：檔案匯入 從本地目錄引入文件，然後 解析器 從PDF、DOCX和其他格式中擷取結構化文字，然後 PII脫敏器 偵測和替換敏感實體，然後 RAG分塊器 將文字分割為適合檢索的片段，然後 嵌入 透過本地模型產生向量，最後 向量儲存寫入器 持久化乾淨的嵌入。

檢索管道連接方式：API端點 接收查詢，查詢嵌入器 將其向量化，向量搜尋 找到相關分塊，上下文組裝器 建構提示詞上下文，API回應 傳回有依據的答案。

關鍵的設計決策是PII脫敏器節點位於解析和分塊之間。每個文件在任何下游處理發生之前都會經過實體偵測和替換。分塊器永遠不會看到原始PII。嵌入模型永遠不會看到原始PII。向量儲存永遠不會包含原始PII。如何在嵌入文件之前脫敏PII變成了一個視覺化的拖放操作，而不是一個自訂腳本專案。

由於Ertas完全在本地執行，文件、脫敏模型、嵌入和向量儲存都保留在您的基礎設施內。沒有資料離開您的環境。

比較：PII安全RAG的三種方法

PII安全RAG管道的最佳工具取決於您的限制條件，但關鍵區別在於PII脫敏是管道的一等階段還是用自訂程式碼臨時新增的事後補救。

合規案例

三個監管框架使得在RAG索引之前進行PII脫敏成為要求而非最佳實務。

GDPR（第5、25和35條）。 資料最小化要求您僅處理為您的目的所必需的個人資料。如果您的RAG系統的目的是回答業務問題，則向量儲存中的個人識別碼是不必要的資料。第25條要求透過設計保護資料——預設將PII建構到您的檢索架構中違反了這一原則。透過RAG系統大規模處理個人資料的組織可能需要根據第35條進行資料保護影響評估。

HIPAA（最小必要標準和安全港）。 使用RAG處理臨床筆記、出院摘要或保險記錄的醫療保健組織必須適用最小必要標準：僅存取特定目的所需的PHI。嵌入完整患者記錄並基於語義相似性檢索的RAG管道提供了遠超必要的PHI。HIPAA的安全港方法確定了18種必須刪除以實現去識別化的特定識別碼類型——PII脫敏器節點可以設定為精確針對這些類型。

歐盟AI法案（第10和15條）。 歐盟AI法案要求AI系統的訓練和運行資料滿足品質和治理標準。第10條特別涉及資料治理，包括偏差檢查和所用資料的適當性。第15條要求日誌記錄和可追溯性。具有內建PII脫敏和稽核日誌的RAG管道滿足這兩項要求。部署高風險AI系統的組織——包括許多企業應用——必須在2027年8月之前證明合規性。

在Ertas中建構PII安全的RAG管道：逐步指南

以下是在Ertas Data Suite中設定帶有PII脫敏的RAG管道的具體工作流程。

第1步：檔案匯入節點。 將檔案匯入節點拖到畫布上。將其指向包含來源文件的目錄。支援的格式包括PDF、DOCX、TXT、HTML和Markdown。該節點索引目錄並列出可用檔案。

第2步：解析器節點。 將檔案匯入的輸出連接到解析器節點。解析器擷取結構化文字，保留段落邊界和中繼資料（頁碼、標題、文件標題）。對於具有複雜版面的PDF，解析器處理多欄文字和嵌入的表格。

第3步：PII脫敏器節點。 將解析器的輸出連接到PII脫敏器節點。設定要偵測的實體類型：人名、電子郵件地址、電話號碼、SSN、醫療記錄號、金融帳號、出生日期、實體地址等。設定脫敏策略——用實體類型佔位符替換（例如「[PERSON_NAME]」）或完全刪除。如有需要，按實體類型調整信心度閾值。

第4步：RAG分塊器節點。 將PII脫敏器的輸出連接到RAG分塊器。設定分塊大小（檢索通常為256-512個token）和重疊（10-15%用於上下文連續性）。分塊器在已脫敏的文字上操作，因此每個分塊在建構上都是無PII的。

第5步：嵌入節點。 將分塊器連接到嵌入節點。選擇本地嵌入模型——該節點在您的硬體上執行推論。沒有文件文字傳送到外部API。

第6步：向量儲存寫入器節點。 將嵌入連接到向量儲存寫入器。乾淨的、無PII的嵌入被持久化到您的本地向量資料庫。

第7步：檢索鏈。 在畫布的另一個區域，建構查詢路徑：API端點到查詢嵌入器到向量搜尋到上下文組裝器到API回應。檢索端連接到同一個向量儲存，但只讀取無PII的內容。

整個管道在單一畫布上可見。您可以在每個連接點檢查資料——驗證PII在到達分塊器之前已被偵測和脫敏。視覺化方法使管道可供不閱讀Python的合規團隊稽核。

與設計合作夥伴合作

Ertas目前正在與設計合作夥伴合作，以驗證這些工作流程在醫療保健、金融服務和法律等產業中的應用。如果您的組織正在建構針對敏感文件的RAG系統，並且正在面對合規方面的挑戰，Ertas Data Suite提供最佳的內建PII脫敏RAG管道——一個視覺化的本地解決方案，敏感資料永遠不會進入向量儲存，也永遠不會離開您的基礎設施。

延伸閱讀

• 80%的企業資料是非結構化的 — 為什麼非結構化資料主導企業環境，以及這對AI管道意味著什麼。
• 跨產業的本地PII和PHI脫敏 — 本地脫敏工作流程如何滿足醫療保健、金融和法律領域的合規要求。