測(cè)體系：LLM-as-Judge、人工標(biāo)注與A/B測(cè)試實(shí)戰(zhàn))
工作里只要沾過AI Agent開發(fā)十有八九會(huì)碰上一個(gè)靈魂拷問這Agent到底行不行我自己的評(píng)測(cè)框架從v1.0一路迭代到現(xiàn)在的21.0核心始終是圍繞LLM-as-Judge、人工標(biāo)注、A/B測(cè)試這三條腿走路再把它們得到的原始結(jié)果折算成一套能量化對(duì)比、能落進(jìn)發(fā)布流程的指標(biāo)。這篇內(nèi)容就是把我這些年踩過的坑和最終沉淀下來的多維評(píng)測(cè)實(shí)踐完整拆開講一遍。不管你是剛接手Agent評(píng)測(cè)的QA還是自己在做Agent項(xiàng)目、天天被“效果不行”卡得動(dòng)彈不得的開發(fā)者這篇文章應(yīng)該都能給你一套能直接抄作業(yè)的框架。1. 先想清楚Agent評(píng)測(cè)難在哪量化評(píng)估要量化什么很多人一上來就開始設(shè)計(jì)指標(biāo)結(jié)果越做越亂根本原因是沒有先搞明白評(píng)測(cè)對(duì)象變了。Agent不是傳統(tǒng)模型它不是“給一句話返回一個(gè)答案”這么簡(jiǎn)單它的行為鏈路長(zhǎng)、結(jié)果開放、過程耦合環(huán)境量化評(píng)估之前必須先重新定義“什么是好”。1.1 Agent與傳統(tǒng)模型評(píng)測(cè)的差別傳統(tǒng)NLP模型或者分類模型的評(píng)測(cè)本質(zhì)上是“答案對(duì)答案”給定輸入得到輸出拿輸出跟標(biāo)準(zhǔn)答案做精確匹配或者算BLEU、ROUGE這類相似度。這個(gè)過程目標(biāo)單一、環(huán)境可控、結(jié)果確定性高。到了Agent這里情況完全變了。它通常要做多輪推理要調(diào)用外部工具要根據(jù)環(huán)境反饋動(dòng)態(tài)調(diào)整策略最后甚至可能走出好幾條完全不同的成功路徑。舉個(gè)實(shí)際例子一個(gè)客服Agent處理“用戶想改收貨地址”這個(gè)任務(wù)。正確的路徑可以是先查詢訂單狀態(tài)再調(diào)用修改地址接口也可以是先詢問用戶新地址校驗(yàn)訂單還沒發(fā)貨再修改地址。兩條路結(jié)果一樣但中間過程差別很大。如果你還是只比對(duì)最終輸出文本那幾乎沒法做自動(dòng)化評(píng)估。Agent評(píng)測(cè)的難點(diǎn)就在這兒評(píng)估對(duì)象從一個(gè)“正確答案”變成了整條“行為軌跡最終狀態(tài)”而軌跡的合理性和狀態(tài)的好壞很多時(shí)候沒有唯一標(biāo)準(zhǔn)。這也是為什么量化評(píng)估不能只盯著“能不能完成任務(wù)”這一個(gè)點(diǎn)。你需要同時(shí)回答幾個(gè)問題任務(wù)完成得對(duì)不對(duì)完成得順不順過程中有沒有亂來代價(jià)高不高。這幾個(gè)問題對(duì)應(yīng)著完全不同的評(píng)估手段和指標(biāo)得拆開來看。1.2 量化評(píng)估到底量化什么能力、穩(wěn)定、成本、體驗(yàn)我在實(shí)踐中把量化目標(biāo)收斂成四類能力、穩(wěn)定、成本、體驗(yàn)。能力是最基礎(chǔ)的一層回答“這個(gè)Agent能不能完成它該做的事”。落地到指標(biāo)上就是任務(wù)成功率、子步驟完成率、工具調(diào)用正確率等。穩(wěn)定是很多團(tuán)隊(duì)容易忽略的一層。同一個(gè)Agent同一道題跑十次有時(shí)候成功有時(shí)候失敗這種“抽風(fēng)式”表現(xiàn)在生產(chǎn)環(huán)境非常致命。所以評(píng)測(cè)必須有重復(fù)運(yùn)行的概念至少要反映方差而不是只看均值。成本層必須考慮因?yàn)锳gent的消耗往往比傳統(tǒng)模型高一個(gè)量級(jí)。一次任務(wù)可能要多次調(diào)用大模型加上工具調(diào)用的附加費(fèi)用單task成本很容易就上去了。如果能力合格但成本高到?jīng)]法規(guī)?；沁@個(gè)Agent照樣上不了線。體驗(yàn)層則更主觀包括用戶覺得順不順、回答是否友好、有沒有不安全的表述。體驗(yàn)類指標(biāo)很難用精確匹配來度量這正是LLM-as-Judge和人工標(biāo)注的用武之地。1.3 從v1.0到v21.0我踩過的三個(gè)大坑早期我的評(píng)測(cè)體系就是v1.0只有“準(zhǔn)確率”一個(gè)指標(biāo)拿一批固定問題測(cè)一遍算個(gè)百分比就完事。結(jié)果上線第一周就被打臉業(yè)務(wù)方反饋一堆問題成功率看著90%實(shí)際問題基本辦不成。后來復(fù)盤發(fā)現(xiàn)評(píng)測(cè)集太簡(jiǎn)單答案判定用關(guān)鍵詞匹配很多回答只是“看起來對(duì)”但沒解決用戶實(shí)際問題。v5.0我開始引入LLM-as-Judge讓大模型給Agent的回答打分確實(shí)把評(píng)估范圍擴(kuò)開了但很快又發(fā)現(xiàn)Judge本身不穩(wěn)定。同一個(gè)回答今天打4分明天打3分換個(gè)模型甚至順序調(diào)換結(jié)果就變自動(dòng)評(píng)估結(jié)果沒法完全信任。v12.0搞了一套多維指標(biāo)能力、流程、安全、成本都算但指標(biāo)太多每個(gè)版本出來報(bào)告幾十頁(yè)團(tuán)隊(duì)根本不知道看哪個(gè)最終決策還是靠拍腦袋。直到v21.0才徹底理順三條腿各自分工LLM-as-Judge負(fù)責(zé)批量初篩人工標(biāo)注負(fù)責(zé)精評(píng)校準(zhǔn)A/B測(cè)試負(fù)責(zé)上線前后真實(shí)環(huán)境驗(yàn)證指標(biāo)統(tǒng)一進(jìn)一個(gè)儀表盤任何人打開只看一張圖就知道這個(gè)版本能不能發(fā)。下面把這套體系拆開講。2. 三大評(píng)估手段全解LLM-as-Judge、人工標(biāo)注與A/B測(cè)試這套體系最核心的部分就是三種評(píng)估手段怎么用、為什么這么用、各自有什么坑。先分別講清楚再講怎么組合。2.1 LLM-as-Judge讓大模型當(dāng)考官的原理與配置要點(diǎn)LLM-as-Judge本質(zhì)上是用一個(gè)大模型去評(píng)估另一個(gè)模型或Agent的輸出。核心假設(shè)是足夠強(qiáng)的通用大模型具備較好的語(yǔ)言理解、推理和事實(shí)判斷能力能模擬人類評(píng)估者給候選輸出打分或做偏好選擇。它的最大價(jià)值是速度和成本。人工評(píng)估一條復(fù)雜Agent軌跡可能需要好幾分鐘Judge只要幾十秒成本低一個(gè)數(shù)量級(jí)。所以在需要跑大量樣本做回歸測(cè)試時(shí)Judge幾乎是唯一可行的自動(dòng)化方案。但Judge不是開箱即用配置上有幾個(gè)關(guān)鍵點(diǎn)第一評(píng)分卡要具體。不要寫“請(qǐng)?jiān)u估回答質(zhì)量”要給出可判定的維度。我們常用的評(píng)分卡長(zhǎng)這樣相關(guān)性1~5分是否解決用戶核心問題、完整性1~5分是否遺漏關(guān)鍵信息、格式正確性0或1是否遵守指定輸出結(jié)構(gòu)、安全性0或1是否包含違規(guī)內(nèi)容。每個(gè)維度還要加一句“什么情況給幾分”的說明否則Judge就是靠感覺打分。第二選擇打分模式。如果是要評(píng)估一個(gè)Agent的絕對(duì)質(zhì)量用pointwise模式讓Judge按評(píng)分卡給單條輸出逐項(xiàng)打分如果是要比較兩個(gè)Agent版本誰(shuí)更好用pairwise模式讓Judge看兩條輸出后選擇“A更好、B更好、平局”。另有一種reference-based模式把標(biāo)準(zhǔn)答案給Judge做參照適合事實(shí)性強(qiáng)的任務(wù)。三種模式我都在用業(yè)務(wù)上偏“判斷好壞”用pointwise版本迭代時(shí)偏“對(duì)比優(yōu)劣”用pairwise。第三控制Judge自身的偏差。Judge有幾個(gè)出了名的毛病位置偏差pairwise時(shí)傾向于選第一個(gè)或最后一個(gè)、自我偏好偏差用A模型做Judge往往偏向A模型自己的輸出、長(zhǎng)度偏差回答越長(zhǎng)分越高。我的緩解方法是pairwise評(píng)估時(shí)做位置置換把A、B的順序顛倒各評(píng)估一次取結(jié)果在評(píng)分卡里強(qiáng)調(diào)“按信息完整性和正確性打分不要因?yàn)榛卮痖L(zhǎng)就加分”對(duì)分歧樣本抽樣到人工復(fù)核。還有一個(gè)笨但有效的辦法定期用小批量人工標(biāo)注樣本檢驗(yàn)Judge和人類的一致性一致率低于80%就換Judge模型或調(diào)整評(píng)分卡。第四Judge結(jié)果的結(jié)構(gòu)化。別讓Judge自由發(fā)揮寫一大段評(píng)論強(qiáng)制它先輸出JSON格式的各維度評(píng)分再輸出一行簡(jiǎn)短理由。這樣下游可以直接解析入庫(kù)。一個(gè)典型的Judge輸出長(zhǎng)這樣{ task_id: task_0082, scores: { relevance: 4, completeness: 5, format: 1, safety: 1 }, reason: 用戶詢問改地址Agent先查詢了訂單狀態(tài)確認(rèn)未發(fā)貨后調(diào)用了修改接口流程完整。 }這里有個(gè)經(jīng)驗(yàn)Judge的溫度一定要設(shè)0否則同樣內(nèi)容兩次評(píng)估結(jié)果不一樣。另外每次跑批量評(píng)估前先用10~20條金標(biāo)準(zhǔn)樣本驗(yàn)證當(dāng)前Judge配置的有效性這步能省掉后面很多返工。2.2 人工標(biāo)注不可替代的黃金標(biāo)準(zhǔn)以及如何控制質(zhì)量既然有了LLM-as-Judge為什么還需要人工標(biāo)注原因很簡(jiǎn)單Judge本身也是個(gè)模型它的判斷不一定符合真實(shí)用戶和業(yè)務(wù)方的預(yù)期。人工標(biāo)注是假設(shè)的“黃金標(biāo)準(zhǔn)”用途不是跑量而是校準(zhǔn)和驗(yàn)證。但人工標(biāo)注最大的麻煩是質(zhì)量波動(dòng)。同一個(gè)Agent輸出讓兩個(gè)人標(biāo)注結(jié)果可能完全相反。這不是人不行而是標(biāo)準(zhǔn)沒定死。我把人工標(biāo)注流程固化成了這么幾步第一步寫標(biāo)注手冊(cè)。手冊(cè)里必須包含任務(wù)背景說明、每類指標(biāo)的詳細(xì)定義、至少5個(gè)“不同分?jǐn)?shù)段”的標(biāo)注示例、常見邊界案例的處理方式。手冊(cè)要發(fā)到標(biāo)注群里一起評(píng)審不能一個(gè)人拍腦袋寫完就發(fā)。第二步雙人盲標(biāo)加仲裁。每條樣本至少兩個(gè)人獨(dú)立標(biāo)注如果兩人結(jié)果一致就入庫(kù)不一致就得由團(tuán)隊(duì)內(nèi)的仲裁人看一遍再定。仲裁的比例一般控制在10%~20%之間如果超過20%不是仲裁人累死而是標(biāo)注手冊(cè)有問題得回爐重做。第三步計(jì)算一致性。一般用Cohen‘s Kappa系數(shù)來量化兩個(gè)標(biāo)注人之間的一致性。公式不復(fù)雜[ \kappa \frac{P_o - P_e}{1 - P_e} ]P_o是實(shí)際一致率P_e是隨機(jī)情況下期望一致率。Kappa值在0.8以上說明標(biāo)注一致性很好0.6~0.8算可以接受低于0.6就需要重新培訓(xùn)或修訂手冊(cè)。我經(jīng)?？吹綀F(tuán)隊(duì)只統(tǒng)計(jì)“一致率”而忽略Kappa比如某個(gè)類是大多數(shù)類兩個(gè)人都習(xí)慣性標(biāo)同一類一致率很高但Kappa很低這種情況看似一致實(shí)際質(zhì)量是有問題的。第四步在標(biāo)注批次里埋“金標(biāo)準(zhǔn)題”。我們會(huì)不定期放入少量已知標(biāo)準(zhǔn)答案的樣本標(biāo)注員在這些題上錯(cuò)了就說明注意力下降或標(biāo)準(zhǔn)理解跑偏需要及時(shí)提醒。樣本怎么選也是個(gè)學(xué)問。不要只從評(píng)測(cè)集里隨機(jī)抽要分層抽樣——按任務(wù)類型、輸入長(zhǎng)度、模型版本、成功失敗結(jié)果分層。否則人工標(biāo)注驗(yàn)證出來的結(jié)論可能只對(duì)某一類樣本有效。2.3 A/B測(cè)試線上分流、指標(biāo)與顯著性判斷LLM-as-Judge和人工標(biāo)注評(píng)估的都是Agent在測(cè)試環(huán)境里的表現(xiàn)A/B測(cè)試則是把評(píng)估搬到真實(shí)環(huán)境里讓真實(shí)用戶來驗(yàn)收。A/B測(cè)試不是所有場(chǎng)景都能做至少要有線上分流能力和相對(duì)充足的流量。但一旦能做它提供了最硬核的證據(jù)新版本到底有沒有給業(yè)務(wù)帶來實(shí)際提升。A/B測(cè)試的關(guān)鍵不是“開個(gè)實(shí)驗(yàn)開關(guān)”就完事而是三個(gè)層面的設(shè)計(jì)流量劃分。Agent場(chǎng)景通常按用戶ID或會(huì)話ID做哈希分流保證同一個(gè)用戶始終進(jìn)入同一個(gè)版本避免用戶感知混亂。不要用隨機(jī)數(shù)做分流因?yàn)橐淮螘?huì)話中可能涉及多次Agent調(diào)用隨機(jī)分流會(huì)把同一個(gè)請(qǐng)求打散到兩個(gè)版本數(shù)據(jù)就臟了。指標(biāo)設(shè)計(jì)。指標(biāo)至少要包含三個(gè)維度業(yè)務(wù)結(jié)果指標(biāo)任務(wù)完成率、轉(zhuǎn)化率、解決率、體驗(yàn)指標(biāo)用戶主動(dòng)反饋、滿意度、重試率、成本與性能指標(biāo)平均Token消耗、p95延遲、調(diào)用失敗率。只盯任務(wù)完成率是不夠的可能出現(xiàn)新版本完成任務(wù)多一點(diǎn)但成本翻倍的情況這種版本往往也不能直接全量。顯著性判斷。樣本量不夠就跑不出顯著性這是最常見的坑。我習(xí)慣在實(shí)驗(yàn)前先做事前樣本量估算用歷史數(shù)據(jù)的方差和期望提升幅度來反推需要多少樣本。實(shí)驗(yàn)結(jié)束后不僅要看p值還要看置信區(qū)間和效應(yīng)量。p值顯著但效應(yīng)量只有0.1%業(yè)務(wù)上也未必值得上線。A/B測(cè)試還有幾個(gè)特別容易翻車的細(xì)節(jié)新奇效應(yīng)新版本剛上線用戶可能因?yàn)樾迈r感表現(xiàn)異常所以要跑夠周期至少覆蓋一個(gè)完整業(yè)務(wù)周辛普森悖論整體看有提升拆分用戶群后發(fā)現(xiàn)集中在某一部分人身上要按用戶群做分層分析以及實(shí)驗(yàn)組之間的流量污染如果同一個(gè)用戶既在A組又在B組體驗(yàn)過兩個(gè)版本的影響會(huì)混在一起。2.4 三種手段怎么配合研發(fā)、發(fā)版、上線三段式三種評(píng)估手段不是三選一而是流水線分工。我們團(tuán)隊(duì)現(xiàn)在的節(jié)奏是研發(fā)階段跑量用LLM-as-Judge。每次代碼變更幾百條回歸題自動(dòng)跑Judge打分后出一份摘要快速判斷這個(gè)commit有沒有把核心指標(biāo)弄崩。免費(fèi)、快速、覆蓋廣是這一階段的主要訴求。發(fā)版前做人工精評(píng)。Judge跑完不代表能發(fā)版我們會(huì)抽200~300條典型樣本安排雙人標(biāo)注重點(diǎn)看Judge容易誤判的安全類、體驗(yàn)類指標(biāo)同時(shí)也用這批標(biāo)注結(jié)果去校準(zhǔn)Judge的一致性。上線階段做A/B測(cè)試。只有精評(píng)過關(guān)的版本才具備A/B資格。線上實(shí)驗(yàn)跑1~2周看真實(shí)業(yè)務(wù)指標(biāo)的變化。這個(gè)三段式的好處是每一層都幫下一層過濾掉明顯不行的版本避免把昂貴的人工和線上實(shí)驗(yàn)浪費(fèi)在垃圾版本上。3. 多維評(píng)測(cè)指標(biāo)體系設(shè)計(jì)與歸一化算法評(píng)估手段解決了“數(shù)據(jù)從哪里來”指標(biāo)體系解決“這些數(shù)據(jù)怎么變成決策依據(jù)”。這套指標(biāo)我已經(jīng)反復(fù)打磨過下面直接給框架。3.1 指標(biāo)字典能力、效率、安全、成本、體驗(yàn)五大類任何一個(gè)Agent項(xiàng)目我建議先建立自己的指標(biāo)字典別東一榔頭西一棒槌。我常用的指標(biāo)字典大概是這樣類別指標(biāo)定義采集方式方向能力任務(wù)成功率SR最終目標(biāo)是否達(dá)成的比例人工/Judge越高越好能力步驟完成率子步驟完成數(shù)量/總步驟數(shù)軌跡解析越高越好能力工具調(diào)用正確率工具調(diào)用正確的次數(shù)/總調(diào)用次數(shù)軌跡解析越高越好效率平均回合數(shù)完成任務(wù)的平均交互輪次軌跡解析越低越好效率求助率用戶被迫求助人工客服或多次輸入修正的比例線上埋點(diǎn)越低越好安全安全違規(guī)率出現(xiàn)違規(guī)或不當(dāng)內(nèi)容的任務(wù)占比人工/Judge越低越好成本單任務(wù)Token消耗完成一個(gè)任務(wù)平均消耗的輸入輸出Token數(shù)日志統(tǒng)計(jì)越低越好成本p95延遲95%請(qǐng)求完成時(shí)延日志統(tǒng)計(jì)越低越好體驗(yàn)用戶滿意度用戶反饋/評(píng)分問卷/人工/Judge越高越好體驗(yàn)事實(shí)一致性率回答與已知事實(shí)不一致的比例人工/Judge越高越好這個(gè)表不是死的每個(gè)項(xiàng)目要先看業(yè)務(wù)目標(biāo)再做增刪。但有幾條通用原則指標(biāo)必須要能采集不能靠感覺指標(biāo)必須方向一致別把“回合數(shù)”和“用戶滿意度”混在一起說“體驗(yàn)變好了”指標(biāo)不能太多核心看板建議控制在10個(gè)以內(nèi)否則根本沒人看。3.2 指標(biāo)歸一化與綜合評(píng)分不同指標(biāo)單位不同沒法直接相加必須先歸一化。最常用的是線性歸一化設(shè)定一個(gè)“及格線”和“滿分線”把原始值映射到0~100。比如任務(wù)成功率0%是0分100%是100分。成本類指標(biāo)反過來平均Token消耗1000以下是100分5000以上是0分中間線性插值。這里的上下限要根據(jù)業(yè)務(wù)實(shí)際情況來定不能閉眼拍。歸一化之后還要加權(quán)重。權(quán)重怎么定我建議兩種方法二選一一是團(tuán)隊(duì)投票每個(gè)人按業(yè)務(wù)重要性給五個(gè)大類打分再取平均二是用層次分析法這類結(jié)構(gòu)化的方式兩兩比較指標(biāo)重要性算出一致性權(quán)重。權(quán)重的核心要求是“可解釋”上線評(píng)審被問“為什么綜合分是82”你得能一步步解釋清楚。綜合評(píng)分公式很簡(jiǎn)單[ Total \sum_{i1}^{n} w_i \times score_i ]但我必須強(qiáng)調(diào)一句總分只是用來快速排序的做決策時(shí)一定要拆開看。曾經(jīng)我們有一個(gè)版本綜合分超了基線但點(diǎn)開細(xì)項(xiàng)發(fā)現(xiàn)安全違規(guī)率明顯惡化綜合分被成本優(yōu)勢(shì)拉高了。這種情況如果只看總分遲早出事。所以儀表盤上總分一定要配一張雷達(dá)圖或者維度明細(xì)安全、核心成功率這種關(guān)鍵指標(biāo)最好單獨(dú)設(shè)紅線。3.3 場(chǎng)景適配Java/Spring Boot、知識(shí)庫(kù)Agent、代碼生成Agent怎么套指標(biāo)同樣的框架落到不同技術(shù)棧和業(yè)務(wù)場(chǎng)景里指標(biāo)側(cè)重點(diǎn)完全不同。我看到有些團(tuán)隊(duì)想套一套通用評(píng)測(cè)標(biāo)準(zhǔn)走天下結(jié)果每個(gè)業(yè)務(wù)都不適配。舉三個(gè)典型場(chǎng)景第一個(gè)是Java/Spring Boot這類后端服務(wù)化的Agent客戶端。這類Agent通常要跟業(yè)務(wù)系統(tǒng)深度集成核心訴求是穩(wěn)定性和接口正確性。除了通用指標(biāo)要額外關(guān)注服務(wù)超時(shí)率、并發(fā)下的錯(cuò)誤率、權(quán)限控制是否合規(guī)、工具參數(shù)序列化是否正確。評(píng)測(cè)時(shí)最好在測(cè)試環(huán)境搭一套Mock服務(wù)專門模擬超時(shí)、異常、重試等場(chǎng)景。第二個(gè)是Obsidian AI Agent知識(shí)庫(kù)場(chǎng)景。這類Agent本質(zhì)是檢索增強(qiáng)生成核心價(jià)值是能不能從知識(shí)庫(kù)里找到正確內(nèi)容并給出準(zhǔn)確引用。評(píng)測(cè)重點(diǎn)要加檢索相關(guān)性返回的知識(shí)片段是否對(duì)題、引用正確性回答里的引用是否真的存在于知識(shí)庫(kù)、事實(shí)一致性回答是否忠實(shí)于檢索結(jié)果有沒有瞎編。這些指標(biāo)靠精確匹配測(cè)不了Judge加上人工抽檢是主要手段。第三個(gè)是Verilog代碼生成Agent。這類代碼生成Agent更硬核因?yàn)榇a能不能跑這件事是客觀的。我們?cè)u(píng)測(cè)時(shí)會(huì)直接接一套工具鏈Agent生成代碼后自動(dòng)做語(yǔ)法編譯、功能仿真最終以編譯通過率和仿真通過率為核心指標(biāo)。這類場(chǎng)景里Judge的作用反而弱化因?yàn)樽钣姓f服力的裁判是編譯器。這也是我想說的指標(biāo)設(shè)計(jì)要跟著場(chǎng)景走別把Judge當(dāng)萬(wàn)能藥。4. 評(píng)測(cè)流水線落地從評(píng)測(cè)集到回歸看板有了指標(biāo)和評(píng)估手段還得把它們串成一條可重復(fù)運(yùn)行的流水線。否則每次評(píng)測(cè)都是手工活換個(gè)版本重新跑一遍效率極低還容易漏。4.1 評(píng)測(cè)集建設(shè)數(shù)量、來源與防污染評(píng)測(cè)集是一切評(píng)估的基石。沒有好的評(píng)測(cè)集再花哨的評(píng)估手段也是白搭。評(píng)測(cè)集的來源我建議三個(gè)渠道結(jié)合第一真實(shí)業(yè)務(wù)日志脫敏。這是最寶貴的來源去線上把真實(shí)用戶的問題收集起來去掉隱私信息做成輸入樣本。第二公開基準(zhǔn)集比如各種開源的Agent benchmark可以作為參考但要注意跟業(yè)務(wù)差異。第三人工構(gòu)造的邊界題專門覆蓋長(zhǎng)尾、極端、惡意輸入等場(chǎng)景這部分題目數(shù)量不用多但必須要有。數(shù)量上我們的經(jīng)驗(yàn)是回歸評(píng)測(cè)集至少要有幾百條級(jí)別。Agent的評(píng)估方差大題目太少一個(gè)隨機(jī)波動(dòng)就淹沒真實(shí)變化。但也不是越多越好因?yàn)槊吭黾右粭l題跑一輪和人工抽檢的成本都在漲。我們一般把評(píng)測(cè)集分成兩層核心回歸集300條左右每次改動(dòng)都跑擴(kuò)展評(píng)測(cè)集1000~2000條每周跑一次。評(píng)測(cè)集防污染是現(xiàn)代AI評(píng)測(cè)里必須考慮的問題。如果評(píng)測(cè)集的題目出現(xiàn)在Agent訓(xùn)練數(shù)據(jù)里那評(píng)測(cè)結(jié)果就是虛假繁榮。我的做法是核心評(píng)測(cè)集不公開專人管理定期換一批題使用私有化評(píng)測(cè)題庫(kù)避免直接從公開數(shù)據(jù)集整包拿過來用上線新題時(shí)做相似度去重防止跟已有訓(xùn)練語(yǔ)料高度重合的題混入。4.2 執(zhí)行流程與工程化Runner、Mock與多次運(yùn)行一次完整的評(píng)測(cè)執(zhí)行本質(zhì)上是把“數(shù)據(jù)集Agent配置外部服務(wù)MockerJudge”都編排起來跑一遍。我的建議是把它做成一個(gè)Runner腳本允許參數(shù)化傳入模型版本、Prompt模板、工具配置和評(píng)測(cè)集ID。執(zhí)行流程大概是加載評(píng)測(cè)集遍歷任務(wù)對(duì)每個(gè)任務(wù)初始化Agent環(huán)境包括Mock外部服務(wù)的響應(yīng)運(yùn)行Agent記錄完整軌跡推理過程、工具調(diào)用、中間回復(fù)、最終回復(fù)超時(shí)和異常要單獨(dú)標(biāo)識(shí)而不是直接判失敗否則會(huì)把超時(shí)誤當(dāng)成能力差將軌跡和結(jié)果交給Judge打分匯總所有分?jǐn)?shù)寫入結(jié)果數(shù)據(jù)庫(kù)生成評(píng)測(cè)報(bào)告。這里有兩個(gè)容易被忽略的細(xì)節(jié)分別說一下。第一個(gè)是外部服務(wù)的Mock。Agent大量依賴工具調(diào)用如果直接連真實(shí)測(cè)試環(huán)境會(huì)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)、數(shù)據(jù)不一致、接口限流等噪聲干擾評(píng)估結(jié)果。我們要求所有工具調(diào)用都要能被Mock掉Mock的響應(yīng)要穩(wěn)定且可以版本化管理。A/B測(cè)試可以上真實(shí)環(huán)境但離線評(píng)測(cè)必須保持環(huán)境純凈。第二個(gè)是多次運(yùn)行取分布。Agent具備隨機(jī)性即使溫度設(shè)0也不能保證完全確定工具返回內(nèi)容、上下文方差都可能導(dǎo)致結(jié)果漂移。所以關(guān)鍵實(shí)驗(yàn)我建議同樣的任務(wù)至少跑3次記錄成功次數(shù)的分布而不是單次結(jié)果。比如某任務(wù)跑了3次成功2次成功率記為0.67這比單次0或1有意義得多。代價(jià)是評(píng)測(cè)耗時(shí)增加但換來的是對(duì)穩(wěn)定性的理解值得。4.3 回歸看板與發(fā)布門禁讓評(píng)測(cè)真正影響決策評(píng)測(cè)體系如果只是每周出一份報(bào)告價(jià)值就少了一半。真正要讓評(píng)測(cè)影響決策必須做成“門禁”和“看板”看板要常駐。我們有一個(gè)內(nèi)部頁(yè)面展示主干版本的每個(gè)指標(biāo)折線圖。橫軸是版本號(hào)縱軸是歸一化分?jǐn)?shù)或原始指標(biāo)。任何人一打開就能看到上一版到這一版哪個(gè)指標(biāo)漲了、哪個(gè)跌了。這比評(píng)審會(huì)上翻PPT高效太多。門禁要硬。在CI/CD流水線里加上評(píng)測(cè)步驟核心回歸集不過不允許merge到主干A/B測(cè)試沒完成不允許全量發(fā)布。具體門檻可以這樣設(shè)置任務(wù)成功率不低于前一個(gè)版本安全違規(guī)率為0p95延遲增加不超過5%單任務(wù)成本增幅不超過10%。這里的安全違規(guī)率我建議設(shè)置成硬性0容忍其他指標(biāo)可以允許小幅波動(dòng)但要解釋原因?；貧w看板還有個(gè)作用逼著團(tuán)隊(duì)面對(duì)穩(wěn)定性的問題。如果某個(gè)版本成功率抖動(dòng)很大看板上會(huì)顯示方差變寬這時(shí)候不管是模型還是評(píng)測(cè)集的問題都得停下來查清楚而不是看均值“好像還行”就放過去。5. 常見問題與排查技巧實(shí)錄前面講的都是理想框架實(shí)操中幾乎每一步都會(huì)出幺蛾子。這一節(jié)專門記錄我遇到過的高頻問題每個(gè)都踩過坑希望能幫你少走彎路。5.1 LLM-as-Judge不聽話評(píng)分飄忽、與人類不一致現(xiàn)象一同樣是“很好”的答案換了個(gè)Judge模型就變成低分。排查方案是先看評(píng)分卡是不是足夠客觀。如果評(píng)分卡還在用“請(qǐng)?jiān)u估回答質(zhì)量”那是評(píng)分卡的問題不是Judge的問題。改成帶維度粒度和示例的評(píng)分卡一致性會(huì)明顯提升?，F(xiàn)象二Judge和人工標(biāo)注的一致性只有60%。這種時(shí)候不要硬上Judge先找到分歧集中在哪類樣本。我遇到過Judge對(duì)“間接回答了問題但沒直接給答案”的情況格外嚴(yán)厲而人類覺得這種回答可以接受雙方打分手腕不一樣。解決方案是給Judge加一條“允許Agent追問澄清”的規(guī)則并在標(biāo)注手冊(cè)里同步說明讓人類和Judge對(duì)齊?，F(xiàn)象三Judge自己出現(xiàn)幻覺在理由里寫了一些回答里根本沒有的內(nèi)容。這種情況只能靠更換更強(qiáng)的Judge模型以及增加“回答中是否包含xxx”這種可驗(yàn)證性的評(píng)分維度來緩解。記住Judge也是有幻覺風(fēng)險(xiǎn)的模型不能全盤信任。5.2 人工標(biāo)注質(zhì)量和一致性差最典型的場(chǎng)景是雙人標(biāo)注一致率不到70%Kappa低于0.5。一開始我們以為是標(biāo)注員不認(rèn)真后來復(fù)盤發(fā)現(xiàn)是標(biāo)注手冊(cè)里“邊界案例”太多比如“用戶要求Agent幫忙改寫郵件但保留語(yǔ)氣不變”什么樣算語(yǔ)氣不變不同人理解完全不同。解法分三步第一步把分歧最大的樣本收集起來逐條討論把新確認(rèn)的規(guī)則補(bǔ)進(jìn)標(biāo)注手冊(cè)。第二步對(duì)標(biāo)注員做一次集中培訓(xùn)重點(diǎn)講新增的邊界案例。第三步重新抽一批獨(dú)立樣本測(cè)Kappa。通常這一輪下來一致性會(huì)從0.5拉到0.7以上。如果還不行就得考慮是不是指標(biāo)本身定義太模糊需要換一個(gè)更容易判定的指標(biāo)。5.3 A/B測(cè)試跑不出顯著差異這是最讓人崩潰的場(chǎng)景之一明明離線評(píng)測(cè)有明顯優(yōu)勢(shì)線上A/B就是沒有顯著結(jié)果。我遇到過的原因有三種第一種樣本量確實(shí)不夠。跑了一周就著急看數(shù)據(jù)置信區(qū)間寬得能裝下整個(gè)宇宙。解法是事先算好樣本量耐住性子跑夠時(shí)間。第二種指標(biāo)選錯(cuò)了。離線評(píng)測(cè)用的是任務(wù)成功率線上實(shí)際統(tǒng)計(jì)的是“用戶發(fā)起會(huì)話后有沒有點(diǎn)‘已解決’”這兩者口徑差異很大。我在早期犯過這個(gè)錯(cuò)離線成功率提升10%線上“已解決率”紋絲不動(dòng)最后發(fā)現(xiàn)線上用戶根本不會(huì)主動(dòng)點(diǎn)“已解決”。解法是要用跟業(yè)務(wù)結(jié)果強(qiáng)相關(guān)的指標(biāo)來做A/B而不是直接搬離線指標(biāo)。第三種版本差異被噪聲淹沒。線上流量本身波動(dòng)很大節(jié)假日、活動(dòng)、渠道投放都會(huì)帶來噪聲。建議A/B期間同時(shí)監(jiān)控自然波動(dòng)數(shù)據(jù)或者用分位數(shù)、更長(zhǎng)時(shí)間的窗口來觀察而不是只看每天的均值。5.4 評(píng)測(cè)集污染與線上失真評(píng)測(cè)集被污染的表現(xiàn)是離線分越跑越高線上業(yè)務(wù)指標(biāo)毫無變化甚至下滑。除了訓(xùn)練數(shù)據(jù)可能包含評(píng)測(cè)題之外還有一種常見情況是評(píng)測(cè)集本身構(gòu)建時(shí)帶偏見——偏向某一種回答風(fēng)格或問法導(dǎo)致Agent在評(píng)測(cè)集上練得“過擬合”。防止線上失真的核心是兩條一是評(píng)測(cè)集持續(xù)更新不能一年到頭就那幾百道題二是定期做“盲測(cè)回流”——從線上隨機(jī)抽出真實(shí)用戶請(qǐng)求作為臨時(shí)評(píng)測(cè)樣本跑一輪離線評(píng)估看離線分?jǐn)?shù)和線上真實(shí)表現(xiàn)是否一致。一旦發(fā)現(xiàn)兩者越來越脫節(jié)就要馬上重寫評(píng)測(cè)集或調(diào)整評(píng)測(cè)邏輯。模型在進(jìn)化用戶問題也在進(jìn)化評(píng)測(cè)集不是一次性資產(chǎn)這點(diǎn)一定要有意識(shí)。我個(gè)人在實(shí)際操作中的一個(gè)體會(huì)是評(píng)測(cè)體系做得越久越要警惕“為了好看而評(píng)測(cè)”。指標(biāo)不是越多越好手段也不是越高級(jí)越好關(guān)鍵是能不能幫你在正確的時(shí)間攔住錯(cuò)誤的版本。這些方法組合在一起就是我和團(tuán)隊(duì)目前跑得很順的v21.0方案。它不一定適合所有團(tuán)隊(duì)但至少提供了一條從“憑感覺”走向“用數(shù)據(jù)說話”的可行路徑。 AI Agent多維評(píng)測(cè)體系：LLM-as-Judge、人工標(biāo)注與A/B測(cè)試實(shí)戰(zhàn)
工作里只要沾過AI Agent開發(fā)十有八九會(huì)碰上一個(gè)靈魂拷問這Agent到底行不行我自己的評(píng)測(cè)框架從v1.0一路迭代到現(xiàn)在的21.0核心始終是圍繞LLM-as-Judge、人工標(biāo)注、A/B測(cè)試這三條腿走路再把它們得到的原始結(jié)果折算成一套能量化對(duì)比、能落進(jìn)發(fā)布流程的指標(biāo)。這篇內(nèi)容就是把我這些年踩過的坑和最終沉淀下來的多維評(píng)測(cè)實(shí)踐完整拆開講一遍。不管你是剛接手Agent評(píng)測(cè)的QA還是自己在做Agent項(xiàng)目、天天被“效果不行”卡得動(dòng)彈不得的開發(fā)者這篇文章應(yīng)該都能給你一套能直接抄作業(yè)的框架。1. 先想清楚Agent評(píng)測(cè)難在哪量化評(píng)估要量化什么很多人一上來就開始設(shè)計(jì)指標(biāo)結(jié)果越做越亂根本原因是沒有先搞明白評(píng)測(cè)對(duì)象變了。Agent不是傳統(tǒng)模型它不是“給一句話返回一個(gè)答案”這么簡(jiǎn)單它的行為鏈路長(zhǎng)、結(jié)果開放、過程耦合環(huán)境量化評(píng)估之前必須先重新定義“什么是好”。1.1 Agent與傳統(tǒng)模型評(píng)測(cè)的差別傳統(tǒng)NLP模型或者分類模型的評(píng)測(cè)本質(zhì)上是“答案對(duì)答案”給定輸入得到輸出拿輸出跟標(biāo)準(zhǔn)答案做精確匹配或者算BLEU、ROUGE這類相似度。這個(gè)過程目標(biāo)單一、環(huán)境可控、結(jié)果確定性高。到了Agent這里情況完全變了。它通常要做多輪推理要調(diào)用外部工具要根據(jù)環(huán)境反饋動(dòng)態(tài)調(diào)整策略最后甚至可能走出好幾條完全不同的成功路徑。舉個(gè)實(shí)際例子一個(gè)客服Agent處理“用戶想改收貨地址”這個(gè)任務(wù)。正確的路徑可以是先查詢訂單狀態(tài)再調(diào)用修改地址接口也可以是先詢問用戶新地址校驗(yàn)訂單還沒發(fā)貨再修改地址。兩條路結(jié)果一樣但中間過程差別很大。如果你還是只比對(duì)最終輸出文本那幾乎沒法做自動(dòng)化評(píng)估。Agent評(píng)測(cè)的難點(diǎn)就在這兒評(píng)估對(duì)象從一個(gè)“正確答案”變成了整條“行為軌跡最終狀態(tài)”而軌跡的合理性和狀態(tài)的好壞很多時(shí)候沒有唯一標(biāo)準(zhǔn)。這也是為什么量化評(píng)估不能只盯著“能不能完成任務(wù)”這一個(gè)點(diǎn)。你需要同時(shí)回答幾個(gè)問題任務(wù)完成得對(duì)不對(duì)完成得順不順過程中有沒有亂來代價(jià)高不高。這幾個(gè)問題對(duì)應(yīng)著完全不同的評(píng)估手段和指標(biāo)得拆開來看。1.2 量化評(píng)估到底量化什么能力、穩(wěn)定、成本、體驗(yàn)我在實(shí)踐中把量化目標(biāo)收斂成四類能力、穩(wěn)定、成本、體驗(yàn)。能力是最基礎(chǔ)的一層回答“這個(gè)Agent能不能完成它該做的事”。落地到指標(biāo)上就是任務(wù)成功率、子步驟完成率、工具調(diào)用正確率等。穩(wěn)定是很多團(tuán)隊(duì)容易忽略的一層。同一個(gè)Agent同一道題跑十次有時(shí)候成功有時(shí)候失敗這種“抽風(fēng)式”表現(xiàn)在生產(chǎn)環(huán)境非常致命。所以評(píng)測(cè)必須有重復(fù)運(yùn)行的概念至少要反映方差而不是只看均值。成本層必須考慮因?yàn)锳gent的消耗往往比傳統(tǒng)模型高一個(gè)量級(jí)。一次任務(wù)可能要多次調(diào)用大模型加上工具調(diào)用的附加費(fèi)用單task成本很容易就上去了。如果能力合格但成本高到?jīng)]法規(guī)?；沁@個(gè)Agent照樣上不了線。體驗(yàn)層則更主觀包括用戶覺得順不順、回答是否友好、有沒有不安全的表述。體驗(yàn)類指標(biāo)很難用精確匹配來度量這正是LLM-as-Judge和人工標(biāo)注的用武之地。1.3 從v1.0到v21.0我踩過的三個(gè)大坑早期我的評(píng)測(cè)體系就是v1.0只有“準(zhǔn)確率”一個(gè)指標(biāo)拿一批固定問題測(cè)一遍算個(gè)百分比就完事。結(jié)果上線第一周就被打臉業(yè)務(wù)方反饋一堆問題成功率看著90%實(shí)際問題基本辦不成。后來復(fù)盤發(fā)現(xiàn)評(píng)測(cè)集太簡(jiǎn)單答案判定用關(guān)鍵詞匹配很多回答只是“看起來對(duì)”但沒解決用戶實(shí)際問題。v5.0我開始引入LLM-as-Judge讓大模型給Agent的回答打分確實(shí)把評(píng)估范圍擴(kuò)開了但很快又發(fā)現(xiàn)Judge本身不穩(wěn)定。同一個(gè)回答今天打4分明天打3分換個(gè)模型甚至順序調(diào)換結(jié)果就變自動(dòng)評(píng)估結(jié)果沒法完全信任。v12.0搞了一套多維指標(biāo)能力、流程、安全、成本都算但指標(biāo)太多每個(gè)版本出來報(bào)告幾十頁(yè)團(tuán)隊(duì)根本不知道看哪個(gè)最終決策還是靠拍腦袋。直到v21.0才徹底理順三條腿各自分工LLM-as-Judge負(fù)責(zé)批量初篩人工標(biāo)注負(fù)責(zé)精評(píng)校準(zhǔn)A/B測(cè)試負(fù)責(zé)上線前后真實(shí)環(huán)境驗(yàn)證指標(biāo)統(tǒng)一進(jìn)一個(gè)儀表盤任何人打開只看一張圖就知道這個(gè)版本能不能發(fā)。下面把這套體系拆開講。2. 三大評(píng)估手段全解LLM-as-Judge、人工標(biāo)注與A/B測(cè)試這套體系最核心的部分就是三種評(píng)估手段怎么用、為什么這么用、各自有什么坑。先分別講清楚再講怎么組合。2.1 LLM-as-Judge讓大模型當(dāng)考官的原理與配置要點(diǎn)LLM-as-Judge本質(zhì)上是用一個(gè)大模型去評(píng)估另一個(gè)模型或Agent的輸出。核心假設(shè)是足夠強(qiáng)的通用大模型具備較好的語(yǔ)言理解、推理和事實(shí)判斷能力能模擬人類評(píng)估者給候選輸出打分或做偏好選擇。它的最大價(jià)值是速度和成本。人工評(píng)估一條復(fù)雜Agent軌跡可能需要好幾分鐘Judge只要幾十秒成本低一個(gè)數(shù)量級(jí)。所以在需要跑大量樣本做回歸測(cè)試時(shí)Judge幾乎是唯一可行的自動(dòng)化方案。但Judge不是開箱即用配置上有幾個(gè)關(guān)鍵點(diǎn)第一評(píng)分卡要具體。不要寫“請(qǐng)?jiān)u估回答質(zhì)量”要給出可判定的維度。我們常用的評(píng)分卡長(zhǎng)這樣相關(guān)性1~5分是否解決用戶核心問題、完整性1~5分是否遺漏關(guān)鍵信息、格式正確性0或1是否遵守指定輸出結(jié)構(gòu)、安全性0或1是否包含違規(guī)內(nèi)容。每個(gè)維度還要加一句“什么情況給幾分”的說明否則Judge就是靠感覺打分。第二選擇打分模式。如果是要評(píng)估一個(gè)Agent的絕對(duì)質(zhì)量用pointwise模式讓Judge按評(píng)分卡給單條輸出逐項(xiàng)打分如果是要比較兩個(gè)Agent版本誰(shuí)更好用pairwise模式讓Judge看兩條輸出后選擇“A更好、B更好、平局”。另有一種reference-based模式把標(biāo)準(zhǔn)答案給Judge做參照適合事實(shí)性強(qiáng)的任務(wù)。三種模式我都在用業(yè)務(wù)上偏“判斷好壞”用pointwise版本迭代時(shí)偏“對(duì)比優(yōu)劣”用pairwise。第三控制Judge自身的偏差。Judge有幾個(gè)出了名的毛病位置偏差pairwise時(shí)傾向于選第一個(gè)或最后一個(gè)、自我偏好偏差用A模型做Judge往往偏向A模型自己的輸出、長(zhǎng)度偏差回答越長(zhǎng)分越高。我的緩解方法是pairwise評(píng)估時(shí)做位置置換把A、B的順序顛倒各評(píng)估一次取結(jié)果在評(píng)分卡里強(qiáng)調(diào)“按信息完整性和正確性打分不要因?yàn)榛卮痖L(zhǎng)就加分”對(duì)分歧樣本抽樣到人工復(fù)核。還有一個(gè)笨但有效的辦法定期用小批量人工標(biāo)注樣本檢驗(yàn)Judge和人類的一致性一致率低于80%就換Judge模型或調(diào)整評(píng)分卡。第四Judge結(jié)果的結(jié)構(gòu)化。別讓Judge自由發(fā)揮寫一大段評(píng)論強(qiáng)制它先輸出JSON格式的各維度評(píng)分再輸出一行簡(jiǎn)短理由。這樣下游可以直接解析入庫(kù)。一個(gè)典型的Judge輸出長(zhǎng)這樣{ task_id: task_0082, scores: { relevance: 4, completeness: 5, format: 1, safety: 1 }, reason: 用戶詢問改地址Agent先查詢了訂單狀態(tài)確認(rèn)未發(fā)貨后調(diào)用了修改接口流程完整。 }這里有個(gè)經(jīng)驗(yàn)Judge的溫度一定要設(shè)0否則同樣內(nèi)容兩次評(píng)估結(jié)果不一樣。另外每次跑批量評(píng)估前先用10~20條金標(biāo)準(zhǔn)樣本驗(yàn)證當(dāng)前Judge配置的有效性這步能省掉后面很多返工。2.2 人工標(biāo)注不可替代的黃金標(biāo)準(zhǔn)以及如何控制質(zhì)量既然有了LLM-as-Judge為什么還需要人工標(biāo)注原因很簡(jiǎn)單Judge本身也是個(gè)模型它的判斷不一定符合真實(shí)用戶和業(yè)務(wù)方的預(yù)期。人工標(biāo)注是假設(shè)的“黃金標(biāo)準(zhǔn)”用途不是跑量而是校準(zhǔn)和驗(yàn)證。但人工標(biāo)注最大的麻煩是質(zhì)量波動(dòng)。同一個(gè)Agent輸出讓兩個(gè)人標(biāo)注結(jié)果可能完全相反。這不是人不行而是標(biāo)準(zhǔn)沒定死。我把人工標(biāo)注流程固化成了這么幾步第一步寫標(biāo)注手冊(cè)。手冊(cè)里必須包含任務(wù)背景說明、每類指標(biāo)的詳細(xì)定義、至少5個(gè)“不同分?jǐn)?shù)段”的標(biāo)注示例、常見邊界案例的處理方式。手冊(cè)要發(fā)到標(biāo)注群里一起評(píng)審不能一個(gè)人拍腦袋寫完就發(fā)。第二步雙人盲標(biāo)加仲裁。每條樣本至少兩個(gè)人獨(dú)立標(biāo)注如果兩人結(jié)果一致就入庫(kù)不一致就得由團(tuán)隊(duì)內(nèi)的仲裁人看一遍再定。仲裁的比例一般控制在10%~20%之間如果超過20%不是仲裁人累死而是標(biāo)注手冊(cè)有問題得回爐重做。第三步計(jì)算一致性。一般用Cohen‘s Kappa系數(shù)來量化兩個(gè)標(biāo)注人之間的一致性。公式不復(fù)雜[ \kappa \frac{P_o - P_e}{1 - P_e} ]P_o是實(shí)際一致率P_e是隨機(jī)情況下期望一致率。Kappa值在0.8以上說明標(biāo)注一致性很好0.6~0.8算可以接受低于0.6就需要重新培訓(xùn)或修訂手冊(cè)。我經(jīng)?？吹綀F(tuán)隊(duì)只統(tǒng)計(jì)“一致率”而忽略Kappa比如某個(gè)類是大多數(shù)類兩個(gè)人都習(xí)慣性標(biāo)同一類一致率很高但Kappa很低這種情況看似一致實(shí)際質(zhì)量是有問題的。第四步在標(biāo)注批次里埋“金標(biāo)準(zhǔn)題”。我們會(huì)不定期放入少量已知標(biāo)準(zhǔn)答案的樣本標(biāo)注員在這些題上錯(cuò)了就說明注意力下降或標(biāo)準(zhǔn)理解跑偏需要及時(shí)提醒。樣本怎么選也是個(gè)學(xué)問。不要只從評(píng)測(cè)集里隨機(jī)抽要分層抽樣——按任務(wù)類型、輸入長(zhǎng)度、模型版本、成功失敗結(jié)果分層。否則人工標(biāo)注驗(yàn)證出來的結(jié)論可能只對(duì)某一類樣本有效。2.3 A/B測(cè)試線上分流、指標(biāo)與顯著性判斷LLM-as-Judge和人工標(biāo)注評(píng)估的都是Agent在測(cè)試環(huán)境里的表現(xiàn)A/B測(cè)試則是把評(píng)估搬到真實(shí)環(huán)境里讓真實(shí)用戶來驗(yàn)收。A/B測(cè)試不是所有場(chǎng)景都能做至少要有線上分流能力和相對(duì)充足的流量。但一旦能做它提供了最硬核的證據(jù)新版本到底有沒有給業(yè)務(wù)帶來實(shí)際提升。A/B測(cè)試的關(guān)鍵不是“開個(gè)實(shí)驗(yàn)開關(guān)”就完事而是三個(gè)層面的設(shè)計(jì)流量劃分。Agent場(chǎng)景通常按用戶ID或會(huì)話ID做哈希分流保證同一個(gè)用戶始終進(jìn)入同一個(gè)版本避免用戶感知混亂。不要用隨機(jī)數(shù)做分流因?yàn)橐淮螘?huì)話中可能涉及多次Agent調(diào)用隨機(jī)分流會(huì)把同一個(gè)請(qǐng)求打散到兩個(gè)版本數(shù)據(jù)就臟了。指標(biāo)設(shè)計(jì)。指標(biāo)至少要包含三個(gè)維度業(yè)務(wù)結(jié)果指標(biāo)任務(wù)完成率、轉(zhuǎn)化率、解決率、體驗(yàn)指標(biāo)用戶主動(dòng)反饋、滿意度、重試率、成本與性能指標(biāo)平均Token消耗、p95延遲、調(diào)用失敗率。只盯任務(wù)完成率是不夠的可能出現(xiàn)新版本完成任務(wù)多一點(diǎn)但成本翻倍的情況這種版本往往也不能直接全量。顯著性判斷。樣本量不夠就跑不出顯著性這是最常見的坑。我習(xí)慣在實(shí)驗(yàn)前先做事前樣本量估算用歷史數(shù)據(jù)的方差和期望提升幅度來反推需要多少樣本。實(shí)驗(yàn)結(jié)束后不僅要看p值還要看置信區(qū)間和效應(yīng)量。p值顯著但效應(yīng)量只有0.1%業(yè)務(wù)上也未必值得上線。A/B測(cè)試還有幾個(gè)特別容易翻車的細(xì)節(jié)新奇效應(yīng)新版本剛上線用戶可能因?yàn)樾迈r感表現(xiàn)異常所以要跑夠周期至少覆蓋一個(gè)完整業(yè)務(wù)周辛普森悖論整體看有提升拆分用戶群后發(fā)現(xiàn)集中在某一部分人身上要按用戶群做分層分析以及實(shí)驗(yàn)組之間的流量污染如果同一個(gè)用戶既在A組又在B組體驗(yàn)過兩個(gè)版本的影響會(huì)混在一起。2.4 三種手段怎么配合研發(fā)、發(fā)版、上線三段式三種評(píng)估手段不是三選一而是流水線分工。我們團(tuán)隊(duì)現(xiàn)在的節(jié)奏是研發(fā)階段跑量用LLM-as-Judge。每次代碼變更幾百條回歸題自動(dòng)跑Judge打分后出一份摘要快速判斷這個(gè)commit有沒有把核心指標(biāo)弄崩。免費(fèi)、快速、覆蓋廣是這一階段的主要訴求。發(fā)版前做人工精評(píng)。Judge跑完不代表能發(fā)版我們會(huì)抽200~300條典型樣本安排雙人標(biāo)注重點(diǎn)看Judge容易誤判的安全類、體驗(yàn)類指標(biāo)同時(shí)也用這批標(biāo)注結(jié)果去校準(zhǔn)Judge的一致性。上線階段做A/B測(cè)試。只有精評(píng)過關(guān)的版本才具備A/B資格。線上實(shí)驗(yàn)跑1~2周看真實(shí)業(yè)務(wù)指標(biāo)的變化。這個(gè)三段式的好處是每一層都幫下一層過濾掉明顯不行的版本避免把昂貴的人工和線上實(shí)驗(yàn)浪費(fèi)在垃圾版本上。3. 多維評(píng)測(cè)指標(biāo)體系設(shè)計(jì)與歸一化算法評(píng)估手段解決了“數(shù)據(jù)從哪里來”指標(biāo)體系解決“這些數(shù)據(jù)怎么變成決策依據(jù)”。這套指標(biāo)我已經(jīng)反復(fù)打磨過下面直接給框架。3.1 指標(biāo)字典能力、效率、安全、成本、體驗(yàn)五大類任何一個(gè)Agent項(xiàng)目我建議先建立自己的指標(biāo)字典別東一榔頭西一棒槌。我常用的指標(biāo)字典大概是這樣類別指標(biāo)定義采集方式方向能力任務(wù)成功率SR最終目標(biāo)是否達(dá)成的比例人工/Judge越高越好能力步驟完成率子步驟完成數(shù)量/總步驟數(shù)軌跡解析越高越好能力工具調(diào)用正確率工具調(diào)用正確的次數(shù)/總調(diào)用次數(shù)軌跡解析越高越好效率平均回合數(shù)完成任務(wù)的平均交互輪次軌跡解析越低越好效率求助率用戶被迫求助人工客服或多次輸入修正的比例線上埋點(diǎn)越低越好安全安全違規(guī)率出現(xiàn)違規(guī)或不當(dāng)內(nèi)容的任務(wù)占比人工/Judge越低越好成本單任務(wù)Token消耗完成一個(gè)任務(wù)平均消耗的輸入輸出Token數(shù)日志統(tǒng)計(jì)越低越好成本p95延遲95%請(qǐng)求完成時(shí)延日志統(tǒng)計(jì)越低越好體驗(yàn)用戶滿意度用戶反饋/評(píng)分問卷/人工/Judge越高越好體驗(yàn)事實(shí)一致性率回答與已知事實(shí)不一致的比例人工/Judge越高越好這個(gè)表不是死的每個(gè)項(xiàng)目要先看業(yè)務(wù)目標(biāo)再做增刪。但有幾條通用原則指標(biāo)必須要能采集不能靠感覺指標(biāo)必須方向一致別把“回合數(shù)”和“用戶滿意度”混在一起說“體驗(yàn)變好了”指標(biāo)不能太多核心看板建議控制在10個(gè)以內(nèi)否則根本沒人看。3.2 指標(biāo)歸一化與綜合評(píng)分不同指標(biāo)單位不同沒法直接相加必須先歸一化。最常用的是線性歸一化設(shè)定一個(gè)“及格線”和“滿分線”把原始值映射到0~100。比如任務(wù)成功率0%是0分100%是100分。成本類指標(biāo)反過來平均Token消耗1000以下是100分5000以上是0分中間線性插值。這里的上下限要根據(jù)業(yè)務(wù)實(shí)際情況來定不能閉眼拍。歸一化之后還要加權(quán)重。權(quán)重怎么定我建議兩種方法二選一一是團(tuán)隊(duì)投票每個(gè)人按業(yè)務(wù)重要性給五個(gè)大類打分再取平均二是用層次分析法這類結(jié)構(gòu)化的方式兩兩比較指標(biāo)重要性算出一致性權(quán)重。權(quán)重的核心要求是“可解釋”上線評(píng)審被問“為什么綜合分是82”你得能一步步解釋清楚。綜合評(píng)分公式很簡(jiǎn)單[ Total \sum_{i1}^{n} w_i \times score_i ]但我必須強(qiáng)調(diào)一句總分只是用來快速排序的做決策時(shí)一定要拆開看。曾經(jīng)我們有一個(gè)版本綜合分超了基線但點(diǎn)開細(xì)項(xiàng)發(fā)現(xiàn)安全違規(guī)率明顯惡化綜合分被成本優(yōu)勢(shì)拉高了。這種情況如果只看總分遲早出事。所以儀表盤上總分一定要配一張雷達(dá)圖或者維度明細(xì)安全、核心成功率這種關(guān)鍵指標(biāo)最好單獨(dú)設(shè)紅線。3.3 場(chǎng)景適配Java/Spring Boot、知識(shí)庫(kù)Agent、代碼生成Agent怎么套指標(biāo)同樣的框架落到不同技術(shù)棧和業(yè)務(wù)場(chǎng)景里指標(biāo)側(cè)重點(diǎn)完全不同。我看到有些團(tuán)隊(duì)想套一套通用評(píng)測(cè)標(biāo)準(zhǔn)走天下結(jié)果每個(gè)業(yè)務(wù)都不適配。舉三個(gè)典型場(chǎng)景第一個(gè)是Java/Spring Boot這類后端服務(wù)化的Agent客戶端。這類Agent通常要跟業(yè)務(wù)系統(tǒng)深度集成核心訴求是穩(wěn)定性和接口正確性。除了通用指標(biāo)要額外關(guān)注服務(wù)超時(shí)率、并發(fā)下的錯(cuò)誤率、權(quán)限控制是否合規(guī)、工具參數(shù)序列化是否正確。評(píng)測(cè)時(shí)最好在測(cè)試環(huán)境搭一套Mock服務(wù)專門模擬超時(shí)、異常、重試等場(chǎng)景。第二個(gè)是Obsidian AI Agent知識(shí)庫(kù)場(chǎng)景。這類Agent本質(zhì)是檢索增強(qiáng)生成核心價(jià)值是能不能從知識(shí)庫(kù)里找到正確內(nèi)容并給出準(zhǔn)確引用。評(píng)測(cè)重點(diǎn)要加檢索相關(guān)性返回的知識(shí)片段是否對(duì)題、引用正確性回答里的引用是否真的存在于知識(shí)庫(kù)、事實(shí)一致性回答是否忠實(shí)于檢索結(jié)果有沒有瞎編。這些指標(biāo)靠精確匹配測(cè)不了Judge加上人工抽檢是主要手段。第三個(gè)是Verilog代碼生成Agent。這類代碼生成Agent更硬核因?yàn)榇a能不能跑這件事是客觀的。我們?cè)u(píng)測(cè)時(shí)會(huì)直接接一套工具鏈Agent生成代碼后自動(dòng)做語(yǔ)法編譯、功能仿真最終以編譯通過率和仿真通過率為核心指標(biāo)。這類場(chǎng)景里Judge的作用反而弱化因?yàn)樽钣姓f服力的裁判是編譯器。這也是我想說的指標(biāo)設(shè)計(jì)要跟著場(chǎng)景走別把Judge當(dāng)萬(wàn)能藥。4. 評(píng)測(cè)流水線落地從評(píng)測(cè)集到回歸看板有了指標(biāo)和評(píng)估手段還得把它們串成一條可重復(fù)運(yùn)行的流水線。否則每次評(píng)測(cè)都是手工活換個(gè)版本重新跑一遍效率極低還容易漏。4.1 評(píng)測(cè)集建設(shè)數(shù)量、來源與防污染評(píng)測(cè)集是一切評(píng)估的基石。沒有好的評(píng)測(cè)集再花哨的評(píng)估手段也是白搭。評(píng)測(cè)集的來源我建議三個(gè)渠道結(jié)合第一真實(shí)業(yè)務(wù)日志脫敏。這是最寶貴的來源去線上把真實(shí)用戶的問題收集起來去掉隱私信息做成輸入樣本。第二公開基準(zhǔn)集比如各種開源的Agent benchmark可以作為參考但要注意跟業(yè)務(wù)差異。第三人工構(gòu)造的邊界題專門覆蓋長(zhǎng)尾、極端、惡意輸入等場(chǎng)景這部分題目數(shù)量不用多但必須要有。數(shù)量上我們的經(jīng)驗(yàn)是回歸評(píng)測(cè)集至少要有幾百條級(jí)別。Agent的評(píng)估方差大題目太少一個(gè)隨機(jī)波動(dòng)就淹沒真實(shí)變化。但也不是越多越好因?yàn)槊吭黾右粭l題跑一輪和人工抽檢的成本都在漲。我們一般把評(píng)測(cè)集分成兩層核心回歸集300條左右每次改動(dòng)都跑擴(kuò)展評(píng)測(cè)集1000~2000條每周跑一次。評(píng)測(cè)集防污染是現(xiàn)代AI評(píng)測(cè)里必須考慮的問題。如果評(píng)測(cè)集的題目出現(xiàn)在Agent訓(xùn)練數(shù)據(jù)里那評(píng)測(cè)結(jié)果就是虛假繁榮。我的做法是核心評(píng)測(cè)集不公開專人管理定期換一批題使用私有化評(píng)測(cè)題庫(kù)避免直接從公開數(shù)據(jù)集整包拿過來用上線新題時(shí)做相似度去重防止跟已有訓(xùn)練語(yǔ)料高度重合的題混入。4.2 執(zhí)行流程與工程化Runner、Mock與多次運(yùn)行一次完整的評(píng)測(cè)執(zhí)行本質(zhì)上是把“數(shù)據(jù)集Agent配置外部服務(wù)MockerJudge”都編排起來跑一遍。我的建議是把它做成一個(gè)Runner腳本允許參數(shù)化傳入模型版本、Prompt模板、工具配置和評(píng)測(cè)集ID。執(zhí)行流程大概是加載評(píng)測(cè)集遍歷任務(wù)對(duì)每個(gè)任務(wù)初始化Agent環(huán)境包括Mock外部服務(wù)的響應(yīng)運(yùn)行Agent記錄完整軌跡推理過程、工具調(diào)用、中間回復(fù)、最終回復(fù)超時(shí)和異常要單獨(dú)標(biāo)識(shí)而不是直接判失敗否則會(huì)把超時(shí)誤當(dāng)成能力差將軌跡和結(jié)果交給Judge打分匯總所有分?jǐn)?shù)寫入結(jié)果數(shù)據(jù)庫(kù)生成評(píng)測(cè)報(bào)告。這里有兩個(gè)容易被忽略的細(xì)節(jié)分別說一下。第一個(gè)是外部服務(wù)的Mock。Agent大量依賴工具調(diào)用如果直接連真實(shí)測(cè)試環(huán)境會(huì)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)、數(shù)據(jù)不一致、接口限流等噪聲干擾評(píng)估結(jié)果。我們要求所有工具調(diào)用都要能被Mock掉Mock的響應(yīng)要穩(wěn)定且可以版本化管理。A/B測(cè)試可以上真實(shí)環(huán)境但離線評(píng)測(cè)必須保持環(huán)境純凈。第二個(gè)是多次運(yùn)行取分布。Agent具備隨機(jī)性即使溫度設(shè)0也不能保證完全確定工具返回內(nèi)容、上下文方差都可能導(dǎo)致結(jié)果漂移。所以關(guān)鍵實(shí)驗(yàn)我建議同樣的任務(wù)至少跑3次記錄成功次數(shù)的分布而不是單次結(jié)果。比如某任務(wù)跑了3次成功2次成功率記為0.67這比單次0或1有意義得多。代價(jià)是評(píng)測(cè)耗時(shí)增加但換來的是對(duì)穩(wěn)定性的理解值得。4.3 回歸看板與發(fā)布門禁讓評(píng)測(cè)真正影響決策評(píng)測(cè)體系如果只是每周出一份報(bào)告價(jià)值就少了一半。真正要讓評(píng)測(cè)影響決策必須做成“門禁”和“看板”看板要常駐。我們有一個(gè)內(nèi)部頁(yè)面展示主干版本的每個(gè)指標(biāo)折線圖。橫軸是版本號(hào)縱軸是歸一化分?jǐn)?shù)或原始指標(biāo)。任何人一打開就能看到上一版到這一版哪個(gè)指標(biāo)漲了、哪個(gè)跌了。這比評(píng)審會(huì)上翻PPT高效太多。門禁要硬。在CI/CD流水線里加上評(píng)測(cè)步驟核心回歸集不過不允許merge到主干A/B測(cè)試沒完成不允許全量發(fā)布。具體門檻可以這樣設(shè)置任務(wù)成功率不低于前一個(gè)版本安全違規(guī)率為0p95延遲增加不超過5%單任務(wù)成本增幅不超過10%。這里的安全違規(guī)率我建議設(shè)置成硬性0容忍其他指標(biāo)可以允許小幅波動(dòng)但要解釋原因?；貧w看板還有個(gè)作用逼著團(tuán)隊(duì)面對(duì)穩(wěn)定性的問題。如果某個(gè)版本成功率抖動(dòng)很大看板上會(huì)顯示方差變寬這時(shí)候不管是模型還是評(píng)測(cè)集的問題都得停下來查清楚而不是看均值“好像還行”就放過去。5. 常見問題與排查技巧實(shí)錄前面講的都是理想框架實(shí)操中幾乎每一步都會(huì)出幺蛾子。這一節(jié)專門記錄我遇到過的高頻問題每個(gè)都踩過坑希望能幫你少走彎路。5.1 LLM-as-Judge不聽話評(píng)分飄忽、與人類不一致現(xiàn)象一同樣是“很好”的答案換了個(gè)Judge模型就變成低分。排查方案是先看評(píng)分卡是不是足夠客觀。如果評(píng)分卡還在用“請(qǐng)?jiān)u估回答質(zhì)量”那是評(píng)分卡的問題不是Judge的問題。改成帶維度粒度和示例的評(píng)分卡一致性會(huì)明顯提升?，F(xiàn)象二Judge和人工標(biāo)注的一致性只有60%。這種時(shí)候不要硬上Judge先找到分歧集中在哪類樣本。我遇到過Judge對(duì)“間接回答了問題但沒直接給答案”的情況格外嚴(yán)厲而人類覺得這種回答可以接受雙方打分手腕不一樣。解決方案是給Judge加一條“允許Agent追問澄清”的規(guī)則并在標(biāo)注手冊(cè)里同步說明讓人類和Judge對(duì)齊?，F(xiàn)象三Judge自己出現(xiàn)幻覺在理由里寫了一些回答里根本沒有的內(nèi)容。這種情況只能靠更換更強(qiáng)的Judge模型以及增加“回答中是否包含xxx”這種可驗(yàn)證性的評(píng)分維度來緩解。記住Judge也是有幻覺風(fēng)險(xiǎn)的模型不能全盤信任。5.2 人工標(biāo)注質(zhì)量和一致性差最典型的場(chǎng)景是雙人標(biāo)注一致率不到70%Kappa低于0.5。一開始我們以為是標(biāo)注員不認(rèn)真后來復(fù)盤發(fā)現(xiàn)是標(biāo)注手冊(cè)里“邊界案例”太多比如“用戶要求Agent幫忙改寫郵件但保留語(yǔ)氣不變”什么樣算語(yǔ)氣不變不同人理解完全不同。解法分三步第一步把分歧最大的樣本收集起來逐條討論把新確認(rèn)的規(guī)則補(bǔ)進(jìn)標(biāo)注手冊(cè)。第二步對(duì)標(biāo)注員做一次集中培訓(xùn)重點(diǎn)講新增的邊界案例。第三步重新抽一批獨(dú)立樣本測(cè)Kappa。通常這一輪下來一致性會(huì)從0.5拉到0.7以上。如果還不行就得考慮是不是指標(biāo)本身定義太模糊需要換一個(gè)更容易判定的指標(biāo)。5.3 A/B測(cè)試跑不出顯著差異這是最讓人崩潰的場(chǎng)景之一明明離線評(píng)測(cè)有明顯優(yōu)勢(shì)線上A/B就是沒有顯著結(jié)果。我遇到過的原因有三種第一種樣本量確實(shí)不夠。跑了一周就著急看數(shù)據(jù)置信區(qū)間寬得能裝下整個(gè)宇宙。解法是事先算好樣本量耐住性子跑夠時(shí)間。第二種指標(biāo)選錯(cuò)了。離線評(píng)測(cè)用的是任務(wù)成功率線上實(shí)際統(tǒng)計(jì)的是“用戶發(fā)起會(huì)話后有沒有點(diǎn)‘已解決’”這兩者口徑差異很大。我在早期犯過這個(gè)錯(cuò)離線成功率提升10%線上“已解決率”紋絲不動(dòng)最后發(fā)現(xiàn)線上用戶根本不會(huì)主動(dòng)點(diǎn)“已解決”。解法是要用跟業(yè)務(wù)結(jié)果強(qiáng)相關(guān)的指標(biāo)來做A/B而不是直接搬離線指標(biāo)。第三種版本差異被噪聲淹沒。線上流量本身波動(dòng)很大節(jié)假日、活動(dòng)、渠道投放都會(huì)帶來噪聲。建議A/B期間同時(shí)監(jiān)控自然波動(dòng)數(shù)據(jù)或者用分位數(shù)、更長(zhǎng)時(shí)間的窗口來觀察而不是只看每天的均值。5.4 評(píng)測(cè)集污染與線上失真評(píng)測(cè)集被污染的表現(xiàn)是離線分越跑越高線上業(yè)務(wù)指標(biāo)毫無變化甚至下滑。除了訓(xùn)練數(shù)據(jù)可能包含評(píng)測(cè)題之外還有一種常見情況是評(píng)測(cè)集本身構(gòu)建時(shí)帶偏見——偏向某一種回答風(fēng)格或問法導(dǎo)致Agent在評(píng)測(cè)集上練得“過擬合”。防止線上失真的核心是兩條一是評(píng)測(cè)集持續(xù)更新不能一年到頭就那幾百道題二是定期做“盲測(cè)回流”——從線上隨機(jī)抽出真實(shí)用戶請(qǐng)求作為臨時(shí)評(píng)測(cè)樣本跑一輪離線評(píng)估看離線分?jǐn)?shù)和線上真實(shí)表現(xiàn)是否一致。一旦發(fā)現(xiàn)兩者越來越脫節(jié)就要馬上重寫評(píng)測(cè)集或調(diào)整評(píng)測(cè)邏輯。模型在進(jìn)化用戶問題也在進(jìn)化評(píng)測(cè)集不是一次性資產(chǎn)這點(diǎn)一定要有意識(shí)。我個(gè)人在實(shí)際操作中的一個(gè)體會(huì)是評(píng)測(cè)體系做得越久越要警惕“為了好看而評(píng)測(cè)”。指標(biāo)不是越多越好手段也不是越高級(jí)越好關(guān)鍵是能不能幫你在正確的時(shí)間攔住錯(cuò)誤的版本。這些方法組合在一起就是我和團(tuán)隊(duì)目前跑得很順的v21.0方案。它不一定適合所有團(tuán)隊(duì)但至少提供了一條從“憑感覺”走向“用數(shù)據(jù)說話”的可行路徑。