ai-agents-for-beginners
生產環境中的 AI 代理：可觀察性與評估
隨著 AI 代理從實驗原型逐步應用於現實世界，理解其行為、監控其效能及系統性地評估其輸出變得越來越重要。
學習目標
完成本課程後，你將會知道如何／理解：
- 代理可觀察性與評估的核心概念
- 改善代理效能、成本與效果的技術
- 如何系統性評估你的 AI 代理
- 如何在部署 AI 代理到生產環境時控制成本
- 如何對使用 Microsoft Agent Framework 建立的代理進行埋點儀表
目標是讓你具備將你的「黑盒子」代理轉化為透明、可管理且可靠系統的知識。
注意： 部署安全且值得信賴的 AI 代理非常重要。請參考建立值得信賴的 AI 代理課程。
跟蹤與跨度
可觀察性工具如 Langfuse 或 Microsoft Foundry通常將代理運行表示為跟蹤 (trace) 和跨度 (span)。
- Trace 代表從開始到結束的完整代理任務（例如處理用戶查詢）。
- Spans 是跟蹤中的個別步驟（例如呼叫語言模型或檢索資料）。
沒有可觀察性，AI 代理感覺就像是「黑盒子」——其內部狀態與推理不透明，難以診斷問題或優化效能。有了可觀察性，代理成為「玻璃盒」，提供的透明度對建立信任與確保運作符合預期至關重要。
為何生產環境中可觀察性重要
將 AI 代理推向生產環境時會帶來一系列新的挑戰和需求。可觀察性不再是「可有可無」，而是關鍵能力：
- 除錯與根因分析：當代理失敗或產生意外輸出時，可觀察性工具提供追蹤紀錄，幫助精確定位錯誤來源。這在涉及多次 LLM 呼叫、工具互動及條件邏輯的複雜代理中特別重要。
- 延遲與成本管理：AI 代理通常依賴按標記或呼叫計費的 LLM 及其他外部 API。可觀察性能精確追蹤這些呼叫，幫助識別過慢或成本過高的操作，進而優化提示詞、選擇更高效模型或重新設計流程，管理運營成本並確保良好用戶體驗。
- 信任、安全與合規：在許多應用中，確保代理行為安全且合乎道德至關重要。可觀察性提供代理行為與決策的稽核軌跡，能用來偵測並緩解如提示詞注入、有害內容產生或個人識別資訊 (PII) 處理不當等問題。例如，你可以回顧追蹤紀錄以理解代理為何給出某個回覆或使用特定工具。
- 持續改進循環：可觀察性數據是迭代開發流程的基礎。透過監控代理在真實環境中的表現，團隊可識別改進空間、收集微調模型所需資料，並驗證變更效果。如此形成反饋循環，將線上評估的生產洞察融入離線實驗與調整，逐步提升代理效能。
需追蹤的關鍵指標
為監控並理解代理行為，需要追蹤多種指標與信號。雖然具體指標會因代理目的不同而異，但以下幾項是普遍重要的。
以下是可觀察性工具通常監控的常見指標：
延遲（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 跨度輸出至可觀察工具。Microsoft Agent Framework 原生整合 OpenTelemetry。以下為如何對 MAF 代理埋點的範例：
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# 代理執行會自動被追蹤
pass
本章的 示例筆記本 將演示如何為 MAF 代理埋點儀表。
手動建立跨度（Manual Span Creation）： 雖然儀表庫已提供良好基礎，有時仍需更詳細或自訂資訊。你可以手動建立跨度，加入自訂應用邏輯。更重要的是，可為自動或手動建立的跨度附加自訂屬性（俗稱標籤或元資料）。這些屬性可包含商務相關資料、中間運算結果或任何有助於除錯與分析的上下文，如 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 代理部署到生產環境中成本的策略：
使用較小模型： 小型語言模型（SLM）在某些具代理性的使用案例中表現良好，並且能顯著降低成本。如前所述，建立一個評估系統來判斷並比較其與較大型號的性能，是了解 SLM 在您的使用案例中表現如何的最佳方式。考慮將 SLM 用於較簡單的任務，如意圖分類或參數提取，而將較大型號保留給複雜推理。
使用路由器模型： 類似的策略是使用多樣化的模型和規模。您可以使用 LLM/SLM 或無伺服器函數根據複雜性路由請求到最合適的模型。這也有助於降低成本，同時確保在適當任務上的性能。例如，將簡單查詢路由到較小且更快的模型，僅對複雜推理任務使用昂貴的大型模型。
快取回應： 識別常見請求和任務，並在它們進入您的代理系統之前預先提供回應，是減少類似請求量的好方法。您甚至可以實現一個流程，使用較基礎的 AI 模型來識別請求與快取請求的相似程度。此策略能顯著減少對於常見問題或常見工作流程的成本。
讓我們來看看實際運作如何
在本節的示例筆記本中，我們將看到如何使用可觀察性工具來監控並評估我們的代理。
對生產環境中的 AI 代理有更多疑問嗎？
加入Microsoft Foundry Discord，與其他學習者交流，參加開放時段，並獲得您對 AI 代理的問題解答。
上一課
下一課
免責聲明：
本文件透過 AI 翻譯服務 Co-op Translator 進行翻譯。儘管我們致力於確保準確性，但請注意自動翻譯可能存在錯誤或不準確之處。原始文件的母語版本應被視為權威來源。對於重要資訊，建議採用專業人工翻譯。我們不對因使用本翻譯而引致的任何誤解或誤譯承擔責任。