产品经理如何评估大模型效果，并从数据、Prompt、RAG、模型和体验层面推动效果提升？｜高频面试题解析

60 秒回答模板

我会先把大模型效果定义成具体场景下的任务成功，而不是单看模型通用能力。第一步是明确用户任务，例如问答、摘要、检索增强、写作、客服或代码辅助；不同任务的效果指标不一样。第二步做评估体系，通常分离线评测、人工评审和线上指标三层：离线看准确性、相关性、完整性、幻觉率、格式遵循、安全性和延迟成本；人工评审看是否真正解决用户问题；线上看采纳率、追问率、重试率、投诉率、留存和转化。第三步要建 badcase 闭环，把失败样本按意图识别错、上下文缺失、检索召回差、Prompt 约束弱、模型能力不足、输出体验差、安全策略误杀等原因归因。第四步再选优化杠杆：数据层补高质量样本和评测集，Prompt 层调整角色、约束、示例和输出格式，RAG 层优化切分、召回、重排和引用，模型层考虑微调、蒸馏或换模型，体验层通过澄清问题、置信提示、编辑入口和人工兜底降低失败感。最后用 A/B、灰度和回归评测验证收益，避免只在少数样例上变好却带来成本、延迟或安全回退。核心是先评估和归因，再选择最便宜、最可控、最能改善用户任务的手段。

考点 场景化定义

难度 真实面经题

回答目标 让候选人能用产品经理视角讲出大模型效果评估和提升的完整闭环：先定义效果，再分层评估，归因 badcase，选择优化杠杆，并用线上指标验证。

深入解析

先定义效果口径

大模型效果不是抽象的聪明程度，而是某类用户在某个场景下能否完成任务。产品经理要先说明用户目标、输入形态、输出要求、容错空间和失败成本。例如知识问答更重事实性和可引用，创意写作更重可编辑性和风格，客服助手更重解决率和安全边界。只有先定义场景，后续指标才不会混乱。

评估体系要分三层

第一层是离线评测，用固定样本集检查正确性、相关性、完整性、格式遵循、幻觉率、安全性、稳定性、延迟和成本。第二层是人工评审，让标注者或业务专家按 rubric 判断答案是否可用。第三层是线上指标，例如首答采纳率、继续追问率、重新生成率、编辑率、投诉率、任务完成率和留存。三层互补，离线适合快速回归，人工适合复杂质量判断，线上适合验证真实用户价值。

评测集要覆盖真实分布和关键风险

高质量评测不是随手挑几十个问题，而是从日志、用户反馈、运营样本、专家构造和边界 case 中抽样。样本要覆盖高频意图、长尾意图、容易幻觉的问题、敏感问题、多轮上下文、格式约束、低质量输入和高价值业务场景。评测集还要版本化，区分回归集、挑战集和线上新鲜 badcase，避免模型只对固定题库过拟合。

badcase 归因决定优化方向

看到效果不好，不能直接说换模型。要把 badcase 拆成输入理解、任务规划、知识缺失、检索失败、证据冲突、Prompt 指令不清、模型推理不足、输出格式错误、拒答策略过严、产品交互引导不足等类别。不同原因对应不同手段：知识缺失可能优先做 RAG，格式不稳可能先改 Prompt 或 schema，复杂推理不足才更像模型能力问题。

优化杠杆按成本和确定性选择

通常先做低成本高确定性的改动：补充指令、约束输出格式、加少量示例、调整上下文顺序、增加引用要求。若问题来自知识覆盖，再优化 RAG 的文档切分、元数据过滤、召回路数、重排和上下文压缩。若问题来自任务能力，可以考虑微调、偏好优化、模型路由或更强模型。若问题来自体验，则用澄清问题、结果解释、置信提示、可编辑模板和人工兜底降低失败率。

效果提升必须看综合取舍

一个方案让准确率提升，但延迟翻倍、成本翻倍、引用更差或安全风险升高，未必是产品上更好。产品经理要把收益和代价放在一起看：质量指标、用户体验指标、成本、稳定性、可维护性、安全合规和上线周期。大模型产品常见取舍是更强模型和成本之间、更多上下文和延迟之间、更严格安全和误拒之间、更自动化和可控性之间的平衡。

上线后要形成持续闭环

效果提升不是一次评测结束。上线要灰度发布，观察核心指标和护栏指标，同时收集用户反馈和人工抽检样本。新 badcase 要进入标签化分析，再回流到评测集、Prompt、知识库或模型训练。每次迭代都要做回归，防止解决一类问题后引入新幻觉、格式退化或安全回退。

易错点

把大模型效果等同于通用榜单分数，没有落到具体产品场景和用户任务。
只看离线准确率，不看人工可用性、线上采纳率、延迟、成本和安全护栏。
没有评测集分层，拿少数主观样例判断整个模型效果。
遇到 badcase 直接要求换更强模型，没有先归因是 Prompt、RAG、数据还是交互问题。
只优化平均效果，忽略高风险场景、长尾意图和关键用户路径的失败成本。
把 Prompt 写得越来越复杂，却没有版本管理、回归评测和可维护性考虑。
上线后不做灰度和持续 badcase 回流，导致新版本质量回退无法及时发现。

面试官追问

如果离线评测变好，但线上用户反馈变差，怎么分析？

先检查评测集是否偏离真实流量，例如样本太简单、只覆盖高频意图或没有多轮场景；再看线上是否有延迟、成本、拒答率、引用质量、交互路径变化等体验问题。离线分数提升只证明固定样本更好，不能替代真实任务完成率。

如何设计人工评审 rubric？

rubric 要和任务目标绑定，常见维度包括事实正确性、相关性、完整性、可执行性、格式遵循、语气、引用可信度和安全合规。每个维度最好有明确评分标准和反例，并用双人评审或仲裁降低主观偏差。

什么时候优先做 RAG，而不是微调模型？

当 badcase 主要来自知识缺失、知识更新、企业私有资料或需要可追溯引用时，优先做 RAG。微调更适合稳定任务格式、风格、领域表达和偏好对齐，但不适合频繁更新事实知识。

Prompt 优化到什么程度就该停？

当问题已经不是指令表达不清、格式约束不足或示例缺失，而是模型缺知识、检索缺证据、推理能力不足或产品流程设计不合理时，就应该转向 RAG、数据、模型或交互层优化。继续堆 Prompt 会变脆且难维护。

如何衡量效果提升是否值得上线？

看目标指标是否显著改善，同时护栏指标没有明显恶化。比如准确率、采纳率、任务完成率提升，但延迟、成本、投诉率、幻觉率、安全误拒和回滚风险都在可接受范围内，才适合灰度扩大。