惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

M
MIT News - Artificial intelligence
雷峰网
雷峰网
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Last Week in AI
Last Week in AI
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
阮一峰的网络日志
阮一峰的网络日志
月光博客
月光博客
博客园 - Franky
腾讯CDC
T
Tailwind CSS Blog
Recent Announcements
Recent Announcements
V
V2EX
N
Netflix TechBlog - Medium
量子位
Jina AI
Jina AI
Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
G
Google Developers Blog
爱范儿
爱范儿
博客园 - 叶小钗
D
Docker
MongoDB | Blog
MongoDB | Blog
D
DataBreaches.Net
T
The Blog of Author Tim Ferriss

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
AI 产品评测体系设计——别让主观感觉骗了你 – 人人都是产品经理,
鸣老师 · 2026-04-19 · via 人人都是产品经理

在AI产品的迭代过程中,「感觉」往往是最大的误导者。当技术评测、产品体验与业务价值交织在一起时,如何建立一套科学的评测体系成为关键挑战。本文系统拆解AI产品三大评测层次(技术、产品、业务),揭示从准确率到用户满意度的量化方法论,并附上客服场景的真实案例,助你告别主观臆断,用数据驱动产品进化。

「感觉新版本比旧版本好用多了。」

这是上周评审会上产品同学说的话。

我问他「好用多了是多少?有数据吗?」

他愣了一下「呃,就是感觉响应更快了,回答更准了。」

「感觉」是最不靠谱的评判标准。

今天聊聊怎么给 AI 产品建立一套靠谱的评测体系。

传统软件好判断,按钮能不能点、功能正不正常、性能快不快。

AI 产品不一样

第一个问题是效果是概率性的。传统软件输入 1 加 1 必须返回 2 不然就是 Bug。AI 产品问「推荐一本好书」返回什么都可能是对的。AI 的输出是概率性的没有绝对正确的答案。

第二个问题是主观性太强。「这个回答好不好」不同人的判断可能完全不同。同一个回答 A 觉得太啰嗦了,B 觉得解释得很清楚,C 觉得没回答到点子上。主观感受很难统一标准。

第三个问题是变量太多。AI 产品的效果受很多因素影响,模型版本、Prompt 写法、上下文长度、用户问法、知识库质量。改一个变量效果可能完全不同。没有系统的评测根本不知道改动是好是坏。

一个完整的 AI 产品评测体系需要三个层次。

第一个层次是技术评测,评估模型本身的能力。常见指标包括准确率、召回率、F1 分数、响应延迟、Token 消耗。适用场景是模型选型、技术优化。

第二个层次是产品评测,评估功能在产品层面的体验。常见指标包括任务完成率、用户满意度、交互轮次、会话放弃率。适用场景是功能迭代、体验优化。

第三个层次是业务评测,评估对业务目标的贡献。常见指标包括效率提升节省多少时间、成本降低节省多少钱、质量提升错误率下降多少、收入增长带来多少订单。适用场景是 ROI 评估、决策支持。

技术评测怎么做呢

首先要建立测试集。测试集是评测的基础。要求是覆盖常见场景、包含边界情况、有标准答案或参考答案、定期更新。

然后是自动化评测。能自动评测的就不要人工评。客观题直接对比答案包括精确匹配、关键词包含、语义相似度。主观题用 AI 评测 AI,用 GPT-4 给回答打分,设定评分标准也就是 Rubric,多次评测取平均。

关键指标包括准确率是正确回答数除以总回答数适用于事实性问答,召回率是召回的正确答案除以所有正确答案适用于 RAG 检索,延迟 P50 和 P99 是响应时间分位数适用于性能评估,幻觉率是包含虚假信息的回答比例适用于可信度评估。

产品评测怎么做呢

技术指标好看产品体验可能很差。所以还需要产品层面的评测。

第一个指标是任务完成率。定义是用户能不能完成他想做的事。计算是成功完成任务的会话数除以总会话数。什么算「完成」呢,用户明确表示满意,用户完成了操作比如下单提交,会话正常结束没有中途放弃。

第二个指标是交互轮次。定义是完成一个任务需要几轮对话。计算是每个任务的平均对话轮次。意义是轮次越少效率越高,但不能为了减少轮次牺牲准确性。

第三个指标是用户满意度。获取方式包括会话结束后让用户打分、抽样做用户访谈、分析用户行为比如有没有转人工有没有重复问。注意满意度调查的样本要足够大否则偏差很大。

第四个指标是会话放弃率。定义是用户中途放弃没有完成任务的比例。计算是中途放弃的会话数除以总会话数。什么算「放弃」呢,连续几条消息没有响应,直接关闭对话窗口,转人工客服,表达不满比如「没用」「算了」。

业务评测怎么做呢

技术好产品好但业务没价值也是白搭。

效率指标方面看处理时间,优化前平均处理一个工单需要 15 分钟优化后需要 5 分钟。看处理量,优化前每人每天处理 30 个工单优化后处理 60 个。

成本指标方面看人力成本,减少了多少人工工作量节省了多少人力成本。看 API 成本,每次调用花多少钱,单位业务量的 AI 成本。

质量指标方面看错误率,优化前人工审核错误率 5% 优化后 AI 辅助后错误率 2%。看合规率,内容审核的准确率、漏检率、误检率。

收入指标方面看转化率,AI 推荐带来的转化率对比不用 AI 的转化率。看客单价,AI 推荐的商品平均单价对比人工推荐。

评测有几个关键实践

第一个实践是建立 Baseline。任何优化都要有对比基准。错误做法是优化完直接上线「感觉」变好了。正确做法是先测 Baseline 再测优化后的效果对比数据。比如 Baseline 旧版本准确率 75%,优化后新版本准确率 82%,提升 7 个百分点。

第二个实践是控制变量。一次只改一个变量否则不知道是哪个改动带来的效果。错误做法是同时改了 Prompt 换了模型加了知识库,效果变好了但不知道是哪个起的作用。正确做法是只改 Prompt 测效果,只换模型测效果,只加知识库测效果。

第三个实践是 A/B 测试。把用户随机分成两组,A 组用旧版本 B 组用新版本,对比两组的数据。注意样本量要足够大,分组要随机,运行时间要足够长。

第四个实践是持续监控。上线不是结束而是开始。建立监控看板核心指标每天看,异常自动报警,定期 Review。监控什么呢,任务完成率、响应延迟、错误率、用户投诉。

分享一个真实案例

我们帮一个客服团队做的评测体系。背景是 AI 客服上线 3 个月老板问「效果怎么样」,没人能回答。

我们做了什么呢。

第一步建立测试集。整理了 500 个真实用户问题分类标注,产品咨询 200 个,售后问题 150 个,投诉建议 100 个,其他 50 个。每个问题都有参考答案。

第二步跑 Baseline。用测试集测了一遍现有系统,整体准确率 68%,产品咨询准确率 82%,售后问题准确率 61%,投诉建议准确率 45%。问题很明显售后和投诉场景比较弱。

第三步针对性优化。针对弱项做了优化,补充了售后知识库,优化了投诉处理的 Prompt,增加了情绪识别。

第四步评测优化效果。优化后重新测,整体准确率 68% 提升到 78%,售后问题准确率 61% 提升到 76%,投诉建议准确率 45% 提升到 62%。

第五步业务指标对比。上线优化版本后人工介入率 35% 降到 22%,用户满意度 3.2 提升到 3.8 满分 5 分,平均响应时间 8 秒降到 3 秒。

关键收获是有数据才能说话,之前大家只能说「感觉」现在能说「准确率提升 10 个点」。发现真正的问题,数据显示售后场景弱这是之前没意识到的。验证优化效果,优化不是盲目的有数据验证。建立持续改进机制,每月跑一次评测持续优化。

说说常见误区

第一个误区是只看技术指标。模型准确率 95% 但用户满意度只有 60%。为什么呢,可能是回答太长、太专业、太冷冰冰。技术好不等于产品好。

第二个误区是样本量太小。测了 20 个案例得出「准确率 90%」的结论。这个数据没有统计意义,样本量至少要有几百个。

第三个误区是测试集和真实场景脱节。测试集是产品经理自己想的问题。真实用户的问题千奇百怪测试集覆盖不到。测试集要从真实数据中抽样。

第四个误区是评测一次就完事。上线前测了一次之后再也不测了。但模型会升级、知识库会变化、用户问题也在变化。评测要持续做不是一次性的。

做 AI 产品最怕的就是「自我感觉良好」。

数据是最诚实的。

建立评测体系的核心是有标准让什么是好什么是差定义清楚,可量化不是「感觉好」而是「准确率 82%」,可对比有 Baseline 有 A/B 测试,可持续不是一次性的是持续监控的。

如果你的 AI 产品还没有评测体系强烈建议尽快建一个。

不然你永远不知道自己是在进步还是在原地踏步。

本文由 @鸣老师 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议