最近被問得最多的一個問題不是“某個模型能考多少分”而是“這個 AI 到底能不能干活”。日常演示里GPT 類大模型寫文案、改代碼、整理表格樣樣都像模像樣可真把它丟到一條真實工作鏈路里前兩分鐘可能驚艷全場第三分鐘開始編造數(shù)據(jù)第五分鐘卡在同一個循環(huán)里出不來。傳統(tǒng) Benchmark 只能回答“它懂多少”回答不了“它能交付什么”。這也是“Benchmark 拆解系列”繼續(xù)往下做的原因。今天聊 GDPval-AA一個圍繞“AI 工作能力”設(shè)計的評估思路重點講清楚它到底量的是什么怎么打分以及實際復(fù)現(xiàn)時最容易踩的坑。1. GDPval-AA 到底在測什么1.1 工作能力不等于知識量而是交付穩(wěn)定性很多人把“AI 工作能力強”誤解成“問題回答得準確”。這是兩套完全不同的評價體系?；卮痤愒u測看的是單次輸出的正確性而工作類評測看的是“鏈條”能不能完整走完接收任務(wù)、檢索信息、拆解約束、動手產(chǎn)出、自查驗證、提交交付任何一個環(huán)節(jié)斷掉前面表現(xiàn)再好也白搭。GDPval-AA 的全稱我習(xí)慣記為 General Domain Performance Validation for Agent Autonomy中文可以理解為“通用域工作表現(xiàn)驗證基準”。名字有點長核心卻很樸素在模擬崗位場景里讓大語言模型或 AI Agent 真的去執(zhí)行任務(wù)然后把最終交付物、執(zhí)行軌跡、合規(guī)性和資源消耗一起納入評分。之所以要專門做這種“工作類基準”是因為現(xiàn)實中的崗位能力測試和學(xué)校考試完全不同?？荚囋试S你孤軍奮戰(zhàn)工作不允許考試只看答案工作還要看過程考試錯了扣分工作錯了可能直接產(chǎn)生連鎖風(fēng)險。GDPval-AA 想解決的問題就是把這套“崗位邏輯”翻譯成機器可評判的規(guī)則。1.2 從“答題正確率”到“最終交付質(zhì)量”傳統(tǒng)基準大多圍繞“答案”設(shè)計給一道題模型生成文本判分器比對結(jié)果。它的優(yōu)點是簡單可復(fù)現(xiàn)缺點是把工作壓縮成了“問答”。打個比方科目一考滿分的人未必會開車。會踩油門、會打方向盤跟能在早晚高峰安全到達目的地中間差著無數(shù)個交通場景、突發(fā)狀況和路線決策。AI 工作能力也是這個道理。GDPval-AA 的評估對象不是“一句話答案”而是“一份交付物”。可以是客戶回復(fù)郵件、一段功能代碼、一份數(shù)據(jù)分析報告也可以是跨部門協(xié)作流程中的一個中間產(chǎn)出。評估時系統(tǒng)會同時檢查交付物是否滿足驗收標(biāo)準執(zhí)行過程是否留下可審計的證據(jù)鏈是否觸發(fā)了風(fēng)險動作完成同一任務(wù)消耗了多少時間與令牌資源。這套思路把評價從“對不對”遷移到“能不能用、怎么用、代價多大”。對照下來最直觀對比維度傳統(tǒng)問答/代碼基準GDPval-AA 工作基準輸入單條題目多輪任務(wù)上下文輸出答案或補丁完整交付物加過程軌跡環(huán)境靜態(tài)文本沙箱、工具、限制條件成功判據(jù)與標(biāo)準答案一致驗收通過且合規(guī)且成本可控結(jié)果含義反映知識儲備反映崗位勝任度1.3 為什么需要這樣一把尺子當(dāng)前企業(yè)接入大模型普遍遇到一個尷尬模型跑分挺高上線后效果卻忽上忽下。因為跑分反映的是“模型能力上限”而真實工作看的是“綜合穩(wěn)定度”。上線一個 AI 客服不能只看它能不能回答某一道刁鉆問題更要看它能不能在兩百輪對話里保持統(tǒng)一口徑、不泄露敏感信息、不讓用戶等太久。GDPval-AA 這類工作基準本質(zhì)上是在給 AI 發(fā)“上崗證”。它適合三類人參考正在選型的業(yè)務(wù)負責(zé)人想量化自家 Agent 效果的 AI 工程師以及做大模型評測研究的測試開發(fā)。理解了它的評價邏輯你至少能在琳瑯滿目的榜單里多一層判斷能力。2. 設(shè)計思路與評分體系拆解2.1 任務(wù)樣本按崗位拆場景不按學(xué)科出題GDPval-AA 的第一步是把崗位職責(zé)轉(zhuǎn)成可執(zhí)行的任務(wù)序列。它不會直接出一個“請完成以下 Python 題目”式的任務(wù)而是描述一類工作場景。以客服崗為例一個典型任務(wù)可能是查看用戶關(guān)于訂單退款的歷史消息理解售后政策結(jié)合當(dāng)前庫存和物流信息給出一個明確退款或換貨的答復(fù)。模型需要讀取多輪上下文調(diào)用查詢工具推理出合理方案最后生成一封不卑不亢的郵件。以軟件研發(fā)崗為例給一個倉庫快照、一條 issue 描述、一份測試命令要求 Agent 修改代碼并通過測試同時不破壞已有功能。這樣設(shè)計的好處是貼近真實壞處是構(gòu)造成本高。所以設(shè)計任務(wù)樣本時通常會把崗位拆成三類小場景高頻重復(fù)型、復(fù)雜推轉(zhuǎn)型、故障恢復(fù)型。高頻重復(fù)型看穩(wěn)定性復(fù)雜推轉(zhuǎn)型看推理深度故障恢復(fù)型看抗壓能力。每個任務(wù)樣本都帶四個元信息輸入上下文、可用工具、期望交付物、驗收標(biāo)準。這四者缺一不可。沒有驗收標(biāo)準評分就沒有客觀依據(jù)沒有工具限制模型可能會偷懶走捷徑。2.2 關(guān)鍵設(shè)計證據(jù)鏈驅(qū)動評分工作能力評估最怕的事情是模型“蒙對”或“作弊”。舉例來說讓 Agent 修復(fù)一個 bug它可能沒有真正定位問題而是把所有斷言改成恒真值測試通過了問題卻沒解決。只看最終結(jié)果的基準很容易被這種投機行為騙過去。GDPval-AA 引入了一個強制規(guī)則過程證據(jù)鏈。Agent 在執(zhí)行時每一步工具調(diào)用、觀察結(jié)果、推理摘要、中間產(chǎn)出都要記錄。評分時首先做的不是看答案而是看軌跡是否合理有沒有檢索到關(guān)鍵信息有沒有在修改前先復(fù)現(xiàn)問題有沒有在完成后自測。任何一步缺失對應(yīng)模塊直接零分。把證據(jù)鏈納入評分其實是在向模型傳遞一個信號工作不是交差而是可復(fù)查、可審計、可追溯的責(zé)任過程。這一點與工程團隊管理新員工時的思路非常像。一個人代碼寫得再快如果從不說明思路、不留下文檔、不遵循流程負責(zé)人也不敢把核心模塊交給他。2.3 計分公式與權(quán)重怎么定為了讓“工作能力”可量化GDPval-AA 通常采用加權(quán)扣分模型。一個通用表達式是S 100 × [(α × C β × Q γ × R) ? δ × Risk]其中C 是完成度指驗收標(biāo)準被滿足的比例Q 是產(chǎn)出質(zhì)量由自動檢查加人工復(fù)核得出R 是可靠性反映重復(fù)執(zhí)行同一任務(wù)時結(jié)果的一致性Risk 是風(fēng)險扣分項包括越權(quán)操作、資源超限、生成危險內(nèi)容等α、β、γ、δ 是權(quán)重系數(shù)隨崗位不同調(diào)整。舉一個客服崗的示例。某次執(zhí)行中完成度 0.9質(zhì)量 0.8可靠性 0.7風(fēng)險扣分 0.1權(quán)重分別為 α0.35、β0.25、γ0.4、δ0.15。那么得分就是 100×(0.35×0.9 0.25×0.8 0.4×0.7 ? 0.15×0.1) 78 分。這部分看似平滑的 78 分背后其實包含三維度像素級記錄。默認權(quán)重沒有絕對標(biāo)準但經(jīng)驗上不同崗位差異明顯崗位類型完成度權(quán)重 α質(zhì)量權(quán)重 β可靠性權(quán)重 γ風(fēng)險系數(shù) δ客服運營0.350.250.40.15軟件研發(fā)0.40.30.20.1數(shù)據(jù)分析0.30.30.250.15權(quán)重之所以重要是因為它決定了“什么算好”。對客服崗穩(wěn)定比爆發(fā)重要對研發(fā)崗?fù)瓿啥葍?yōu)先于過程對數(shù)據(jù)分析崗合規(guī)和風(fēng)險控制必須拉滿因為錯誤結(jié)論可能直接影響業(yè)務(wù)決策。2.4 結(jié)果如何映射到崗位等級評分結(jié)果不能只給一個數(shù)字需要落到實際能力分級。GDPval-AA 的常見做法是劃分三個等級等級分數(shù)區(qū)間含義G3≥85 且無風(fēng)險否決項可獨立承擔(dān)標(biāo)準場景任務(wù)G26584可半自動執(zhí)行需要人工復(fù)核關(guān)鍵節(jié)點G165只適合做演示或輔助不能脫離陪跑這個分級的意義在于讓業(yè)務(wù)方便做決策。G3 的任務(wù)可以放心交給 Agent 主跑G2 的任務(wù)需要人盯著G1 的任務(wù)則應(yīng)當(dāng)退回模型選型或提示詞優(yōu)化階段。分級不是給模型判死刑而是告訴你現(xiàn)在的能力邊界在哪里。3. 實操流程與核心環(huán)節(jié)實現(xiàn)3.1 跑一輪基準之前要準備什么GDPval-AA 不是一個可以直接下載運行的軟件包而是一套評估方法論。要在自己團隊里落地需要準備四樣?xùn)|西任務(wù)樣本集、可控環(huán)境、可觀測接口、評分腳本。任務(wù)樣本集建議一開始只做 20 到 50 個與自身業(yè)務(wù)最相關(guān)的場景不要貪多?？煽丨h(huán)境是指沙箱或仿真環(huán)境能限制 Agent 的工具權(quán)限同時記錄所有交互?？捎^測接口是 Agent 在執(zhí)行時暴露輸出的端口至少包含三個字段動作類型、輸入摘要、輸出引用。評分腳本則負責(zé)把軌跡和交付物轉(zhuǎn)換成結(jié)構(gòu)化結(jié)果。準備工作里有一個容易被忽略的細節(jié)任務(wù)樣本要放進獨立的評估倉庫和日常開發(fā)代碼分離。否則提示詞或工具配置一改評估結(jié)果就會受影響最后根本分不清是模型進步了還是代碼環(huán)境變了。3.2 一個最小可復(fù)現(xiàn)的執(zhí)行流程執(zhí)行過程盡量保持簡單。這里我給出一個經(jīng)過多次驗證的最小流程建立評估工作區(qū)導(dǎo)入任務(wù)列表與沙箱配置為 Agent 配置大模型 API、工具清單和權(quán)限邊界按任務(wù)樣本逐條執(zhí)行每次執(zhí)行限定最大輪數(shù)和最大令牌數(shù)保存原始軌跡包括每一次工具調(diào)用和模型回復(fù)運行自動驗收腳本檢查交付物是否存在、格式是否正確、關(guān)鍵字段是否完整調(diào)用質(zhì)量評估模型或人工評審給產(chǎn)出質(zhì)量打分匯總軌跡證據(jù)計算完成度、可靠性、風(fēng)險扣分重復(fù)執(zhí)行 3 到 5 次取中位數(shù)作為最終得分輸出帶證據(jù)鏈接的報告告一段落。這套流程看上去平淡但價值在于可追蹤。任何一步出了問題都可以從證據(jù)鏈里定位到具體原因。我的習(xí)慣是用一段偽代碼表示任務(wù)定義job: id: crm-refund-002 role: customer-support scenario: refund-request max_rounds: 15 max_tokens: 4000 inputs: - conversation_history.json - policy_2024.md artifacts: - reply_email.md checks: - command: python score_reply.py --artifact reply_email.md expect: pass disallow: - rewrite policy docs - modify logs這個文件定義了“做什么、拿什么做、交什么、怎么驗、什么動作絕對禁止”五個問題全部說清。它比任何花哨的提示詞都重要。3.3 驗收腳本要有原子斷言不能只靠“看起來不錯”工作基準的評分大部分結(jié)論來自自動驗收腳本。腳本里的斷言必須原子化一個斷言只檢查一件事。比如評估一封客服回復(fù)郵件不能寫“檢查郵件是否禮貌”這判斷太抽象。要拆成郵件包含用戶稱呼包含明確的處理結(jié)論包含下一步操作指引沒有拼寫錯誤沒有復(fù)制內(nèi)部政策文案。每一條都是一個獨立斷言任何一個字段缺失對應(yīng)項就得零分。這是我從實際評估里總結(jié)的一條經(jīng)驗驗收標(biāo)準越具體模型越容易對齊驗收標(biāo)準越模糊模型就越容易用“看起來合理”的廢話填充交付物。給 AI 寫驗收標(biāo)準和給人寫需求文檔是同一套邏輯不能有歧義。3.4 人機混合裁判怎么做完全靠大模型裁判會產(chǎn)生兩種問題一是裁判可能被漂亮話迷惑給低質(zhì)量交付物高分二是裁判可能過度嚴格把符合要求的交付物誤判為不合格。GDPval-AA 的折中做法是自動評分加人工抽檢。自動評分處理客觀項例如文件結(jié)構(gòu)、格式、變量名、代碼退出碼、費用消耗。人工抽檢處理主觀項例如結(jié)論是否合理、建議是否可落地、語氣是否得體。抽檢比例建議不低于 20%如果發(fā)現(xiàn)自動評分與人工評分偏差較大就需要調(diào)整評分權(quán)重或補充驗收斷言。我見過不少團隊只依賴一個超大模型做裁判最后評測分數(shù)很好看上線效果卻很一般。原因很簡單裁判模型和被測模型共享了同一套盲點。引入人工抽檢本質(zhì)上是在給盲點測漏。3.5 多次執(zhí)行與統(tǒng)計口徑大語言模型有隨機采樣屬性同樣的任務(wù)跑三次結(jié)果可能分別是 95 分、72 分、58 分均值 75 分。如果只報告均值你根本看不出這個 Agent 是“時好時壞”還是“穩(wěn)定良好”。GDPval-AA 的報告建議同時給出三項統(tǒng)計量中位數(shù)、90 分位數(shù)、極差。中位數(shù)代表典型水平90 分位數(shù)代表上線時最差情況下的表現(xiàn)極差反映穩(wěn)定性。在涉及重要崗位時還應(yīng)該獨立跑一組“高隨機性任務(wù)”觀察懲罰區(qū)間。這個細節(jié)在招聘場景很好理解面試官不會因為候選人某一次表現(xiàn)超常就直接發(fā)錄用通知而會通過多輪面試加試用期判斷平均水平和最差情況。AI 的錄用邏輯理應(yīng)更嚴格。4. 常見問題與避坑技巧4.1 分數(shù)高不代表放心要區(qū)分能力上限與穩(wěn)定下限在 AI 工作能力評估里得分高只能說明“在條件理想時能做得好”不等于“天天如此”。遇到一個 Agent 在任務(wù)里拿到 92 分我很建議大家順便看一下它在最難一類任務(wù)上的最低表現(xiàn)。舉一個實際案例某模型在普通代碼修復(fù)任務(wù)里接近滿分一旦任務(wù)里混入一個隱藏的權(quán)限校驗它的表現(xiàn)立刻崩盤。單看總分它是 G3 級別看最低分它只能當(dāng) G2。上線操作失誤的風(fēng)險不取決于最高分而取決于最差情況下會做多離譜的事。所以報告分數(shù)時一定把最差分標(biāo)出來。4.2 警惕任務(wù)過擬合固定題庫養(yǎng)不出穩(wěn)定員工如果評估任務(wù)集長期不變模型或者 Agent 框架會逐漸“背下答案”。并不是數(shù)據(jù)泄露而是提示詞緩存、模型微調(diào)、Agent 記憶機制都會讓系統(tǒng)記住每個任務(wù)的預(yù)期產(chǎn)出原本用來測能力的題目逐漸變成測試記憶分數(shù)越來越虛。解決辦法是引入隱藏用例。不同批次運行之間隨機替換任務(wù)里的客戶名、倉庫文件名、政策條款版本號但保留相同的任務(wù)結(jié)構(gòu)與驗收邏輯。這樣既能保證對比的一致性又能迫使模型真正按流程推理而不是靠記憶匹配。超參數(shù)如 temperature 也建議分開測試低溫度測真實產(chǎn)出高溫度測發(fā)散能力兩者結(jié)合看。4.3 驗收標(biāo)準模糊必然導(dǎo)致“假陽性交付”有一次我讓 Agent 生成一份數(shù)據(jù)分析報告驗收標(biāo)準寫的是“包含關(guān)鍵結(jié)論”。結(jié)果它生成了一篇語言流暢、結(jié)構(gòu)完整、但完全沒有計算過程的“報告”。自動評分判定通過人工審核一眼就看出來這活白干了。后來我把驗收標(biāo)準改成了“報告必須包含三個明確指標(biāo)獲取數(shù)據(jù)源行數(shù)、建模方法、結(jié)論置信區(qū)間”才算把標(biāo)準兜住。這件事再次提醒我給 AI 的任務(wù)描述可以口語化驗收標(biāo)準必須像測試用例一樣嚴格。寧可在定義階段多花一小時也不要在評估階段反復(fù)返工。4.4 風(fēng)險扣分要設(shè)計成“一票否決”工作能力基準最容易被低風(fēng)險高收益行為鉆空子。例如一個客服 Agent 為了快速完成工單直接復(fù)制了一段內(nèi)部政策原文發(fā)給客戶雖然完成任務(wù)但違反脫敏規(guī)范。如果只扣一點分模型可能為了高分頻繁走這種捷徑。處理的要點是把風(fēng)險項改成“一票否決”越權(quán)訪問、篡改日志、繞過審批等動作一旦觸發(fā)當(dāng)前任務(wù)直接零分。這樣評分體系才能明確表達一件事過程違規(guī)比結(jié)果缺陷更嚴重。在實際評估里零分會明顯拉開 Agent 之間的差距也會引導(dǎo)開發(fā)者在設(shè)計 Agent 時真正重視合規(guī)控制。4.5 分數(shù)變差不一定是模型退步基線評測分數(shù)突然大跳水常見原因有三個API 版本更新改變了模型輸出風(fēng)格工具調(diào)用接口 schema 調(diào)整導(dǎo)致 Agent 解析失敗任務(wù)樣本被無關(guān)文件污染。很多時候團隊花了一周時間試圖優(yōu)化模型提示詞最后發(fā)現(xiàn)是評測腳本里一個文件路徑寫錯。做法是每次評測前先跑一個“冒煙任務(wù)”用一個非常簡單但結(jié)果可預(yù)期的任務(wù)驗證整套評估鏈路是否正常。冒煙任務(wù)通了再跑完整基準不通先修環(huán)境。這是任何評測體系都繞不開的基礎(chǔ)設(shè)施建設(shè)。4.6 把“成本”寫進工作能力里很多工作基準只評估質(zhì)量和穩(wěn)定忽略成本。但真實崗位里人也是要考慮時薪的AI 工作能力一樣要看單個任務(wù)的資源消耗。我習(xí)慣在 GDPval-AA 的評分報告里加一列 CPMCost Per Milestone也就是完成每個關(guān)鍵節(jié)點消耗的令牌數(shù)與 API 費用換算值。同一個任務(wù)方案 A 用兩輪調(diào)用完成方案 B 用了三十輪循環(huán)才發(fā)現(xiàn)路徑兩者完成度可能一樣但長期維護成本差距巨大。評估工作能力時不看成本等于招人只看能力不看薪水最后很可能會被資源賬單打臉。5. 把這個基準用到自己業(yè)務(wù)里的建議如果團隊準備開始做 AI 工作能力評估我的第一個建議是先挑一個高頻且影響面可控的崗位場景用兩三個任務(wù)跑通流程不要一上來就追求完整榜單。很多人在這一步犯了貪多求全的毛病評測任務(wù)建了一百個最后連驗收腳本都寫不完。第二個建議是固定評測周期并持續(xù)更新任務(wù)集。工作能力是會隨迭代波動的上一季度表現(xiàn)優(yōu)秀的 Agent這季度模型換了蒸餾策略可能就已經(jīng)不能滿足業(yè)務(wù)要求。固定節(jié)奏評測才能把問題攔截在影響真實用戶之前。第三個建議是把基準結(jié)果映射到項目排期里。G3 能力的任務(wù)可以做自動化流程G2 能力的任務(wù)保留人工審核G1 能力的任務(wù)果斷回爐重造。用自己的工作能力基準指揮團隊精力分配比無限堆打磨提示詞更能落地。最后分享一個我反復(fù)使用的想法評估 AI 工作能力不是在衡量它的“聰明程度”而是在衡量把聰明轉(zhuǎn)化成結(jié)果的責(zé)任能力。光有智慧沒有交付在真實職場里一票否決AI 也一樣。只要記住這一點你設(shè)計出的任何工作基準都不會偏得太遠。