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