评估与评测
评估与评测
"这个 AI 产品到底行不行?"——没有评估,就没有迭代。评估是 AI 产品经理最重要的基本功之一。本文从三层评估体系讲起,再展开评测维度、基准与榜单、人工评测与 LLM-as-Judge、红队测试与线上评估,把「怎么证明一个 AI 产品行不行」讲全。
为什么评估难
- 模型输出是概率性的:同样输入,两次结果可能不同——评估必须容忍方差,用多次采样或足够多样本摊平噪声
- 质量是多维度的:准确、流畅、相关、安全、风格……很难一个分数说清;不同业务对维度的权重完全不同(医疗要准确与安全,营销要风格与相关性)
- 人工评测贵,自动评测不准:人工慢且主观,自动指标常抓不住语义质量
- 评估对象在漂移:模型版本更新、提示词改动、用户行为变化,都会让旧评测集失真——评估不是一次性工程,是常跑常新的循环
- 评估分三层:能力(模型本身)、任务(某个任务做得好不好)、产品(业务指标好不好)——三层混淆是 AI 评估最常见的错误,下面逐一展开
三层评估体系
1. 评测集(离线)
- 收集代表性输入:典型场景、边界场景、对抗场景;规模从 20 条种子集起步,随迭代扩充到几百上千条
- 为每个输入标注期望行为(答案要点、禁止行为);标注要写明「可接受的答案范围」而非唯一答案——大模型输出天然多样
- 每次改模型/提示词后跑一遍,作为回归防线;评测集要版本管理,并记录每次得分(模型、提示词、日期、得分),才能看出趋势
- 注意评测集污染:测试用例一旦进入提示词或训练数据,该用例就失效;评测集要与生产链路隔离,定期轮换新增
2. 线上指标(在线)
| 指标 | 说明 |
|---|---|
| 任务完成率 | 用户请求最终是否达成 |
| 采纳率 | 生成结果被用户采用/修改的比例 |
| 错误率/投诉率 | 用户明确表示不满 |
| 重试率 | 用户是否反复追问同一问题 |
| 会话深度 | 多轮对话的比例与长度 |
| 转人工率 | Agent/客服场景:自动解决不了的占比(降本指标的核心) |
| 幻觉率代理 | 点踩、纠正、引用被质疑等行为的占比(没有直接幻觉标签时的代理指标) |
| 首 token 延迟 / 端到端延迟 | 体感指标,与完成率互为代价(快而差 vs 慢而好) |
| 成本 / 请求 | 与质量指标一起看,评估「质量换成本」的划算度 |
线上指标回答「真实用户下表现如何」,但噪声大、归因难(是模型问题还是入口问题?)——所以线上指标与离线评测集是互为补充的两条腿,不能只用其一。
3. 用户体验(定性)
- 用户访谈、可用性测试
- 把真实对话记录抽样复盘(注意脱敏)
- 定性发现用于生成假设,再回到评测集与线上指标验证——定性不定量,定量不定性,两者闭环
常见评测维度
| 维度 | 定义 | 怎么测 |
|---|---|---|
| 准确率 | 事实正确性 | 对照标注的要点逐条打分;数字/日期/来源类错误单独记录 |
| 忠实度 | 是否忠于给定资料(RAG 场景) | 对照资料检查「资料里没有的信息是否被编造」 |
| 相关性 | 回答是否切题 | 问题-回答语义匹配度打分 |
| 完整性 | 是否漏掉关键点 | 对照要点清单查漏 |
| 安全性 | 是否输出有害内容 | 安全评测集 + 红队测试(见下) |
| 风格 | 是否符合品牌与场景 | 人工盲评、风格 rubric |
实操提示:每个维度单独打分(1-5 分),不要混成一个总分——混分之后你不知道该修哪一维。
常见评测基准与榜单
- 知识:MMLU(多任务理解,常识与学科知识)
- 推理:GPQA(研究生级科学问答)、AIME/MATH(数学竞赛)、MATH-500
- 代码:HumanEval(函数生成)、LiveCodeBench(在线更新、抗污染)、SWE-bench(真实 GitHub 工程修复,Agent 级)
- 多模态:MMMU(大学级多模态理解)、MMBench、MM-Vet
- 中文:C-Eval、CMMLU
- Agent:GAIA、τ-bench(工具调用)、SWE-bench(长程任务)
看榜单的四个坑:
- 污染:热门基准可能混入训练数据,分数虚高;优先看 LiveCodeBench 这类「在线出新题」的基准,或第三方复测
- 同分布问题:基准分布 ≠ 你的用户分布——榜单只是初筛,最终以自建评测集为准
- 官方自报 vs 第三方:优先第三方评测(如 LMArena 匿名竞技场),官方自报分数作参考
- 采样设置:temperature 为 0 与多采样投票的分数没有可比性;对比时必须同设置
人工评测与 LLM-as-Judge
- 人工评测:双盲标注(标记者不知道模型身份)、多人独立评分取一致性(Cohen's κ / Krippendorff's α)、评分标准(评分卡)先行;贵、慢,但最可靠——用于小规模高价值样本与争议裁决
- LLM-as-Judge:用一个强模型给另一个模型的输出打分/两两对比;原理是让评判模型按 rubric 打分,或 A/B 对比后投票
- Judge 的校准:
- 位置偏差(先出现的答案被偏好):两两对比时交换顺序各评一次
- 长度偏差(长答案得分虚高):提示词里明确「不考虑长度」
- 自我偏好(judge 偏好与自己同源的模型):混合多家模型做 judge
- 用一小批人工标注样本校准 judge:judge 与人工一致性达到阈值(如 80%)才可放心批量使用
- 适用边界:结构化任务(摘要、分类、抽取)judge 很稳;创意写作、深度推理仍以人工为准;judge 适合做「过滤器」(先自动筛,低置信再人工)
红队测试
- 红队(Red Teaming) 指以攻击者视角主动探测模型的失败模式:越狱提示、有害内容诱导、隐私套取、注入攻击(见 提示词安全)、偏见与冒犯性输出
- 红队不是一次性的:每个新模型版本、新提示词、新功能上线前都要跑一轮;红队用例沉淀进评测集成为长期回归项
- 产出不是「有没有问题」而是「失败模式清单」:每种失败给触发条件、危害等级、缓解方向(提示词加固 / 内容过滤 / 人工兜底)
- 大厂做法参考:官方系统卡(system card)里的红队方法论,如 OpenAI/Anthropic 的安全评测披露
线上评估与灰度
- 灰度发布:新模型/新提示词按比例放量(如 10% → 50% → 100%),与旧版本对照线上指标;对照期间保证分组随机,排除时间因素
- A/B 测试:同一批用户随机分两组,比较任务完成率、采纳率等;注意大模型输出方差大,样本量要足够,并用统计检验而非拍脑袋
- 回滚预案:新版本指标明显变差时,5 分钟退回旧版本——回滚是发布流程的一部分,不是事后补救
- badcase 回流闭环:线上失败案例 → 人工复盘 → 归纳错误模式 → 回填评测集 → 修复(改提示词/换模型/加护栏)→ 回归 → 再灰度;这是 AI 产品迭代的日常节奏,详见 AI 产品开发生命周期(CC/CD)
实操建议
- 种子评测集从第一天建:20 条就够了,边做边扩充
- 失败案例库:每次上线后收集用户不满意案例,回填评测集
- 人工抽检常态化:每周抽 20-50 条真实对话人工评分
- 版本对照:新模型/新提示词上线前,同一评测集新旧对照
- 评估自动化:评测集跑分脚本化(每日/每次变更触发),把评估从「手动活动」变成「CI 一部分」
评测会失效:持续校准(CC)
评测集基于"预期用户行为"设计,而 AI 用户的真实行为是非确定的——评测失效、需要重做,完全正常,通常要跑多轮。CC(持续校准)阶段的做法:运行评测 → 人工审查最弱环节(每部门抽 20~50 条低分样本)→ 归纳错误模式(表格:模式/触发条件/影响/修复方向)→ 数据驱动修复。
完整的 CC/CD 生命周期见 AI 产品开发生命周期(CC/CD)。
练习
为你正在做的 AI 产品定义:① 10 条种子评测集;② 3 个线上核心指标;③ 每周抽检的方式;④ 一个新模型上线时的灰度与回滚方案。
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用