前阵子面试AI产品岗，评测这块被问了好几道题，结合之前做的一个智能客服问答系统升级项目复盘一下。项目背景是这样：公司原有客服系统准确率只有60%左右，我们做了RAG+Prompt优化，上线前需要设计完整的评测体系。整个过程中踩了不少坑，也积累了一些实战经验。

---

【真题1】评测指标怎么定？

你们做AI产品评测，指标是怎么设计的？从哪些维度考虑？

参考解析：

这个问题考查的是评测体系搭建能力。很多人只会说准确率、召回率这些技术指标，但实际上需要从技术、业务、用户体验三个维度来构建完整体系。

技术指标要针对不同任务类型区分。分类任务看准确率、召回率、F1值；生成任务看响应时间、并发能力、输出稳定性。还要根据场景做权衡，比如风控系统更关注召回率，宁可多拦截也不能漏掉风险；推荐系统更关注精准率，推错几个没关系，但推得准才能带来转化。

业务指标关注AI有没有真正创造价值。核心看任务完成率、人工干预率、成本节约、对核心业务指标的影响。像我们那个客服项目，就是把AI效果和业务增长绑定——机器能覆盖多少问题，省下多少人工坐席，转化率有没有提升。

用户体验指标也不能少。用户满意度可以通过NPS或问卷收集；采纳率看AI给出的建议用户实际用了多少；留存率和使用频次反映用户会不会持续用；还有严重错误率，那些会导致投诉或流失的高危错误要单独监控。

---

【真题2】评测流程怎么设计？

你能详细说说你们的测评流程吗？怎么定义测评维度和规则，怎么判断产品能不能上线？

参考解析：

这个问题考查的是评测落地的实操能力。我们当时的流程分四步：

第一步是设定目标。比如我们定的是准确率达到80%以上才能上线。这个80%不是拍脑袋决定的，我们调研了行业水平大概在87%左右，考虑到我们是气象应急行业，问题比较硬性，要求准确率高，但项目初期80%是一个合理目标。

第二步是制定测评集。由我和业务专家一起以人工方式构建，准备了200条真实问题作为测试集。用业务数据说话，结果才能靠谱。

第三步是实际测评。把测评集输入到问答产品，获取输出结果，再由人工判断输出是不是和标准答案匹配。

第四步是统计通过率。通过样本数量占总测评数的比例，作为本次测评的最终指标。

但这只是基础流程，真正的挑战在于结果不达标怎么办。我们当时第一次测评只有72%，离80%差一截。

---

【真题3】结果不达标怎么排查？

如果测评结果达不到预期，你们怎么定位问题、决定优化方向？

参考解析：

这个问题考查的是问题定位和优化决策能力。我们采用倒推的方式，从最终生成结果开始，逐步回溯整个流程。

具体做法是复现整个链路，查看日志。如果召回阶段完全没有召回相关内容，说明是召回的问题；如果召回正确但答案错误，就是生成模块的问题；如果意图识别把用户问题分到错误类别，那就是前端分类的问题。

找到问题后，还要分析哪些场景失败率高。比如我们发现某一类问题占失败率的60%，就设定目标把这类问题的失败率降到20%。然后判断问题出在哪个环节——意图识别、知识库覆盖、提示词设计、还是模型本身能力不够。

优化优先级的考量也很重要。先调提示词，成本最低、见效快；再优化知识库，补充召回内容；最后才考虑换模型或微调，因为成本高、周期长。

---

【真题4】AI产品AB测试有什么特殊性？

你做过AB测试，AI产品和传统产品的AB测试有什么不同？

参考解析：

这个问题考查对AI产品特性的理解。AI产品的AB测试有两个明显特殊性：

一是指标更多元。传统产品看点击率、转化率就行，但AI产品尤其是大模型应用，既要盯着任务完成率、回答质量这类核心效果指标，还要兼顾响应速度、Token成本、用户满意度，不能单看一个指标得综合权衡。有时候新版本回答更准，但响应变慢，用户反而会更不满意。

二是模型本身有随机性。同样的Prompt，每次生成结果可能有差异。而且部分优化可能只适配特定场景，在其他场景反而更差。所以需要更大样本量抵消误差，必要时做分层实验，按用户类型、问题类型分别评估效果，避免整体数据掩盖问题。

---

【真题5】AB实验怎么设计？

你们做AI产品的AB实验，具体怎么设计？

参考解析：

这个问题考查的是实验设计能力。我一般分五步走：

第一步，明确实验目标和假设。比如优化后的Prompt能够将任务完成率提升10%，假设必须具体、可量化。

第二步，定义核心指标和观测指标。核心指标是决策依据，比如任务完成率；观测指标辅助分析，比如Token消耗、用户评分。

第三步，计算样本量和实验周期。样本量不足会导致结论不可靠，周期要覆盖足够多的用户，保证数据有统计意义。

第四步，设计分流策略。确保两组用户分布均匀，不能新用户全在B组、老用户全在A组。多实验并行时要考虑互斥性，避免互相干扰。

第五步，上线后持续监控，排查分流异常。实验结束后做显著性检验，验证假设是否成立。

---

【真题6】AI功能成功怎么定义？

你是怎么定义一个AI功能成功的？有哪些核心指标？

参考解析：

这个问题考查指标体系构建能力。一般从技术、用户、业务三个层面评估：

技术层面关注AI本身的能力表现。基础性能指标有准确率、召回率，但光看准确率不够，还要关注误判代价。比如推荐系统推错商品，用户不点就行，代价很低；但金融风控把正常客户误判为高风险导致流失，代价就很大。所以要根据业务目标权衡，是宁可漏掉也不误杀，还是宁可误杀也不漏掉。响应时间也很关键，大模型再聪明，用户问一个问题等10秒，体验就崩了。我们通常设定P95延迟，比如95%的请求在2秒内返回。

用户层面看行为数据。采纳率：有多大比例真正接受AI输出，要定义清楚什么是采纳，比如写作助手生成内容未修改直接发送才算有效使用。使用频率和留存率：一个真正有用的功能用户会反复用，用一次就流失说明没解决痛点或体验太差。用户满意度通过NPS和评分问卷收集，但不能只看评分，要结合定性反馈分析具体问题。

业务层面关注投入产出比。收益可能是直接收入增长，也可能是成本节约或效率提升。

---

【真题7】ROI怎么评估？

你们做AI项目，ROI怎么评估？

参考解析：

这个问题考查商业价值评估能力。不同类型项目方法不一样，常见有三种思路：

第一种，ToB项目可以直接算钱。把人力节省、效率提升换算成具体金额。比如客服场景，上线后机器能覆盖大部分场景，按每人月薪2万算，一年省72万。但实践中要注意，如果只算节省，不算训练、标注、运维投入，很容易高估收益。

第二种，ToC项目看用户行为变化。比如推荐系统，不能直接算省了多少钱，但可以看用户停留时长、留存率、转化率有没有提升。关键是做AB测试，没有对照组很难说清楚是不是模型带来的提升。上线后用户次日留存提升5%、转化率涨1.2%，结合用户规模就能估算真实价值。

第三种，底层模型看提效对业务的传导。要把模型指标和业务指标挂钩。比如语音识别错误率从10%降到5%，客服单次处理时间缩短20%，每天能多处理多少单，能带来多少增量。很多团队做模型优化会卡在"然后呢"这一步，关键是要形成从技术到业务的闭环。

---

【真题8】大模型选型怎么评估？

你们做大模型选型，整体思路是什么？

参考解析：

这个问题考查技术选型能力。大模型选型的关键不在于模型有多强，而在于评估方法能不能真实反映业务需求。可以从四个方向来做：

第一，评估方法要可落地。比如做论文批改系统，不能只用公开数据集，要准备200篇真实学生论文作为测试，用业务数据说话。

第二，备选模型要全面。不能只盯着GPT，要把主流模型都拉进来比一比。可以在OCR识别、内容理解、批改建议这些关键环节对每个模型单独打分，避免被某一个维度的高分带偏。

第三，评估过程要场景化。把任务拆解成核心子场景，每个场景定具体标准。像论文批改可以拆成图片转文字准确率、内容理解深度、批改建议质量，每一个都要有明确评估指标，不能笼统打分。

第四，结论要结合业务。测试分数最高的模型可能反而不适合上线，比如响应速度达不到业务要求。指标只是参考，业务适配才是关键。

还有一个技巧就是记录原始测试数据。面试时能说清楚每个模型在哪个环节失败、内容理解耗时分布、批改建议准确率波动，这种细节讲出来基本能进终面。

---

【真题9】AI聊天产品怎么评估好坏？

你觉得怎么评估一个AI聊天产品的好坏？

参考解析：

这个问题考查产品评测的综合视角。一般从三个层面看：可用性、可理解性、满意度。

可用性最基础，看用户能不能快速拿到想要的信息。主要指标有准确率、召回率、响应速度、上下文保持能力。如果总是需要多轮澄清，说明系统没有真正理解用户意图。

可理解性关注回答质量，逻辑是否清晰、语言是否自然。最关键的是有没有幻觉，即编造事实。好的产品还能根据上下文动态调整语气，比如对新手解释更详细，对专家直接给结论。

满意度反映长期价值，包括用户主观评分、留存率、使用时长、业务转化。在AB测试里重点看正向反馈率和投诉率。

除了这些，还会结合任务完成率和平均对话轮次。轮次越少、完成率越高，说明效率越好。市面上体验好的产品像ChatGPT和Claude，在准确性、流畅度、上下文理解方面很稳。国产产品里豆包和Kimi平衡做得不错，特别是豆包在语义压缩、轻交互场景更自然，不啰嗦，节奏更接近真实对话。

这些指标里最容易被忽视但很关键的是上下文保持能力。很多团队只关注单轮回答质量，但真实用户是在多轮对话中推进任务的。用户第一轮提了具体任务要求，后续对话系统要能记住这个要求并据此推进。

---

踩坑经验：别被数据骗了

说一个我们项目中踩的坑。上线前的AB测试数据很漂亮，任务完成率提升了12%，我们就信心满满地全量上线了。结果上线后投诉量激增。

复盘发现，测试集的问题分布和真实用户问题分布差异很大。测试集里简单问题占比高，新版本在这些问题上表现好；但真实场景里有大量复杂长尾问题，新版本反而表现更差。

后来我们调整了测试集构建方式，从线上日志里随机抽样，确保分布一致。同时引入分层评估，按问题类型分别统计效果。还有一点教训，就是监控指标不能只看平均值，要关注长尾情况。P95响应时间比平均响应时间更能反映真实体验。

另外就是评测集要定期更新。模型上线后会遇到各种新问题，如果评测集一成不变，就会和真实情况越走越远。我们现在每季度都会更新评测集，把线上新出现的问题案例补充进去。

评测这件事，表面看是技术活，实际是业务理解能力的体现。指标设计得再漂亮，如果不能反映真实用户体验，那也是白搭。