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