成功建構隐私感覺 AI 軟體需要考慮并分類您計劃預先存儲的資料。
譯自 Building Privacy-Aware AI Software With Vector Databases，作者 Zachary Proser。
GenAI 通過将專有資料與各個使用者知識相結合，建立個性化網絡體驗。我們如何確定按照安全合規标準安全地處理此知識？
我們如何向使用者保證删除其個人身份資訊 (PII)？
讓我們研究可用于確定應用程式符合安全和隐私标準的工具和模式。
為什麼 RAG 是確定資料隐私的最佳架構
檢索增強生成，一種使用私有資料豐富 GenAI 響應的架構，通常用于解決大型語言模型的缺陷，包括幻覺和短上下文視窗。
但 RAG 還可以幫助我們建構隐私感覺 AI 系統，可按需忘記有關個人的特定資訊。
為了遵守安全标準，我們需要確定使用者資料：
| 特性 | 描述 |
| 分離 | 僅對所有者可見，對其他使用者不可見。 |
| 私有 | 未通過訓練或微調提供給 LLM，僅在推理或生成時提供。 |
| 可按需删除 | 使用者應在希望時被遺忘。 |
分離
命名空間可分離使用者資料，并适合作為安全基元。
隐私
使用 RAG 時，僅在生成時将資料作為上下文提供給 LLM，但資料無需用于訓練或微調 AI 模型。
這意味着使用者資料不會作為知識存儲在模型本身中，而隻是在請求生成内容時顯示給 GenAI 模型。
RAG 能夠實作個性化，同時嚴格控制用于生成特定于使用者的響應的任何 PII。
專有資料或 PII 會根據每個請求與 LLM 共享，并且可以從系統中快速删除，進而使資訊在未來請求中不可用。
按需删除
當使用者希望被遺忘時，從向量資料庫索引中删除其資料将導緻 RAG 系統不再了解他們。
資料删除後，LLM 将無法回答有關給定使用者或主題的問題。檢索階段将不再在生成時向 LLM 提供任何此類資訊。
與訓練或微調相比，RAG 在管理特定于使用者的資料方面提供了更大的靈活性，因為你可以從生産系統中快速删除一個或多個實體的資料，而不會影響其他使用者的系統性能。
安全處理客戶資料
了解不同類型的資料
設計軟體以實作隐私感覺需要了解與存儲的每種類型客戶資料相關的風險。
首先，對需要存儲在 向量資料庫 中的資料類型進行分類。具體來說，識别哪些資料是公開的、私有的以及哪些包含 PII。
假設我們正在建構一個電子商務應用程式，該應用程式将存儲公開、機密和 PII 資料的組合：
公開：公司名稱、個人資料圖檔和職位。 私有：API 密鑰、組織 ID、購買曆史記錄。 PII：全名、出生日期、帳戶 ID。
接下來，确定哪些資料将僅存儲為向量，哪些資料必須存儲在中繼資料中以支援篩選。
我們的目标是在盡可能少地存儲 PII 和提供豐富的應用程式體驗之間取得平衡。
使用中繼資料進行篩選非常強大，但其最簡單的形式需要以純文字形式存儲私有資料或 PII，是以我們希望注意公開哪些字段。
有了這種了解，我們可以考慮每種資料類型，并應用以下技術來安全地處理它。
在索引中隔離客戶資料
對不同目的使用單獨的索引。如果應用程式管理地理位置的自然語言描述和一些個人身份使用者資料，請建立兩個單獨的索引，例如位置和使用者。
根據索引包含的内容為其命名。将索引視為存儲的資料類型的頂級存儲桶。
在命名空間中隔離客戶資料
正如我們之前關于 建構多租戶系統 所寫，命名空間是用于在單個索引中分離組織或使用者的便捷且安全的基元。
将命名空間視為索引中的特定于實體的分區。如果索引是使用者，則每個命名空間都可以映射到每個使用者的名稱。每個命名空間僅存儲與其使用者相關的資料。
使用命名空間還可以通過減少在傳回相關結果時需要搜尋的總空間來幫助提高查詢性能。
使用 ID 字首查詢内容片段
Pinecone 支援 ID 字首，這是一種在 upsert 時将額外資料附加到向量的 ID 字段的技術，以便您稍後可以引用内容的“片段”，例如第 1 頁、第 23 塊中的所有文檔，或部門 Z 的使用者 A 的所有向量。
ID 字首非常适合将一組向量與特定使用者關聯，以便您可以在他們要求您時有效地删除該使用者的資料。
例如，想象一個處理餐館訂單的應用程式，以便使用者可以使用自然語言找到他們的購買記錄：
index = pc.Index("serverless-index")
index.upsert(
vectors=[
{"id": "order1#chunk1", "values": [0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1]},
{"id": "order1#chunk2", "values": [0.2, 0.2, 0.2, 0.2, 0.2, 0.2, 0.2, 0.2]},
{"id": "order1#chunk3", "values": [0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3]},
{"id": "order1#chunk4", "values": [0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4, 0.4]}
],
namespace="orders"
) ID 字段可以提供任何組合的分層标簽，這些組合在您的應用程式中是有意義的。
這樣，您可以更輕松地執行批量删除和列出操作：
# Iterate over all chunks from order #1
for ids in index.list(prefix='order1#', namespace='orders'):
print(ids) 使用 ID 字首需要在設計應用程式時進行一些前期規劃，但它提供了一種友善的方法來引用與特定實體相關的所有向量和中繼資料。
檢索增強生成非常适合删除知識
檢索增強生成将專有、私有或快速更改的資料添加到 LLM 響應中，以将其建立在真實性和特定上下文中。
但這也是為您的最終使用者提供有關其被遺忘權的保證的理想方式。讓我們考慮一個電子商務場景，我們的使用者可以使用自然語言與商店互動、檢索舊訂單、購買新産品等。
在以下 RAG 工作流中，使用者的自然語言查詢首先轉換為查詢向量，然後發送到向量資料庫以檢索與使用者參數比對的訂單。
在推理時擷取使用者的個人上下文（他們的訂單曆史記錄）和一些個人身份資訊，并将其提供給生成模型以滿足他們的請求。
RAG 讓您可以控制向 LLM 呈現哪些使用者資料
當您使用 ID 字首方案發出批量删除時會發生什麼？
for ids in index.list(prefix='order1#', namespace='orders'):
print(ids) # ['order1#chunk1', 'order1#chunk2', 'order1#chunk3']
index.delete(ids=ids, namespace=namespace) 您已删除所有系統特定于使用者的内容，以便後續檢索查詢不會傳回任何結果——我們已有效地從 LLM 中删除了對我們使用者的了解。
ID 字首允許我們隔離、标記并稍後列出或删除特定于實體的資料。這使我們能夠将 RAG 擴充到一個架構中，該架構提供了有關資料删除的保證。
最安全的資料是您不存儲的資料
令牌化以混淆使用者資料
您通常可以完全避免在向量資料庫中存儲個人身份資訊。相反，您可以通過存儲對其他系統的引用或外鍵來保護您的使用者安全，例如您在其中存儲完整使用者記錄的私有資料庫中的行 ID。
您可以在本地或由雲服務提供商托管的加密和安全存儲系統中維護完整的使用者記錄。這減少了看到您使用者資料的系統總數。
此過程有時稱為令牌化，類似于模型将我們發送到提示中的單詞轉換為給定詞彙表中單詞 ID 的方式。您可以使用 此處 的互動式令牌化示範來探索此概念。
假設您的應用程式可以提供查找表或可逆令牌化過程。在這種情況下，您可以将外鍵寫入在 upsert 期間與向量關聯的中繼資料，而不是使使用者資料可見的明文值。
外鍵可以是任何對您的應用程式有意義的内容：PostgreSQL 行 ID、您保留使用者記錄的關系資料庫中的 ID、URL 或可用于查找其他資料的 S3 存儲桶名稱。
在 upsert 向量時，您可以附加您希望的任何中繼資料：
index.upsert(
vectors=[
{
"id": "order1#chunk1",
"values": [0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 0.1],
"metadata": {"user_id": 3046, "url": "https://example.com"}
},
{
"id": "order2#chunk2",
"values": [0.2, 0.2, 0.2, 0.2, 0.2, 0.2, 0.2, 0.2],
"metadata": {"user_id": 201}
}
]
)
使用哈希混淆使用者資料
您可以在将使用者資料寫入中繼資料之前使用哈希對其進行混淆。
隐藏不是加密。混淆使用者資料并不能提供與加密相同級别的保護，但它可以使 PII 不被意外洩露。
您的應用程式提供在将使用者 PII 作為中繼資料附加到其關聯向量之前對其進行哈希的邏輯：
有許多類型的哈希操作，但從高層次上講，它們将輸入資料轉換為一系列本身沒有意義但可能被攻擊者逆轉或破解的字元。
您的應用程式可以在将值寫入中繼資料之前以多種方式混淆使用者資料，包括不安全的郵件哈希或 base64 編碼：
在對使用者資料進行哈希并将其存儲為中繼資料後，您的應用程式通過相同的哈希邏輯運作查詢以導出中繼資料篩選器值。
向量資料庫傳回與您的查詢最相關的結果，就像以前一樣。
您的應用程式在對使用者資料進行操作或将其傳回給最終使用者之前會對其進行脫混淆：
這種方法提供了額外的縱深防禦。即使攻擊者可以通路您的向量存儲，他們仍然需要逆轉您的應用程式級哈希才能擷取明文值。
加密和解密中繼資料
混淆和哈希使用者資料比以純文字存儲它們更好，但不足以抵禦技術娴熟且有動機的攻擊者。
在每次更新之前加密中繼資料、重新加密查詢參數以執行查詢以及解密每個請求的最終輸出可能會給您的系統帶來很大的開銷，但這是確定您的使用者資料安全且您的向量存儲對它所服務的查詢的敏感資料一無所知的最佳方式。
工程中的所有事情都是權衡取舍，您需要仔細權衡持續加密和解密的性能損失，以及安全維護和輪換私鑰的開銷，以及洩露敏感客戶資料的風險。
向量資料庫中的資料保留和删除
如果您遵循通過維護單獨的命名空間來實作多租戶的建議慣例，則可以通過單個操作友善地删除存儲在該命名空間中的所有内容。
要從命名空間中删除所有記錄，請為您的用戶端指定适當的 deleteAll 參數，并提供一個 namespace 參數，如下所示：
index.delete(delete_all=True, namespace='example-namespace') 成功建構隐私感覺 AI 軟體需要考慮和分類您計劃預先存儲的資料。
它要求您為自己留下對内容片段的周到處理，正如我們在 ID 字首和中繼資料過濾中看到的那樣，您可以使用它來有效地從您的系統中删除整個使用者或組織的知識。
通過在您的堆棧中使用 Pinecone 向量資料庫并進行一些周密的規劃，您可以建構生成式 AI 系統，這些系統同樣響應使用者的需求并尊重他們的隐私。