为什么需要测评#

由于llm的不确定性，导致每一次任务的过程、结果也是不确定的。当我们修改prompt、修改工具、修改模块，都无法直接得出修改的好与坏。所以需要通过测评来处理。

有测评后，每次改动都可以被量化，测评中的失败案例可以加入评估集。没有测评，每次改动都是碰运气。

如何测评#

Anthropic在2026年初发布的一篇技术博客《Demystifying evals for AI agents》中提出了将评分器分为基于代码、基于模型和人工 这三类的框架。

基于代码的评分器：字符串匹配、单元测试、静态分析。优点是快、便宜、客观、可复现；缺点是脆弱，对有效变体不够宽容，缺乏细微判断能力。
基于模型的评分器：用LLM 做评委，基于评分标准打分、自然语言断言、成对比较等。优点是灵活、能处理开放式任务；缺点是非确定性、比代码贵、需要和人工校准。
人工评分器：领域专家评审、众包判断、抽样检查。黄金标准，但贵、慢、难以规模化。

了解：基于代码的评分器是将agent系统整个过程中可被程序化读取的内容，读取后进行评分，通过传统的字符串匹配、编写测试脚本等方式对输出内容进行测试。

四类测评方式#

离线测评：#

通过日志、用户反馈获收集评估集评分方式：三类，上面提到的基于代码脚本（成本最低）、基于模型的评分器（最灵活）、人工（代价最高）频率：每次改动prompt；以及每周自动化脚本运行评估集评估效果：和历史baselin对比、失败案例集、分类case的分数

红蓝对抗#

设计三类agent

red team agent：专门设计来攻击：提示词恶意注入、越狱、诱导、混淆
blue team agent：当前agent系统
judge：裁判，用来评价攻防结果

通过红蓝对抗，可获得红队胜率、攻破案例集频率：每月进行

回归集#

每次修复的bug都要把case加入回归集，保证同一个bug不出现两次

频率：每次发布前，每次大的改动前都要跑

在线测评#

抽样 + LLM judge:每天从生产日志抽 1-5%，用 judge 模型评分用户反馈信号:点赞/点踩、纠错按钮、放弃率、对话轮次 A/B 实验:新 prompt/新模型上线先 1-10% 流量，对比指标滚动 baseline:每周生成质量趋势图

AB test

1
┌─────────────┐
2
│  1. 提出假设 │  "新Prompt能让Agent任务完成率提升10%"
3
└──────┬──────┘
4
       ▼
5
┌─────────────┐
6
│  2. 创建变体 │  A组：旧Prompt（对照组）  B组：新Prompt（实验组）
7
└──────┬──────┘
8
       ▼
9
┌─────────────┐
10
│  3. 随机分流 │  用户ID哈希 → 50%进A组，50%进B组（互斥且均匀）
11
└──────┬──────┘
12
       ▼
13
┌─────────────┐
14
│  4. 采集数据 │  运行1~2周，收集两组的关键指标（完成率、耗时、满意度）
15
└──────┬──────┘
16
       ▼
17
┌─────────────┐
18
│  5. 统计分析 │  用t检验或卡方检验，看差异是否显著（p < 0.05）
19
└─────────────┘

agent测评学习笔记