Generative AI 應用程式開發人員工作流程

開發強大的產生 AI 應用程式（Gen AI 應用程式）需要刻意規劃、快速開發意見反應評估迴圈，以及可調整的生產基礎結構。 此工作流程概述建議的步驟順序，以引導您從初始概念證明 （POC） 到生產環境部署。

0。必要條件

• 收集需求，以驗證生成式人工智慧的適用性並識別限制條件。
• 設計您的解決方案架構。 請參閱 代理程式系統設計模式

1.組建

• 準備數據源並建立必要的工具。
• 建置和驗證初始原型 （POC）。
• 部署至預備生產環境。

2.評估 & 重複執行

• 收集用戶意見反應和測量品質
• 根據評估來精簡代理程式邏輯和工具，以修正質量問題。
• 納入主題專家（SME）的意見，持續提升代理系統的品質。

3.生產

• 將 Gen AI 應用程式部署至生產環境。
• 監視效能和品質。
• 根據真實世界的使用量來維護和改善。

此工作流程應該是反覆的：在每個部署或評估周期之後，返回先前的步驟來精簡數據管線或更新代理程序邏輯。 例如，生產監視可能會顯示新的需求、觸發代理程序設計的更新，以及另一輪評估。 透過系統地遵循這些步驟並運用 Databricks MLflow 追蹤、代理程式架構和代理程式評估功能，您可以建置能可靠地符合使用者需求、尊重安全性和合規性需求的高品質 GEN AI 應用程式，並持續改善一段時間。

0。先決條件

在開始開發生成 AI 應用程式之前，強調以下工作的重要性再多也不為過：收集需求和設計解決方案。花時間妥善執行這些步驟是至關重要的。

收集需求 包含下列步驟：

• 驗證 Gen AI 是否符合您的使用案例。
• 定義用戶體驗。
• 界定數據源的範圍。
• 設定效能條件約束。
• 擷取安全限制。

解決方案設計 包含下列項目：

• 規劃數據管線。
• 識別必要的工具。
• 概述整體系統架構。

藉由奠定此基礎，您可以為後續的建置、評估，以及生產 階段設定明確的方向。

收集需求

定義清楚且全面的使用案例需求，是開發成功 Gen AI 應用程式的重要第一步。 這些需求符合下列目的：

• 它們可協助您判斷 Gen AI 方法是否適合您的使用案例。
• 他們會引導解決方案設計、實作和評估決策。

在開始收集詳細需求時，投資時間可防止開發程式稍後的重大挑戰，並確保產生的解決方案符合終端使用者和項目關係人的需求。 定義完善的需求為應用程式生命週期的後續階段提供基礎。

使用案例適合 Gen AI 嗎？

在認可 Gen AI 解決方案之前，請考慮其固有優勢是否符合您的需求。 有一些例子，其中生成式 AI 解決方案非常適合，包括：

• 內容產生： 工作需要產生無法透過靜態範本或簡單規則型邏輯達成的新穎或創意內容。
• 動態查詢處理： 用戶查詢是開放式或複雜且需要彈性、內容感知回應。
• 資訊合成： 使用案例的優點是結合或摘要各種資訊來源，以產生一致的輸出。
• 代理程式系統： 應用程式不僅需要產生文字以回應提示。 它可能需要能夠：
  • 規劃和決策： 制定多步驟策略以達成特定目標。
  • 採取動作： 觸發外部進程或呼叫各種工具來執行工作（例如，擷取數據、進行 API 呼叫、執行 SQL 查詢、執行程式代碼）。
  • 維護狀態： 追蹤多個互動之間的交談歷程記錄或工作內容，以確保連續性。
  • 產生調適性輸出： 根據先前的動作、更新的信息或變更條件而演變的回應。

相反地，在下列情況下，Gen AI 方法可能不理想：

• 此工作具有高度決定性，且可透過預先定義的範本或規則型系統有效地解決。
• 整組必要資訊已經是靜態的，或適合在簡單、封閉的架構內。
• 需要極低延遲（毫秒）的回應，而且無法容納產生處理的額外負荷。
• 簡單的樣板化回應就足以用於預定的使用案例。

重要

下列各節使用標籤 P0、P1和 P2 來指出相對優先順序。

• 🟢 [P0] 項目是關鍵或必要的。 這些必須立即解決。
• 🟡 [P1] 項目非常重要，但可以在 P0 需求之後進行。
• ⚪ [P2] 項目是優先順序較低的考慮或增強功能，將視時間和資源的情況來處理。

這些標籤可協助小組快速查看哪些需求需要立即注意，以及可延遲的需求。

用戶體驗

定義使用者如何與 Gen AI 應用程式互動，以及預期的回應類型。

• 🟢 [P0] 一般要求： 一般使用者要求看起來會是什麼樣子？ 從項目關係人收集範例。
• 🟢 [P0] 預期的回應： 系統應該產生哪種類型的回應（例如簡短答案、長格式說明、創意敘事）？
• 🟡 [P1] 互動方式： 使用者如何與應用程式互動（例如聊天介面、搜尋列、語音助理）？
• 🟡 [P1] 語氣、樣式、結構： 產生的輸出應該採用什麼語氣、風格和結構（正式、交談、技術、專案符號或連續散文）？
• 🟡 [P1]錯誤處理： 應用程式如何處理模棱兩可、不完整或非目標查詢？ 它應該提供意見反應或要求釐清嗎？
• ⚪ [P2] 格式需求： 輸出是否有任何特定的格式或簡報指導方針（包括元數據或補充資訊）？

數據

判斷將在 Gen AI 應用程式中使用之數據的本質、來源和品質。

• 🟢 [P0] 數據源： 有哪些數據源可供使用？
  • 針對每個來源，判斷：
    • 數據是結構化還是非結構化？
    • 來源格式為何（例如 PDF、HTML、JSON、XML）？
    • 數據位於何處？
    • 有多少數據可用？
    • 應該如何存取數據？
• 🟡 [P1] 數據更新： 數據更新的頻率為何？ 處理更新有哪些機制？
• 🟡 [P1] 數據品質： 是否有已知的質量問題或不一致？
  • 請考慮是否需要對數據源進行任何質量監視。

請考慮建立清查數據表來合併這項資訊，例如：

數據源	源	檔案類型	大小	更新頻率
數據源 1	Unity 目錄卷	JSON（JavaScript物件標記法）	10GB	日常
數據源 2	公用 API	XML	NA （API）	即時
數據源 3	SharePoint	PDF、.docx	500MB	每月

效能限制條件

擷取 Gen AI 應用程式的效能和資源需求。

延遲

• 🟢 [P0] 時間到第一個令牌： 傳遞輸出第一個令牌之前可接受的延遲上限為何？
  • 注意： 延遲通常是使用 p50 （中位數） 和 p95 （第 95 個百分位數） 來擷取平均和最差的效能。
• 🟢 [P0] 完成時間： 用戶可接受的 （完成時間） 回應時間為何？
• 🟢 [P0] 串流延遲： 如果串流回應，是否可以接受較高的整體延遲？

延展性

• 🟡 [P1]並行使用者 & 要求： 系統應該支援多少同時使用者或要求？
  • 注意：延展性通常以 QPS（每秒查詢數）或 QPM（每分鐘查詢數）來測量。
• 🟡 [P1] 使用模式： 預期的流量模式、尖峰負載或以時間為基礎的尖峰預期情況如何？

成本條件約束

• 🟢 [P0] 推斷成本限制： 推斷計算資源的成本限制或預算限制為何？

評估

確定如何隨著時間的推移評估和改進 Gen AI 應用程式。

• 🟢 [P0] 商務 KPI：應用程式應該影響哪些商務目標或 KPI？ 定義您的基準值和目標。
• 🟢 [P0] 專案關係人意見反應：誰將提供應用程式效能和輸出的初始和持續意見反應？ 識別特定使用者群組或網域專家。
• 🟢 [P0] 測量品質：將使用哪些計量（例如精確度、相關性、安全性、人類分數）來評估產生的輸出品質？
  • 開發期間會如何計算這些計量（例如，針對綜合數據、手動策劃的數據集）？
  • 如何在生產環境中測量品質（例如記錄和分析對實際使用者查詢的回應）？
  • 您的錯誤整體承受度為何？ （例如，接受一定百分比的次要事實錯誤，或要求在關鍵使用案例中達到接近100%或%等級的正確性。）
  • 其目標是從實際使用者查詢、合成數據或兩者的組合，建立一個評估集。 此集合提供一致的方式來評估系統發展時效能。
• 🟡 [P1] 意見反應迴圈：如何收集使用者意見反應（例如向上/向下拇指、問卷窗體），以及用來推動反覆改善？
  • 規劃檢閱並納入意見反應的頻率。

安全

識別任何安全性和隱私權考量。

• 🟢 [P0] 數據敏感度： 是否有需要特殊處理的敏感性或機密數據元素？
• 🟡 [P1] 訪問控制： 您需要實作訪問控制來限制特定數據或功能嗎？
• 🟡 [P1] 威脅評估 & 緩解： 您的應用程式是否需要防範常見的生成式 AI 威脅，例如提示插入或惡意使用者輸入？

部署

瞭解 Gen AI 解決方案如何整合、部署、監視和維護。

• 🟡 [P1] 整合： Gen AI 解決方案應該如何與現有的系統和工作流程整合？
  • 識別整合點（例如 Slack、CRM、BI 工具）和必要的數據連接器。
  • 判斷要求和回應在 Gen AI 應用程式和下游系統之間流動的方式（例如 REST API、Webhook）。
• 🟡 [P1] 部署： 部署、調整和版本設定應用程式的需求為何？ 本文涵蓋如何使用 MLflow、Unity 目錄、Agent Framework、代理程式評估和模型服務，在 Databricks 上處理端對端生命週期。
• 🟡 [P1] 生產監視 & 可檢視性： 一旦應用程式處於生產環境中，該如何監視應用程式？
  • 記錄 & 追蹤：取得完整執行追蹤。
  • 品質計量：持續評估即時流量的關鍵計量（例如正確性、延遲、相關性）。
  • 警示 & 儀錶板：設定關鍵問題的警示。
  • 意見反應迴圈：在生產環境中納入使用者意見反應（向上或向下拇指），以儘早捕捉問題並推動反覆改善。

例

例如，請考慮這些考慮和需求如何套用至 Databricks 客戶支援小組所使用的假設代理 RAG 應用程式：

面積	考量因素	要求
用戶體驗	互動方式。 一般用戶查詢範例。 預期的回應格式和樣式。 處理模棱兩可或無關的查詢。	與 Slack 整合的聊天介面。 範例查詢：「如何減少叢集啟動時間？「我有什麼樣的支持計劃？ 清晰的技術回應，其中包含代碼段，並在適合的地方提供相關文件的連結。 視需要提供內容建議，並升級給支援工程師。
代理程序邏輯	查詢理解與分類。 多步驟規劃和決策。 自主工具選取和執行。 跨互動的狀態和上下文管理。 錯誤處理和後援機制。	支援 LLM 的具有決定性備援方案的規劃。 與一組預先定義的工具整合（例如文件擷取工具或 Salesforce 擷取工具）。 維持對話狀態以確保多回合互動的連貫性並強化錯誤復原能力。
數據	數據源的數目和類型。 數據格式和位置。 數據大小和更新頻率。 數據品質與一致性。	四個數據源。 公司檔（HTML、PDF）。 已解決的支援票證（JSON）。 社群論壇文章（Delta 表格）。 Salesforce 連接器。 儲存在 Unity 目錄的數據，每周更新一次。 數據大小總計：5GB。 由專職文件與支援團隊維護的資料結構和品質的一致性。
性能	可接受的延遲上限。 成本限制。 預期用法和並行使用。	延遲需求上限。 成本限制。 預期的尖峰負載。
評估	評估數據集可用性。 品質計量。 用戶意見反應收集。	來自每個產品領域的主題專家可協助檢閱輸出，並調整不正確的答案來建立評估數據集。 商務 KPI。 提高客服工單解決率。 減少用戶在每個支援票證上花費的時間。 品質計量。 由 LLM 判斷的答案正確性和相關性。 LLM 評估擷取精確度。 使用者按讚或反對。 意見反應集合。 Slack 將會被配置，以提供贊/踩功能。
安全	敏感數據處理。 訪問控制需求。	擷取來源中不應有機密客戶數據。 透過 Databricks Community SSO 進行用戶驗證。
部署	與現有系統整合。 部署和版本控制。	與支援票證系統整合。 作為 Databricks 模型服務端點部署的代理程式。

解決方案設計

如需其他設計考慮，請參閱 代理程式系統設計模式。

數據來源 & 工具

設計 Gen AI 應用程式時，請務必識別並對應驅動解決方案所需的各種數據源和工具。 這可能涉及結構化數據集、非結構化數據處理管線，或查詢外部 API。 以下是在 Gen AI 應用程式中納入不同資料來源或工具的建議方法：

結構化數據

結構化數據通常位於定義完善的表格式格式（例如 Delta 數據表或 CSV 檔案）中，適合用來根據使用者輸入動態產生查詢的工作。 如需將結構化數據新增至 Gen AI 應用程式的建議，請參閱 結構化擷取 AI 代理程式工具。

非結構化數據

非結構化數據報含未經處理的檔、PDF、電子郵件、影像和其他不符合固定架構的格式。 這類數據需要額外的處理，通常是透過剖析、區塊化和內嵌的組合，在 Gen AI 應用程式中有效地查詢和使用。 如需將結構化數據新增至 Gen AI 應用程式的建議，請參閱 用於非結構化數據的建置和追蹤擷取工具。

外部 API & 動作

在某些情況下，您的 Gen AI 應用程式可能需要與外部系統互動，以擷取數據或執行動作。 如果您的應用程式需要叫用工具或與外部 API 互動，我們建議下列事項：

• 使用 Unity 類別目錄連線管理 API 認證： 使用 Unity 目錄連線安全地控管 API 認證。 此方法可確保令牌和秘密會集中管理和存取控制。
• 透過 Databricks SDK呼叫：
  使用來自 http_request 連結庫的 databricks-sdk 函式，將 HTTP 要求傳送至外部服務。 此函式會利用 Unity 目錄連線進行驗證，並支援標準 HTTP 方法。
• 活用 Unity Catalog 函數：
  在 Unity Catalog 函式中包裝外部連線，以新增自定義前置或後置處理邏輯。
• Python 執行程式工具：
  若要使用 Python 函式動態執行資料轉換或 API 互動的程式代碼，請使用內建的 Python 執行程式工具。

範例：

內部分析應用程式會從外部財務 API 擷取即時市場數據。 應用程式會使用：

• Unity 目錄外部連線 安全地儲存 API 認證。
• 自定義 Unity Catalog 函式 包裝 API 呼叫，以新增前置處理（例如數據正規化）和後續處理（例如錯誤處理）。
• 此外，應用程式可以直接 透過 Databricks SDK調用 API。

實作方法

開發 Gen AI 應用程式時，您有兩個主要選項可實作代理程式的邏輯：利用開放原始碼架構或使用 Python 程式代碼建置自定義解決方案。 以下是每個方法的優缺點細目。

使用架構 （例如 LangChain、LlamaIndex、CrewAI 或 AutoGen）

專業人員：

• 現成的元件： 架構隨附現成的工具，可用於提示管理、鏈結呼叫，以及與各種數據源整合，以加速開發。
• 社群和文件： 受益於社群支援、教學課程和定期更新。
• 常見設計模式： 架構通常會提供清楚、模組化的結構來協調一般工作，以簡化整體代理程序設計。

缺點：

• 新增抽象概念： 開放原始碼架構通常會引進一層抽象概念，而您的特定使用案例可能不需要。
• 更新相依性： 您可能依賴架構維護人員進行錯誤修正和功能更新，這可能會減緩快速適應新需求的能力。
• 潛在的額外負荷：如果您的應用程式需要更精細的控制， 額外的抽象化可能會導致自定義挑戰。

使用純 Python

專業人員：

• 彈性：在純 Python 中開發 可讓您完全根據需求量身打造實作，而不受架構設計決策的限制。
• 快速調整： 您可以快速調整程式代碼，並視需要併入變更，而不需要等候外部架構的更新。
• 簡單： 避免不必要的抽象層，這可能會導致更精簡、效能更高的解決方案。

缺點：

• 增加開發工作： 從頭建置可能需要更多時間和專業知識，才能實作專用架構可能提供的功能。
• 重新發明輪子： 您可能需要自行開發一些常見的功能（例如工具串接或提示管理）。
• 維護責任： 所有更新和錯誤修正都會成為您的責任，這對複雜的系統來說可能很困難。

最後，您的決策應以您專案的複雜度、效能需求和所需的控制層級為指導。 這兩種方法本質上都不是優越的;每個都會根據您的開發喜好設定和策略優先順序，提供不同的優點。

1，建置

在這個階段中，您會將解決方案設計轉換成運作中的 Gen AI 應用程式。 與其提前完善所有專案，不如從最小的概念證明（POC）開始，可以快速測試。 這可讓您儘快部署到生產階段前環境、收集實際使用者或中小企業的代表查詢，並根據真實世界的意見反應進行精簡。

建置程式會遵循下列重要步驟：

一個。 準備數據 & 工具： 確定必要數據可供存取、剖析及準備擷取。 實作或註冊代理程式所需的 Unity Catalog 函數和連接（例如，資料擷取 API 或外部 API 呼叫）。 b。 建置代理程式： 從簡單的POC方法開始協調核心邏輯。 丙. 質量檢查： 向更多使用者公開應用程式之前驗證基本功能。 d。 部署生產前代理程式： 讓POC可供測試用戶和主題專家以取得初始意見反應。 ｅ。 收集使用者意見反應： 使用真實世界的使用來識別改進區域、所需的額外數據或工具，以及下一個迭代的潛在改進。

一個。 準備 & 資料工具

從解決方案設計階段，您將初步瞭解應用程式所需的數據源和工具。 在這個階段，請將其保持最少：專注於足以驗證 POC 的數據。 這確保了快速迭代，而無需對複雜流程進行大量前期投資。

數據

1. 識別代表性的數據子集
   • 針對 結構化數據，請選取與您初始案例最相關的關鍵表格或欄位。
   • 針對 非結構化數據，優先考慮索引具代表性的文件。 使用基本區塊化/內嵌管線搭配 馬賽克 AI 向量搜尋，讓您的代理程序視需要擷取相關的文字區塊。
2. 設定數據存取
   • 如果您需要您的應用程式進行外部 API 呼叫，請使用 Unity 目錄連線安全地儲存認證。
3. 驗證基本涵蓋範圍
   • 確認所選的數據子集已充分解決您計劃測試的用戶查詢。
   • 儲存任何其他數據源或複雜的轉換，以供日後反覆專案使用。 您目前的目標應該是證明基本可行性並收集意見反應。

工具

設定數據源后，下一個步驟是實作和註冊代理程式將在運行時間呼叫的工具至 Unity 目錄。 工具是 單一互動函式，例如 SQL 查詢或外部 API 呼叫，代理程式可以叫用以擷取、轉換或動作。

數據擷取工具

• 限制式結構化數據查詢： 如果已修正查詢，請將查詢包裝在 Unity 目錄 SQL 函式或 Python UDF中。 這會讓邏輯保持集中且可探索。
• 開放式結構化數據查詢： 如果查詢更開放，請考慮設定 Genie 空間 來處理文字到 SQL 查詢。
• 非結構化數據協助程式函式： 針對儲存在馬賽克 AI 向量搜尋中的非結構化數據，建立非結構化數據擷取工具， 代理程式可以呼叫以擷取相關的文字區塊。

API 呼叫工具

• 外部 API 呼叫：。
• 選擇性包裝函式： 如果您需要實作前置或後置處理邏輯（例如數據正規化或錯誤處理），請將 API 呼叫包裝在 Unity Catalog 函式中。

保持簡約

• 僅從基本工具開始： 專注於單一擷取路徑或一組有限的 API 呼叫。 您可以在反覆操作時新增更多內容。
• 以互動方式驗證： 在將工具併入代理程序系統之前，先獨立測試每個工具（例如，在筆記本中）。

準備好原型工具之後，請繼續建置代理程式。 代理程式會協調這些工具來回應查詢、擷取數據，並視需要執行動作。

b。 組建代理程式

在您的資料和工具就緒之後，您可以建置代理程式來回應傳入要求，例如用戶查詢。 若要建立初始原型代理程式，請使用 Python 或 AI 遊樂場。 請遵循下列步驟：

1. 從簡單開始
   • 挑選基本設計模式： 針對 POC，請從基本鏈結（例如固定步驟序列）或單一工具呼叫代理程式（LLM 可以動態呼叫一或兩個基本工具）開始。
     • 如果您的情境符合 Databricks 文件中提供的其中一個範例筆記本，請將該程式碼作為模板進行調整。
   • 最小提示： 抵制此時過度工程師提示的衝動。 保持指示簡潔且與初始工作直接相關。
2. 併入工具
   • 工具整合： 如果使用鏈結設計模式，呼叫每個工具的步驟將會硬式編碼。 在工具呼叫代理程式中，您 提供架構，讓 LLM 知道如何叫用函式。
     • 先驗證隔離中的工具是否如預期般執行，再將它們併入代理程序系統，並測試端對端。
   • 護欄： 如果您的代理程式可以修改外部系統或執行程式碼，請確定您有基本的安全檢查和護欄（例如限制呼叫數目或限制特定動作）。 在 Unity Catalog 的函式中實作這些功能。
3. 使用 MLflow 追蹤並記錄代理程式
   • 追蹤每個步驟： 使用 MLflow 追蹤 來擷取每個步驟的輸入、輸出和經過的時間，以偵錯問題和測量效能。
   • 記錄代理程式： 使用 MLflow 追蹤 來記錄代理程式的程式代碼和組態。

在這個階段，完美不是的目標。 您想要一個簡單且正常運行的代理程式，您可以將其部署給測試使用者和專家以獲得早期反饋。 下一個步驟是在使其在預生產環境中可用之前進行快速質量檢查。

丙. 質量檢查

在將代理公開給更廣泛的預生產受眾之前，請先執行離線「足夠好」的品質檢查，以在將其部署到端點之前查找任何重大問題。 在這個階段，您通常不會有大型且健全的評估數據集，但您仍然可以執行快速傳遞，以確保代理程式在少數範例查詢上的行為如預期般運作。

1. 在筆記本中以互動方式測試
   • 手動檢查： 使用具代表性的請求手動呼叫您的代理人。 請注意它是否擷取正確的數據、正確呼叫工具，並遵循所需的格式。
   • 檢查 MLflow 追蹤功能：如果您已啟用 MLflow 追蹤功能，請檢閱逐步檢視的遙測數據。 確認代理程式會挑選適當的工具、正常處理錯誤，而且不會產生非預期的中繼要求或結果。
   • 檢查延遲： 記下每個要求執行所花費的時間長度。 如果回應時間或令牌使用量過高，您可能需要修剪步驟或簡化邏輯再繼續進行。
2. 氛圍檢測
   • 這可以在筆記本或 「AI 遊樂場」中完成。
   • 一致性 & 正確性： 代理程序的輸出對您所測試的查詢是否有意義？ 是否有明顯的不透明度或遺漏詳細數據？
   • 邊緣案例： 如果您嘗試了一些非傳統查詢，代理是否仍以邏輯方式回應或失敗後至少合乎禮節地回應（例如，禮貌地拒絕回答而不是產生無意義的回應）？
   • 提示遵循： 如果您提供高階的指示，例如所需的音調或格式設定，代理程式是否遵循這些？
3. 評估「足夠好」的品質
   • 如果您目前受限於測試查詢，請考慮產生綜合數據。 請參閱 建立評估集。
   • 解決主要問題： 如果您發現重大缺陷（例如，代理程式重複呼叫無效的工具或輸出無稽之談），請先修正這些問題，再向更廣泛的對象公開這些問題。 請參閱 常見的質量問題，以及如何加以修正。
   • 決定可行性： 如果系統代理符合一小部分查詢的基本可用性和正確性標準，您可以繼續。 如果沒有，請精簡提示、修正工具或數據問題，然後重新測試。
4. 規劃後續步驟
   • 追蹤改善： 記錄您決定延後的任何缺點。 在生產階段前收集真實世界的意見反應之後，您可以重新檢視這些項目。

如果一切看起來都適合有限度的發佈，您就可以將代理程式部署至預生產環境。 在後續階段會進行徹底的評估流程，尤其是在您擁有更真實的數據、SME意見反饋和結構化評估集之後。 目前，請專注於確保代理程式可靠地示範其核心功能。

d。 部署生產前代理程式

代理程式符合基準品質閾值之後，下一個步驟是在生產階段前環境中裝載它，以便了解使用者如何查詢應用程式並收集其意見反應來引導開發。 此環境可以是您在POC階段的開發環境。 主要需求是環境可供選取內部測試人員或領域專家存取。

1. 部署代理程式
   • 記錄和註冊代理程式： 首先，將代理程式 記錄為 MLflow 模型，並在 Unity 目錄中 註冊 代理程式。
   • 使用 Agent Framework 部署： 使用 Agent Framework 來取得已註冊的代理程式，並 將它部署為模型服務端點。
2. 推斷數據表
   • Agent Framework 會自動將要求、回應以及追蹤與元數據一起，儲存在 Unity 目錄中每個服務端點的 推斷數據表 中。
3. 確保安全並配置
   • 訪問控制：限制端點存取 至您的測試群組（SME、進階使用者）。 這可確保受控制的使用量，並避免非預期的數據暴露。
   • 驗證： 確認已正確設定任何必要的秘密、API 令牌或資料庫連線。

您現在有一個受控環境，可收集真實查詢的意見反應。 您可以快速與代理程式互動的其中一種方式是 AI 遊樂場，您可以在其中選取新建立的模型服務端點並查詢代理程式。

ｅ。 收集用戶意見反應

將代理程式部署至生產階段前環境之後，下一個步驟是收集真實使用者和中小企業的意見反應，以找出差距、找出不準確之處，並進一步精簡您的代理程式。

1. 使用檢閱應用程式

   • 當您使用 Agent Framework 部署代理程式時，會建立簡單的聊天樣式 檢閱應用程式。 它提供使用者易記的介面，讓測試人員可以提出問題，並立即對代理程式的回應進行評分。
   • 所有要求、回應和使用者意見反應（向上/向下、書面批注）都會自動記錄到 推斷數據表，以便稍後分析。

2. 使用監視UI來檢查記錄

   • 在監視 UI中追蹤贊成票/反對票或文字回饋，以查看哪些回應對測試人員特別有幫助（或無幫助）。

3. 吸引領域專家

   • 鼓勵中小企業經歷典型和不尋常的案例。 領域知識可協助呈現細微錯誤，例如原則錯誤解譯或遺漏數據。
   • 請保留問題的待辦清單，其中包括從次要的提示調整到更大規模的數據管線重構。 決定在繼續之前要優先處理哪些修正。

4. 編製新的評估數據

   • 將值得注意或有問題的互動轉換成測試案例。 經過一段時間，這些會形成更健全評估數據集的基礎。
   • 可能的話，請在這些案例中新增正確或預期的答案。 這有助於在後續評估週期中測量品質。

5. 根據反饋進行反覆改進

   • 套用快速解決方案，例如小幅度的提示變更或新設的控制措施，以解決當前的痛點。
   • 如需更複雜的問題，例如需要進階的多步驟邏輯或新的數據源，請先收集足夠的辨識項，再投資主要架構變更。

藉由利用審核應用程式、推理表格記錄和 SME 洞察的意見反應，此生產前階段有助於顯示關鍵差距，並反覆優化您的代理。 此步驟中收集的實際互動會建立建置結構化評估集的基礎，讓您從臨機作改進轉換到更系統化的質量測量方法。 解決週期性問題並穩定效能之後，您便已做好備妥生產部署的準備，並備妥強固的評估。

2。評估 & 重複改進

在生產前環境中測試您的 Gen AI 應用程式之後，下一個步驟是有系統地測量、診斷和精簡其品質。 這個「評估和反覆執行」階段會將原始意見反應和記錄轉換成結構化評估集，讓您能夠重複測試改進，並確保您的應用程式符合正確性、相關性和安全性所需的標準。

此階段包含下列步驟：

• 從記錄收集實際查詢： 將推斷數據表的高價值或有問題的互動轉換成測試案例。
• 新增專家標籤： 盡可能將真實標準或風格和政策指導方針附加到這些案例，以便更客觀地測量正確性、穩固性和其他質量維度。
• 利用 代理程式評估： 使用內建 LLM 評量或自定義檢查來量化應用程式品質。
• 反覆檢閱： 透過改進代理程式的邏輯、數據管道或提示來提升品質。 重新執行評估，以確認您是否已解決關鍵問題。

請注意，即使您的生成式 AI 應用程式在 Databricks 外部執行，這些功能仍可運作，。 藉由使用 MLflow 追蹤來檢測程式代碼，您可以從任何環境擷取追蹤，並將其統一在 Databricks Data Intelligence Platform 中，以進行一致的評估和監視。 當您繼續納入新的查詢、意見反應和 SME 深入解析時，您的評估數據集會成為一種活生生的資源，可支撐持續改善週期，確保您的 Gen AI 應用程式保持健全、可靠且符合商務目標。

一個。 評估代理人

在您的代理程式在預生產環境中運行後，下一步是有系統地測量其效能，而不只是進行隨意檢查。 Mosaic AI 代理程式評估 可讓您建立評估集，使用內建或自定義的 LLM 評審進行品質檢查，並快速迭代改善問題區域。

離線和線上評估

評估 Gen AI 應用程式時，有兩個主要方法：離線評估和在線評估。 開發週期的這個階段著重於離線評估，這是指即時用戶互動以外的系統評估。 稍後討論在生產環境中監視代理程式時，會討論在線評估。

團隊通常長時間過於依賴開發人員工作流程中的「氛圍測試」， 非正式地嘗試一些查詢，並主觀判斷回應是否合理。 雖然這提供了起點，但它缺乏建置生產品質應用程式所需的嚴謹性和涵蓋範圍。

相反地，適當的離線評估程式會執行下列動作：

• 在更廣泛的部署之前建立品質基準，建立明確的計量以取得改善的目標。
• 識別需要注意的特定弱點，超出僅測試預期使用案例的限制。
• 偵測質量退化，藉由自動比較版本之間的效能來優化您的應用程式。
• 提供量化指標，以證明對利害關係人的改善。
• 協助在使用者之前探索邊緣案例 和潛在的失敗模式。
• 降低將效能不佳的代理程式部署到生產環境的風險。

投資時間在離線評估上，從長遠來看能帶來顯著的收益，幫助您持續提供高質量的回應。

建立評估集

評估集可作為測量 Gen AI 應用程式效能的基礎。 類似於傳統軟體開發中的測試套件，此代表性查詢和預期回應集合會成為您的品質基準檢驗和回歸測試數據集。

您可以透過數種互補方法來建置評估集：

1. 將推斷數據表記錄轉換成評估範例

   最有價值的評估數據直接來自實際使用方式。 您的預生產部署已產生推斷表格日誌，其中包含請求、代理回應、工具調用和擷取的上下文。

   將這些記錄轉換成評估集提供數個優點：

   • 真實世界涵蓋範圍： 您可能未預期的使用者行為包含在內。
   • 問題聚焦： 您可以特別篩選負面回饋或回應緩慢的情況。
   • 代表分佈： 擷取不同查詢類型的實際頻率。

2. 產生綜合評估數據

   如果您沒有一組策劃的使用者查詢，您可以 自動產生綜合評估資料集。 此「入門查詢集」可協助您快速評估代理：

   • 傳回一致、準確的答案。
   • 以正確的格式回應。
   • 尊重結構、語氣和政策指導方針。
   • 正確檢索上下文（適用於RAG）。

   綜合數據通常並不完美。 把它想像成一塊臨時的墊腳石。 您也會想要：

   • 讓中小企業或領域專家檢閱並修剪任何無關或重複的查詢。
   • 之後以現實世界的使用日誌來取代或增強。

3. 手動整理查詢

   如果您不想依賴綜合數據，或還沒有推斷記錄，請識別 10 到 15 個實際或代表性的查詢，並從這些查詢建立評估集。 代表查詢可能來自使用者面試或開發人員腦力激蕩。 即使是簡短的精心挑選列表，也會揭露客服人員回應中的明顯缺陷。

這些方法不是互斥的，而是互補的。 有效的評估集會隨著時間演進，通常會結合來自多個來源的範例，包括下列各項：

• 從手動策劃的範例開始，以測試核心功能。
• 您可以選擇性地新增綜合數據，以擴大涵蓋範圍，然後才有真正的用戶數據。
• 逐漸納入實際記錄，當它們變得可用時。
• 不斷以反映使用模式變更的新範例進行更新。

評估查詢的最佳做法

製作評估集時，請刻意包含各種不同的查詢類型，如下所示：

• 預期和非預期的使用模式（例如非常長或短的要求）。
• 潛在的誤用嘗試或提示注入攻擊（例如嘗試揭露系統提示）。
• 需要多個推理步驟或工具呼叫的複雜查詢。
• 具有最少或模棱兩可信息的邊緣案例（例如拼字錯誤或模糊查詢）。
• 代表不同使用者技能層級和背景的範例。
• 在回應中測試潛在偏差的查詢（例如「比較公司 A 與公司 B」）。

請記住，您的評估集應該隨著您的應用程式成長和發展。 當您發現新的失敗模式或用戶行為時，請新增代表性範例，以確保您的代理程式在這些區域中會持續改善。

新增評估準則

每個評估範例都應該有評估品質的準則。 這些準則可作為測量代理程式響應的標準，以跨多個品質維度進行客觀評估。

基本真相事實或參考答案

評估事實精確度時，有兩個主要方法：預期的事實或參考答案。 每個都會在您的評估策略中提供不同的用途。

使用預期的事實 （建議）

expected_facts 方法牽涉到列出應該出現在正確回應中的重要事實。 如需範例，請參閱 使用 request、response、guidelines和 expected_facts的範例評估集。

此方法提供顯著優勢：

• 允許彈性地在回應中表達事實的方式。
• 使中小企業更容易提供正確數據。
• 在確保核心資訊存在時，容納不同的響應樣式。
• 提供更可靠的評估，適用於不同的模型版本或參數設定。

內建的正確性判斷會檢查代理的回應是否包含這些基本事實，無論措詞、順序或其他內容如何。

使用預期的回應（作為替代方案）

或者，您也可以 提供完整的參考答案。 在下列情況下，此方法最適用：

• 您有專家制定的優質答案。
• 回應的確切措辭或結構很重要。
• 您正在評估在嚴格管制的環境中的回應。

Databricks 通常建議使用 expected_facts 超過 expected_response，因為它提供更大的彈性，同時仍然確保精確度。

樣式、語氣或政策合規性的指導方針

除了事實精確度之外，您可能需要評估回應是否符合特定樣式、語氣或原則需求。

僅限指導方針

如果您的主要考量是強制執行風格或政策要求，而不是事實準確性，您可以在不涉及事實的情況下提供指導方針：

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

LLM 法官的指導方針會解釋這些自然語言指示，並評估回應是否符合這些指示。 這特別適用於主觀品質維度，例如語氣、格式設定和遵守組織原則。

結合標準數據和指導原則

為了進行全面的評估，您可以結合事實精確度檢查與風格指導原則。 請參閱 使用 request、response、guidelines和 expected_facts的範例評估集。 這種方法可確保回應確實正確且符合組織的通訊標準。

使用預先擷取的回應

如果您已經從開發或測試擷取要求-回應組，您可以直接評估它們，而不需重新叫用代理程式。 這適用於：

• 分析代理人行為中的現有模式。
• 對舊版本的效能表現進行基準測試。
• 藉由不重新產生回應來節省時間和成本。
• 評估在 Databricks 平台外部運行的代理程式。

如需在評估 DataFrame 中提供相關欄位的詳細資訊，請參閱 範例：如何將先前產生的輸出傳遞至代理評估。 馬賽克 AI 代理程式評估會使用這些預先擷取的值，而不是再次呼叫您的代理程式，同時仍套用相同的品質檢查和計量。

評估準則的最佳做法

定義評估準則時：

1. 明確且客觀： 定義不同的評估者會以類似方式解釋的清晰、可測量的準則。
   • 請考慮新增自定義計量來測量您關心的品質準則。
2. 專注在使用者值上： 設定符合使用者最重要事項的優先順序準則。
3. 開始簡單： 開始使用一組核心準則，並隨著您對品質需求的理解而擴大。
4. 平衡涵蓋範圍： 包括處理不同品質層面的準則（例如事實精確度、風格和安全）。
5. 根據意見反應不斷改進： 根據使用者意見反應和不斷演進的需求完善您的準則。

如需建置高品質評估數據集的詳細資訊，請參閱 開發評估集的最佳做法。

進行評估

既然您已備妥具有查詢和準則的評估集，您可以使用 mlflow.evaluate()來執行評估。 此函式會處理整個評估程式，從叫用代理程式到分析結果。

基本評估工作流程

執行基本評估只需要幾行程序代碼。 如需詳細資訊，請參閱 執行評估。

觸發評估時：

1. 針對評估集中的每個數據列，mlflow.evaluate() 會執行下列動作：
   • 致電給您的代理人以提出查詢（如果您尚未提供回應）。
   • 套用內建的 LLM 評估器來評估品質維度。
   • 計算令牌使用量和延遲等作業計量。
   • 記錄每個評量的詳細理由。
2. 結果會自動記錄至 MLflow，並建立：
   • 對每列進行質量評估。
   • 所有範例的匯總指標。
   • 偵錯和分析的詳細記錄。

自訂評估

您可以使用其他參數，根據您的特定需求量身打造評估。 evaluator_config 參數可讓您執行下列動作：

• 選擇要執行的內建評測器。
• 設定適用於所有範例的全域指導方針。
• 設定評委的臨界值。
• 提供少量範例以引導評審的評估。

如需詳細資料和範例，請參閱 範例。

評估外部 Databricks 的代理

代理程式評估的其中一個強大功能，就是能夠評估部署在任何地方的 Gen AI 應用程式，而不只是在 Databricks 上。

哪些法官適用

預設情況下，代理評估會自動從評估集中可用的數據中選取適當的 LLM 評審。 如需如何評估品質的詳細資訊，請參閱 LLM 評委如何評估品質。

分析評估結果

執行評估之後，MLflow UI 會提供視覺效果和深入解析，以瞭解應用程式的效能。 此分析可協助您識別模式、診斷問題，以及排定改善的優先順序。

流覽評估結果

當您在執行 mlflow.evaluate(), 之後開啟 MLflow UI 時，您會發現數個互連的檢視。 如需如何在 MLflow UI 中巡覽這些結果的詳細資訊，請參閱 使用 MLflow UI 檢閱輸出。

如需如何解譯失敗模式的指引，請參閱 b 。改善代理程式和工具。

自訂 AI 評估 & 計量

雖然內建評委涵蓋許多常見的檢查（例如正確性、樣式、原則和安全性），但您可能需要評估應用程式效能的領域特定層面。 自定義評委和計量可讓您擴充評估功能，以解決您獨特的品質需求。

自定義 LLM 評委

如需如何從提示建立自定義 LLM 法官的詳細資訊，請參閱從提示 建立 AI 法官。

定制評審擅長評估具有類人判斷能力的主觀或細微的質量層面，例如：

• 領域特定的合規性（法律、醫療、財務）。
• 品牌語音和溝通風格。
• 文化敏感度和適當性。
• 複雜推理的質量。
• 特殊撰寫慣例。

法官的結果會顯示在 MLflow UI 中，與內建的評估審查者並列，並提供同樣詳細的理由來解釋評估。

自定義計量

如需更具程序性和決定性的評量，您可以使用 @metric 裝飾器來建立自定義指標。 請參閱 @metric 裝飾者。

自訂指標很適合：

• 驗證格式驗證和架構合規性等技術需求。
• 檢查特定內容是否存在。
• 執行量化測量，例如響應長度或複雜度分數。
• 實作商務特定的驗證規則。
• 與外部驗證系統整合。

b. 改善代理程式和工具

執行評估和識別質量問題之後，下一個步驟是有系統地解決這些問題以改善效能。 評估結果提供寶貴的見解，讓您了解您的代理失敗的地方和方式，讓您能夠進行針對性的改進，而非隨機進行調整。

常見的質量問題，以及如何修正這些問題

LLM 評委的評估結果顯示您的代理系統存在特定類型的失敗。 本節會探索這些常見的失敗模式及其解決方案。 如需如何解譯 LLM 判斷輸出的資訊，請參閱 AI 判斷輸出。

品質迭代最佳實踐

當您進行改進時，請維護嚴格的文件。 例如：

1. 為您的變更創建版本
   • 記錄每個重要的迭代使用 MLflow 追蹤。
   • 在中央組態檔中儲存提示、組態和金鑰參數。 請確保此事項由代理人記錄。
   • 針對每個新部署的代理程式，請在存放庫中維護 變更記錄，詳細說明變更的原因和原因。
2. 記錄哪些有效，哪些無效
   • 記錄成功和失敗的方法。
   • 請注意每個變更對計量的特定影響。 返回連結至代理評估的 MLflow 執行記錄。
3. 與利害關係人協調
   • 使用檢閱應用程式來驗證中小企業的改善。
     • 使用 檢閱者指示，向檢閱者溝通變更。
   • 若要並行比較不同版本的代理程式，請考慮在 AI 遊樂場 中建立多個代理程式端點並使用模型。 這可讓使用者將相同的要求傳送至不同的端點，並排檢查回應和追蹤。

3.生產

反覆評估並改善您的應用程式之後，您已達到符合需求且已準備好更廣泛使用的質量等級。 生產階段牽涉到將精簡代理程式部署至生產環境，並實作持續監視，以維持一段時間的品質。

生產階段包括：

• 將代理程式部署至生產環境： 設定具有適當安全性、調整和驗證設定的生產就緒端點。
• 監視生產中的代理程式： 建立持續質量評估、效能追蹤和警示，以確保您的代理程式在真實世界中維持高品質和可靠性。

這會建立一個持續的反饋迴圈，其中監視洞察會促進進一步的改善，而您可以進行測試、部署並繼續監視。 這種方法可確保您的應用程式在整個生命週期中保持高品質、符合規範，並符合不斷演進的業務需求。

一個。 將代理程式部署至生產環境

完成徹底的評估和反覆改進之後，您就可以將代理程式部署至生產環境。 [馬賽克 AI 代理框架](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework) 自動處理許多部署考量，簡化此過程。

部署流程

將您的代理程式部署至生產環境牽涉到下列步驟：

1. 在 Unity Catalog 中將代理程式 紀錄並註冊為 MLflow 模型。
2. 使用 Agent Framework 部署代理程式。
3. 為代理程式需要存取的任何相依資源 設定驗證。
4. 測試部署，以確認生產環境中的功能。
   • 模型服務端點準備就緒之後，您可以在 AI 遊樂場中與代理程式互動，您可以在其中測試及驗證功能。

如需詳細的實作步驟，請參閱 部署代理程式以進行產生式 AI 應用程式。

生產部署考慮

當您移至生產環境時，請記住下列重要考慮：

效能和擴展性

• 根據預期的使用模式來平衡成本與效能。
• 請考慮為間歇性使用的代理啟用 "調整至零" 功能，以降低成本。
• 根據應用程式用戶體驗需求了解延遲需求。

安全性和治理

• 請確定所有代理元件在 Unity Catalog 層級的適當存取控制。
• 儘可能針對 Databricks 資源使用內建的 驗證傳遞功能。
• 為外部 API 或數據源設定適當的認證管理。

整合方法

• 決定您的應用程式如何與代理程式互動（例如，使用 API 或內嵌介面）。
• 請考慮如何在應用程式中處理和顯示代理程序回應。
  • 如果您的用戶端應用程式需要額外的內容（例如源文檔參考或信賴分數），請設計您的代理程式在其回應中包含此元數據（例如，使用 自定義輸出）。
• 規劃代理程式無法使用時的錯誤處理和後援機制。

意見反應收集

• 在初始推出期間，利用檢閱應用程式以取得專案關係人的意見反應。
• 在應用程式介面中直接收集用戶意見反應的設計機制。
  • 從審查應用程式收集意見反應所建立的意見反應端點，也可以被外部應用程式用來對您的代理程式提供意見反應。 請參閱 對已部署的代理提供意見。
• 請確定意見反應數據會流入您的評估和改進程式。

b。 在生產環境中監視代理程式

將代理程式部署至生產環境之後，必須持續監視其效能、品質和使用模式。 不同於功能具決定性的傳統軟體，Gen AI 應用程式在遇到真實世界輸入時，可能會表現出品質漂移或非預期的行為。 有效的監視可讓您儘早偵測問題、瞭解使用模式，並持續改善應用程序的品質。

設定代理程式監控

馬賽克 AI 提供內建 監視功能， 可讓您追蹤代理程式的效能，而不需要建置自定義監視基礎結構：

1. 為已部署的代理程式建立監視。
2. 根據流量和監視需求設定取樣率和頻率。
3. 選擇品質指標，以自動評估抽樣的請求。

重要監視維度

一般而言，有效的監視應該涵蓋三個重要維度：

1. 作業計量

   • 請求數量和模式。
   • 回應延遲。
   • 錯誤率和類型。
   • 令牌使用量和成本。

2. 品質指標

   • 與使用者查詢的相關性。
   • 擷取內容中的基礎性。
   • 安全性和指導方針遵循。
   • 整體品質通過比率。

3. 用戶意見反應

   • 明確的意見反應（向上/向下豎起大拇指）。
   • 隱含訊號（後續問題、放棄的對話）。
   • 回報給客服渠道的問題。

使用監視UI

監視UI透過兩個索引標籤，提供跨這些維度的視覺化深入解析。

• 圖表索引標籤：檢視要求量、品質指標、延遲和錯誤隨時間的趨勢。
• 日志標籤：檢查個別請求和回應，包括其評估結果。

篩選功能可讓使用者搜尋特定查詢或依評估結果進行篩選。 如需詳細資訊，請參閱什麼是 Lakehouse Monitoring for generative AI？（MLflow 2）

建立儀錶板和警示

為了全面的監控：

• 建置自訂儀表板 使用儲存在評估追蹤表中的監控數據。
• 針對重大品質或作業閾值設定警示。
• 安排定期的品質檢閱 與主要的利害關係人。

持續改善週期

當監控能回饋到您的改進流程時，最有價值。

1. 透過監視計量和用戶意見反應來識別 的問題。
2. 將有問題的範例 匯出至評估集。
3. 使用 MLflow 追蹤分析和 LLM 判斷結果 診斷根本原因（如 常見質量問題所討論，以及如何修正它們）。
4. 開發並測試針對擴充評估集的改進。
5. 部署更新和監視 影響情況。

此 反覆的封閉式循環方法 有助於確保您的代理程式會根據真實世界的使用模式持續改善，同時維持高品質，同時適應不斷變化的需求和用戶行為。 透過代理程式監視，您可以深入瞭解代理程式在生產環境中執行的方式，讓您能夠主動解決問題，並將品質和效能優化。