文章目录
- 1. 先别急着问跑得怎么样，这个问题本身就是个坑
- 2. 评估体系的两层结构：先分清"怎么评"和"评什么"
-
- 2.1 评估器（Evaluator）：考卷和评分标准
- 2.2 评估任务（Evaluation Task）：组织一场考试
- 2.3 评估器类型：找代码还是找"人"
- 3. 黄金指标：先回答"什么算好"
- 4. Rubric：把"凭感觉"变成"可复现"
- 5. 创建评估器：把 Rubric 装进 Prompt
-
- 5.1 评估器的三个输入变量
- 5.2 输出定义：结构化字段
- 6. 创建评估任务：评什么、怎么跑、评多少、字段怎么对
-
- 6.1 轨迹数据 vs Trace 数据
- 6.2 两种运行策略
- 6.3 采样配置：省钱是硬道理
- 6.4 字段映射：把数据接到变量上
- 7. 评估结果与 badcase 闭环
-
- 7.1 多次评估看均值
- 7.2 badcase 进库，实验才有弹药
- 8. 一句话总结
P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看，传送门https://blog.csdn.net/qq_74013365
1. 先别急着问跑得怎么样，这个问题本身就是个坑
数据接入搞定了，下一个问题跟着就来了：Agent 跑得怎么样？
这个问题看似简单，实际上它跟"你觉得我今天这身打扮怎么样"属于同一级别的灵魂拷问。你女朋友这么问你，你答"还行"会被打死；Agent 这么被问，它能给你答出一千种"还行"来，你还挑不出毛病。
为什么难？因为 Agent 的输出是开放式的。同一个问题，它今天回你两个字"好的"，明天给你来一篇两千字小作文。你都不知道该夸它进步了，还是该骂它话痨了。
人工抽检？又贵又慢。找三个人看一千条对话，看完仨人当场吵起来：一个说这条答得不错，一个说它连用户叫什么都记错了，第三个说要不咱们仨还是转行吧。
所以这事儿的正确答案只有一个：建立一套可量化、可解释、可复用的评估体系。把"好不好"变成一组带权重的分数，把"为什么不好"变成能追溯的证据。
今天就用一个客服 Agent 当例子，把"黄金指标 → Rubric → 评估器 → 评估任务 → 结果分析"这条线完整走一遍。
2. 评估体系的两层结构：先分清"怎么评"和"评什么"
评估体系拆成两层，这个拆分值得先讲清楚，不然后面所有配置你都得反复回来翻定义。
2.1 评估器（Evaluator）：考卷和评分标准
评估器先定义清楚评估指标是什么。比如"任务完成度"，这就是一个指标。评估器里装着它的类型、输出定义、评判标准（Rubric）——它是"怎么评"的定义，跟具体数据无关，可以复用。
注意"可以复用"这四个字。意味着你写一次评估器，能拿它评一万条数据，评完这波还能评下一波。比你的健身卡值多了，健身卡你办了三年就去过两次。
2.2 评估任务（Evaluation Task）：组织一场考试
有了评估器，再创建评估任务：指定用哪些评估器、对哪些指标做评估。它是"评什么数据、何时评"的执行配置。
打个比方：评估器是考卷和评分标准，评估任务是组织一场考试。同一套考卷能考不同学生（数据），同一批学生也能考好几套卷子（多个评估器）。
这套逻辑你上学的时候早就体验过了——那种一个下午连考三门的魔鬼排期，本质就是"评估任务"给你安排得明明白白。
2.3 评估器类型：找代码还是找"人"
评估器有个关键属性——类型：到底是基于 Agent 的方式去评估，还是基于 Code 去评估。
Code 评估：用代码规则打分。确定、便宜，但只能覆盖能用规则表达的指标，比如格式、长度、字段完整性。就像自动判卷机，它只会检查"答案里有没有出现’谢谢’两个字"，至于你谢得诚不诚恳，它管不着。
Agent 评估：让一个专门的评估 Agent 像人一样阅读输入、输出和运行轨迹，按 Rubric 判断打分。它能理解语义，覆盖"回答是否切题""流程是否合理"这种规则写不出来的指标。
代价嘛，就是贵。所以后面那个"采样配置"的存在，就是给钱包留的一口气。
3. 黄金指标：先回答"什么算好"
评估的第一步不是写代码，而是回答一个哲学问题：这个场景下，什么算"好"？
客服 Agent 场景下，黄金指标分两类：回答质量（最终答案对不对、好不好）和执行过程（工具调用是否合理、路径是否绕远）。
为什么两个都要看？只看结果会漏掉"蒙对的"——它运气好撞上了正确答案，但你敢放它上线吗？只看过程会漏掉"做对了但答非所问的"——它流程走得贼标准，就是没回答用户的问题。就像你打游戏，全程操作拉满，最后水晶被偷了，你到底是高手还是菜鸡？
这时候有人要问了：这黄金指标得从零手写吧？不用。可以让 AI 基于业务场景帮忙制定并拆解，把需求写成一段 Prompt 输进去就行。
Prompt 的核心诉求就一句话：请制定黄金指标，用来评判客服 Agent 的回答质量和执行过程，并对黄金指标进行拆解，定义成 Rubric——每个指标在什么情况下打什么分数，每个指标有权重，最终汇总成一个加权分数。
AI 的输出相当完整：覆盖"回答结果质量"与"执行过程质量"两大类指标，每个指标给出分档规则、权重、总分公式，还贴心地补充了"加权诊断分 + 硬门禁 + 证据覆盖率"这种实操建议。
那一刻你会突然意识到，自己作为"人"的贡献，就只剩下复制粘贴了。
4. Rubric：把"凭感觉"变成"可复现"
这里的关键概念是 Rubric：把抽象的"好"拆成一条条可判定的评分细则——每个指标在什么情况下打什么分数，每个指标占多少权重，最终汇总成一个加权分数。
有了 Rubric，评估才从"凭感觉"变成"可复现"。以后再有人跟你说"我觉得这个 Agent 不行"，你可以淡定地回他一句：“请给出带权重的分档证据，谢谢。”
两条补充经验：第一，如果你对业务足够熟悉，也可以人工制定，AI 只是提效手段，不是必需品；第二，如果特别关注某个指标（比如客服场景里的"是否泄露用户隐私"），可以把它提出来作为顶层评估器单独评估，别让它淹没在总分里。
翻译一下就是：总分是给人看的，单独拎出来是给法务看的。
5. 创建评估器：把 Rubric 装进 Prompt
有了 Rubric，下一步是把它装进评估器——载体就是评估器的 Prompt。评分规则写在 Prompt 输入区里，跟 input、output、执行轨迹三个参考变量一起，构成评估器定义的一部分。
评估时，评估 Agent 阅读被评数据的 input、output 和轨迹，再对照 Prompt 里的 Rubric 逐项检查、按档给分。Rubric 写得越具体，打分就越稳定、越可解释。
这就像餐厅菜单：只写"特色菜"三个字的店，你永远不知道端上来的是啥；写清楚"宫保鸡丁，微辣，花生米要脆"的，至少不会给你端出鱼香肉丝。
创建时还可以做减法：模板里的通用项用不到就删掉，只保留真正需要的部分。评估器是长期复用的资产，初始配置越干净，后面维护越省心。这跟搬家一个道理，搬进去那天不扔的杂物，三年后一定还在那儿。
5.1 评估器的三个输入变量
评估器的输入变量有三个，恰好对应评估一次运行所需的三类信息：
input：用户输入——用户问了什么；
output：Agent 的输出——Agent 答了什么；
运行轨迹：即 trace.agent——Agent 是怎么一步步得出这个答案的。
有了这三个变量，评估器既能评结果（input 对 output），也能评过程（轨迹）。这就像查员工 KPI，不能只看他交了什么东西，还得看他上班八小时到底是真在干活，还是在工位上给绿植浇水。
5.2 输出定义：结构化字段
输出定义是一组结构化字段，评估器每次评估都必须按这个 Schema 输出。核心字段大概长这样：
{
"score": 0,
"explanation": "",
"raw_weighted_score": 0,
"final_score": 0,
"decision": "",
"scenario_type": "",
"summary": ""
}
逐个解释一下：
score：单项得分；
raw_weighted_score：float 类型，取值范围 0~1。评估器的判断逻辑是先把加权分数算出来，再转成 0~1 之间的数值；
final_score：0~1，最终归一化的总分；
decision、scenario_type：结论判定与场景分类，方便下游按结论过滤——比如直接捞出所有 decision 为失败的条目；
summary、explanation：结论摘要与解释。分数必须可解释，否则低分时你不知道该改什么；
rubric_version：Rubric 版本号。Rubric 会迭代，留版本号才能区分"分数变化是 Agent 变了还是标准变了"。
解释这个字段有多重要？给你个场景：你收到一个孤零零的 0.4 分，对着屏幕发呆半小时，不知道该改哪里。但如果旁边写着"第二步工具调用失败，返回 404"，你至少知道该去骂谁。
如果有业务领域的 Skill（比如客服领域知识），还可以把它挂到评估器上——相当于给阅卷老师发了一份领域手册，别让它拿通用常识去批专业卷。
6. 创建评估任务：评什么、怎么跑、评多少、字段怎么对
评估器就绪，接下来创建评估任务，把"考卷"发到"学生"的数据上。这一步有四个配置点。
6.1 轨迹数据 vs Trace 数据
平台里有两类数据，选哪类直接影响评估视角。
Trace 数据：关注微服务的调用过程——哪个服务调了哪个服务、耗时多少，是基础设施视角。
轨迹（Trajectory）数据：关注 Agent 的思考和调用工具的过程——包括 user prompt、每一步的调用、最终输出和内部思考，是智能体行为视角。
区别就像查水表和看监控回放。评估一个 Agent 该用哪个？当然用监控回放。不然你以为它答得对，其实是蒙的，你还蒙在鼓里。
6.2 两种运行策略
持续评估：基于新数据持续运行，来一条新数据就评估一条，每分钟都在跑。适合线上质量盯盘，badcase 一出现就能被抓到。
历史评估：对某段时间的历史数据做一次完整评估（比如最近 4 小时），评完就结束。适合复盘和专项分析。
类比一下：持续评估是你 24 小时盯着猫，看它什么时候把杯子推下桌；历史评估是杯子碎了之后，你调监控找出罪魁祸首。两种都合理，看你是想止损还是想追责。
6.3 采样配置：省钱是硬道理
评估是调用专门指定的评估 Agent 来做的——每一条数据都要走一遍完整的评估流程，消耗比较大。
并非所有场景都需要全量评估。如果只关心 badcase，可以做一个采样，大幅降低成本。比如最大样本数设为 100、采样比例 100%，意思是"最多评 100 条"。
先用采样把流程跑通、验证掉，等需要全量盯盘时再放开。这是控制成本的标准做法。毕竟评估 Agent 烧的钱又不是大风刮来的——虽然它自己可能觉得是。
6.4 字段映射：把数据接到变量上
最后一个配置点：评估器定义了 input / output / 轨迹三个变量，但平台里的数据字段有自己的名字，任务里要把数据字段映射上去：
trace.input → input
trace.output → output
trace.agent → agent_trajectory
映射的本质是把"数据的字段"接到"评估器的变量"上。这就好比两个系统对接，一个叫"客户姓名"，另一个叫 user_name，中间必须有个翻译官。
映射错了，评估器拿不到正确的输入——就像你给阅卷老师发了答题卡，但是忘了发试卷。他倒是想给你打分，他拿什么打？
7. 评估结果与 badcase 闭环
评估完成后看结果页：左边是每条数据的介绍（Input/Output），右边是评估结论——平均分值和加权分数。
但分数之外，更有价值的是右边那组字段：解释、summary、final score、decision 以及证据。评估器不只是打分，还要说明"为什么是这个分"——证据字段会给出判定的依据。
这让低分条目变得可处理：你看到的不是一个孤零零的 0.4 分，而是"哪一步做错了、依据是什么"，调优方向直接写在结果里。
这体验怎么说呢，就像女朋友说"我没事"和说"我没事，因为你忘了今天的纪念日"的区别。后者虽然扎心，但你至少知道该干什么。
7.1 多次评估看均值
由于单次评估存在浮动（同一个评估器评同一条数据，分数可能略有差异），可以多次评估看均值，更客观地反映 Agent 质量。
就像体测跳远，你一次跳 2 米，一次跳 1.2 米，教练让你再跳一次取平均。你愤怒地发现，平均数比你最好的那次差了一大截——但教练说得对，你确实不稳定。
7.2 badcase 进库，实验才有弹药
更重要的是闭环：在线评估抓出来的 badcase 沉淀进数据集，成为后续实验回测的弹药。评估分数低的地方，就是下一轮针对性调优的方向。
到这一步，评估不再是一次性的质检动作，而是飞轮里承上启下的一环——上承观测数据，下接实验回测。
这跟你写单元测试的心路历程一模一样：第一版觉得是负担，后来发现它能帮你挡掉 80% 的线上事故，从此真香。
8. 一句话总结
评估的本质，是把专家对"好"的定义变成机器可执行、结果可解释的资产。
翻译成人话：先把尺子造好，再谈量东西。尺子都没有，你量出来的所有数字，都只是自我安慰。
下一篇该聊聊实验回测了——评估发现了问题，接下来就要反复验证优化效果。咱下回见。
P.S. 推荐一个大神的教程给想要了解或者学习人工智能知识的读者，这个教程里内容讲解通俗易懂且风趣幽默，对我帮助很大。我想与大家分享这个宝藏教程，请点击下方链接查看，传送门https://blog.csdn.net/qq_74013365
