效果评测体系

效果评测 = 用一套科学的方法和指标，持续衡量 AI 产品的输出质量是否达标、是否在退化、是否优于竞品的过程。

简说：给 AI"考试"，看它做的事到底好不好。

一句话心法：没有度量，就没有改进；没有评测，就没有好产品。

核心认知：评测不是"上线前测一次"的环节，是贯穿产品全生命周期的基础设施。

本页是评测主题的枢纽页。评测对象怎么分（Prompt vs Agent）见 Prompt测试与Agent测试；输出怎么打分（确定性/生成性、评估器加权、GSB/SBS）见 AI评测打分方法；Bad Case 怎么归因见 Badcase分析方法论。

评测定义的五要素

AI 评测 = 围绕特定业务目标，用测试集、指标体系和评价标准，对 AI 输出质量、任务完成能力、稳定性、安全性、风险做系统性测量和判断。本质是把"这个 AI 看起来还不错"变成"我们有证据证明它在特定场景下可用、可靠、可控"。拆成五要素：

要素	通俗说
业务目标	不是泛泛测聪明程度，先从业务倒推评什么
测试集	要有"考卷"
指标体系	要有"分数"
评价标准	要有"判卷规则"
系统性测量	不是凭感觉看几条回答

好 AI 因业务而异：同一句"我买了 15 天能退款吗"，法务关注条款责任、销售关注能否回款、财务关注开票收入、CSM 关注服务边界——所以评什么、怎么评、什么算通过，必须先理解业务场景。

评测的核心目的

知道效果好不好（量化）
知道哪里不好（定位）
知道怎么变好（行动）
知道有没有变好（验证）

没有评测体系的 4 个致命后果

不知道现在效果是好是坏 → 产品决策全靠拍脑袋
改 Prompt/换模型不敢上线 → 没法判断是变好了还是变坏了
模型悄悄退化没人发现 → 等用户投诉时已经太晚了
竞品发布新模型不敢跟 → 不知道自己的差距在哪

步骤总览

步骤	名称	核心问题	主要产出	负责人 / 时长
1	定指标	北极星指标是什么？红线在哪？	分层指标清单 + 红线告警	PM 主导 / 0.5 天
2	建评测集	用什么样本来评？	锁定版本的评测集	PM 主导 / 2-3 天
3	跑评测	多版本对比结果如何？	评测报告	技术主导 / 1 天
4	看 Badcase	错在哪？是系统问题吗？	归因清单（系统问题 vs 偶发）	PM 主导 / 1 天
5	反馈迭代	改哪里？多久再评？	修复方案 + 下轮评测计划	全员 / 持续

三大评测类型

类型	原理	优势	劣势	成本	速度
自动评测（70%）	用程序计算目标（准确率、F1、BLEU、ROUGE 等）	快、可重复	只评"客观对错"，评不了"主观好坏"	~¥0/条	1000 条/分钟
人工评测（5%）	让真人对 AI 输出打分或对比	最接近真实用户感受，能评价主观质量	贵、慢、不可大规模	~¥5-20/条	~50 条/天
模型评测 LLM-as-Judge（25%）	用强大模型（GPT-5/Claude Opus）来替代人工评判 AI 输出	比人工快 100 倍，比自动评测更理解主观质量	不完全可靠，有偏见	~¥0.1-0.5/条	~50 条/分钟

最佳配置（金字塔结构）：自动评测 70% + 模型评测 25% + 人工评测 5%

另一种正交的切法：离线 / 在线 / 人工

上表是按**"谁来评判"分（自动程序 / 强模型 / 真人）。还有一种按"什么时机、用什么数据"**分的切法，二者正交、常组合使用：

方法	说明	何时用
离线评测	上线前用固定评测集批量自动测，可复现、可频繁回归	质量保障与快速迭代的基石，尤其 Prompt 测试与回归
在线评测	上线后通过 A/B 测试在真实流量中验证，结果最真实、直连业务指标	检验 Agent 实战价值的最终环节
人工评测	专人对生成内容（文案/图片）做主观质量评估，能评创意、审美	机器难评的主观维度，成本高

实践组合：以离线评测保基础，用在线评测验价值，以人工评测补主观。Prompt 测试偏离线+固定集，Agent 测试要离线+在线+人工组合（见 Prompt测试与Agent测试）。

第一步：定指标

北极星指标 + 分层指标（性能层/效果层/体验层/业务层）
设置红线（自动告警/暂停）
业务方背书：什么算"达标"必须有业务方签字

第二步：建评测集

分布科学：覆盖真实使用场景的样本比例
规模适中：常规题 + 陷阱题（陷阱题决定上限）
锁定版本：评测集要打 tag，迭代后能溯源
重视陷阱题：陷阱题暴露的是模型在边界情况的真实能力

五大构建原则：覆盖性（不同难度/句式/干扰/核心与边缘场景）、真实性（优先真实用户数据或高仿真合成）、可标注性（每条都有明确预期输出或评估标准）、规模（满足统计显著性）、平衡性（各类别样本均衡，避免数据倾斜）。

四类样本来源：

来源	重点采集对象
线上用户日志	尤其是用户改了 AI 输出、或重复提交的 case
历史 BadCase	被投诉的问题、算法标记的异常、用户差评
边界 Case	人工主动构造的难题——矛盾需求、极端脏数据、极小众场景
AI 生成初始样本	让 AI 生成候选，但必须人工筛选，不能直接用

评测集是资产，不是一次性数据：最大的坑是"每次临时凑一批数据，导致不同版本结果没有可比性"。要像管代码一样版本化管理（V1.0/V2.0），定期用线上回流数据更新，保持"活性"。

第三步：跑评测

多版本对比，自动 + 人工 + LLM-as-Judge 按金字塔配比，看趋势而非单点。

第四步：看 Badcase

分类归因，可复现 vs 偶发，找规律。完整方法见 Badcase分析方法论。

第五步：反馈迭代

模型/数据/Prompt/产品各维度修复，再循环。每次只动一个变量——否则不知道是哪个改动起作用。

评测设计 5 大原则

与业务强相关：评测指标和业务目标直接挂钩
可重复、可对比：相同输入，不同版本的结果可量化比较
全面但不奢华：覆盖主要场景和关键 case，不追求穷举
持续监控：上线后双边监控，效果和业务指标双看
选择性优化：每次只改一个变量（模型/Prompt/数据）

PM 此阶段职责

定北极星指标：找到能代表业务价值的核心指标，避免被"准确率"这种单一技术指标绑架
造评测集：评测集是评测体系的根，必须由 PM 牵头、业务方共建
解释结果：把技术报告翻译成业务方能看懂的"现在能用 / 不能用 / 风险在哪"
守住红线：哪些指标跌破要立即回滚，必须提前定好
闭环迭代：每轮评测的 Badcase 必须有归因和修复计划，避免"评了就完"

协作对象：算法工程师（自动评测 + 模型评测）、评测工程师、业务方（人工评测样本/标准）、运维（线上监控告警）

两种对比视角：横向 vs 纵向

跑评测时所有对比都靠"同一把固定的尺"（同一评测集 + 同一评估器）：

视角	操作	目的
横向对比	同一时间、同一评测集，比不同模型/方案（A/B/C）	选优——技术选型、引入新模型
纵向对比	同一评测集，比同一模型的不同版本（线上版 vs 待发布版）	验迭代——量化提升、捕获回滚，是能否上线的核心决策依据

具体打分用 GSB / SBS 对比法，见 AI评测打分方法。

"四步走"评测流程

把评测固化成可复用的质量门禁，是上面"五步评测法"的工程化落地：

固定评测集 + 统一评估标准：评测集版本化，评估器口径统一（这是一切对比的基础）
执行对比评测：纵向（版本回归）+ 横向（方案选型）
线上数据回流 + Bad Case 分析：定期采集线上输入/输出/反馈更新评测集，Bad Case 归因修复，见 Badcase分析方法论
沉淀结论共识：输出标准化报告

标准化评测报告应含：实验背景（目标是版本验证还是选型）、实验设计（对比的版本/方案、评测集与评估器版本）、核心结论（开门见山用数据说话，是否达上线标准）、详细数据对比、Bad Case 分析（典型失败案例 + 根因 + 解决方案）。

评测中的团队四角色

评测是把团队从"我觉得"拉到"数据表明"的协作语言：

角色	在评测中负责
PM（产品）	定核心业务目标与成功标准、参与评测维度设计与 Bad Case 定级、基于报告做产品决策
Operator（运营）	提供真实业务场景与用户洞察（保评测集真实性/覆盖性）、参与生成性内容人工评测、盯线上 A/B 业务数据
Server RD（研发）	模型选型/训练/Finetune、Prompt 优化、接"模型能力局限/Prompt 缺陷"类 Bad Case、搭自动化评测流水线
QA（质量保障）	主导整个评测体系建设、评测集设计与维护、执行横纵对比与自动化测试、撰写标准化报告

从传统 PM 到 AI PM：四个环节各多了一项 AI 专属动作——需求分析多了"AI 能力边界评估"、产品设计多了"Prompt 工程"、效果验证多了"评测集 + 指标体系"、迭代决策多了"Bad Case 归因"。