擷取擴增世代 （RAG） 是建置應用程式的模式，其中基礎模型用來對專屬資訊或其他未在因特網上公開提供的資訊進行推理。 一般而言，用戶端應用程式會呼叫協調流程層，從數據存放區擷取相關信息，例如向量資料庫。 協調流程層會將該數據當做內容中的一部分傳遞至基礎模型。
多租用戶解決方案由多個客戶使用，其中每個客戶（租使用者）是由來自相同組織、公司或群組的多個使用者所組成。 在多租使用者案例中，您必須確保租使用者或租使用者內的個人只能納入授權查看的地面數據。
雖然除了確保使用者只存取他們應該看到的資訊之外，還有多租用戶的擔憂，但本文著重於多租使用者這一層面。 本文從單一租使用者 RAG 架構的概觀開始，討論使用 RAG 的多租使用者和一些常見的方法所遇到的挑戰，並以安全的多租使用者考慮和建議結束。
注意
本文討論一些 Azure OpenAI 特定功能，例如 Azure OpenAI On Your Data。 也就是說，本檔中討論的大部分原則都適用於大多數基礎 AI 模型，不論其主機平台為何。
具有協調器的單一租使用者RAG架構
圖 1. 單一租使用者RAG架構
工作流程
在此單一租使用者 RAG 架構中，協調器必須負責從數據存放區擷取相關的專屬租用戶數據，並將其作為基礎模型的基礎數據。 以下是高階工作流程：
- 使用者向智慧型 Web 應用程式發出要求。
- 識別提供者會驗證要求者。
- 智慧型手機應用程式會使用使用者查詢和使用者的授權令牌來呼叫協調器 API。
- 協調流程邏輯會從要求擷取用戶的查詢，並呼叫適當的數據存放區來擷取查詢的相關地面數據。 基礎數據會新增至傳送至基礎模型的提示，例如在下一個步驟中公開的 Azure OpenAI 中公開的模型。
- 協調流程邏輯會連線到基礎模型的推斷 API，並傳送包含所擷取之地面數據的提示。 結果會傳回至智慧型手機應用程式。
如需RAG詳細資料的詳細資訊，請參閱 設計和開發RAG解決方案。
具有直接數據存取的單一租使用者RAG架構
單一租使用者 RAG 架構的變體會利用 Azure OpenAI 服務直接與 Azure 搜尋服務等數據存放區整合的能力。 在此架構中，您沒有自己的協調器，或協調器的責任較少。 Azure OpenAI API 必須負責呼叫數據存放區，以擷取基礎數據，並將該數據傳遞至語言模型。 反過來，您對要擷取哪些基礎數據以及該數據相關性的控制較少。
注意
由 Microsoft 管理的 Azure OpenAI 服務會與資料存放區整合。 模型本身不會與數據存放區整合。 如果協調器擷取數據，模型會以完全相同的方式接收地面數據。
圖 2. 從 Azure OpenAI 服務直接存取數據的單一租使用者 RAG 架構
工作流程
在此RAG架構中，提供基礎模型的服務必須負責從數據存放區擷取適當的專屬租用戶數據，並將該數據當做基礎模型的基礎數據。 以下是高階工作流程（斜體步驟與具有協調器工作流程的單一租使用者RAG架構相同）：
- 使用者向智慧型 Web 應用程式發出要求。
- 識別提供者會驗證要求者。
- 智慧型手機應用程式接著會使用使用者查詢來呼叫 Azure OpenAI 服務。
- Azure OpenAI 服務會連線到支持的數據存放區，例如 Azure AI 搜尋和 Azure Blob 記憶體，以擷取地面數據。 當 Azure OpenAI 服務呼叫 OpenAI 語言模型時，會使用地面數據做為內容的一部分。 結果會傳回至智慧型手機應用程式。
為了在多租使用者解決方案中考慮此架構，直接存取地面數據的服務必須支持解決方案所需的多租用戶邏輯。
RAG 架構中的多租使用者
在多租用戶解決方案中，租用戶數據可能存在於租使用者特定存放區中，或與其他租使用者共存於多租使用者存放區中。 在跨租用戶共用的存放區中，也可能有數據。 只有使用者有權查看的數據，才應該作為地面數據使用。 用戶應該只會看到來自其租使用者的一般（所有租用戶）數據或數據，並套用篩選規則，以確保他們只會看到他們獲授權查看的數據。
圖 3：RAG 架構 - 具有多個數據存放區租使用者
工作流程
除了步驟 4 以外，此工作流程與單一租使用者 RAG 架構中的 協調器 相同。
- 使用者向智慧型 Web 應用程式發出要求。
- 識別提供者會驗證要求者。
- 智慧型手機應用程式會使用使用者查詢和使用者的授權令牌來呼叫協調器 API。
- 協調流程邏輯會從要求擷取用戶的查詢，並呼叫適當的數據存放區，以擷取查詢的租用戶授權相關地面數據。 基礎數據會新增至下一個步驟中傳送至 Azure OpenAI 的提示。 涉及下列部分或所有步驟：
- 協調流程邏輯會從適當的租使用者特定數據存放區實例擷取地面數據，並可能套用安全性篩選規則，只傳回用戶獲授權存取的數據。
- 協調流程邏輯會從多租用戶數據存放區擷取適當的租用戶基礎數據，並可能套用安全性篩選規則，只傳回使用者獲授權存取的數據。
- 協調流程邏輯會從跨租用戶共享的數據存放區擷取數據。
- 協調流程邏輯會連線到基礎模型的推斷 API，並傳送包含所擷取之地面數據的提示。 結果會傳回至智慧型手機應用程式。
RAG 中多租用戶數據的設計考慮
選擇存放區隔離模型
在多租使用者案例中，記憶體和數據有兩種主要架構方法：每一租使用者存放區和多租使用者存放區。 這些方法除了包含跨租使用者共享數據的存放區之外。 本節會觸及每個方法。 請注意，您的多租用戶解決方案可以使用這些方法的組合。
每一租使用者的市集
在每一租使用者的存放區中，正如名稱所建議，每個租使用者都有自己的存放區。 此方法的優點包括數據和效能隔離。 每個租用戶的數據都會封裝在自己的存放區中。 在大部分的數據服務中，隔離存放區不會受到其他租使用者的嘈雜鄰近問題的影響。 此方法也會簡化成本配置，因為市集部署的整個成本可以歸因於單一租使用者。
這種方法的挑戰可能包括更高的管理和作業額外負荷，以及更高的成本。 當有大量小型租使用者，例如企業對取用者案例時，不應該考慮這種方法。 此方法也可以針對 服務限制執行。
在此 AI 案例的內容中，每一租使用者的存放區表示將相關性帶入內容所需的基礎數據會來自只包含租使用者地面數據的現有或新數據存放區。 在此拓撲中，資料庫實例是每個租使用者使用的歧視性。
多租使用者存放區
在多租使用者存放區中，多個租用戶數據會共存於相同的存放區中。 此方法的優點包括成本優化的可能性、處理比每一租使用者存放區模型更高的租用戶數目的能力，以及由於存放區實例數目較低而降低管理額外負荷。
使用共用存放區的挑戰包括需要確保數據隔離、數據管理、 可能造成嘈雜的鄰近反模式，以及難以將成本配置給租使用者。 確保數據隔離是這種方法最重要的考慮。 您必須負責實作安全性方法，以確保租使用者只能存取其數據。 如果租使用者有不同的數據生命週期，可能需要作業，例如在不同的排程上建置索引，則數據管理也可能是一項挑戰。
某些平臺具有在共用存放區中實作租用戶數據隔離時，您可以利用的功能。 例如，Azure Cosmos DB 有原生支援分割和分區化，而且通常會使用租使用者標識碼作為分割區索引鍵，以提供租用戶之間的某種隔離等級。 Azure SQL 和 Postgres Flex 支援數據列層級安全性，雖然此功能不常用於多租使用者解決方案，因為如果您打算在多租使用者存放區中使用這些功能，則必須針對這些功能設計解決方案。
在此 AI 案例的內容中，這表示所有租使用者的基礎數據都會出現在相同的數據存放區中，如此一來，您對該數據存放區的查詢必須包含租用戶歧視性，以確保回應僅限於在租用戶內容中只傳回相關數據。
共用存放區
多租用戶解決方案通常會有跨租用戶共享的數據。 在醫療保健網域的範例多租用戶解決方案中，可能有一個資料庫會儲存非租使用者特定一般醫療資訊或資訊。
在此 AI 案例的內容中，這是一般可存取的地面數據存放區，不需要根據任何租用戶進行篩選，因為數據與系統中所有租使用者相關且獲得授權。
身分識別
身分識別是多租用戶解決方案 的重要層面，包括安全的多租使用者RAG。 智慧型應用程式應該與識別提供者 （IdP） 整合，以驗證使用者的身分識別。 多租使用者RAG解決方案需要一個 身分識別目錄 ，其中會儲存授權身分識別或身分識別的參考。 此身分識別必須流經要求鏈結，讓協調器甚至數據存放區本身等下游服務能夠識別使用者。
您也需要將用戶對應至租使用者的方法，以便授與該租用戶數據的存取權。
定義您的租用戶和授權需求
建置多租使用者RAG解決方案時，您必須 定義您解決方案的租使用者。 兩種常見的選擇模式是企業對企業（B2B）和企業對消費者（B2C）。 此判斷可協助您了解架構解決方案時應考慮的區域。 瞭解租用戶數目對於決定數據存放區模型至關重要。 大量租使用者可能需要每個存放區有多個租使用者的模型，而較小的租用戶數目可能會允許每個租使用者模型的存放區。 每個租用戶的數據量也很重要。 如果租使用者有大量數據，可能會因為數據存放區的大小限制而無法使用多租使用者存放區。
在正在擴充以支援此 AI 案例的現有工作負載中，您可能已經做出這個選擇。 一般而言，如果數據存放區可以提供足夠的相關性，並符合任何其他非功能性需求，您就能夠使用現有的數據儲存拓撲進行地面數據。 不過，如果您要引進新的元件，例如專用向量搜尋存放區作為專用的地面存放區，則您必須做出此決策，並考慮您目前的部署戳記策略、應用程式控制平面影響，以及任何個別租用戶數據生命周期差異（例如效能付費情況）。
一旦您為解決方案定義租用戶是什麼，您就必須定義數據的授權需求。 雖然租使用者只會從其租使用者存取數據，但您的授權需求可能會更細微。 例如，在醫療保健解決方案中，您可能會有下列規則：
- 患者只能存取自己的病患數據
- 醫療保健專業人員可以存取其患者的數據
- 財務使用者只能存取財務相關數據
- 臨床稽核員可以看到所有患者的數據
- 所有使用者都可以存取共用數據存放區中的基底醫學知識
在檔案型 RAG 應用程式中，您可能會想要根據檔案上設定的標記配置或敏感度層級，限制使用者存取檔。
當您定義租用戶是什麼，並清楚瞭解授權規則之後，請使用該資訊作為數據存放區解決方案的需求。
篩選
篩選也稱為安全性修剪，是指只向獲授權查看的使用者公開數據。 在多租使用者 RAG 案例中，使用者可能會對應至租使用者特定存放區。 這並不表示使用者應該能夠存取該存放區中的所有數據。 在定義租使用者和授權需求中，我們討論了定義數據授權需求的重要性。 這些授權規則應作為篩選的基礎。
您可以使用數據平臺功能來完成篩選，例如數據列層級安全性，或可能需要自定義邏輯、數據或元數據。 同樣地，由於需要圍繞這些功能設計您的系統，這些平臺功能通常不會用於多租用戶解決方案中。
封裝多租用戶數據邏輯
建議您在您使用的任何儲存機制前面有 API。 API 會作為閘道守衛，強制使用者只能存取他們應該存取的資訊。
圖 4。 使用 API 封裝多租用戶數據存取邏輯的多租使用者 RAG 架構
如本文稍早所述，使用者對數據的存取可以受到下列限制：
- 使用者的租使用者
- 平台功能
- 自定義安全性篩選/修剪規則。
此層應該要有下列責任：
- 將查詢路由至每個租使用者模型中的租使用者特定存放區
- 僅從多租使用者存放區中的使用者租用戶選取數據
- 為使用者使用適當的身分識別來支援支援平臺啟用的授權邏輯
- 強制執行自定義安全性調整邏輯
- 儲存用於稽核用途之地面資訊的存取記錄
需要存取租用戶數據的程式代碼不應該能夠直接查詢後端存放區。 數據的所有要求都應該流經此 API 層。 此 API 層會在租用戶數據之上提供單一治理點或安全性層。 此方法會讓租使用者和用戶數據存取授權邏輯不流向應用程式的不同區域。 此邏輯會封裝在 API 層中。 此封裝可讓解決方案更容易驗證和測試。
摘要
設計多租使用者 RAG 推斷解決方案時，您必須考慮如何為租使用者建構基礎數據解決方案。 瞭解租用戶數目，以及您儲存的每一租用戶數據量。 此資訊可協助您設計數據租用解決方案。 建議您實作封裝數據存取邏輯的 API 層，包括多租用戶和篩選邏輯。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
- John Downs | 主任軟體工程師
- Daniel Scott-Raynsford | Sr. Partner Solution Architect， Data & AI