生成式 AI 帶來了全新的 AI 應用程式建構和運作方式，與預測型 AI 不同。如要建構生成式 AI 應用程式，您必須從各種架構和大小中選擇、管理資料、設計最佳提示、針對特定工作調整模型，以及根據實際資料建立模型輸出內容。
本文說明如何調整 DevOps 和 MLOps 程序，在現有基礎模型上開發、部署及運作生成式 AI 應用程式。如要瞭解如何部署預測型 AI，請參閱「機器學習運作：機器學習的持續推送軟體更新與自動化管線」。
什麼是 DevOps 和 MLOps？
開發運作是一種軟體工程方法，可連結開發和營運。開發運作可促進協作、自動化和持續改善，藉由持續整合和持續推送軟體更新 (CI/CD) 等做法，簡化軟體開發生命週期。
機器學習運作以開發運作原則為基礎，解決建構及運作機器學習 (ML) 系統時面臨的挑戰。機器學習系統通常會使用預測型 AI 找出模式並進行預測。MLOps 工作流程包括下列項目：
- 資料驗證
- 模型訓練
- 模型評估與反覆運算
- 模型部署與服務
- 模型監控
什麼是基礎模型？
基礎模型是生成式 AI 應用程式的核心元件。這些模型是大型程式，會使用資料集學習並做出決策，不需要人為介入。基礎模型會接受各種資料訓練，包括文字、圖片、音訊和影片。基礎模型包括大型語言模型 (LLM)，例如 Llama 3.1，以及多模態模型，例如 Gemini。
與以特定資料集訓練的預測型 AI 模型不同，基礎模型是以龐大且多元的資料集訓練而成。這項訓練課程可協助您運用基礎模型，開發適用於各種用途的應用程式。基礎模型具有突現特性 (PDF)，因此無須經過明確訓練，就能針對特定輸入內容提供回覆。由於這些新興特性，基礎模型難以建立及運作，因此您必須調整開發運作和機器學習運作程序。
開發基礎模型需要大量資料資源、專用硬體、大量投資和專業知識。因此，許多企業偏好使用現有的基礎模型，簡化生成式 AI 應用程式的開發和部署作業。
生成式 AI 應用程式的生命週期
生成式 AI 應用程式的生命週期包含下列階段：
- 探索：開發人員和 AI 工程師找出最適合其用途的基礎模型。他們會考量每個模型的優缺點和費用，做出明智的決策。
- 開發和實驗：開發人員會運用提示工程技術，建立及調整輸入提示，以取得所需輸出內容。如果可以，請使用少量樣本學習、參數高效微調 (PEFT) 和模型鏈結，引導模型行為。模型鏈結是指以特定順序協調對多個模型的呼叫，藉此建立工作流程。
- 部署：開發人員必須在部署過程中管理許多構件，包括提示範本、鏈結定義、嵌入模型、擷取資料儲存庫和微調模型轉接程式。這些構件有各自的治理要求，因此在開發和部署期間，需要仔細管理。部署生成式 AI 應用程式時，也必須考量目標基礎架構的技術功能，確保符合應用程式的硬體需求。
- 持續監控正式環境：管理員可運用負責任的 AI 技術 (例如確保模型輸出內容的公平性、透明度和可靠度)，提升應用程式效能並維持安全標準。
- 持續改善：開發人員會透過提示技巧不斷調整基礎模型、換成新版模型，甚至結合多個模型，以提升效能、成本效益或縮短延遲時間。如果需要重複微調或納入人類回饋迴路，傳統的持續訓練仍適用於這些情境。
資料工程實務在所有開發階段都扮演著關鍵角色。 如要產生可靠的輸出內容，您必須建立事實基礎 (確保模型輸出內容是以準確的最新資訊為依據)，並從內部和企業系統取得最新資料。微調資料有助於調整模型，以適應特定工作和風格，並修正持續發生的錯誤。
尋找符合您用途的基礎模型
由於建構基礎模型需要大量資源，因此大多數企業偏好使用最適合自身用途的現有基礎模型。由於基礎模型種類繁多，因此很難找到合適的模型。每個模型的架構、大小、訓練資料集和授權都不盡相同。此外，每個用途都有獨特需求，因此您必須從多個層面分析可用模型。
評估模型時，請考量下列因素：
- 品質：執行測試提示，評估輸出內容品質。
- 延遲時間和輸送量：判斷您的用途所需的正確延遲時間和輸送量，因為這些因素會直接影響使用者體驗。舉例來說，與批次處理的摘要工作相比，聊天機器人需要較低的延遲時間。
- 開發和維護時間：請考量初始開發和持續維護所需的時間投入。相較於自行部署的公開模型，管理型模型通常需要較少心力。
- 使用費用：請考慮與模型相關聯的基礎架構和用量費用。
- 法規遵循：評估模型遵守相關法規和授權條款的能力。
開發及實驗
建構生成式 AI 應用程式時，開發和實驗會反覆進行並自動調度管理。每次實驗疊代都涉及資料精修、基礎模型調整，以及結果評估。評估可提供意見回饋，引導後續疊代，形成持續回饋的循環。如果成效未達預期，您可以收集更多資料、擴增資料，或進一步管理資料。此外，您可能需要最佳化提示、套用微調技術，或改用其他基礎模型。這個由評估洞察資料驅動的疊代式精進週期，對於最佳化生成式 AI 應用程式的重要性，與機器學習和預測式 AI 相同。
基礎模型範例
基礎模型與預測模型不同，因為基礎模型是多用途模型。基礎模型並非以特定工作專用的資料訓練，而是以廣泛的資料集訓練，因此可應用於許多不同的用途。
基礎模型對輸入內容的變化非常敏感，模型的輸出內容和執行的工作取決於模型的輸入內容。只要變更輸入內容，基礎模型就能翻譯文字、生成影片或分類資料。即使輸入內容只有微小變化，也可能影響模型正確執行該項工作的能力。
基礎模型的這些屬性需要不同的開發和作業實務。雖然預測型 AI 環境中的模型是自給自足且專為特定工作而設計，但基礎模型是多用途模型，除了使用者輸入內容外，還需要額外元素。生成式 AI 模型需要提示，更具體來說，需要提示範本。提示範本是一組指令和範例，以及可容納使用者輸入內容的預留位置。應用程式可以結合提示範本和動態資料 (例如使用者輸入內容)，建立完整的提示，也就是傳遞至基礎模型的輸入文字。
提示模型元件
提示是生成式 AI 應用程式的顯著特徵。模型和提示不足以生成內容，生成式 AI 需要兩者。模型和提示的組合稱為提示模型元件。提示模型元件是最小的獨立元件，足以建立生成式 AI 應用程式。提示不必太複雜，例如，你可以下達簡單的指令，像是「將下列句子從英文翻譯成法文」，然後輸入要翻譯的句子。不過，如果沒有初步指示，基礎模型就無法執行必要的翻譯工作。因此，您必須提供提示 (即使只是基本指示) 和輸入內容，才能讓基礎模型執行應用程式所需的工作。
提示模型元件為開發生成式 AI 應用程式時的 MLOps 做法，建立重要區別。開發生成式 AI 應用程式時，必須在提示模型元件的環境中進行實驗和疊代。生成式 AI 實驗週期通常從測試提示變化形式開始，包括變更指令措辭、提供額外背景資訊或加入相關範例，並評估這些變更的影響。這種做法通常稱為「提示工程」。
提示工程包含下列疊代步驟：
- 提示：設計及調整提示，讓基礎模型針對特定用途產生所需行為。
- 評估：評估模型輸出內容，最好是以程式輔助，藉此評估模型對提示指令的理解程度，以及是否成功完成指令。
如要追蹤評估結果，您可以選擇註冊實驗結果。提示本身是提示工程流程的核心元素，因此會成為實驗中最重要的構件。
不過，如要試用生成式 AI 應用程式，請務必找出構件類型。在預測型 AI 中，資料、管道和程式碼都不相同。但在生成式 AI 的提示範例中，提示可包含脈絡、指示、範例、防護措施，以及從其他地方提取的實際內部或外部資料。
如要判斷構件類型，您必須瞭解提示有不同元件，且需要不同的管理策略。請考量下列事項：
- 提示即資料：提示的某些部分就像資料一樣。少樣本範例、知識庫和使用者查詢等元素本質上都是資料點。這些元件需要以資料為中心的 MLOps 做法，例如資料驗證、漂移偵測和生命週期管理。
- 提示即程式碼：其他元件 (例如脈絡、提示範本和防護措施) 與程式碼類似。這些元件定義了提示本身的結構和規則，需要更多以程式碼為中心的做法，例如核准程序、程式碼版本控管和測試。
因此，將機器學習運作實務應用於生成式 AI 時，您必須提供相關程序，讓開發人員輕鬆儲存、擷取、追蹤及修改提示。這些流程可加快疊代速度，並進行有原則的實驗。通常一個版本的提示適用於特定模型版本，但可能不適用於其他版本。追蹤實驗結果時，請務必記錄提示、元件版本、模型版本、指標和輸出資料。
模型鏈結和擴增
生成式 AI 模型 (尤其是大型語言模型) 在維持最新狀態和避免產生幻覺方面，面臨著固有的挑戰。將新資訊編碼至 LLM 需要耗費大量資源，且必須先經過密集的預先訓練，才能部署。視用途而定，只使用一個提示模型執行特定生成作業可能不夠。如要解決這個問題，您可以將多個提示模型連結在一起，並呼叫外部 API 和以程式碼表示的邏輯。以這種方式連結在一起的一連串提示模型元件，通常稱為鏈結。
下圖顯示鏈結的元件和相關開發程序。
減少近期的資訊和幻覺
有兩種常見的鏈結式模式可減少近期的幻覺，分別是檢索增強生成 (RAG) 和代理程式。
- RAG 會從資料庫擷取知識，增強預先訓練的模型，因此不需要預先訓練。RAG 會直接在生成過程中納入最新事實資訊，藉此建立基準並減少幻覺。
- 代理程式 (由 ReAct 提示技術 (PDF) 普及) 會使用 LLM 做為中介程式，與各種工具互動，包括 RAG 系統、內部或外部 API、自訂擴充功能，甚至是其他代理程式。代理程式會動態選取並使用相關資訊來源，因此可處理複雜查詢和執行即時動作。LLM 會扮演代理程式的角色，解讀使用者的查詢、決定要使用的工具，並根據擷取的資訊擬定回覆。
您可以運用 RAG 和代理程式，建立連結至大型資訊網路的多代理程式系統，實現複雜的查詢處理和即時決策。
對生成式 AI 應用程式而言，協調不同模型、邏輯和 API 並非新技術。舉例來說，推薦引擎會結合協同過濾模型、以內容為準的模型和業務規則，為使用者產生個人化產品推薦內容。同樣地，在詐欺偵測方面，機器學習模型會與規則型系統和外部資料來源整合，以找出可疑活動。
這些生成式 AI 元件鏈的不同之處在於，您無法事先描述元件輸入內容的分布情形，因此更難以單獨評估及維護個別元件。編排作業會徹底改變您開發生成式 AI 專用 AI 應用程式的方式。
在預測式 AI 中，您可以單獨疊代個別模型和元件，然後在 AI 應用程式中將這些模型和元件串連起來。在生成式 AI 領域中，您會在整合期間開發鏈結、對鏈結執行端對端實驗，並以協調一致的方式疊代鏈結策略、提示、基礎模型和其他 API，以達成特定目標。您通常不需要進行特徵工程、收集資料或進一步訓練模型，只要變更提示範本的措辭即可。
相較於預測式 AI 的機器學習運作平台，生成式 AI 的機器學習運作平台有以下差異：
- 評估：由於鏈結緊密耦合，鏈結需要端對端評估，而不只是評估每個元件，才能衡量整體效能和輸出內容品質。就評估技術和指標而言，評估鏈結與評估提示模型類似。
- 版本管理：您必須將鏈結視為完整的構件來管理。您必須追蹤鏈結設定及其修訂記錄，以利分析、重現，並瞭解變更對輸出的影響。記錄檔必須包含輸入內容、輸出內容、鏈結的中間狀態，以及每次執行期間使用的任何鏈結設定。
- 持續監控：如要偵測鏈結中的效能降低、資料偏移或異常行為，您必須設定主動監控系統。持續監控有助於盡早找出潛在問題，確保生成內容的品質。
- 內省：您必須檢查鏈結的內部資料流 (也就是每個元件的輸入和輸出)，以及整個鏈結的輸入和輸出。開發人員可以查看鏈結中流動的資料和產生的內容，找出錯誤、偏誤或不當行為的來源。
下圖顯示鏈結、提示模型元件和模型微調如何在生成式 AI 應用程式中協同運作，以減少近期性問題和錯覺。系統會管理資料、調整模型，並新增鏈結，進一步改善回覆內容。評估結果後，開發人員可以記錄實驗並繼續疊代。
微調
開發涉及基礎模型的生成式 AI 用途時，如果只依賴提示工程和鏈結來解決用途，可能會很困難，尤其是複雜的工作。為提升工作效能，開發人員通常需要直接微調模型。微調功能可讓您主動變更模型的所有層或部分層 (參數效率微調)，以提升模型執行特定工作的能力。以下是調整模型最常見的方法：
- 監督式微調：以監督方式訓練模型，教導模型預測特定輸入內容的正確輸出序列。
- 人類回饋增強學習 (RLHF)：訓練獎勵模型，預測使用者偏好的回覆。接著，您可以使用這個獎勵模型，在微調過程中引導 LLM 朝正確方向發展。這個過程類似於由一組人類評審引導模型的學習。
下圖顯示微調如何在實驗週期中協助改善模型。
在 MLOps 中，微調與模型訓練共用下列功能：
- 能夠追蹤微調工作中的構件。舉例來說，構件包括輸入資料或用於調整模型的參數。
- 能夠評估調整作業的影響。這項功能可讓您評估針對特定工作訓練的微調模型，並比較結果與先前微調的模型或相同工作的凍結模型。
持續訓練和調整
在機器學習運作中，持續訓練是指在正式環境中重複重新訓練機器學習模型。持續訓練可確保模型與時俱進，並在實際資料模式隨時間變化時，仍能維持良好效能。對於生成式 AI 模型，由於涉及高昂的資料和運算成本，因此持續調整模型通常比重新訓練模型更實用。
持續調整模型的方法取決於您的特定用途和目標。如果是相對靜態的工作 (例如文字摘要)，持續調整模型的需求可能較低。但對於需要持續與人類對齊的動態應用程式 (例如聊天機器人)，則必須更頻繁地使用 RLHF 等技術，根據人類回饋進行微調。
如要判斷合適的持續微調策略，您必須評估用途的性質，以及輸入資料隨時間的變化。成本也是主要考量因素，因為運算基礎架構會大幅影響微調速度和費用。微調作業需要圖形處理器 (GPU) 和 Tensor Processing Unit (TPU) 這類硬體。GPU 以平行處理能力著稱，非常適合處理需要大量運算資源的工作負載，通常用於訓練及執行複雜的機器學習模型。另一方面，TPU 是 Google 專為加速機器學習工作而設計。TPU 擅長處理深度學習類神經網路中常見的大型矩陣運算。
資料做法
先前，機器學習模型的行為完全由訓練資料決定。雖然這對基礎模型來說仍是事實，但以基礎模型為基礎建構的生成式 AI 應用程式，其模型行為取決於您如何使用不同類型的輸入資料調整模型。
基礎模型會使用下列資料進行訓練：
- 預先訓練資料集 (例如 C4、The Pile 或專屬資料)
- 指令調整資料集
- 安全性調整資料集
- 人類偏好資料
生成式 AI 應用程式會根據下列資料進行調整：
- 提示
- 擴增或基礎資料 (例如網站、文件、PDF、資料庫或 API)
- PEFT 的特定工作資料
- 特定工作的評估
- 人類偏好資料
預測式機器學習與生成式 AI 的資料做法主要差異，在於生命週期流程的開端。在預測型機器學習中，您會花費大量時間進行資料工程，如果沒有正確的資料，就無法建構應用程式。在生成式 AI 中，您會從基礎模型、一些指令，以及可能的一些輸入範例 (例如情境內學習) 開始。您可以使用極少量資料，快速製作應用程式原型並發布。
不過，原型設計的便利性也帶來了額外挑戰，那就是管理各種資料。預測式 AI 依賴定義明確的資料集。在生成式 AI 中，單一應用程式可使用來自完全不同資料來源的各種資料類型，並讓這些資料類型共同運作。
請考慮下列資料類型：
- 條件提示：提供給基礎模型的指令，用來引導模型輸出內容，並設定可生成內容的範圍。
- 少量樣本範例：透過輸入/輸出組合，向模型展示您想達成的目標。這些範例有助於模型瞭解特定工作，且在許多情況下，這些範例可以提升效能。
- 基準或擴增資料：這類資料可讓基礎模型針對特定脈絡生成回覆，並確保回覆內容符合現況且相關，不必重新訓練整個基礎模型。這類資料可能來自外部 API (例如 Google 搜尋)，或是內部 API 和資料來源。
- 特定工作資料集：這類資料集有助於微調現有的基礎模型，讓模型專精於特定工作，進而提升該領域的成效。
- 完整預先訓練資料集：用於初步訓練基礎模型的大量資料集。雖然應用程式開發人員可能無法存取這些資訊或權杖化工具，但模型本身編碼的資訊會影響應用程式的輸出內容和效能。
這類多元資料類型在資料組織、追蹤和生命週期管理方面，都增加了複雜度。舉例來說，以 RAG 為基礎的應用程式可以重寫使用者查詢、使用精選範例集動態收集相關範例、查詢向量資料庫，以及將資訊與提示範本合併。以 RAG 為基礎的應用程式需要管理多種資料類型，包括使用者查詢、含有精選少樣本範例和公司資訊的向量資料庫，以及提示範本。
每種資料類型都需要仔細整理和維護。舉例來說，向量資料庫需要將資料處理為嵌入內容、最佳化分塊策略，並確保只提供相關資訊。提示範本需要版本控管和追蹤，使用者查詢也需要重寫。MLOps 和 DevOps 最佳做法可協助您完成這些工作。在預測型 AI 中，您會建立資料管道，用於擷取、轉換及載入資料。在生成式 AI 中，您可以建構管道，以可追蹤、可重現的方式管理、演進、調整及整合不同資料類型。
微調基礎模型可提升生成式 AI 應用程式的效能，但模型需要資料。您可以啟動應用程式並收集真實世界資料、產生合成資料，或兩者兼具，藉此取得這項資料。使用大型模型生成合成資料越來越受歡迎，因為這種方法可加快部署程序，但仍須由人工檢查結果，確保品質。以下是使用大型模型進行資料工程的範例：
- 生成合成資料：這個程序會建立人工資料，在特徵和統計屬性方面與實際資料極為相似。大型且功能強大的模型通常可以完成這項工作。 合成資料可做為生成式 AI 的額外訓練資料，即使有標籤的真實世界資料不足，也能讓 AI 學習模式和關聯。
- 合成資料修正：這項技術的重點在於找出並修正現有標記資料集中的錯誤和不一致之處。生成式 AI 運用大型模型的強大功能，標示潛在的標籤錯誤並建議修正，提升訓練資料的品質和可靠性。
- 合成資料擴增：這種方法不只是生成新資料，合成資料擴增技術會智慧地操縱現有資料，建立多種變化形式，同時保留重要特徵和關係。訓練期間，生成式 AI 可能會遇到比預測型 AI 更廣泛的情境，因此能提升泛化能力，並生成細緻且相關的輸出內容。
與預測式 AI 不同，生成式 AI 難以評估。舉例來說，您可能不知道基礎模型的訓練資料分布情形。您必須建立自訂評估資料集，反映所有用途，包括基本、平均和極端情況。與微調資料類似，您可以使用強大的 LLM 生成、管理及擴增資料，建構穩健的評估資料集。
評估
評估程序是開發生成式 AI 應用程式的核心活動。評估的自動化程度可能不同，從完全由人為驅動，到完全由程序自動化都有可能。
在製作專案原型時，評估通常是手動程序。開發人員會審查模型的輸出內容，從質性角度瞭解模型成效。但隨著專案成熟，測試案例數量增加，手動評估就會成為瓶頸。
自動評估有兩大優點：可加快速度，並提高評估的可靠性。此外，這項工具還能排除人為的主觀性，確保結果可重現。
但自動評估生成式 AI 應用程式時，會遇到一系列難題。舉例來說，你可以嘗試下列做法：
- 輸入內容 (提示) 和輸出內容都可能非常複雜。單一提示可能包含多項指令和限制，模型必須加以管理。輸出內容本身通常是高維度，例如生成的圖片或一段文字。很難用簡單的指標來評估這些輸出的品質。有些既有指標 (例如翻譯的 BLEU 和摘要的 ROUGE) 並非總是足夠。因此，您可以採用自訂評估方法或其他基礎模型來評估系統。舉例來說，您可以提示大型語言模型 (例如 AutoSxS)，針對各種層面評估生成文字的品質。
- 生成式 AI 的許多評估指標都是主觀的，哪一個輸出內容比較好，可能見仁見智。您必須確保自動評估與人工判斷一致，因為您希望指標能可靠地反映人們的想法。為確保實驗之間具有可比性，您必須在開發流程初期就決定評估方法和指標。
- 缺乏基本事實資料，尤其是在專案初期。其中一種解決方法是產生合成資料，做為暫時的實際資料，並隨著時間推移，根據人工回饋進行修正。
- 全面評估是保護生成式 AI 應用程式免受對抗攻擊的必要措施。惡意人士可能會精心設計提示，試圖擷取私密資訊或操縱模型的輸出內容。評估集必須透過提示模糊化 (向模型提供提示的隨機變體) 和資訊洩漏測試等技術，具體處理這些攻擊媒介。
如要評估生成式 AI 應用程式，請實作下列項目：
- 自動化評估程序，確保速度、可擴充性和可重現性。您可以將自動化視為人工判斷的替代方案。
- 視用途需要自訂評估程序。
- 為確保可比較性，請盡早在開發階段穩定評估方法、指標和實際資料。
- 產生合成真值資料，以因應缺乏真實真值資料的情況。
- 在評估集加入對抗提示的測試案例，測試系統本身抵禦這類攻擊的可靠性。
部署
正式版生成式 AI 應用程式是複雜的系統，包含許多互動式元件。如要將生成式 AI 應用程式部署到正式環境，您必須管理及協調這些元件，並與生成式 AI 應用程式開發的前幾個階段配合。舉例來說，單一應用程式可能會搭配使用多個 LLM 和資料庫，而這些 LLM 和資料庫都由動態資料管道提供資料。每個元件可能都需要自己的部署程序。
部署生成式 AI 應用程式與部署其他複雜軟體系統類似，因為您必須部署資料庫和 Python 應用程式等系統元件。建議您採用版本控管和 CI/CD 等標準軟體工程做法。
版本管控
生成式 AI 實驗是疊代程序，需要重複進行開發、評估和修改。為確保方法有條不紊且易於管理，您必須為所有可修改的元件實施嚴格的版本控管。這些元件的說明如下：
- 提示範本：除非使用特定提示管理解決方案，否則請使用版本控管工具追蹤版本。
- 鏈結定義：使用版本控管工具追蹤定義鏈結的程式碼版本 (包括 API 整合、資料庫呼叫和函式)。
- 外部資料集：在 RAG 系統中，外部資料集扮演重要角色。使用 BigQuery、AlloyDB for PostgreSQL 和 Vertex AI Feature Store 等現有資料分析解決方案，追蹤這些資料集的變更和版本。
- 適應器模型：適應器模型的 LoRA 調整等技術不斷演進。使用現有的資料儲存解決方案 (例如 Cloud Storage)，有效管理及版本化這些資產。
持續整合
在持續整合架構中，每項程式碼變更都會先經過自動測試，再合併以提早發現問題。單元測試和整合測試對於品質和穩定性至關重要。單元測試著重於個別程式碼片段，整合測試則會驗證不同元件是否能共同運作。
導入持續整合系統有助於：
- 確保輸出內容可靠且品質優良：嚴格的測試可提高對系統效能和一致性的信心。
- 及早發現錯誤：透過測試找出問題，避免問題在後續流程中造成更大的影響。及早發現錯誤可讓系統更強大，並能因應極端情況和預期外的輸入內容。
- 降低維護成本：妥善記錄的測試案例可簡化疑難排解程序，日後也能更順利地進行修改，進而減少整體維護工作。
這些優勢適用於生成式 AI 應用程式。對系統的所有元素套用持續整合，包括提示範本、鏈結、鏈結邏輯、任何內嵌模型和擷取系統。
不過，將持續整合套用至生成式 AI 時，會遇到下列挑戰：
- 難以生成全面的測試案例：生成式 AI 輸出內容複雜且開放式，因此難以定義及建立涵蓋所有可能性的詳盡測試案例。
- 重現性問題：生成模型通常具有內在隨機性，即使輸入內容相同，輸出結果也會有所差異，因此要取得確定性且可重現的結果並不容易。這種隨機性會導致難以持續測試預期行為。
這些挑戰與如何評估生成式 AI 應用程式這個更廣泛的問題密切相關。您可以在開發生成式 AI 的 CI 系統時，套用許多相同的評估技術。
持續推送軟體更新
程式碼合併後，持續推送軟體更新程序就會開始運作，將建構及測試完成的程式碼移至與實際工作環境相似的環境，進行進一步測試，然後再進行最終部署。
如「開發及實驗」一文所述，鏈結元素會成為部署的主要元件之一，因為這些元素從根本上構成了生成式 AI 應用程式。含有鏈結的生成式 AI 應用程式的傳送程序，可能會因延遲時間需求而異，也取決於用途是批次或線上。
批次用途需要部署批次程序，並在正式環境中依排程執行。在交付程序中，我們會先在類似於實際運作的環境中，測試整個整合管道，確認沒有問題後再進行部署。在測試過程中，開發人員可以針對批次程序本身的輸送量，聲明特定需求，並檢查應用程式的所有元件是否正常運作。(例如，開發人員可以檢查權限、基礎架構和程式碼依附元件)。
如要線上使用，您必須部署 API，也就是包含鏈結的應用程式，且能夠以低延遲時間回應使用者。您的交付程序包括在類似於實際工作環境的環境中，測試整合 API。這些測試會驗證應用程式的所有元件是否正常運作。您可以透過一系列測試 (包括負載測試)，驗證非功能性需求 (例如擴充性、可靠性和效能)。
部署檢查清單
下列清單說明使用 Vertex AI 等代管服務部署生成式 AI 應用程式時，應採取的步驟：
- 設定版本管控：為模型部署作業導入版本管控做法。如有需要，您可以使用版本控管功能還原至先前的版本，並追蹤模型或部署設定的變更。
- 將模型最佳化：在封裝或部署模型前，執行模型最佳化工作 (蒸餾、量化和修剪)。
- 將模型容器化：將訓練好的模型封裝到容器中。
- 定義目標硬體需求：確保目標部署環境符合模型最佳效能需求，例如 GPU、TPU 和其他專屬硬體加速器。
- 定義模型端點：指定模型容器、輸入格式、輸出格式和任何其他設定參數。
- 分配資源：根據預期流量和效能需求，為端點分配適當的運算資源。
- 設定存取控管：設定存取控管機制，根據驗證和授權政策限制端點存取權。存取控管可確保只有獲得授權的使用者或服務，才能與已部署的模型互動。
- 建立模型端點： 建立端點，將模型部署為 REST API 服務。用戶端可透過端點將要求傳送至端點，並接收模型的回應。
- 設定監控和記錄功能：設定監控和記錄系統，追蹤端點的效能、資源用量和錯誤記錄。
- 部署自訂整合功能：使用模型的 SDK 或 API，將模型整合至自訂應用程式或服務。
- 部署即時應用程式：建立串流管道，即時處理資料並產生回應。
記錄與監控
監控生成式 AI 應用程式及其元件時，需要使用一些技術，您可以將這些技術加入傳統機器學習運作程序所用的監控技術。您必須記錄及監控應用程式的端對端流程，包括記錄及監控應用程式和每個元件的整體輸入和輸出內容。
應用程式的輸入內容會觸發多個元件，產生輸出內容。如果特定輸入內容的輸出結果不正確，您必須判斷是哪個元件的效能不佳。您需要記錄所有已執行的元件的沿襲。您也必須將輸入內容和元件對應至依附的任何其他構件和參數，才能分析輸入內容和輸出內容。
套用監控功能時，請優先在應用程式層級進行監控。如果應用程式層級的監控結果顯示應用程式運作良好，就表示所有元件的運作狀況也良好。接著，對提示模型元件套用監控功能，取得更精細的結果，並進一步瞭解應用程式。
與 MLOps 中的傳統監控作業一樣，您必須部署警報程序，在偵測到偏移、偏差或效能衰退時，通知應用程式擁有者。如要設定快訊，您必須在監控程序中整合快訊和通知工具。
以下各節說明監控偏斜和漂移，以及持續評估工作。此外，MLOps 的監控功能還包括監控整體系統健康狀態的指標，例如資源使用率和延遲時間。這些效率指標也適用於生成式 AI 應用程式。
偏斜偵測
傳統機器學習系統中的偏差偵測是指訓練/應用偏差，當正式環境的特徵資料分布與模型訓練期間觀察到的特徵資料分布不同時，就會發生這種偏差。對於在串連的元件中使用預先訓練模型，以產生輸出的生成式 AI 應用程式，您也必須測量偏斜。您可以比較用於評估應用程式的輸入資料分配情形，以及應用程式在實際工作環境中的輸入分配情形，藉此評估偏斜程度。如果這兩個分布情形出現差異，您必須進一步調查。您也可以對輸出資料套用相同程序。
偏移偵測
與偏移偵測一樣，漂移偵測會檢查兩個資料集之間的統計差異。不過，漂移會尋找輸入資料的變化，而不是比較評估和服務輸入內容。「漂移」可評估輸入內容，進而瞭解使用者行為隨時間的變化。
由於應用程式的輸入內容通常是文字，因此您可以使用不同的方法來評估偏斜和漂移。一般來說，這些方法會嘗試找出與評估資料集相比，生產資料的重大變化，包括文字 (例如輸入大小) 和概念 (例如輸入主題)。所有這些方法都會尋找可能表示應用程式無法成功處理新資料性質的變更。常見方法包括：
- 計算嵌入和距離
- 計算文字長度和詞元數量
- 追蹤資料集中的詞彙變化、新概念和意圖、提示和主題
- 使用統計方法，例如最小平方密度差異 (PDF)、最大平均差異 (MMD)、學習到的核心 MMD (PDF) 或情境感知 MMD。
由於生成式 AI 的用途非常多元，您可能需要額外的自訂指標，以便更準確地掌握資料中的非預期變化。
持續評估
持續評估是另一種常見的生成式 AI 應用程式監控方法。在持續評估系統中，您會擷取模型的實際輸出內容，並使用該輸出內容執行評估工作，以便追蹤模型在不同時間點的成效。您可以直接收集使用者意見回饋，例如評分，即時瞭解使用者對輸出內容品質的看法。同時，將模型生成的回覆與既有真值進行比較，可深入分析成效。您可以透過人工評估收集實際資料，也可以採用整合式 AI 模型方法產生評估指標。這個程序會顯示評估指標的變化，從您開發模型時到目前在正式環境中使用的模型，都能一覽無遺。
管理
在 MLOps 領域中，控管涵蓋所有做法和政策，可針對機器學習模型的開發、部署和持續管理建立控管、問責和透明度，包括與程式碼、資料和模型生命週期相關的所有活動。
在預測型 AI 應用程式中，沿襲會著重於追蹤及瞭解機器學習模型的完整歷程。在生成式 AI 中，沿襲關係不僅限於模型構件，還會擴及鏈結中的所有元件。追蹤內容包括資料、模型、模型沿襲、程式碼，以及相關的評估資料和指標。譜系追蹤功能可協助您稽核、偵錯及改善模型。
除了這些新做法，您也可以使用標準 MLOps 和 DevOps 做法，控管資料生命週期和生成式 AI 元件生命週期。
後續步驟
作者：Anant Nawalgaria、Christos Aniftos、Elia Secchi、Gabriela Hernandez Larios、Mike Styer 和 Onofrio Petragallo