設計安全的多租戶RAG推理解決方案
Retrieval-Augmented Generation （RAG）模式是用於建置應用程式的範式，其使用基礎模型來推理專屬資訊或其他在因特網上未公開提供的數據。 一般而言，用戶端應用程式會呼叫協調流程層，從數據存放區擷取相關信息，例如向量資料庫。 協調流程層會將該數據當做背景數據的一部分傳遞至基礎模型。
多個客戶會使用多租戶解決方案。 每個客戶或租使用者都包含來自相同組織、公司或群組的多個使用者。 在多租戶情境中，您必須確保租戶或其成員只能納入他們獲授權存取的基礎數據。
除了確保使用者只存取獲授權存取的資訊之外，還有多租戶架構上的考量。 不過，本文側重於多租戶這一層面。 本文從單一租使用者 RAG 架構的概觀開始。 它探討在使用 RAG 的多租戶環境中可能遇到的挑戰，以及一些常見的解決方法。 它也概述多租使用者考慮和建議，以改善安全性。
注意
本文說明 Azure OpenAI 服務特有的數個功能，例如 Azure OpenAI On Data 功能。 不過，您可以將本文所述的大部分原則套用至任何平臺上的基礎 AI 模型。
具有協調器的單一租戶RAG架構
工作流程
在此單一租戶 RAG 架構中，協同器會從資料存放區擷取相關的專有租戶資料，並作為基礎模型的參考資料提供。 下列步驟說明高階工作流程。
- 使用者向智慧型 Web 應用程式發出要求。
- 識別提供者會驗證要求者。
- 智慧型手機應用程式會使用使用者的查詢和使用者的授權令牌來呼叫協調器 API。
- 協調流程邏輯會從要求擷取用戶的查詢，並呼叫適當的數據存放區來擷取查詢的相關地面數據。 基礎數據會新增至傳送至基礎模型的提示，例如在下一個步驟中公開於 Azure OpenAI 中的模型。
- 協調流程邏輯會連線到基礎模型的推斷 API，並傳送包含所擷取之地面數據的提示。 結果會傳回至智慧型手機應用程式。
如需詳細資訊，請參閱 設計和開發RAG解決方案。
具有直接數據存取的單一租戶 RAG 架構
此單一租戶 RAG 架構的變體利用 Azure OpenAI 的 On Your Data 功能，直接與像 Azure AI 搜尋這樣的數據存放區整合。 在此架構中，您沒有自己的協調器，或協調器的責任較少。 Azure OpenAI API 會呼叫數據存放區，以擷取基礎數據，並將該數據傳遞至語言模型。 此方法可讓您更不控制要擷取哪些基礎數據，以及該數據的相關性。
注意
Azure OpenAI 是由 Microsoft 管理。 它會與數據存放區整合，但模型本身不會與數據存放區整合。 模型會以與協調器擷取數據時相同的方式接收地面數據。
工作流程
在此RAG架構中，提供基礎模型的服務會從數據存放區擷取適當的專屬租用戶數據，並使用該數據作為基礎模型的基礎數據。 下列步驟說明高階工作流程。 斜體步驟與具有協調工作流程的先前單一租戶RAG架構相同。
- 使用者向智慧型 Web 應用程式發出要求。
- 識別提供者會驗證要求者。
- 智慧應用程式會呼叫 Azure OpenAI 以回應使用者的查詢。
- Azure OpenAI 會連線到支援的資料存放區，例如 AI 搜尋功能和 Azure Blob 儲存體，以擷取基礎數據。 當 Azure OpenAI 呼叫 OpenAI 語言模型時，會使用基礎數據做為內容的一部分。 結果會傳回至智慧型手機應用程式。
如果您想要在多租使用者方案中使用此架構，則直接存取地面數據的服務，例如 Azure OpenAI，必須支持解決方案所需的多租用戶邏輯。
RAG 架構中的多租戶架構
在多租用戶解決方案中，租用戶數據可能存在於租使用者特定存放區中，或與其他租使用者共存於多租使用者存放區中。 數據也可能位於跨租用戶共用的存放區中。 只有使用者有權存取的數據，才應該作為地面數據使用。 用戶應該只看到常見數據或所有租用戶的數據，或者來自其租用戶的已篩選數據，以確保他們只看到他們有權限存取的數據。
工作流程
下列步驟說明高階工作流程。 斜體步驟與具有協調器 工作流程的單一租戶 RAG 架構 相同。
- 使用者向智慧型 Web 應用程式發出要求。
- 識別提供者會驗證要求者。
- 智能應用程式會使用使用者的查詢和授權令牌來呼叫協調器 API。
- 編排邏輯會從請求中擷取用戶的查詢，並呼叫適當的數據存放區，以取得獲得租用戶授權的相關背景數據。 將基礎數據新增至下個步驟傳送給 Azure OpenAI 的提示中。 包括下列部分或所有步驟：
- 協調流程邏輯會從適當的租使用者特定數據存放區實例擷取基礎數據，並可能套用安全性篩選規則，只傳回使用者獲授權存取的數據。
- 協調流程邏輯會從多租用戶數據存放區擷取適當的租用戶基礎數據，並可能套用安全性篩選規則，只傳回使用者獲授權存取的數據。
- 協調流程邏輯會從跨租用戶共享的數據存放區擷取數據。
- 協調流程邏輯會連線到基礎模型的推理 API，並傳送包括所擷取基礎數據的提示。 結果會傳回至智慧型手機應用程式。
RAG 中多租用戶數據的設計考慮
當您設計多租戶的RAG推理解決方案時，請考慮下列選項。
選擇商店隔離模型
多租戶情境中儲存和數據的主要 架構方法 是每租戶一庫和多租戶存放區。 這些方法除了包含跨租使用者共享數據的存放區之外。 您的多租用戶解決方案可以使用這些方法的組合。
每租戶專屬商店
在每個租戶的商店裡，每個租戶都有自己的店鋪。 此方法的優點包括數據和效能隔離。 每個租用戶的數據都會封閉在自己的存儲區中。 在大部分的數據服務中，隔離存放區不會受到其他租使用者的嘈雜鄰近問題的影響。 這種方法也能簡化成本配置，因為商店部署的整體成本可以歸因於單一租戶。
這種方法可能會面臨挑戰，例如增加管理和作業額外負荷，以及更高的成本。 如果您有大量小型租戶，例如在企業對消費者情境中，就不應該使用此方法。 此方法也可能達到或超過 服務限制，。
在此 AI 情境中，每位租戶的專屬存放區表示將相關性引入情境所需的基礎資料來自只包含該租戶基礎資料的現有或新數據存放區。 在此拓撲中，資料庫實例作為識別器用於每個租用戶。
多租戶存放區
在多租戶商店中，多個租戶的資料會共存在相同的存放區中。 這種方法的優點包括成本優化的可能性、處理比每一租使用者存放區模型更高的租用戶數目的能力，以及因為存放區實例數目較低而降低管理額外負荷。
使用共用存儲的挑戰包括數據隔離和管理的需求、嘈雜的鄰近反模式，以及對租戶的成本分配更為複雜。 當您使用此方法時，數據隔離是最重要的問題。 您必須實作安全的方法，以協助確保租使用者只能存取其數據。 如果租使用者有不同的數據生命週期需要作業，例如在不同的排程上建置索引，則數據管理也可能很困難。
某些平臺具有可在共用存放區中實作租用戶數據隔離時使用的功能。 例如，Azure Cosmos DB 有原生數據分割和分區化支援。 通常會使用租戶識別碼作為分區金鑰，以在租戶之間提供一些隔離。 適用於 PostgreSQL 的 Azure SQL 和 Azure 資料庫 - 彈性伺服器支援數據列層級安全性。 不過，這些功能通常不會用於多租使用者解決方案，因為如果您打算在多租使用者存放區中使用這些功能，則必須針對這些功能設計解決方案。
在這個 AI 情境中，所有租戶的基礎數據共同儲存在相同的數據存放區中。 因此，您對該數據存放區的查詢必須包含租用戶識別標識，以確保回應僅限於在租用戶範疇內只傳回相關數據。
共享商店
多租戶解決方案通常會在租戶間共享數據。 在醫療保健網域的範例多租用戶解決方案中，資料庫可能會儲存非租用戶專屬的一般醫療資訊或資訊。
在此 AI 案例的內容中，基礎數據存放區通常可供存取，且不需要根據特定租用戶進行篩選，因為數據與系統中所有租使用者相關且已獲得授權。
身份
身份是多租戶解決方案的重要層面，包括多租戶RAG解決方案。 智慧型手機應用程式應該與識別提供者整合，以驗證使用者的身分識別。 多租戶 RAG 解決方案需要 身分識別目錄 來儲存權威身分識別或身分識別的參考。 此身分識別必須流經要求鏈結，並允許下游服務，例如協調器或數據存放區本身，以識別使用者。
您也需要 將用戶對應至租戶，以便授予該租戶數據的存取權。
定義您的租用戶和授權需求
當您建置多租使用者 RAG 解決方案時，您必須 定義解決方案的租使用者。 兩種常見的選擇模型是企業對企業和企業對消費者模型。 您選擇的模型可協助您判斷建置解決方案時應考慮的其他因素。 瞭解租用戶數目對於選擇數據存放區模型至關重要。 大量租戶可能需要一個模型，讓每家商店都有多個租戶。 較少數量的租戶可能會允許每個租戶擁有一個商店的模式。 每個租用戶的數據量也很重要。 具有大量數據的租戶可能會因為數據存放區的大小限制而阻止您使用多租戶存放區。
如果您想要擴充現有的工作負載以支援此 AI 案例，您可能已經做出此決定。 一般而言，如果該數據存放區可以提供足夠的相關性，並符合任何其他非功能需求，您可以使用現有的數據儲存拓撲作為基礎數據。 不過，如果您打算引進新的元件，例如專用向量搜尋存放區作為專用的基礎存儲區，則您仍然需要做出此決定。 請考慮您目前的部署標籤策略、應用控制平面的影響，以及租戶數據生命周期的任何差異等因素，例如效能付費情況。
定義您解決方案的租戶之後，您必須定義資料的授權要求。 租戶只能從其租戶存取數據，但您的授權需求可能更詳細。 例如，在醫療保健解決方案中，您可能會有下列規則：
- 患者只能存取自己的病患數據。
- 醫療保健專業人員可以存取其患者的數據。
- 財務使用者只能存取財務相關數據。
- 臨床稽核員可以看到所有病人的數據。
- 所有使用者都可以存取共用數據存放區中的基本醫學知識。
在檔案型 RAG 應用程式中，您可能會想要根據指派給檔的標記配置或敏感度層級，限制使用者對檔的存取。
在您定義租用戶是什麼，並清楚瞭解授權規則之後，請使用該資訊作為數據存放區解決方案的需求。
數據篩選
限制使用者僅能存取其獲授權的資料，這一過程稱為 篩選 或 安全性調整。 在多租戶 RAG 案例中，使用者可能會對應至租戶特定的存放區。 這並不表示使用者應該能夠存取該存放區中的所有數據。 定義租用戶和授權需求 討論定義數據授權需求的重要性。 您應該使用這些授權規則作為篩選的基礎。
您可以使用數據平臺功能，例如數據列層級安全性來實作篩選。 或者，您可能需要自定義邏輯、數據或元數據。 這些平臺功能通常不會用於多租使用者解決方案，因為您需要針對這些功能設計系統。
封裝多租戶資料邏輯
建議您在您使用的儲存機制前面設有一個 API。 API 的作用就像閘道守衛一樣，可協助確保使用者只能存取他們獲授權存取的資訊。
使用者對資料的存取可以受限於：
- 使用者的租戶。
- 平臺功能。
- 自訂安全性篩選或修剪規則。
API 層應該：
- 在每租戶一商店的模型中，將查詢路由至租戶特定的存放區。
- 僅從多租戶存放區中選取使用者租戶的數據。
- 為使用者使用適當的身分識別來支援平台啟用的授權邏輯。
- 強制執行自訂的安全性修剪邏輯。
- 儲存用於稽核之基礎資訊的存取記錄。
需要存取租用戶數據的程式代碼不應該能夠直接查詢後端存放區。 數據的所有要求都應該流經 API 層。 此 API 層會在租用戶數據之上提供單一治理點或安全性。 此方法可防止租使用者和用戶數據存取授權邏輯到達應用程式的其他區域。 此邏輯會封裝在 API 層中。 此封裝可讓解決方案更容易驗證和測試。
總結
當您設計多租使用者 RAG 推斷解決方案時，必須考慮如何為租使用者建構基礎數據解決方案。 瞭解租用戶數目，以及您儲存的每一租用戶數據量。 此資訊可協助您設計數據租用解決方案。 建議您實作封裝數據存取邏輯的 API 層，包括多租用戶邏輯和篩選邏輯。
貢獻者们
Microsoft維護本文。 下列參與者撰寫本文。
主要作者：
- John Downs |首席軟體工程師
- 丹尼爾·斯科特-倫斯福德 |資深合作夥伴解決方案架構師、數據 & AI
若要查看非公用LinkedIn配置檔，請登入LinkedIn。