AI 产品经理：评测体系入门
核心观点：先学评测，不要先学算法或模型原理。
评测不是传统意义上的“测试”。传统测试更关注功能有没有 bug、是否符合预期；很多人也会把评测简单理解为“看准确率”。但对 AI 产品而言，评测集的构建过程，就是你对需求和模型的理解；评测结果，则是后续迭代的原点。
一、为什么 AI 产品经理要先学评测
1. 评测标准源于对场景的理解
评测标准不是凭空定的，而是基于你对场景的认知，定义“用户需求被满足时，模型应该达到什么标准”。
例如做 AI 客服时，我们希望客服回答准确、表达自然、能真正解决问题。但“怎么算准确”“怎么算解决问题”“什么程度叫用户满意”，都需要通过指标定义清楚。
看起来是在定指标，本质上是在基于需求理解模型能力。
2. 评测集约等于 AI 产品的 PRD
评测集通常包含几百到几千个典型用户意图、场景以及理想回答。
- 用户意图决定产品要解决哪些问题
- 场景决定模型需要覆盖哪些边界
- 理想回答代表产品经理对产品理想态的理解
- 模型在这些维度上的表现，就是给算法团队的需求
因此，评测集不是简单的测试样本，而是 AI 产品需求的结构化表达。
3. 不懂评测的后果
如果不懂评测，就会出现这样的问题链条：
不理解需求和模型 → 无法设计 → 无法衡量 → 无法迭代 → 不知道怎么做产品
同时，产品经理也很容易被算法指标“糊弄”。算法团队关注的数据指标，可能与用户体验、业务价值脱节。只有懂评测，产品经理才能从用户视角和业务视角验收模型，而不是被动接受技术产出。
4. 评测是 AI 产品经理的数据分析
传统产品经理通过数据分析迭代产品；AI 产品经理通过评测 + bad case迭代产品。
这也是 AI 产品经理面试中的高频考点。
二、评测理解的三级模型
Level 1：感知型评测
多数人停留在这个阶段：大概知道 AI 输出好不好，但判断标准粗糙，主要靠感觉。
典型回答：
- 看用户满意度
- 在产品里设置“有用 / 没用”按钮
- 看用户是否继续追问
问题在于没有说清楚：
- 什么是“好”？
- 从哪些维度衡量？
- 这些维度与业务目标是什么关系？
- 标准怎么定？
Level 2：指标拆解型评测
这一层已经能把业务目标拆成具体指标，但还缺乏体系化闭环。
以 AI 客服为例，可以拆成：
- 准确率：回答是否正确
- 覆盖率：能处理多少类问题
- 转人工率：AI 对场景的覆盖程度
- 解决率：用户是否还需要继续追问
- 用户满意度：用户是否认可答案
以电商素材生成为例，可以拆成：
- 图片是否符合用户意图
- 与商品是否一致
- 图像生成质量和美感如何
- 卖点表达是否准确
指标拆解本身没问题，但评测是体系化工作，还需要继续说明：
- 评测标准怎么定？
- 评测集怎么构建？
- bad case 如何回流？
- 如何形成持续闭环？
Level 3：体系化评测
体系化评测要能完整回答六个问题：评什么、用什么评、怎么打分、谁来执行、错了怎么改、什么时候持续评。
三、体系化评测的六个维度
1. 定评测维度
不同产品、不同任务的评测标准差别极大，不能用同一套维度。
例如：
- 智能客服更关注准确性、覆盖率、解决率、转人工率
- 电商素材生成更关注意图匹配、商品一致性、画面质量、卖点表达
- 知识问答更关注事实正确性、引用可靠性、答案完整性
- Agent 类产品更关注任务完成率、步骤合理性、工具调用成功率
评测维度必须从具体场景和具体目标中来。
2. 构建评测集
评测集不是随便抽几个 case，而要覆盖四类问题：
- 高频问题：用户最常遇到的场景
- 低频但重要的问题：出现少，但影响大的场景
- 边界问题：临界、模糊、容易出错的场景
- 高风险问题：出错后果严重的场景
一个好的评测集，本质上是在回答：这个 AI 产品到底应该服务哪些用户、解决哪些问题、在哪些边界上不能犯错。
3. 制定评分标准
AI 产品效果往往带有主观性，例如生成内容好不好、推荐理由可不可信、回答有没有帮助，都需要人来判断。
但如果没有标准化、可共识的评分标准，就会出现“产品和算法觉得还行，但老板不满意、用户不满意”的情况。
关键做法是：把主观感觉变成可讨论的标准化逻辑。
例如评价“图片是否符合意图”，可以做 1 分到 5 分的分档：
- 1 分：完全不符合用户意图
- 2 分：只命中少量关键词，整体方向偏差明显
- 3 分：基本符合意图，但存在明显缺失或误解
- 4 分：较好符合意图，只有轻微瑕疵
- 5 分：高度符合意图，且表达完整自然
这样即使交给其他团队评测，目标也更清晰。
4. 明确落地执行逻辑
评测不是一句“产品经理看一下”就结束了，需要明确执行机制：
- 是产品经理自己 check，还是专门的评测团队执行？
- 产品、算法、运营分别负责哪些部分？
- 哪些 case 需要人工复核？
- 哪些指标可以自动化评测？
- 为什么采用这种分工？
执行逻辑越清楚，评测结果越稳定，也越容易被团队信任。
5. Bad Case 分析与回流
bad case 是 AI 产品迭代的关键燃料。
分析 bad case 时，不能只停留在“模型答错了”，而要进一步归因：
- 是模型能力问题？
- 是 prompt 设计问题？
- 是知识库或数据问题？
- 是工具调用链路问题？
- 是需求定义本身不清楚？
- 是评测标准不合理？
不同归因对应不同解决方式。模型问题可能需要换模型或微调；prompt 问题需要改提示词；数据问题需要补知识库；需求定义问题则要回到产品规则本身重新澄清。
最终，沉淀下来的 bad case 需要回流到评测集，变成下一轮迭代的固定考题。
6. 设计评测时机与持续机制
评测不是一次性动作，也不是上线前测一次就结束。AI 产品越用越会产生新问题，因此必须设计持续评测机制。
| 阶段 | 评测方式 |
|---|---|
| 上线前 | 基于评测集的离线评测 |
| 上线后 | 线上真实数据监控 + 用户反馈 |
| 定期 | 沉淀 bad case，做专项评测 |
| 闭环 | bad case 回流到评测集，持续迭代 |
这套机制能让产品迭代从“凭感觉优化”变成“基于问题证据优化”。
四、一句话总结
评测不是测试，是 AI 产品的 PRD。
它定义了“什么是好”，承载了产品经理对需求和模型的理解，也是产品与算法之间最重要的共同语言。
不懂评测，就做不了 AI 产品。
