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