![](https://developer.qcloudimg.com/http-save/yehe-6490225/dc6868dc674aaefca4dbf962e95a319a.png)


## 写在开头

2026 年，国内外AI大模型已经「卷」到了一个新高度。

GPT、Claude、Gemini、GLM、DeepSeek、KIMI、Qwen……各家厂商每隔一两个月就发布新模型，声称在各项基准测试上「刷新纪录」。

几乎所有做 AI 应用的团队都在面对同一个问题——模型越来越强，但产品越来越难评。

你可能会问：

>**这些评测结果真的可信吗？它们能反映模型在业务场景中的真实表现吗？**


先说一个我观察到的现象。

过去做 LLM 评测，准备好数据集，跑一轮，对对答案，出个分数，完事。现在做 Agent 评测，把 LLM 那套评测方法，原封不动搬到了 Agent 上——准备一批 `(输入, 标准答案)`，让 Agent 逐条作答，比对，打分。数字很好看，上线照样翻车。

**不是他们不努力，是"思维框架"用错了。**

框架错了，后面越用力，偏得越远。

所以这篇文章，我想简单聊一聊，AI 评测的一些方法、思考、常见陷阱和最佳实践，帮助你在建立科学的 AI 评测体系提供一些思路。（当然，更系统完整AI测评体系学习，请移步到「AI 进化社」）

---

## 一、先说说，为什么 AI 评测如此重要？

这问题听起来很虚，但它其实是最该先想清楚的。

打个比方。你去菜市场买鱼，十个摊位全在喊"我家的最新鲜"。

你信谁？

你不能靠听吆喝做决定。你得自己走过去——翻翻鱼鳃红不红、按一下鱼肉弹不弹回、凑近闻一闻。

**评测，就是你亲手去验那条鱼的动作。**

厂商的发布会、PR 稿、各种榜单——都是吆喝。只有你自己的评测，才是你亲手按的那一下。

想象一下：你现在负责为公司即将要开发的一款智能客服系统选择一个大模型。面前有 10 个候选模型，每个都声称自己「最强大」。

**没有评测，你只能靠厂商的营销话术做决策。**

**有了评测，你才能用数据说话。**

那评测到底帮你干什么？说白了就三件事。

**第一，帮你选对。**

你公司要上一套 AI 客服，面前七八个模型。光看通用排行榜？没意义。你得把自家真实的业务问题喂进去跑一遍，才知道谁行谁不行。

通用榜单第一名的模型，到了你的垂直场景里，被排第五的甩开十几条街——**这种事我见过太多了。**

**第二，帮你盯住。**

模型上线不是终点，是起点。

版本悄悄更新了、用户问题分布变了、数据慢慢漂移了——随便哪个变量，都能让昨天还稳稳当当的系统，今天就开始抽风。

没有持续评测，这些问题你根本看不到。等用户骂过来了，已经晚了。

**第三，帮你兜底。**

AI 会幻觉，会一本正经地胡说八道，会被几句 prompt 绕进去。真到了医疗、法律、金融这些场景里，说错一句话就是事故。

评测就是你上线前的"压力测试"。**把可能翻车的点，提前在内部试出来，别让用户替你踩雷。**

最后说一个我反复看到的坑：**太多人追"最强"，而不是"最合适"。**

有个团队，追着当时评分最高的模型用，结果那模型虽然"聪明"，但输出特别啰嗦，放到他们产品里用户体验很差。后来换了个排名低两名、但回答更精炼的模型，用户满意度反而冲上去了。

**合不合适，只有你自己测了才算数。别人嚼过的榜单，喂不饱你的业务。**

靠看几个 Case 来判断质量，不够——你永远不知道自己没看到的地方发生了什么。

评测要做的事，就是在这个概率系统上建一套闭环机制，让你对系统的每次修改，都有迹可循、有据可查。

---

## 二、搞清楚：Agent 比单轮模型多了什么

要谈评测，得先看清评测对象的不同。

目前测评对象主要分为：
- 对大模型本身测评
- 对Agent智能体产品测评（或者可以理解为测产品）

**单轮 LLM 的工作方式，是"给一句、答一句"。** 你给它一个 prompt，它吐出一段文本，结束。它不主动做下一步，不碰外部世界，也不会因为上一句答错了而回头修正。

这种"输入进、输出出"的交互，干净、静态、一次性。所以评测范式也特别清爽：

```
准备数据集 → 模型逐条作答 → 和标准答案比对 → 出分数
```

整个过程的特征是：**静态的**（数据集固定不变）、**确定性导向的**（同一输入期望同一输出）、**单点的**（看最终那段文本就够了）。

**而 Agent 的工作方式，是"在一个循环里自主行动"。**

给它一个目标，它会自己规划、调用工具、观察结果、判断距离目标还有多远，然后决定下一步——一轮一轮转下去，直到它认为任务完成。

在这个循环里，Agent 比单轮模型多出了四样东西，**每一样都会直接戳破老评测范式**：

| 多了什么 | 为什么戳破老范式 |
| --- | --- |
| **会用工具、动外部世界** | 它的行为有后果（改文件、调 API、写数据库），不只是产生文本 |
| **会走很多步** | 一次任务有一长串决策和中间状态，不是一个孤立回答 |
| **会出错并尝试自恢复** | 一次工具调用失败，它可能重试、换路子，这条"弯路"本身就是评测要看的东西 |
| **高度不确定** | 同样的任务跑两次，路径和结果可能完全不一样 |

把这两种工作方式摆在一起，评测要变的地方就浮出水面了。


## 三、从 LLM 评测到 Agent 评测：几点变化

前面铺垫够了，开始进入重点。

LLM 评测和 Agent 评测，到底差在哪？我总结了四个变化。**前三个你可能猜得到，第四个才是真正的根。**

### 变化一：光看"说了什么"不够，还得看"做了什么"

传统大模型评测，盯的是模型最后吐出来的那段话。把它和标准答案做比对，像就给分。

但 Agent 不一样——**它会动手。**

假设你让 Agent 处理一个退款。它跑完，告诉你：

> "订单已退款，确认邮件已发。"

你拿这句话去跟标准答案比对——很像，打满分。

**但钱真退了吗？邮件真发了吗？**

这就是 LLM 评测和 Agent 评测最本质的分水岭：

> **嘴上说的，叫 output。世界里真正发生的变化，叫 outcome。**

一个 Agent 可以特别真诚地跟你说"搞定了"，然后什么都没干。你信了，上线了，事故就埋下了。

光看 outcome 也不够。

假设钱确实退了。但你翻开它干活的完整记录，发现它压根没查订单状态，上来直接调了退款接口——碰巧这单能退，蒙对了。

**这次它走运。下次遇到一单不能退的，它照样直接退——那就是事故。**

所以你得看两样东西：**最终结果对不对，以及它走的路合不合理。**



### 变化二：静态数据集不够用了，得搭"交互式环境"

传统大模型评测，数据是一张固定的表：一列问题、一列答案。模型逐行答，逐行对。数据本身从头到尾不变。

Agent 没法这么测。

因为 Agent 要干活。它要查订单、调接口、改数据库——这些动作需要背后有真东西响应它。一张静态的表，给不了这种交互。

**所以 Agent 评测不是在准备数据，而是在搭环境。**

你得用沙箱、模拟服务、Docker 容器，搭一个能真实操作的"实景考场"。Agent 在里面真实地跑，跑完之后你去检查考场状态——订单状态变了没？接口参数对不对？邮件发出去了吗？

这比写几行 eval 脚本复杂太多了。而且每个 case 跑完，你得把环境**恢复原样**，不然下一个 case 的结果就被污染了。

| | LLM 评测 | Agent 评测 |
|---|---|---|
| 你在准备什么 | 数据 | **环境** |
| 复杂度 | 低 | 高（沙箱、模拟、状态管理） |
| 每次跑完 | 不用管 | **必须复位** |
| 和生产像不像 | 不要求 | **必须尽量对齐** |

**下次有人说"我的 Agent 评测搭好了"，你就问一句：你的环境能交互、能复位吗？** 答不上来的，大概率还停在拿静态数据测动态系统的阶段。

### 变化三：跑一次不算数，得看概率

这个变化最容易被技术人忽略，也最容易坑人。

传统大模型评测默认：同一个输入，模型表现稳定，跑一次或几次就够了。

**Agent 不吃这一套。**

同一个任务，今天跑成功，明天可能失败。这次三步到位，下次绕了十步还出错。原因不复杂——模型采样有随机性，工具返回有波动，多步决策中的误差会一层层放大。

来看个现实场景：

你的 Agent 成功率 70%。你跑了一次，过了，于是上线。

但 70% 的意思是——**你这次"通过"有三成是纯运气。** 你用一次抽签的结果，给一个概率系统盖了章。

更坑的是版本对比。你改了一版，成功率从 70% "提升到" 75%，于是宣布进步了。可如果这两个数字都只是跑了一轮、几十条 case——**这 5 个点的差距，完全可能落在噪声范围里。**

所以 Agent 评测要求你换个看法：不再盯"一个点"，而是看"一条分布"。

同一个任务**多跑几遍**（至少 5-10 次），看通过率。比较两个版本时，先问"差异够不够大"，而不是急着看谁数字高。

**一次叫运气，十次才叫规律。**

### 变化四：从"评模型"到"评系统"

最后这个变化，是前三个的根。

以前评测对象很明确——就是模型本身。换个模型，分数变了，锅和功劳都算模型的。

但 Agent 的成绩，从来不是模型一个人决定的。

它能用什么工具、工具描述写得清不清楚、上下文怎么管理、循环逻辑怎么设计、出错怎么办——**这层包在模型外面的系统，叫 harness。**

![](https://developer.qcloudimg.com/http-save/yehe-6490225/62414ed816c89f9ddf1f482a83143cba.png)



> **同一个模型，换两套 harness，分数能差出几十个百分点。**

这意味着你跑出来的每个分数，都是"模型 + Harness"打包在一起的结果。**不是单独评发动机，是评整辆车。发动机再好，底盘散架了也跑不快。**

所以评测报告必须写清楚用的是哪套 Harness。不写这个，数字既不能复现，也不能比较。这一点在实操中被忽略了太多次。

---

## 四、AI 评测的演进：从一把尺子到一整张体检表

AI 评测不是一开始就这么复杂的。它也经历了几轮"进化"。

### 第一轮：单一指标、一把尺子量天下

2020 年前后，AI 评测非常「粗暴」，大家评模型就盯一个数字，用一个数字概括模型能力。

搞翻译的看 BLEU 分，做分类的看 F1，搞语言模型的看 Perplexity。一个数字高，就牛。

- **BLEU 分数**：机器翻译的「金标准」
 
- **F1 分数**：分类任务的常用指标
 
- **Perplexity**：语言模型的困惑度

简单粗暴，但有个致命问题：**分数高，不等于真正好用。**

比如：一个翻译模型可能 BLEU 分数很高，但翻译出来的句子逻辑不通、语义错误。人类一看就知道「这翻译有问题」，但 BLEU 分数却说「很好」。

**测的是"像不像"，不是"对不对"。**

说白了，这些指标只能衡量「表面相似度」，无法反映模型的「真实理解能力」。


### 第二轮：基准测试、刷榜时代

随着2022 年，大模型的崛起，评测进入了「基准测试」时代。

或者说进入到了"标准化考试"时代——MMLU、HumanEval、GSM8K，一堆 benchmark 轮番上。所有模型做同一套卷子，标准化、可复现、多维度，看起来科学多了。

常见的有：
- **MMLU**：57 个学科的选择题
 
- **HumanEval**：164 个 Python 编程题
 
- **GSM8K**：小学数学应用题
 
- **HellaSwag**：常识推理

但问题也跟着来了。

**第一个坑：数据污染。**

模型训练的时候可能已经"见过"这些题。你以为在考试，人家在开卷。某模型 MMLU 考了 90 分，后来发现训练集里混进了大量类似题目——去掉污染数据，真实水平只有 78。

**第二个坑：刷分不等于能干。**

模型可以专门针对 benchmark 优化，分数刷得飞起，但泛化能力稀碎。某模型 HumanEval 得分 95%，放到真实工程任务里，成功率只有 40%。

**考场里的学霸，工位上的废物。**

**第三个坑：脱离你的场景。**

通用 benchmark 测的是"通识"能力。但你的业务不需要模型什么都会——你需要它在特定场景下解决问题。通用榜上排第一的模型，到了你的垂类场景里，可能啥也不是。

### 第三轮：多维、多模态、多场景

2024 年之后，大家终于想明白了——一个数字概括不了模型的真实水平，就跟一个体检指标概括不了你的健康状况一样。

于是评测开始"多元化"：不只测文本，还要看图像和视频理解；不只发静态卷子，还搞实时对战（比如 Chatbot Arena 的盲投 Elo 排名）；不只看通用能力，还看垂直行业够不够专。

一条线串起来就是：

> **从"一把尺子"，到"一套标准化试卷"，再到"一整张体检表"。**

越往后，评测越贴近真实世界里的表现。但也越复杂、越难做。


---

## 五、主流评测方法：到底该用哪种？

聊完了评测的演进，接下来的问题更实际：**手上有哪些方法可以用？**

评测方法说到底，就三条路。我按"从便宜到贵"的顺序给你捋。

### 方法一：基准测试——发卷子，对答案

在标准化的数据集上测试模型，输出可量化的指标（如准确率、F1 分数）。

**知识理解类**
- MMLU：57 个学科的选择题（物理、历史、法律等）
- ARC-Challenge：小学科学推理题
- TruthfulQA：测试模型是否会生成虚假信息

**编程能力类**
- HumanEval：164 个 Python 编程题，
- MBPP：974 个基础 Python 编程题
- SWE-bench：真实的 GitHub Issue 修复任务

**数学推理类**
- GSM8K：小学数学应用题
- MATH：高中和竞赛数学题

简单来说，你准备一套标准题，让模型答，算分数。就这么简单。MMLU 考知识面，HumanEval 考写代码，GSM8K 考数学——每套卷子测一种能力。

好处明摆着：快、便宜、可复现。十个模型一起做同一套卷子，排名一目了然。

但它只能判"对不对"，判不了"好不好"。而且前面说过——题目可能泄露，模型可能刷分。

**一把快刀，但不是万能刀。**


>我的建议：
>**选择与你业务相关的基准**，比如你的场景是客服，重点看对话类基准；如果是编程助手，重点看代码类基准。另外要**关注多个基准，而非单一分数**

### 方法二：人工评测——人来看，人来判

由人类评估者对模型输出进行主观评分。

最原始，也最靠谱。

找一群人（最好是懂行的），把模型的输出摆出来，让他们打分，或者拿两个模型的回答做对比、选更好的那个。

人工评测方法细分下来，也有好几种，比如：
- **绝对评分**：评估者对每个输出独立打分（如 1-5 分）。
- **相对排序：** 评估者对比两个模型的输出，选择更好的那个。
- **A/B 测试**：在真实场景中，将用户随机分配到不同模型，收集用户反馈。

人工评测能捕捉到机器判不出来的东西——语气到不到位、有没有温度、是不是真解决了用户问题。这些"软质量"维度，代码和 LLM 都很难判准。

缺点也直白：**贵、慢、主观。**

不同人标准不一样，同一个人今天和明天的判断也可能不一样。

所以人工评测通常不拿来跑量，而是拿来**定标尺**——先人工评一小批，拿到一组"金标准"结果，给后面其他方法当参照物。

> 我的建议：
> **制定清晰的评分指南**：明确每个评分维度的定义和示例。对参与的**评估者**进行培训，确保评估者理解评分标准。另外，还可以**结合自动化指标**，将人工评测与自动化指标结合，降低成本。

### 方法三：LLM-as-Judge——用大模型评测大模型

让AI来当评委，使用一个更强大的大模型（如 GPT-5.6）作为「评委」，对其他模型的输出进行评分。

 这是最近两年最火的玩法。

思路很直白：你既然有大模型，那就让大模型来当评委呗。写一段 prompt，告诉它"请从准确性、完整性、语气这几个维度给以下回答打 1-10 分"，可以单点评分，也可以对比评分。

规模化、便宜、还快。一次跑几百条，成本也就几块钱。

**但评委自己也有偏见。**

比如它偏好长回答——觉得越长越用心；偏好自己风格的回答——"自我偏好"是 LLM 评测里出了名的问题；偏好格式整齐的，哪怕内容一般。

而且评委模型的能力就是天花板。**评委不够聪明的时候，好的回答它也认不出来。**

实操上，靠谱的做法通常是：

> 先用人工评一小批，拿到基准线 → 然后用 LLM-as-Judge 跑大量，快速规模化 → 关键 case 再回到人工复核。

**三种方法不是三选一，而是一套组合拳。**

最后提一嘴**多模态评测**。如果你的应用涉及图像、视频理解，光测文本就不够了。你需要 VQA（视觉问答）之类的专项测试。这块目前还缺统一标准，比较前沿，这里就不展开，知道有这回事就行。

## 写在最后

没有评测体系的 AI 产品迭代是什么状态？

**更新不知道变好还是变坏，出了问题永远要等用户投诉，复现之后才能修掉，然后祈祷没有引入新的问题。**

大模型和传统软件有一个根本不同：传统软件是确定性的，同样的输入永远给同样的输出。大模型不是——每次输出都不一样，你改任何一个地方，影响都是发散的。

**评测要做的事，就是在这个概率系统上建一套闭环机制，让你对系统的每次修改，都有迹可循、有据可查。**

而 Agent 评测更进一步——它要求你从"对答案"升级到"验过程+验结果"，从"静态数据"升级到"交互环境"，从"跑一次"升级到"看分布"，从"评模型"升级到"评系统"。

**范式变了，工具没变，但你看待问题的方式变了。**

这，也是从 LLM 评测到 Agent 评测的核心转变。

GPT、Claude、Gemini、GLM、DeepSeek、KIMI、Qwen……各家厂商每隔一两个月就发布新模型，声称在各项基准测试上「刷新纪录」。

从 LLM 评测到 AI Agent 评测，我的一些思考！

人工智能

测试

职业发展

2026年AI大模型竞争白热化，但评测体系面临重大挑战。本文深度剖析AI评测四大关键变化：从结果验证到过程追踪、静态数据到交互环境、单次测试到概率评估、模型测评到系统评估。针对智能体产品评测，提出必须搭建真实交互环境、关注执行过程合理性、进行多轮概率测试等核心方法论，帮助企业在模型选型、效果监控和风险防控中建立科学评测体系。

压力测试

代码解释

机器翻译

视频理解

A/B测试

数据库

智能体

DeepSeek

Python

容器

Agent

2026上云采购 | AI焕新·智启新局

cscbot

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2026年AI大模型竞争白热化，但评测体系面临重大挑战。本文深度剖析AI评测四大关键变化：从结果验证到过程追踪、静态数据到交互环境、单次测试到概率评估、模型测评到系统评估。针对智能体产品评测，提出必须搭建真实交互环境、关注执行过程合理性、进行多轮概率测试等核心方法论，帮助企业在模型选型、效果监控和风险防控中建立科学评测...

从 LLM 评测到 AI Agent 评测，我的一些思考！-腾讯云开发者社区-腾讯云

从 LLM 评测到 AI Agent 评测，我的一些思考！

从 LLM 评测到 AI Agent 评测，我的一些思考！

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐