工作人員企業的運作傑出
工作人員系統的營運傑出功能擴充了傳統 DevOps 作法,以解決 AI 工作人員的獨特特性:非決定性行為、內容相依的推理和記憶、目標複雜性和變數推斷成本。傳統應用程式會遵循可預測的程式碼路徑,但工作人員會根據內容產生新回應。傳統監視可追蹤已知度量,而工作人員可觀察性需要瞭解語言模型推理和決策模式。標準測試會驗證決定性輸出,但工作人員驗證會評估多個維度的回應品質,包括準確性、相關性、安全性和公平性。
產品與系統會隨著時間變化,因此請套用這些五個設計原則,將卓越營運納入您的執行方式:透過可觀察性開發、標準化作業程序、採用 DevOps 文化、自動化以獲得效率,並從所有作業事件中學習。核心作業傑出原則「透過可觀察性進化」對工作人員系統而言至關重要,因為工作人員行為源自提示之間的複雜互動、所取得的內容、模型行為和對話歷程記錄,而非決定性程式碼執行。由於回應是由模型、提示和即時內容所塑造,因此請針對可觀察性和護欄進行設計。全方位可觀察性顯示工作人員在實際狀況下實際行為的方式。此可視性可在工作人員產生非預期輸出時,啟用資料驅動的改善方式和快速問題診斷。
「操作代碼」為工作人員帶來新的維度。傳統基礎結構代碼擴充至提示版本化、模型組態管理和工作人員部署自動化。工作人員作業程序會處理模型版本變更、提示進化和Knowledge庫更新,以及傳統部署和回復作業。
「從所有作業事件中學習」對於工作人員系統而言變得更有價值。工作人員事件通常會顯示微妙的提示工程問題、指令檔和協調流程錯誤、Knowledge 庫缺口,或非預期的使用者互動模式。與工作人員遠程測試的系統分析結合後測試,會將作業體驗轉換為隨著時間複雜的組織能力。
完整對話記錄是工作人員可觀察性的基礎。捕捉每個對話,包括使用者輸入、工作人員回應、推理步驟、叫用的動作、取回的資料和最終成果。此遠端測試適用於多種用途:除錯特定事件、跨許多互動的品質分析、規範稽核、模型改善和使用模式分析。
將原生工作階段追蹤模型用於自訂建立的記錄。Agentforce 工作階段追蹤會在 Data 360 上的統一資料模型中捕捉工作人員互動資料,而不需要您建立平行遙測系統。工作階段追蹤資料模型 (STDM) 會將交談記錄為追蹤階層。每個工作階段都包含互動 (輪數)、每個互動都包含步驟 (UserInputStep、LLMExecutionStep、FunctionStep),而步驟包含訊息 (使用者和工作人員通訊)。STDM 使用標準 Data 360 物件,例如 AIAgentSession、AIAgentSessionParticipant、AIAgentInteraction、AIAgentInteractionStep 和 AIAgentInteractionMessage。互動會帶有散佈式追蹤識別碼 (TelemetryTraceId 和 TelemetryTraceSpanId),而步驟會帶有 span 識別碼 (TelemetryTraceSpanId),以反映 OpenTelemetry 樣式的 span 模型。
將工作人員對話建模為追蹤與延展是對工作人員可觀察性的業界標準方法,且重複使用原生模型可避免手動建置物件遇到的規模問題:儲存多輪對話、大型 JSON 裝載和快速資料成長。建立自訂交易物件以記錄對話是刻意例外狀況,例如輕量型自訂物件,可將工作人員行為與業務成果相關聯,而非主要記錄基底。
工作階段和對話中繼資料會捕捉重要內容,包括工作階段和互動識別碼、使用者身分、工作人員身分、開始時間和結束時間。STDMalso 會將每個互動步驟連結至其大型語言模型 (LLM) 通話記錄 (透過 GenerationId 和 GenAiGatewayRequest/Response 參照)。權杖用量、模型和提示詳細資料可透過這些聯結取得,而非儲存為工作階段欄位。中繼資料可啟用篩選和彙總對話以進行模式分析。
互動和步驟層級詳細資料會捕捉每個輪數,包括使用者輸入、工作人員回應、推理說明 (若可用)、信賴分數、檢取的內容、嘗試的動作和遇到的錯誤。逐步層級追蹤可讓詳細的事件調查完全重建推理鏈中每個點發生的狀況。
動作步驟會記錄工作人員採取的每個動作,包括 API 呼叫、資料修改、外部系統互動和叫用的整合。動作記錄會回答問題,例如「此工作人員變更了什麼?」以及「此工作人員存取了哪些系統?」。這些回答支援安全性調查和規範需求。STDM 會以互動步驟的原生方式來捕捉動作。
Atlas 原因引擎中的推理追蹤會顯示工作人員的決策流程,協助診斷工作人員選擇特定動作或產生特定回應的原因。「工作階段追蹤」會記錄計畫者的步驟,作為每個互動的一部分。公開的推理深度取決於模型和計畫者,但這些追蹤可用時會大幅改善除錯性。
Einstein Trust Layer 生成式 AI 稽核追蹤會捕捉每個生成式 AI 互動、提示與回應文字 (包括個人身分識別資訊 (PII) 遮蔽版本) 從基礎資料、回應安全性和毒性分數,以及串流至 Data 360 和儲存在 Data 360 中的 LLM 模型詳細資料。請開啟 Einstein 生成式 AI 和回饋資料收集與儲存,以便在 Data 360 中獲取稽核與回饋意見資料,您可以在其中使用 Data 360 報告來查詢與分析資料以進行長期保留。
範例:
好:儲存在自訂 Salesforce 物件中的交談記錄,其中包含使用者輸入、工作人員回應、所採取動作、權杖耗用和交談結果的欄位。顯示面板會依工作人員和使用個案顯示交談成功率。更佳:全方位記錄包括顯示工作人員決策流程的推斷追蹤、顯示哪些資訊基於哪些回應的摘要內容,以及指出不確定性的信賴度分數。最佳:對話分析可將工作人員行為與業務成果建立關聯、透過模式分析識別改善機會,並使用品質標記的範例摘要持續學習銷售管道。
監視作業效能,確保工作人員符合服務層級並在預期參數內作業。
回應延遲會追蹤從使用者輸入到工作人員回應的端對端時間。延遲會直接影響使用者體驗。在百分位數 (p50、p95、p99) 中測量延遲,顯示一般效能與最差個案的體驗。當 p95 延遲超出指示效能降級值時顯示警示。
工作人員的延遲係數包括模型推斷時間、資料和內容尋找持續時間、外部工具和動作執行,以及網路延遲。當整體延遲超過目標時,請分別為每個階段進行儀器處理,以啟用目標最佳化。
權杖耗用量會測量每個交談、每個工作人員和每個使用個案使用的權杖。權杖耗用會推動推斷成本並影響回應時間 (更多權杖需要更多推斷計算)。追蹤權杖散佈,顯示實際用量是否符合預測。偵測耗用過多權杖的異常對話,以提示問題或不當使用。
權杖度量包括提示權杖 (輸入至模型)、完成權杖 (模型輸出),以及權杖總數 (提示與完成的總和)。提示權杖比完成權杖更容易控制。最佳化提示與所取用內容,同時減少提示權杖耗用,同時維持品質。
輸送量監視可追蹤同時對話、每秒要求和對話量趨勢,並可協助專案產能和調整規模需求。將目前的輸送量與已知的比率限制或即將達到達到達值的容量基準警示進行比較。
錯誤率追蹤會依類型監視失敗,包括模型特定的錯誤、逾時失敗、拒絕權限的錯誤,以及外部整合失敗。錯誤模式顯示需要修復的系統問題。將錯誤率計算為要求總數的百分比,以便在工作人員和期間之間進行比較。
區分需要不同回應的錯誤種類。模型特定錯誤可能需要提示調整或切換至較佳的模型。權限錯誤需要安全性組態變更。整合錯誤需要外部系統調查或斷電器啟用。
可用性監視會測量工作人員執行時間和成功的作業期間。以工作人員成功回應要求的時間百分比計算可用性。根據「服務層級目標」(SLO) 追蹤可用性,在可用性低於目標時啟用主動回應。
Proactive Monitoring 會評估貴組織是否有可能影響工作人員基礎結構健康的平台異常和資源利用問題。它會在訊號升級為使用者可見問題之前呈現。使用它來優先處理基礎結構層級條件,例如異常的 API 活動或資源耗用趨勢走向平台限制,這可能會降低工作人員績效。根據工作人員的正常營運基準檢閱其訊號,以便您可以區分可運作的異常與預期的變化。
持續監控回應品質,在影響業務成果之前偵測降級。當平台提供內建評估工具時,請使用這些工具來取代自訂或手動流程。從原生測試和評估工具開始。Agentforce 測試中心可讓您維護可重複使用的測試個案集,並以批次方式對其執行工作人員,檢查工作人員是否選取預期的主題和動作,並產生可接受的回應,而不是建立和執行您自己的測試機器。它也支援原生評估程式,包括立即可用的品質維度,以及評分對話品質的 LLM-as-judge 方法,並允許針對組織特定的條件撰寫自訂評估程式。在測試集中使用代表對話,以便評估反映實際用量。
回應準確性會測量工作人員回應是否包含正確的資訊。精確評估需要已知回答判斷式或人類審查。針對具有已知回答的實際問題,自動評估會將工作人員回應與正確回答進行比較;將這些項目作為測試中心中的測試個案來進行重複評估。針對開放式問題,人力評估程式會評估取樣對話的準確度。追蹤隨時間的準確性趨勢,顯示提示變更、模型更新或Knowledge庫修改是否改善或降低效能。
回應相關性會測量工作人員回應是否適當處理使用者問題,即使其不完全準確。相關的回應會瞭解使用者的意圖,並提供實用的資訊,即使無法提供完整的回答也是如此。透過可用的原生評估程式、人類檢閱取樣的交談,以及使用者訊號來評估相關性。針對以 Knowledge 庫為基礎的工作人員,原生提取品質分析可以評估內容相關性、回答相關性,以及回應的忠誠度 (基礎)。
護欄會偵測不安全、不適當或有害的回應,包括偏見、不當內容、危險建議和超出範圍的回應。Einstein Trust 圖層會將毒性偵測套用至執行階段的 LLM 互動,這是您的第一線防線。透過內容篩選、手動檢閱取樣、使用者報告機制和評估人口統計群組中成果分佈的公平性稽核,改善安全監視。
使用者滿意度度量會捕捉主觀體驗品質。Agentforce 回饋意見會流入 Einstein 生成式 AI 稽核和回饋意見資料模型 (Data 360 中的 GenAIFeedback/GenAIFeedbackDetail)。這些模型會將明確的使用者訊號 (姆指朝上/朝下、接受/拒絕、編輯和文字記錄) 從人類或系統來源中,連同管道要求和產生資料一同捕獲。在您需要的情況下捕捉明確的回饋意見 (在升級前、對話結束後以及透過後續調查要求),並將明確和隱含的訊號結合為全方位的品質觀點。
Salesforce 提供各種模型表面。生成層級提供對話推理工作人員執行的項目:Agentforce 主控的模型可在 Salesforce Trust 邊界內提供立即可用的邏輯,並將您自己的 LLM (BYOLLM) 連結帶入外部 LLM 或提供者。預測層級提供工作人員決定基礎的結構化評分:BYOM 會從外部主控的平台提取零複製預測分數,而原生 Einstein 模型會在 CRM 物件上產生自動評分和分類。這些面向可讓自發工作人員以自然語言說明原因,同時將其工作流程以結構化統計資料為基礎。
模型漂移的監視器,表示隨著時間或需要調整的變更條件的效能降低。在每個主要版本進入生產環境之前,請先檢閱版本注意事項並在 Sandbox 中測試重要使用個案。使用版本矩陣與 Sandbox 預覽視窗可提早找出相容性問題。
工作人員準確性、相關性或安全性隨著時間降低時,會發生 效能漂移。追蹤隨時間的品質度量,偵測到統計顯著的下降。效能漂移可能來自模型降級、Knowledge庫延遲、提示不符合變更的使用模式,或概念漂移,其中輸入與所需輸出之間的關係會演進。
在初始工作人員部署後立即建立基準效能,測量代表測試個案的準確性、相關性、安全性和滿意度。根據相同的測試個案定期重新評估,以顯示與使用模式排班無關的效能變更。
當品質度量超過可接受的值時顯示警示。根據業務影響容忍度定義上限。某些使用個案容忍溫和的品質降級,而其他則需要立即回應任何下降。
當使用者輸入模式因訓練或調整資料散佈而大幅變更時,會發生 散佈漂移。當工作人員遇到其未設計為處理的輸入類型時,散佈漂移會降低效能。監視輸入特性,包括問題長度、主題分佈、語言複雜度,以及偵測顯著排班的網域術語。
比較目前的輸入分佈與歷程記錄基準。大型散佈排班表示新的使用個案、變更的使用者行為或不斷發展的業務流程。散佈排班可能需要提示更新、Knowledge 庫擴充或工作人員功能增強功能。
當工作人員回應模式非預期變更時,會發生 行為漂移。監視回應特性,包括平均回應長度、動作叫用率、升級頻率和錯誤模式。顯著的行為變更表示提示問題、模型問題或基本系統變更。
早期在生產環境中建立行為基準,並捕捉一般營運特性,例如一般效能模式、工具用量和決策路徑。這些基準會成為稍後異常偵測測量的基準。對照基準比較進行中的行為,在偏差超出預期變化時警示。
自動警示會啟用主動漂移回應。設定當漂移度量超出觸發調查和潛在補救措施 (包括提示精簡、Knowledge 庫更新、測試集擴充或 BYOM 模型重新訓練) 時觸發警示。
自動偵測需要調查的工作人員異常行為。
包含權杖耗用高峰、推斷率增加或總成本加速等成本異常。成本高峰可能表示會造成權杖產生過多、濫用或濫用導致非預期使用的提示問題,或導致冗餘呼叫的基礎結構問題。
監視偵測異常對話的權杖耗用散佈。調查耗用一般權杖計數 10 倍的交談,以瞭解其是否代表合法的邊緣個案或需要補救的問題。
錯誤率高峰,包括失敗率突然增加、在基準中不存在的新錯誤類型出現,或影響特定使用者、工作人員或使用個案的當地語系化錯誤集中情況。錯誤高峰通常會在客戶可能看到的品質降級問題之前。主動偵測可在大規模影響之前啟用補救措施。
回應模式變更,包括回應長度的突然變化、動作叫用頻率或升級速度變更。模式變更可能表示提示問題、模型行為變更或不斷演進的使用模式。
對話捨棄率增加,使用者以更高的率捨棄對話表示品質降低、延遲增加或功能差異。透過對話階段追蹤捨棄狀況,以識別使用者在初始互動、交談中或嘗試工作完成後是否捨棄。放棄模式會顯示特定改善機會。
設計警示結構以平衡快速通知和警示疲勞。立即將重要工作人員失敗路由至通話工程師。在營業時間將品質降級警告路由至產品小組以供調查。將次要異常彙總至每日摘要以進行趨勢分析。
版本可控制提示、組態和模型中繼資料,以啟用回復、A/B 測試和稽核追蹤維護。
提示範本是提示詞產生器中建立的可重複使用提示,可定義工作人員的目標、限制及品牌指導方針,以及動態奠基資料的預留位置,例如客戶或產品詳細資料。將提示範本與應用程式程式碼一起儲存在 Git 中,將提示視為重要的應用程式邏輯,其嚴格性與程式碼相同。提示變更會經過程式碼檢閱、測試和控制的部署。
使用提示詞產生器來使用版本歷程記錄和測試功能來重複提示開發。使用提示範本作為工作人員動作時,請在提示詞產生器中預覽範本,以確認合併欄位解析正確。接著使用測試中心執行端對端測試,確認工作人員選取動作並產生正確的輸出。
將準備好生產的提示匯出至版本控制,以在提示詞產生器開發與來源控制的部署管道之間建立同步。
組態管理會追蹤模型選取項目、溫度設定、檢索組態和功能標記。將組態儲存為程式碼,讓您可以使用環境特定的值、自動化部署,以及偵測組態漂移。
語意版本化適用於工作人員版本。主要版本表示大幅變更,例如修改的輸入/輸出契約或明顯變更的行為。較小的版本表示維護相容性的功能新增或改善。修補程式版本表示錯誤修正。版本編號會將變更影響傳達給作業小組和使用者。
實作工作人員元件的語意版本化,包括提示範本、工作人員組態和 Knowledge 庫。記錄中的版本號碼可啟用與特定部署的事件關聯。
變更文件會針對提示變更、組態修改和模型更新的考量。記錄變更的項目、變更的原因、驗證變更的測試,以及存在的回復程序。變更文件可加速事件調查和 Knowledge 轉移。
維護模型版本、提示、組態和部署歷程記錄的全方位登錄。
模型登錄會記錄部署的模型版本,其中包括模型系列、特定版本、微調狀態、部署環境 (生產、暫存和開發)、部署日期和負責小組。註冊處提供工作人員基礎結構狀態的單一事實來源。
部署追蹤會記錄每個工作人員部署,包括部署的版本、環境、部署時間戳記、部署使用者、取得的批准和部署結果。使用部署歷程記錄來評估問題出現時的影響 (例如「此事件開始前部署了哪些工作人員?」),並支援合規性報告。
相依性追蹤會對應工作人員、提示、Knowledge 庫、動作和整合之間的關係。當共用Knowledge更新時,相依性追蹤會顯示哪些工作人員受到影響。外部整合變更時,相依性追蹤會識別受影響的工作人員。
明確記錄相依性,而非在事件期間進行探索。建立透過開發和部署流程維護的相依性地圖。
淘汰原則會定義模型版本的生命週期,包括支援持續時間、淘汰時間表和移轉需求。清除淘汰原則可管理技術債務,進而防止對舊模型版本的無限支援。建立淘汰排程,提前足夠地傳達時間表,以啟用計畫移轉,而非強制淘汰的緊急應變。通訊良好且保單支援的最短通知期間可提供足夠的移轉時間來進行重大變更。
回復程序可讓小組從有問題的部署中快速復原。記錄每個工作人員的回復程序,並包含以下內容:
- 觸發回復的條件
- 要還原的版本
- 如何執行回復
- 授權和執行回復的人員
- 確認回復成功的測試為何,以及要通知的小組。
在非生產環境中定期測試回復程序,以確認在生產事件期間依賴這些程序之前可以運作。使用模擬部署進行訓練,讓小組確實知道要執行的動作。未經測試的回復程序通常會在最需要時失敗。
透過持續的訓練、微調和精簡工作流程來維護工作人員品質。
回饋意見集合會系統收集使用者回饋意見、人力評論修正、品質評估和成果估量。回饋意見提供改善的原始資料。若沒有系統的收集,則改善會變成猜測。透過在升級前、對話結束後或透過追蹤調查詢問來收集明確的回饋意見。透過完成率、升級頻率和重試模式收集隱含回饋意見。結合明確與隱含的訊號,提供全方位的品質透視圖。
資料精密設計透過精密設計、品質審查和偏差檢查來維護高品質的訓練資料集。訓練資料品質會直接決定模型品質。資料不足會產生不可靠的模型;優良的資料可達到卓越的效能。
透過以下方式來設計對話登入訓練資料集:
- 篩選品質 - 包括高評分對話和成功成果
- 移除有問題的範例,包括安全違規與錯誤
- 確保代表性 - 包括各種案例與邊緣個案
- 取消重複 - 移除近似相同的範例
主要透過以 Data 360 奠基且為 Salesforce 原生路徑 (RAG) 奠基,將工作人員調整至您的網域—專業詞彙、獨特的業務流程、組織特有的 Knowledge。
Salesforce 內沒有微調生成模型;您可以透過 AI 模型和提示詞產生器選取和設定模型。當奠基不足時,請微調外部,然後透過 BYOLLM 連線。
提示精簡會使用提示詞產生器以反覆方式根據效能資料改善提示。提示工程是連續的練習,而非一次性的練習。隨著使用模式的演變、業務流程的變更,以及使用者期望的變更,提示需要調整以維持最佳效能。
建立定期提示檢閱步調,以檢查最近對話、品質度量,以及識別改善機會的使用者回饋意見。透過 A/B 測試在完整首展之前驗證改善方式,以增量方式實作提示變更。
評估自動化會對延遲的測試集執行品質評估,以快速評估候選的改善方式。自動評估提供補充主觀的人類評估的目標測量。
維護涵蓋快樂路徑、邊緣個案、敵對輸入和歷程記錄問題情境的測試集。設定測試自動化以定期執行測試案例。包含自動結果監視、量度和通知,以警示管理員出現異常。此自動測試對於偵測外部因素 (例如模型漂移) 的不良影響而言至關重要。
在生產環境中出現新的極端個案時,持續展開測試集。測試自動化至關重要,但也會執行定期手動點檢查、一次性測試和大猩猩測試,以確保您的工作人員部署能夠抵禦邊緣個案。
請逐步部署工作人員變更,並在完整首展前監視品質,以限制問題的爆炸半徑。當變更跨越多個區域 (提示、模型組態、動作、奠基、整合) 時,會以測試未找到的方式降低行為。發生此情況時,產生的品質迴歸極少指向一個明顯的根本原因。一次傳送一個小變更,讓迴歸可以追蹤至其來源,然後先將每個變更釋放至有限的流量片段,以在您診斷時包含影響。
功能標記會透過在組態後端停用功能的工作人員部署,以將部署與版本分開。使用邏輯或自訂中繼資料類型或自訂設定實作功能標記。功能標記可在生產環境中啟用測試,而不向使用者顯示功能、逐步首展至特定使用者區段、A/B 測試比較實作,以及透過停用標記而不重新部署來立即回復。
針對重大工作人員變更使用功能標記,其中失敗的爆炸半徑可能嚴重,例如影響業務關鍵工作人員的變更、具有不確定生產行為的新推理模式 與外部系統的整合,其中互動模式可能與測試不同。
在更廣泛推出之前,Canary 部署 將工作人員變更發行至小型使用者子集的第一個監視錯誤率、品質度量和效能。使用權限集控制 canary 部署—限制工作人員對使用者子集的存取權,或根據使用者屬性在協調流程邏輯內篩選。
監視並測量成功率、回應品質和使用者回饋意見。使用先前的工作人員版本比較控制群組。只有在 Canary 顯示相等或改善的效能時,才展開首展。
A/B 測試會比較工作人員變化,以測量品質、成本和使用者滿意度。A/B 測試提供改善決策的實體證據。將變體部署至隨機選取的使用者子集,以確保統計有效性。測量跨多個維度 (準確性、滿意度、成本和延遲) 的成果,提供全方位比較。
開始 A/B 測試前,請先定義成功條件和假設。清除條件可防止產生不明確的結果,其中某些度量會改善,而其他度量會降低。成功條件應與業務目標保持一致 (例如,「選項 B 必須符合「變體 A」準確度的 2% 以減少成本達 15%」)。
相較於目前的 Champion 版本,Champion-challenger 測試會將改善的工作人員版本部署至流量子集。Champion-challenger 模式會透過將已驗證版本作為回復項目來管理改善風險。如果挑戰者績效不佳,請回復為 Champion,而不會影響使用者。如果挑戰者績效高於,請將其升級至新的 Champion。
建立目標促銷條件,包括統計有效性的最小樣本大小、挑戰者必須超過的品質界限,以及促銷決策前的評估持續時間。建立稽核追蹤工作人員版本變更原因的文件促銷決策。
建立事件偵測,透過全方位監視快速識別工作人員的作業問題。
工作人員失敗模式與傳統應用程式失敗不同。常見的失敗模式包括:
- 幻燈—產生可信但不正確的資訊
- 主題外回應 - 不瞭解使用者意圖
- 過度耗用成本 - 離開權杖產生
- 逾時失敗 - 推斷花費時間太長
- 權限錯誤 - 嘗試進行未經授權的動作
- 整合失敗 - 外部系統無法使用
- 安全違規 - 產生不當的內容
透過自動監視錯誤率、品質度量降級、成本異常、延遲增加和使用者升級的警示來偵測失敗。補充使用者自我報告機制,包括回饋意見要求,以及如何以及何處提供回饋意見的明確指引,讓您可以修正自動化中的報告缺口。
嚴重性分類會將事件路由至適當的緊急回應者。重要事件表示影響許多使用者的生產無法使用、工作人員動作造成的資料損毀風險、安全性損毀或需要立即回應的安全違規。高嚴重性表示品質降低,會影響業務關鍵工作人員或大幅超出成本。中度嚴重性表示在營業時間需要調查的隔離問題或即將達到達臨界值。低嚴重性表示在事件管理流程外追蹤的次要問題。
根據使用者影響、爆炸半徑、資料完整性風險和復原的急迫性,以物件的方式定義嚴重性條件。目標條件可防止實際問題過低升級和過度升級小型問題。維護事件解決結果的文件,以持續改善流程。
初始回應程序可引導穩定情況的立即動作。程序包括:
- 停用失敗的工作人員 - 斷電器啟用
- 將使用者路由至回復選項 - 人性處理、更簡單的工作人員、靜態回應
- 收集診斷資訊 - 最近對話、錯誤記錄、資源度量
- 通知利害關係人 - 通話工程師、產品擁有者、受影響的使用者
- 起始事件通訊 - 狀態頁面更新、內部協調管道
- 將初始回應程序記錄為執行手冊,以便快速執行,而不需要事件特定的調查。
- 執行手冊必須可由沒有深入工作人員專業知識的通話工程師執行。
避免串聯失敗,並在工作人員事件期間維護部分功能。
斷電器模式會自動停用失敗的工作人員,避免重複失敗,並在解決問題時影響使用者。實作監視錯誤率和開啟 (停用工作人員) 的斷路器,當錯誤率超過持續期間的期限時。
使用錯誤值、持續時間範圍和復原測試來設定斷路器。例如,具有五分鐘輪動視窗的 50% 錯誤率,以及要求測試工作人員是否康復的定期試用。開啟電路時,會將要求路由至回復選項。逾時後,電路會轉換為半開啟狀態,允許試用要求通過。當試用要求一致成功時,請關閉電路,恢復正常作業。
主要工作人員失敗時,回復階層會提供寬鬆的降級。設計回復順序,嘗試越來越簡單的選項,直到達成可接受的回應為止。回復階層範例:主要精密工作人員 → 更簡單的備份工作人員 → 靜態常見問題回應 → 人力轉移。
在協調流程層中實作回復邏輯,而非在工作人員中實作,以在工作人員生態系統中啟用一致的行為。定期測試回復路徑,並在需要時驗證其運作。
當 AI 工作人員無法處理要求時,人類轉移會升級至人類工作人員。設計運送工作流程以保留交談內容、傳達運送原因、路由至具相關專業知識的適當人力工作人員,以及追蹤運送頻率以顯示改善機會。
依照主題、工作人員和失敗原因監視升級率。比率愈高,表示需要提示改善、Knowledge庫擴充或使用個案精簡的工作人員能力差距。
優良降級會在降級作業期間維持部分功能。當複雜的推理失敗時,請返回更簡單的邏輯。當無法使用即時資料時,請對快取的資料進行操作。外部整合失敗時,請以唯讀模式作業。寬鬆降級可讓系統以減少的容量持續運作,而非完全失敗。
執行無罪的事件後審查,專注於系統改善,而非個別瑕疵,以建立誠實評估的心理安全。
時程表重建會透過第一個訊號、偵測、確認、調查、回應動作、復原和驗證,從初始狀況建立詳細的順序。為每個事件加上時間戳記,以啟用每個階段的持續時間分析,以顯示事件回應延遲的位置。
在時程表中包含下列內容:
- 最近部署的項目為何 (提示、組態、模型、整合)?
- 使用模式的哪些變更 (突然增加的流量、新交談類型) 已觀察到?
- 哪些外部因素影響 (第三方服務降級、平台更新)?
- 為什麼偵測速度低於理想?
根本原因識別會決定直接技術原因。區分立即原因 (模型逾時) 和影響因素 (提示設計超過特定對話模式下的權杖限制)。根原因分析可防止簡化結論 (「工作人員有程式錯誤」),以利特定發現結果,進而導致有效的補救措施。
使用「五個原因」技術,從症狀逐層細分至根本原因。
表面範例:「工作人員產生不正確的資訊」 →「為什麼?取得的內容包含過期的資料」 →「為什麼?Knowledge 庫未更新為最近產品變更」 →「為什麼?產品小組沒有觸發 Knowledge 庫更新的程序」 → 根本原因:缺少將產品版本連線至 Knowledge 庫維護的工作流程。
影響因素會顯示可啟用或放大事件影響的組織、程序或結構條件。常見因素包括監視缺口讓問題持續時間超過偵測到的時間、測試缺口讓失敗案例未被發現、文件缺口使快速診斷速度變慢、強制手動復原步驟的自動化缺口,以及結構缺口,例如單一失敗點或遺失冗餘。
貢獻因素分析顯示立即根本原因修正以外的改善機會。大多數事件都有多個影響因素,每個因素都有加強的影響。
偵測分析會檢查偵測事件的方式,以及是否可以更快地進行偵測。許多工作人員事件會先由使用者報告,而非自動監視,這表示有監視缺口。決定:先前應該偵測到問題的訊號為何?什麼監視可加速偵測?哪些警示條件會適當地觸發?
偵測分析改善方式包括:新增缺少的監視涵蓋範圍、調整警示值以消除假陰性、增強警示內容以加速分級,並改善顯示面板以主動識別問題。
回應評估會評估是否順利,以及是否比必要慢或難以處理的項目。回應評估問題:執行手冊是否實用且準確?升級路徑是否清楚且有效?回復程序是否經過測試並準備好?工具是否提供必要的診斷資訊?通訊是否及時且有效?
回應評估改善方式包括:使用學習的經驗更新執行手冊、澄清升級條件、定期測試回復程序、新增診斷工具,以及改善事件通訊範本。
動作項目指定可防止重複或改善未來回應的具體、已指派、繫結時間改善。避免使用模糊的動作項目 (例如「改善監視」) 來改善特定工作,例如「在 10 分鐘的時間範圍內針對超過 5% 的工作人員錯誤率新增警示」,已指派:Alex, due:2 週。」
在後續審查中追蹤動作項目完成度,確保實際發生持續改善。在每次事件後檢閱期間,檢閱先前事件的未結束動作項目。低完成率表示需要注意的持續改善流程失敗。
Knowledge 共用會在共用維基、知識庫或協同合作空間中記錄事件後審查,並使用標記來啟用多個事件的模式分析。事件追蹤應可依失敗模式、受影響的元件和期間搜尋,以便未來回應者能夠從歷程記錄事件中學習。
廣泛共用事件後審查,而非立即事件回應者。組織學習需要傳播資訊。考慮在小組會議或午餐學習會議中呈現主要事件學習,以傳播 Knowledge 並建立集體能力。
在部署生產工作人員以確保檢閱、風險評估和利害關係人對齊方式之前,需要批准。
預先部署檢查清單會驗證整備,包括:
- 已完成全方位測試 - 功能、品質、安全性、效能
- 已批准安全審查 - 權限界限、資料存取權、動作授權
- 已驗證規範 - 法規需求、保單符合度
- 文件完成 - 執行手冊、回復程序、升級路徑
- 已設定監視 - 品質度量、錯誤率、成本追蹤
- 已取得利害關係人批准 - 產品擁有者、安全性、合規性
檢查清單為工作人員提供一致的評估條件。根據工作人員重要性、資料敏感性和自主性層級,調整工作人員風險設定檔的檢查清單,以變更深度。
風險評估會評估工作人員失敗的潛在影響,包括:
- 爆炸半徑 - 受到失敗影響的使用者人數
- 資料敏感度 - 工作人員存取的資料
- 動作授權機構 - 工作人員可進行的修改
- 整合相依性 - 工作人員影響的系統
- 復原複雜度 - 回復的難度
- 規範涵義 - 適用的法規
風險評估會決定批准需求。高風險工作人員需要執行批准、安全性審查和漸進式首展,而低風險工作人員可能需要對等審查和標準測試。
批准工作流程會透過適當的檢閱者路由部署要求。使用 Salesforce 批准流程或外部部署工具實作批准工作流程。自動化、追蹤和稽核批准工作流程,以啟用合規性報告和事件調查。
記錄批准決策、建立批准部署人員的稽核追蹤、通知批准的資訊、套用的條件或限制,以及所做的監視承諾。
當一般批准流程會延遲重大修正時,緊急略過程序可在生產事件期間快速部署。緊急程序應需要執行批准、包含理由文件,並觸發加速的部署後審查以驗證緊急變更。
與標準版本分開追蹤緊急部署。高緊急部署頻率表示需要調查的流程問題。
定義工作人員必須在生產部署前通過的品質門,以防止有問題的工作人員與使用者聯繫。
功能測試會驗證工作人員在代表情況之間正確執行預期的工作。測試涵蓋一般互動的快樂路徑、涵蓋不常見但有效案例的邊緣個案、測試工作人員是否妥善處理無效輸入的錯誤路徑,以及檢查工作人員是否在管理員限制、權杖限制和資料量限制的邊界條件。
工作人員的功能測試與傳統測試不同,因為非決定性輸出會防止完全符合。測試輸出特性 (包含必要資訊、維持適當的語調、包含必要引號),而非完全相符的文字。
回應品質測試會評估跨測試案例的回應準確性和相關性。品質測試需要人工評估或含預期輸出的基本事實資料集。建立工作人員必須符合的最低品質值 (例如,「逾期測試集的準確度為 95%,安全違規為零,公平性稽核顯示的人口統計差異不超過 5%」)。當發現新的邊緣個案時,請持續維護並展開測試集。
安全測試會驗證工作人員是否拒絕危險、不道德或超出範圍的要求。安全測試會嘗試對應輸入,包括:
- 提示插入嘗試 - 嘗試覆寫指示
- 洩漏嘗試 - 嘗試略過安全限制
- 要求升級 - 要求具有愈來愈敏感性的動作
- 超出範圍要求 - 嘗試進行未經授權的工作
將安全測試指派給未參與建立工作人員的獨立小組成員。針對高風險工作人員,請提供紅色小組專家。
效能測試會驗證延遲、輸出和符合預期成本。在實際的負載中進行測試,包括同時對話、一般對話長度和預測使用量。效能測試顯示管理員限制問題、資源限制,以及單一使用者測試中看不到的延展性瓶頸。
在效能測試期間測量測試環境耗用,並將其用於預測生產容量需求。
安全性測試會驗證權限界限、資料存取控制和動作授權。安全性測試確認:工作人員無法存取未經授權的資料、工作人員無法執行未經授權的動作、提示插入無法升級權限,且稽核記錄會捕捉所有工作人員活動。
使用 Salesforce Code Analyzer 將靜態程式碼安全性掃描整合至部署管道,此分析工具會掃描 Apex、Flow、Lightning 和 Visualforce 是否有安全性漏洞,並可透過其指令行介面 (CLI) 或 GitHub 動作在連續整合/部署 (CI/CD) 中執行。使用專業的 AI/工作人員安全性測試來偵測提示插入漏洞和敏感資料曝光風險,因為這些是靜態程式碼分析範圍外的執行階段 LLM 輸入威脅。
將變更管理規則套用至工作人員部署,以確保記錄、檢閱和傳達變更。
變更文件會記錄:
- 變更的項目 - 提示修改、組態更新、模型變更
- 進行變更的原因 - 品質改善、成本最佳化、錯誤修正
- 哪些測試已驗證該變更 - 測試結果、品質分數、安全性掃描
- 有哪些回復程序
變更文件可啟用事件調查、規範報告和 Knowledge 轉移。記錄的變更會建立以先前經驗為基礎的學習組織,而非重新探索經驗。
通訊計畫會通知利害關係人有關工作人員變更,包括受影響的使用者、作業小組、支援小組和業務利害關係人。通訊應描述:變更的項目、變更何時部署、使用者會看到哪些好處、存在哪些風險,以及要連絡的問題對象。
針對不同變更類型建立通訊範本,將訊息標準化並減少部署準備額外的負擔。
在低用量期間,透過「事件監視」資料通知工作人員部署的時間,以顯示實際用量模式的部署排程時間。避免在使用量高峰、月結束、季結束或主要業務事件期間進行部署。通訊部署時段,包括預期的持續時間和回復決策時間表。
請考慮排程一週早到中午的主要變更,並避免在週末部署,以便透過適當的資源解決問題。將快速回復和強大的部署後監視優先於任何固定行事曆規則。
變更視窗與凍結視窗可保護重要業務週期。在主要業務事件 (會計年度結束、產品推出和主要行銷活動) 之前建立變更凍結期間,以避免在高利息期間發生部署所導致的問題。
文件變更凍結行事曆會每年提前足夠地溝通受限制的期間,讓小組能夠進行相應的計畫。過度凍結會使速度變慢;凍結不足會造成業務風險。
建立回饋意見迴圈,將作業遠端測量連線至工作人員改善。
使用者回饋意見集合會透過問題或追蹤調查收集明確的回饋意見。透過完成率、升級至人力工作人員、重試模式,以及指示不滿的後續追蹤問題來收集隱含的回饋意見。結合明確與隱含的訊號,提供全方位的品質透視圖。
收集回饋意見內嵌,立即發生,而非稍後。延遲的回饋意見收集會降低回應率並導致取回偏差。
使用分析會顯示實際對話模式,例如主題、問題和循環趨勢。他們會測試工作人員的複雜性是否能獲得其保留、由於可探索性不佳而使功能無法使用,以及實際使用是否會驗證原始設計假設。
查詢對話記錄會分析問題類型、對話長度、依照主題的成功率,以及依對話特性的使用者滿意度。使用模式分析可引導精簡、Knowledge 庫擴充和功能優先順序。
錯誤模式分析會識別需要修復的系統品質問題。依錯誤類型、受影響的使用者、對話模式和時間散佈來分析錯誤記錄分組。錯誤模式會顯示提示問題、Knowledge 基礎缺口、整合問題或需要處理的邊緣個案。
依頻率與影響排定錯誤修復的優先順序。影響許多使用者的高頻率錯誤需要立即注意。低頻率錯誤會根據業務影響和補救成本,表示可接受的邊緣個案。
品質趨勢監視會追蹤一段時間內的準確性、相關性、安全性和滿意度,以偵測在退化變為嚴重之前的退化。初始工作人員部署後建立品質基準。當趨勢下降超過可接受的期限時,針對基準警示監視持續品質。
品質監視會顯示提示變更、模型更新或Knowledge庫修改是否改善或降低效能,以啟用資料驅動的改善決策。
使用實驗證據,以系統方式追蹤資訊改善決策的實驗。
試驗架構提供一致的測試改善結構,包括:
- 假設 - 預期改善方式
- 試驗設計 - 部署變體的方式
- 度量 - 測量的成果
- 樣本大小 - 統計有效期間所需的互動次數
- 成功條件 - 哪些結果可以證明促銷
在執行前記錄實驗,以避免對結果進行不明確的解譯。預先定義的成功條件可啟用明確的促銷決策,避免長時間討論結果是否「足夠好」。
變體追蹤會記錄哪些使用者收到哪些變體來啟用成果關聯性。在對話中繼資料中追蹤變體指派,以依變體分析品質、成本和滿意度。
統計有效性可確保實驗的執行時間足夠長,且樣本大小足以得出可靠的結論。根據預期的效果大小、統計效能需求和可接受的錯誤率,計算所需的樣本大小。樣品不足會產生雜訊的結果,導致決策不佳。
多重防盜最佳化會在試驗期間動態地將更多流量配置給效能較佳的變體。多重武器盜手方法會減少對較差變體的曝光,同時收集足夠的資料以供統計分析,藉此降低機會實驗成本。
實驗目錄會記錄每個實驗的變體、成果和決策。它會阻止小組重新測試失敗的方法、在整個組織中傳播學習,並建立實際運作的共用記錄。
工作人員系統的最佳作業需要擴充傳統 DevOps 作法,以解決獨特的 AI 特性。全方位可觀察性可讓您瞭解新增的工作人員行為。系統的生命週期管理可確保品質、安全性和成本控制。事件回應程序可處理工作人員特定的失敗模式。持續改善可將作業體驗轉換為組織能力。
在工作人員系統中卓越運作的重要作法:
- 記錄完整的交談,包括輸入、輸出、推理追蹤、動作和成果。
- 透過準確性、相關性、安全性和滿意度度量,持續監控回應品質。
- 透過基準比較和異常偵測來偵測模型漂移和行為變更。
- 版本可控制啟用回復與 A/B 測試的提示、組態和模型。
- 使用限制爆炸半徑的功能標記和 canary 部署實作漸進式首展。
- 設計斷路器與回復階層以防止階層化工作人員失敗。
- 執行以系統化改善為重點的具體事件後審查。
- 建立品質門與批准流程,避免有問題的工作人員進入生產環境。
- 建立回饋意見迴圈,將作業遠端測量連線至工作人員改善。
- 使用實體證據系統追蹤實驗,以指引增強決策。
投資於工作人員卓越營運的組織會透過可靠的高品質 AI 功能獲得永續的競爭優勢,這些功能會根據業務需求持續發展。