企業聊天應用程式可以透過對話互動來賦能員工。 得益於語言模型的不斷進步 (例如 OpenAI 的 GPT 模型和 Meta 的 LLaMA 模型)，這一點更是如此。 這些聊天應用程式的組成包括聊天使用者介面 (UI)、與使用者查詢相關特定網域資訊的資料存放庫、能夠對特定網域資料進行推斷以生成相關回應的語言模型，以及負責監視這些元件之間互動的協調器。
本文提供了一個基準架構，用於建置和部署使用 Azure OpenAI 服務語言模型的企業聊天應用程式。 架構會採用提示流程來建立可執行流程。 這些可執行的流程協調從傳入提示到資料儲存的工作流程，以獲取語言模型的基礎資料，以及其他必要的 Python 邏輯。 可執行流程會部署到具有受控計算的受控線上端點。
自定義聊天使用者介面 （UI） 的裝載遵循基準應用程式服務 Web 應用程式指引，以在 Azure App 服務 上部署安全、區域備援和高可用性的 Web 應用程式。 在這個架構中，App Service 會透過私人終端上的虛擬網路整合，與 Azure 平台即服務 (PaaS) 解決方案進行通訊。 聊天 UI 應用程式服務透過私人端點與流程的受控線上端點進行通訊。 已停用對 Azure AI Studio 的公用存取。
重要
本文不會討論基準應用程式服務 Web 應用程式的元件或架構決策。 閱讀該文章，了解如何裝載聊天 UI 的架構指南。
Azure AI Studio 中樞已設定受控 虛擬網路隔離 ，需要核准所有輸出連線。 透過此設定，將建立受控虛擬網路以及受控私人端點，這些端點能夠連接到私人資源，例如工作區 Azure 儲存體、Azure Container Registry 和 Azure OpenAI。 這些私人連接會在流程撰寫和測試期間使用，以及在部署到 Machine Learning 計算的流程中使用。
中樞是最上層的 Azure AI Studio 資源，可提供管理多個專案的安全性、連線和其他顧慮的集中方式。 此架構只需要一個專案才能用於其工作負載。 如果您有需要不同邏輯之不同提示流程的額外體驗，可能會使用不同的後端資源，例如數據存放區，您可以考慮在不同的專案中實作這些資源。
提示
本文由參考實作支援，該參考實作展示了 Azure 上的基準端對端聊天實作。 在邁向生產的第一步中，您可以使用此實作做為自訂解決方案開發的基礎。
架構
下載此架構的 Visio 檔案。
元件
此架構的許多元件與基本的 Azure OpenAI 端對端聊天架構相同。 以下清單只重點介紹基本架構的變更。
- Azure OpenAI 用於基本架構和此基準架構。 Azure OpenAI 是一項完全受控的服務，提供對 Azure OpenAI 語言模型 (包括 GPT-4、GPT-3.5-Turbo 和嵌入模型集) 的 REST API 存取。 基準架構會利用基本架構未實作的企業功能，例如 虛擬網路和私人連結 。
- Azure AI Studio 是一個平臺，可用來建置、測試及部署 AI 解決方案。 AI Studio 會用於此架構，以建置、測試及部署聊天應用程式的提示流程協調流程邏輯。 在此架構中，Azure AI Studio 會提供 受控虛擬網路 以提供網路安全性。 如需詳細資訊，請參閱 網路一節 以取得詳細數據。
- 應用程式閘道 是第 7 層 （HTTP/S） 負載平衡器和 Web 流量路由器。 它使用基於 URL 路徑的路由，在可用性區域之間分配傳入流量並卸載加密，以提高應用程式效能。
- Web 應用程式防火牆 (WAF) 是一項雲端原生服務，可保護 Web 應用程式免受 SQL 注入和跨網站指令碼等常見攻擊。 Web 應用程式防火牆 可讓您監視和保護您 Web 應用程式的流量。
- Azure Key Vault 是一項安全儲存和管理機密、加密金鑰和憑證的服務。 它可集中管理敏感資訊。
- Azure 虛擬網路這項服務可讓您在 Azure 中建立隔離且安全的私人虛擬網路。 對於應用程式服務上的 Web 應用程式，您需要虛擬網路子網路，才能使用私人端點在資源之間進行安全的網路通訊。
- Private Link 讓用戶端可以直接從私人虛擬網路存取 Azure 平台即服務 (PaaS) 服務，而無需使用公用 IP 位址。
- Azure DNS 是 DNS 網域的裝載服務，它使用 Microsoft Azure 基礎結構提供名稱解析。 私人 DNS 區域提供了一種方法，可將服務的完整網域名稱 (FQDN) 對應到私人端點的 IP 位址。
替代項目
此架構有多個元件，其他 Azure 服務可能會更符合工作負載的功能和非功能需求。 以下是一些需要注意的這類替代方案。
Azure 機器學習 工作區 （和入口網站體驗）
此架構會使用 Azure AI Studio 來建置、測試及部署提示流程。 或者，您可以使用 Azure 機器學習 工作區，因為兩個服務都有重疊的功能。 雖然 AI Studio 是設計提示流程解決方案的絕佳選擇，但 Azure 機器學習 目前有較佳支援的功能。 如需詳細資訊，請參閱 功能比較。 建議您不要混合和比對 Azure AI Studio 和 Azure 機器學習。 如果您的工作可以在 AI Studio 中完全完成，請使用 AI Studio。 如果您仍然需要 Azure Machine Learning 工作室 的功能，請繼續使用 Azure Machine Learning 工作室。
應用層元件
Azure 中提供數個受控應用程式服務供應專案，可作為聊天 UI 前端應用層。 請參閱 針對所有計算選擇 Azure 計算服務 ，以及 針對容器解決方案選擇 Azure 容器服務 。 例如，雖然已針對聊天 UI API 和提示流程主機分別選取 Azure Web Apps 和 Web App for Containers，但可以使用 Azure Kubernetes Service （AKS） 或 Azure Container Apps 來達成類似的結果。 根據工作負載的特定功能和非功能需求，選擇工作負載的應用程式平臺。
提示流程裝載
部署提示流程不限於 機器學習 計算叢集，而且此架構說明 Azure App 服務 中的替代方式。 流程最終會是容器化應用程式，可部署到任何與容器相容的 Azure 服務。 這些選項包括 Azure Kubernetes Service （AKS）、Azure Container Apps 和 Azure App 服務 等服務。 根據您的協調流程層需求選擇 Azure 容器服務 。
本文稍後會討論為何在替代計算上裝載提示流程的範例。
地面數據存放區
雖然此架構會與 Azure AI 搜尋搭配使用，但您為地面數據選擇的數據存放區是工作負載專屬的架構決策。 事實上，許多工作負載都是polyglot，而且有不同來源和技術來建立基礎數據。 這些數據平臺的範圍從現有的 OLTP 資料存放區、Azure Cosmos DB 等雲端原生資料庫，到 Azure AI 搜尋等特殊解決方案。 這類數據存放區的常見但並非必要特性是向量搜尋。 請參閱 選擇 Azure 服務進行向量搜尋 ，以探索此空間中的選項。
考慮和建議
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。
基準 App Service Web 應用程式架構著重於關鍵區域服務的區域備援。 可用性區域是區域內實體上獨立的位置。 當跨區域部署兩個或多個執行個體時，它們在區域內提供備援以支援服務。 當一個可用性區域發生停機時，該區域內的其他可用性區域可能仍不受影響。 此架構還確保足夠的 Azure 服務執行個體，以及這些服務的設定分佈在可用性區域中。 有關更多資訊，請參閱「基準」以查看該指南。
本部分從應用程式服務基準中未解決的此架構中組件的角度討論了可靠性，包括 Machine Learning 、Azure OpenAI 和 AI 搜尋服務。
流程部署的區域備援
企業部署通常需要區域備援。 要在 Azure 中實現區域備援，資源必須支援可用性區域，並且必須部署至少三個資源執行個體，或在執行個體控制不可用時啟用平台支援。 目前，Machine Learning 計算不提供可用性區域的支援。 為了減輕資料中心級災難對 Machine Learning 元件的潛在影響，有必要在各個區域建立叢集，並部署負載平衡器以在這些叢集之間分配呼叫。 您可以使用執行狀況檢查，協助確保呼叫只路由到正常執行的叢集。
有一些替代方法可 機器學習 計算叢集，例如 Azure Kubernetes Service （AKS）、Azure Functions、Azure Container Apps 和 Azure App 服務。 其中每項服務都支援可用性區域。 為了實現提示流程執行的區域備援，而不增加多區域部署的複雜性，您應該將流程部署到其中一項服務。
下圖顯示了提示流程部署到應用程式服務的替代架構。 此架構中使用了應用程式服務，因為工作負載已將其用於聊天 UI，並且不會因在工作負載中引入新技術而受益。 具有 AKS 經驗的工作負載團隊應考慮在該環境中進行部署，尤其是當 AKS 用於工作負載中的其他元件時。
該圖針對該架構中的值得注意的區域進行了編號：
流程仍會以提示流程撰寫，且網路架構不會變更。 流程作者仍會透過私人端點連線到 AI Studio 專案中的撰寫體驗，而受控私人端點則用來在測試流程時連線到 Azure 服務。
此虛線表示容器化的可執行流程被推送到 Container Registry。 圖中未顯示將流程容器化並推送到 Container Registry 的管線。 這些管線執行的計算必須具有 Azure 容器登錄和 AI Studio 專案等資源的網路視線。
還有另一個 Web 應用程式部署至已裝載聊天 UI 的相同 App Service 方案。 新的 Web 應用程式裝載容器化提示流程，共置在已至少執行三個實例的相同 App Service 方案上，分散於可用性區域。 載入提示流程容器映像時，這些應用程式服務執行個體會透過私人端點連接到 Container Registry。
提示流程容器需要連接到所有依賴的服務才能執行流程。 在此架構中，提示流程容器連接到 AI Search 和 Azure OpenAI。 只向 Machine Learning 受控私人端點子網路公開的 PaaS 服務現在也需要在虛擬網路中公開，以便可以從 App Service 建立可見性。
Azure OpenAI - 可靠性
Azure OpenAI 目前不支援可用性區域。 為了減輕資料中心級災難對 Azure OpenAI 模型部署的潛在影響，有必要將 Azure OpenAI 部署到不同的區域，並部署負載平衡器以在各區域之間分配呼叫。 您可以使用執行狀況檢查，協助確保呼叫只路由到正常執行的叢集。
為了有效支援多個執行個體，我們建議您將微調檔案外部化，例如異地備援儲存體帳戶。 此方法可最大限度地減少儲存在每個區域的 Azure OpenAI 中的狀態。 您仍然必須微調每個執行個體的檔案，才能裝載模型部署。
監視每分鐘權杖數 (TPM) 和每分鐘請求數 (RPM) 所需的輸送量非常重要。 確保從配額中分配足夠的 TPM 以滿足您的部署需求，並防止已部署模型的呼叫受到限制。 Azure API 管理 之類的閘道可以部署在 Azure OpenAI 服務或服務前面，而且可以在發生暫時性錯誤和節流時設定重試。 API 管理也可以當做斷路器，以防止服務因呼叫而不堪重負，超出其配額。 若要深入瞭解如何新增閘道以取得可靠性考慮，請參閱 透過閘道存取 Azure OpenAI 和其他語言模型。
AI 搜尋服務 - 可靠性
在支援可用性區域的區域中部署具有標準定價層或更高定價層的 AI 搜尋服務，並部署三個或更多副本。 副本會自動均勻分佈在可用性區域中。
請考慮以下指南來確定適當的副本和分區數量：
使用監視指標和記錄以及效能分析來確定適當的副本數量，以避免基於查詢的節流和分區，並防止基於索引的節流。
Azure AI Studio - 可靠性
如果您部署至 機器學習 受控在線端點後方的計算叢集，請考慮下列有關調整的指引：
自動擴展您的線上端點，以確保有足夠的容量來滿足需求。 如果由於突發使用情況而導致使用訊號不夠及時，請考慮進行超額佈建，以防止因可用執行個體過少而影響可靠性。
對於活躍的生產部署，應至少部署三個執行個體。
避免在正在使用的執行個體上進行部署。 而是部署到新的部署中，並在部署準備好接收流量後再轉移流量。
受控在線端點會作為負載平衡器和路由器，供其後方執行的受控計算使用。 您可以設定應該路由傳送至每個部署的流量百分比，只要百分比加起來最多 100%。 您也可以部署受控在線端點，並將 0% 的流量路由傳送至任何部署。 如果在提供的參考實作中，您會使用基礎結構即程序代碼 （IaC） 來部署資源，包括受控在線端點，則有可靠性考慮。 如果您已將流量設定為路由傳送至部署（透過 CLI 或 Azure AI Studio 建立），而且您執行包含受控在線端點的後續 IaC 部署，即使它不會以任何方式更新受控在線端點，端點流量會還原為路由 0% 流量。 實際上，這表示在您將流量調整回您想要的位置之前，將無法再連線已部署的提示流程。
注意
如果將流程部署到應用程式服務，則適用來自基準架構的相同應用程式服務可擴充性指南。
多區域設計
此架構不是建置成多重區域架構中的區域戳記。 由於可用性區域的完整使用，它確實提供單一區域內的高可用性，但缺少一些重要元件，可讓這真正準備好用於多區域解決方案。 以下是此架構中缺少的一些元件或考慮：
- 全域輸入和路由
- DNS 管理策略
- 數據復寫（或隔離）策略
- 主動-主動、主動-被動或主動冷指定
- 故障轉移和容錯回復策略，可達成工作負載的 RTO 和 RPO
- Azure Studio Hub 資源中開發人員體驗的區域可用性決策
如果您的工作負載需求需要多區域策略，您必須在此架構中呈現的內容之上，投資元件和作業程式的其他設計工作。 您設計來支援下列層級的負載平衡或故障轉移：
- 基礎資料
- 模型裝載
- 協調流程層 （此架構中的提示流程）
- 面向用戶端的UI
此外，您需要在可觀察性、入口網站體驗和負責任的 AI 考慮中維護商務持續性，例如內容安全性。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。
此架構擴展了在 Azure OpenAI 架構的基本端對端聊天中實作的安全範圍。 雖然基本架構使用系統指派的受控識別和系統指派的角色指派，但此架構會使用使用者指派的身分識別搭配手動建立的角色指派。
該架構實現了網路安全邊界，以及在基本架構中實現的身分識別識別邊界。 從網路角度來看，唯一可以從網際網路存取的是透過應用程式閘道的聊天 UI。 從身分識別識別角度來看，聊天 UI 應該對請求進行驗證和授權。 在可能的情況下，使用受控身分識別識別對 Azure 服務的應用程式進行驗證。
除網路注意事項外，本部分也介紹了金鑰輪換和 Azure OpenAI 模型微調的安全注意事項。
身分識別與存取權管理
使用使用者指派的受控識別時，請考慮下列指引：
- 針對下列 Azure AI Studio 和 機器學習 資源建立個別的受控識別，並視情況適用：
- AI Studio Hub
- 用於流程撰寫和管理的 AI Studio 專案
- 如果流程部署到受控線上端點，則線上端點將在已部署的流程中使用
- 使用 Microsoft Entra ID 實作聊天 UI 的身分識別識別存取控制
針對您想要與其他人隔離的不同提示流程，從許可權觀點建立不同的專案和在線端點。 為每個專案和受控在線端點建立個別的受控識別。 僅提供提示流程作者存取所需的專案。
當您將使用者上線至 Azure AI Studio 專案以執行如撰寫流程等函式時，您需要將最低許可權角色指派給他們所需的資源。
Machine Learning 角色型存取角色
如同基本架構，系統會自動為系統指派的受控識別建立角色指派。 因為系統不知道中樞和專案可使用哪些功能，所以它會建立角色指派，支援所有潛在的功能。 根據使用案例，自動建立的角色指派可能會超過布建許可權。 例如，指派給容器登錄中樞的「參與者」角色，其中可能只需要控制平面的「讀取者」存取權。 如果您需要進一步限制最低許可權目標的許可權，您必須使用使用者指派的身分識別。 您將自行建立和維護這些角色指派。
由於管理所有必要工作分派的維護負擔，此架構優先於絕對最低許可權角色指派的卓越營運。 請注意，您必須讓數據表中列出的所有工作分派。
| 受控識別 | 範圍 | 角色指派 |
|---|---|---|
| 中樞受控識別 | 參與者 | 資源群組 |
| 中樞受控識別 | 中樞 | Azure AI 系統管理員 |
| 中樞受控識別 | Container Registry | 參與者 |
| 中樞受控識別 | 金鑰保存庫 | 參與者 |
| 中樞受控識別 | 金鑰保存庫 | 系統管理員 |
| 中樞受控識別 | 儲存體帳戶 | 讀取者 |
| 中樞受控識別 | 儲存體帳戶 | 儲存體帳戶參與者 |
| 中樞受控識別 | 儲存體帳戶 | 儲存體 Blob 資料參與者 |
| 中樞受控識別 | 儲存體帳戶 | 儲存體檔案資料特殊權限參與者 |
| 中樞受控識別 | 儲存體帳戶 | 儲存體資料表資料參與者 |
| 專案受控識別 | 專案 | Azure AI 系統管理員 |
| 專案受控識別 | Container Registry | 參與者 |
| 專案受控識別 | 金鑰保存庫 | 參與者 |
| 專案受控識別 | 金鑰保存庫 | 系統管理員 |
| 專案受控識別 | 儲存體帳戶 | 讀取者 |
| 專案受控識別 | 儲存體帳戶 | 儲存體帳戶參與者 |
| 專案受控識別 | 儲存體帳戶 | 儲存體 Blob 資料參與者 |
| 專案受控識別 | 儲存體帳戶 | 儲存體檔案資料特殊權限參與者 |
| 專案受控識別 | 儲存體帳戶 | 儲存體資料表資料參與者 |
| 線上端點受控身分識別識別 | 專案 | Azure 機器學習 工作區連線秘密 |
| 線上端點受控身分識別識別 | 專案 | AzureML 計量寫入器 |
| 線上端點受控身分識別識別 | Container Registry | ACRPull |
| 線上端點受控身分識別識別 | Azure OpenAI | 認知服務 OpenAI 使用者 |
| 線上端點受控身分識別識別 | 儲存體帳戶 | 儲存體 Blob 資料參與者 |
| 線上端點受控身分識別識別 | 儲存體帳戶 | 儲存體 Blob 資料讀者 |
| App Service （當提示流程部署至 App Service 時） | Azure OpenAI | 認知服務 OpenAI 使用者 |
| 入口網站使用者 （提示流程開發） | Azure OpenAI | 認知服務 OpenAI 使用者 |
| 入口網站使用者 （提示流程開發） | 儲存體帳戶 | 記憶體 Blob 資料參與者（使用條件式存取） |
| 入口網站使用者 （提示流程開發） | 儲存體帳戶 | 儲存體檔案資料特殊權限參與者 |
請務必瞭解 AI Studio 中樞具有跨項目共用的 Azure 資源，例如記憶體帳戶和 Container Registry。 如果您有使用者只需要存取專案子集，請考慮針對支持這些專案的 Azure 服務使用 角色指派條件，以提供資源的最低許可權存取權。 例如，Azure 儲存體 中的 Blob 支援角色指派條件。 對於需要存取專案子集的使用者，而不是以每個容器為基礎指派許可權的使用者，請使用角色存取條件來限制這些專案所使用的 Blob 容器許可權。 每個專案都有唯一的 GUID，做為該專案中所使用 Blob 容器名稱的前置詞。 該 GUID 可以當做角色指派條件的一部分使用。
中樞必須能夠 Contributor 存取中樞資源群組，以允許其建立和管理中樞和項目資源。 中樞具有控制平面存取資源群組中任何資源的副作用。 任何與中樞及其項目無關的 Azure 資源都應該建立在個別的資源群組中。 建議您使用自我管理的 Azure AI Studio Hub，為工作負載小組建立至少兩個資源群組。 包含中樞、其專案及其所有直接相依性的資源群組，例如 Azure 容器登錄、金鑰保存庫 等等。 一個資源群組，以在您的工作負載中包含其他所有專案。
我們建議您將中樞作業所需的 Azure 資源使用降到最低（Container Registry、記憶體帳戶、金鑰保存庫、Application Insights），以及工作負載中的其他元件。 例如，如果您需要將秘密儲存為工作負載的一部分，您應該建立與中樞相關聯的密鑰保存庫以外的個別 金鑰保存庫。 中樞 金鑰保存庫 只應該由中樞用來儲存中樞和專案秘密。
請確定針對每個相異專案，其相依性的角色指派不會提供入口網站使用者和受控在線端點受控識別不需要的資源存取權。 例如， Cognitive Services OpenAI User Azure OpenAI 的角色指派會授與該資源所有部署的存取權。 沒有任何方法可以限制流程作者或受控在線端點受控識別，且該角色指派存取 Azure OpenAI 中的特定模型部署。 針對這類案例，我們的指引是根據每個專案部署 Azure OpenAI 和 Azure AI 搜尋等服務，且不會將資源部署到流程作者或受控在線端點受控識別不應該存取的服務。 例如，只將模型部署到專案 Azure OpenAI 實例，而專案需要存取。 只有將索引部署到專案 Azure AI 搜尋實例，項目應該可以存取。
網路
除了基於身分識別識別的存取之外，網路安全也是使用 OpenAI 的基準端對端聊天架構的核心。 從較高的層面來看，網路架構確保：
- 只有一個安全的聊天 UI 流量輸入點。
- 網路流量被篩選。
- 傳輸中的資料透過傳輸層安全性 (TLS) 進行端對端加密。
- 透過使用私人連結將流量保留在 Azure 中，可以最大程度地減少資料外洩。
- 網路資源會透過網路分割，以邏輯方式分組並彼此隔離。
網路流量
基準 App Service Web 應用程式架構涵蓋了此圖中的兩個流程：從終端使用者到聊天 UI 的輸入流程 (1)，和從應用程式服務到 Azure PaaS 服務的流程 (2)。 本節重點介紹 Machine Learning 線上端點流程。 以下流程從在基準 App Service Web 應用程式中執行的聊天開始，到部署至 Machine Learning 計算的流程：
- 來自 App Service 裝載的聊天 UI 呼叫會透過私人端點路由到 Machine Learning 線上端點。
- 線上端點將呼叫路由到執行已部署流程的伺服器。 線上端點既可當作負載平衡器又可當作路由器。
- 已部署流程所需的 Azure PaaS 服務的呼叫透過受控私人終端進行路由。
進入 Machine Learning
在此架構中，會停用對 Machine Learning 工作區的公共存取。 使用者可以透過私人存取來存取工作區，因為此架構遵循 Machine Learning 工作區私人端點的設定。 事實上，整個架構都會使用私人端點來補充基於身分識別識別的安全性。 例如，App Service 裝載的聊天 UI 可以連接到未在公共網際網路上公開的 PaaS 服務，包括 Machine Learning 端點。
要連接到 Machine Learning 工作區進行流程撰寫還需要私人端點存取權。
此圖顯示了提示流程作者透過 Azure Bastion 連接到虛擬機器跳板機。 從此跳板機，作者可以透過與跳板機位於同一網路中的私人端點連接到 Machine Learning 工作區。 還可以透過 ExpressRoute 或 VPN 閘道以及虛擬網路對等互連來實現與虛擬網路的連線。
從 Azure AI Studio 受控虛擬網路流向 Azure PaaS 服務
建議您針對受控虛擬網路隔離設定 Azure AI Studio 中樞，以要求核准所有輸出連線。 此架構遵循該建議。 核准的輸出規則有兩種類型。 必要的輸出規則是指解決方案正常運作所需的資源，例如 Container Registry 和儲存體。 使用者定義的輸出規則適用於工作流程將使用的自訂資源，例如 Azure OpenAI 或 AI 搜尋服務。 您必須設定使用者自訂的輸出規則。 建立受控虛擬網路時要設定必要的輸出規則。 當您第一次使用受控虛擬網路時，會視需要部署受控虛擬網路，並從此持續運作。
輸出規則可以是私人端點、服務標籤或外部公共端點的完整網域名稱 (FQDN)。 在此架構中，與 Container Registry 、儲存體、Azure Key Vault、Azure OpenAI 和 AI 搜尋服務等 Azure 服務的連接會透過私人連結進行連接。 雖然在這個架構中沒有，但有些常見的操作可能需要設定 FQDN 輸出規則，例如下載 pip 套件、複製 GitHub 倉庫或從外部庫下載基礎容器影像。
虛擬網路分割與安全性
此架構中的網路具有單獨的子網，其用途如下：
應用程式閘道
App Service 整合元件
私人端點
Azure Bastion
跳板機虛擬機器
定型和評分子網 - 這兩者都是為了自備與定型和推斷相關的計算。 在此架構中，我們不會進行定型，而我們使用受控計算。
評分
每個子網路都有一個網路安全群組 (NSG)，該群組會限制這些子網路的輸入和輸出流量，只允許必要的流量。 下表顯示了基準為每個子網路新增 NSG 規則的簡化檢視。 表格提供了規則名稱和功能。
| 子網路 | 輸入 | 輸出 |
|---|---|---|
| snet-appGateway | 允許我們聊天使用者介面的來源 IP (例如公共網際網路)，以及服務所需的項目。 | 存取應用程式服務私人端點，以及該服務的必要項目。 |
| snet-PrivateEndpoints | 只允許來自虛擬網路的流量。 | 只允許流程向虛擬網路的流量。 |
| snet-AppService | 只允許來自虛擬網路的流量。 | 允許存取私人端點和 Azure Monitor。 |
| AzureBastionSubnet | 請參閱「使用 NSG 存取和 Azure Bastion」中的指南。 | 請參閱「使用 NSG 存取和 Azure Bastion」中的指南。 |
| snet-jumpbox | 允許來自 Azure Bastion 主機子網路的輸入遠端桌面協定 (RDP) 和 SSH。 | 允許存取私人端點 |
| snet-agents | 只允許來自虛擬網路的流量。 | 只允許流程向虛擬網路的流量。 |
| snet-training | 只允許來自虛擬網路的流量。 | 只允許流程向虛擬網路的流量。 |
| snet-scoring | 只允許來自虛擬網路的流量。 | 只允許流程向虛擬網路的流量。 |
明確拒絕其他流量。
實作虛擬網路分割和安全性時，請考慮以下幾點。
使用子網路為虛擬網路啟用 DDoS 保護，該子網路屬於具有公用 IP 位址的應用程式閘道。
盡可能將 NSG 新增到每個子網路。 使用最嚴格的規則來啟用完整的解決方案功能。
使用應用程式安全性群組對 NSG 進行分組。 對 NSG 進行分組可以更輕鬆地為複雜環境建立規則。
金鑰輪替
此架構中有一個服務使用金鑰型驗證：機器學習 受控在線端點。 因為您將金鑰型驗證用於此服務，因此請務必：
將金鑰儲存在安全存放區中 (例如 Key Vault)，以便授權用戶端 (例如裝載提示流程容器的 Azure Web App) 以進行隨選存取。
實作金鑰輪換策略。 如果您手動輪替密鑰，請建立金鑰到期原則，並使用 Azure 原則 來監視密鑰是否已輪替。
OpenAI 模型微調
如果您在實作中微調 OpenAI 模型，請考慮以下指南：
如果您上傳訓練資料進行微調，請考慮使用客戶自控金鑰來加密該資料。
如果將訓練資料儲存在 Azure Blob 儲存體等存放區中，請考慮使用客戶自控金鑰進行資料加密、使用受控身分識別識別來控制資料的存取權，以及使用私人端點來連接到資料。
透過原則進行治理
為了協助確保安全性，請考慮使用 Azure 原則和網路策略，以便部署符合工作負載的要求。 透過策略使用平台自動化可以減輕手動驗證步驟的負擔，並確保即使繞過管線也能進行治理。 考慮以下安全性策略：
- 停用 Azure AI 服務和 Key Vault 等服務中的金鑰或其他本機驗證存取。
- 需要網路存取規則或 NSG 的特定設定。
- 需要加密，例如使用客戶自控金鑰。
適用於 Azure 金鑰保存庫 的 Azure AI Studio 角色指派
Azure AI Studio 受控識別需要控制平面（參與者）和數據平面（金鑰保存庫 系統管理員）角色指派。 這表示此身分識別具有儲存在 Azure 金鑰保存庫中之所有秘密、金鑰和憑證的讀取和寫入存取權。 如果您的工作負載具有 Azure AI Studio 以外的服務，而該服務需要存取 金鑰保存庫 中的秘密、密鑰或憑證，您的工作負載或安全性小組可能不熟悉可存取這些成品的 Azure AI Studio 中樞受控識別。 在此情況下，請考慮特別針對 Azure AI Studio 中樞和其他 Azure 金鑰保存庫 實例部署 金鑰保存庫 實例，以適合工作負載的其他部分。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。
若要查看此方案的定價範例，請使用 Azure 定價計算機。 您需要根據自己的使用情況自訂此範例，因為此範例僅包含架構中的元件。 案例中最昂貴的元件是 DDoS 保護，以及部署為受控在線端點一部分的防火牆。 其他值得注意的成本是聊天UI和提示流程計算和 AI 搜尋。 最佳化這些資源以節省最多成本。
計算
提示流程支援多個選項來裝載可執行流程。 這些選項包括 Machine Learning、AKS、App Service 和 Azure Kubernetes 服務中的受控線上端點。 每個選項都有自己的計費模型。 選擇的計算方式會影響解決方案的整體成本。
Azure OpenAI
Azure OpenAI 是一種耗用型服務，與任何耗用型服務一樣，控制需求與供應之間的關係是主要的成本控制方式。 要在 Azure OpenAI 中做到這一點，您需要採用多種方法的組合：
控制用戶端。 用戶端請求是消費模型中成本的主要來源，因此控制用戶端行為至關重要。 所有客戶應：
獲得核准。 避免以支援免費存取的方式公開服務。 透過網路和身分識別識別控制 (例如金鑰或基於角色的存取控制 (RBAC)) 限制存取。
保持自我控制。 要求用戶端使用 API 呼叫提供的權杖限制約束，例如 max_tokens 和 max_completions。
在可行的情況下使用批次處理。 檢查客戶以確保他們正確地批次提示。
最佳化提示輸入和回應長度。 較長的提示會耗用更多的權杖，從而提高成本，但缺少足夠上下文的提示無助於模型產生良好的結果。 建立簡潔的提示，提供足夠的上下文，使模型能夠產生有用的回應。 同樣，請確保最佳化回應長度的限制。
應根據需要使用 Azure OpenAI Playground，並應在預先生產執行個體上進行，以避免這些活動產生生產成本。
選擇正確的 AI 模型。 模型選擇在 Azure OpenAI 的整體成本中也扮演著重要角色。 所有模型都有其優點和缺點，並且單獨定價。 根據使用案例選擇正確的模型，以確保不會在更昂貴的模型上過度花費，而使用較便宜的模型即可達到滿意的效果。 這個聊天參考實作中選擇了 GPT 3.5-turbo 而不是 GPT-4，以節省約一個量級的模型部署成本，同時達到滿意的效果。
了解計費的臨界點。 微調是按小時收費。 為了達到最高效率，您會希望在每小時內充分利用可用時間來改善微調結果，同時避免剛好進入下一個計費週期。 同樣，生成 100 張影像的成本與生成一張影像的成本相同。 充分利用價格臨界點，以獲取最大利益。
了解計費模型。 Azure OpenAI 也可以透過佈建輸送量方案，提供提交型計費模型。 當您擁有可預測的使用模式後，如果這種預購計費模式對您的使用方式更具成本效益，請考慮切換到這種預購計費模式。
設定佈建限制。 確保所有佈建配額只分配給預期將成為工作負載一部分的模型，並按照模型逐一分配。 啟用動態配額時，對於已部署模型的輸送量不受此預設定配額的限制。 配額並不直接對應到成本，且成本可能會有所變動。
監視隨用隨付的使用情況。 如果您使用隨用隨付定價，請監視 TPM 和 RPM 的使用情況。 使用這些資訊來指引架構設計決策，例如使用哪些模型，並最佳化提示大小。
成本管理。 遵循有關使用 OpenAI 成本管理功能的指導，以監視成本、設定預算來管理成本，並建立警示以通知利害關係人風險或異常情況。
卓越營運
卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運的設計檢閱檢查清單。
內建提示流程運行時間
與基本架構一樣，此架構使用自動執行階段來將操作負擔降到最低。。 自動執行階段是機器學習中的一種無伺服器計算選項，其簡化了計算管理，並將大部分提示流程設定委派給執行應用程式的 requirements.txt 檔案和 flow.dag.yaml 設定。 這使得這種選擇具有低維護性、短暫性且由應用程式驅動。 使用計算執行個體執行階段或外部計算 (如在此架構中) 需要更多由工作負載團隊管理的計算生命週期，並且應在工作負載需求超過自動執行階段選項的設定能力時，選擇此選項。
監視
與基本架構類似，所有服務都設定了診斷功能。 除了 App Service 的所有服務都已設定為擷取所有記錄。 App Service 設定為擷取 AppServiceHTTPLogs、AppServiceConsoleLogs、AppServiceAppLogs 和 AppServicePlatformLogs。 在生產環境中，所有記錄可能會過多。 調整記錄數據流以符合您的作業需求。 針對此架構，Azure AI Studio 專案所使用的 Azure 機器學習 記錄包括：AmlComputeClusterEvent、AmlDataSetEvent、AmlEnvironmentEvent 和 AmlModelsEvent。
評估為此架構中的資源建立自訂警示，例如 Azure Monitor 基準警示中所找到的那些警示。 例如：
請務必追蹤 Azure OpenAI 模型部署的令牌使用量。 在此架構中，提示流程會透過與 Azure 應用程式 Insights 整合來追蹤令牌使用方式。
語言模型操作
基於 Azure OpenAI 的聊天解決方案 (如此架構) 部署應遵循 GenAIOps 中的指南，結合 Azure DevOps 和 GitHub 進行提示流程管理。 此外，它必須考慮持續整合和持續傳遞 (CI/CD) 以及網路安全架構的最佳做法。 以下指南根據 GenAIOps 建議，實作流程及其相關基礎結構。 此部署指導不包括前端應用程式元素，這些元素與「基準高可用性區域域備援 Web 應用程式架構」中的內容相同。
部署
提示流程在 Azure AI Studio 中或透過 Visual Studio Code 擴充功能提供瀏覽器型撰寫體驗。 這兩個選項都可將流程程式碼儲存為檔案。 當您使用 Azure AI Studio 時，檔案會儲存在記憶體帳戶中。 當您使用 Microsoft Visual Studio Code 時，檔案會儲存在本機檔案系統中。
為了遵循協作開發的最佳做法，原始檔案應儲存線上上原始碼存放庫 (例如 GitHub) 中。 這種方法有助於追蹤所有程式碼變更，促進流程作者之間的協作，並與測試和驗證所有程式碼變更的部署流程整合。
對於企業開發，請使用 Microsoft Visual Studio Code 擴充功能和提示流程 SDK/CLI 進行開發。 提示流程的作者可以從在Microsoft Visual Studio Code 中建立和測試其流程，並將本機儲存的檔案與線上原始檔控制系統和管線整合。 雖然瀏覽器式體驗非常適合探索性開發，但透過一些工作，它可以與原始檔控制系統整合。 您可以從 Files 面板的流程頁面下載、解壓縮流程資料夾，並將其推送到原始檔控制系統。
評估
就像測試其他軟體成品一樣，測試聊天應用程式中使用的流程。 要為語言模型輸出指定和斷言單一「正確」答案並不容易，但您可以使用語言模型本身來評估回應。 考慮實作以下自動化評估來評估您的語言模型流程：
分類準確性：評估語言模型是否給出「正確」或「不正確」的分數，並彙總結果以生成準確性等級。
連貫性：評估模型預測答案中句子寫得有多好，以及它們之間的連貫性。
流暢性：評估模型預測答案的語法和語言準確性。
針對情境的基礎性：評估模型的預測答案與預先設定情境的貼合度。 即使語言模型的回應是正確的，如果無法根據指定的上下文對其進行驗證，那麼這些回應就沒有根據實際情況進行回答。
相關性：評估模型的預測答案與所提出問題的一致程度。
實作自動化評估時請考慮以下指引：
根據評估產生分數並根據預先定義的成功閾值進行衡量。 使用這些分數來報告管線中的測試通過/失敗情況。
其中一些測試需要預先設定的問題、上下文和基本事實資料輸入。
包含足夠的問答對以確保測試結果可靠，建議至少 100-150 對。 這些問題-答案對被稱為「黃金資料集」。根據資料集的大小和領域，可能需要更大的群體。
避免使用語言模型產生黃金資料集中的任何資料。
部署流程
提示工程師/料科學家會開啟功能分支，讓他們處理特定工作或功能。 提示工程師/資料科學家會使用 Visual Studio Code Microsoft 的提示流程來反覆運算流程，定期認可變更，並將這些變更推送至功能分支。
完成本機開發和實驗之後，提示工程師/資料科學家會將功能分支的提取要求開啟至主分支。 提取要求 (PR) 會觸發PR管線。 此管線會執行快速品質檢查，其中包括：
- 執行實驗流程
- 執行已設定的單元測試
- 程式碼基底的編譯
- 靜態程式碼分析
管線可以包含一個步驟，要求至少一個小組成員在合併之前手動核准 PR。 核准者不能是認可者，而且他們擁有提示流程專業知識和熟悉專案需求。 如果未核准 PR，則會封鎖合併。 如果 PR 已核准，或沒有核准步驟，功能分支就會合併至主分支。
合併至主分支會觸發開發環境的建置和發行程序。 具體而言：
- CI 管線會從合併觸發至主分支。 CI 管線執行 PR 管線中完成的所有步驟，以及以下步驟：
- 實驗流程
- 評估流程
- 偵測到變更時在 Machine Learning 登錄中註冊流程
- CD 管線會在 CI 管線完成之後觸發。 此流程執行以下步驟：
- 將流程從 Machine Learning 登錄部署到 Machine Learning 線上端點
- 執行針對線上端點的整合測試
- 執行針對線上端點的冒煙測試
核准程序內建於核准後發行升級程序，CI & CD 程序在步驟 4.a. & 4.b. 中的描述是重複的，以測試環境為目標。 步驟 4.a. 和 4.b. 相同，不同之處在於使用者驗收測試是在測試環境中的煙霧測試之後執行。
步驟 4.a 和 4.b. 中所述的 CI & CD 程序 在測試環境驗證和核准後，將執行 & 4.b 來促進將版本發佈到生產環境。
發行至即時環境之後，就會執行監視效能計量和評估已部署語言模型的作業工作。 其中包括 (但不限於)：
- 偵測資料漂移
- 觀察基礎結構
- 管理成本
- 將模型的效能傳達給專案關係人
部署指引
您可以使用 Machine Learning 端點來部署模型，從而在發佈到生產環境時實現靈活性。 考慮以下策略以確保最佳模型效能和品質：
藍/綠部署：透過此策略，您可以將新版本的 Web 服務安全地部署給有限的使用者或請求群組，然後再將所有流量引導至新部署。
A/B 測試：藍/綠部署不只可以有效且安全地推出更改，還可以用於部署新行為，允許一部分使用者評估更改的影響。
包括 Python 檔案的 linting，這些檔案是管線中提示流程的一部分。 Linting 檢查是否符合樣式標準、錯誤、程式碼複雜度、未使用的匯入和變數命名。
將流程部署至網路隔離的 Machine Learning 工作區時，請使用自架代理程式將專案部署至 Azure 資源。
只有當模型發生變更時，才應更新 Machine Learning 模型登錄。
語言模型、流程和用戶端 UI 應該是鬆散耦合的。 流程和用戶端 UI 的更新可以而且應該能夠在不影響模型的情況下進行，反之亦然。
當您開發和部署多個流程時，每個流程都應該有自己的生命週期，這樣可以在將流程從實驗階段升級到生產時，提供鬆散耦合的體驗。
基礎結構
當您部署基準 Azure OpenAI 端對端聊天元件時，所配置的某些服務在架構中屬於基礎和永久服務，而其他元件更為短暫，它們的存在與部署相關。 此外，雖然受控虛擬網路是基礎虛擬網路，但當您建立計算實例時會自動布建，這會導致一些考慮。
基礎組件
此架構中的某些元件的生命週期超出了任何單獨的提示流程或任何模型部署。 這些資源通常由工作負載團隊作為基礎部署的一部分部署一次，並與提示流程或模型部署的新增、刪除或更新分開進行維護。
- Machine Learning 工作區
- Machine Learning 工作區的儲存體帳戶
- Container Registry
- AI 搜尋服務
- Azure OpenAI
- Azure Application Insights
- Azure Bastion
- 用於跳板機的 Azure 虛擬機
臨時組件
某些 Azure 資源與特定提示流程的設計更緊密地耦合。 這種方法允許將這些資源繫結到元件的生命週期，並在此架構中變得短暫。 當工作負載發生變化時，例如新增或刪除流程或引入新模型時，Azure 資源會受到影響。 這些資源將被重新建立，並且先前的執行個體將被刪除。 其中一些資源是直接的 Azure 資源，有些是其包含的服務中的資料平面表現。
Machine Learning 模型登錄中的模型 (如果發生變更) 應作為 CD 管線的一部分進行更新。
容器映像應作為 CD 管線的一部分在 Container Registry 中更新。
如果部署參考不存在的端點，則會在部署提示流程時建立 Machine Learning 端點。 此端點需要更新以關閉公共存取。
部署或刪除流程時，會更新 Machine Learning 端點的部署。
建立新端點時，必須使用端點的金鑰更新用戶端 UI 的金鑰存放庫。
隨選受控虛擬網路
當您第一次建立計算實例時，系統會自動布建受控虛擬網路。 如果您使用基礎結構即程式代碼來部署中樞，而且 Bicep 中沒有 AI Studio 計算資源，則不會部署受控虛擬網路，而且連線到 Azure AI Studio 時會收到錯誤。 您必須執行一次性動作，才能 在 IaC 部署之後手動佈建受控虛擬網路 。
資源組織
如果您有中樞由工作負載小組以外的小組集中擁有的案例，您可以選擇將專案部署到不同的資源群組。 如果您使用基礎結構即程序代碼，您可以在 Bicep 中設定不同的資源群組來完成此作業。 如果您使用入口網站，您可以將 底下的 workspaceHubConfig 屬性設定defaultWorkspaceResourceGroup為您想要建立專案的資源群組。
效能效益
效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 有關詳細資訊，請參閱效能效率的設計審核清單。
本部分從 Azure 搜尋服務、Azure OpenAI 和 Machine Learning 的角度介紹效能效益。
Azure 搜尋服務 - 效能效益
依照指南分析 AI 搜尋服務中的效能。
Azure OpenAI - 效能效益
確定您的應用程式是否需要佈建輸送量，或共用裝載或耗用模型。 佈建輸送量可確保為您的 OpenAI 模型部署預留處理能力，從而為您的模型提供可預測的效能和輸送量。 這種計費模型不同於共用裝載或耗用模型。 耗用模型是以最大努力為原則，可能會受到「吵鬧的鄰居」或平台上的其他壓力因素的影響。
監視佈建輸送量的佈建受控使用率。
Machine Learning - 效能效益
如果您部署到 Machine Learning 線上端點：
請遵循有關如何自動縮放線上端點的指南。 這樣做可以與需求保持密切一致，而不會超額佈建，尤其是在低使用率時期。
為線上端點選擇適當的虛擬機器 SKU，以滿足您的效能目標。 測試較少執行個體數和較大 SKU 與較大執行個體數和較小 SKU 的效能，以找到最佳設定。
部署此案例
若要部署和執行參考實作，請依照「OpenAI 端對端基準參考實作」中的步驟操作。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
- Rob Bagby | 模式 & 做法 - Microsoft
- Freddy Ayala | 雲端解決方案架構師 - Microsoft
- Prabal Deb | 資深軟體工程師 - Microsoft
- Raouf Aliouat | 軟體工程師 II - Microsoft
- Ritesh Modi | 軟體工程師主任 - Microsoft
- Ryan Pfalz | 資深解決方案架構師 - Microsoft
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。