評測也很酷，Data Agent 自動化評測的三層框架與實戰

作者｜尹小明

編輯｜李忠良

策劃｜AICon 全球人工智能開發與應用大會

在大模型技術飛速發展的當下，大數據領域的各類應用如雨后春筍般涌現，從數倉開發到 ChatBI 問數，再到深度分析 Agent，這些領域的大模型應用極大地提升了數據處理和分析的效率。但與此同時，如何科學、準確地評估這些應用的效果，成為了行業面臨的重要難題。

InfoQ 榮幸邀請到了字節跳動 / 數據平臺大模型評測技術負責人尹小明在 AICon 全球人工智能開發與應用大會·深圳站上分享了《評測也很酷——Agent 自動化評測技術創新與實踐》。作為字節跳動數據平臺的大模型效果評估團隊，他們深耕數據應用 Agent 領域，構建了覆蓋從數據開發到數據應用垂直領域 Agent 應用的評測技術體系，尤其在自動化評測算法、Agent 級評測框架等方面形成了可落地的技術方案。本次分享將聚焦這一領域的技術細節與實踐經驗。

12 月 19～20 日的 AICon 北京站 將錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。

詳細日程見：

https://aicon.infoq.cn/202512/beijing/schedule

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

為什么“評測也很酷”：

從用例到效果度量

先談今天分享的主題——“評測也很酷”。在傳統軟件測試中，我們編寫并執行用例，核對功能是否正常即可。而在大模型相關場景中，評測的復雜度和挑戰明顯更高。

挑戰主要體現在兩方面：一是如何更加貼切地評價我們所構建應用的實際效果；二是既有的傳統技術是否可復用，若不足，我們應在何處開展探索與創新。那當我們談“模型評測”時，究竟在說什么、常見的評測維度和指標有哪些？

首先是“效果”，也就是大家常說的好不好、準不準。這里有三個常見指標，首先是事實性，指模型在回答時是否遵從通識和常識，在給定上下文的情況下是否依據證據作答，是否存在“幻覺”；其次是有用性，回答是否對任務有幫助，不能只是講了實話卻對問題沒有實質價值；最后是有害性，這是模型訓練和評估都會關注的方向，比如是否觸及政治敏感、是否引導不當行為等；

其次，是性能與推理性能。很多人都有這種體驗：大模型輸出 Token 很慢，我得等很久，眼看著一個字一個字往外蹦。這里通常涉及首個 Token 出現的時間，也就是首字符 / 首 Token 時延，以及完整推理過程中的生成速度等；同時還要看資源消耗，這些都應納入評估口徑；

第三是穩健性，或者說魯棒性。重點在于能不能容錯、持續穩定地輸出，以及面對對抗或異常輸入時的抗攻擊能力。這些都直接關系到上線后的可用性與風險。

明確了該“看什么”，接下來就是“怎么評”。在實際工作中，當前的常見評測方法有以下幾種：

首先人工評測。在大模型生成帶有主觀性的內容時，比如一次性生成幾千張創意圖片，哪個更好、哪個更差，通常要先請領域專家過一遍，并據此寫出清晰的評價標準——我們認為什么是“好”，什么是“壞”；其次是自動化評測。

業界普遍的做法大致有幾類：一類是客觀題（單選或多選），便于直接做結果匹配；文本類會更難一些，常見思路是和標準答案做相似度比較，配合相應算法和指標，比如 BLEU、ROUGE 等；還有一類是基于排序的評估（rank），在 RLHF 里就很典型——不是給一個絕對分，而是讓人對多個候選進行相對優劣比較，從而完成與人的偏好對齊。

此外，人機協同評測。很多場景里，純自動化還達不到足夠準確、足夠讓人放心的程度，于是通常采用機器先給出初步結論和建議，再由人工復核與定判。

不過，落地過程中依然會暴露出一些共性痛點。

一方面當下有很多評測 Benchmark，也有很多評測集。當評測結束之后，大家常有一個痛點：你說現在效果很好，可為什么線上客戶老在吐槽，說“我的感覺沒有你說的分數那么高”？這其實就是靜態評測和線上實際效果脫節的問題。

另一方面：今天很多評測往往針對模型的單一能力，或者若干常見的通用能力。這就像高考考數學、語文、英語；但這些科考完，放到自己的業務里會發現，成績好并不等于能力強。回到實際業務場景，我該怎么綜合評估他的能力？

再者，即便有了一個評測集，業務在變，產品定義在變，線上用戶的使用方式也在變。這個時候，評測就更難反映線上的真實情況。

以上是通用框架，落到數據應用 Agent，具體會碰到哪些垂直適配難點？

第一，領域特殊性。模型的代碼生成能力很強，但在早期訓練語料里，SQL 的占比非常低。所以你會發現：它寫 Python 還不錯，寫 SQL 就明顯吃力。另外，在數據領域，數據“正確性”極其關鍵。

找資料、寫個想法，準不準影響也許不大；但一份數據分析報告，或者一個關鍵數值，最后要給到老板，如果這個數差之千里，后果就很嚴重了。

還有，從評測的維度來看，通用模型通常關注一些基礎能力，比如數學。但一旦落到真正的 Agent 場景，情況就完全不同了。在數據（Data Agent）方向，像“深度研究”這樣的產品形態，涉及的維度非常多。其包括數據源的差異、數據的異構性都很復雜。

因此，對應的評估維度也需要從單一能力，擴展到能夠覆蓋這些復雜因素。

第三，“效率”與“并發”非常關鍵，這里的并發指研發并發，同時嘗試多種方案。這點尤其重要。為什么？因為在做模型時，我們至今并沒有一套被驗證為“最有效”的通用架構；模型本身也在不斷迭代。

很難沿著一條技術路線一直走到底，所以必須做大量嘗試；新模型出來，也要做新的探索。此時能否承載方案空間的復雜度，往往決定成敗。因此，評測的效率就顯得格外重要。一輪回歸測試要做兩周，和一天之內就能判斷一個方案是好是壞，帶來的研發周期差異可想而知。

三層評測框架

前面說的是數據領域里可能會遇到的問題。回到 Agent 這邊，我們提出了一個“三層評測”的體系設計。在構建大模型的 Agent 應用時，通常會同時面對幾層問題。

最下層是技術選型。市面上的模型很多，豆包、千問、文心、DeepSeek 等等。我的 Agent 關注哪些能力，哪些模型能達標、值得進入實驗集？不能盲目把所有模型都往架構里堆，并發和成本都承受不住。先做一輪有依據的篩選，這一步非常關鍵；

中間層是研發迭代。確定了初步架構之后，需要持續優化，并能看清 Agent 的各個部分在哪里拖了后腿。大家熟悉的 Multi-Agent、ReAct、workflow 都會用到。做法上更像“單元測試”式的評測：把子模塊拆開看，既看效果也看速度，把問題收斂到具體模塊，迭代才高效；

最上層才是端到端的業務效果。最終要用一套覆蓋完整鏈路的評測集與流程，加上相應的方法實踐，來衡量這個 Agent 在真實任務中的表現到底如何。

圍繞上述各層，我們開展了配套實踐。

第一個層面是基礎能力評測，對應我們前面說的技術選型階段。做這件事的目的，是先設定一個“準入門檻”。以數據領域為例，我們會關注工具調用能力（Function Call、Tool using、MCP 等）、數值計算與表格理解、數據幻覺的控制、復雜指令遵循，以及編碼與 Text-to-SQL。各個方向基本都有可參考的開源 Benchmark。

比如在 Function Call 方向，我們調研后會采用 ComplexFuncBench；在編碼能力上，早期熟悉的 HumanEval 仍有參考價值，現在也會引入 SWE-Bench（評估代碼 Agent 能力的 Benchmark）。這些評測會接入我們的平臺，提供給數據平臺的各個探索團隊使用。

第二個層面是組件（或子 Agent）的評測，面向的是 Agent 的各個組成部分。可以把一個 Agent 的工作流程拆成幾個階段：先是召回，比如做 Schema Linking；然后是理解與規劃；接著進入洞察、分析與執行；最后是結果總結，把結論寫成報告。

我們要看的，是問題出在第幾個階段，以及每個階段的實際表現如何。放到一個典型的 RAG 應用里，前序召回的上下文質量會直接決定后續表現：Schema 里有沒有找到正確的字段、閾值和指標，都會影響后面 SQL 能不能寫對。如果第一階段就偏差很大，后面再怎么優化 Agent 也很難“拉回”。

第三個層面，是端到端效果評測。一方面，我們針對特定的業務場景構建相應的評測集；層級越往上，我們離業務越近，評測也就越貼近實際的業務場景和產品形態的定義。

我們相應地構建評測集和自動化評測方法；同時，在我們的評估平臺上設有“數據與飛輪”模塊對接業務，把線上的會話日志采集進來，用于 Case Study、回歸評測集的沉淀，以及人工標注。

Data Agent 評測技術創新和實踐

基于上述“三層評測”框架，下一步將聚焦 Data Agent 這一主題，結合兩個具體案例展開說明。

其一為 Text-to-SQL 任務。無論是問答取數類 Agent，還是更綜合的分析型 Data Agent，自然語言查詢通常需要轉化為實際的 SQL 查詢；無論用戶提出具體指標問題（如“昨天的 DAU 是多少”）還是總結性分析請求（如“請分析上一周的數據情況”），底層通常都會拆解為若干查詢任務，核心評估點落在 SQL 查詢的準確率與誤差歸因。

傳統的 Text-to-SQL（或 NL-to-SQL）評測方法與數據集（如 Spider、WikiSQL、BIRD-SQL 等）為通用場景提供了基礎衡量手段，但在面向大數據與真實業務約束的環境中，仍會遭遇諸多適配性與可擴展性問題。

傳統評測方法往往只給出“對 / 錯”的結論，這種二元判定無法體現能力優劣的細微差異。以一條 SQL 為例，若僅在某個條件上將“≥”寫成“>”，其余部分完全正確，執行結果可能只相差極小，但在二元評分下仍被判為零分。

若此類情況高頻出現，模型的實際可用性仍然較強——在數據開發場景中，只需改動個別細節即可投入使用——而傳統方法無法反映這種“接近正確”的價值。

所謂“執行正確性”，是指對每個問題—答案對提供標準 SQL 與測試數據集，分別執行標準 SQL 與模型預測的 SQL，比較結果是否一致，以此判斷對錯。

然而實踐表明，這一方法易產生誤判。根源在于測試數據分布并不完備，可能存在“非等價 SQL 執行結果相同”的情況。例如，age > 34 與 age ≥ 34 在測試集中恰無 34 這一邊界值時，二者輸出一致，導致錯誤地判定為正確。

這里放一個稍微復雜點的例子：我們的gold（ground truth）標準答案其實是一條很簡單的 SQL，問題是“文檔中哪些template_id被使用過”。但模型在預測時，去和另一張template表做了INNER JOIN，按id關聯。

肉眼一看就知道兩者不是一回事。按理說，放到設計更嚴謹的數據集上，應該能把差異測出來；可不幸的是，在 Spider 上兩條 SQL 的執行結果一模一樣，最終造成了誤判。

還有一種做法是比較標準答案 SQL 與預測 SQL 的文本相似度。字面上可以直接比對一致性，并計算一個相似度分數，比如余弦相似度等。但這類方法很難準確反映語義 / 邏輯上的等價：哪怕只是表名或子查詢的別名不同，也可能被判為不一致而誤判。

第三個問題，如果要在大數據引擎（比如 ClickHouse）上構造一套可用于回歸測試的數據集，成本非常高。這些都是傳統 Text-to-SQL 評測在實際落地中的局限。

針對以上問題，我們做了一些改進，核心是提出一套基于語義等價的評測方法。所謂語義等價，是指兩條 SQL 在邏輯含義上相同，那么它們在執行結果上就應當相同；只要判斷這一點即可，并不一定需要真正去跑一次查詢。

做法上，先把 SQL 當作代碼處理，表示成抽象語法樹（AST）。進一步，我們借助Apache Calcite做執行層的下推，把字面 SQL 轉成執行層的語法表示，也就是RelNode。到了這一層，很多寫法上的不一致會被歸一到相同的執行語義。

舉兩個直觀的例子：某些情況下，用JOIN和用IN子查詢是等價的；再比如連接兩個表時，你可以用子查詢，也可以用WHERE條件，最終下推到執行語法樹上的執行過程是一樣的。通過這樣的語義下推和標準化，能抹平大量表面差異。

第二個方法，我們把節點之間的引用關系建立起來：參考答案是一張圖，預測答案也是一張圖，然后訓練一個圖匹配網絡（Graph-Matching Network，GMN）來計算兩條 SQL 在語法 / 表達上的相似度。基于語法樹的匹配這一路，我們稱為RelPM（在執行層面的語法樹上做Partial Matching的局部匹配）：用規則做局部比對并賦權，得到 0～1 的相似度分數，已經明顯優于傳統做法。

進一步，在FuncEvalGMN上，無論對比基于執行正確性的評測、基于文本 / 語義相似度的評測，還是一些基于 BERT 的預訓練模型，我們的效果都有顯著提升。在業務側，這套方法也已經成為我們數據領域的核心算法之一。

以上 Text-to-SQL 更偏向“查詢”類場景，不過 Data Agent 的產品形態在不斷豐富。現在形成了一種新的產品形態——“深度研究”。用戶只需提出一個簡單的問題，或者把意圖描述清楚，系統就會給出一套完整的分析流程，并且能夠同時完成多種分析任務。

評測在這里會明顯更難。它不再是簡單的查數題，比 Text-to-SQL 難得多。我們要回答的不是“查得對不對”這么單一的問題，還要判斷：這份報告是否對業務有用；生成時的推理思路是否合理；內容是否完整，是否覆蓋了我要求它分析的那些角度；最后給出的建議是否有效。

用什么維度來衡量一份深度分析報告“好不好”，以及如何把這些維度做成可執行的自動化評測，都是實打實的挑戰。

因此我們首先定義了一套評測體系。它是指用一套明確的標準來衡量好與壞。就像高考有一整套評價口徑；公司招聘、晉升和績效也都有相應的準則一樣。針對“深度研究”這種產品形態，我們從幾個角度來評：一是分析與洞察的深度與準確性；二是報告在展示上的可讀性、易讀性；三是執行過程的穩定性與成功率。圍繞這些，我們設定了第一層與第二層的評估維度，并分別定義了關鍵指標，并在每項指標下設定可落地的評分點。

接下來談自動化評估技術。這是業界相對前沿的話題，大家可能聽過 “LLM as a Judge” 或 “LLM Judge”。我們最新的探索是用 Agent 來評測 Agent。原因很簡單：寫一份數據分析報告，沒辦法把數據直接丟給大模型就指望一次性產出完整結果，中間需要大量 Agent 能力來完成過程性的工作，所以在評測側同樣要引入 Agent 技術。

從評測角度來講。我們也不可能把一個結果直接交給 LLM 就讓它打分完事，評測仍需要 Agent。這里大家可能會有個自然的疑問：Data Agent 做了那么多架構改進、用了那么多技術和技巧，甚至有那么多專家參與，它都可能算不對；為什么“評測的 Agent”能評得出來？

這是我們一開始必須回答的基礎判斷。我的判斷基于幾個前提：第一，挑錯往往比做對容易；給出一套完全正確的方案很難，但指出其中的問題相對容易。第二，可以復盤過程：把 Data Agent 寫報告的完整流程和數據計算鏈路逐步審閱，像批改應用題一樣看每一步思路是否合理；如果每一步都是對的，結果大概率也是對的。第三，可以做定向優化：針對特定領域或特定評測集進行針對性調優，并結合 Agent 方法增強判斷能力。基于這些，我們認為這條路線是有前景的。

在實現上，我們用到一些基本技術。其一是自我反思：模型先按評分標準完成一次打分，再進入反思環節，檢查自己是否完整遵循了打分邏輯、是否有遺漏。其二是多 Agent 協作架構。

我們把評估對象（報告）、評估過程、問題及相關上下文作為整體輸入，送入一個用于應用評估的系統（我們稱為 Critic Agents）。該系統首先按我們的評分標準與細則完成初評分，然后交給 Reflect（自我反思）模塊，復查本次打分是否存在遺漏或不當之處。

再舉一個我們踩過的坑：寫報告時很容易在單位轉換上出錯。原始計算得到的是一個數，寫進報告卻被表述成“XX 萬”。這既是 Data Agent 的高發錯誤點，也是評估里容易被誤判的點。

針對這類問題，我們會把相關環節交給Reflect的反思流程復查；同時引入多個 Agent，從不同角度、甚至基于不同的底層模型分別打分，最后由“裁判長”統一審閱整條打分鏈路及其與標準答案的對齊情況。

整體架構上，我們還會結合ReAct，讓評測側“自己寫代碼”把關鍵數據復算一遍，核對計算是否正確。遇到特定場景（比如歸因分析），要完成有效評估還需要專業的領域計算工具；這些工具同樣交由評判方調用，才能對該類任務給出評價結果。

為說明方法有效性，以下給出兩個真實案例。

這是第一個案例：我們用自動化評測在報告里定位到數據錯誤。上面的片段是一個典型的歸因場景。機評發現，報告寫到“德芙巧克力單筆銷售額 1.5 萬”等數字沒有真實來源。回溯過程可以看到，右側的 SQL 少寫了一個GROUP BY 商品名。

在這種寫法下，只能查出一系列明細訂單，不可能直接得到“德芙巧克力 1.5 萬”這樣的聚合結論。原始明細里雖然出現過“1.5 萬”這個數，但無法據此推斷它對應“德芙巧克力”。這一問題被機評準確抓出。

在人評場景中，讀過類似報告的同學會有同感：像 OpenAI 的 Deep Research 那樣的長報告，要把其中每個數字都核驗一遍，幾乎不現實；人評非常容易漏錯。相比之下，機評在這類細粒度、很復雜的校驗上更有優勢。

第二個例子，我們評估的是“分析意圖的完成度”。左邊是題目：對 DAU 數據做分析；下面先定義分析對象，再給出一套完整的分析框架，也就是要從哪些角度展開。右邊是自動化評測頁面的截圖。紅框里可以看到：這個題目一共有 18 個分析意圖，這份報告完成了 17 個，對應得分 0.94。系統還會標注哪一個意圖沒有完成，已完成的意圖在報告中對應的是哪些章節。由此能直觀看到機評在這個場景下的實際效果。

最后給一組離線實驗數據：我們做了人評與機評的對比。機評在事實性錯誤上的召回率超過 88%，準確性達到 86%。意思是說，真實存在的錯誤里有 88% 以上能被正確發現；而被機評判為“錯誤”的項里，接近九成判斷是對的。對日常評測，尤其是研發迭代，這樣的能力基本夠用。只要測試集覆蓋充分，就能用來比較兩個版本、兩種架構的優劣。

當然也有目前覆蓋不到的部分。比如易讀性高度依賴人工判斷：圖表展示是否出現圖例堆疊等問題，自動化暫時難以發現；再如報告是否“足夠有深度、足夠有豐富度”，這些判斷偏主觀，我們也尚未做自動化覆蓋。

評估平臺的工具與鏈路建設

開展評測不僅需要方法與算法，也需要完善的平臺與工具支撐。我們在數據平臺內部搭建了面向數據評估的統一平臺，定位于為大模型應用的探索與優化提效。平臺覆蓋數據集管理與標注、自動化與人工評測、指標匯總與分析、結果歸因與對比歸因等完整流程，并提供相應的功能組件。

另外平臺同時引入“數據飛輪”，將線上新增案例持續沉淀為評測集，確保評測隨業務與使用方式演化而更新；在基礎選型環節，提供 Benchmark 與榜單模塊，便于業務側進行判斷與選擇。

這里簡單介紹一下幾個特色功能。第一個“數據飛輪”前面已經提過。第二，我們還提供一系列常用評測算子，既有基于規則實現的，也有基于大模型實現的。

業務方可以自行調用，在“自定義策略”模塊里按業務需要編排這些“原子算子”，實現自己的分析邏輯。針對這類場景，我們還設計了“評估工作流”模塊。用過類似 langchain、Dify、Coze 這類平臺的同學都會熟悉，用工作流可視化地搭建一個 agent；同樣地，我們也支持把評估流程用工作流快速搭建起來，更高效地復用算子，而不是一律寫代碼。

這個模塊的反饋很好，內部評測同學也在用它為業務搭建評測流程。舉個很簡單的用法：先對輸入做基礎處理與歸一化，然后調用一個評估算法，或調用大模型，并寫好自己的 prompt，即可把這條評估鏈路跑通。

未來展望

面向未來，自動化評測在數據領域可能的重點投入方向如下：

首先，評測的維度和體系需要進一步完善。現在對多模態能力的利用還不夠，數據集也需要持續優化；流程要更規范，效率要更高。同時要解決線上與線下的一致性：如何讓線下評估盡可能反映線上的真實能力，而不是做成“線上全量、全人工”的評估。

可以通過有效采樣、時效性校驗等手段，持續衡量線下評測數據集是否過時，讓評測結果真正對應用戶的實際體感。

其次，在應用改進方面，以前常講 TDD（Test-Driven Development）。在大模型時代，我更主張“評估驅動開發”（EDD）。它需要把評估更好地分解到 Agent 架構的各個環節：細化到子模塊的能力、推理的不同階段，并把最終業務指標與過程性指標建立起更有效的關聯。

模型訓練層面，無論是精調（SFT）還是強化學習，歸根到底都是與預期業務效果和人類判斷對齊，這與評測天然相關。我們也在探索用自動化評測去反向驅動訓練流程。

最后，是讓自動化評估的結果更快、更高效地生成對應用改進的建議，切實服務迭代。這能直接幫助到研發與業務兩端：作為用戶方 / 業務方，可以更有效地判斷一個 Agent 是否滿足需求；作為開發者，也能在更高效的評測支持下，用更大的探索空間去嘗試新技術方案，并把最終效果做上去。

AI 重塑組織的浪潮已至，Agentic 企業時代正式開啟！當 AI 不再是單純的輔助工具，而是深度融入業務核心、驅動組織形態與運作邏輯全面革新的核心力量。

把握行業變革關鍵節點，12 月 19 日 - 20 日，AICon 全球人工智能開發與應用大會（北京站） 即將重磅啟幕！本屆大會精準錨定行業前沿，聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新，邀您共同深入探討：如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統，讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。