Azure 上 AI 工作負載的應用程式設計
規劃使用 AI 函式建置應用程式時，有許多選項可供您考慮。 您獨特的功能和非功能性需求可協助您縮小設計的相關高階決策範圍，例如使用案例是傳統機器學習、產生式、決定性或 AI 類型的組合。 當您從高階設計區域移至較低層級的設計區域時，有數個選項可以一路上考慮。
如開始使用文章所述，選擇要建置您自己的模型或使用預先建置的模型，是要做出的第一個重要決策之一。 選擇預先建置的模型時，請考慮下列幾點：
目錄來源。 探索擁抱臉部模型中樞、TensorFlow 中樞或 Azure AI Studio 模型目錄等存放庫，以尋找預先定型的模型。 這些平臺提供跨各種工作的廣泛模型目錄。
授權。 請確定模型的授權條款符合您的安全性、合規性和應用程式目標，特別是當您打算散發應用程式或將其與其他服務整合時。
重要元件。 查看模型的架構、定型數據、效能和授權，以判斷其是否針對您的工作或網域進行微調。
如需選擇裝載平臺的指引，請參閱 模型裝載平台考慮。
本文探討許多常見的設計領域和因素，以在做出關於技術和方法的重要決策時考慮。
建議
以下是本文所提供的建議摘要。
| 建議 | 描述 |
|---|---|
| 優先處理現成的解決方案。 | 只要實用，請使用平臺即服務 （PaaS） 解決方案來處理工作負載功能。 盡可能使用預先建置和預先定型的模型，將工作負載和作業小組的操作和開發負擔降到最低。 |
| 將函式和功能從用戶端抽象化。 | 藉由設計後端服務來處理跨領域考慮，例如速率限制和故障轉移作業，讓用戶端盡可能精簡。 |
| 封鎖對數據存放區的存取。 | AI 系統中的程式代碼不應該直接接觸您的數據存放區。 透過 API 層路由傳送所有資料要求。 API 應針對所需的特定工作而建置。 |
| 隔離您的模型。 | 如同數據存放區，請使用 API 層作為模型要求閘道。 某些 PaaS 解決方案，例如 Azure OpenAI 服務和 Azure 機器學習 使用此用途的 SDK。 許多工具，例如 PromptFlow，包含原生支援，以將 API 傳播至服務。 |
| 設計可獨立部署的元件。 | AI 模型、數據管線、前端元件和微服務，例如數據前置處理、特徵擷取和推斷，應該獨立部署，以優化工作負載的彈性、延展性和可操作性。 |
容器化元件
為了確保可獨立部署的元件是完全獨立的，並簡化部署，請考慮容器化作為設計策略的一部分。 下列元件應容器化：
微服務： 應容器化處理應用程式的特定功能，例如數據處理、模型推斷或使用者驗證等個別微服務。 這種方法允許獨立部署和調整，以利更有效率的更新和維護。
AI 模型： 容器化 AI 模型，以確保所有相依性、連結庫和組態都組合在一起。 此方法會將模型環境與主機系統隔離，防止版本衝突，並確保不同部署環境的行為一致。
數據處理管線： 任何在模型推斷之前或遵循模型推斷的數據處理工作，例如數據清理、轉換和特徵擷取，都應該容器化。 此方法可增強重現性，並簡化相依性的管理。
基礎結構服務： 提供基礎結構支援的服務，例如資料庫或快取層，也可以受益於容器化。 這種方法有助於維護版本一致性，並協助更輕鬆地調整和管理這些元件。
與其他工作負載元件共置 AI 元件
有數個很好的理由，將您的 AI 元件與其他工作負載元件共置，但這樣做有取捨。 您可能會共置的原因如下：
延遲敏感度： 當低延遲很重要時，將 AI 元件與其他服務共置，例如 API 裝載。 例如，如果需要即時推斷來增強用戶體驗，將 AI 模型放在 API 附近，可以將擷取結果所需的時間降到最低。
數據鄰近性： 當 AI 模型需要經常存取特定數據集時，例如搜尋索引，共置這些元件可以改善效能，並減少數據傳輸的額外負荷，以加快處理和推斷速度。
資源使用率： 如果某些元件具有互補的資源需求，例如 CPU 和記憶體，共置它們可以優化資源使用量。 例如，需要大量計算的模型可以與同時需求較低的服務共用資源。
權衡。 應該考慮共置元件的取捨。 您可能會失去獨立部署或調整元件的能力。 您也可以增加事件的潛在爆破半徑來增加您的故障風險。
評估在產生的 AI 解決方案中使用協調器
協調器會管理工作流程，協調 AI 解決方案的不同元件之間的通訊，否則在複雜的工作負載中難以管理。 如果您的工作負載具有下列任何特性，建議您在設計中建置協調器：
複雜工作流程： 工作流程牽涉到多個步驟，例如前置處理、模型鏈結或後置處理。
條件式邏輯： 必須根據模型輸出動態做出決策，例如將結果路由傳送至不同的模型。
調整和資源管理： 您必須根據需求使用模型調整來管理大量應用程式的資源配置。
狀態管理： 您需要管理使用者互動的狀態和記憶體。
數據擷取： 您必須能夠從索引擷取增強數據。
使用多個模型的考慮
當您的工作負載使用多個模型時，使用協調器非常重要。 協調器負責根據使用案例，將數據和要求路由傳送至適當的模型。 規劃模型之間的數據流，確保一個模型的輸出可作為另一個模型的輸入。 規劃可能會牽涉到數據轉換或擴充程式。
協調流程和代理程式
針對產生式 AI 工作負載，請考慮採用代理程式為基礎的代理程式，有時稱為 代理程式的方法，以將擴充性新增至協調流程。 代理程式是指內容系結功能，共用許多微服務樣式特性，這些特性會與協調器一起執行工作。 協調器可以將工作公告給代理程式集區，或者代理程式可以向協調器註冊功能。 這兩種方法可讓協調器動態決定如何在代理程序之間分拆和路由查詢。
當您有一個具有多個、不斷演變的功能時，代理程式方法很理想，可 插入 該體驗，以在一段時間內將更多技能和地面數據新增至流程。
對於具有許多代理程式的複雜工作負載，允許代理程式動態共同作業，而不是使用協調器來分手工作並指派它們，會更有效率。
協調器和代理程式之間的通訊應該遵循主題佇列模式，其中代理程式是主題的訂閱者，協調器會透過佇列傳送工作。
使用代理程式方法最適合協調流程模式，而不是 編舞模式。
如需詳細資訊，請參閱 協調流程平台的考慮。
評估 API 閘道的使用
API 閘道，例如 Azure API 管理，會將函式與要求服務與 API 之間的相依性分離開來。 API 閘道可為 AI 工作負載提供下列優點：
多個微服務： 它們可協助您管理多個 AI 模型端點，而且您需要強制執行一致的原則，例如速率限制和驗證。
流量管理： 其可透過管理要求、快取回應和散發負載，協助您有效率地管理高流量應用程式。
安全性： 它們為閘道後方的 API 提供集中式存取控制、記錄和威脅防護。
利用 AI 應用程式設計模式
已針對 AI 應用程式在產業中建立的數個常見設計模式，可用來簡化設計和實作。 這些設計模式包括：
模型組合： 此設計模式牽涉到結合多個模型的預測，以改善精確度和健全性，降低個別模型的弱點。
微服務架構： 將元件分成可獨立部署的服務可增強延展性和可維護性，讓小組能夠同時處理應用程式的不同部分。
事件驅動架構： 利用事件來觸發動作可讓分離的元件和實時處理，讓系統更回應並適應變更數據。
RAG 模式和區塊化策略
擷取增強世代 （RAG） 模式結合了產生模型與擷取系統，讓模型能夠存取外部知識來源，以改善內容和精確度。 如需此模式的深入指引，請參閱設計和開發RAG解決方案系列。 有兩種RAG方法：
Just-In-Time： 此方法會在要求時動態擷取相關信息，確保一律使用最新的數據。 這在需要即時內容的案例中很有説明，但可能會造成延遲。
預先計算（快取）： 此方法牽涉到快取擷取結果，藉由提供預先計算的數據來減少響應時間。 它適用於可儲存一致數據的高需求案例，但可能不會反映最新的資訊，導致潛在的相關性問題。
使用RAG模式時，定義完善的區塊化策略對於優化工作負載的效能效率至關重要。 從設計和開發RAG解決方案系列中提供的指引開始。 需要考慮的其他建議包括：
實作動態區塊化策略，根據數據類型、查詢複雜度和使用者需求來調整區塊大小。 這可以提升擷取效率和內容保留。
納入意見反應迴圈，以根據效能數據精簡區塊化策略。
藉由維護連結回地面來源的元數據和唯一標識符，保留區塊的數據譜系。 清除譜系文件可協助確保使用者了解數據來源、其轉換，以及其對輸出的貢獻方式。
使用設計模式的時機
當您的使用案例符合其中一個條件時，請考慮使用這些設計模式：
複雜工作流程： 處理多個 AI 模型之間的複雜工作流程或互動時，RAG 或微服務等模式有助於管理複雜度，並確保元件之間的通訊清晰。
延展性需求： 如果應用程式的需求變動，使用微服務之類的模式可讓個別元件獨立調整，以容納不同的負載，而不會影響整體系統效能。
數據驅動應用程式： 如果您的應用程式需要大量的數據處理，事件驅動架構可以提供即時回應性和有效率的數據處理。
注意
較小的應用程式或POC通常不會因採用其中一種設計模式而受益，而且應該使用簡單的設計來建置。 同樣地，如果您有資源（預算、時間或計數）條件約束，則使用可稍後重構的簡單設計，是比採用複雜設計模式更好的方法。
選擇正確的架構和連結庫
架構和連結庫的選擇與應用程式設計緊密相連，不僅影響架構，而且會影響效能、延展性和可維護性。 相反地，設計需求可以限制架構選擇，在兩者之間建立動態互動。 例如，使用語意核心 SDK （SK） 通常鼓勵微服務型設計，其中每個代理程式或功能都封裝在自己的服務內。 選擇架構和連結庫時需要考慮的因素如下：
應用程式需求： 應用程式的特定需求，例如實時處理或批處理，可能會限制架構的選擇。 例如，如果應用程式需要低延遲，可能需要具有異步功能的架構。
整合需求： 設計可能需要與其他系統或服務的特定整合。 如果架構不支援必要的通訊協定或數據格式，可能需要重新考慮設計或選取不同的架構。
小組專業知識： 開發小組的技能集可以限制架構選擇。 依賴較不熟悉架構的設計可能會導致開發時間和複雜度增加，進而選擇更熟悉的工具。
設計身分識別、授權和存取的策略
一般而言，您應該以通常設計應用程式的相同方式來接近身分識別、授權和存取。 您應該使用身分識別提供者，例如Microsoft Entra ID，盡可能管理這些區域。 不過，許多需要特殊考慮的 AI 應用程式都有獨特的挑戰。 透過系統保存訪問控制清單（ACL）有時具有挑戰性，甚至不可能，而不需要引進新的開發。
檢閱安全多租使用者 RAG 解決方案中找到的指引，以瞭解如何將安全性修剪元數據新增至檔和區塊。 此修剪可以根據安全組或類似的組織建構。
請考慮非功能需求
您的工作負載可能會因為 AI 技術固有的因素而面臨挑戰，因此您的工作負載可能有非功能需求。 常見的非功能需求及其挑戰包括：
模型推斷/逾時延遲： AI 應用程式通常需要即時或近乎實時的回應。 設計低延遲非常重要，這牽涉到優化模型架構、數據處理管線和硬體資源。 實作快取策略並確保有效率的模型載入也是避免逾時並提供及時回應的必要條件。
令牌或要求輸送量限制： 許多 AI 服務會對令牌數目或要求的輸送量施加限制，特別是在使用雲端式模型時。 針對這些限制進行設計需要仔細管理輸入大小、在必要時批處理要求，以及可能實作速率限制或佇列機制來管理使用者期望，並防止服務中斷。
成本和退款案例： 設計成本透明度涉及實作使用量追蹤和報告功能，以利退款模型，讓組織能夠準確地跨部門配置成本。 計費管理通常是由 API 閘道處理，例如 Azure API 管理。