作者｜尹小明

編輯｜李忠良

策劃｜AICon 全球人工智能開發(fā)與應(yīng)用大會

在大模型技術(shù)飛速發(fā)展的當(dāng)下，大數(shù)據(jù)領(lǐng)域的各類應(yīng)用如雨后春筍般涌現(xiàn)，從數(shù)倉開發(fā)到 ChatBI 問數(shù)，再到深度分析 Agent，這些領(lǐng)域的大模型應(yīng)用極大地提升了數(shù)據(jù)處理和分析的效率。但與此同時(shí)，如何科學(xué)、準(zhǔn)確地評估這些應(yīng)用的效果，成為了行業(yè)面臨的重要難題。

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

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

詳細(xì)日程見：

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

以下是演講實(shí)錄（經(jīng) InfoQ 進(jìn)行不改變原意的編輯整理）。

為什么“評測也很酷”：

從用例到效果度量

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

挑戰(zhàn)主要體現(xiàn)在兩方面：一是如何更加貼切地評價(jià)我們所構(gòu)建應(yīng)用的實(shí)際效果；二是既有的傳統(tǒng)技術(shù)是否可復(fù)用，若不足，我們應(yīng)在何處開展探索與創(chuàng)新。那當(dāng)我們談“模型評測”時(shí)，究竟在說什么、常見的評測維度和指標(biāo)有哪些？

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

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

第三是穩(wěn)健性，或者說魯棒性。重點(diǎn)在于能不能容錯、持續(xù)穩(wěn)定地輸出，以及面對對抗或異常輸入時(shí)的抗攻擊能力。這些都直接關(guān)系到上線后的可用性與風(fēng)險(xiǎn)。

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

首先人工評測。在大模型生成帶有主觀性的內(nèi)容時(shí)，比如一次性生成幾千張創(chuàng)意圖片，哪個更好、哪個更差，通常要先請領(lǐng)域?qū)＜疫^一遍，并據(jù)此寫出清晰的評價(jià)標(biāo)準(zhǔn)——我們認(rèn)為什么是“好”，什么是“壞”；其次是自動化評測。

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

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

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

一方面當(dāng)下有很多評測 Benchmark，也有很多評測集。當(dāng)評測結(jié)束之后，大家常有一個痛點(diǎn)：你說現(xiàn)在效果很好，可為什么線上客戶老在吐槽，說“我的感覺沒有你說的分?jǐn)?shù)那么高”？這其實(shí)就是靜態(tài)評測和線上實(shí)際效果脫節(jié)的問題。

另一方面：今天很多評測往往針對模型的單一能力，或者若干常見的通用能力。這就像高考考數(shù)學(xué)、語文、英語；但這些科考完，放到自己的業(yè)務(wù)里會發(fā)現(xiàn)，成績好并不等于能力強(qiáng)�；氐綄�(shí)際業(yè)務(wù)場景，我該怎么綜合評估他的能力？

再者，即便有了一個評測集，業(yè)務(wù)在變，產(chǎn)品定義在變，線上用戶的使用方式也在變。這個時(shí)候，評測就更難反映線上的真實(shí)情況。

以上是通用框架，落到數(shù)據(jù)應(yīng)用 Agent，具體會碰到哪些垂直適配難點(diǎn)？

第一，領(lǐng)域特殊性。模型的代碼生成能力很強(qiáng)，但在早期訓(xùn)練語料里，SQL 的占比非常低。所以你會發(fā)現(xiàn)：它寫 Python 還不錯，寫 SQL 就明顯吃力。另外，在數(shù)據(jù)領(lǐng)域，數(shù)據(jù)“正確性”極其關(guān)鍵。

找資料、寫個想法，準(zhǔn)不準(zhǔn)影響也許不大；但一份數(shù)據(jù)分析報(bào)告，或者一個關(guān)鍵數(shù)值，最后要給到老板，如果這個數(shù)差之千里，后果就很嚴(yán)重了。

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

因此，對應(yīng)的評估維度也需要從單一能力，擴(kuò)展到能夠覆蓋這些復(fù)雜因素。

第三，“效率”與“并發(fā)”非常關(guān)鍵，這里的并發(fā)指研發(fā)并發(fā)，同時(shí)嘗試多種方案。這點(diǎn)尤其重要。為什么？因?yàn)樵谧瞿Ｐ蜁r(shí)，我們至今并沒有一套被驗(yàn)證為“最有效”的通用架構(gòu)；模型本身也在不斷迭代。

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

三層評測框架

前面說的是數(shù)據(jù)領(lǐng)域里可能會遇到的問題�；氐� Agent 這邊，我們提出了一個“三層評測”的體系設(shè)計(jì)。在構(gòu)建大模型的 Agent 應(yīng)用時(shí)，通常會同時(shí)面對幾層問題。

最下層是技術(shù)選型。市面上的模型很多，豆包、千問、文心、DeepSeek 等等。我的 Agent 關(guān)注哪些能力，哪些模型能達(dá)標(biāo)、值得進(jìn)入實(shí)驗(yàn)集？不能盲目把所有模型都往架構(gòu)里堆，并發(fā)和成本都承受不住。先做一輪有依據(jù)的篩選，這一步非常關(guān)鍵；

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

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

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

第一個層面是基礎(chǔ)能力評測，對應(yīng)我們前面說的技術(shù)選型階段。做這件事的目的，是先設(shè)定一個“準(zhǔn)入門檻”。以數(shù)據(jù)領(lǐng)域?yàn)槔�，我們會關(guān)注工具調(diào)用能力（Function Call、Tool using、MCP 等）、數(shù)值計(jì)算與表格理解、數(shù)據(jù)幻覺的控制、復(fù)雜指令遵循，以及編碼與 Text-to-SQL。各個方向基本都有可參考的開源 Benchmark。

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

第二個層面是組件（或子 Agent）的評測，面向的是 Agent 的各個組成部分�？梢园岩粋� Agent 的工作流程拆成幾個階段：先是召回，比如做 Schema Linking；然后是理解與規(guī)劃；接著進(jìn)入洞察、分析與執(zhí)行；最后是結(jié)果總結(jié)，把結(jié)論寫成報(bào)告。

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

第三個層面，是端到端效果評測。一方面，我們針對特定的業(yè)務(wù)場景構(gòu)建相應(yīng)的評測集；層級越往上，我們離業(yè)務(wù)越近，評測也就越貼近實(shí)際的業(yè)務(wù)場景和產(chǎn)品形態(tài)的定義。

我們相應(yīng)地構(gòu)建評測集和自動化評測方法；同時(shí)，在我們的評估平臺上設(shè)有“數(shù)據(jù)與飛輪”模塊對接業(yè)務(wù)，把線上的會話日志采集進(jìn)來，用于 Case Study、回歸評測集的沉淀，以及人工標(biāo)注。

Data Agent 評測技術(shù)創(chuàng)新和實(shí)踐

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

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

傳統(tǒng)的 Text-to-SQL（或 NL-to-SQL）評測方法與數(shù)據(jù)集（如 Spider、WikiSQL、BIRD-SQL 等）為通用場景提供了基礎(chǔ)衡量手段，但在面向大數(shù)據(jù)與真實(shí)業(yè)務(wù)約束的環(huán)境中，仍會遭遇諸多適配性與可擴(kuò)展性問題。

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

若此類情況高頻出現(xiàn)，模型的實(shí)際可用性仍然較強(qiáng)——在數(shù)據(jù)開發(fā)場景中，只需改動個別細(xì)節(jié)即可投入使用——而傳統(tǒng)方法無法反映這種“接近正確”的價(jià)值。

所謂“執(zhí)行正確性”，是指對每個問題—答案對提供標(biāo)準(zhǔn) SQL 與測試數(shù)據(jù)集，分別執(zhí)行標(biāo)準(zhǔn) SQL 與模型預(yù)測的 SQL，比較結(jié)果是否一致，以此判斷對錯。

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

這里放一個稍微復(fù)雜點(diǎn)的例子：我們的gold（ground truth）標(biāo)準(zhǔn)答案其實(shí)是一條很簡單的 SQL，問題是“文檔中哪些template_id被使用過”。但模型在預(yù)測時(shí)，去和另一張template表做了INNER JOIN，按id關(guān)聯(lián)。

肉眼一看就知道兩者不是一回事。按理說，放到設(shè)計(jì)更嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)集上，應(yīng)該能把差異測出來；可不幸的是，在 Spider 上兩條 SQL 的執(zhí)行結(jié)果一模一樣，最終造成了誤判。

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

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

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

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

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

第二個方法，我們把節(jié)點(diǎn)之間的引用關(guān)系建立起來：參考答案是一張圖，預(yù)測答案也是一張圖，然后訓(xùn)練一個圖匹配網(wǎng)絡(luò)（Graph-Matching Network，GMN）來計(jì)算兩條 SQL 在語法 / 表達(dá)上的相似度�；谡Z法樹的匹配這一路，我們稱為RelPM（在執(zhí)行層面的語法樹上做Partial Matching的局部匹配）：用規(guī)則做局部比對并賦權(quán)，得到 0～1 的相似度分?jǐn)?shù)，已經(jīng)明顯優(yōu)于傳統(tǒng)做法。

進(jìn)一步，在FuncEvalGMN上，無論對比基于執(zhí)行正確性的評測、基于文本 / 語義相似度的評測，還是一些基于 BERT 的預(yù)訓(xùn)練模型，我們的效果都有顯著提升。在業(yè)務(wù)側(cè)，這套方法也已經(jīng)成為我們數(shù)據(jù)領(lǐng)域的核心算法之一。

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

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

用什么維度來衡量一份深度分析報(bào)告“好不好”，以及如何把這些維度做成可執(zhí)行的自動化評測，都是實(shí)打?qū)嵉奶魬?zhàn)。

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

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

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

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

在實(shí)現(xiàn)上，我們用到一些基本技術(shù)。其一是自我反思：模型先按評分標(biāo)準(zhǔn)完成一次打分，再進(jìn)入反思環(huán)節(jié)，檢查自己是否完整遵循了打分邏輯、是否有遺漏。其二是多 Agent 協(xié)作架構(gòu)。

我們把評估對象（報(bào)告）、評估過程、問題及相關(guān)上下文作為整體輸入，送入一個用于應(yīng)用評估的系統(tǒng)（我們稱為 Critic Agents）。該系統(tǒng)首先按我們的評分標(biāo)準(zhǔn)與細(xì)則完成初評分，然后交給 Reflect（自我反思）模塊，復(fù)查本次打分是否存在遺漏或不當(dāng)之處。

再舉一個我們踩過的坑：寫報(bào)告時(shí)很容易在單位轉(zhuǎn)換上出錯。原始計(jì)算得到的是一個數(shù)，寫進(jìn)報(bào)告卻被表述成“XX 萬”。這既是 Data Agent 的高發(fā)錯誤點(diǎn)，也是評估里容易被誤判的點(diǎn)。

針對這類問題，我們會把相關(guān)環(huán)節(jié)交給Reflect的反思流程復(fù)查；同時(shí)引入多個 Agent，從不同角度、甚至基于不同的底層模型分別打分，最后由“裁判長”統(tǒng)一審閱整條打分鏈路及其與標(biāo)準(zhǔn)答案的對齊情況。

整體架構(gòu)上，我們還會結(jié)合ReAct，讓評測側(cè)“自己寫代碼”把關(guān)鍵數(shù)據(jù)復(fù)算一遍，核對計(jì)算是否正確。遇到特定場景（比如歸因分析），要完成有效評估還需要專業(yè)的領(lǐng)域計(jì)算工具；這些工具同樣交由評判方調(diào)用，才能對該類任務(wù)給出評價(jià)結(jié)果。

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

這是第一個案例：我們用自動化評測在報(bào)告里定位到數(shù)據(jù)錯誤。上面的片段是一個典型的歸因場景。機(jī)評發(fā)現(xiàn)，報(bào)告寫到“德芙巧克力單筆銷售額 1.5 萬”等數(shù)字沒有真實(shí)來源�；厮葸^程可以看到，右側(cè)的 SQL 少寫了一個GROUP BY 商品名。

在這種寫法下，只能查出一系列明細(xì)訂單，不可能直接得到“德芙巧克力 1.5 萬”這樣的聚合結(jié)論。原始明細(xì)里雖然出現(xiàn)過“1.5 萬”這個數(shù)，但無法據(jù)此推斷它對應(yīng)“德芙巧克力”。這一問題被機(jī)評準(zhǔn)確抓出。

在人評場景中，讀過類似報(bào)告的同學(xué)會有同感：像 OpenAI 的 Deep Research 那樣的長報(bào)告，要把其中每個數(shù)字都核驗(yàn)一遍，幾乎不現(xiàn)實(shí)；人評非常容易漏錯。相比之下，機(jī)評在這類細(xì)粒度、很復(fù)雜的校驗(yàn)上更有優(yōu)勢。

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

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

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

評估平臺的工具與鏈路建設(shè)

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

另外平臺同時(shí)引入“數(shù)據(jù)飛輪”，將線上新增案例持續(xù)沉淀為評測集，確保評測隨業(yè)務(wù)與使用方式演化而更新；在基礎(chǔ)選型環(huán)節(jié)，提供 Benchmark 與榜單模塊，便于業(yè)務(wù)側(cè)進(jìn)行判斷與選擇。

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

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

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

未來展望

面向未來，自動化評測在數(shù)據(jù)領(lǐng)域可能的重點(diǎn)投入方向如下：

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

可以通過有效采樣、時(shí)效性校驗(yàn)等手段，持續(xù)衡量線下評測數(shù)據(jù)集是否過時(shí)，讓評測結(jié)果真正對應(yīng)用戶的實(shí)際體感。

其次，在應(yīng)用改進(jìn)方面，以前常講 TDD（Test-Driven Development）。在大模型時(shí)代，我更主張“評估驅(qū)動開發(fā)”（EDD）。它需要把評估更好地分解到 Agent 架構(gòu)的各個環(huán)節(jié)：細(xì)化到子模塊的能力、推理的不同階段，并把最終業(yè)務(wù)指標(biāo)與過程性指標(biāo)建立起更有效的關(guān)聯(lián)。

模型訓(xùn)練層面，無論是精調(diào)（SFT）還是強(qiáng)化學(xué)習(xí)，歸根到底都是與預(yù)期業(yè)務(wù)效果和人類判斷對齊，這與評測天然相關(guān)。我們也在探索用自動化評測去反向驅(qū)動訓(xùn)練流程。

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

AI 重塑組織的浪潮已至，Agentic 企業(yè)時(shí)代正式開啟！當(dāng) AI 不再是單純的輔助工具，而是深度融入業(yè)務(wù)核心、驅(qū)動組織形態(tài)與運(yùn)作邏輯全面革新的核心力量。

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

今日薦文

你也「在看」嗎？