符合GDPR的RAG管線：被遺忘權、資料最小化與向量儲存的影響

檢索增強生成已成為將大型語言模型連接到企業知識庫的標準模式。將文件分塊，嵌入向量儲存，並在查詢時檢索相關上下文。這種架構運作良好——直到有人行使其GDPR權利。

《通用資料保護規則》第17條賦予個人被遺忘權，通常被稱為「被遺忘權」。當資料主體請求刪除時，必須毫不延遲地刪除其個人資料。在傳統資料庫中，這意味著執行DELETE查詢。在向量儲存中，問題則截然不同。

如果RAG管線攝取包含個人資料的文件——客戶電子郵件、支援工單、人力資源記錄、合約——這些資料會被轉換為密集向量嵌入。這些嵌入是無法輕易逆轉的數學表示，但它們源自個人資料，因此屬於GDPR的管轄範圍。該法規並不區分原始文字及其數值表示。

建構符合GDPR的RAG管線需要在架構層面解決這個問題，而不是事後補救。

影響RAG設計的四項GDPR條款

GDPR中有四項條款對檢索增強生成管線的設計和營運有直接影響。

第5條：處理原則

第5條確立了基本原則，其中兩項對RAG至關重要。目的限制意味著只能為收集資料的特定目的處理個人資料。如果客戶提供其資料用於支援服務，將其嵌入通用知識庫可能超出該目的。資料最小化要求只處理嚴格必要的個人資料。當只需要技術內容時嵌入整個文件違反了這一原則。

第17條：被遺忘權

當資料主體請求刪除時，必須能夠定位並從系統中刪除其所有個人資料。在RAG管線中，這意味著識別向量儲存中包含其資料的每個區塊，刪除這些區塊，並驗證嵌入本身不保留可識別資訊。如果向量儲存不支援細粒度刪除，或者無法將區塊對映回其來源文件及其中提到的個人，則存在合規差距。

第25條：設計和預設的資料保護

本條要求資料保護從一開始就內建於系統中，而不是事後新增。對於RAG管線，這意味著設計攝取流程以在個人資料到達向量儲存之前將其最小化。這還意味著實施有利於隱私的預設設定——例如，自動編輯PII而不是要求人工審查。

第30條：處理活動記錄

必須維護詳細的記錄，說明處理了哪些個人資料、原因和方式。對於RAG管線，這轉化為完整的稽核追蹤：攝取了哪些文件、套用了哪些轉換、建立了哪些區塊，以及何時根據刪除請求刪除了資料。

向量儲存的刪除問題

傳統資料庫儲存離散記錄。可以查詢與特定個人關聯的所有記錄並刪除它們。向量儲存的工作方式不同。

當嵌入一個文字區塊時，生成的向量是一個高維數值陣列。向量本身不包含可讀文字——它在數學空間中表示語義含義。然而，當需要刪除個人資料時，會出現幾個問題。

**區塊邊界不尊重資料邊界。**如果一個文件提到三個不同的客戶，一個區塊可能包含所有三個客戶的個人資料。刪除一個客戶的資料意味著需要重新處理該區塊，移除相關內容，並重新嵌入剩餘部分。

**中繼資料連結通常不完整。**許多RAG實作僅儲存每個向量的最少中繼資料——可能只有來源文件ID和頁碼。如果沒有細粒度的中繼資料追蹤每個區塊中引用了哪些個人，回應刪除請求需要掃描儲存中的每個區塊。

**索引重建代價高昂。**一些向量資料庫使用索引結構（如HNSW圖），無法簡單地刪除單個向量而不降低搜尋品質。刪除後可能需要完全或部分重新索引，這在大規模下可能運算成本很高。

**備份和複製使刪除複雜化。**如果向量儲存被複製或備份，刪除必須傳播到所有副本。忘記清除備份意味著個人資料仍然存在於基礎設施中，這違反了第17條。

這些不是理論上的擔憂。它們是必須在攝取第一個文件之前解決的架構現實。

設計符合GDPR的RAG架構

符合GDPR的最佳RAG管線在資料生命週期的每個階段都解決刪除、最小化和可稽核性問題。

階段1：嵌入前的PII編輯

處理第5條資料最小化和減少第17條風險敞口的最有效方法是在個人資料進入向量儲存之前將其刪除。如果個人資料從未被嵌入，就永遠不需要從嵌入中刪除它。

這意味著在攝取過程中對每個文件執行PII偵測和編輯步驟。姓名、電子郵件地址、電話號碼、身分證號碼和其他個人識別符應在分塊和嵌入之前被去除或替換為佔位符標記。

編輯後的內容進入向量儲存。原始、未編輯的內容可以單獨儲存在具有適當存取控制和保留政策的傳統資料庫中——標準刪除操作可以按預期運作。

Ertas Data Suite在設計上採用了這種方法。PII編輯器在文件到達嵌入階段之前在本機處理文件，去除個人資料，使向量儲存僅包含去個人化的內容。由於編輯在本機進行，個人資料永遠不會離開基礎設施。

階段2：細粒度中繼資料和譜系追蹤

向量儲存中的每個區塊都應攜帶可追溯到其來源文件、其中引用的個人以及套用的處理步驟的中繼資料。這些中繼資料使第17條合規在操作上成為可能。

當收到刪除請求時，查詢中繼資料以查找與該個人關聯的文件衍生的所有區塊。然後刪除這些區塊，重新處理來源文件並移除該個人的資料，必要時重新嵌入。

Ertas Data Suite維護透過管線處理的每個文件的完整稽核追蹤——輸入了什麼、套用了哪些轉換以及輸出了什麼。這直接滿足了第30條的記錄保存要求。

階段3：本機部署向量儲存

在本機執行向量儲存消除了整個類別的GDPR風險。無需擔心第46條下的跨境資料傳輸。沒有第三方子處理者存取資料。資料駐留沒有歧義。

當監管機構詢問個人資料在哪裡處理時，答案很簡單：在自己的基礎設施上，在自己的控制下。與雲端託管的向量資料庫相比，這是一個顯著的優勢，在雲端中資料可能在索引和查詢期間穿越多個司法管轄區。

使用Ertas Data Suite，整個RAG管線——攝取、編輯、嵌入、儲存和檢索——都在自己的硬體上執行。向量儲存是本機的。處理日誌是本機的。稽核追蹤是本機的。

階段4：刪除工作流程自動化

合規的刪除流程不應依賴人工操作。當收到刪除請求時，系統應自動透過中繼資料查找識別所有受影響的區塊，將其從向量儲存中刪除，在需要時觸發重新索引，記錄帶有時間戳記和範圍的刪除操作，並確認完成。

此工作流程應可測試和可稽核。監管機構期望證明的不僅是資料已被刪除，還包括刪除流程是可靠和可重複的。

RAG管線資料隱私作為競爭優勢

對於在受監管行業營運的企業——金融服務、醫療保健、法律、政府——RAG管線資料隱私不是可選項。它是採購要求。無法在架構層面證明GDPR合規的供應商在技術評估開始之前就被淘汰。

從一開始就建構符合GDPR的RAG管線比事後改造成本更低。重新設計現有管線以支援細粒度刪除、PII編輯和稽核日誌的成本遠超從第一天就設計這些能力的成本。

模式很直接：在嵌入前編輯個人資料，為每個區塊維護細粒度中繼資料，在自己的基礎設施上執行向量儲存，並自動化刪除工作流程。Ertas Data Suite將此模式實現為統一的本機平台——使合規成為系統的預設屬性，而不是持續的工程專案。

GDPR第25條將此稱為「設計和預設的資料保護」。這不僅僅是法律要求。這是唯一能在不累積合規債務的情況下擴展的架構。