企業聊天應用程式可以透過交談互動來賦予員工權力。 這尤其如此，因為語言模型的不斷進步，例如 OpenAI 的 GPT 模型和 Meta 的 LLaMA 模型。 這些聊天應用程式包含聊天使用者介面 （UI）、數據存放庫，其中包含與使用者查詢相關的網域特定資訊、導致網域特定數據產生相關響應的語言模型，以及監督這些元件之間互動的協調器。
本文提供基準架構，可用來建置及部署使用 Azure OpenAI 服務語言模型的企業聊天應用程式。 此架構會採用 Azure 機器學習 提示流程來建立可執行流程。 這些可執行流程會協調工作流程，從傳入提示到數據存放區，以擷取語言模型的地面數據，以及其他必要的 Python 邏輯。 可執行流程會部署至受控在線端點後方的 機器學習 計算叢集。
自定義聊天使用者介面 （UI） 的裝載遵循基準應用程式服務 Web 應用程式指引，以在 Azure App 服務 上部署安全、區域備援和高可用性的 Web 應用程式。 在該架構中，App Service 會透過透過私人端點的虛擬網路整合，與 Azure 平臺即服務 （PaaS） 解決方案通訊。 聊天UI App Service會透過私人端點與受控在線端點進行通訊。 已停用 機器學習 工作區的公用存取權。
重要
本文不會討論基準 App Service Web 應用程式的元件或架構決策。 如需如何裝載聊天 UI 的架構指引，請閱讀該文章。
機器學習 工作區已設定受控虛擬網路隔離，需要核准所有輸出連線。 使用此組態，會建立受控虛擬網路，以及能夠連線到私人資源的受控私人端點，例如工作場所 Azure 儲存體、Azure Container Registry 和 Azure OpenAI。 這些私人聯機會在流程撰寫和測試期間使用，以及部署至 機器學習 計算的流程。
提示
本文受到 參考實 作的支援，可展示 Azure 上的基準端對端聊天實作。 您可以在生產環境的第一個步驟中，使用此實作作為自定義解決方案開發的基礎。
架構
元件
此架構的許多元件都與基準 App Service Web 應用程式架構中的資源相同，因為您用來裝載聊天 UI 的方法在這兩個架構中都相同。 本節中醒目提示的元件著重於用來建置及協調聊天流程、數據服務和公開語言模型之服務的元件。
機器學習 是受控雲端服務，可用來定型、部署和管理機器學習模型。 此架構會使用數個其他 機器學習 功能，這些功能可用來開發及部署由語言模型支援的 AI 應用程式可執行流程：
Container Registry 可讓您針對所有類型的容器部署，在私人登錄中建置、儲存及管理容器映像和成品。 在此架構中，流程會封裝為容器映像，並儲存在 Container Registry 中。
Azure OpenAI 是完全受控的服務，可讓 REST API 存取 Azure OpenAI 的語言模型，包括 GPT-4、GPT-3.5-Turbo 和內嵌模型集。 在此架構中，除了模型存取之外，還用來新增常見的企業功能，例如 虛擬網路和私人連結、 受控識別 支援，以及內容篩選。
Azure AI 搜尋服務是雲端搜尋服務，可支援全文搜索、語意搜尋、向量搜尋和混合式搜尋。 AI 搜尋包含在架構中，因為它是聊天應用程式後置流程中使用的一般服務。 AI 搜尋可用來擷取和編製使用者查詢相關數據的索引。 提示流程會實作RAG 擷取增強式產生 模式，以從提示擷取適當的查詢、查詢 AI 搜尋，並使用結果作為 Azure OpenAI 模型的基礎數據。
機器學習 提示流程
企業聊天應用程式的後端通常會遵循類似下列流程的模式：
- 使用者會在自定義聊天使用者介面 （UI） 中輸入提示。
- 介面程式代碼會將該提示傳送至後端。
- 使用者意圖，無論是問題或指示詞，都是從後端的提示中擷取。
- 選擇性地，後端會決定保存與使用者提示相關的數據存放區
- 後端會查詢相關的數據存放區。
- 後端會將意圖、相關的基礎數據，以及提示中提供的任何歷程記錄傳送給語言模型。
- 後端會傳回結果，使其可在UI上顯示。
後端可以任意數目的語言實作，並部署到各種 Azure 服務。 此架構會使用 機器學習 提示流程，因為它提供簡化的體驗，以建置、測試及部署流程，以協調提示、後端數據存放區和語言模型。
提示流程運行時間
機器學習 可以直接裝載兩種類型的提示流程運行時間。
自動運行時間：無伺服器計算選項，可管理計算的生命週期和效能特性，並允許環境的流程驅動自定義。
計算實例運行時間：工作負載小組必須選取效能特性的 Always-On 計算選項。 此運行時間提供更多環境的自定義和控制。
提示流程也可以裝載在外部，以 機器學習 主機容器主機平臺上的計算。 此架構會使用App Service來示範外部裝載。
網路
除了身分識別型存取之外，網路安全性是使用 OpenAI 的基準端對端聊天架構的核心。 從高階而言，網路架構可確保：
- 只有聊天UI流量的單一安全進入點。
- 已篩選網路流量。
- 傳輸中的數據會以傳輸層安全性 （TLS） 加密端對端。
- 使用 Private Link 來保留 Azure 中的流量，可將數據外洩降至最低。
- 網路資源會透過網路分割，以邏輯方式分組並彼此隔離。
網路流程
此圖表中的兩個流程涵蓋在 基準 App Service Web 應用程式架構中：從終端使用者到聊天 UI 的輸入流程（1），以及從 App Service 到 Azure PaaS 服務的 流程（2）。 本節著重於在線端點流程 機器學習。 下列流程會從在基準 App Service Web 應用程式中執行的聊天 UI，到部署至 機器學習 計算的流程：
- App Service 裝載聊天 UI 的呼叫會透過私人端點路由傳送至 機器學習 在線端點。
- 在線端點會將呼叫路由傳送至執行已部署流程的伺服器。 在線端點可做為負載平衡器和路由器。
- 對已部署流程所需的 Azure PaaS 服務呼叫會透過受控私人端點路由傳送。
輸入至 機器學習
在此架構中，會停用 機器學習 工作區的公用存取權。 用戶可以透過私人存取來存取工作區，因為架構遵循 機器學習 工作區設定的私人端點。 事實上，此架構中會使用私人端點來補充身分識別型安全性。 例如，App Service 裝載的聊天 UI 可以連線到未公開至公用因特網的 PaaS 服務，包括 機器學習 端點。
若要連線到流程撰寫的 機器學習 工作區，也需要私人端點存取權。
此圖顯示透過 Azure Bastion 連線到虛擬機跳躍方塊的提示流程作者。 從該跳躍方塊中，作者可以透過與跳躍方塊相同的網路中的私人端點連線到 機器學習 工作區。 虛擬網路的 連線 性也可以透過 ExpressRoute 或 VPN 閘道和虛擬網路對等互連來完成。
從 機器學習 受控虛擬網路流向 Azure PaaS 服務
建議您針對需要核准所有輸出連線的受控虛擬網路隔離設定 機器學習 工作區。 此架構遵循該建議。 核准的輸出規則有兩種類型。 必要的輸出規則是解決方案運作所需的資源，例如 Container Registry 和 儲存體。 使用者定義的輸出規則 是您的工作流程將使用的自定義資源，例如 Azure OpenAI 或 AI 搜尋。 您必須設定使用者定義的輸出規則。 建立受控虛擬網路時，會設定必要的輸出規則。
輸出規則可以是外部公用端點的私人端點、服務標籤或完整功能變數名稱（FQDN）。 在此架構中，容器登錄、儲存體、Azure 金鑰保存庫、Azure OpenAI 和 AI 搜尋等 Azure 服務的聯機會透過私人連結連線。 雖然不是在此架構中，但可能需要設定 FQDN 輸出規則的一些常見作業是下載 pip 套件、複製 GitHub 存放庫，或從外部存放庫下載基底容器映像。
虛擬網路分割和安全性
此架構中的網路有個別的子網，其用途如下：
- 應用程式閘道
- App Service 整合元件
- 私人端點
- Azure Bastion
- 跳板箱虛擬機
- 定型 - 不適用於此架構中的模型定型
- 評分
每個子網都有一個網路安全組 （NSG），其會將這些子網的輸入和輸出流量限制為所需的流量。 下表顯示基準新增至每個子網之 NSG 規則的簡化檢視。 數據表提供規則名稱和函式。
| 子網路 | 傳入 | 輸出 |
|---|---|---|
| snet-appGateway | 我們的聊天UI使用者來源IP（例如公用因特網）以及服務所需的專案津貼。 | 存取 App Service 私人端點，以及服務的必要專案。 |
| snet-PrivateEndpoints | 只允許來自虛擬網路的流量。 | 只允許虛擬網路的流量。 |
| snet-AppService | 只允許來自虛擬網路的流量。 | 允許存取私人端點和 Azure 監視器。 |
| AzureBastionSubnet | 請參閱使用 NSG 存取和 Azure Bastion 的指引。 | 請參閱使用 NSG 存取和 Azure Bastion 的指引。 |
| snet-jumpbox | 允許來自 Azure Bastion 主機子網的輸入 RDP 和 SSH。 | 允許存取私人端點 |
| snet-agents | 只允許來自虛擬網路的流量。 | 只允許虛擬網路的流量。 |
| snet-training | 只允許來自虛擬網路的流量。 | 只允許虛擬網路的流量。 |
| snet-scoring | 只允許來自虛擬網路的流量。 | 只允許虛擬網路的流量。 |
所有其他流量都會明確拒絕。
實作虛擬網路分割和安全性時，請考慮下列幾點。
針對具有公用IP位址的應用程式閘道一部分子網的虛擬網路啟用 DDoS 保護 。
盡可能將 NSG 新增至每個子網。 使用啟用完整解決方案功能的最嚴格規則。
使用 應用程式安全組 將 NSG 分組。 群組 NSG 可讓複雜環境更容易建立規則。
內容篩選和濫用監視
Azure OpenAI 包含 內容篩選系統 ，其使用分類模型的合奏來偵測和防止輸入提示和輸出完成中潛在有害內容的特定類別。 這種潛在有害內容的類別包括仇恨、性、自我傷害、暴力、褻瀆和越獄（旨在略過語言模型限制的內容）。 您可以設定您想要篩選每個類別內容的嚴格性，選項為低、中或高。 此參考架構採用嚴格的方法。 根據您的需求調整設定。
除了內容篩選之外，Azure OpenAI 也會實作濫用監視功能。 濫用監視是一種異步操作，旨在偵測和減輕週期性內容或行為的實例，以可能違反 Azure OpenAI 規範的方式建議使用服務。 如果您的數據高度敏感，或有內部原則或適用的法律法規防止處理濫用偵測的數據，您可以要求 豁免濫用監視和人工檢閱 。
可靠性
基準 App Service Web 應用程式 架構著重於主要區域服務的區域性備援。 可用性區域是區域內實際不同的位置。 當兩個以上的實例部署在兩個以上的實例時，它們會在區域中提供支援服務的備援。 當某個區域發生停機時，區域內的其他區域可能仍然不受影響。 此架構也可確保足夠的 Azure 服務實例，以及這些服務的設定，以分散到可用性區域。 如需詳細資訊，請參閱檢閱該指引的 基準 。
本節從 App Service 基準中未解決的元件的觀點來看，解決可靠性，包括 機器學習、Azure OpenAI 和 AI 搜尋。
流程部署的區域性備援
企業部署通常需要區域性備援。 若要在 Azure 中實現區域性備援，資源必須支援 可用性區域 ，而且您必須部署至少三個資源實例，或在實例控制無法使用時啟用平台支援。 目前，機器學習 計算不支援可用性區域。 若要減輕資料中心層級災難對 機器學習元件的潛在影響，您必須在各種區域中建立叢集，以及部署負載平衡器，以分散這些叢集之間的呼叫。 您可以使用健康情況檢查，協助確保呼叫只會路由傳送至正常運作的叢集。
部署提示流程不限於 機器學習 計算叢集。 可執行流程是容器化應用程式，可以部署到任何與容器相容的 Azure 服務。 這些選項包括 Azure Kubernetes Service （AKS）、Azure Functions、Azure Container Apps 和 App Service 等服務。 每個服務都支援可用性區域。 若要達到提示流程執行的區域性備援，而不需要多區域部署的複雜度，您應該將流程部署到其中一個服務。
下圖顯示將提示流程部署至 App Service 的替代架構。 App Service 會用於此架構，因為工作負載已將其用於聊天 UI，而且無法受益於將新技術引入工作負載。 具備 AKS 經驗的工作負載小組應考慮在該環境中部署，特別是當 AKS 用於工作負載中的其他元件時。
此圖表編號為此架構中值得注意的區域：
流程仍會以 機器學習 提示流程撰寫，且 機器學習 網路架構不會變更。 流程作者仍會透過私人端點連線到工作區撰寫體驗，而受控私人端點則用來在測試流程時連線到 Azure 服務。
這個虛線表示容器化的可執行流程會推送至 Container Registry。 圖表中未顯示容器化流程並推送至 Container Registry 的管線。
還有另一個 Web 應用程式已部署到已裝載聊天 UI 的相同 App Service 方案。 新的 Web 應用程式裝載容器化提示流程，共置在已至少執行三個實例的相同 App Service 方案上，分散於可用性區域。 載入提示流程容器映像時，這些 App Service 實例會透過私人端點連線到 Container Registry。
提示流程容器必須連線到所有相依服務，才能執行流程。 在此架構中，提示流程容器會連線到 AI 搜尋和 Azure OpenAI。 只有公開至 機器學習 受控私人端點子網的 PaaS 服務現在也需要在虛擬網路中公開，以便從 App Service 建立視線。
Azure OpenAI - 可靠性
Azure OpenAI 目前不支援可用性區域。 若要減輕數據中心層級災難對 Azure OpenAI 中模型部署的潛在影響，您必須將 Azure OpenAI 部署到各種區域，以及部署負載平衡器，以在區域之間散發呼叫。 您可以使用健康情況檢查，協助確保呼叫只會路由傳送至正常運作的叢集。
若要有效地支援多個實例，建議您將微調檔案外部化，例如異地備援 儲存體 帳戶。 此方法會將每個區域儲存在 Azure OpenAI 中的狀態降到最低。 您仍然必須微調每個實例的檔案，才能裝載模型部署。
請務必監視每分鐘令牌所需的輸送量（TPM）和每分鐘的要求（RPM）。 請確定從配額指派足夠的 TPM u 以符合部署的需求，並防止對已部署模型的呼叫進行節流。 Azure API 管理 之類的閘道可以在 OpenAI 服務或服務前面部署，而且可以在發生暫時性錯誤和節流時設定重試。 API 管理 也可以當做斷路器使用，以防止服務因呼叫而不知所措，超過其配額。
AI 搜尋 - 可靠性
在支援可用性區域的區域中，使用標準定價層或更高層級部署 AI 搜尋，並部署三個或多個複本。 複本會自動分散到可用性區域。
請考慮下列指引，以判斷適當的複本和分割區數目：
使用監視計量和記錄和效能分析來判斷適當的複本數目，以避免以查詢為基礎的節流和數據分割，以及避免以索引為基礎的節流。
機器學習 - 可靠性
如果您部署至 機器學習 受控在線端點後方的計算叢集，請考慮下列有關調整的指引：
自動調整您的在線端點 ，以確保有足夠的容量可符合需求。 如果使用量訊號因高載使用量而不夠及時，請考慮過度布建以防止對可靠性造成太大影響，而無法使用實例。
請考慮根據 部署計量建立調整規則， 例如 CPU 負載和 端點計量 ，例如要求延遲。
不應針對作用中的生產環境部署部署部署少於三個實例。
避免針對使用中的實例進行部署。 而是部署至新的部署，並在部署準備好接收流量之後移轉流量。
注意
如果您將流程部署至 App Service，就會套用基準架構中的相同 App Service 延展性指引 。
安全性
此架構會同時實作網路和身分識別安全性周邊。 從網路的觀點來看，唯一應該從因特網存取的是透過 應用程式閘道 的聊天 UI。 從身分識別的觀點來看，聊天 UI 應該驗證和授權要求。 在可能的情況下，會使用受控識別向 Azure 服務驗證應用程式。
本節說明密鑰輪替的身分識別與存取管理和安全性考慮，以及 Azure OpenAI 模型微調。
身分識別和存取管理
下列指引會 擴充 App Service 基準中的身分識別和存取管理指導方針：
- 在適用的情況下，為下列 機器學習 資源建立個別的受控識別：
- 流程撰寫和管理的工作區
- 測試流程的計算實例
- 如果流程部署至受控在線端點，則部署流程中的在線端點
- 使用 Microsoft Entra ID 實作聊天 UI 的身分識別訪問控制
機器學習 角色型存取角色
有五個預設角色可用來管理 機器學習 工作區的存取權：AzureML 資料科學家、AzureML 計算操作員、讀者、參與者和擁有者。 除了這些預設角色之外，還有 AzureML Learning 工作區 連線 秘密讀取器和 AzureML 登錄使用者，可授與工作區資源的存取權，例如工作區秘密和登錄。
此架構會遵循最低許可權原則，只要將角色指派給所需的先前身分識別。 請考慮下列角色指派。
| 受控識別 | 範圍 | 角色指派 |
|---|---|---|
| 工作區的受控識別 | 資源群組 | 參與者 |
| 工作區的受控識別 | 工作區 儲存體 帳戶 | 儲存體 Blob 資料參與者 |
| 工作區的受控識別 | 工作區 儲存體 帳戶 | 儲存體檔案資料特殊權限參與者 |
| 工作區的受控識別 | 工作區 金鑰保存庫 | Key Vault 系統管理員 |
| 工作區的受控識別 | 工作區容器登錄 | AcrPush |
| 在線端點受控識別 | 工作區容器登錄 | AcrPull |
| 在線端點受控識別 | 工作區 儲存體 帳戶 | 儲存體 Blob 資料讀者 |
| 在線端點受控識別 | Machine Learning 工作區 | AzureML 工作區 連線 秘密讀取器 |
| 計算實例受控識別 | 工作區容器登錄 | AcrPull |
| 計算實例受控識別 | 工作區 儲存體 帳戶 | 儲存體 Blob 資料讀者 |
金鑰輪替
此架構中有兩個服務使用密鑰型驗證：Azure OpenAI 和 機器學習 受控在線端點。 因為您針對這些服務使用金鑰型驗證，所以請務必：
將密鑰儲存在安全存放區中，例如 金鑰保存庫，以便從授權客戶端進行隨選取，例如裝載提示流程容器的 Azure Web 應用程式。
實作金鑰輪替策略。 如果您手動輪替密鑰，請建立金鑰到期原則，並使用 Azure 原則 來監視密鑰是否已輪替。
OpenAI 模型微調
如果您在實作中微調 OpenAI 模型，請考慮下列指引：
如果您上傳定型數據以進行微調，請考慮使用 客戶管理的密鑰 來加密該數據。
如果您在 Azure Blob 儲存體 等存放區中儲存定型數據，請考慮使用客戶管理的密鑰進行數據加密、控制數據的存取權的受控識別，以及連線到數據的私人端點。
透過原則控管
為了協助確保與安全性一致，請考慮使用 Azure 原則 和網路原則，讓部署符合工作負載的需求。 透過原則使用平臺自動化可降低手動驗證步驟的負擔，並確保即使略過管線，也能確保治理。 請考慮下列安全策略：
- 停用 Azure AI 服務和 金鑰保存庫 等服務中的金鑰或其他本機驗證存取。
- 需要網路存取規則或 NSG 的特定設定。
- 需要加密，例如使用客戶管理的密鑰。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。
若要查看此案例的定價範例，請使用 Azure 定價計算機。 您需要自定義範例以符合您的使用量，因為此範例只包含架構中包含的元件。 案例中最昂貴的元件是聊天UI和提示流程計算和 AI 搜尋。 將這些資源優化，以節省最多成本。
計算
機器學習 提示流程支援多個選項來裝載可執行流程。 這些選項包括 機器學習、AKS、App Service 和 Azure Container Service 中的受控在線端點。 每個選項都有自己的計費模型。 計算的選擇會影響解決方案的整體成本。
Azure OpenAI
Azure OpenAI 是以耗用量為基礎的服務，與任何以使用量為基礎的服務一樣，控制對供應的需求是主要成本控制。 若要在 Azure OpenAI 中特別這樣做，您必須使用方法的組合：
控制用戶端。 用戶端要求是取用模型中成本的主要來源，因此控制客戶端行為非常重要。 所有客戶端都應該：
獲得核准。 請避免以支援完全免費存取的方式公開服務。 透過網路和身分識別控制來限制存取，例如密鑰或角色型訪問控制（RBAC）。
自我控制。 要求用戶端使用 API 呼叫所提供的令牌限制條件約束，例如max_tokens和max_completions。
使用批處理，其中實用。 檢閱用戶端，以確保其適當地批處理提示。
優化提示輸入和回應長度。 較長的提示會耗用更多令牌、提高成本，但缺少足夠內容的提示並無法協助模型產生良好的結果。 建立簡潔的提示，以提供足夠的內容，讓模型產生有用的回應。 同樣地，請確定您已將回應長度的限制優化。
Azure OpenAI 遊樂場 使用方式應該視需要和生產前實例，讓這些活動不會產生生產成本。
選取正確的 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 監視器基準警示中找到的資源。 例如：
語言模型作業
使用 Azure DevOps 和 GitHub 的提示流程，部署 Azure OpenAI 型聊天解決方案應該遵循 LLMOps 中的指引。 此外，它必須考慮持續整合和持續傳遞 （CI/CD） 和網路保護架構的最佳做法。 下列指引會根據 LLMOps 建議，解決 Flow 及其相關聯基礎結構的實作。 此部署指引不包含前端應用程式元素，這些元素與基準高可用性區域備援 Web 應用程式架構中的不同。
部署
機器學習 提示流程在 機器學習 Studio 或透過 Visual Studio Code 擴充功能提供瀏覽器型撰寫體驗。 這兩個選項都會將流程代碼儲存為檔案。 當您使用 機器學習 Studio 時，檔案會儲存在 儲存體 帳戶中。 當您在 VS Code 中工作時，檔案會儲存在本機文件系統中。
為了遵循 共同開發的最佳作法，來源檔案應該保留在在線原始程式碼存放庫中，例如 GitHub。 此方法有助於追蹤所有程式代碼變更、流程作者之間的共同作業，以及與 測試及驗證所有程式代碼變更的部署流程 整合。
針對企業開發，請使用 VS Code 擴充 功能和 提示流程 SDK/CLI 進行開發。 提示流程作者可以從 VS Code 建置及測試其流程，並將本機儲存的檔案與在線原始檔控制系統和管線整合。 雖然瀏覽器型體驗非常適合探索式開發，但有些工作可以與原始檔控制系統整合。 您可以從面板中的流程頁面 Files 下載流程資料夾、解壓縮並推送至原始檔控制系統。
評估
測試聊天應用程式中所使用的流程，就像測試其他軟體成品一樣。 指定和判斷語言模型輸出的單一「正確」答案是一項挑戰，但您可以使用語言模型本身來評估回應。 請考慮實作下列語言模型流程的自動化評估：
分類精確度：評估語言模型是否提供「正確」或「不正確」分數，並匯總結果以產生精確度等級。
一致性：評估模型的預測答案中句子的撰寫程度，以及它們如何一致地彼此連接。
流暢度：評估模型的預測答案，以取得其文法和語言精確度。
根據內容的基礎性：評估模型的預測答案根據預先設定的內容有多好。 即使語言模型回應正確，如果無法針對指定的內容進行驗證，則這類回應不會停工。
相關性：評估模型的預測答案與所詢問的問題一致程度。
實作自動化評估時，請考慮下列指引：
從評估產生分數，並根據預先定義的成功閾值來測量分數。 使用這些分數來報告管線中的測試通過/失敗。
其中一些測試需要預先設定的問題、內容和基礎真相的數據輸入。
包含足夠的問答組，以確保測試結果可靠，建議至少 100-150 組。 這些問答組稱為「黃金數據集」。視數據集的大小和網域而定，可能需要較大的母體擴展。
避免使用語言模型在黃金數據集中產生任何數據。
部署流程
提示工程師/數據科學家會開啟功能分支，讓他們處理特定工作或功能。 提示工程師/數據科學家會使用 VS Code 的提示流程來反覆運算流程，定期認可變更，並將這些變更推送至功能分支。
完成本機開發和實驗之後，提示工程師/數據科學家會將功能分支的提取要求開啟至Main分支。 提取要求 （PR） 會觸發PR管線。 此管線會執行快速品質檢查，其中包括：
- 執行實驗流程
- 執行已設定的單元測試
- 程序代碼基底的編譯
- 靜態程式代碼分析
管線可以包含一個步驟，要求至少一個小組成員在合併之前手動核准 PR。 核准者不能是認可者，而且他們擁有提示流程專業知識和熟悉專案需求。 如果未核准PR，則會封鎖合併。 如果 PR 已核准，或沒有核准步驟，功能分支就會合併至 Main 分支。
合併至Main會觸發開發環境的建置和發行程式。 具體而言：
a. CI 管線會從合併觸發至Main。 CI 管線會執行 PR 管線中完成的所有步驟，以及下列步驟：
- 實驗流程
- 評估流程
- 偵測到變更時，在 機器學習 登錄中註冊流程
b. CD 管線會在 CI 管線完成之後觸發。 此流程會執行下列步驟：
- 將流程從 機器學習 登錄部署到 機器學習 在線端點
- 執行以在線端點為目標的整合測試
- 執行以在線端點為目標的煙霧測試
核准程式內建於發行升級程式 – 經過核准時，步驟 4.a 中所述的 CI 和 CD 程式。 和 4.b. 是重複的，以測試環境為目標。 步驟 a. 和 b. 相同，不同之處在於使用者驗收測試是在測試環境中的煙霧測試之後執行。
步驟 4.a 中所述的 CI 和 CD 程式。 & 4.b. 會在測試環境經過驗證並核准之後，將發行升級至生產環境。
發行至即時環境之後，就會執行監視效能計量和評估已部署語言模型的作業工作。 這包括，但不限於：
- 偵測數據漂移
- 觀察基礎結構
- 管理成本
- 將模型的效能傳達給項目關係人
部署指引
您可以使用 機器學習 端點，以在發行至生產環境時提供彈性的方式部署模型。 請考慮下列策略，以確保最佳的模型效能和品質：
藍/綠部署：使用此策略，您可以在將所有流量導向至新的部署之前，安全地將新版本的 Web 服務部署到有限的使用者或要求群組。
A/B 測試：不僅藍/綠部署對於安全地推出變更有效，還可以用來部署新的行為，讓使用者子集評估變更的影響。
包含管線中提示流程一部分的 Python 檔案 Linting。 Linting 會檢查樣式標準、錯誤、程式代碼複雜度、未使用的匯入和變數命名的合規性。
當您將流程部署至網路隔離 機器學習 工作區時，請使用自我裝載代理程式將成品部署至 Azure 資源。
只有在模型有變更時，才應該更新 機器學習 模型登錄。
語言模型、流程和用戶端UI應該鬆散結合。 更新 流程和用戶端UI可以而且應該能夠進行，而不會影響模型，反之亦然。
當您開發和部署多個流程時，每個流程都應該有自己的生命週期，這可讓您在將流程從實驗升級為生產環境時，有鬆散結合的體驗。
基礎結構
當您部署基準 Azure OpenAI 端對端聊天元件時，布建的一些服務在架構中是基本且永久的，而其他元件本質上則比較暫時，它們的存在會系結至部署。
基礎元件
此架構中的某些元件存在生命週期，其延伸超過任何個別的提示流程或任何模型部署。 這些資源通常會在工作負載小組作為基礎部署的一部分進行一次部署，並且除了提示流程或模型部署的新、移除或更新之外，也一樣維護。
- Machine Learning 工作區
- 機器學習 工作區 儲存體 帳戶
- Container Registry
- AI 搜尋
- Azure OpenAI
- Azure Application Insights
- Azure Bastion
- 跳躍方塊的 Azure 虛擬機
暫時元件
某些 Azure 資源會與特定提示流程的設計緊密結合。 此方法可讓這些資源系結至元件的生命週期，並在此架構中變成暫時性。 當工作負載發展時，Azure 資源會受到影響，例如新增或移除流程或引進新的模型時。 這些資源會重新建立，並移除先前的實例。 其中有些資源是直接的 Azure 資源，有些是其內含服務中的數據平面表現。
機器學習 模型登錄中的模型應該在CD管線中變更時加以更新。
容器映像應該在容器登錄中更新為CD管線的一部分。
如果部署參考不存在的端點，則會在部署提示流程時建立 機器學習 端點。 必須更新該端點，才能 關閉公用存取。
部署或刪除流程時，會更新 機器學習 端點的部署。
建立新端點時，用戶端UI的 金鑰保存庫必須使用端點的密鑰更新。
效能效益
效能效率是工作負載能夠有效率地調整，以符合使用者對它的需求。 如需詳細資訊，請參閱 效能效率的設計檢閱檢查清單。
本節說明 Azure 搜尋服務、Azure OpenAI 和 機器學習 的觀點的效能效率。
Azure 搜尋服務 - 效能效率
請遵循指引來 分析 AI 搜尋中的效能。
Azure OpenAI - 效能效率
判斷您的應用程式是否需要 布建的輸送量 或共用裝載，或耗用量、模型。 布建的輸送量可確保 OpenAI 模型部署的保留處理容量，為您的模型提供可預測的效能和輸送量。 此計費模型與共用裝載或耗用量模型不同。 耗用量模型是最佳努力，而且可能會受到平臺上嘈雜的鄰近或其他壓力因素的影響。
監視 布建管理的輸送量使用率 。
機器學習 - 效能效率
如果您部署至 機器學習 線上端點：
請遵循如何 自動調整在線端點的指引。 這樣做可以保持與需求緊密配合，而不過度過度布建，特別是在低使用量期間。
為在線端點選擇適當的虛擬機 SKU，以符合您的效能目標。 測試較低實例計數和較大 SKU 的效能，以及較大的實例計數和較小的 SKU，以找出最佳的組態。
部署此案例
若要部署和執行參考實作，請遵循 OpenAI 端對端基準參考實作中的步驟。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
- Rob Bagby |模式和實務 - Microsoft
- Freddy Ayala |雲端解決方案架構師 - Microsoft
- Prabal Deb |資深軟體工程師 - Microsoft
- Raouf Aliouat |軟體工程師 II - Microsoft
- Ritesh Modi |首席軟體工程師 - Microsoft
- 里安·普法爾茨 |資深解決方案架構師 - Microsoft
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。