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