當AI代理從實驗性原型轉向現實世界的應用時,理解其行為、監控其性能以及系統性地評估其輸出變得至關重要。
完成本課程後,您將能夠了解/掌握:
目標是讓您掌握將“黑箱”代理轉變為透明、可管理且可靠系統的知識。
注意: 部署安全且值得信賴的AI代理非常重要。請參考構建值得信賴的AI代理課程。
可觀察性工具(如 Langfuse 或 Azure AI Foundry)通常將代理運行表示為跟蹤與跨度。
如果缺乏可觀察性,AI代理可能像一個“黑箱”——其內部狀態和推理過程不透明,難以診斷問題或優化性能。有了可觀察性,代理就變成了“玻璃箱”,提供了透明性,這對於建立信任並確保其按預期運行至關重要。
將AI代理轉移到生產環境會帶來一系列新的挑戰和需求。此時,可觀察性不再是“可有可無”的功能,而是一項關鍵能力:
為了監控和理解代理行為,需要追蹤一系列指標和信號。雖然具體指標可能因代理的用途而異,但有些指標是普遍重要的。
以下是可觀察性工具通常監控的一些常見指標:
延遲(Latency): 代理的響應速度如何?長時間等待會對用戶體驗產生負面影響。您應該通過跟蹤代理運行來測量任務和單個步驟的延遲。例如,一個代理在所有模型調用上花費20秒,可能可以通過使用更快的模型或並行運行模型調用來加速。
成本(Costs): 每次代理運行的費用是多少?AI代理依賴於按字元計費的LLM調用或外部API。頻繁的工具使用或多次提示可能會迅速增加成本。例如,如果一個代理為了微小的質量提升調用了LLM五次,您需要評估這樣的成本是否值得,或者是否可以減少調用次數或使用更便宜的模型。實時監控還可以幫助識別意外的成本激增(例如,因錯誤導致的過多API循環)。
請求錯誤(Request Errors): 代理失敗的請求數量是多少?這可能包括API錯誤或工具調用失敗。為了使代理在生產環境中更具魯棒性,您可以設置回退機制或重試邏輯。例如,如果LLM提供商A宕機,則切換到LLM提供商B作為備份。
用戶反饋(User Feedback): 實施直接的用戶評估提供了寶貴的見解。這可以包括明確的評分(👍/👎,⭐1-5星)或文本評論。持續的負面反饋應引起警惕,因為這表明代理未按預期工作。
隱式用戶反饋(Implicit User Feedback): 即使沒有明確的評分,用戶行為也能提供間接反饋。例如,立即重新措辭問題、重複查詢或點擊重試按鈕。如果您發現用戶反復提出相同的問題,這表明代理未按預期工作。
準確性(Accuracy): 代理生成正確或期望輸出的頻率如何?準確性的定義可能不同(例如,解決問題的正確性、信息檢索的準確性、用戶滿意度)。第一步是定義代理成功的標準。您可以通過自動檢查、評估分數或任務完成標籤來追蹤準確性。例如,將跟蹤數據標記為“成功”或“失敗”。
自動評估指標(Automated Evaluation Metrics): 您還可以設置自動評估。例如,您可以使用LLM對代理的輸出進行評分,例如是否有幫助、準確或無害。還有一些開源庫可以幫助您評分代理的不同方面。例如,RAGAS 用於RAG代理,LLM Guard 用於檢測有害語言或提示注入。
實踐中,這些指標的組合能提供AI代理健康狀況的最佳覆蓋。在本章的示例筆記本中,我們將展示這些指標在實際案例中的表現,但首先,我們將學習典型的評估工作流程。
為了收集跟蹤數據,您需要為代碼添加監控功能。目標是讓代理代碼能夠生成可被可觀察性平台捕獲、處理和可視化的跟蹤和指標。
OpenTelemetry (OTel): OpenTelemetry 已成為LLM可觀察性的行業標準。它提供了一套API、SDK和工具,用於生成、收集和導出遙測數據。
有許多儀器庫可以包裝現有的代理框架,並輕鬆將OpenTelemetry跨度導出到可觀察性工具。以下是使用OpenLit儀器庫為AutoGen代理添加監控的示例:
import openlit
openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)
本章的示例筆記本將演示如何為AutoGen代理添加監控功能。
手動創建跨度: 儘管儀器庫提供了良好的基礎,但在某些情況下可能需要更詳細或自定義的信息。您可以手動創建跨度以添加自定義應用邏輯。更重要的是,您可以為自動或手動創建的跨度添加自定義屬性(也稱為標籤或元數據)。這些屬性可以包括業務特定數據、中間計算或任何可能對調試或分析有用的上下文,例如user_id
、session_id
或model_version
。
以下是使用Langfuse Python SDK手動創建跟蹤和跨度的示例:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
可觀察性提供了指標,而評估則是分析這些數據(並執行測試)以確定AI代理的性能如何以及如何改進。換句話說,一旦您擁有這些跟蹤和指標,如何利用它們來評估代理並做出決策?
定期評估很重要,因為AI代理通常是非確定性的,並且可能會隨著更新或模型行為的漂移而演變——如果沒有評估,您無法知道您的“智能代理”是否真的在做好工作,或者是否出現了性能退化。
AI代理的評估分為兩類:離線評估和在線評估。兩者都很有價值,並且相輔相成。我們通常從離線評估開始,因為這是部署任何代理之前的最低必要步驟。
這涉及在受控環境中評估代理,通常使用測試數據集,而不是實時用戶查詢。您使用經過精心挑選的數據集,這些數據集中您知道期望的輸出或正確的行為,然後讓代理在這些數據集上運行。
例如,如果您構建了一個數學文字題代理,您可能擁有一個測試數據集,其中包含100個問題及其已知答案。離線評估通常在開發過程中進行(並且可以成為CI/CD管道的一部分),以檢查改進或防止性能退化。其優勢在於可重複,並且由於擁有真實答案,可以獲得清晰的準確性指標。您還可以模擬用戶查詢,並將代理的響應與理想答案進行比較,或者使用上述的自動指標。
離線評估的主要挑戰是確保您的測試數據集具有全面性並保持相關性——代理可能在固定測試集上表現良好,但在生產中遇到完全不同的查詢。因此,您應該持續更新測試集,加入新的邊界情況和反映現實場景的示例。混合使用小型“冒煙測試”案例和大型評估集是有用的:小型集用於快速檢查,大型集用於更廣泛的性能指標。
這是指在實時、真實環境中評估代理,即在生產中的實際使用過程中進行評估。在線評估涉及監控代理在真實用戶交互中的表現,並持續分析結果。
例如,您可能會追蹤成功率、用戶滿意度得分或其他指標的實時流量。在線評估的優勢在於捕捉到實驗室環境中可能無法預見的情況——您可以觀察模型隨時間的漂移(例如,隨著輸入模式的變化,代理的有效性是否下降),並捕捉測試數據中未包含的意外查詢或情況。它提供了代理在真實環境中的真實表現。
在線評估通常涉及收集隱式和顯式用戶反饋(如前所述),並可能運行影子測試或A/B測試(即新版本代理與舊版本並行運行以進行比較)。挑戰在於為實時交互獲取可靠的標籤或評分可能很困難——您可能需要依賴用戶反饋或下游指標(例如,用戶是否點擊了結果)。
在線和離線評估並非互斥;它們高度互補。來自在線監控的洞察(例如,代理在某些新類型的用戶查詢中表現不佳)可以用於擴充和改進離線測試數據集。反之,在離線測試中表現良好的代理可以更有信心地部署並在線監控。
事實上,許多團隊採用一個循環:
離線評估 -> 部署 -> 在線監控 -> 收集新的失敗案例 -> 添加到離線數據集 -> 優化代理 -> 重複。
在將AI代理部署到生產環境時,您可能會遇到各種挑戰。以下是一些常見問題及其潛在解決方案:
問題 | 潛在解決方案 |
---|---|
AI代理無法一致地執行任務 | - 優化給AI代理的提示,明確目標。 - 確定是否可以將任務分解為子任務,並由多個代理處理。 |
AI代理陷入連續循環 | - 確保設置了明確的終止條件,讓代理知道何時停止流程。 |
以下是一些在生產環境中使用 AI Agent 時可能遇到的常見問題及其解決方法:
問題 | 解決方法 |
---|---|
AI Agent 的回應不準確或不一致 | - 調整 Agent 的提示語(Prompts),使其更具針對性和清晰度。 - 使用更大的模型來處理需要更高準確度的任務。 |
對複雜任務的處理能力不足 | - 使用專門針對推理任務的大型模型。 |
AI Agent 工具的調用表現不佳 | - 在 Agent 系統外測試並驗證工具的輸出。 - 優化工具的參數設置、提示語及命名方式。 |
多 Agent 系統表現不穩定 | - 優化每個 Agent 的提示語,確保它們具體且彼此區分明確。 - 建立層級系統,使用「路由」或控制器 Agent 來判斷哪個 Agent 是正確的選擇。 |
透過建立可觀測性(Observability),可以更有效地識別這些問題。前面提到的追蹤和指標能幫助精確定位 Agent 工作流程中的問題所在,從而使調試和優化更加高效。
以下是一些管理 AI Agent 部署成本的策略:
使用較小的模型: 小型語言模型(SLM)在某些 Agent 使用場景中表現良好,並能顯著降低成本。如前所述,建立評估系統以比較小型模型與大型模型的性能,是了解 SLM 是否適合您的使用場景的最佳方法。考慮將 SLM 用於簡單任務,例如意圖分類或參數提取,而將大型模型保留給需要複雜推理的任務。
使用路由模型: 類似的策略是使用多種模型和不同大小的模型。您可以使用 LLM/SLM 或無伺服器函數來根據任務的複雜程度將請求路由到最合適的模型。這不僅能降低成本,還能確保在正確的任務上保持性能。例如,將簡單的查詢路由到較小、速度較快的模型,僅在需要複雜推理時使用昂貴的大型模型。
緩存回應: 識別常見請求和任務,並在它們進入 Agent 系統之前提供回應,是減少相似請求量的好方法。您甚至可以實施一個流程,使用更基本的 AI 模型來識別請求與緩存回應的相似程度。此策略能顯著降低常見問題或工作流程的成本。
在本節的示例筆記本中,我們將看到如何使用可觀測性工具來監控和評估 Agent 的表現。
加入 Azure AI Foundry Discord,與其他學習者交流,參加辦公時間,並獲得您的 AI Agent 問題的解答。
免責聲明:
本文件已使用人工智能翻譯服務 Co-op Translator 進行翻譯。雖然我們致力於提供準確的翻譯,但請注意,自動翻譯可能包含錯誤或不準確之處。原始語言的文件應被視為權威來源。對於重要資訊,建議使用專業的人類翻譯。我們對因使用此翻譯而引起的任何誤解或錯誤解釋概不負責。