在 Azure 上測試及評估 AI 工作負載
在 AI 工作負載中測試的目的是在系統導入變更時，協助確保品質。 測試可以驗證工作負載是否符合已識別的目標，並滿足使用者的期望。 它也會防止質量回歸。 此程式包括跨各種功能區域執行測試，並根據工作負載需求評估功能、負載處理、可預測性和其他準則的品質。
測試結果會提供重要的 數據點，以做出決策， 例如 AI 元件是否已準備好發行，以及哪些 SKU 或功能適用。 此外，測試可作為 失敗 的通知系統，並透過例行或綜合測試協助偵測生產環境中的問題。
Azure 架構完善的架構概述完整的測試方法。 您應該 在開發生命週期的不同階段，以及跨不同系統元件和流程使用不同的測試類型。 如果沒有這些測試，推出的變更可能會降低系統品質。 例如，次要程式代碼錯誤可能會變成大型系統失敗。 系統行為可能會因為 AI 系統的不具決定性本質而變得無法預測或產生偏差的結果。 此外，資源配置可能效率不佳，而實際的用戶數據或系統資源可能會遭到利用，因為這些系統容易受到濫用。
您必須 以測試為考慮來設計和開發工作負載資產。 例如，當您針對特徵工程執行數據操作和重塑源數據時，請遵循良好的編碼作法，並確保建構程式代碼以支持測試。 此策略包括設計程式代碼，以協助有效的單元測試，並將測試與程序代碼的功能及其相依性隔離。 在此範例中，您必須設計可在測試環境中執行的系統，該系統在數量和相似度方面具有足夠代表性的測試數據。
您必須安全地將工作負載元件部署到生產環境。 任何工作負載的安全部署作法的一部分是策略性測試，以協助確保使用者或數據取用系統之前的正確行為。 策略性測試在初始部署期間很重要，而且隨著系統演進並經歷程式代碼或基礎結構變更。 先測試 AI 相關程式代碼和基礎結構的所有建議變更，再將變更部署至生產環境。
本文著重於將該方法套用至架構的 AI 層面。 如何進行這些測試不在範圍內。
建議
以下是本文所提供的建議摘要。
| 建議 | 描述 |
|---|---|
| 定義測試策略的成功計量。 | 如同任何其他類型的工作負載測試，您需要擷取和分析給定測試的適當計量，以確保您的測試提供有關 AI 工作負載的實用見解。 ▪ 定義成功計量 |
| 在整個開發生命週期中，對數據擷取和處理管線進行端對端測試。 | 測試可以驗證數據，並協助您確保數據操作程式如預期般運作。 在設計階段早期納入測試，以確保數據品質與適當的技術和大小調整選擇。 在開發期間開發自定義程式碼的單元測試，並執行即時生產測試來攔截問題和驗證功能。 ▪ 測試數據擷取 |
| 執行定型作業的測試，以確定會叫用腳本，並如預期般運作。 | 負載和效能測試可讓您深入瞭解適合執行作業的計算選擇和大小調整。 單元測試可以驗證程式代碼的公用程式，並在更新相依性時攔截回歸。 ▪ 測試定型工作流程 |
| 評估及測試模型，以避免在定型、評估和測試數據中重複。 | 若要確保源數據不會完全用於定型，您必須保留唯一的數據以供模型評估和最終測試使用。 這些子集不會包含在實際的定型程式中。 ▪ 評估及測試模型 |
| 測試推斷端點。 | 在推斷伺服器所裝載的端點上執行負載測試，並根據這些測試結果選擇 GPU SKU。 針對平臺即服務 （PaaS）裝載的端點，請測試輸送量和潛在的失敗。 這些端點是可連線的，因此請進行適當的安全性測試，以防止發生越獄的情況。 ▪ 測試推斷端點 |
| 測試索引設計的正確性，讓查詢產生相關的結果。 | 功能與整合測試可協助您確保數據正確無誤，以及索引架構測試會檢查回溯相容性。 您必須測試品質的前置處理步驟。 負載測試會決定適當的資源 SKU，以及安全性控制可保護數據機密性。 ▪ 測試地面數據 |
| 測試協調器，以驗證其功能和安全性。 | 進行單元、功能、整合和運行時間測試，包括負載和失敗模式測試，以確保效能和可靠性。 安全性與內容安全性測試對於保護系統和數據也至關重要。 ▪ 測試協調器 |
| 測試模型衰變。 | 模型衰變是影響大部分 AI 工作負載的必然問題。 測試數據和概念漂移可協助您儘早捕捉模型衰變，並在對工作負載造成負面影響之前先解決問題。 ▪ 防止模型衰變 |
定義成功計量
我們建議您有基準，並使用定義完善的計量來測量模型的預測能力。 以下是一些常見的計量。
精確度 代表正確預測實例與測試數據集中實例總數的比例。 這是整體模型效能的常見量值。
精確度 是真肯定預測與真真和誤判總和的比率。 例如，在將誤判降至最低很重要時，例如在醫學診斷中。
敏感度 會測量真真與真真和誤判總和的比率。 避免誤判或遺漏相關案例非常重要。
具體性 會計算真負數與真負數和誤判的總和。 當您針對精確的負面預測進行優化時，這很相關。
注意
當您定義回歸模型的成功計量時，請考慮新增下列計量：
平均絕對誤差 （MAE） 測量預測值與實際值之間的平均絕對差異。 藉由取得每個實際值與其對應預測值之間的絕對差異平均值來計算。 相較於 MSE 和 RMSE，MAE 對極端值較不敏感。
平均平方誤差 （MSE） 測量實際值與預測值之間的平均平方差異。 藉由取得每個實際值與其對應預測值之間的平方差異平均值來計算它。 MSE 會比MAE更嚴重地懲罰較大的錯誤，因為錯誤是平方的。
根均平方誤差 （RMSE） 是 MSE 的平方根。 它提供實際值與預測值之間平均絕對誤差的量值，但與原始數據單位相同。 相較於MAE，RMSE 對極端值比較敏感，因為它會在平均之前將錯誤平方。
測試數據擷取
數據管線，例如擷取、轉換和載入 （ETL） 程式、移動及操作數據。 測試工作負載的 ETL 部分，以確定其能可靠地內嵌數據，且數據是高品質且可接受的分析與特徵工程。 請確定數據清理和處理包含測試，以確認數據操作如預期般運作。
測試應該在整個生命週期中整合，包括設計、開發和生產階段。
測試以利設計選擇
當您收集工作負載的需求時，關鍵決策步驟是選擇適合您設計的特定技術選項。
根據您的 ETL 需求和驗收準則，進行探勘功能測試，以選取最適合的產品、其 SKU，以及執行預定工作的功能。 概念證明、技術證明和功能證明測試對於評估您是否選擇正確的技術，以及其大小是否適當至關重要。
針對將 AI 納入現有架構的案例，請測試新技術如何與目前的系統整合。
初始工作負載需求可能會變更。 假設企業預期成長，而且系統必須處理一般用戶查詢的兩倍。 此預期需要適當的容量規劃。 我們建議主動測試，以了解系統如何回應額外的數據，並針對現有的重設大小或做出新產品選擇進行數據驅動調整。 針對容量測試，建議您結合功能測試與負載和效能測試，並使用合成來模擬實際狀況。
測試以確保程式代碼品質
包含程式代碼時，請確定它通過單元測試，如果失敗，就不會釋放。 例如，通常會有自定義程式碼在擷取時執行。 也有程式代碼用於數據清理和處理。 執行單元測試，以確保程式碼會根據其設計運作，且數據操作如預期般運作。
在持續整合和持續傳遞管線中執行測試。
在即時系統中進行測試
功能測試應延伸至實時系統。 如果這些測試失敗，請考慮視需要觸發警示來起始立即調查。 以下列出一些範例：
執行排程測試，以確認是否在具有預期數量之設定排程上內嵌數據時，已收集正確的數據量。
執行測試以偵測數據問題，例如遺漏值或重複數據，並執行基本數據完整性檢查。 如果數據包含指出其最新狀態的時態資訊，這些測試可以檢查該資訊，並可能防止下游進程使用過時的數據。
檢查外部相依性的可用性。 例如，數據清理作業可能會呼叫另一個服務來擷取數據表或前置處理。 執行測試以確保可用，因為它們無法使用可能會影響 ETL 程式。
另一個測試生產環境中 ETL 系統正確性的方法，是透過綜合測試。 生產環境中有已知的測試數據非常有效。 您可以使用它來驗證端對端處理，方法是比較已知起始狀態與該數據的預期結束狀態。 例如，需要檔才能進行文件情報，並包含個人資料。 插入綜合檔可以測試工作負載會如預期般執行數據操作作業。
此外，藉由釋放不同的體驗，也稱為 A/B 測試來實驗，以在完全認可之前先從用戶互動中學習。 A/B 測試可協助您防止質量回歸。
測試擷取期間收集的數據
作為各種數據源擷取程式的一部分，包括測試，以驗證定型數據是否符合您的預期。
使用不完整或損毀的數據來定型機器學習模型可能會適得其反。 這可能會導致浪費工作，並導致無法進行有意義的預測模型。 您的數據擷取和前置處理管線包含質量測試作為檢查點。 這些測試可協助您確認數據符合您在數據分析和特徵工程期間設定的期望。
下列清單包含一些範例測試案例：
測試完整性。 測試預期的定型數據數量，以確認數據集的完整性。 此測試可確保您提供足夠的數據來定型模型。
測試重要資訊。 如果定型是以已知的實體為基礎，例如特定記錄或標識符，請測試數據集以確定這些實體存在。 此驗證可確保不會遺漏重要資訊。
測試無關的數據。 擷取的數據不應該包含無關或錯誤的專案。 數據擷取程式應該篩選掉該數據。
測試新鮮度。 擷取數據的新鮮度不應影響模型的預測能力。 驗證數據會反映合理的目前資訊，而且不會過時於先前的執行。 例如，如果您預期數據會包含過去一周的記錄，但在匯入數據之後沒有這類記錄，這可能表示匯入失敗或來源系統中的數據新鮮度問題。
進行例行測試
數據擷取的重要考慮是數據量和輸送量。 在作業期間進行持續評估是防止效能瓶頸的必要條件。 此持續評估應該是作業程式的一部分，而不只是一次性測試。 目標是確保工作負載小組不會錯過其服務等級目標。
請考慮監視表示效能降低的情況。 若要減輕這類狀況，請重新評估並優化 ETL 程式。 進行變更之後，效能測試可協助您確定修改符合所需的輸送量。
注意
測試和監視有不同的用途。 執行測試以評估系統的潛在變更，通常是在您實作任何變更之前。 持續進行監視，以評估系統的整體健康情況。
測試定型工作流程
使用自定義程式代碼來定型模型，例如執行實際定型工作的 PyTorch 腳本。 這些腳本會在計算上執行，例如在筆記本或 Azure 機器學習 作業中，這些作業也需要記憶體和網路資源。 建議您在設計階段進行負載測試，以評估計算需求，並確保建議的SKU適合。 您通常需要手動測試，以判斷在時間限制內有效率地執行工作負載的最佳設定。
使用特製化 SDK 撰寫腳本，以處理大部分的工作。 不過，由於腳本仍然是程序代碼，因此您應該在開發時整合單元測試。 這些測試可協助您確保更新相依性時不會發生任何回歸。 如果不可能進行單元測試，則必須先進行手動測試，才能部署新的程序代碼，以防止質量回歸。
這些腳本會以工作流程的一部分執行，例如 Azure Machine Learning 工作室，可提供腳本執行時機和時間的深入解析。 但我們建議您執行整合測試，以確保這些腳本能可靠地叫用。
評估及測試模型
注意
模型評估和測試通常會交替使用，但應該視為使用不同數據集的個別程式。 評估是您在開發階段期間執行的反覆活動。 其著重於實驗，以尋找具有正確微調層級的最佳模型。 它包含調整超參數、組態或功能，然後根據各種計量評估模型。 識別出最佳模型之後，請在部署期間進行測試。
測試包括驗證整個系統，包括微調的模型和非 AI 元件，以檢查它們是否正常運作、妥善整合，以及根據品質標準提供預期的結果。 與工作負載的其他元件一起評估模型。 此程式包括將要求傳送至模型、評估其回應，以及根據測試數據做出去或無進決策。 雖然測試在生產環境之前是無法談判的，但建議您也使用實際數據和綜合數據在生產環境中執行測試。
使用數據來評估和測試
一般而言，源數據分割了三個主要數據集：定型、評估和測試。
使用定型數據集，通常是最大的子集，來定型模型。 使用另一個數據集進行評估，藉由評估不同的排列，透過反覆程式精簡模型。 找到令人滿意的排列之後，請針對測試數據集進行測試。
所有數據集都應該包含高質量的數據，以將雜訊降到最低。 數據擷取和前置處理管線的測試案例可作為質量檢查點。 缺乏樣本也可以歸因於低質量的數據。 使用綜合數據來平衡並達到數據集中的統一性。 這種方法對於詐騙偵測模型等定型模型很有用，其中真正的詐騙實例很少見，因此難以取得足夠的統計能力來進行可靠的預測。
若要避免預測中的偏差，請保留所有數據集的不同。 您不應該使用定型數據進行評估，也不應該使用評估數據進行測試。 保留模型評估和最終測試的唯一數據。
使用評估計量
將模型定型並選取適合生產環境的正確模型是相互依存的程式。 您一開始需要選擇模型，但在實驗和評估之後可能會變更。
模型評估會遵循作為實驗迴圈，使用計量來評估模型、參數和功能的許多排列。 這些計量提供科學評等，您必須反覆比較不同版本和組態，以判斷最佳模型。 如需詳細資訊，請參閱 評估計量。
類似的方法適用於產生式 AI 模型。 讓程式根據模型的效能評估及量化用戶體驗的結果。 例如，基礎性是可量化模型與源數據對齊程度的關鍵計量之一。 相關性是另一個重要計量，指出回應對查詢的相關性。 例如計量，請參閱 評估及監視產生 AI 的計量。
使用各種計量評估不同類型的模型。 每個計量的重要性可能會根據案例而有所不同。 根據使用案例排列計量的優先順序。 例如，在負責任的 AI 中，公平性至關重要。 儘管測試良好，但模型仍可能會因為有偏差的源數據而表現出不公平的偏差。 結果的相關性可能很高，但公平性較低。 將公平性評估整合到程式中，以確保不偏不倚的結果。
Generative AI 會與協調流程程式代碼、路由邏輯和索引整合，以擷取增強的產生 （RAG），這會使評估複雜。 雖然您應該使用計量個別評估模型，但評估其他系統元件也很重要。
測試模型
微調基本上是測試，因為它會修改預先定型的模型來變更其行為。 它需要從基準開始，才能瞭解模型的初始效能。 微調之後，重新評估模型的效能，以確保其符合質量標準。 請考慮下列常見的評估計量：
地面是指模型與源數據的對齊方式。 地面模型會產生與現實一致的答案。
相關性 表示回應對指定問題的相關程度。 如果未直接解決問題，則高度基礎的答案可能缺乏相關性。
相似度 會測量源數據文字與產生的回應之間的相似度。 模型是否使用精確的措辭？ 缺乏編輯治理可能會降低相似度分數。
擷取 表示索引查詢的有效性。 評估擷取的索引數據與問題對齊程度。 來自索引搜尋的不相關數據會降低此分數。 較高的擷取分數表示變異性較低，因為它們只依賴索引查詢。
流暢 度與詞彙使用方式有關。 如果模型遵守樣式指南，並以適當的格式呈現內容，即使它缺乏基礎或相關性，它也可以流暢。
一致性 會評估模型的語音是否自然且一致。 它評估對話是否像是真正的交流。
測試超參數
模型參數取決於應用程式特定的設計決策。 在應用程式設計中，根據工作負載的使用案例選擇模型和參數。 測試程式具有反覆的內部迴圈，其中會將定型數據與測試數據進行比較，以驗證模型是否在預期的數據集上進行定型。 此外，參數也會經過微調，讓模型能夠以可接受的精確度層級進行預測。
折衷。 內部迴圈包含定型模型的計算成本，以及透過測試評估模型的成本。 您必須將模型定型和測試所需的時間納入此迴圈。 預期測試程式需要比定型程式更長的時間。 您可以對定型數據的子集進行初始測試，以評估模型是否產生合理的結果。 您可以逐漸相應增加該測試集設為完整數據集。
測試推斷端點
推斷端點是 REST API，可讓您存取模型以進行預測。 這是您在要求中傳送數據的介面，並取得包含模型結果的回應。 端點裝載於計算上，可以是 PaaS，例如 Azure OpenAI Service 或非Microsoft推斷伺服器，例如 NVIDIA Triton Inference Server、TorchServe 和 BentoML。 在 PaaS 案例中，服務提供者會以某種程度處理測試。 不過，如果您裝載端點，請將它視為任何其他 API，並徹底測試它。
雖然您在定型和評估期間測試模型，但測試推斷端點牽涉到確保該模型周圍的機制，例如要求處理、回應建立、調整及跨實例的協調，都能夠正常運作。 建立完整的測試計劃，以根據您的需求涵蓋使用案例。 本節說明一些要考慮的測試案例和測試類型範例。
推斷裝載伺服器的測試考慮
請務必瞭解計算的負載特性，並透過負載測試驗證效能。 這些動作可協助您在設計或優化架構時選擇技術。 例如，不同的推斷伺服器有不同的效能特性。 當並行連線數目增加時，程式代碼會耗用CPU週期和記憶體。 瞭解您的程式代碼和計算資源如何在標準和尖峰負載條件下執行。 Azure 負載測試是負載測試的絕佳選項，可產生大量負載。 其他開放原始碼選項，例如 Apache JMeter，也很受歡迎。 請考慮直接從您的環境叫用這些測試。 例如，機器學習 與負載測試整合良好。
另一個關鍵決策是 GPU 功能的選擇。 由於設計，許多模型都需要 GPU 進行有效的推斷。 負載測試可協助您瞭解 GPU SKU 的效能限制，並防止過度布建，這是重要的財務考慮。
對於非 PaaS 裝載平臺，安全性非常重要，因為 API 公開。 請務必確保端點不會遭到惡意探索或遭入侵，這可能會危及整個系統。 包含此端點作為例行安全性測試的一部分，以及其他公用端點。 請考慮在即時系統上執行測試，例如滲透測試。 安全性的另一個方面是內容安全性。 您的程式代碼可以呼叫特製化 API，以偵測要求和響應承載中的有害內容。 您可以從測試呼叫 Azure AI 內容安全性，以利進行內容安全性測試。
如需重要策略，請參閱 安全性測試的建議。
PaaS 推斷端點的測試考慮
客戶端應該會在將要求傳送至 PaaS 服務上的推斷端點時發生錯誤。 失敗可能會因為系統多載、沒有回應的後端和其他錯誤狀況而發生。 對服務進行失敗模式分析，並測試這些潛在的失敗。 在用戶端程式代碼中設計和實作風險降低策略時，需要失敗模式分析。 例如，Azure OpenAI API 會傳回 HTTP 429 錯誤回應碼來節流要求。 客戶端應該使用重試機制和斷路器來處理該錯誤。 有關詳細資訊，請參閱「執行失敗模式分析的建議」。
測試 PaaS 服務可協助您選取服務 SKU，因為您了解相關聯的成本，例如隨用隨付或預先布建的計算。 使用 Azure 定價計算機來評估工作負載、頻率和令牌使用量，以判斷最佳的計費和計算選項。 使用低成本 SKU 模擬工作負載，並合理化適用於 Azure OpenAI 的已布建輸送量單位（PTU）等高端選項。
負載測試與隨用隨付計算無關，因為具有無限容量，您不會遇到問題。 測試會驗證限制和配額。 不建議針對隨用隨付計算進行負載測試，因為這是一筆顯著的財務費用。 不過，您應該負載測試來驗證輸送量，這是以每分鐘令牌或每分鐘要求為單位來測量的輸送量。 不同於考慮要求大小等計量的標準 API，此方法會根據令牌評估工作負載，以判斷使用量。 關鍵是瞭解作用中用戶的數目，並據以測量輸送量。 如需詳細資訊，請參閱 測量輸送量。
使用安全性控制件
無論您使用推斷伺服器還是 PaaS 選項，安全性都是您的責任。 使用 API 端點時，請務必測試越獄和內容安全性控件。 請確定無法略過這些控件，並如預期般運作。 例如，傳送已知的封鎖專案可協助您確認安全性控制是否已就緒，並在部署之前正常運作。 請考慮視需要執行這些測試，或將它們整合到發行程式中。
請務必測試系統是否不小心公開它不應該的資訊。 例如，系統不應該在響應承載中公開個人資訊。 此外，測試以確定客戶端無法存取適用於其他身分識別的端點。 進行安全性測試，以驗證 API 及其驗證和授權機制不會洩漏機密資訊，並維護適當的使用者分割。
測試地面數據
數據設計會影響產生模型的效率，而基礎數據是關鍵元件。 地面數據提供更多內容來提升回應的相關性。 它會在到達模型之前編製索引。 當使用者等候答案時，會即時存取此索引。
進行端對端測試，並將該程式納入數據設計。 實作測試程式，根據模型的效能、協調流程、索引、前置處理和源數據，評估並量化客戶體驗的結果。 反覆監視及測量品質計量。 以下是一些考量：
使用功能和整合測試徹底測試數據處理。 確認數據已如預期般載入，且所有數據都存在。
測試索引架構以取得回溯相容性。 您應該測試檔或欄位的任何變更，以確保新版本仍然可以容納舊版的數據。
在編製數據索引之前，它會進行準備，以減少雜訊和偏差，並啟用有效率的查詢。 此程式包括前置處理、區塊化和計算內嵌，而每個步驟都會將數據儲存至索引中的內容或檔案。 協調流程管線，例如 Azure AI 搜尋所提供的技能集，會執行這些步驟。 您必須測試協調流程程序代碼，以確保不會遺漏任何步驟，且已處理的數據品質很高。
測試應該檢查舊數據、綜合值、空數據表、數據重新整理，以及最新版本的處理。 如果測試失敗發生，您可能需要調整搜尋查詢和索引。 此程式包括調整篩選條件和先前討論的其他元素。 您應該將測試視為反覆活動。
索引很複雜，查詢效能可能會根據索引結構而有所不同，這需要負載估計。 適當的負載測試可協助判斷記憶體、計算和其他可用來支援您需求的不同 SKU。
您必須測試所有安全性控制件。 例如，數據可能會分割成不同的檔。 每個分割區都有訪問控制。 您必須正確測試這些控制件以保護機密性。
測試協調器
RAG 應用程式的主要元件是中央協調器。 此程式代碼會協調與初始使用者問題相關的各種工作。 協調器工作通常需要瞭解使用者意圖、與索引的連線來查閱地面數據，以及呼叫推斷端點。 如果代理程式需要執行工作，例如呼叫 REST API，此程式代碼會在內容中處理這些工作。
您可以使用任何語言開發協調流程程式代碼，或從頭開始撰寫。 不過，我們建議您使用 Azure AI Studio 中的提示流程或 Apache Airflow 的導向非循環圖形 （DAG） 等技術，以加速和簡化開發程式。 提示流程提供設計時間體驗。 使用它將工作模組化為單位，並連接每個單位的輸入和輸出，最終形成代表整個程式的協調流程程序代碼。
隔離您的協調流程程序代碼。 分別開發它，並使用在線端點和 REST API 將其部署為微服務 ，以供存取。 此方法可確保模組化且易於部署。
從測試的觀點來看，請將此程式代碼視為任何其他程序代碼，並 執行單元測試。 不過，更重要的層面是其功能，例如其路由邏輯，您可以透過功能和整合測試進行驗證。 測試提示工程，以確保程式碼可以適當地偵測使用者意圖並路由呼叫。 測試有數個架構和連結庫，例如 Scikit-learn、PyTorch 的 torch.testing 模組、FairML 的偏差和公平性測試，以及用於模型評估的 TensorFlow 模型分析。
此外，請執行運行時間測試，例如失敗模式測試。 例如，測試與令牌限制相關的潛在失敗。
某些運行時間測試可協助您做出決策。 執行負載測試 ，以瞭解此程式代碼在壓力下的行為，並使用結果進行容量規劃。 由於此程式代碼位於需要觸達其他服務的架構中的關鍵位置，因此有助於從所有這些呼叫收集遙測。 此數據可深入解析本機處理與網路呼叫所花費的時間，以及判斷其他元件的行為，例如潛在的延遲。 提示流程等技術具有內建的遙測功能，可協助進行此程式。 否則，請將遙測併入您的自定義程式碼中。
注意
測試此程式代碼具有成本影響。 例如，如果您使用 Azure OpenAI 來裝載推斷端點，壓力測試是可協助您判斷系統限制的常見做法。 不過，每個通話的 Azure OpenAI 費用可能會使大量壓力測試變得昂貴。 優化費用的其中一個方法是在測試環境中使用 Azure OpenAI 的未使用 PTU。 或者，您可以模擬推斷端點。
安全性考慮同時適用於協調流程程序代碼和模型。 包括針對越獄測試，其中目標是要打破模型的安全性。 攻擊者不會直接與模型互動。 他們會先與協調流程程式代碼互動。 協調流程程式代碼會接收使用者要求並加以剖析。 如果協調流程程式代碼收到惡意要求，它可以將該要求轉送至模型，並可能危害模型。
內容安全性是另一個重要層面。 在聊天機器人應用程式中，協調流程程式代碼會接收聊天文字。 在程式代碼中， 請考慮呼叫內容安全服務。 同時傳送使用者提示和地面內容進行分析，並接收風險的評估。 提示防護 是統一的 API，可分析大型語言模型輸入，並偵測使用者提示攻擊和文件攻擊，這是兩種常見的對抗輸入類型。
安全性控制與驗證對於 RESTful 端點至關重要 。 您需要管理驗證並確保徹底測試。
防止模型衰變
所有模型的常見問題是一段時間的效能降低。 工作負載內部和外部的變更最終會導致模型的品質及其輸出降低。 模型衰變有兩種方式：
輸入數據變更時，會發生數據漂移 。 新的數據輸入會使定型的模型過期。 例如，您可能有一個模型可預測特定地理區域的投票模式，例如區域。 如果區域已重新繪製，且該區人口的人口統計數據會變更，則必須更新您的模型以考慮變更。
當工作負載和模型外部的條件變更時，就會發生概念漂移 ，讓模型輸出不再符合現實。 例如，您可能有技術產品的銷售預測模型。 如果競爭對手意外引入更進階的競爭產品，引起公眾的極大關注，您需要根據消費者趨勢的變化來更新您的模型。
可能的話，請使用自動化測試來偵測和評估模型生命週期的模型衰變。 如果您的模型預測離散值，您可以建立測試來評估這些值在一段時間內的預測，並測量預期和實際結果之間的偏差。 藉由比較摘要統計數據和距離計量來補充這項測試，以偵測一段時間的漂移。
識別模型衰變的另一個常見方法是用戶意見反應。 用戶意見反應的範例是豎起大拇指或向下拇指響應機制。 追蹤一段時間的正面與負面意見反應，並在符合負面意見反應閾值時建立警示，可協助您知道何時調查模型的品質。
不論您用來識別模型衰變的訊號為何，警示潛在衰變的作業小組都需要讓數據科學家研究訊號，並判斷衰變是否發生，以及根本原因。
實作工具
使用 Azure 機器學習 資料收集器，從部署到受控在線端點或 Kubernetes 在線端點的模型取得輸入和輸出數據的實時記錄。 機器學習 會將記錄的推斷數據儲存在 Azure Blob 記憶體中。 接著，您可以將此數據用於模型監視、偵錯或稽核，以提供已部署模型效能的可觀察性。 如果您在 機器學習 或 機器學習 批次端點之外部署模型，則無法利用數據收集器，且需要操作另一個數據收集程式。
使用 機器學習 模型監視來實作監視。 機器學習 藉由對串流生產推斷數據和參考數據執行統計計算，以取得監視訊號。 參考資料可以是歷程記錄定型資料、驗證資料或有根據事實資料。 另一方面，生產推斷資料是指模型在生產階段收集到的輸入和輸出資料。
- 請參閱 機器學習 模型監視，以瞭解 機器學習 的監視功能及其擷取和分析的計量。
- 如需更多監視建議，請參閱最佳做法。