：評測與可觀測性實戰(zhàn)指南)
1. 從Demo驚艷到上線翻車AI智能體交付的斷層在哪里做過AI智能體項目的人大概都有類似的體驗在PoC階段用幾十條精心挑選的測試用例跑一遍效果驚艷團隊信心滿滿老板拍板推進?？梢坏┻M入真實業(yè)務流量各種問題就像開閘的水一樣涌出來——有的用戶問法稍微繞一點智能體就開始胡言亂語有的工具調(diào)用在測試環(huán)境好好的到了生產(chǎn)環(huán)境因為接口超時直接卡死更讓人頭疼的是你根本不知道它為什么出錯因為整個鏈路就像一個黑盒輸入進去、輸出出來中間發(fā)生了什么全靠猜。這個斷層不是模型能力的問題而是工程化交付的問題。PoC階段關(guān)注的是“能不能做出來”生產(chǎn)階段關(guān)注的是“能不能穩(wěn)定地做對”。這兩件事之間的鴻溝需要用評測體系和可觀測性來填。評測解決的是“怎么知道它做得好不好”可觀測性解決的是“它為什么做得不好”。兩者缺一不可而且必須從PoC階段就開始搭不能等到上線前才臨時抱佛腳。我見過太多團隊在PoC階段只關(guān)注“跑通”把評測簡化成人工看幾條case把日志簡化成print大法。結(jié)果到了生產(chǎn)環(huán)境面對每天幾千上萬次調(diào)用既沒有自動化的質(zhì)量度量也沒有細粒度的鏈路追蹤出了問題只能靠用戶截圖反饋來定位。這種狀態(tài)下智能體的迭代基本靠玄學今天修好一個bug明天可能又引入兩個新問題。所以這篇文章想聊的就是怎么在AI智能體項目里從第一天起就把評測和可觀測性當成基礎(chǔ)設(shè)施來建。不是那種“等有空了再補”的附屬品而是和業(yè)務邏輯同等重要的核心組件。我會從評測集的設(shè)計、評測方法的選型、可觀測性的埋點策略、鏈路追蹤的實現(xiàn)、以及生產(chǎn)環(huán)境的持續(xù)監(jiān)控這幾個維度展開盡量把每個環(huán)節(jié)的“為什么”和“怎么做”都講清楚。2. 評測集不是測試用例的堆砌構(gòu)建能反映真實分布的Agent評測體系2.1 為什么傳統(tǒng)測試用例在Agent場景下不夠用傳統(tǒng)軟件測試的思路是給定輸入驗證輸出是否等于預期。這套邏輯在確定性系統(tǒng)里很好用但放到AI智能體上就完全失效了。因為智能體的輸出不是確定性的同一個問題換一種問法可能得到完全不同的回答同一個回答在不同上下文里正確性判斷標準也不一樣。更麻煩的是智能體往往涉及多輪對話和工具調(diào)用中間任何一步出偏差最終結(jié)果就可能南轅北轍。我剛開始做Agent評測的時候也犯過“把測試用例當評測集”的錯誤。當時整理了200條問答對每條都有標準答案跑完一看準確率85%覺得還不錯。結(jié)果上線后發(fā)現(xiàn)用戶的實際問法千奇百怪那200條用例覆蓋的場景連真實流量的20%都不到。后來復盤才明白評測集的核心不是“數(shù)量”而是“分布”。它必須能反映真實用戶請求的多樣性包括不同的問法、不同的意圖組合、不同的上下文長度、不同的工具調(diào)用路徑。2.2 評測集的四個維度意圖覆蓋、難度分層、對抗樣本、邊界條件一個能打的Agent評測集至少要從四個維度來構(gòu)建。第一個維度是意圖覆蓋也就是用戶可能提出的所有任務類型。比如一個客服智能體意圖可能包括查訂單、退換貨、咨詢政策、投訴建議等每個意圖下還要細分不同的子場景。這個維度決定了評測集的廣度。第二個維度是難度分層。同樣是查訂單有的用戶直接給訂單號有的用戶說“我上周買的那雙鞋”有的用戶說“幫我看看最近那個快遞到哪了”。難度從低到高評測集里都要有。我通常會把難度分為L1到L4四檔L1是明確指令L2是隱含意圖L3是多輪澄清L4是模糊或矛盾需求。生產(chǎn)環(huán)境里L3和L4的比例往往比我們想象的高得多。第三個維度是對抗樣本。這是最容易被忽略但最重要的部分。對抗樣本包括故意誘導智能體犯錯的提問、包含錯誤前提的問題、帶有情緒或攻擊性的表達、以及試圖繞過安全限制的嘗試。這些樣本不一定多但必須有因為它們暴露的是系統(tǒng)的魯棒性邊界。第四個維度是邊界條件。比如超長輸入、空輸入、特殊字符、多語言混合、工具調(diào)用失敗后的降級路徑等。這些場景在PoC階段很少遇到但在生產(chǎn)環(huán)境里遲早會出現(xiàn)。維度說明建議占比典型示例意圖覆蓋覆蓋所有業(yè)務意圖及子場景40%查訂單、退換貨、政策咨詢難度分層L1-L4難度均勻分布30%明確指令到模糊矛盾需求對抗樣本誘導犯錯、錯誤前提、攻擊性表達15%“你上次說的明明是...”邊界條件超長、空值、特殊字符、工具失敗15%輸入5000字、工具超時2.3 評測集的動態(tài)維護從生產(chǎn)流量中回流bad case評測集不是建完就完了它必須是一個活的東西。我的做法是建立一個bad case回流機制生產(chǎn)環(huán)境里每次用戶反饋“答得不對”或者人工抽檢發(fā)現(xiàn)問題的case都自動進入待評估隊列經(jīng)過脫敏和標注后定期補充到評測集里。這樣評測集就能跟著真實流量的變化一起進化。具體操作上可以在Agent的響應鏈路里加一個“用戶反饋”入口或者在客服系統(tǒng)里標記異常會話。每周花半小時把這些case過一遍判斷是模型問題、提示詞問題、還是工具問題然后決定是否加入評測集。這個習慣堅持三個月評測集的覆蓋度和殺傷力會有質(zhì)的提升。注意回流bad case時一定要做脫敏處理去掉用戶隱私信息同時要避免把個例當成普遍問題。我的經(jīng)驗是同一個問題模式出現(xiàn)三次以上才值得加入評測集。3. 自動評測與人工評測怎么分工Agent評測方法的選型與組合3.1 規(guī)則匹配、模型打分、人工評估的適用邊界Agent評測的方法大致分三類規(guī)則匹配、模型打分、人工評估。這三類不是互斥的而是要根據(jù)場景組合使用。規(guī)則匹配適合有明確答案的場景比如工具調(diào)用是否成功、返回格式是否符合預期、關(guān)鍵信息是否提取正確。它的優(yōu)點是快、便宜、可重復缺點是只能覆蓋確定性部分。模型打分適合評估開放性回答的質(zhì)量比如回答是否流暢、是否切題、是否有幫助。通常的做法是用一個更強的模型作為“裁判”給Agent的輸出打分。這里有個坑裁判模型和被評模型如果同源可能會有偏好偏差。我一般會用不同廠商的模型來做裁判或者至少用不同版本的模型。人工評估適合評估主觀性強、規(guī)則難以描述的場景比如語氣是否得體、是否體現(xiàn)了同理心、復雜多輪對話的整體體驗。人工評估的成本最高所以通常只用于抽樣驗證和校準自動評測的結(jié)果。評測方法適用場景成本一致性建議使用頻率規(guī)則匹配工具調(diào)用、格式校驗、關(guān)鍵信息提取低高每次迭代模型打分開放性回答質(zhì)量、切題度、有幫助性中中每次迭代人工評估語氣、同理心、多輪體驗、復雜判斷高低每周抽樣3.2 用LLM-as-Judge做規(guī)模化評測的實操細節(jié)LLM-as-Judge是目前最實用的規(guī)?；u測手段但要用好并不簡單。首先裁判提示詞的設(shè)計很關(guān)鍵。不能簡單地說“請給這個回答打分”而要給出明確的評分維度和評分標準。比如我會把評分拆成三個維度準確性信息是否正確、完整性是否覆蓋了用戶所有問題、安全性是否有不當內(nèi)容。每個維度1-5分最后加權(quán)匯總。其次要控制裁判模型的“寬容度”。實測發(fā)現(xiàn)如果不加約束裁判模型傾向于給高分。解決辦法是在提示詞里加入“如果你給滿分請說明為什么這個回答無可挑剔”這樣的要求迫使裁判模型更嚴格地審視。另外可以定期用人工標注的數(shù)據(jù)來校準裁判模型的打分分布如果發(fā)現(xiàn)裁判模型給分普遍偏高就調(diào)整提示詞或換一個更嚴格的裁判模型。還有一個細節(jié)是位置偏差。當讓裁判模型對比兩個回答時它往往傾向于選擇第一個或第二個。解決辦法是隨機打亂順序或者做雙向?qū)Ρ热∑骄＿@個坑我在早期項目中踩過后來加了隨機化之后評測結(jié)果的穩(wěn)定性明顯提升。3.3 人工評測的抽樣策略與標注規(guī)范人工評測雖然貴但不能完全省掉。我的做法是每次迭代從評測集里分層抽樣50-100條覆蓋所有意圖和難度層級由2-3個標注員獨立評估然后計算標注一致性。如果一致性低于80%說明評分標準不夠清晰需要重新對齊。標注規(guī)范要寫得足夠細。比如“準確性”這一項要明確什么算“完全正確”、什么算“部分正確”、什么算“錯誤”。最好每個等級都有示例。我見過很多團隊的人工評測結(jié)果不可用就是因為標注員對標準的理解不一致同一條case兩個人給出的分數(shù)差了兩分。提示人工評測的結(jié)果不要只用來算一個總分要保留每條case的詳細標注。這些標注數(shù)據(jù)是校準自動評測的寶貴資源也是分析Agent弱點的直接依據(jù)。4. 可觀測性不是加日志Agent鏈路的埋點設(shè)計與追蹤實現(xiàn)4.1 Agent可觀測性的特殊性多輪、多工具、多模型傳統(tǒng)服務的可觀測性主要關(guān)注請求量、延遲、錯誤率這些指標但Agent的可觀測性要復雜得多。因為一個用戶請求進來可能觸發(fā)多輪模型調(diào)用、多次工具調(diào)用、多次知識庫檢索每一步都有輸入輸出每一步都可能出錯。如果只記錄最終的輸入輸出中間過程就是黑盒出了問題根本沒法定位。我通常會把Agent的鏈路拆成幾個關(guān)鍵節(jié)點意圖識別、對話管理、工具選擇、工具調(diào)用、結(jié)果生成。每個節(jié)點都要記錄輸入、輸出、耗時、狀態(tài)。這樣當最終結(jié)果不對時可以逐節(jié)點排查看是哪一步偏了。比如用戶問“幫我退掉上周買的鞋”如果最終回答是“找不到訂單”你可以看是意圖識別錯了識別成了查訂單還是工具調(diào)用失敗了訂單查詢接口超時還是結(jié)果生成錯了查到了但沒正確表述。4.2 埋點數(shù)據(jù)模型Trace、Span、Event的三層結(jié)構(gòu)參考分布式追蹤的成熟經(jīng)驗Agent的可觀測性也可以用Trace、Span、Event三層結(jié)構(gòu)來組織。一個用戶請求對應一個TraceTrace下面有多個Span每個Span代表一個處理節(jié)點Span里面可以記錄多個Event代表節(jié)點內(nèi)的關(guān)鍵事件。具體來說Trace級別記錄會話ID、用戶ID、開始時間、總耗時、最終狀態(tài)。Span級別記錄節(jié)點名稱、輸入、輸出、耗時、狀態(tài)、使用的模型或工具。Event級別記錄更細粒度的事件比如“模型返回了工具調(diào)用請求”、“工具調(diào)用超時”、“觸發(fā)了降級策略”等。這種結(jié)構(gòu)的優(yōu)勢是既能宏觀地看整體鏈路又能微觀地定位具體問題。而且和現(xiàn)有的分布式追蹤系統(tǒng)如OpenTelemetry兼容可以直接接入現(xiàn)有的監(jiān)控平臺。# 一個簡化的Agent埋點示例 trace { trace_id: abc123, session_id: sess_456, user_id: user_789, start_time: 2024-01-15T10:00:00Z, spans: [ { span_id: span_1, name: intent_recognition, input: 幫我退掉上周買的鞋, output: {intent: return_goods, confidence: 0.92}, duration_ms: 320, status: success }, { span_id: span_2, name: tool_call, tool: order_query, input: {user_id: user_789, time_range: last_week}, output: {order_id: ORD_001, status: delivered}, duration_ms: 1500, status: success }, { span_id: span_3, name: response_generation, input: {order_info: {order_id: ORD_001}}, output: 已為您找到上周購買的訂單是否確認退貨, duration_ms: 800, status: success } ], total_duration_ms: 2620, status: success }4.3 關(guān)鍵指標的定義與采集延遲、成功率、工具調(diào)用準確率可觀測性不只是記錄鏈路還要定義和采集關(guān)鍵指標。對于Agent來說我重點關(guān)注這幾類指標延遲指標端到端延遲、各節(jié)點延遲、模型調(diào)用延遲、工具調(diào)用延遲。延遲的P99比平均值更重要因為長尾延遲直接影響用戶體驗。成功率指標整體成功率、各節(jié)點成功率、工具調(diào)用成功率、模型調(diào)用成功率。成功率要分維度看比如按意圖分、按用戶分、按時間段分。質(zhì)量指標工具調(diào)用準確率是否調(diào)用了正確的工具、參數(shù)提取準確率工具參數(shù)是否正確、回答相關(guān)性是否切題。這些指標需要結(jié)合評測體系來計算。成本指標每次會話的token消耗、模型調(diào)用次數(shù)、工具調(diào)用次數(shù)。成本指標在規(guī)?；髸兊梅浅Ｖ匾?。這些指標最好能實時采集并展示在監(jiān)控面板上這樣一旦出現(xiàn)異常能第一時間發(fā)現(xiàn)。我通常會在監(jiān)控面板上設(shè)置幾個告警規(guī)則端到端P99延遲超過閾值、工具調(diào)用成功率低于閾值、單次會話token消耗超過閾值。告警觸發(fā)后再通過Trace鏈路去定位具體原因。5. 生產(chǎn)環(huán)境的持續(xù)監(jiān)控從被動救火到主動發(fā)現(xiàn)5.1 在線評測用生產(chǎn)流量實時計算質(zhì)量指標評測不應該只發(fā)生在離線階段生產(chǎn)環(huán)境同樣需要在線評測。做法是在Agent的響應鏈路里嵌入輕量級的評測邏輯對每次響應實時計算質(zhì)量指標。比如可以用一個小模型快速判斷回答是否切題、是否有害、是否包含關(guān)鍵信息。這些指標不需要100%準確但能提供實時的質(zhì)量趨勢。在線評測的另一個用途是異常檢測。如果某個時間段內(nèi)質(zhì)量指標突然下降可能意味著上游數(shù)據(jù)分布發(fā)生了變化或者某個工具接口出了問題。這種主動發(fā)現(xiàn)比等用戶投訴要快得多。5.2 告警策略什么值得告警什么只是噪音告警策略的設(shè)計很考驗經(jīng)驗。告警太多團隊會麻木告警太少又會漏掉關(guān)鍵問題。我的原則是只對影響用戶體驗和業(yè)務指標的問題告警。具體來說端到端成功率低于95%、P99延遲超過5秒、工具調(diào)用失敗率超過10%、單次會話成本超過預算這些值得告警。而單個節(jié)點的偶發(fā)超時、個別用戶的異常輸入這些先記錄不告警等積累到一定量再分析。告警的閾值不要拍腦袋定最好基于歷史數(shù)據(jù)來定。比如先跑一周看各項指標的正常波動范圍然后把閾值設(shè)在正常范圍的邊界上。另外告警要分級P0是影響核心功能的需要立即處理P1是影響部分用戶的當天處理P2是體驗優(yōu)化的排期處理。5.3 根因定位從Trace鏈路快速縮小問題范圍當告警觸發(fā)后下一步就是根因定位。這時候Trace鏈路的價值就體現(xiàn)出來了。我通常的排查順序是先看整體成功率確定是全局問題還是局部問題然后按意圖、按工具、按模型版本分組看問題集中在哪個維度最后挑幾條失敗的Trace逐Span看是哪一步出了問題。舉個例子如果發(fā)現(xiàn)“退換貨”意圖的成功率突然下降而其他意圖正常那問題很可能出在退換貨相關(guān)的工具或提示詞上。再看Trace如果發(fā)現(xiàn)工具調(diào)用成功率正常但結(jié)果生成失敗率升高那可能是模型版本更新導致的。這種逐層縮小的排查方式比盲目看日志要高效得多。注意Trace數(shù)據(jù)的保留時間要合理設(shè)置。全量保留成本太高但只保留幾天又不夠排查歷史問題。我的做法是最近7天全量保留7天到30天只保留失敗的Trace和抽樣成功的Trace30天以上只保留聚合指標。6. 評測與可觀測性的聯(lián)動讓數(shù)據(jù)閉環(huán)驅(qū)動Agent迭代6.1 從監(jiān)控發(fā)現(xiàn)異常到評測集補充case的自動化路徑評測和可觀測性不是兩套獨立的系統(tǒng)它們應該形成一個閉環(huán)。生產(chǎn)監(jiān)控發(fā)現(xiàn)異常case自動進入評測集評測結(jié)果指導下一輪迭代迭代后的版本再通過評測驗證然后上線接受生產(chǎn)監(jiān)控。這個閉環(huán)轉(zhuǎn)得越快Agent的進化速度就越快。具體實現(xiàn)上可以在監(jiān)控系統(tǒng)里設(shè)置規(guī)則當某個Trace的最終狀態(tài)為失敗或者在線評測分數(shù)低于閾值時自動將該case脫敏后推送到評測集的待審核隊列。人工審核確認后加入評測集。這樣評測集就能持續(xù)吸收生產(chǎn)環(huán)境的新問題保持殺傷力。6.2 版本迭代中的回歸驗證新版本上線前的評測門禁每次Agent版本迭代無論是改提示詞、換模型、還是加工具都必須過評測門禁。門禁的規(guī)則可以設(shè)定為核心評測集的整體分數(shù)不能低于上一版本關(guān)鍵意圖的分數(shù)不能下降超過2%對抗樣本的通過率不能低于閾值。只有全部通過才允許上線。這個門禁機制聽起來簡單但執(zhí)行起來需要紀律。我見過不少團隊因為趕進度而跳過評測結(jié)果上線后出問題再回滾反而更浪費時間。我的建議是把評測門禁做成CI/CD流水線的一部分自動觸發(fā)、自動判斷、自動阻斷減少人為干預的空間。6.3 成本與質(zhì)量的平衡用可觀測性數(shù)據(jù)指導模型選型可觀測性數(shù)據(jù)不僅能用來排查問題還能指導模型選型。比如通過分析不同模型版本在相同評測集上的表現(xiàn)可以量化每個模型的質(zhì)量-成本比。有些場景用大模型效果只比小模型好一點點但成本高好幾倍那就可以考慮降級到小模型。有些場景小模型搞不定那就必須用大模型。我通常會做一個模型選型矩陣橫軸是質(zhì)量指標縱軸是成本指標把各個候選模型畫上去然后根據(jù)業(yè)務對質(zhì)量和成本的容忍度來選擇。這個矩陣的數(shù)據(jù)來源就是評測結(jié)果和可觀測性數(shù)據(jù)。有了這個矩陣模型選型就不再是拍腦袋而是有數(shù)據(jù)支撐的決策。模型版本評測集準確率平均延遲單次成本適用場景大模型A92%2.1s0.05元復雜意圖、多輪對話中模型B87%1.2s0.02元常規(guī)問答、工具調(diào)用小模型C78%0.6s0.005元簡單分類、意圖識別這張表在實際項目中非常有用。比如我們發(fā)現(xiàn)意圖識別用中模型B就夠了沒必要用大模型A一年下來能省不少成本。而結(jié)果生成環(huán)節(jié)因為對質(zhì)量要求高還是得用大模型A。這種精細化的分工就是靠評測和可觀測性數(shù)據(jù)來支撐的。7. 踩過的坑與實戰(zhàn)心得7.1 評測集過擬合為什么你的評測分數(shù)漲了但線上效果沒變這是我最開始做Agent評測時踩的最大的坑。當時團隊花了兩周時間精心構(gòu)建了一個500條的評測集然后針對這個評測集反復調(diào)優(yōu)提示詞看著分數(shù)從70%漲到90%大家都很開心。結(jié)果上線后發(fā)現(xiàn)用戶滿意度幾乎沒有變化。復盤才發(fā)現(xiàn)我們過度擬合了評測集——提示詞里加了很多針對特定case的規(guī)則但這些規(guī)則在真實流量里根本不通用。避免過擬合的方法有幾個一是評測集和訓練/調(diào)優(yōu)數(shù)據(jù)要嚴格分開調(diào)優(yōu)時不能看評測集的詳細結(jié)果只能看聚合分數(shù)二是定期用新回流的case替換評測集里的舊case保持評測集的新鮮度三是除了看總分還要看各維度的分數(shù)分布如果某個維度的分數(shù)異常高但其他維度沒變可能是過擬合的信號。7.2 可觀測性數(shù)據(jù)的存儲成本全量記錄還是采樣記錄可觀測性數(shù)據(jù)量很大全量記錄成本很高。我一開始也是全量記錄結(jié)果一個月下來存儲費用超預算好幾倍。后來改成分層采樣策略失敗的Trace全量記錄成功的Trace按10%采樣關(guān)鍵節(jié)點如工具調(diào)用全量記錄非關(guān)鍵節(jié)點如中間狀態(tài)只記錄摘要。這樣既保證了排查問題時有足夠的數(shù)據(jù)又把成本控制在了合理范圍。另外數(shù)據(jù)的保留時間也要分層。最近7天的數(shù)據(jù)查詢頻率最高保留全量7-30天的數(shù)據(jù)查詢頻率下降只保留聚合和失敗樣本30天以上的數(shù)據(jù)基本只用于趨勢分析保留聚合指標就夠了。7.3 工具調(diào)用超時的降級策略可觀測性如何幫你設(shè)計兜底方案工具調(diào)用超時是Agent生產(chǎn)環(huán)境里最常見的問題之一。沒有可觀測性的時候你只知道“工具調(diào)用失敗了”但不知道失敗率多高、哪些工具容易失敗、失敗后用戶經(jīng)歷了什么。有了可觀測性數(shù)據(jù)之后你可以量化每個工具的失敗率和延遲分布然后針對性地設(shè)計降級策略。比如我們發(fā)現(xiàn)訂單查詢接口的P99延遲是3秒失敗率2%。針對這個我們設(shè)計了三級降級第一級是重試一次第二級是返回緩存數(shù)據(jù)并提示“信息可能有延遲”第三級是轉(zhuǎn)人工客服。這個降級策略上線后工具調(diào)用相關(guān)的用戶投訴下降了70%。如果沒有可觀測性數(shù)據(jù)我們可能只會做一個簡單的“失敗就報錯”用戶體驗會差很多。7.4 多輪對話的評測難點如何判斷“追問”是澄清還是跑偏多輪對話的評測比單輪難得多因為“正確”的標準變得模糊了。比如用戶問“幫我退掉上周買的鞋”Agent追問“請問是哪一雙”這算澄清還是跑偏如果用戶上周只買了一雙鞋那這個追問就是多余的如果用戶買了三雙那這個追問就是必要的。判斷標準取決于上下文而上下文又很難在評測集里完整模擬。我的做法是對于多輪對話評測時不僅看最終結(jié)果還要看每一輪的意圖是否合理。具體來說會定義一個“追問合理性”指標如果Agent的追問能幫助縮小問題范圍且沒有重復詢問已知信息就算合理。這個指標需要人工標注一部分數(shù)據(jù)來校準然后訓練一個小的分類模型來自動判斷。8. 一些實操建議與工具選型參考8.1 評測框架的選型自建還是用開源評測框架的選擇取決于團隊規(guī)模和需求復雜度。如果只是簡單的規(guī)則匹配和模型打分自建一個輕量級的評測腳本就夠了幾十行代碼的事。如果需要復雜的多輪評測、人工標注管理、評測集版本控制那可以考慮用開源框架比如基于LangSmith、Weights Biases等平臺的評測功能或者用RAGAS這類專門針對RAG場景的評測庫。我的建議是PoC階段先自建快速跑通評測流程進入生產(chǎn)階段后如果評測需求變得復雜再考慮引入開源框架。不要一上來就上重型工具容易把時間花在工具配置上而不是評測本身。8.2 可觀測性接入OpenTelemetry在Agent場景的適配可觀測性方面OpenTelemetry是目前比較通用的標準。它的Trace、Span、Event模型和Agent的鏈路結(jié)構(gòu)很匹配而且有很多現(xiàn)成的后端可以接入如Jaeger、Zipkin、Grafana Tempo等。接入的方式也不復雜在Agent的每個處理節(jié)點加一個Span記錄輸入輸出和耗時然后通過OTLP協(xié)議上報。需要注意的是Agent的輸入輸出往往是自然語言文本數(shù)據(jù)量可能比較大。上報時要做截斷或摘要避免單條Trace過大。另外模型調(diào)用的token數(shù)、工具調(diào)用的參數(shù)等敏感信息要做好脫敏處理。8.3 小團隊的最小可行方案從零搭建評測與監(jiān)控的步驟對于小團隊或者剛起步的項目不需要一開始就建大而全的體系。我建議的最小可行方案是第一周整理50-100條評測case覆蓋核心意圖和常見難度用規(guī)則匹配做基礎(chǔ)評測。第二周在Agent鏈路里加基礎(chǔ)埋點記錄每個節(jié)點的輸入輸出和耗時輸出到日志文件。第三周寫一個簡單的腳本每天從日志里計算成功率、延遲、工具調(diào)用準確率等指標輸出到表格。第四周引入LLM-as-Judge做開放性回答的自動打分補充人工抽樣評估。第二個月把評測和監(jiān)控接入CI/CD每次迭代自動跑評測生產(chǎn)環(huán)境設(shè)置基礎(chǔ)告警。這個路徑不需要復雜的工具用Python腳本加一個數(shù)據(jù)庫就能跑起來。等業(yè)務量上來了再逐步替換成更專業(yè)的方案。8.4 團隊協(xié)作評測和可觀測性誰來負責最后聊一個容易被忽略的問題評測和可觀測性誰來負責我的經(jīng)驗是不能只交給算法工程師也不能只交給運維。最好的方式是有一個質(zhì)量工程的角色可以是兼職負責評測集維護、評測流程執(zhí)行、監(jiān)控面板搭建、告警響應。算法工程師負責根據(jù)評測結(jié)果調(diào)優(yōu)模型和提示詞運維負責保障監(jiān)控系統(tǒng)的穩(wěn)定性。在小團隊里這個角色往往由Tech Lead兼任。關(guān)鍵是有人對“質(zhì)量”這件事負責而不是出了問題大家一起救火。我見過的最好的實踐是每周固定一個“質(zhì)量會”花30分鐘過一遍評測結(jié)果和監(jiān)控指標討論本周發(fā)現(xiàn)的bad case和下周的改進計劃。這個習慣堅持下來Agent的質(zhì)量會穩(wěn)步提升。提示評測和可觀測性的建設(shè)是一個長期投入不要指望一蹴而就。從最小可行方案開始邊用邊完善比一開始就追求完美更實際。我在實際項目中的體會是AI智能體的交付質(zhì)量很大程度上不取決于模型有多強而取決于評測和可觀測性這套“基礎(chǔ)設(shè)施”有多扎實。模型可以換提示詞可以調(diào)但如果沒有一套可靠的評測和監(jiān)控體系所有的優(yōu)化都是盲人摸象。希望這些經(jīng)驗能幫你在從PoC到生產(chǎn)的路上少踩幾個坑。 AI智能體從PoC到生產(chǎn)：評測與可觀測性實戰(zhàn)指南
1. 從Demo驚艷到上線翻車AI智能體交付的斷層在哪里做過AI智能體項目的人大概都有類似的體驗在PoC階段用幾十條精心挑選的測試用例跑一遍效果驚艷團隊信心滿滿老板拍板推進?？梢坏┻M入真實業(yè)務流量各種問題就像開閘的水一樣涌出來——有的用戶問法稍微繞一點智能體就開始胡言亂語有的工具調(diào)用在測試環(huán)境好好的到了生產(chǎn)環(huán)境因為接口超時直接卡死更讓人頭疼的是你根本不知道它為什么出錯因為整個鏈路就像一個黑盒輸入進去、輸出出來中間發(fā)生了什么全靠猜。這個斷層不是模型能力的問題而是工程化交付的問題。PoC階段關(guān)注的是“能不能做出來”生產(chǎn)階段關(guān)注的是“能不能穩(wěn)定地做對”。這兩件事之間的鴻溝需要用評測體系和可觀測性來填。評測解決的是“怎么知道它做得好不好”可觀測性解決的是“它為什么做得不好”。兩者缺一不可而且必須從PoC階段就開始搭不能等到上線前才臨時抱佛腳。我見過太多團隊在PoC階段只關(guān)注“跑通”把評測簡化成人工看幾條case把日志簡化成print大法。結(jié)果到了生產(chǎn)環(huán)境面對每天幾千上萬次調(diào)用既沒有自動化的質(zhì)量度量也沒有細粒度的鏈路追蹤出了問題只能靠用戶截圖反饋來定位。這種狀態(tài)下智能體的迭代基本靠玄學今天修好一個bug明天可能又引入兩個新問題。所以這篇文章想聊的就是怎么在AI智能體項目里從第一天起就把評測和可觀測性當成基礎(chǔ)設(shè)施來建。不是那種“等有空了再補”的附屬品而是和業(yè)務邏輯同等重要的核心組件。我會從評測集的設(shè)計、評測方法的選型、可觀測性的埋點策略、鏈路追蹤的實現(xiàn)、以及生產(chǎn)環(huán)境的持續(xù)監(jiān)控這幾個維度展開盡量把每個環(huán)節(jié)的“為什么”和“怎么做”都講清楚。2. 評測集不是測試用例的堆砌構(gòu)建能反映真實分布的Agent評測體系2.1 為什么傳統(tǒng)測試用例在Agent場景下不夠用傳統(tǒng)軟件測試的思路是給定輸入驗證輸出是否等于預期。這套邏輯在確定性系統(tǒng)里很好用但放到AI智能體上就完全失效了。因為智能體的輸出不是確定性的同一個問題換一種問法可能得到完全不同的回答同一個回答在不同上下文里正確性判斷標準也不一樣。更麻煩的是智能體往往涉及多輪對話和工具調(diào)用中間任何一步出偏差最終結(jié)果就可能南轅北轍。我剛開始做Agent評測的時候也犯過“把測試用例當評測集”的錯誤。當時整理了200條問答對每條都有標準答案跑完一看準確率85%覺得還不錯。結(jié)果上線后發(fā)現(xiàn)用戶的實際問法千奇百怪那200條用例覆蓋的場景連真實流量的20%都不到。后來復盤才明白評測集的核心不是“數(shù)量”而是“分布”。它必須能反映真實用戶請求的多樣性包括不同的問法、不同的意圖組合、不同的上下文長度、不同的工具調(diào)用路徑。2.2 評測集的四個維度意圖覆蓋、難度分層、對抗樣本、邊界條件一個能打的Agent評測集至少要從四個維度來構(gòu)建。第一個維度是意圖覆蓋也就是用戶可能提出的所有任務類型。比如一個客服智能體意圖可能包括查訂單、退換貨、咨詢政策、投訴建議等每個意圖下還要細分不同的子場景。這個維度決定了評測集的廣度。第二個維度是難度分層。同樣是查訂單有的用戶直接給訂單號有的用戶說“我上周買的那雙鞋”有的用戶說“幫我看看最近那個快遞到哪了”。難度從低到高評測集里都要有。我通常會把難度分為L1到L4四檔L1是明確指令L2是隱含意圖L3是多輪澄清L4是模糊或矛盾需求。生產(chǎn)環(huán)境里L3和L4的比例往往比我們想象的高得多。第三個維度是對抗樣本。這是最容易被忽略但最重要的部分。對抗樣本包括故意誘導智能體犯錯的提問、包含錯誤前提的問題、帶有情緒或攻擊性的表達、以及試圖繞過安全限制的嘗試。這些樣本不一定多但必須有因為它們暴露的是系統(tǒng)的魯棒性邊界。第四個維度是邊界條件。比如超長輸入、空輸入、特殊字符、多語言混合、工具調(diào)用失敗后的降級路徑等。這些場景在PoC階段很少遇到但在生產(chǎn)環(huán)境里遲早會出現(xiàn)。維度說明建議占比典型示例意圖覆蓋覆蓋所有業(yè)務意圖及子場景40%查訂單、退換貨、政策咨詢難度分層L1-L4難度均勻分布30%明確指令到模糊矛盾需求對抗樣本誘導犯錯、錯誤前提、攻擊性表達15%“你上次說的明明是...”邊界條件超長、空值、特殊字符、工具失敗15%輸入5000字、工具超時2.3 評測集的動態(tài)維護從生產(chǎn)流量中回流bad case評測集不是建完就完了它必須是一個活的東西。我的做法是建立一個bad case回流機制生產(chǎn)環(huán)境里每次用戶反饋“答得不對”或者人工抽檢發(fā)現(xiàn)問題的case都自動進入待評估隊列經(jīng)過脫敏和標注后定期補充到評測集里。這樣評測集就能跟著真實流量的變化一起進化。具體操作上可以在Agent的響應鏈路里加一個“用戶反饋”入口或者在客服系統(tǒng)里標記異常會話。每周花半小時把這些case過一遍判斷是模型問題、提示詞問題、還是工具問題然后決定是否加入評測集。這個習慣堅持三個月評測集的覆蓋度和殺傷力會有質(zhì)的提升。注意回流bad case時一定要做脫敏處理去掉用戶隱私信息同時要避免把個例當成普遍問題。我的經(jīng)驗是同一個問題模式出現(xiàn)三次以上才值得加入評測集。3. 自動評測與人工評測怎么分工Agent評測方法的選型與組合3.1 規(guī)則匹配、模型打分、人工評估的適用邊界Agent評測的方法大致分三類規(guī)則匹配、模型打分、人工評估。這三類不是互斥的而是要根據(jù)場景組合使用。規(guī)則匹配適合有明確答案的場景比如工具調(diào)用是否成功、返回格式是否符合預期、關(guān)鍵信息是否提取正確。它的優(yōu)點是快、便宜、可重復缺點是只能覆蓋確定性部分。模型打分適合評估開放性回答的質(zhì)量比如回答是否流暢、是否切題、是否有幫助。通常的做法是用一個更強的模型作為“裁判”給Agent的輸出打分。這里有個坑裁判模型和被評模型如果同源可能會有偏好偏差。我一般會用不同廠商的模型來做裁判或者至少用不同版本的模型。人工評估適合評估主觀性強、規(guī)則難以描述的場景比如語氣是否得體、是否體現(xiàn)了同理心、復雜多輪對話的整體體驗。人工評估的成本最高所以通常只用于抽樣驗證和校準自動評測的結(jié)果。評測方法適用場景成本一致性建議使用頻率規(guī)則匹配工具調(diào)用、格式校驗、關(guān)鍵信息提取低高每次迭代模型打分開放性回答質(zhì)量、切題度、有幫助性中中每次迭代人工評估語氣、同理心、多輪體驗、復雜判斷高低每周抽樣3.2 用LLM-as-Judge做規(guī)模化評測的實操細節(jié)LLM-as-Judge是目前最實用的規(guī)?；u測手段但要用好并不簡單。首先裁判提示詞的設(shè)計很關(guān)鍵。不能簡單地說“請給這個回答打分”而要給出明確的評分維度和評分標準。比如我會把評分拆成三個維度準確性信息是否正確、完整性是否覆蓋了用戶所有問題、安全性是否有不當內(nèi)容。每個維度1-5分最后加權(quán)匯總。其次要控制裁判模型的“寬容度”。實測發(fā)現(xiàn)如果不加約束裁判模型傾向于給高分。解決辦法是在提示詞里加入“如果你給滿分請說明為什么這個回答無可挑剔”這樣的要求迫使裁判模型更嚴格地審視。另外可以定期用人工標注的數(shù)據(jù)來校準裁判模型的打分分布如果發(fā)現(xiàn)裁判模型給分普遍偏高就調(diào)整提示詞或換一個更嚴格的裁判模型。還有一個細節(jié)是位置偏差。當讓裁判模型對比兩個回答時它往往傾向于選擇第一個或第二個。解決辦法是隨機打亂順序或者做雙向?qū)Ρ热∑骄＿@個坑我在早期項目中踩過后來加了隨機化之后評測結(jié)果的穩(wěn)定性明顯提升。3.3 人工評測的抽樣策略與標注規(guī)范人工評測雖然貴但不能完全省掉。我的做法是每次迭代從評測集里分層抽樣50-100條覆蓋所有意圖和難度層級由2-3個標注員獨立評估然后計算標注一致性。如果一致性低于80%說明評分標準不夠清晰需要重新對齊。標注規(guī)范要寫得足夠細。比如“準確性”這一項要明確什么算“完全正確”、什么算“部分正確”、什么算“錯誤”。最好每個等級都有示例。我見過很多團隊的人工評測結(jié)果不可用就是因為標注員對標準的理解不一致同一條case兩個人給出的分數(shù)差了兩分。提示人工評測的結(jié)果不要只用來算一個總分要保留每條case的詳細標注。這些標注數(shù)據(jù)是校準自動評測的寶貴資源也是分析Agent弱點的直接依據(jù)。4. 可觀測性不是加日志Agent鏈路的埋點設(shè)計與追蹤實現(xiàn)4.1 Agent可觀測性的特殊性多輪、多工具、多模型傳統(tǒng)服務的可觀測性主要關(guān)注請求量、延遲、錯誤率這些指標但Agent的可觀測性要復雜得多。因為一個用戶請求進來可能觸發(fā)多輪模型調(diào)用、多次工具調(diào)用、多次知識庫檢索每一步都有輸入輸出每一步都可能出錯。如果只記錄最終的輸入輸出中間過程就是黑盒出了問題根本沒法定位。我通常會把Agent的鏈路拆成幾個關(guān)鍵節(jié)點意圖識別、對話管理、工具選擇、工具調(diào)用、結(jié)果生成。每個節(jié)點都要記錄輸入、輸出、耗時、狀態(tài)。這樣當最終結(jié)果不對時可以逐節(jié)點排查看是哪一步偏了。比如用戶問“幫我退掉上周買的鞋”如果最終回答是“找不到訂單”你可以看是意圖識別錯了識別成了查訂單還是工具調(diào)用失敗了訂單查詢接口超時還是結(jié)果生成錯了查到了但沒正確表述。4.2 埋點數(shù)據(jù)模型Trace、Span、Event的三層結(jié)構(gòu)參考分布式追蹤的成熟經(jīng)驗Agent的可觀測性也可以用Trace、Span、Event三層結(jié)構(gòu)來組織。一個用戶請求對應一個TraceTrace下面有多個Span每個Span代表一個處理節(jié)點Span里面可以記錄多個Event代表節(jié)點內(nèi)的關(guān)鍵事件。具體來說Trace級別記錄會話ID、用戶ID、開始時間、總耗時、最終狀態(tài)。Span級別記錄節(jié)點名稱、輸入、輸出、耗時、狀態(tài)、使用的模型或工具。Event級別記錄更細粒度的事件比如“模型返回了工具調(diào)用請求”、“工具調(diào)用超時”、“觸發(fā)了降級策略”等。這種結(jié)構(gòu)的優(yōu)勢是既能宏觀地看整體鏈路又能微觀地定位具體問題。而且和現(xiàn)有的分布式追蹤系統(tǒng)如OpenTelemetry兼容可以直接接入現(xiàn)有的監(jiān)控平臺。# 一個簡化的Agent埋點示例 trace { trace_id: abc123, session_id: sess_456, user_id: user_789, start_time: 2024-01-15T10:00:00Z, spans: [ { span_id: span_1, name: intent_recognition, input: 幫我退掉上周買的鞋, output: {intent: return_goods, confidence: 0.92}, duration_ms: 320, status: success }, { span_id: span_2, name: tool_call, tool: order_query, input: {user_id: user_789, time_range: last_week}, output: {order_id: ORD_001, status: delivered}, duration_ms: 1500, status: success }, { span_id: span_3, name: response_generation, input: {order_info: {order_id: ORD_001}}, output: 已為您找到上周購買的訂單是否確認退貨, duration_ms: 800, status: success } ], total_duration_ms: 2620, status: success }4.3 關(guān)鍵指標的定義與采集延遲、成功率、工具調(diào)用準確率可觀測性不只是記錄鏈路還要定義和采集關(guān)鍵指標。對于Agent來說我重點關(guān)注這幾類指標延遲指標端到端延遲、各節(jié)點延遲、模型調(diào)用延遲、工具調(diào)用延遲。延遲的P99比平均值更重要因為長尾延遲直接影響用戶體驗。成功率指標整體成功率、各節(jié)點成功率、工具調(diào)用成功率、模型調(diào)用成功率。成功率要分維度看比如按意圖分、按用戶分、按時間段分。質(zhì)量指標工具調(diào)用準確率是否調(diào)用了正確的工具、參數(shù)提取準確率工具參數(shù)是否正確、回答相關(guān)性是否切題。這些指標需要結(jié)合評測體系來計算。成本指標每次會話的token消耗、模型調(diào)用次數(shù)、工具調(diào)用次數(shù)。成本指標在規(guī)?；髸兊梅浅Ｖ匾?。這些指標最好能實時采集并展示在監(jiān)控面板上這樣一旦出現(xiàn)異常能第一時間發(fā)現(xiàn)。我通常會在監(jiān)控面板上設(shè)置幾個告警規(guī)則端到端P99延遲超過閾值、工具調(diào)用成功率低于閾值、單次會話token消耗超過閾值。告警觸發(fā)后再通過Trace鏈路去定位具體原因。5. 生產(chǎn)環(huán)境的持續(xù)監(jiān)控從被動救火到主動發(fā)現(xiàn)5.1 在線評測用生產(chǎn)流量實時計算質(zhì)量指標評測不應該只發(fā)生在離線階段生產(chǎn)環(huán)境同樣需要在線評測。做法是在Agent的響應鏈路里嵌入輕量級的評測邏輯對每次響應實時計算質(zhì)量指標。比如可以用一個小模型快速判斷回答是否切題、是否有害、是否包含關(guān)鍵信息。這些指標不需要100%準確但能提供實時的質(zhì)量趨勢。在線評測的另一個用途是異常檢測。如果某個時間段內(nèi)質(zhì)量指標突然下降可能意味著上游數(shù)據(jù)分布發(fā)生了變化或者某個工具接口出了問題。這種主動發(fā)現(xiàn)比等用戶投訴要快得多。5.2 告警策略什么值得告警什么只是噪音告警策略的設(shè)計很考驗經(jīng)驗。告警太多團隊會麻木告警太少又會漏掉關(guān)鍵問題。我的原則是只對影響用戶體驗和業(yè)務指標的問題告警。具體來說端到端成功率低于95%、P99延遲超過5秒、工具調(diào)用失敗率超過10%、單次會話成本超過預算這些值得告警。而單個節(jié)點的偶發(fā)超時、個別用戶的異常輸入這些先記錄不告警等積累到一定量再分析。告警的閾值不要拍腦袋定最好基于歷史數(shù)據(jù)來定。比如先跑一周看各項指標的正常波動范圍然后把閾值設(shè)在正常范圍的邊界上。另外告警要分級P0是影響核心功能的需要立即處理P1是影響部分用戶的當天處理P2是體驗優(yōu)化的排期處理。5.3 根因定位從Trace鏈路快速縮小問題范圍當告警觸發(fā)后下一步就是根因定位。這時候Trace鏈路的價值就體現(xiàn)出來了。我通常的排查順序是先看整體成功率確定是全局問題還是局部問題然后按意圖、按工具、按模型版本分組看問題集中在哪個維度最后挑幾條失敗的Trace逐Span看是哪一步出了問題。舉個例子如果發(fā)現(xiàn)“退換貨”意圖的成功率突然下降而其他意圖正常那問題很可能出在退換貨相關(guān)的工具或提示詞上。再看Trace如果發(fā)現(xiàn)工具調(diào)用成功率正常但結(jié)果生成失敗率升高那可能是模型版本更新導致的。這種逐層縮小的排查方式比盲目看日志要高效得多。注意Trace數(shù)據(jù)的保留時間要合理設(shè)置。全量保留成本太高但只保留幾天又不夠排查歷史問題。我的做法是最近7天全量保留7天到30天只保留失敗的Trace和抽樣成功的Trace30天以上只保留聚合指標。6. 評測與可觀測性的聯(lián)動讓數(shù)據(jù)閉環(huán)驅(qū)動Agent迭代6.1 從監(jiān)控發(fā)現(xiàn)異常到評測集補充case的自動化路徑評測和可觀測性不是兩套獨立的系統(tǒng)它們應該形成一個閉環(huán)。生產(chǎn)監(jiān)控發(fā)現(xiàn)異常case自動進入評測集評測結(jié)果指導下一輪迭代迭代后的版本再通過評測驗證然后上線接受生產(chǎn)監(jiān)控。這個閉環(huán)轉(zhuǎn)得越快Agent的進化速度就越快。具體實現(xiàn)上可以在監(jiān)控系統(tǒng)里設(shè)置規(guī)則當某個Trace的最終狀態(tài)為失敗或者在線評測分數(shù)低于閾值時自動將該case脫敏后推送到評測集的待審核隊列。人工審核確認后加入評測集。這樣評測集就能持續(xù)吸收生產(chǎn)環(huán)境的新問題保持殺傷力。6.2 版本迭代中的回歸驗證新版本上線前的評測門禁每次Agent版本迭代無論是改提示詞、換模型、還是加工具都必須過評測門禁。門禁的規(guī)則可以設(shè)定為核心評測集的整體分數(shù)不能低于上一版本關(guān)鍵意圖的分數(shù)不能下降超過2%對抗樣本的通過率不能低于閾值。只有全部通過才允許上線。這個門禁機制聽起來簡單但執(zhí)行起來需要紀律。我見過不少團隊因為趕進度而跳過評測結(jié)果上線后出問題再回滾反而更浪費時間。我的建議是把評測門禁做成CI/CD流水線的一部分自動觸發(fā)、自動判斷、自動阻斷減少人為干預的空間。6.3 成本與質(zhì)量的平衡用可觀測性數(shù)據(jù)指導模型選型可觀測性數(shù)據(jù)不僅能用來排查問題還能指導模型選型。比如通過分析不同模型版本在相同評測集上的表現(xiàn)可以量化每個模型的質(zhì)量-成本比。有些場景用大模型效果只比小模型好一點點但成本高好幾倍那就可以考慮降級到小模型。有些場景小模型搞不定那就必須用大模型。我通常會做一個模型選型矩陣橫軸是質(zhì)量指標縱軸是成本指標把各個候選模型畫上去然后根據(jù)業(yè)務對質(zhì)量和成本的容忍度來選擇。這個矩陣的數(shù)據(jù)來源就是評測結(jié)果和可觀測性數(shù)據(jù)。有了這個矩陣模型選型就不再是拍腦袋而是有數(shù)據(jù)支撐的決策。模型版本評測集準確率平均延遲單次成本適用場景大模型A92%2.1s0.05元復雜意圖、多輪對話中模型B87%1.2s0.02元常規(guī)問答、工具調(diào)用小模型C78%0.6s0.005元簡單分類、意圖識別這張表在實際項目中非常有用。比如我們發(fā)現(xiàn)意圖識別用中模型B就夠了沒必要用大模型A一年下來能省不少成本。而結(jié)果生成環(huán)節(jié)因為對質(zhì)量要求高還是得用大模型A。這種精細化的分工就是靠評測和可觀測性數(shù)據(jù)來支撐的。7. 踩過的坑與實戰(zhàn)心得7.1 評測集過擬合為什么你的評測分數(shù)漲了但線上效果沒變這是我最開始做Agent評測時踩的最大的坑。當時團隊花了兩周時間精心構(gòu)建了一個500條的評測集然后針對這個評測集反復調(diào)優(yōu)提示詞看著分數(shù)從70%漲到90%大家都很開心。結(jié)果上線后發(fā)現(xiàn)用戶滿意度幾乎沒有變化。復盤才發(fā)現(xiàn)我們過度擬合了評測集——提示詞里加了很多針對特定case的規(guī)則但這些規(guī)則在真實流量里根本不通用。避免過擬合的方法有幾個一是評測集和訓練/調(diào)優(yōu)數(shù)據(jù)要嚴格分開調(diào)優(yōu)時不能看評測集的詳細結(jié)果只能看聚合分數(shù)二是定期用新回流的case替換評測集里的舊case保持評測集的新鮮度三是除了看總分還要看各維度的分數(shù)分布如果某個維度的分數(shù)異常高但其他維度沒變可能是過擬合的信號。7.2 可觀測性數(shù)據(jù)的存儲成本全量記錄還是采樣記錄可觀測性數(shù)據(jù)量很大全量記錄成本很高。我一開始也是全量記錄結(jié)果一個月下來存儲費用超預算好幾倍。后來改成分層采樣策略失敗的Trace全量記錄成功的Trace按10%采樣關(guān)鍵節(jié)點如工具調(diào)用全量記錄非關(guān)鍵節(jié)點如中間狀態(tài)只記錄摘要。這樣既保證了排查問題時有足夠的數(shù)據(jù)又把成本控制在了合理范圍。另外數(shù)據(jù)的保留時間也要分層。最近7天的數(shù)據(jù)查詢頻率最高保留全量7-30天的數(shù)據(jù)查詢頻率下降只保留聚合和失敗樣本30天以上的數(shù)據(jù)基本只用于趨勢分析保留聚合指標就夠了。7.3 工具調(diào)用超時的降級策略可觀測性如何幫你設(shè)計兜底方案工具調(diào)用超時是Agent生產(chǎn)環(huán)境里最常見的問題之一。沒有可觀測性的時候你只知道“工具調(diào)用失敗了”但不知道失敗率多高、哪些工具容易失敗、失敗后用戶經(jīng)歷了什么。有了可觀測性數(shù)據(jù)之后你可以量化每個工具的失敗率和延遲分布然后針對性地設(shè)計降級策略。比如我們發(fā)現(xiàn)訂單查詢接口的P99延遲是3秒失敗率2%。針對這個我們設(shè)計了三級降級第一級是重試一次第二級是返回緩存數(shù)據(jù)并提示“信息可能有延遲”第三級是轉(zhuǎn)人工客服。這個降級策略上線后工具調(diào)用相關(guān)的用戶投訴下降了70%。如果沒有可觀測性數(shù)據(jù)我們可能只會做一個簡單的“失敗就報錯”用戶體驗會差很多。7.4 多輪對話的評測難點如何判斷“追問”是澄清還是跑偏多輪對話的評測比單輪難得多因為“正確”的標準變得模糊了。比如用戶問“幫我退掉上周買的鞋”Agent追問“請問是哪一雙”這算澄清還是跑偏如果用戶上周只買了一雙鞋那這個追問就是多余的如果用戶買了三雙那這個追問就是必要的。判斷標準取決于上下文而上下文又很難在評測集里完整模擬。我的做法是對于多輪對話評測時不僅看最終結(jié)果還要看每一輪的意圖是否合理。具體來說會定義一個“追問合理性”指標如果Agent的追問能幫助縮小問題范圍且沒有重復詢問已知信息就算合理。這個指標需要人工標注一部分數(shù)據(jù)來校準然后訓練一個小的分類模型來自動判斷。8. 一些實操建議與工具選型參考8.1 評測框架的選型自建還是用開源評測框架的選擇取決于團隊規(guī)模和需求復雜度。如果只是簡單的規(guī)則匹配和模型打分自建一個輕量級的評測腳本就夠了幾十行代碼的事。如果需要復雜的多輪評測、人工標注管理、評測集版本控制那可以考慮用開源框架比如基于LangSmith、Weights Biases等平臺的評測功能或者用RAGAS這類專門針對RAG場景的評測庫。我的建議是PoC階段先自建快速跑通評測流程進入生產(chǎn)階段后如果評測需求變得復雜再考慮引入開源框架。不要一上來就上重型工具容易把時間花在工具配置上而不是評測本身。8.2 可觀測性接入OpenTelemetry在Agent場景的適配可觀測性方面OpenTelemetry是目前比較通用的標準。它的Trace、Span、Event模型和Agent的鏈路結(jié)構(gòu)很匹配而且有很多現(xiàn)成的后端可以接入如Jaeger、Zipkin、Grafana Tempo等。接入的方式也不復雜在Agent的每個處理節(jié)點加一個Span記錄輸入輸出和耗時然后通過OTLP協(xié)議上報。需要注意的是Agent的輸入輸出往往是自然語言文本數(shù)據(jù)量可能比較大。上報時要做截斷或摘要避免單條Trace過大。另外模型調(diào)用的token數(shù)、工具調(diào)用的參數(shù)等敏感信息要做好脫敏處理。8.3 小團隊的最小可行方案從零搭建評測與監(jiān)控的步驟對于小團隊或者剛起步的項目不需要一開始就建大而全的體系。我建議的最小可行方案是第一周整理50-100條評測case覆蓋核心意圖和常見難度用規(guī)則匹配做基礎(chǔ)評測。第二周在Agent鏈路里加基礎(chǔ)埋點記錄每個節(jié)點的輸入輸出和耗時輸出到日志文件。第三周寫一個簡單的腳本每天從日志里計算成功率、延遲、工具調(diào)用準確率等指標輸出到表格。第四周引入LLM-as-Judge做開放性回答的自動打分補充人工抽樣評估。第二個月把評測和監(jiān)控接入CI/CD每次迭代自動跑評測生產(chǎn)環(huán)境設(shè)置基礎(chǔ)告警。這個路徑不需要復雜的工具用Python腳本加一個數(shù)據(jù)庫就能跑起來。等業(yè)務量上來了再逐步替換成更專業(yè)的方案。8.4 團隊協(xié)作評測和可觀測性誰來負責最后聊一個容易被忽略的問題評測和可觀測性誰來負責我的經(jīng)驗是不能只交給算法工程師也不能只交給運維。最好的方式是有一個質(zhì)量工程的角色可以是兼職負責評測集維護、評測流程執(zhí)行、監(jiān)控面板搭建、告警響應。算法工程師負責根據(jù)評測結(jié)果調(diào)優(yōu)模型和提示詞運維負責保障監(jiān)控系統(tǒng)的穩(wěn)定性。在小團隊里這個角色往往由Tech Lead兼任。關(guān)鍵是有人對“質(zhì)量”這件事負責而不是出了問題大家一起救火。我見過的最好的實踐是每周固定一個“質(zhì)量會”花30分鐘過一遍評測結(jié)果和監(jiān)控指標討論本周發(fā)現(xiàn)的bad case和下周的改進計劃。這個習慣堅持下來Agent的質(zhì)量會穩(wěn)步提升。提示評測和可觀測性的建設(shè)是一個長期投入不要指望一蹴而就。從最小可行方案開始邊用邊完善比一開始就追求完美更實際。我在實際項目中的體會是AI智能體的交付質(zhì)量很大程度上不取決于模型有多強而取決于評測和可觀測性這套“基礎(chǔ)設(shè)施”有多扎實。模型可以換提示詞可以調(diào)但如果沒有一套可靠的評測和監(jiān)控體系所有的優(yōu)化都是盲人摸象。希望這些經(jīng)驗能幫你在從PoC到生產(chǎn)的路上少踩幾個坑。